awuwunya / amps Goto Github PK

So I wanted to enter the project's official Discord to try and get some help with bringing AMPS into my Project Sonic 1: Two Eight Git disassembly project, but the provided invite link in the documentation is expired. Can this be updated so I can properly get some much needed tech support for my project?

EDIT: Well, I found the updated invite link in the Sonic Retro thread, but it should still be updated in the docs :P

As far as I'm aware, the only method which exists for converting SMPS binaries to AMPS format seems to be using SMPS2ASM (as described in the docs). By default, the output isn't compatible with AMPS. The documentation describes a general idea of how to adjust tracks, but a more direct conversion process would be ideal.

This is a feature in SMPS and may be used by songs that are to be ported from SMPS games. This would provide additional control over the tracker at the cost of using more space. The details will have to be thought out since DAC frequency can be negative as well...

ADSR (Attack, Decay, Sustain, Release) is simplified form of how FM voices operate regarding volume. This allows for more control over how the notes sound, and indeed would help PSG sound a little more natural while also allowing Volume Envelopes be used for more complex effects on top of that. This feature would make it possible to also have PSG do a more natural fade-out after a note is released.

This would be a FM-only feature, that would allow for more complex sounding instruments without having to worry about modify the TL values by hand each frame. However, it would probably take a lot of CPU time and would be difficult to get right. A lot of thought should be put into this to make sure its useful and wouldn't waste time and space.

This is one of these "nice to have" things. It would make dealing with PSG volume much easier, at the cost of extra CPU time and more difficulty porting music over. However, it would bring PSG in line with FM and DAC which have volume range of 00 to 7F. This would make volume envelopes cross-compatable as well, which will be good if FM & DAC volume envelopes are implemented.

Lets be honest, it looks like shit, and is not at all user-friendly. It should have an UI that is easy to look at, but provides all the necessary information. Additional code could be added to the sound driver to make display more accurate as well (specifically relating to the envelopes)

This feature would make all frequency work as note.fraction as opposed to frequency. Lets say you want to modulate: Instead of adding x to the note frequency, you add x to the note.fraction value. This will later be converted into a frequency, where note is just the note to use, and fraction represents a fraction of the difference between the next note - current note difference in frequency. For example, fraction of $40 may mean current note + ((next note - current note) / $100 * $40). This would make modulation, portamento and other effects be effectively exponential as opposed to linear, and make them sound more "realistic". It would make the driver more accurate in production of notes at the cost of extra CPU time and more work to port songs correctly. It would also make code more complex (especially when dealing with how FM splits its octaves; dome frequency values actually overlap between octaves), but it would also bring many advantages and make it easier to create interesting effects in music.

Extend support for using VolEnv's for FM and DAC through a switch. Currently hardcoded to only support PSG, make the ability to support FM and DAC as well at the cost of 2 bytes of RAM and an extra tracker command.

There needs to be more thought put into error detection in safe mode. Although many common cases are already detected, more uncommon mistakes may not be covered. To work effectively, all errors should be detected

FM3 special mode is a very useful technique for making more interesting sounding instruments or simulating up to 4 channels at the same time. However, it will also be more difficult to program this effectively, as to take full advantage of the features you essentially need 4 trackers with control over TL and frequency of each operator. Also, there will be some issues to be considered with SFX, like should 1 SFX channel override effectively 4 channels? Should SFX be able to use FM3 special mode?

I've gone over here why 'Sound-Source' likely isn't SMPS's name - rather, it appears to merely be a placeholder string for the name of the game that the driver is inserted in. Specifically 'Source' appears to be a corruption of 'Sorce', which is possibly short for 'Sorcerian', a game which uses SMPS Z80 and was released around the time the leaked source code is dated.

Retroactively 'correcting' SMPS to Sound-Source like this is not only potentially factually-incorrect, but also extremely confusing to anyone who only knows SMPS by its unofficial name.

Having PSG4 be able to work as an independent channel would make it possible to have greater control over the PSG chip and make use of 4 PSG channels at once (even with PSG3 playing a note and PSG4 playing noise using PSG3's frequency), but also complicate a lot of tracker and driver related things. It may not be worth implementing.