unnamed-snes-game

[KungFuFurby]

Yes... I had actually opened the first pull request for my music contributions on March 18th (so I had already jumped the gun on that one). The soundtrack itself evolved over time as the sound driver went from six channels to eight channels, in addition to feedback-related adjustments regarding volume balancing between music and SFX, so I've been keeping the soundtrack up to date as the sound driver evolves.

[SNES AYE]

Hey, UnDisbeliever, I'm not quite sure I understand what a sound driver is here. So, can I just ask, does this mean you've developed a tool that other people can use to create music for SNES? And if so, is this something new that allows them to do things with the SNES audio that they couldn't with other tools or maybe just get a better sound quality than other older tools, or is it simply an alternative option they can use if maybe there's something they prefer about the way you've designed this particular tool or something like that?

[UnDisbeliever]

Hey, UnDisbeliever, I'm not quite sure I understand what a sound driver is here. So, can I just ask, does this mean you've developed a tool that other people can use to create music for SNES? And if so, is this something new that allows them to do things with the SNES audio that they couldn't with other tools or maybe just get a better sound quality than other older tools, or is it simply an alternative option they can use if maybe there's something they prefer about the way you've designed this particular tool or something like that?

An audio-driver (also known as an audio-engine) is the code that runs on the spc700 processor. It is responsible for setting the S-DSP registers and communicating with the 65816 CPU to play music and sound effects.

I wrote the Terrific Audio Driver because I was dissatisfied with how the other open-source game-ready audio-drivers (snesmod, snesgss and qspc) handled sound effects. I wanted an audio driver that could hold ~100 sequenced sound effects. TAD was written to be sound-effect first, to the point where I implemented sound effects before my audio-driver could play music and before the the audio-compiler could parse MML (the music format I chose).

After about 6 months, I was happy with my audio-driver. It did everything I wanted and was at a point where I could make music and sound effects with. But I'm horrible at making music. So I made the decision to port the tooling to rust, build a GUI and make the driver easier for other people to use. This includes the decision to maintain the project and add requested features to the driver/GUI (provided they are not too outrageous).

The Terrific Audio Driver is an alternative option snesdevers can use in their games with the following features:

• Actively developed.
• The spc700 code is zlib licensed.
• Channel ducking. 8 Music channels and 2 sound effect channels.
• Songs written in a pmdmml inspired MML format.
• Sequenced sound effects, written in either bytecode assembly or MML.
• Configurable sound effect dropout behaviour:
  • High-priority sfx that will override the currently playing sfx. Intended for important sfx like player-hurt-low-health.
  • Interruptible sfx.
  • Uninterruptible sfx. Useful for vocal samples or item collected ditties.
  • One channel sfx that will play on a maximum 1 SFX channel. Intended for rapidly played sfx (ie, collect-coin) to prevent it from occupying both sfx channels.
  • Low-priority sfx that will not play if both sfx channels are occupied. Intended for background sfx like water droplets.
  See the sound-effect documentation for more details.
• Echo, portamento and vibrato support.
• An asynchronous API for ca65 and PvSnesLib that supports loading audio data over multiple frames. Useful for loading audio data in the middle of a level transition or fade-in.
• A GUI that:
  • Runs on Windows, MacOS and Linux
  • Plays MML songs at the cursor position or line start
  • Plays songs and sound effects at the same time (to assist in volume balancing sound effects and music)

[SNES AYE]

OK. Thank you for all the information there. That helps clarify a lot of things. Thanks again.

[UnDisbeliever]

I've finished the critical engine features I need for the next demo. There's still more features I want to to engine, mainly improving movement and collisions, but I'll do them later. I want to avoid falling into a rabbit-hole of endless engine changes for the sake of change.

I've improved MetaSprite palettes:

• Added palette swapped MetaSprite framesets
• The two bomb entities, player and boss, now have different colours.
• Added palette cycling using callbacks.
• Up to 3 MetaSprite palettes can be loaded at once.
• MetaSprite palettes can load child palettes, simplifying palette reuse.

I've rewritten the gamestate subsystem:

• u8 and u16 gamestate variables are now defined in a json file, so they can be referenced by the python and the 65816 wiz code.
• Split gamestate flags into global-flags and dungeon-flags. When I run out of dungeon-flags, I'll implement a dungeon banking system that switches the dungeon-flag bank when a dungeon is loaded.
• Added saving and loading gamestate from battery backed cartridge RAM.
  I'm saving multiple copies of each save slot to Cart-RAM. If one of the copies is corrupt, the save can hopefully be restored from remaining copies. I've got a ton of free cart-RAM space, there's currently four copies of each save slot (on a 4KiB save RAM).
• Added version and data size fields to gamestate. To prevent glitches, a save will only be loadable if the header (identifier, version, data-size) and checksums match.
• I've added a gamestate viewer/editor tab to my resources-over-usb2snes GUI. Allowing me to live-edit the gamestate flags while I develop and test the game. (Not critical, but it will make testing a lot easier and it can be used to warp the player to a specific room.)

File select screen (1chip Super Famicom screen capture)

Resources over usb2snes GUI screenshot

Finally, I've rearchitectured how the entity process/drawing functions are called to move the code to bank 0xc0 and increase the amount of free code space by 24KiB (4KiB of bank $c0 is used for the rodata segment).

Previously the process and drawing functions were stored as function tables in RAM and called with the JSR (addr,x) instruction (X = entity index), but required the code to be stored in bank $80 (so the Program Bank can access lowram).

Now the process and drawing functions are managed as byte-indexes to a function table. This is slightly slower but allowed me to move the Program Bank to a 64KiB ROM bank.


---


I'm going to wipe the old dungeon, start afresh and build a horizontal slice.

Instead on focusing on building a production-ready single dungeon slice of the game, I'm going to focus on a prototype slice of whole game. With bare bones tilesets, placeholders for enemies, NPCs, treasures, dungeons, etc. The goal is to map out the game's main path to get a feel of the demo's scope. This should (finger's crossed) give me a better understanding on the finished game and provide motivation to focus on the game over engine features.

Then, over the rest of the year, I will slowly develop and enhance the prototype placeholders and graphics until the game-demo feels complete.

Here's an 11 minute Youtube video by Timothy Cain explaining the concept better then I can.

[Kannagi]

It's interesting to see the solutions and difficulty for the engine and the game.
But I know what you write well, since I often tried to reconcile several things (engine, gameplay) etc., and that all this is not too long to do, otherwise we never finish!

Good luck "redoing" the level, I hope it will result in a more modular and easy code so that you can then continue to make an entire game