Jumping routine with physics - need a littlehelp

SDL Development
1

Benjamin Deutsch wrote:

Hi again,

Now if I may ask of one mor thing, while the jumping is smooth now, I
notice that occasionally when I start jumping it’ll spike a little
higher then resume going a constant hieght. I think this has to do
with the timing I’m trying to impliment (the 'int true_accel = accel

  • tick_delta/10;’ line). I devided by 10, when I oriiginally thought
    to use 1000 but that gave me decimal value and ends up being
    interpreded as
  1. And I thought it best to avoid something like ‘while (ticks <
    ticks_last + interval) ticks = SDL_GetTicks();’ which would limit the
    fame to that much time. Is there any way to remedy this?

I agree with David on this; using floating points is much more
accurate. Your code should calculate how many (fractional) seconds
passed since
the last frame, and calculate the movement based on this time delta.
Your velX and velY seem to be fixed on a per-frame basis, but each
frame could be different in length. But if your approach works, keep
it that way.

Well I’m seeking to improve my approuch. I’m not sure how to incorporate
the floating point i na useful manner, seeing that those information
gets lost somewhre along the line, since the finaly movement is done as
integers (as far as I know you can’t have half a pixel, or even if you
can, I don’t see how that can be done in SDL, seeing as the actualy
drawing (such as in my DrawIMG functions) is using SDL_BlitSurface,
which takes an SDL_Rect, whih uses ints.)

So maybe I’m missing your meaning. Do you mean perhaps to make
everything floats or doubles (vel’s, guy/move/X/Y, tick stuff) and then
let DrawIMG harvest the int part? I’m not sure hwo this wil lbe more
accurate when it’ll eventually be turned back into ints.

Oh, and you may want to change the guy’s velocity (now in the “//
Jump.” block) after the guy has moved, so you’ll get the full
max_velocity in the first frame of jumping.

I’m not sure what you mean here? This doesn’t make sense to me. How
can the guy move before the velocity is set? Perhaps I’m not
understanding what you meant.

No, not before it is set, before it is adjusted. In your (original)
"// Jump." block, you have a line
velY -= true_accel;
That’s the line I’m talking about. Move this more towards the back,
otherwise you will never use the full maximal velocity, only the
once-diminished form.

Ah, seems so clear now, it would substract first and ask questions
later. Thanks for claring that up. I don’t think I’ve had enough sleep
lately lol.–
Blaza

2

[…]

So maybe I’m missing your meaning. Do you mean perhaps to make
everything floats or doubles (vel’s, guy/move/X/Y, tick stuff) and
then let DrawIMG harvest the int part? I’m not sure hwo this wil
lbe more accurate when it’ll eventually be turned back into ints.

If you use integers for accelerations, velocities and positions, you
must ensure that the exact values used are always integer values. No
problem - games were often designed that way in the 8 and 16 bit
days, and it worked just fine.

However, when you design like that and then drag in variable frame
rates, and must scale everything by delta times, you run into two
major - and apparently rather non-obvious - problems:

1) Time dependent "constants" and variables must be
   scaled to fractions of your designed frame rate. 
   Unless your designed frame rate matches the
   granularity of the time base (ie "unless you design
   around a 1000 Hz logic frame rate" in the case of
   SDL_GetTicks()), there will be rounding errors.
   Since the calculations are recursive (math lingo;
   "iterative" to programmers), this will result in
   literally explosive rounding error build-up! That
   is, objects can stop moving entirely, or move with
   speeds that are up to 100% off, working with pos +
   speed only. Acceleration makes it a lot worse.

2) The game logic (ie collission tests and event
   handling) runs at varying "random" points in logic
   time, which means that event timing gets a random
   timing jitter added to it. The net result of this
   is that the game behaves unpredictably. When the
   game runs at a lower frame rate than the designer
   had in mind, objects may fly through walls and
   stuff, and/or bounce/explode/whatever before they
   touch, depending on the implementation.

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Sunday 16 May 2004 11.57, Blaza wrote:

3

David Olofson wrote:

[…]

So maybe I’m missing your meaning. Do you mean perhaps to make
everything floats or doubles (vel’s, guy/move/X/Y, tick stuff) and
then let DrawIMG harvest the int part? I’m not sure hwo this wil
lbe more accurate when it’ll eventually be turned back into ints.

If you use integers for accelerations, velocities and positions, you
must ensure that the exact values used are always integer values. No
problem - games were often designed that way in the 8 and 16 bit
days, and it worked just fine.

Well I made delta_time, velX/Y, accel, grav, doubles, but the end result
still has to be an int for the final movement offset value (moveX/Y to
change guyX/Y) and so I’ll still loose information, especially annoying
for abs(velX/Y) less than 1, unless there is some way (in SDL or so) to
move by a fraction of a pixel, something I’ve never heard of. This is my
problem.

However, when you design like that and then drag in variable frame
rates, and must scale everything by delta times, you run into two
major - and apparently rather non-obvious - problems:

  1. Time dependent “constants” and variables must be
    scaled to fractions of your designed frame rate.
    Unless your designed frame rate matches the
    granularity of the time base (ie “unless you design
    around a 1000 Hz logic frame rate” in the case of
    SDL_GetTicks()), there will be rounding errors.
    Since the calculations are recursive (math lingo;
    “iterative” to programmers), this will result in
    literally explosive rounding error build-up! That
    is, objects can stop moving entirely, or move with
    speeds that are up to 100% off, working with pos +
    speed only. Acceleration makes it a lot worse.

Note really sure what you’re geting at here. SDL_GetTicks() returns an
integer value, of milliseconds, not a decimal.

  1. The game logic (ie collission tests and event
    handling) runs at varying “random” points in logic
    time, which means that event timing gets a random
    timing jitter added to it. The net result of this
    is that the game behaves unpredictably. When the
    game runs at a lower frame rate than the designer
    had in mind, objects may fly through walls and
    stuff, and/or bounce/explode/whatever before they
    touch, depending on the implementation.

Well I have my CanMove function to make sure anything that goes into a
wall gets stopped by it (ie smacks into it.)> On Sunday 16 May 2004 11.57, Blaza wrote:

–
Blaza

4

David Olofson wrote:

[…]

So maybe I’m missing your meaning. Do you mean perhaps to make
everything floats or doubles (vel’s, guy/move/X/Y, tick stuff)
and then let DrawIMG harvest the int part? I’m not sure hwo this
wil lbe more accurate when it’ll eventually be turned back into
ints.

If you use integers for accelerations, velocities and positions,
you must ensure that the exact values used are always integer
values. No problem - games were often designed that way in the 8
and 16 bit days, and it worked just fine.

Well I made delta_time, velX/Y, accel, grav, doubles, but the end
result still has to be an int for the final movement offset value
(moveX/Y to change guyX/Y)
[…]

No, that’s rounding one step too early! Make your object coordinates
(guyX/Y) floating point, and round only when rendering.

However, when you design like that and then drag in variable
frame rates, and must scale everything by delta times, you run
into two major - and apparently rather non-obvious - problems:

  1. Time dependent “constants” and variables must be
    scaled to fractions of your designed frame rate.
    Unless your designed frame rate matches the
    granularity of the time base (ie “unless you design
    around a 1000 Hz logic frame rate” in the case of
    SDL_GetTicks()), there will be rounding errors.
    Since the calculations are recursive (math lingo;
    “iterative” to programmers), this will result in
    literally explosive rounding error build-up! That
    is, objects can stop moving entirely, or move with
    speeds that are up to 100% off, working with pos +
    speed only. Acceleration makes it a lot worse.

Note really sure what you’re geting at here. SDL_GetTicks() returns
an integer value, of milliseconds, not a decimal.

Yeah, but unless your speed and acceleration units are the equivalent
of kpixels/s and kpixels/s? (ie a speed of 1 is 1000 pixels/second
and an acceleration of 1 is 1000 pixels/s?), there’s no way you can
get away with integers without rounding errors…

Basically, if there’s a division somewhere in there, you’re losing
bits - and the earlier you’re rounding, the worse the rounding error
buildup.

  1. The game logic (ie collission tests and event
    handling) runs at varying “random” points in logic
    time, which means that event timing gets a random
    timing jitter added to it. The net result of this
    is that the game behaves unpredictably. When the
    game runs at a lower frame rate than the designer
    had in mind, objects may fly through walls and
    stuff, and/or bounce/explode/whatever before they
    touch, depending on the implementation.

Well I have my CanMove function to make sure anything that goes
into a wall gets stopped by it (ie smacks into it.)

Does it handle the case where an object is on one side of a wall in
one fame, and completely on the other side of the wall in the next
frame; ie no intersection at any point that’s actually tested? Does
it calculate the exact position and time of the collision? Does the
rest of your game logic (ie events and stuff) take the exact time of
collisions in account?

If not, your game logic will behave differently from time to time, and
between machines.

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Monday 24 May 2004 01.45, Blaza wrote:

On Sunday 16 May 2004 11.57, Blaza wrote:

5

I haven’t read most of this thread, so don’t mind me
if my comments seem irrelevant or redundant. My first
suggestion is to do what I’ve had a lot of success
using: scaled integers, used where I would have used
floats for the reasons of having more granularity of
motion than counting pixels. To implement this, just
#define a scale macro and multiply all pixel values by
it, and divide all position values by it to get real
pixel position. Using a power of 2 for your scale will
increase the speed of division dramatically because
your compiler will just bitshift which is a very
simple operation.

If this is a game where JUMPING AND FALLING are the
only places you want this sort of granularity, you
should consider doing what has been done in the past
by console developers. Simply create an array of
accelerated velocity values. It’s not only simpler and
well suited to the purpose of any platformer, but it
also allows you powerful customization over your
gravity curve, as many platformers use deliberately
unrealistic physics to make easier or more fun
gameplay.

Hope this helps! Please let me know.__________________________________
Do you Yahoo!?
Yahoo! Domains ? Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer