Pixel Collision

Page: 1 2 3 4
Feb 8 2016, 9:59 am
I remember back in the day when games like Mortal Kombat had cheats to make the bounding boxes visible and it was just a bunch of rectangles piled on top of each other

Have you looked into how Sonic the Hedgehog on the Sega Genesis handled pixel collision? It's amazingly ugly, but also incredibly sensible.

There are some areas of game design where the clean/beautiful/complete solutions are infinitely worse/harder than the ugly solution.

Collision and pathfinding are two of those areas.
Feb 9 2016, 10:09 am
In response to Multiverse7
Multiverse7 wrote:
Ishuri wrote:
This is already possible, I think I'll do a tutorial.

Good luck with that. I can only imagine how terribly slow that would end up being. Just to start with, you will have to iterate over every single pixel, using icon.GetPixel(), to generate a 2D list matrix for collisions. Then, as things are about to collide, on every tick, you have to compare the trajectories of the nearest dense pixels in the matrices, to check for any contact. Don't forget to consider any anomalies, like different step_size values.

Feels like you're overcomplicating it. Surely you'd just run it when the atom is created, and create a bunch of sub-atoms with bounding boxes, and then write a small bit of custom collision checking and movement handling.

Code-foo GetPixel() and colour mask of atom's icon, generate a bunch of subAtoms that cover the whole icon

Override subAtom collision to pass all relevant information to main atom

Override main atom movement to move all subAtoms

You'd be trading constant checking for raw number of atoms on screen at any given time (Though I haven't checked the efficiency of visible number of atoms vs atoms that are on screen but don't get rendered).
Feb 9 2016, 10:44 am
In response to Rushnut
Rushnut wrote:
You'd be trading constant checking for raw number of atoms on screen at any given time.

Using whole atoms instead of constant checking would be astronomically worse, on both the RAM and CPU. For even simple shapes, you would be talking about thousands of highly synchronized, moving objs. The idea wasn't feasible to begin with, but now you made it almost completely impossible. Even using the bounds() proc to replace the objs would be better.
Feb 9 2016, 10:49 am
In response to Multiverse7
Whether or not my suggestion is feasible or not, don't doubt Ishuri, his entire Land of Fire project uses colour maps for custom pixel perfect collision and it runs buttery smooth.
Feb 9 2016, 10:57 am
In response to Rushnut
Rushnut wrote:
Whether or not my suggestion is feasible or not, don't doubt Ishuri, his entire Land of Fire project uses colour maps for custom pixel perfect collision and it runs buttery smooth.

[citation needed]

I was under the impression that he was being sarcastic.
Feb 9 2016, 11:01 am
In response to Multiverse7
Multiverse7 wrote:
[citation needed]

"Last but certainly not least, We've hired another Code wizard to assist in the game's development. Welcome Rushnut." - http://www.byond.com/forum/?post=1995186

I've seen it myself, it's super cool stuff.

I was under the impression that he was being sarcastic.

He wasn't.
Feb 9 2016, 11:18 am
In response to Rushnut
If that's true, then I would really like to know how Ishuri is using color mapped collision detection in a BYOND game. It would have to be relatively simple to run at any reasonable speed.
Page: 1 2 3 4