LoginLogin
Might make SBS readonly: thread

SMILE Tool generated SPDEF file format

Root / FAQs / [.]

mystman12Created:
mystman12#1
I'm trying to figure out how to load the custom SPDEF DAT files you can save through the animation SMILE tool, but I can't seem to get it to work. I'm trying this: 
DIM CCDEF[0]
LOAD"DAT:DEF_CC_DEF",CCDEF,0
SPDEF CCDEF
All I get is an out of range error though. I've been having a hard time loading *any* type of data files, in fact, so I'd like to know how those work in general!
Mariominer#2
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.
mystman12#3
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.
pirate#4
Uh... have you checked what's in the array after you load it? It has 40964 elements...
mystman12#5
Okay, I checked, it contains data and has 40964 elements (0-40963), so I know it's at least loading properly. The example in the references for SPDEF basically just shows this: 
SPDEF SRCDATA
It says a numerical value array should go after SPDEF. Sadly I can't find any examples of this working in any programs.
calc84maniac#6
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.
pirate#7
Yeah it's probably an error in that tool.
Yolkai#8
Mmm what's the problem, exactly? It's possible the Japanese have solved it.
pirate#9
Mmm what's the problem, exactly? It's possible the Japanese have solved it.
Just save a DEF template using the SBANM tool. Load it and you'll see it's not valid.
Yolkai#10
Just save a DEF template using the SBANM tool. Load it and you'll see it's not valid.
Oh, sorry, I keep forgetting. I don't actually have Smilebasic, sorry, that's why I need it explained.
pirate#11
Just save a DEF template using the SBANM tool. Load it and you'll see it's not valid.
Oh, sorry, I keep forgetting. I don't actually have Smilebasic, sorry, that's why I need it explained.
u wot m8. By the way I just tried this older version and I still get the 40964 elements array. So maybe it isn't an error and the sprite template files aren't supposed to loaded like that?
snail_#12
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.
pirate#13
yeah, that def file is probably only meant to be used by SBANM.
Techokami#14
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???
NeatNit#15
Can't you read the source code of the SMILE tool and see exactly what it saves and how it saves it?
snail_#16
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
kldck_hul#17
I've bumped into this problem and didn't quite catch what slackerSnail meant the first time. SPANM stores 3 extra bytes at the end. PRV = 7 - Vertical Inversion PRH = 6 - Horizontal Inversion PRO = 8 - Rotation When SPANMN loads these it does: 
A = 1
A = A OR (DATA[N,PRV]<<4)
A = A OR (DATA[N,PRH]<<3)
A = A OR (DATA[N,PRO]<<1)
and gets the attribute value for SPDEF I wrote this into my game library along with BG loading and other things; I'll be posting that resource in the next week.
mystman12#18
Oh cool. So basically, you've found a way to load them?
kldck_hul#19
Yep. Its pretty straightforward.
Micalobia#20
COMMON DEF LOADDEF G%[],J
 DIM V%[4096,10]
 IF J THEN
  FOR I=0 TO 3
    T%=SHIFT(G%)
  NEXT
  COPY V%,G%
  FOR N=0 TO 4095
   U=V%[N,0]:V=V%[N,1]
   W=V%[N,2]:H=V%[N,3]
   X=V%[N,4]:Y=V%[N,5]
   A=1
   A=A OR (V%[N,7]<<4)
   A=A OR (V%[N,6]<<3)
   A=A OR (V%[N,8]<<1)
   SPDEF N,U,V,W,H,X,Y,A
  NEXT
 ELSE
  SPDEF G%
 ENDIF
END
This will act like SPDEF, but has a flag for if your using an array created by SBANM