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