Timerbased Movement and Collision[SOLVED]

Previous topic - Next topic

XanthorXIII

I'll probably be correct on this but does collision and timer based movement go hand in hand? I'm having a slightly odd problem with collision. I have a large object colliding with smaller objects using ether Box or Sprcoll. I found that while both sometimes works I've noticed that at certain angles when it collides, it goes straight through the object. I wonder if I need to put the timerbased movement into my game to correct this issue.
Owlcat has wise

matchy

From the Samples/_Projects_/3DMaze.gbas
Code (glbasic) Select

dtime = GETTIMER()
// Show FPS / FPS anzeigen
fps = ((1000/dtime)+fps)/2
delay=delay+dtime
IF delay>1000 // 1/2 sec
delay=0
ShowFPS=fps
ENDIF

// limit on slow machines / begrenzen f. langsame Rechner
dtime = MIN(dtime, 16)


then:
Code (glbasic) Select

ply_x=ply_x+my*COS(ply_dir)*sz*dtime/1000
// IF X_COLLISIONAABB(0,0,ply_x, sz/2, ply_y, sz/4, sz/2, sz/4) THEN ply_x=ply_x_old
IF X_COLLISION(0, 0, sz/4, ply_x, sz/2, ply_y) THEN ply_x = ply_x_old

ply_y=ply_y+my*SIN(ply_dir)*sz*dtime/1000

BdR

Isn't this a matter of one object completely passing through the other in one update step? I mean, each iteration (or cycle or update or whatever you call it) both objects are updated and move a little bit. When one object goes too fast, it can "pass through" the other object and the collision-detection won't notice it because the objects never overlap. See example below:

object A -> speed is 1 steps
object B <- speed is 3 steps

Iteration 1) --A-----B---
Iteration 2) ---A-B------
Iteration 3) --B-A-------

I think this could be solved by taking smaller steps or limiting top speed or doing multiple collision checks per movement update.

XanthorXIII

I think that sounds about right. The object I'm using is 44 pixels W/H and the smaller object is 20 pixels. The objects that are 20 pixels are stationary.
Owlcat has wise

Slydog

#4
From BdR:
Quoteor doing multiple collision checks per movement update

That's how my nephew handles it in his platformer.
He figures out how many pixels the object will move that frame.
Then loops for each pixel and does a SPRCOLL() at each new position.

I'm not sure how slow this is.  Only moving objects need to be checked, but it could add up quickly.
I guess if it gets too slow we could use BOXCOLL() instead, but I don't think that will help much as that's what SPRCOLL() does first anyways!

Or don't check EVERY pixel, but every 2nd or 3rd, depending on the size of your smallest object, but you risk situations where just the corners may have overlapped for a pixel.  I guess it all depends if you're going for 'perfect' or 'close enough'!

[Edit] Another advantage of doing it every pixel is that when you do find a collision, you stop the loop, and you'll know the objects are snug up against each other (when you place it back at the previously known good coordinates!).  Otherwise with a large move, you may detect a collision somewhere in the next 15 pixels but you don't know exactly where to place the moving object so it appears touching the other one.  But now if both objects are moving towards each other, and one left at 10:15am . . .
My current project (WIP) :: TwistedMaze <<  [Updated: 2015-11-25]

XanthorXIII

After re-thinking my code some I figured out that since I wanted to do multiple checks why not have a flag that says a collision has taken place. So I loop through the array of items, check for a collision it sets the flag to true, deletes the item and checks for the next one. After I do all that I then have my object that is moving react to the hit flag and poof, my problem has been solved.
I still will probably put in Timer Based movement but this makes my game run so much better.
Owlcat has wise