Post
by KungFuFurby » Thu Jan 30, 2014 9:00 am
Interestingly, I usually consume a good chunk of memory with music and SFX alone.
- Uwol: Quest for Money (the SNES port) is 2 Mbits, and almost a third of that is the music and SFX.
- MazezaM Challenge is 4 Mbits. Two fifths of that memory is used by the music and SFX. Interestingly, the game is more like a 3 Mbit game, as the last megabit is left unused.
- Tchou, for some odd reason, is a 7 Mbit game, although there is at least one megabit that can be shaved off since it's unused (and if the conditions are right, more than a megabit with some pointer shuffling). My music takes up one and three quarters of a megabit (or almost two megabits)... and a bunch of the music actually ends up unused!
I have a couple of game ideas myself, and I am already developing the soundtrack for both of them (one of them is so large, even larger than Earthbound's soundtrack, that the music alone is already 8 megabits! And the game I have in mind isn't even an RPG!). I've made a couple of test programs (including a graphic test), and I compile on the Mac with WLA DX (compiled using the shell script provided), and test them with SNES9X 1.53. I transfer the data over to another computer to debug if I absolutely have to, because there is no debugger on my end.
I do have a graphic converter that was produced by alekmaul (which I compiled with XCode and then, if I recall correctly, I adjusted the program for endianness issues), and SNESMod by mukunda for the music and SFX (also compiled through XCode).
I've also learned how the music can be banked over time thanks to inventing all sorts of music modifiers over the years, and I'm taking that method for some of these games. The in-game music in Uwol is all in SPC700 RAM at once (exceptions are the Title Screen, Ending and Game Over themes).
For a., I know both SPC700 assembly and 65C816 assembly, although I use 65C816 assembly much more often (I usually don't look up SPC700 opcodes, although I have looked up raw data inside SPC700 files before, especially these days when I do track counts when checking the ranges for the music modifier I produced).
For b, heh... this is where Schism Tracker comes into play, especially given the sound driver I use. I let SNESMod do the conversion, and I simply edit the samples, including loop points, with the tracker. It's basically dynamically changing the size of the sample in the process.
On a related note, I actually have endianness issues with the newest version of BRRTools, while I did not suffer from this problem with the Java version (I don't have the latest Java version..).
For c., I actually have an idea in one of my games to let the main sprites take up four or five colors, with one of those colors being different, and spread them out over the eight patlettes. The best use for this is so that I don't have to make duplicate versions each time. Then the other ten colors for each sprite patlette can be used for other objects. (or, if the right patlette is used, I can recycle some of the colors in one patlette).
For d... I think I have at least one idea that might use 3 layers. However, it might not always apply.
For e... I'm not sure about the graphics, but usually the music I make takes up a good deal of memory.
f. is a major reason why I have multiple debuggers... I have laevatinn (until there's another debugger) just in case I need to really examine what went wrong if the debugger I use, nosns, can't quite pick out the problem due to differences in emulators (I had this problem at least once).
For g... heh, I see what you mean. Especially with custom music. Plus, I think of mid-scanline effects, which I'm tempted to experiment with.
For h... oh yeah, tough call there... I actually can't even think of one that would work on a PowerPC Mac (I'm running an iMac G5 on Mac OS X 10.4.11). Even if I had the source, I'd have to check it and account for endianness issues if they pop up, and that's if the programming language (C or C++ is best for me) and libraries are compatible.