You are not logged in.
Pages: 1
This appears to be present in at least GM7 and GM8, though most likely earlier.
Unexpectedly, image_index is a floating-point decimal. This can make debugging a nightmare, as I found out. You cannot directly test image_index == value; instead you must use floor(image_index) == value. The help file states that it can have a fractional part, but it fails to mention that unless image_speed also does not have a fractional part, image_index will be expressed as a floating-point decimal.
Offline
You cannot directly test image_index == value; instead you must use floor(image_index) == value.
Yes, this is pretty common problem I've seen come up at the GMC. I always assume image_index is a float, never really considered the "wholeness" of image_speed having an effect. Clarification is always good.
Now that the final version of GM8 is out, I'm going start converting the help file and adding the annotations like I've always wanted.
Abusing forum power since 1986.
Offline
It is undertandable that image index would be a float. same as x, when you would change the position by .1 for example, it is right to assume you would want to do the same with image index
However, it would be good to know if what is displayed is floor(), or round() or ceil() of the value contained therein.
Offline
Yes, but many newer users get confused if trying to cut an animation short with "if(image_index == whatever)".
Testing for image_index == 3 fails. floor(image_index) == 3 works fine.
EDIT: This is related to the confusing fact that score is a signed integer.
Last edited by PlasticineGuy (2010-01-06 09:26:35)
Offline
Think about this
x+=.123
if(x == 2) //fail
and this
image_index +=.123
if(image_index == 2) //fail
in order to control the speed of the animation, it needs to be a float... because if is was a forced integer
image_index = 0;
step
image_index +=.123
if(image_index == 2)// fail
Why?
Because
0 + .123 = 0 if you force it to be an integer. it would never increase and be stuck on 0
Just like adding .1 100 times to score, the score remain 0;
Score is wrong IMO, it too should be a float.
If image_index was an interger, you would have a lot more trouble controling the speed of the animation than calling floor() to check where the animation frame is... And I verified; floor is the proper function.
Offline
Makes to think about it: wouldn't it be better if image indices work like paths? - so the "end/post last image" is image_index "1"? Makes it easy to see images as "generic" images, and allows you to easier build the graphics in a later stadium.
ie: "halfway the animation" would become: image_index = 0.5; instead of "image_index = image_number/2;".
Offline
that would make other things difficult too...
image_index = image_index mod (animend-animstart) + animstart
for having multiple animations in the same strip...
however, it would be nice to have this... Maybe via a series of gm variables that update themselves
image_index : same
image_frame : (int) image_index
image_pos : image_index/image_number
where you can update any of these... and the other 2 are updtated. sort of like the (v/h)speed/direction variables
Last edited by icuurd12b42 (2010-01-13 16:19:13)
Offline
Pages: 1