Home | Downloads | Screenshots | Forums | Source code | RSS | Donate

Register | Log in

< Hardware renderer progressMerry Christmas from melonDS >

Why make it simple when it can be complicated? Dec 15th 2025, by Arisotura

First, a bit of a status update. I'm about to begin a training period of sorts, that will (hopefully!) lead to an actual job next year. It looks like a pretty nice job for me, too! So that part is sorted out, for now. Next, the OpenGL renderer is still in the works, although I've been taking a bit of a break from it. But hey, when you happen to be stuck on a train for way longer than planned, what can you do? That's right, add features to your renderer! The latest fun feature I added is also the reason behind this post title. The DS's 3D renderer has registers that set the clear color and depth, and a bunch of other clear attributes - basically what the color/depth/attribute buffers will be initialized to before drawing polygons. Much like glClearColor() and glClearDepth(). However, you can also use a clear bitmap. In this case, two 128K "slots" of texture VRAM (out of a total of 4) will be used to initialize the color and depth buffers: slot 2 for the color buffer, slot 3 for the depth buffer. The bitmaps are 256x256, and they can be scrolled. It isn't a widely used feature, but there are games that use it. As far as melonDS is concerned, the software renderer supports it, but it had always been missing from the OpenGL renderers. Since I was busy adding features to the compute shader renderer, I thought, hey, why not add this? Shouldn't be very difficult. And indeed, it wasn't. But the game I used to test it threw me for a loop. This is Rayman Raving Rabbids 2. In particular, this is the screen that shows up after you've played one of the minigames. The bottom screen uses the clear bitmap feature - without it, the orange frame layer won't show up at all. When I was debugging my code, I looked at my clear bitmap textures in RenderDoc, and expected to find the orange frame in the color texture, but there was nothing. For a while, I thought I had missed something, because I expected that layer to be in there. But it wasn't the case. That layer is actually a 2D layer (BG1). The clear bitmap feature is used to block the 3D scene (including the blue background) where the orange frame would appear. To do this, they just use a depth bitmap. There's nothing mapped to texture slot 2, so the color bitmap is all zeroes (and therefore completely transparent). I also noticed the glitchy pixels on the right and bottom edges, and that had me chasing a phantom bug for a while - not a bug in melonDS, the edges of the clear bitmap are just uninitialized. It looks like someone at Ubisoft goofed up their for loops. This made me wonder why the developers went for this approach, given how much VRAM it takes up. When they could just have, you know... changed the priority orders to have BG1 cover the 3D scene. No need for a clear bitmap! Another possibility was to draw this orange frame with the 3D engine. This would even have enabled them to add a shadow between it and the background, like they did on the top screen... maybe that was what they wanted to go for. But this is the viewpoint of someone who knows the DS hardware pretty well, so... yeah. I realize not all developers would have this much knowledge. And hey, I won't complain -- the diversity in approaches helps test more possible use cases! I could also talk about why I was messing with the compute shader renderer in the first place. Remember this? That was my little render-to-texture demo. I wanted to try adding support for hi-res capture textures in the 3D renderers. Reason why I started with the compute renderer is that it already has a texture cache, and thus does texturing in a clean way. On the other hand, the regular OpenGL renderer just streams raw DS VRAM to the GPU and does all the texture addressing and decoding in its fragment shaders. It's the lazy approach to texturing: it works, it's simple to implement, but it's also suboptimal. It's a lot of redundant work done on the GPU that could be avoided by having it precomputed (ie. what the texture cache does), and it makes it harder to add support for things like texture filtering. So, you guess: I want to backport the texture cache to the regular OpenGL renderer before I start to work on that one. There are also other improvements I want to make in there, too. The texture cache could even benefit the software renderer, too. Anyway, fun shit!

14 comments have been posted.

< Hardware renderer progressMerry Christmas from melonDS >

Post a comment
Name:

DO NOT TOUCH