Devlog #2 — Rendering sprites

Welcome to a devlog for a retro arena FPS I am working on. If you want to know more about the project, go read <a href="https://medium.com/@nerudaj/devlog-0-embarking-on-a-new-project-948433ca7161" rel="noopener">the first devlog</a>. Each Saturday, I am going to share project updates as well as more technical discussion on writing my own engine in C++. This week I want to talk about basic sprite rendering and occlusion techniques. <a href="https://medium.com/@nerudaj/devlog-1-writing-a-raycaster-in-2023-44485b6e0ccc" rel="noopener">Last time</a>, I’ve talked about rendering the game world. Adding sprites — that should be easy once that I have all of the level mesh rendered. Or not? Well.. I had some considerations to make. The rendering engine worked so far with just one vertex array to which I pushed all quads for rendering. I could do so because all quads used same texture (the tileset texture). Since they are pushed into the same array, they can overlap for as long as I can insert them in the sorted order and they will render just fine. It would be nice if I could mix in the sprites as well, and let the GPU sort it out, but I can’t. I would have to merge the tileset and the spritesheet texture which is not practical (having all sprite textures in a single sheet is impractical enough). So I needed to take an inspiration in Wolf3D engine and cheat a little bit as well. So how does the Wolfentein do it? It stores a depth buffer for each screen column. Since the raycaster returns an exact point where a ray hit a wall, it can compute the distance to the camera and store that in the buffer. The raycaster also marks all things that were encountered during the casting step. <a href="https://medium.com/@nerudaj/devlog-2-rendering-sprites-81a378575f76">Click Here</a>