Page 1 of 1
Need Help Optimizing Platformer Background Collision
Posted: Tue Mar 22, 2011 1:51 pm
by qbradq
I've just written my first update and background collision routine for a new project I am working on. I have never done a platformer before. I've gone over the logic several times, but I get the impression that it is sub-optimal. Could you all help me think this through? I can't seem to find any discussion of this on the forums.
Note that this routine handles applying gravity, applying velocity to position, background collision and response to those collisions.
Code: Select all
For Object in All Objects
Apply gravity to Object Y velocity
Apply Y velocity to Y position
Calculate bounds
Check Y collision with background
If a collision occured
Correct Y position
Recalculate top and bottom bounds
Apply X velocity to X position
Recalculate left and right bounds
Check X collision with background
If a collision occured
Correct X position
Recalculate left and right bounds
My current implementation resolves all edge-cases, but there is a lot of processing here. My current implementation is taking a full 6 scan lines worst-case. I could probably trim this down a bit, but I can't shake the feeling that my logic is not optimal.
Thoughts? How do you all implement platformer-style collision detection?
Thanks!
Posted: Tue Mar 22, 2011 3:49 pm
by cartlemmy
6 scan lines total? That's really good as far as I know. Even 6 scan lines per object doesn't seem too bad. Though I'm no expert
Re: Need Help Optimizing Platformer Background Collision
Posted: Tue Mar 22, 2011 4:05 pm
by Drag
qbradq wrote:My current implementation is taking a full 6 scan lines worst-case.
Is that 6 scanlines per object, or 6 scanlines total for all of the objects?
Either way, that sequence itself is correct, so any optimizations would need to be for the code itself.
Posted: Tue Mar 22, 2011 4:55 pm
by tokumaru
I have to agree that even 6 scanlines per object sounds very reasonable if you are doing proper physics and collisions for all of them. A lot of games don't even apply the same rules to all objects, since not all of them need such complex handling. Some objects don't move at all, others are always on the floor and never move vertically, and most times they can get by with fewer collision points than the main character, so you can usually save some processing time in those cases.
Posted: Tue Mar 22, 2011 5:04 pm
by qbradq
6 scanlines per object. I have 1 player, 4 mobiles and 11 projectiles possible giving me a worst-case of 96 lines. This does not include AI or object to object collision detection or music.
I suppose I could lower the projectile count. This more of a Zelda II affair anyhow. That would help with scaling the object to object collisions as well.
Thanks for your input!
Posted: Tue Mar 22, 2011 5:17 pm
by qbradq
tokumaru wrote:I have to agree that even 6 scanlines per object sounds very reasonable if you are doing proper physics and collisions for all of them. A lot of games don't even apply the same rules to all objects, since not all of them need such complex handling. Some objects don't move at all, others are always on the floor and never move vertically, and most times they can get by with fewer collision points than the main character, so you can usually save some processing time in those cases.
Right, there will be many more types of objects in the game, such as NPCs, pick-up-able items, attack hit boxes and shields. None of these objects have an applied velocity, nor do they collide with the background. The only processing they require is pre-calculating the bounding boxes for the object to object collision phase.
Even for objects that do need complex processing if they have a zero X speed I skip the bottom half of the routine. Every complex object has some Y speed every frame due to gravity.
Thanks again for the input! This type of semi-rhetorical questioning is very helpful to me, and hopefully to others that find this thread.