Here is one idea I have to reduce the overdraw in my game : Since I'm using RGB code for objects close to the camera and palette codes for objects further away, I thought about simply using the framebuffer as a pseudo- z-buffer. Since I know pixels starting with a 1 (RGB code) are closer to the screen than pixels starting with a 0 (palette code), I could just test palette objects against the previous frame to reject them (like, if the area is covered by 1, the object is occluded and doesn't need to be rendered). I'm not sure if I could even manage to do it quickly enough to make it worth it - since it would require some perspective divisions for the whole mesh, but I could also just test it with the buffered sprite commands and insert a skip command if it fails the test - but anyway it's worth testing. But here is the main issue : reading from the framebuffer is really slow from the little tests I made. Of course, I don't transfer the whole buffer, I just made tests with a smaller buffer (like 64x32 or something and just skipped pixels). Is it possible to do it indirectly (like a scu dma transfer) so that the Cpu can continue doing other things? What would be the best moment to do it? V-blank in? And since I'm reading that buffer anyway, if I wanted to transfer to a sprite or scroll layer, what would be the best time to do it? SGL has a function to get the framebuffer, which is what I'm using, but there is very little detail on how to properly use it or what it does internally, so I'm not even sure I do it right. Right now it's so slow that I would be better off to just create my own z-buffer. Thanks!