kungfufurby / snessounddriverdocviewer Goto Github PK

There are sound drivers out there that will require the SNES side to process the music data.

• ARAM maps only cover the SPC side, not the SNES side. The SNES side is not guaranteed to be as consistent as the SPC side on WRAM allocation since it is shared with the rest of the game. If I do create a WRAM memory map for the SNES side for these special cases, it must only involve the sound-related components, which isn't always easy to do.
• The music format (which is the main reason why this case would come up: in all other cases, I do not feel like I should be doing this, as they can get incredibly game-specific quite fast) may be wildly different, or it may be pretty much the same.
  • An example where there is relatively little translation required is Eastridge Technology. The internal music format is headerless, and almost all of its command IDs match the equivalent command ID that is sent to the SPC700. There are two exceptions, that being the delay (handled on the SNES side in NTSC/PAL frames, though theoretically it can also be as often as the music processing routine is called) and the end of song marker.
  • An example where a lot of translation is required is Distinctive Software/Electronic Arts. The internal SPC700 commands are quite low level (basically corresponding directly to raw DSP values, particularly on the pitch), leaving a lot of work, including setting up the pitch, to the SNES side.

Currently I have handled three sound drivers and have actually adapted them for use in the SPC file format, all of them falling under the case where relatively little translation is required:

• Compedia (used only in Mr. Bloopy Saves the World)
• Eastridge Technology (the most common sound driver I know of that normally requires the SNES side for music processing)
• Mindscape (used only in the Mario's Early Years series)

I will have the website work in two ways: with Javascript and without Javascript. Without Javascript will likely go first.

With Javascript, the user can select a sound driver, then the page itself can dynamically change with the build selected on top.

Without Javascript, the user can instead go into a page for an individual build, where the documentation will be generated right then and there. Depending on the sound driver selected and depending on how drastic the differences are, I can also create a page that contains everything in one go, which I've already done for a few sound drivers on SNESLab. I may also need to split them up into multiple pages if there's too much to look up in one go.

Requires #1 to be complete first. Otherwise this component cannot dynamically generate ARAM maps on the fly based off of the user's selection of a sound driver build.

I am splitting my design into a few different components. The very first one I want to tackle is the ARAM Map Viewer, because it has the most consistent core component, that being the raw memory location.

The ARAM Map Viewer will consist of the following:

• Sound Driver Build Selection

Currently I don't have Jekyll installed simply because I don't want to bring it out while the generators are not yet working, even though my content is theoretically ready to go. I will bring out Jekyll once I've got at least somewhat of a working example, as I'm working on it locally for now.

This is the very core of the SNES Sound Driver Documentation viewer: all of the sound drivers and all of the builds contained within must be user-selectable.

The user has two options...

• They can select a game as well as the region (the latter is optional) and/or revision (this case is rarer). Critically, I should be linking game names where the region is different across regions, but they refer to the same game.
  • If there is only one sound driver build present in the game selected, then the sound driver build is automatically selected, otherwise it will show the builds present. Note that I am aware of cases where there is more than one sound driver used (and not just build variants).
    • In cases where there are pointer differences in the code but doesn't yield an actual code difference, the build is instantly selected, but all of the pointer difference cases are shown.
  • If a region/revision is not defined, then all builds across all regions the game uses will be shown if there is more than one regional or revisional build.
• They can directly select a sound driver build. I need to sort these by a sound driver identifier, and possibly by branch, too (don't overdo it, though). This overwrites selecting by game.

Now I won't bring them all in at once due to a search function being required down the road (this is because there are at least, by my own estimate, a thousand of them), but at the absolute least there should be a drop-down menu to select the ones that are present.