[game] bomberman

[cieszak]

Finnaly released public version. I had to make it long ago but ... forgot. :) May be some bugs, but now I haven't too much time to check it.

ENGL:Bomberman 2.03. Kill all monsters and find way to next level. Keys 2-up, 8-down, 4-left, 6-right, 5-bomb, 0-manual detonation.

POLI:Bomberman 2.03. Zabij wszystkie potworki i znajdz przejscie do nastepnego poziomu. Klawisze 2-gora, 8-dol, 4-lewo, 6-prawo, 5-bomba, 0-detonacja ręczna.

[deadspot]

Thanks For The New Game.....

[BlinK_]

Hey, you finished and realeased it. Thank you.. (: I was so waiting for this game. Screenshots were available for such a long time in your site.

[nuukiaworld]

Thanks for the great game!

As usual, I had problems in making the game to fit in my 6110. That's why I wrote null_file_system.nrx. However, it did not solve all problems: The RAM (heap) usage of Bomberman is so huge, that most other applications hang if I have an unfinished BM game. (The phone hangs because there is not enough free RAM for the FreeGFX buffer with blinking needed by the other application.) For example, the official calendar patch hangs on 6110 if a BM game is unfinished.

That's why I started to do some quick-and-dirty modifications to Bomberman so that the size of the struct game would be much smaller than the original 1228 bytes. (struct game is reserved from the heap even when the game is paused, until the game is played to the end.)

After my "quick" (ok, it took the whole day) modifications, the memory needed by struct game is only 444 bytes (64 % less) :-o ! This is small enough to allow other applications to use FreeGFX even when a BM game is paused.

Note the following compared to the original version:
max. size of map 16 × 15 (was 25 × 25) (allows storing map_x and map_y of objects in one byte)
custom map files should work, although not tested
the idea of storing objects in linked lists consumes even more RAM, luckily it was not implemented
high score handling fixed
plus other minor changes...
BTW. the code got more than 1.5 kB smaller, too :-D
Even more code space could be freed if the whole code is written using "packed" one-byte representation of map coordinates (if 16 × 16 map size would be enough). It would ease comparisons and allow passing the position in one argument (currently two arguments are required, map_x and map_y in many places). However, this would have needed much more time and would have been much more error-prone because negative values cannot be represented in the packed format. Whole code should have been analyzed the see where negative map coordinated are possible.

Edit: Last weekend I couldn't take my thoughts away from how to optimize BM even further. May be some day I'll continue on it trying to minimize everything without affecting the functionality... :)