What would you do?

[justin3009]

This is for the X3 project once more as I have been going through a full blown rewrite of all my code and many other things with the Zero Project.  It's overall so much better, less bugs, easier modification and is just not a nightmare anymore to work with.  But now an interesting issue has come up.

Animation Data and Sprite Assembly are my concerns.

Animation Data is pretty self explanatory.  It loads how many frames are in an animation, the wait time and what other special variable to use.
Sprite Assembly is the same way.  It loads which piece of graphics to use, what's the X/Y coordinates and which direction to put it.

Now this game uses a cheap method that essentially works but is a space killer.  What it does is that it uses the SAME byte for Sprite Assembly and Animation Data.




For example:

Zero's 1-byte data would be: 4A.  The base table for Animation Data is 3F8000.  To calculate, the game does 4A * 2 + 4A to load 3F80DE.
Essentially, the game does the exact same thing for Sprite Assembly as well.      So instead of 3F80DE though, it'd be 0D80DE.

Going through the Animation Data table though, there's A LOT of repeated bytes that load the exact same thing.  Dear god, especially for one thing.  I'm not sure what all goes to it, but it repeats itself at least 15 times because every single one uses the same Animation Data, but different Sprite Assembly.

Now, here's the ideas I essentially have and I'm not sure what else to do, and what problems are occurring for each.  No matter what I do, I essentially will have to bump the original tables to new space to make room for anything new.  Simply, there just isn't enough room to do squat.  I just want to make it easier to customize and insert extra data:


1. Do a Chrono Trigger method.  Split both tables up completely and add a new byte to dictate which Sprite Assembly to use.  This would be the essential one.  It would allow table expansion WELL beyond normal range (I'm hoping to see if I can actually make the game us two bytes instead of one byte for data.  Though, I'd still have to alter every single piece of data in the game to load two bytes for the enemies data..) and be a hell of a lot more flexible.  This would easily free up all those damn repeated bytes in the first table and clear up whatever mischief is in the 2nd one as well.  Now, this one is even worse than the first method for work.  Why?  I'd have go through the ENTIRE game and bump data from every single enemy, PC, weapon, explosion, ride armor, ride armor chips, etc.. and dictate which byte to use for their data.  That is A LOT of frikin data to move around.  It's not essentially bad and it's the best route to go that I know of, but that's days and days of tedious work and many issues could easily be missed.  But overall, this would allow a much easier method to shuffle things around.

2. Maybe see if there's a universal area that they all use and see if a custom table can be inserted to load two bytes.  One dictated for Sprite Assembly and one for Animation Data.  This would combine the table moving and do a partial of #2.  I'm not sure how viable a 2-byte option would be as that'd just be even more extra work but it'd probably be the greatest method.  That'd leave so much room for ANYONE to add anything they want.


I'm not sure if there's any other method anyone would use, but these are what I've come up with.

[henke37]

Is there a one way correspondence in that each animation data only uses one sprite assemply data? If so you could add data to the entries in the animation data table for which sprite assembly data table index to use.

[justin3009]

I just realized something much easier and works in theory.  I'll test it later on.

I'll break both routines apart right before it hits an 29 FF 00 command so it knows exactly what data is being loaded.  I'll then have it check if the value is > FF.  If so, it'll break the routine apart and load the animation data/sprite assembly from a DIFFERENT location.  It's the same methods as above, less work, less re-arranging, more room, quicker and it SHOULD work!  The 2-byte option table as well to split SA and AD works perfectly as well with the idea!