pouët.net

Frame-independent movement, I'm stuck

category: general [glöplog]
No. I'm using line intersection to determine whether there was a collision or not, e.g. I draw a line between the player's old position and the new position and intersect it with possible platforms it may collide with.
saga music, do platforms collide between themselves?
added on the 2009-01-01 22:55:39 by texel texel
No, it's just the player and the platforms. For better understanding, check my game: http://sagagames.de/?programm=jumpin_hi
ah, ok, then there is no need for space partitioning
added on the 2009-01-01 22:57:02 by texel texel
The game doesn't work correctly on my VPC but, by the screenshots, does it is a platform game where the physics are only applied to the ball? Do the platforms are statically placed?
added on the 2009-01-01 23:02:08 by texel texel
well, physics are also applied on the particles, but that's the same math. Platforms are also static (well, they can fall down, but that's another simple thing), so the only calculations that are really screwed up are the ball's physics, yes.
then you might use space partitioning. Read about it. It could solve all your speed problems, and you could increase the granularity
added on the 2009-01-01 23:09:44 by texel texel
I cannot really see how that could fix my problem at the moment, which is more an unsteady timer than problems with calculating too many particles. :\
I tried to increase the granularity of the position updates, e.g. calling it ten times instead of one time, but that does not help either, because something in my formulas simply seems to be fucked up. I divided vy by 10, I divided movement steps by 10. and now I get a very fast x movement and a very slow y movement again.
if you divide all by 10 it is just not correct.

If the time is divided by 10 -10 times more steps -, then you have to divide X movement by 10, and vy by sqrt10(10) (I mean elevate vy to (1/10))
added on the 2009-01-01 23:41:35 by texel texel
sorry, sqrt10 is not very correct. I mean the 10th root... I'm not sure how it is written in english... Just elevate to 1/10
added on the 2009-01-01 23:42:49 by texel texel
just so you know, with 5:

if you divide by 10, you get 0.5 (this is not correct)
if you elevate to 1/10, you get ~1.17

As you can see, the vy is higher in that second case
added on the 2009-01-01 23:44:04 by texel texel
wait... ummm... not sure if what I wrote is correct... let me see again..
added on the 2009-01-01 23:48:58 by texel texel
can you write it in code? :P
Calculate physics at fixed framerate, eg 100hz, and interpolate linearly for smooth movement.

That is, say you have a milisec timer, and you are the nth frame:

frame n-1 @ 353 ms
frame n @ 413 ms

then your last physics calculation was at 360ms. Now compute the physics until 420 ms, with 10ms resolution, and interpolate between the result at 410 ms and 420 ms using the 3/10 ratio ( = (7*pos(410)+3*pos(420))/10. )
added on the 2009-01-02 00:10:24 by blala blala
Sorry saga musix
Forget what I wrote before: but this should be more coherent:

This is your actual code:

y+=vy;
vy+=g;

You want 10 times more steps:

y+=vy/10;
vy+=g/10;

This is the same that:

y+=vy;
vy+=g/(10*10);

Remember that in this case, every step means 1/10 of x movement too.
added on the 2009-01-02 00:10:59 by texel texel
maybe i'm just dumb or i'm missing something obvious... i just don't get it working in any way I try it. :(
if you take a look at the example I posted on the last page and do the maths (i.e. simplify and derive the equation to get the delta function)
you get sth. like this:

Code: y += 0.5 * acc * 2 * time_since_coll * dt; time_since_coll += dt;


(dt=delta time, acc=acceleration)

added on the 2009-01-02 00:26:19 by xyz xyz
0.5 * 2 is a bit pointless... :) but what exactly is time_since_coll? a second timer variable, wtf?
needless to say, the right hand side expression (0.5 * acc ...) boils down to a single value that you can add to each of the 10.000 particles, for example :)
"time_since_coll" would be the particle life time in that case.

in terms of your game, it's basically just a counter that you increase by "dt" each frame and reset if "The Ball" hits a platform.
added on the 2009-01-02 01:05:14 by xyz xyz
(ok I guess I am confusing you right now: What you actually wanna do is do the maths to derive the "velocity" function instead of the "distance" one.. so you can e.g. calc the reflection velocity vector on collision..)

schau mal hier:
Gleichmässig beschleunigte Bewegung
added on the 2009-01-02 01:08:38 by xyz xyz
I can't really imagine how that should work. The ball just gets faster and faster here (and that's what i expected it to do...)

Damn, this is giving me a serious headache.
well, :) then integrate numerically and add the delta to the "force vector" of your ball.
(see velocity function above.. the "right hand side" of the y+= line is the current velocity!)
you can then also add other influences like e.g. ventilators to that "force vector"..

and what'ya mean, it gets faster and faster? the collision detection should take care of that and let the ball bounce off platforms ?!


added on the 2009-01-02 01:21:16 by xyz xyz
well, there was simply no collision, the ball went straight upwards and out of sight :D

i thought about integrating as well, but at the moment I can't recall what I wanted to integrate... damn, this is so confusing :(
nobody said it'd be easy ;)
just think about this a couple of days and you will get it

here's some example code to calculate a "reflection vector":

Code: static method Reflect(Vector3f vNorm, vIn, vReflect) { vNorm.unit(); float l = vIn.abs; Vector3f i; vIn.unit() => i; float f2 = i.dot(vNorm); Vector3f t; vNorm.mulf(f2) => t; vReflect = t; vReflect.add(t); vReflect.sub(i); vReflect.mulf(-l); }


(
"abs" = sqrt(x*x + y*y + z*z)
"unit"= each vector component (x,y,z) divided by the length of the vector, i.e. "abs")

I leave it up to you to simplify that code for 2D and the "C" language ;)
added on the 2009-01-02 01:39:58 by xyz xyz

login