Well, with the first version accepted, I guess it's time to think about what else I'd want for this tool to be capable of doing. I actually have 3 main targets for now: Extended and Cluster Sprites, extra byte usage and more CFG information.
Extended and Cluster should be simple enough to understand what I mean with, right?
As for how they'll be implemented, I thought maybe have the list file be able to switch between modes with lines like:
CodeSPRITES: ;list file now in sprite mode (default)
00 Hammerbro.cfg
...
EXTENDED: ;list file now in extended sprite mode
00 somefile.asm
...
CLUSTER: ;you get the point
00
Cluster and Extended are simple enough but maybe I could also add ow sprites if I can get to it.
Extra byte usage is something that imamelia originally did with tesserar and was then added to Lunar Magic too (or maybe it was vica versa, not sure honestly). In any case, it is Lunar Magic's ability to insert sprites with more than the default 3 bytes into a level. Just like the extra bit we know and live, which means you can have different behavior for each individual sprite based on these extra bytes. The number of extra bytes can be anything per sprite number but I was thinking about just constantly setting it to 3 or 2 for all sprites (because honestly, what kind of sprite needs more than 24 bits of custom information for each individual sprite?).
I could also add it to the cfg file but I wonder if just setting it constant is not the less bothersome way to go.
Now for what is actually my main goal for now, more CFG information, namely, information to generate ssc, s16, mwt and mw2 files for Lunar Magic's custom display function (to have sprites not just as red Xs)
I was thinking something like this for cfg files after the usual stuff:
CodeNUMNAME NUMMAP16 NUMSSC (line 7 of cfg file)
NUMNAME is the number of lines following this that hold the sprites name to be put in Lunar Magics list. The number can be in between 0-2. 0 just means there is no name (will use cfg filename by default), 1 means just the sprite name and 2 means the first line is the sprite name and the second is the name for the sprite with extra bit set. Example:
Code2 0 0
Ball 'n Chain clockwise
Ball 'n Chain counter clockwise
NUMMAP16 would be the number of custom map16 tiles that will be needed to display the sprite, each tile taking one line. The line would have to be the raw data map16 data, can't think of any way to make this "pretty". The line holds 8 bytes, character and yxpccctt data for the 8x8 tiles. But honestly, when generating this, you can just open your own s16 file in a hex editor and copy the stuff over. Example:
Code1 2 0
Hammer Bro ;name
48 09 58 09 49 09 59 09 ;top tile
58 09 4A 09 59 09 7F 09 ;bottom tile
Lastly, NUMSSC is the number of lines used for the ssc file. Honestly, I can't think of a way to make this "prettier" either, so I guess it will just be 1:1 the same as a normal ssc file lines minus the sprite number. For custom display map16 data, you can assume the previously inserted map16 tiles to start at 0x400 (tool will add proper offset). Example:
Code1 2 2
Hammer Bro ;name
48 09 58 09 49 09 59 09 ;top tile
58 09 4A 09 59 09 7F 09 ;bottom tile
0020 A classic hammer bro. Throws hammers and jumps.
0022 10,-14,1DB 0,0,401 0,-8,400
For anybody unfamiliar with the ssc file format, the 4 leading hex digits indicate whether the line is a description text or the display information, as well as "what" the information is targeted at (sprite, sprite with extra bit set, sprite at position x&1, sprite at y&1 etc...)
Note that line 7 itself won't be mandatory. If the cfg file ends before there, that's that.
I also might just make it replace line 6 (assembler in sprite_tool) and have the tool recognize if the line only holds one number (= old cfg file for sprite tool).
Any thoughts on the matter?
Anime statistic on
MyAnimeList:
400 animes completed ✓
6000 episodes completed ✓
100 Days completed ✓
... what even am I doing with my life?