Need Help Optimizing Platformer Background Collision

[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!

[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

[Drag]

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.

[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.

[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!

[qbradq]

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.