GML Question about Gravity vs Scale & Lerps

[RyanC]

Hi All,

I have been trying to make a ghost on my platform game which basically records the users game play and plays it back again.
The issue I'm facing is that on different scales the ghost does not perform correctly.

About the game mechanics.
player x position is generally fixed, with the floor objects moving instead.
game x and y speed is based on the game scale which varies on devices.
player x and y positions can sometimes move if pushed by another object, after which everything lerps a little to re-position the player in the room.
player y position also has a typical gravity and move_contact_solid() system.

The game has no views and all scale is done manually when zooming out. for example:
scale*=0.99
x*=0.99
y*=0.99 etc
game_speed then adjusts according to scale. Zooming can only be done before starting the level or recording.

I have managed to get a fairly reliable ghost recording but it occasionally has issues where the player is not at the same place at a certain step in the recording sequence when on a different scale.

My thoughts:
Should the gravity amount be based on game scale?
Are the lerps messing up the synchronicity on various scales? (The lerp speed is not based on scale, as I think this is a percentage of distance already which would take scale into account?)
What is the default math_set_epsilon() and can this be used to address the speed vs scale issue.
Is there a way to make all x and y values integers while still using gravity and lerp functions?

Any help greatly appreciated.

 

[TheouAegis]

Shouldn't you be doing all the calculations at full scale and then just draw things at scaled values? Because yes, you will need to scale EVERYTHING.

 

[NightFrost]

As Theou says, scaling is best done as visual effect only. Scaling your actual content can have undesirable side effects as you've noticed. Like collision check oddities, as the they run at integer values and round any floats they encounter. So, when scaling is just right, a character might suddenly consider itself one pixel above the ground it was standing on, or one pixel into the ground.

 

[RyanC]

Shouldn't you be doing all the calculations at full scale and then just draw things at scaled values? Because yes, you will need to scale EVERYTHING.

The game uses mouse_x and mouse_y to click on things in the levels, and so I thought the objects would need to be scaled so they can be checked for mouse clicks.

The room_width is set to the device width and room_height to the device height. The game scale and objects scale is all based on the width of the device.

Are you suggesting creating something like game maker's views? they take up lots of draw time and I chose not to use them for that reason but now I'm wondering if there's another way?

 

[TheouAegis]

I'm saying a single hit to the draw routine would probably be better than calculating x,y, hspeed, vspeed, image_xscale, image_yscale, and whatever else for every instance in the room. Each y is modified by a vspeed, which is modified by (a) gravity.

y = yprevious + (vspeed + gravity)

Scaling EVERYTHING last, which is what the draw method does, is the fastest.

y*scale = (yprevious + (vspeed + gravity))*scale

But with your current method, you would have to multiply vspeed and gravity both by 0.99 for all instances.