Lunar Lander

[Myndale]

Looking over the world test, that is astonishingly good work! Makes me want to add animation now to things like the water and cranes.

Deep breath, one thing at a time....

[Quirby64]

Erico,Erico,Erico....these are absolutely amazing. Such attention to detail, especially on a screen this size!
I also made these a couple days ago before I saw this map of awesome.

[erico]

hehe, yah!
I got some story coming to breath life into the gfx and another type of pad to the 2 current ones.

Depending on the world test, how it fares, next work in refining it and placing the pads.
Since each pad will have some text to it, I have to check fonts and text limit (ye, no wall of texts).

Meanwhile we should strive for a working world. I will wait for the tests.

[erico]

... Such attention to detail, especially on a screen this size!...

Thanks, that must be the reason it took 7 days to put it up.

Hopefully this will come to be a game that will interest people.
Long-run type of game with multiple endings (like pirates), so you don´t leave your Gamebuino home.

[Myndale]

Initial tests of compression were disappointing, around the 30k mark. My previous algorithm wasn't designed for such high-res detail though, I've just tested with the .NET compressor on the raw data stored in 8110 LCD format and got it down to just over 15k. If I can decompress that in real-time without needing too much RAM then I'd say we're right up against our upper-limit.

Fingers crossed...

[Myndale]

Ok, as always it looks like I need to compromise memory vs compression vs speed.

For the programmers: GZIP compression gets the whole map down to ~15kb while LZW manages about 12kb, but these unfortunately require a lot of RAM for decompression tables so not feasible on Gamebuino. LZSS requires almost no RAM and is very fast but only manages about 20kb. The best results I've had so far have been with quad-trees, which is effectively a form of 2d run-length encoding. I use a 4-value Huffman table derived from the image itself: '110' means fill the entire rectangle with black, '10' means fill with white, '111' means raw bits follow and '0' means recurse down to the next level.

With this scheme I can get it down to about 16.5kb of flash with virtually no RAM requirement i.e. just over 3:1 compression ratio. That's really pushing available memory but I'll see what I can do. If anyone else knows of some good low-memory decompression algorithms then I'm all ears!

[jonnection]

I am also very interested on the whole compression/decompression problem on the Gamebuino. I made my own packing routine which is normal rle except for the fact that it switches to unpacked bits at boundaries to avoid memory waste on complicated areas. I get around 1:2 to 3:4 compression with that.

Myndale: are you packing the whole map or individual screens within the map? Because if I've understood correctly the world will not scroll but will be drawn in sections. How will you unpack only a section of the map if you're using quadtrees and/or rle type procedural packing? If the world is drawn in sections, why not read from sd card as there is no real need for speed between the sections?

Edit : oh yeah, I once listened to an interesting story about how maniac mansion was crammed into the C64. What they did was that the artist drew the room, the programmer ran an analytical tool on the artwork that determined how to approximate the artwork with a limited set of tiles. Then the artwork was optimized to remove tiles that occurred rarely and/or were close variants of existing tiles. A similar scheme could possibly work here as well, and yet allow for a lot of detail.

[Myndale]

How will you unpack only a section of the map if you're using quadtrees and/or rle type procedural packing?

Well spotted! I've been giving it a lot of thought....first of all it'll be faster by simple virtue of the fact that the background itself doesn't actually need to be drawn for sections that are outside the view frustum. Next, I can store offsets into the quad tree down to a certain level to skip large sections of it (where the exact cut-off is will probably come down to experimentation). Thirdly, as a last-case resort, the back-buffer doesn't have to be drawn every single frame, I only need to worry about the bit behind the lander (at least until I want to start animating things). Finally I can keep track of the hierarchy tree between frames, this was actually a technique I used in a commercial game called MX vs. ATV Unleashed which had many, many technical problems, none of which were related to any of the code I wrote myself!

If the world is drawn in sections, why not read from sd card

Because the data has to be stored in flash, which has limited write cycles. And yeah, I'm probably being way too conservative, but if I can find a way to avoid it I will.

[Drakker]

I might be a bit off topic here, but the Gamebuino has an SD card... so why are you bothering with RAM compression at all? Wouldn't it be much simpler/less RAM hungry to read the data from the SD card straight to RAM? You could technically have an almost-infinite size world that way.

[Myndale]

I might be a bit off topic here, but the Gamebuino has an SD card... so why are you bothering with RAM compression at all

The TinyFAT library requires a 512 byte RAM buffer, which leaves almost nothing for the game itself. Rodot recently exposed the 504-byte display buffer but that's still not quite large enough, so I'd have to modify both the Gamebuino and SD cards libraries to work with each other to use a shared buffer. The TinyFAT library is also quite slow, on account of the fact that it doesn't do much book-keeping on account of the fact that it's trying to save on its memory requirements.