Bitmap buffering

I am replying here as I do not want to detract from @ Architect’s thread.

Using a small double buffer is exactly how I achieved the sprites overlaying the background in RETRO Cave Dweller. My sprites are all only 1 bit 16x16 in size, I then determine the dirty rectangle based on the sprites movement and compose the background and the sprite onto a 4 bit 24x24 sprite which is then rendered in its entirety to the full color screen. This allows each object to be one of 16 colors and they can coexist. I did not bother with RLE or any other compression.

I will take a look at that and post an update, thanks.

@ maxint - I just published a fix for the issue you identified with fill rectangle. I am clearly mathematically challenged…

Thanks for reporting the issue.

Since it is close to the end of the contest.

I used a different approach. I have a tile map and a list of sprites. Each tile/sprite is 1 bit 8x8. They could be bigger. I ran out of time. That much is not special. What is different from what I can tell is that I use a 1 line buffer that is 160 shorts long. The render function first adds the tile map data into the line buffer first. Then the sprites are added over the existing data. You can have a great deal of different sprites and maps going to the screen and just have to rewrite the LCD memory once per frame. After each line is composited, the line is then drawn to the LCD. Kind of like an Atari 2600. Each sprite/tile has a foreground and background color and can be different from the other tiles/sprites. There is one color reserved for Transparency.