EDIT: The post below has been answered by experiment… It works perfectly…
I can recommend using a gigantic 2d array for collision detection…
Original post:
Is it within reason to define each pixel of a side-scroller in big 2d int array (int for terrain types), so things like projectiles can just look up their screen coordinate in the array for whether or not they collide with the terrain?
I would generate these 2d arrays from normal 1920* 1080 textures. Each level consists of 10 to 20 of such images.
I realize that would mean millions of array entries, and indexing into the tens-of-thousands. Is this normal in the computing world?
Would I run into problems with ram or anything?
-I am also considering implementing something like quad-trees / subdividing my terrain pieces for normal perPixel detection, but this seems like a more extensive over-haul…
Could you have a black and white mask of the collision points and reference that instead? I’m just starting to try this approach myself so fingers crossed it works.
Personally the array idea fills me with dread! If you use a good pixel detection routine and your sprites don’t have too much dead space it can be pretty quick.
Thanks for your response. Well, I actually already have that, I’ve used red and white, and even other colors for scripted events/ enemy paths etc… But the problem is when you want to do detection on MANY objects, lots of missiles and bullets and wheels, etc, you have to do a rather cumbersome operation for every instance…
This can create lag, especially on mobile computers, or lower-end graphics cards.
It would just be a lot faster to just look up a number in a chart, rather than processing images for collisions? Tons of missiles could look up a number in an array, I think…
Any more thoughts?
As we’ve both just found, it works a treat!
I would say it is not usual to have a full high-resolution pixel perfect collision map.
Is your screen built up from tiles? Have a collision mask for each tile. Since tiles are repeated many times and reference the same graphics, do the same with your collision tiles.
If you are using a full colour 1920x1080 image for the collision mask, you are using 8MB of memory (4 bytes per pixel, at 2073600 pixels). Do you really need 16 million terrain types, which is what 32-bits per pixel will give you?
A 1-bit 1920x1080 collision mask (representing a simple hit or miss) would consume a shade under 256KB of memory. If you expand that to 4 bits to allow up to 16 terrain types, that is 1MB per collision mask. This would need some pre-processing of the collision data (you wouldn’t be able to load it as a texture) to get this memory saving. It will save you memory, and help to reduce memory cache misses you would usually get from indexing into a massive array.
“Is your screen built up from tiles? Have a collision mask for each
tile. Since tiles are repeated many times and reference the same
graphics, do the same with your collision tiles.”
Nah, for this project I use full hand-drawn images, so every pixel is unique…
The whole idea behind all this, was using GIMP as a level editor, without needing to tile-map anything 
“A 1-bit 1920x1080 collision mask (representing a simple hit or miss)
would consume a shade under 256KB of memory. If you expand that to 4
bits to allow up to 16 terrain types, that is 1MB per collision mask.
This would need some pre-processing of the collision data (you wouldn’t
be able to load it as a texture) to get this memory saving. It will
save you memory, and help to reduce memory cache misses you would
usually get from indexing into a massive array.”
My collision mask is loaded from textures into a color array…
Are you saying store something smaller than color in each cell? I could do that, I only need a dozen or so variations.
What data-type would be best?