Testing for collision against a particular colour

[kcfb]

I've been experimenting with the above recently, as I have been wanting to work on a platformer with irregular slopes - I've found this to be pretty difficult if I use the regular collision check for rectangle against rectangle. So this demo checks for specific colours in the pixels at 9 points that surround the player, and if it finds a particular colour (255,0,0 in this case) it reacts according to rules in the code, which vary depending on where the collision has taken place, relative to the player.

As it stands, you need to keep any slopes below about 45 degrees - even if just a few pixels exceed this, the player may get stuck.

The demo is pretty basic, and it will be interesting to see whether it runs quickly enough when the code gets larger - I'm pretty confident it will (it's running at about 300 fps on one of my older laptops currently).

Has anyone worked with anything similar? I'd be interested to hear any tips or observations if you have.

   


  Colour collision demo.zip (Size: 445.83 KB / Downloads: 4)

[johnno1956]

I have actually deliberately avoided 'slopes' because of the problems associated with "catching" on said slopes - regardless of the angle... I suppose it is one of the drawbacks of AABB collision detection... Since you raised the subject, I have been looking through some solutions/suggestions, as to how to overcome the problem. AABB and Circular collision detect are generally the fastest but moving towards polygons means more processing and possible 'slowing'.

I suppose the issue would stem from the "hit box" that is usually applied. All 4 sides at right angles. Which immediately has problems if the "ground" side comes across an object a pixel or two higher. It "catches" on the leading face of the pixel. There is still a lot about this I do not fully understand. Most of the examples I have read (or tried to read) were written or coded for some other kind if editor... This is not very helpful... but you 'did' ask... lol

I started reading (https://info.sonicretro.org/SPG:Slope_Collision) about Slope Collision for Sonic the Hedgehog. Touching on Ground, Ceiling and Push collision... For me, it is a bit heavy going, but you will probably follow it better than I.

I will keep researching and let you know if I can find a "simpler" solution.

By the way, what you have done so far, is really good... Using "pixel" (or any colour detection at a pixel level) will always be "labour intensive" and possibly effect performance... But, because the screen size and detecting only one colour, the demo is quite "playable".

Looking forward to the next version...

[kcfb]

Thanks Johnno - the website for Sonic collision looks really useful. I've only glanced at it for now, but already I can see that I may be able to make the code more efficient by just checking specific parts of the players edges, depending on the direction of travel - i.e. if the player is moving to the left and down, check the players' left side and base only. Seems obvious now, but I had totally missed that, so thank you.

Incidentally, the code I am trying to produce is miles away from being pixel perfect collision. I am only checking 9 pixels each frame, as opposed to the 128 pixels that I would need to check for pixel perfect collision for a 32 * 32 player. I've tried the latter, but the result moves far to slowly. However, for my purposes I think the results checking just the 9 points is good enough.

Again, many thanks for your response and suggestion.

[Marcus]

I'm at my dad's, far away from computers, for a week. I'll definitely have a look at your code when I get back home

[johnno1956]

Enjoy your visit... "see" you when you get back...

J

[johnno1956]

kcfb,

"I am only checking 9 pixels each frame, as opposed to the 128 pixels"... I am curious. Which nine?

I had a crazy thought (you can stop laughing now...) that one would only need to check the player pixels on the "side" of the direction the player is moving. eg: If moving right, check 3 pixels, top right; centre right and bottom right. Reason: If the player is moving right, why would one need check behind or above? (for your demo as is) This theory falls on it face if there are bad-guys etc. that are moving in from multiple directions... I hope that I am making sense...

There does not seem to be a "happy medium". Either use an efficient, but at times, inaccurate AABB or suffer from performance (potential) issues with pixel-perfect collision. Using PP detection, in your case, seems to be the better choice. I can see why you would need to reduce the number of detection points... Oh... One possible issue with only checking for a singe pixel, is the speed of the player... It maybe possible for the player to 'travel' too far 'before' the detection routine can stop it. The player may end up being "stuck" in a wall. I suppose checking "before" moving may help... I only mention it because I remember seeing that happen in platform tutorials... But that was a long time ago... I digress... Probably my lack of caffeine talking... lol

Sorry.. At times I suffer from "waffle-itis"... I really need to work on brevity... lol

Have a great day!

J

[kcfb]

Hi Johnno,

"I am only checking 9 pixels each frame, as opposed to the 128 pixels"... I am curious. Which nine?

These are detailed in the collision function - I check 3 pixels on the lower edge, and 2 on each of the sides and the top, avoiding using the corners. I avoid the corners for the reason that I think you mentioned before - a corner could be colliding from underneath and to the side. I have an additional collision point on the lower edge to improve collision detection on uneven ground.

One possible issue with only checking for a singe pixel, is the speed of the player... It maybe possible for the player to 'travel' too far 'before' the detection routine can stop it. The player may end up being "stuck" in a wall.

This is indeed an issue that I run into while experimenting with this. I have worked around it in the collision function by repeating the collision detection each frame. So I check for a collision, adjust the players position, and repeat the collision detection using the players new position. If there is no collision the second time, the players new position is unchanged  of course. Even doing this, it is necessary to restrict both the players speed, and the speed of gravity, to below 3 and below 2 pixels each frame.

I'm enjoying looking at collision detection, and am currently looking at a couple of other procedures (including the Sonic one that you suggested). Still really focusing on solutions for collision detection against uneven slopes (not necessarily checking for colours), so I thnk I may be busy on this for a while yet.....

[johnno1956]

Speaking of slopes... I remembered a series on building platformers using Scratch... https://www.youtube.com/watch?v=Ham3cyqbPuQ (ignore all the "blocky bits" and start from about 2min 10sec where he starts to talk about moving up slopes (without jumping) then moving down slopes. If you have not used scratch in the past, it may be a little confusing about using this block or that block, but it may be of interest to focus on the math of the movement...

At times I use Scratch to 'prototype' because it is easy enough to patch together a concept before trying to actually code it.... Hopefully this may help?

J

[Marcus]

I've just had a quick look at your demo, and it looks very nice

For higher speeds maybe you can "just" create a loop where you move a maximum of 1 pixel per iteration?