MegaBomber

Use this forum to share and discuss Uzebox games and demos.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: MegaBomber

Post by Artcfox »

Putting the changes at the end to balance out shorter games seems like a "free" win, so no harm there. I think as long as it is explicit to the user when a reflash is happening, it should be okay. The most explicit would be using the bootloader and then you get the visual indication of which blocks changed and which remained the same and did not get reflashed. If it happened behind the scenes, or if a user found they could reload an old save/checkpoint to effectively get unlimited lives then I think it becomes a problem.

If it is split up so you play all of "volume 1" before moving to "volume 2" then "volume 3" rather than switching every other level, then I think it should be no big deal, you would just be providing a convenient way to load the next volume rather than having the user select the next one from the bootloader manually.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: MegaBomber

Post by D3thAdd3r »

Makes sense. Seems like talking through things and getting some multi ROMs in the field will help build a more detailed general consensus on best practices. For now I'm planning the implementation of a red warning menu and the full bootloader reset. For an RPG or something that would probably be quite annoying.

One thing I forgot was the original game had 4 variations per level, where block patterns, starting locations, traps, and item probabilities are changed. Adding this would provide a lot of varied gameplay on the same assets minimizing reloads, which could be some single player/cooperative tournament quest thing too.

Using state across ROM loads will take some care, though here pretty simple versus an RPG. Planning on just storing stuff to the quasi-standard shared _HISCORE.DAT file which I hope others will too to minimize files.

I'll have to make a custom PCM only mixer to get back RAM for full blits(so no real world test is possible yet as my ram tiles are down several, 16 color sprites are 8 bit gibberish)...and I pulled in the new kernel which is way better than the 2011 version(hacked out sound engine for now)and have to graft back the 4bpp blitter from the old hack...and of course SFX are gone, etc. It's a build only a programmer could love :lol:

Mainly...got SD->SPI RAM PCM music playing and YES! I was head bobbing like a fool, same song as in the demos, but an SNES rip versus my never perfected MIDI version...different realms! If casually told to listen back to back for between the SNES version, most would pass the AB test sure. But all things considered, it sounds literally amazing to me.

I'm aiming for 2 PCM sound effects channels simultaneously over the music(1 channel explosions, 1 for pickups, kicks, throws, etc) but cycles will dictate this. I'm dedicating half the SPI RAM to preload sound effects, which is a lot, and they will be way better than the current half hearted placeholders in there now.

For those who never saw the ridiculous PCM rants I espouse regularly, essentially it's several relatively simple things in tandem: a custom WaitVsync always spins on filling the audio buffer instead of doing the normal nothing to achieve this. Then if Vsync flag is still not set(or if gameplay must be stalled)it will attempt to average a SD sector read once every <=1.9 frames to keep the buffer full. In the event it can keep up on reasonably fast audio buffer fills, but not enough time for SD reads, there will be no issue as long as the processing load lightens within ~4 seconds in theory. If the buffer is empty, gameplay will go down from 30Hz(2 Vsync Flags) to 15Hz(4) until it's full. Ideally that never happens, but slowing down is way better than horrid stuttering static. Not redrawing RAM tiles for 3 frames(still displays the old version) is quite a bit of time to avoid this.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: MegaBomber

Post by Artcfox »

It sounds like you have a really good plan!

I don't understand the part about not redrawing RAM tiles on some frames to save time the next frame for user stuff. Doesn't the kernel have an interrupt that requires it to output all of the pixels that make up the entire screen every frame? If so, wouldn't it have to redraw everything from flash or RAM tiles each frame? Or do you mean that you wouldn't be blitting to any new RAM tiles or restoring the background buffer, so you could just leave VRAM pointing to everything it was pointing to during the previous frame(s), so the same pixels would be automatically drawn by the interrupt giving you more time?
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: MegaBomber

Post by D3thAdd3r »

Yes exactly as you said, prevent the kernel from restoring flash tile indices for RAM tiles drawn. Don't change VRAM or RAM tiles, and it will still eat most cycles to display the frame to the screen at 60Hz, but there will be more user time cycles free. Someone sanity check me if they know better, but I believe this is what I've encountered.

Normally extra cycles would just be burned in the blocking WaitVsync(), so here I just did MBWaitVsync() which does as much as it can while checking the non-blocking GetVsyncFlag()

I should make a demo for it. The code is very similar to SPIRamMusicDemo, except it takes more RAM.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: MegaBomber

Post by Artcfox »

Ah, cool. One of the reasons I believe my always run at 60fps is because I didn't know how to do otherwise, so I had to keep optimizing. :lol:
User avatar
danboid
Posts: 1932
Joined: Sun Jun 14, 2020 12:14 am

Re: MegaBomber

Post by danboid »

Wow this sounds like it will be raising the bar for Uzebox games, the first multiload game! Proper 8 bit antics!

I'm looking forward to hearing this new improved Mega Bomber PCM BGM. How have you created this new PCM soundtrack and how did you do the music for the SPIRAMmusicdemo / Alter Ego? Is it purely coding skills and hard work or have you got some nice DAW/tracker -> .DAT file workflow sorted that you're not letting us in on?
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: MegaBomber

Post by D3thAdd3r »

Artcfox wrote: Thu Mar 02, 2023 5:19 am ...so I had to keep optimizing. :lol:
Definitely that is the ideal! A temporal tradeoff, I think of it as lowering time resolution. The player will feel it, so it matters a lot on the nature of the game.
danboid wrote: Thu Mar 02, 2023 11:27 am Is it purely coding skills and hard work...
When I manage to actually complete things, it's basically the amount of work put into it(like anything really). For me this is fun, as long as it's interested. Definitely about the journey, but making it to the destination is ideal.

I use Audacity to capture audio, and run the game's sound test. Then manually chop the pieces I need.

Music is the same capture process, though there are no length restrictions(so far haven't got around to proper loop timing for the music).
danboid wrote: Thu Mar 02, 2023 11:27 am ...or have you got some nice DAW/tracker -> .DAT file workflow sorted that you're not letting us in on?
All my ideas on MIDI are out there, but for PCM there could be some new stuff possible in that regard. So far I am getting my dconvert configs setup to properly build the pointer directory for the different SFX banks, and music. With that stuff in place, technically you could convert a lot of different sources to PCM. But even this is pretty manual, since you will want to trim down samples, make good cost/benefit analysis for the limited space/etc.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: MegaBomber

Post by D3thAdd3r »

Some progress has been made for PCMMusicDemo, which will essentially be the MB sound engine and resources. Now I actually believe this could be a near universal solution, and someone could chop out what they want of this demo and graft it in for their use case, and just replace the PCM. This would bring it closer to a legitimate Sound Engine alternative.

A big change is I gave up trying to make dconvert do what I want. Dconvert was made with Streaming Music(MIDI) in mind, but it will need some additions for PCM. Instead I just wrote a Shell script which takes in file names containing the SFX and music .raw files to use, concatenates, and (TODO) builds the directory/pointers for a standard format automatically. I abstractly experimented with many possible layouts, and I think the current is a good blend of all use cases; minimizing waste on the SD card, and cycles at run time. Good for a small game, or a full blown RPG(someone please?)

Basically the first 512 bytes of the SD image(and SPI RAM) contain the directory with fixed length entries about SFX and music. This starts with 4 banks of 20 SFX(start(2), len(2)) entries, and 16 song(start(4), loop(4), end(4)).

There is a following 512 bytes empty, or can be set to variable init states. Basically the sound player variables go here, followed by optional user variables. Unfortunately for bigger games with high RAM use, you almost certainly will need to put what game variables you can here to afford the buffer...

Starting at 1K offset is a direct dump of 4 banks(64K each, 63K usable per, last bank is only 62K usable) of SFX(unused padded with 0x00 by script). Each bank is defined by the corresponding list of .raw files to include in sequence. Doing a single 64K read from SD offset 0 into RAM starting at offset 0 has the effect of loading the full directory, and SFX bank 0 PCM for use(most games likely to use only this). Empty areas can be used by the game. Switching sound banks will be discussed later, it's relatively fast(hide during a transition), and you have about 4 seconds of audio per bank divided into/up to to 20 SFX per. I feel this is sufficient for a large variety up to even SNES level RPGs...ie overkill.

Directly after the SFX banks data, starting at 64K, is whatever music files have been specified, if any. This section is not fixed length, and each of the 16 songs can be any length. The directory pointers coordinate these tedious details(not fun manually..). For MegaBomber this is a good variety of music and lands at about 5MB. This music covers battle, menus, victory, defeat, etc., more 16bit like than 8 bit.

I was building this manually in a hex editor to start...what a pain. I will add the extra parts for automatic pointer calculation. At that point you fill the bank config files with file names of SFX in the order you want for each bank. Then the music file(filename, plus loop bytes offset). Then all editing is simply making the source sound files good, finding the loop point(or NULL for one shot), and rebuild instantly for quick testing. This is a boring but critical feature for development.

The new design keeps all playback variables inside SPI RAM, and does a sequential pull before Vsync, uses them, and writes them back. This minimizes RAM cost while being reasonably fast, as there are several 32bit pointers in use. Games incorporating this will already be at a pretty extreme RAM disadvantage to start, so I will document one possible use case to offload some game logic variables(very custom per game).

So if I can manage to finish it, it will try to show a "user database file". Besides MegaBomber, I will incorporate Columns PCM. Same format, just concatenated after MB. This use requires an offset(basically the size of all preceding files) specified as an argument to the build tool so the song SD pointers are accurate. SFX pointers don't need this since it's implied SFX are always the first 64K of SPI RAM. The effect of this is that the demo can switch between different game sound tracks/SFX, without cluttering the card.

The "user database file" is similar to _HISCORE.DAT as an optional idea. Basically it's a single file where a single author puts all data for all their games. IMO if you are going to make lots of SD games that you source control, you might want to use a single file with known offsets for each. There would be a signature representing a version number so games can specify a minimum version(future versions implied as backwards compatible). Then as you make new games, the new version can overwrite the old and everything works. This might be a pain in the ass, but I would like to retroactively do Alter Ego and Toorums Quest with this philosophy.

Still lots to do. Basically the current design eats the enormous cost of 524 bytes for the HSYNC sound buffer, plus 512 bytes for an SD buffer :shock: :cry: Jubatian's idea was to make a custom mixer which only uses half the HSYNC buffer; I will check it out. It really couldn't be lower than a 262 byte cost, likely higher. Then the game will need to get crafty to attack/regain the SD buffer loss. Basically put game variables in SPI RAM wherever possible. It might be possible to do partial sector reads and reduce this SD buffer requirement. I haven't tested it, but it sounds very slow and extra complicated. Things are already slow and complex enough :lol:

So all this has the implications(if it even works in real life games) of extreme cycle and RAM cost. For Mode 3, I would say games using it will be characterized by 30Hz gameplay, and lower RAM tiles. Also some cards are going to be too slow I'd guess. I'm aiming for PCMMusicDemo to be a test ground for all this. It might arguably be easier to use than Streaming Music. BTW I will say by the time you get waves chopped and arranged right, the files organized and defined...PCM is really not less work than MIDI :roll: Also, in some ways, it might have a couple higher elements of skill/understanding than MIDI development. I'm starting to consider all this PCM stuff "not impure".

TLDR
work has been done on a demo implementation for "Streaming PCM" sound engine. DA once again externalizes the thought process as a rant/thought experiement to re-refine the current state.
User avatar
danboid
Posts: 1932
Joined: Sun Jun 14, 2020 12:14 am

Re: MegaBomber

Post by danboid »

Sounds great DA but definitely sounds more involved than MIDI, as you say. That's only to be expected.

Is there no hope of an xm -> UB PCM track converter or something to ease the writing process? You don't seem to hint at any kind of non coder, musician friendly composition workflow in your last post, not that I could discern at least.

Maybe some kind of custom GUI (for desktop machines) would be able to be written to simplify the process of putting a PCM track together or do you not think a GUI would help much?
Last edited by danboid on Sat Mar 04, 2023 8:17 pm, edited 1 time in total.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: MegaBomber

Post by Artcfox »

Wow, so if I understand correctly, you are essentially using the SPI RAM as a swap space for actual RAM, paging in chunks as you need them, and the SD card will feed the SPI RAM with even more pages that can be swapped into actual RAM, allow you to achieve multiple PCM sound effects? That sounds pretty wild!

I like the stream of consciousness idea dump/rant style. I wonder if you could use the RAM tiles space as a temporary intermediate buffer for going from SD card to SPI RAM, as long as you do it before blitting happens, and can finish before blitting starts, you should be able to reuse that RAM for free essentially I think.
Post Reply