• Dear Cerberus X User!

    As we prepare to transition the forum ownership from Mike to Phil (TripleHead GmbH), we need your explicit consent to transfer your user data in accordance with our amended Terms and Rules in order to be compliant with data protection laws.

    Important: If you accept the amended Terms and Rules, you agree to the transfer of your user data to the future forum owner!

    Please read the new Terms and Rules below, check the box to agree, and click "Accept" to continue enjoying your Cerberus X Forum experience. The deadline for consent is April 5, 2024.

    Do not accept the amended Terms and Rules if you do not wish your personal data to be transferred to the future forum owner!

    Accepting ensures:

    - Continued access to your account with a short break for the actual transfer.

    - Retention of your data under the same terms.

    Without consent:

    - You don't have further access to your forum user account.

    - Your account and personal data will be deleted after April 5, 2024.

    - Public posts remain, but usernames indicating real identity will be anonymized. If you disagree with a fictitious name you have the option to contact us so we can find a name that is acceptable to you.

    We hope to keep you in our community and see you on the forum soon!

    All the best

    Your Cerberus X Team

Collisions

Wingnut

Well-known member
3rd Party Module Dev
Tutorial Author
Joined
Jan 2, 2020
Messages
1,414
One interesting fact about Nintendo's consoles is that they did not support collision any hardwares of theirs except NES which had collision bit but only for sprite number #1. Every Nintendo game you've ever played used rectangular collisions or some other kind of math.

Two of the computers that I grew up with actually did have hardware-collision but the first one was pretty much unused because of how hard it was to distinct what hit what. The other one used a mask-technique which made it much easier to use but it was also rarely used because it was not completely free.

Btw pixel-exact collision felt pretty common back in the day but understanding the math of overlapping rectangles and slanted tiles and all the other things that we take for granted today felt very magical. Today I would say pixel-exact collision would be the harder thing to do.

I'm converting a worms & lemmings -like game to Cerberus-X and so this is something that caught my attention now.
My plan now is to solve this complexly using the GPU, and not a single read to the CPU as GPU doesn't like to be read. I was thinking of mimicing the above computers and do it through hardware.

The first technique that I'm gonna try is shaders and atomic counters. Got also some ideas that could make it easier to identify objects, one idea is to implement object-ID in the pixel colors of the sprites. Maybe it's crazy, we'll see, maybe. But it could be fun and interesting. We'll see.

But anyways I got intrigued about the fact that Nintendo never had pixel-exact collision. I know it doesn't make a lot of sense in 3d games and such nowadays, but It will a fun aside-project that can teach you some things, I hope.
 
Pixel collision, when a single pixel on screen takes 4 bytes can escalate very, very quickly to something unusable. Hence the use of AABB, circle-circle and even physics engines like Box2D to calculate collisions.
 
I don't know if this is a thing, but the idea just occurred to me - run a shadow game with a low res pixel collision engine, and get your collisions in the real game from that.

If you're making a Wormslike, you need pixel collisions of some sort.
 
If you're making a Wormslike, you need pixel collisions of some sort.
Not quite :)

In the old days, for sure. You'd use a b/w bitmap for collisions, cached as one big array in memory. You could even 'compress it' by storing 8 pixels in a single byte - although that would make updating the 'bitmap' a little more complicated.

Today I'd just use something like Box2D and build everything out of polygons and 'rebuild / deform it' when and where necessary.
(Unfortunately in Monkey/Cerberus in mojo1 DrawPoly only draws 'flat' surfaces, it doesn't take an image to be used as a texture.)
 
Back
Top Bottom