MegaBomber

Use this forum to share and discuss Uzebox games and demos.
Post Reply
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

MegaBomber

Post by D3thAdd3r »

Throwing any info for this game here since people ask about it from time to time. The GitHub version is the latest version I can find, and is only a couple months before the last demo I released. In particular most of the additions are trivial to add to the code existing, but I will still attempt to latest code still. I can build it(all 4 versions?), but the AI doesn't work and the level gimmicks are very broken. I believe this was the point right before I eliminated the surrounding tiles and just made the game field bigger(huge gain for flash space, and better playability). But most of the code I remember for the AI is actually there. So worst case I could likely bring this past the last version in a weekend of work if I randomly get inspired.

So yes, super broken gimmicks, foreground graphics, etc, but I didn't realize this much space had been gained back. Probably with SD card tricks, this could be a game with 2-3 level sets, and could do multiple maps/gimmicks per tile set(fire tiles are expensive and can't translate to other floors). So yea, this could probably be a real game.

AI is broken in these, but I tested Player 2 is working. If you have someone to play against, let me know if the gameplay is any fun.
mb-recovery.jpg
mb-recovery.jpg (559.68 KiB) Viewed 2330 times
Attachments
MB-SandMan.hex
Lost source for this one, AI decent, can recreate better
(145.14 KiB) Downloaded 218 times
MB3.hex
(152.75 KiB) Downloaded 224 times
MB2.hex
(152.26 KiB) Downloaded 214 times
MB1.hex
(151.55 KiB) Downloaded 238 times
MB0.hex
(150.19 KiB) Downloaded 219 times
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: MegaBomber

Post by Artcfox »

Oooh, nice! I will have to try these out tonight once everyone else is asleep.

Edit: Wow! These are very awesome! :D
User avatar
danboid
Posts: 1931
Joined: Sun Jun 14, 2020 12:14 am

Re: MegaBomber

Post by danboid »

Thanks for reviving Mega Bomber! I've had a quick test of these levels under cuzebox and it seems 2 player is working so I look forward to playtesting it with two players properly on my real Uzebox shortly. I'd love to see you finish this but even in its current unfinished state its a big win having working two player mode (again?) as this is one of the best looking Uzebox games.
User avatar
danboid
Posts: 1931
Joined: Sun Jun 14, 2020 12:14 am

Re: MegaBomber

Post by danboid »

Are you saying that these four hex files are built from the current github source without any changes? Was I building it wrong?
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: MegaBomber

Post by D3thAdd3r »

@Artcfox - Thanks!

@danboid
No the Github sources as they currently stand, do not build. Primarily the need for "const" and now broken "inline" usage(new version of GCC?). The code is in horrible state, but I will at least get it cleaned up and building in Linux and push that to Github. I just did some hacks to make it work for now. I suspect this could have something to do with the AI, as it was definitely "working" well before the date on those files. I guess the 2P was disabled since it didn't use the menu flags for "CPU" and "MAN" yet.

100% I had players, bombs, and fire going "underneath" the igloo at one point(I so wanted to see that again...then disappointment), but I was chopping at the gimmicks to make it compile time selectable...and there are obvious artifacts. Where in MB3 is supposed to be a big tree you can walk under instead of a broken igloo. I remember getting the mine cart partially working and running over the bots! Early on I had conveyor belts in the industrial/factory one that has no gimmicks now. I had to redo the conveyor belts since they were a tricky challenge to the optimizations taken towards the bomb system. Anyway just some info, thanks for the nudges, this feel pretty good to actually have all stages shown.

Anyway the foregrounds can be made to work again, I'm assuming tile numbers changed or something. The "SandMan" level and newer AI code I will keep looking for, but mostly what's here already can be salvaged. Give me some time and I'll have a buildable version cleaned up and some hacks removed.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: MegaBomber

Post by CunningFellow »

Looks very pretty. I have no idea what the game is or how to play it, but it indeed looks nice.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: MegaBomber

Post by D3thAdd3r »

I can't take much credit for the graphics, but I did try every 8/16 bit Bomberman in existence and IMO the Japanese only Super Bomberman 5(might notice similarities 8-) ) easily stands above all.

Just as a hypothetical on continuing development. I'd use SPI RAM music/SFX to save space now(even if it had to drop to 30Hz...possibly better for Uzenet anyway). I could offload the AI code as a standalone Linux bot(or 3) that is always available to play against. Then I'd be sitting at maybe 12K free flash which would buy lots of extra graphical flourish. I happen to have access to a 30Gbps presence in a Minneapolis data center, BGP to the "backbone", and this network must stay up 24/7/365 or I am unemployed.

Then adding a fancy level select menu, RAM tiles can be used to load a small representation of a particular level(with tiles not in ROM, from SD) to play, so it's unlimited levels. After a level has been selected, if it isn't the one currently flashed, request the bootloader to load the needed .uze of the multi-rom .uze file.


Questions someone probably knows the answer to. As I understand it >= v5 bootloaders can actually load from an arbitrary offset on the SD, not just the beginning of a file? So the individual .uze files could be padded to the max size of 60K, then just directly concatenate multiple into 1 file to make this work?

Jubatian's bootlib.h and BootDemo seems self explanatory. So with a concatenated ROM, one could just:

Code: Select all

sdc_struct_t sd_struct;
u32 t32
sd_struct.bufp = &(ram_tiles[512]);//some unused ram tiles for buffer
FS_Init(&sd_struct);
t32 = FS_Find(&sd_struct,
((u16)('M') << 8) |
((u16)('E')     ),
((u16)('G') << 8) |
((u16)('A')     ),
((u16)('B') << 8) |
((u16)('O')     ),
((u16)('M') << 8) |
((u16)('B)     ),((u16)('U') << 8) |((u16)('Z') ),((u16)('E') << 8) |((u16)(0)));

t32 += (60*1024*ROM_NUM_TO_USE);
FS_Select_Cluster(&sd_struct, t32);

Bootld_Request(&sd_struct);
while(1);
I know there are arguments against using Prog_Page@0xFFAA to directly write flash sectors, but it is technically possible right now? Does cuzebox support this? Best just to call it as a function pointer, or some inline asm?

As for arguments against direct flash writing, I do respect the concerns(EEPROM too, trivial to be a malicious asshat for a short time) could we have emulator features(not allowing ROM to know it's in an emulator) that alert to excess writes in addition to in game warnings? It seems being able to inspect and build from source, plus warnings, and emulator verification would suffice to feel good about things. To be fair if I made a game with a bug that destroyed chips, I'd feel terrible and mail out replacement '644s with a sincere apology, but it seems very unlikely things would ever get there.
User avatar
ry755
Posts: 226
Joined: Mon May 22, 2017 6:01 am

Re: MegaBomber

Post by ry755 »

D3thAdd3r wrote: Sun Feb 26, 2023 9:31 am Questions someone probably knows the answer to. As I understand it >= v5 bootloaders can actually load from an arbitrary offset on the SD, not just the beginning of a file? So the individual .uze files could be padded to the max size of 60K, then just directly concatenate multiple into 1 file to make this work?
Yes, that should work.
D3thAdd3r wrote: Sun Feb 26, 2023 9:31 am I know there are arguments against using Prog_Page@0xFFAA to directly write flash sectors, but it is technically possible right now? Does cuzebox support this? Best just to call it as a function pointer, or some inline asm?
I used inline assembly in my bootloader update utility: https://github.com/ry755/bootloader-upd ... ate.c#L141.
(actually now that I look back at the code for that utility I see some potential unrelated bugs, oops)

cuzebox does support it, I've tested it and it worked fine. One of the main things you'd have to watch out for if you go this route is accidentally overwriting the code that is calling Prog_Page :P
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: MegaBomber

Post by Artcfox »

If you use the bootlib API to reflash a game it will only write to the sectors that changed, and it does proper verification and handles multiple retries automatically, so we might as well use that to save space and ensure correctness.

With the old bootloader, my AVR didn't always flash a game perfectly, sometimes there was corruption in the graphical tiles, sometimes in the logic. With v5 it always flashes correctly.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: MegaBomber

Post by D3thAdd3r »

Thanks guys. So I will try the bootlib method first and see if the delay is tolerable. Otherwise the bootloader updater code is a great example if not. It seems either method can avoid unnecessary rewrites. Either way there would be a warning in intro, and a confirm button hold in game before. For a bit of an extra delay and some codespace, there could be a flash counter stored in SD to watch a real world trends.

I think I'd look into putting all the flash tiles and per level gimmick code, in padded out max size blocks at fixed locations, towards the end of the ROM. Lets imagine some user will play MB 100 times ever, with other games in between plays, and changes levels 4 times each session. This would apply sort of to either method.

So 100 writes against all flash to start sessions(free, since the ability to change games at will is by design), then 4 additional flashes each, against the last pages to change levels. So the last pages receive 500 writes versus the 100 for the lower pages(common code).

I'd imagine such a hypothetical MB power user could also play a blend of the many "short ROMs" at a 6:1 ratio to MB, like demos or smaller games that never hit the last pages(ideal). It seems then to me, the first section(staying the same in a game so designed) will be worn out first just like it would have "naturally".

Alternatively, perhaps per level data could be put "randomly" at the beginning or end of different ROMs, with the common code handling either case? That would seem to also minimize hot spots in the event the user doesn't balance with short ROMs. Complex, but it seems possible.

So many possibilities there, does the above make sense or could there be better ways? Thanks again for the help guys.
Post Reply