Getting Real About This Update
This stretch of development was a weird mix of exciting and humbling. I finally pushed the engine far enough that all the little shortcuts I’d been getting away with came back and demanded attention. The moment I added more meshes and started moving them around, it became painfully obvious that depth sorting just wasn’t a thing. New objects always drew on top. Didn’t matter where they were in the world...if they were born last, they ruled the scene.
That kicked off a whole chain of fixes: sorting, transparency, per-entity materials, per-entity sprite textures, and cleaning up the constant buffer system. Honestly, I felt like I was stumbling around in a dark room looking for the light switch. I’d bump into something, swear a little, try again, and eventually the room started to take shape.
Per-Entity Materials Without Bleeding
One of the big lessons I learned: materials need their own space. Early on, every cube and sprite was sharing the same constant buffer slot. So if you changed the color on one cube, everything else changed too. It was funny the first time. Then it got old really fast.
The fix was simple in concept, but took me awhile to really internalize: every entity gets its own aligned spot in the constant buffer. That means transforms, materials, and sprite data all have independent offsets. Suddenly, modifying one cube didn’t yank the rug out from under the others.
Per-Entity Sprite Textures
Sprites originally lived in that “just make it work” category. One texture for everything, no questions asked. That obviously fell apart once I started giving each sprite its own identity.
Now every sprite gets its own SRV in a dedicated heap, with proper allocation and tracking. You can import textures, assign them per sprite, and nothing conflicts. This was one of those “finally” moments where things started to click and I could visualize the progress.
Depth Sorting That Respects Reality
The biggest visual improvement came from finally tackling transparency and sorting. Before, everything just rendered in creation order, which meant sprites could end up in front of cubes even if they were miles behind. Transparent edges cut literal holes into other objects. Depth writes were wrong, depth tests were wrong… everything was wrong.
The fix involved drawing opaque geometry first, turning off depth writes for sprites, and sorting sprites back-to-front every frame. It’s not glamorous, but it works, and it feels like a proper game engine now.
Another nice touch I wanted to call out, was you get the classic CRT after-image of phosphor decay magic as you move items around in the scene, even while in editor mode. I thought it was a cool proof of the underlying render process as well.
Breaking Things Down, Slowing Down
The real turning point wasn’t a single line of code, it was accepting that I needed to slow down. I usually like to build fast and let the pieces fall into place later, but that wasn’t cutting it here. So I refactored. Cleaned up the flow of data. Made sure I understood every step instead of just hoping it worked.
And once I did that, everything clicked into place. Materials behaved. Sprites behaved. Sorting behaved. It all felt less like fighting the engine and more like collaborating with it.
Next Steps
With the rendering side finally stabilizing, I can start pushing into more interesting editor features. Things like:
- Better material editing tools
- Hierarchy and parenting
- Smarter sprite workflows
But really, the big takeaway these past couple weeks was that the engine is growing into something comfortable to work inside. Moving objects around, changing colors, swapping textures, it all feels natural now. That’s a huge milestone.