On yet another note,
it would appear that the "play sprite"
does cache the delay... using the following
snippet I would expect the animations to
change frame rates.
do
` Variable: f is the max number of frames in the sprite
` Note: there are 16 sprites loaded and pasted to the screen
randomize timer()
for i = 1 to 16
play sprite i,1,f,rnd(1000)+50
``````````play sprite i,f,1,50````Cannot play a sprite backwards
next i
sync
loop
but once drawn, the sprite's delay is a constant...
altering it with subsequent calls, has no affect...
I suspect that is true of the startframe, and endframe...
Time to go test my suspections...
EDIT :
I haven't tested my theory completely but it is
interesting to note, the following code...
do
randomize timer()
for i = 1 to 16
play sprite i,1,f,rnd(1000)+50
next i
f = f-1
``````````play sprite 1,f,1,50````Cannot play a sprite backwards
sync
loop
Where varF is decreasing brings a runtime error
that the "image number is illegal", so my theory is
definately wrong ( how wrong I am not sure ), changes
to the endframe DO affect the command on subsequent calls,
However please note that the error message is irrelevant
to the problem. It can only be rellevant to something
under the hood. "Play Sprite" might just be creating images
for me...
EDIT :
Ok, so to prove affecting the play sprite parameters
is not the problem directly above I did this...
once = 1
do
randomize timer()
for i = 1 to 16
play sprite i,1,f,rnd(1000)+50
next i
if once then f = f-1 : once = 0
``````````play sprite 1,f,1,50````Cannot play a sprite backwards
sync
loop
Where varF is only reduced ONCE, everything on screen
appears fine... Everything runs normally, no errors...
So now lets reduce F to 2...
do
randomize timer()
for i = 1 to 16
play sprite i,1,f,rnd(1000)+50
next i
if f > 2 then f = f-1
``````````play sprite 1,f,1,50````Cannot play a sprite backwards
sync
loop
Now that F is reduced to 2 the animation is indeed
now only playing frame 1 and frame 2.. So my theory is shot...
Subsequent calls to "play sprite" can affect the endframe...
They cannot affect the delay, but endframe can be manipulated.
Just to be thorough tho, I'll test the startframe
parameter by increaseing it...
s=1
do
` Variable: s is the start frame for the requested animation
randomize timer()
for i = 1 to 16
play sprite i,s,f,rnd(1000)+50
next i
if s < (f-2) then s = s+1
``````````play sprite 1,f,1,50````Cannot play a sprite backwards
sync
loop
Completely destroying my original theory,
( which leaves me utterly perplexed why I cannot affect the delay parameter )
changes to either the startframe or the endframe
are possible. However one strange thing did happen.
If I set the max value of s to f-1 which should allow
for two frames of animation ( f-1 and then f ). The animation
ceases all together, and stays static at the original
last frame ( f )... It should display the second-to-last and the
last frames. Instead it shows the only the last frame, and
becomes static. Setting the max value of varS to f-2 has the
desired affect of f-1... The animation shows two frames,
when logically it should be showing three ( f-2, f-1, f ).
Subsequent changes and experiments with manipulation
of the startframe, appear to always loose the first frame of the
original frame list. The first frame is there as long as you make
no changes to the startframe... once you do however,
the set of frames is decreased by one loosing whatever the
new startframe SHOULD be.
I think my experimentation with play sprite is comming to
a close. I look forward to any technical help, advice, or
insights any one has that might help me better understand
play sprite.
================
-Dejunai
================
