calimero wrote:Wow! I must try it on real hardware tonight! So this kind of display does not use almost nothing CPU (two fields with 16 colors)?
Just 16 colours, and 2x 4plane bitmaps yes. No CPU.
calimero wrote:So burden now would be on decompressing images... Is it possible to somehow compress further GIF 16colors file? (your examples have around 20KB converted to GIF 16colors)
GIF uses LZ form of compression which is just one of many dictionary types. They all try to use the smallest encoding for the most common values, with the largest encoding for the least common. The algorithm is sometimes a bit less important than how the data is stored, and making sure related data is stored together, to benefit reuse in the dictionary.
You can LZ the two bitmaps separately or combine them and LZ together. My previous post recommended bitplane->nibble translation (chunky) first, then combine nibbles to bytes, then LZ the bytes. Or just LZ the two sets of nibbles but this might be a bit algorithm sensitive if its (wrongly!) expecting to compress patterns of bytes for some reason.
Regardless - don't LZ the bitplanes directly. Bad dictionary coherence. Bad compression.
But you still need to pre-calculated images for "only background" and than for "background + enemy" (and for each enemy you would need to do same pre-calculated images - there would be like thousand of images...).
Actually no - it should work the same way as it did for the texture sets needed for ST-Doom.
You collect all of the graphics together into a 'textureset', with representative use. i.e. the number of pixels dedicated to scenery should approximate its importance (there are lots of way to do this but a quick hack can involve just duplicating 'important' content a few times).
You then generate a superpalette for all of it together. Then convert all of the graphics to that superpalette, using the colour map produced by the tool (2 fields for everything). Then you can combine all the gfx without conversion.
If you want *more* colours still, you can go a bit further. Generate the gfx in overlapping context groups (say, 8 groups for a really challenging game) and store each graphic once, with its own colour map. Then remap the gfx to the active palette group when it is in use. This way, irrelevant gfx don't have to pollute the colours needed by relevant stuff vs the same background (e.g. bg==fg1, bg==fg2, but fg1!=fg2).
Since the gfx will need decompressed anyway, some table remapping won't hurt that much in comparison.