FIXED - How can I get the image_speed and image_index to consistently return the same value?

Drell

Member
It seems like due to image_speed and image_index returning as precision floating point values, the way that game maker evaluates them is somewhat inconsistent. I have the variable animSpeed which evaluates to 0.27 in the create event of my character object, but when I set the image_speed = animSpeed, image_speed returns 0.270000010728836. This would be fine except that it will evaluate to slightly different values in the trillionths and somehow when GM:S rounds the number when converting to a string it sometimes produces results that are one hundredth off from one another during it's rounding process. Is there a way to consistently get the same image_speed and image_index without completely creating my own animation functionality?
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
The way strings are rounded has nothing to do with the precision of the value itself... and you can use the string_format function to draw the exact value to any number of decimal places if required... Can I ask why you think you need a precision in trillions for these two variables? What problems is this causing you?
 

Drell

Member
The way strings are rounded has nothing to do with the precision of the value itself...
That's even more confusing then. I am working on rollback netcode for my 2D fighting game which works like this: with a truly deterministic game state, both players just send inputs back and forth while the game predicts what to do next during any latency receiving the inputs. If the game receives inputs different than what it predicted, it "rolls back" the game to the last known correct frame, and then simulates the frames up to current step with the correct inputs. Every part of my game is working for this except the image_speed/image_index.

I tried using string_format as suggested but ended up getting the same issue where the truncated value is off by a hundredth every so often: https://www.diffchecker.com/cVlXY6T5
This is especially confusing because the image_index for player 0 in this example does not match in the simulated game state even though the image_speed matches.

That said, the issue may be with how I'm processing the animation updates during the simulated game steps since I'm guessing at how GM:S2 handles incrementing the animations. My code for that looks like this:

GML:
if image_index+image_speed < image_number
    image_index += image_speed;
else{
    image_index = image_speed-(image_number-image_index);
}
If the issue is with this method of simulated animation, what's the best way to simulate GM:S's built in animation during my rollback process?
 

Gamebot

Member
1.

Perhaps I'm the dunce but why would you need to have your image_speed ever match your image_index? Speed up animation?
image_speed will never be exactly the same anyway as I believe this uses your game_speed ( generally 60 ) and will fluctuate slightly throughout your game.

2.
You say you have states, I'm guessing a state machine, why not just change to the last known correct image_index through that state.

myguess = state3;
actual = state4;

switch ( myguess ) {
case 3:
switch( actaual ) { image_index = // whatever // }
}

2.

Have you tried using <= and/or >= to check your values.

What about:
floor( image_index ) or
ceil ( image_index ) // Probably not this one //

EDIT: switch is pseudocode
If your using GMS2 you can use get_timer or delta_time to get time passed.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
I'm curious about this line of code:
GML:
image_index = image_speed-(image_number-image_index);
Why not just do this?
GML:
image_index -= image_number;
// or
image_index = image_index mod image_number;
in fact, I would change that entire calculation to be more like this:
GML:
image_index += image_speed;
if image_index >= image_number
{
image_index -= image_number;
}
I don't see any need at all for the extra stuff you've got going on in the current code, tbh...
 
Top