Collision Detection

For questions about using Classic.

Post » Sat May 19, 2012 7:52 pm

It will not collide perfectly because your sprite will move more than 1 pixel per frame, ex. if your sprite is 1 pixel from the object to collide and your FPS is 60 than, 120*1/60 = 2 pixels, it will move 1 pixel inside the collision object, with lower FPS is even wrost try to put it fixed aroud 15 fps and test, try it on unlimited too and you will see it work perfectly because it will move lower than 1 pixel per frame.
The way i discribed, using loops, will always move the exact pixels before collide with the object.

The "is moving" i mean to be your way to detect this, in your case you have to do "On keyboard: Left button is down", move to left, and so on...

Metal_X2012-05-19 20:05:57
B
22
S
7
G
5
Posts: 90
Reputation: 3,430

Post » Tue May 22, 2012 4:43 pm

[QUOTE=Metal_X] It will not collide perfectly because your sprite will move more than 1 pixel per frame, ex. if your sprite is 1 pixel from the object to collide and your FPS is 60 than, 120*1/60 = 2 pixels, it will move 1 pixel inside the collision object, with lower FPS is even wrost try to put it fixed aroud 15 fps and test, try it on unlimited too and you will see it work perfectly because it will move lower than 1 pixel per frame.
The way i discribed, using loops, will always move the exact pixels before collide with the object.

The "is moving" i mean to be your way to detect this, in your case you have to do "On keyboard: Left button is down", move to left, and so on...

[/QUOTE]

Hehehe, i thought so, i felt dumb thinking there was an "is moving" event that i'd skipped over! anyways that question HAD to be asked

anyways, are either fixed or unlimited FPS recommended? i thought v-sync was optimal.

I had tried it on unlimited, and collision-wise it worked great, but i had that sprite tearing almost, that i reference before, like for example, if the sprite is 32x32, it'll show up as that size, but within its own 32x32 bounding box, it'd be moved say to the right, and the left border would be drawn into the X0 and X1 columns, weird.

and i thought fixed FPS was supposed to hinder your TimeDelta

i'm looking forward to implementing a loop as you suggested, it looks like i'll have to clean up the game structure first, in order to replace it neatly hahahaha

as for now, while i'm restructuring it, i got around the collision enough to work with it with something like this:

B pick closest to A.left\right\top\bottom
+ if A.left\right\top\bottom >\< B.left\right\top\bottom -\+ speed*TimeDelta
-> then move at speed*TimeDelta
etc

extremely summarized but in essence that's what i got around to enough for it to work until applying loops, if it helps anyone in the future.


XD
B
6
S
1
G
1
Posts: 52
Reputation: 858

Post » Wed May 23, 2012 2:17 am

Metal_X described a lot more detailed, what I meant in my previous post by "when not working v-synced".

And, yes, you have to decide wether to go pixel based or time based. A mixture will almost always fail. Using a fixed rate may assure you to work pixel based, but will have a jerking output (as it isn't in sync). v-sync and deltatime, on the other hand, will assure you of the same game speed at all rates and a smooth output.

For problems like yours, when people want to work time based, they use a technique like "push out". Whenever a collision happens, the object will be moved out of the other object within one frame. In result, it looks like it collides pixel accurate. There also is "overlap at offset" which helps a lot, too, when working time based.tulamide2012-05-23 02:19:01
Image
B
23
S
8
G
10
Posts: 1,820
Reputation: 8,242

Previous

Return to Help & Support using Construct Classic

Who is online

Users browsing this forum: No registered users and 5 guests