Bitmap buffering

[taylorza]

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

@maxint

@ taylorza: to get rid of the flickering I tried to make a double buffering library that would allow drawing to a (tiny) bitmap that could then be dropped onto the display. The required bitmap size was too large for the available memory to support my Pong-variant, but the technique worked. Unfortunately I didn’t find the time to implement bitmap compression, but I did some research on using a palette combined with LZH/RLE, which looked promising.
It would be nice if you could add something like that to your graphics library.

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.

@maxint

P.S. In my ball-and-holes maze-game also noticed that two line rectangles miss a pixel in the bottom-right corner. Thanks again for providing the library.

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

[taylorza]

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

Thanks for reporting the issue.

[cfavreau]

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.