That is a total time of 60,000 ms over 10 frames. Which is 6,000 ms per frame. Divide that by another 10 to get 1/100th of a second, so you are actually storing 600 in that variable, which is fine for a 16bit variable.
Continuum probably does read it as unsigned, but I can't say for sure.
Samapico - Sat Feb 24, 2007 8:00 am
Post subject:
but the time entered there is 1/100th of seconds, not ms
and its not storing 600 in the variable... when i loaded it it was something like -5536, so it crashed my preview thing, that's why I noticed that.
here's the ini created with debuildlevel when unpacking the lvz
600.000 seconds = 60000 * 1/100th
and the value we enter there is exactly the value stored in the file, there isn't any calculation done there (i.e. all other images time that was loaded is exactly the value entered in that ini, regardless of the number of frames)
Code: Show/Hide [objectimages] IMAGE0=timer.bmp,1,1,100 IMAGE1=0-9.bmp,10,1,60000 ; Total loop time: 600.000 seconds Frame time: 60.000 seconds IMAGE2=0-6.bmp,6,1,6000 ; Total loop time: 60.000 seconds Frame time: 10.000 seconds IMAGE3=0-9.bmp,10,1,1000 ; Total loop time: 10.000 seconds Frame time: 1.000 seconds IMAGE4=0-9.bmp,10,1,100 ; Total loop time: 1.000 seconds Frame time: 0.100 seconds IMAGE5=0-9.bmp,10,1,10 ; Total loop time: 0.100 seconds Frame time: 0.010 seconds IMAGE6=0-5.bmp,2,1,1 ; Total loop time: 0.010 seconds Frame time: 0.005 seconds |
Bak - Sat Feb 24, 2007 10:47 am
Post subject:
it is the whole animation time in centiseconds
Samapico - Sat Feb 24, 2007 4:16 pm
Post subject:
so the wiki is wrong
edited it...
and definitly, it support values up to 65000-something
the lvz ini i posted above is for a chronometer, and the one that is set to 60000 is for a 10 minutes cycle and it indicates the minutes (it has 10 frames) , and it definitly works correctly.
So should the wiki be modified to indicate u16 instead of i16 as well?