I’ve had a project going I’ve been calling "Daiyousei", which I started for my own hack which, for various reasons, has a need for this kind of thing. Here’s everything interesting I’ve got so far:
https://dl.dropboxusercontent.com/u/12961639/smwc/dys-2015-12-11.zip
If it’s decided Daiyousei is worthwhile, I have a github thanks to my university, so I could set up a proper repo instead of sharing .zip’s or whatever. I haven’t been able to test it on Linux yet because I murdered my Arch install a while ago, but as far as I know as long as you can get Asar to link it doesn’t do any weird platform-specific things that would break it.
Currently:
- The tool can only insert standard sprites, and the ASM only deals with standard sprites. Shooters and generators should not be hard to add but I want to get the standard sprites up to par first. The load routine doesn’t deal with the koopa shells, etc, so those crash.
- The tool has absolutely no compatibility with TRASM sprites. It may have incompatibility with a few sprites using weird xkas edge cases. I am not sure how many TRASM sprites there are, so I’m not sure how important that is.
- A bunch of the original game sprites crash because I haven’t made them rtl yet.
- It reads the same cfg and sprite list formats as the original sprite tool.
- It should work with headerless roms. Haven’t tried.
- It should work with typical Romi’s spritetool sprites. Haven’t tried.
- The ASM is there to load extra bytes, but there isn’t any way to actually mark sprites as using extra bytes. We’ll need a new cfg or sprite list format for that.
- Sprites are enumerated 000-1ff, using the extra bit used to mark sprites as custom by sprite tool.
- A bunch of RAM addresses and a few constants are declared in memory.asm.
- Everything is really poorly tested.
A bunch of things in the code are meant to make room for things I haven’t written the code for yet. In particular, tables are defined for extra options, which would allow the tool to have a few extra sprite settings (like extra custom states, clipping options, etc.), and clipping tables, although I have not yet written a custom-clipping collision routine.
A lot of things warranting explanation in a readme are currently unexplained, but I am willing to answer questions for now.
A lot of code is kind of weird and I want to fix it. I wasn’t really planning on sharing any of this until I at least had standard sprites working all the way but now this forum has shown up, so here we are.
Also, this isn’t like super important, but I’m gonna be honest: using raw hexadecimal addresses for all the sprite tables, aside from making everything a nuisance to port to the SA-1, is barbaric as a coding standard. Even mikeyk’s sprites were polite enough to write out a couple defines here and there. I still just have to leave the RAM map open in another window when I’m dealing with anybody else’s sprite code, because I honestly just do not care to memorize the fifty-or-so tables by address. And if I find anybody using a new-to-Daiyousei table by its hex address instead of its defined name, I swear to God I will move it simply to break your sprite.
Plans I have for the future:
- The tool should detect if the original sprite tool has been used, and if so, clear out its patches. This shouldn’t be hard, but it’s enough of a bother that I haven’t done it yet.
- Disassembling the original game sprites and allowing users to use the disassemblies instead using !opt_reinsertOriginals. Given how many sprites have yet to be disassembled I am unsure how feasible this is.
- Having the tool actually parse options.asm so that options like !opt_reinsertOriginals will actually bear any meaning.
- A new cfg format, including things like the new Daiyousei options, and maybe a new sprite list format.
- I’m doing something wrong when I print out Asar’s errors. I should replace this with something correct.
In particular, for the new cfg format, I was thinking something like:
Code
DYS 1 type: standard props: aa bb cc dd ee ff xopts: 00 11 clipping: 08 08 10 10 xbytes: 2 source: myfile.asm
This format would be fairly easy to detect (is the first word "DYS"?), and allows for the addition of new fields without just counting how many bytes are in the file. Given the amount of defines and such Daiyousei generates a version number could help detect a sprite that would cause errors without just launching a wall of Asar errors onto the user.
I have a lot more weird plans and thoughts, but they’re far enough away that any extra promises would probably be vaporware. I feel a little silly leaving this honestly pretty messy stuff here, but it’s what I’ve got.