Well, DAT files are basically just saved arrays. So you can save an array and load an array. Not sure how to use it for SPDEFs, but I did write a thing on loading DAT:SC files. If you need that. Haven't tried to learn the DEF ones though.
Yeah, I've loaded map files fine, so I know how to load DAT files into SmileBASIC, I just don't know why some of them just don't seem to work right. I've successfully loaded map, wave, and GRP DAT files into SB, but I haven't figured out animation or, of course, sprite definition DAT files yet.
Btw, forgot to mention that the out of range error comes from the SPDEF command, so the the DIM and LOAD seem to be working fine.
Uh... have you checked what's in the array after you load it?
It has 40964 elements...
Well, that's enough elements for 5852 sprite definitions, which is more than the 4096 slots available. That sounds like it could definitely cause an out-of-range error.
Yeah it's probably an error in that tool.
Mmm what's the problem, exactly? It's possible the Japanese have solved it.
Seriously? Nobody's looked at the save code in SBANM but me? Jeez, for shame.
There's a four-entry header at the beginning of the array. Just SHIFT it off, real easy. Then it should work.
EDIT: This should get the first 4096 entries loaded, but this doesn't cover the spare 1000+ defs. whoops.
yeah, that def file is probably only meant to be used by SBANM.
So the DAT file is 40964 entries long, and the first four entries are header. With 40960 entries that are actually used for sprite definitions, that'd mean 10 entries per definition... but aren't they only 8 values long in SPDEF?
SPDEF Definition number, U, V [,W, H [,Origin X, OriginY]] [,Attribute]
Could it be that SPDEF used to take 10 values, but this was changed during development and SmileBoom forgot to fix it in the tool?
EDIT: Okay, reading some more of SPDEF's documentation, loading from an array actually uses 7 entries per definition. Which means 3 excess values per definition???
Can't you read the source code of the SMILE tool and see exactly what it saves and how it saves it?
Yes, I've already looked. Looking further, the extraneous entries are caused by the way SBANM stores the attributes. The data should be really easy to convert though
Oh cool. So basically, you've found a way to load them?
Yep. Its pretty straightforward.