Precise collision for static sprites

Alright, update time. Here is an example of some simple collision mask collision using C2's built in array object. This is the simplest type of mask collision which is really just a straight array of layout x by layout y and it's pretty suboptimal as far as performance expectations go, especially since everything is buried under C2's function calls which are kind of slow compared to what you could expect out of something specifically coded for the task.

filedropper.com/arraycollisionmask

Actually the news is pretty good. In this manner, up to 450 pixels per frame could be tested on my machine before framerates dropped below 60. This might not seem like a huge amount, but when you consider that you can usually get by testing 8 or so pixels for the primary character collision against terrain and usually less than that for other entities, it's not half bad. Performance would probably go up significantly if something were written to handle this more properly in javascript too. And it's much faster than what I was seeing when using a canvas of the same size and checking rgba even when it wasn't obscured behind as many layers of events.

Sorry for the simplistic geometry in this example. I didn't want to spend all day coming up with a method for converting sprites to pixel mask points. I have an idea of how to do it by using a temporary canvas, but it shouldn't take away from the purpose of the demonstration regardless of that.

Now I know this form is old, but I couldn't find anything else to fit.

If your looking for a compelling case (to the creator of scirra) I have one.

I am re-creating a limbo-type level, and the terrain is compiled in a single image (1920*8000pi). This was the best method to design limbo terrain after much research. Originally attempting 2D in Blender3D BGE it just didn't work out so I turned to my long-time used engine of Construct 2. I looked for an option for HD Collisions but I couldn't find it, so I looked up and I found this.

Sure, I understand performance issues, but with High Resolution terrain that your only rendering a certain portion at a time, this sort of thing is NEEDED. It would take me a very long time to do each point by hand, and especially since that covers an entire level. So correct collisions are needed, and in the past your engine has done them better than me.

I just ask that maybe there be an option for "HD Collisions" with a Warning so users know what they're getting into.

I agree per pixel collision would be welcome. Ability to draw collision masks on layout would be also welcome. Ashley I absolutely understand why you are not convinced to do those things, but those are modern days standards in game development. In c2 we do can make walk-arounds for simple things, but in more complex situations everything tends to get super complicated and fall apart. And I personally would expect engine to take care of those things, as I was mentioning multi-level collisions, push out of solids etc. Those all would be extremely welcome for everyone. Our gamedev would become much shorter and more good games could come out.

dilk

The simplest way to do it would be to fill a tilemap with a duplicate of your collision mask.

To do this you'll need a tilemap with a 1x1 tilesize that covers the area of your collision mask image. It's only for collision detection so it can be invisible.

Next you'll need a canvas object with the collision mask as its image.

Then at the start of layout use two for loops to loop over every pixel. Use a system compare with canvas.alphaAt(X,y) to read the alpha of the pixel. If it's say >128 then set a tile on the tilemap at the same position.

At the end of it the tilemap will be ready for collisions and all behaviors can interact with it. It can take a while to do, so as a speed up you could save the tilemap as json and use that in your actual game.

I am re-creating a limbo-type level, and the terrain is compiled in a single image (1920*8000pi).

We strongly recommend against designing games like this. See remember not to waste your memory. The memory use will be very high, and an image that large will not even load on systems with a maximum texture size of 2048x2048 or 4096x4096.

You don't need to design the collision mask point-by-point for an entire level like that. Just create some collider objects which are invisible sprites with a simple shape (e.g. triangle, rectangle, etc) with a matching collision mask. Then you can design the collisions for your level in the layout view by arranging those objects. The collision cells optimisation keeps this fast regardless of how many collision objects you have scattered across the level.

Given the high complexity of the per-pixel collisions feature, I really don't want to have to support that. As I said earlier in the thread the implementation complexity is very difficult, it has high performance and memory overheads in some cases, it was an ongoing source of bugs and crashes in Classic, it would be even more difficult in C2 (since there is a new poly-to-pixel-mask case), and every new collision feature exponentially increases the types of collision interaction that must be supported, effectively ruling out ever adding any other new collision features. I really think it's best to stick to polygons. AFIAK, that's how all 3D games work anyway - I don't think many games use voxel collision masks (which would be the 3D equivalent) - and if polygons are good enough for 3D...

If you need a precise collision mask for an object, in my point of view, you can use two or more simple shapes connected together. For example you can have a big robot character with iron fists, iron feet, a heart and a head; you can attach 6 objects to a really complicated shape that for sure needs a lot more collision points. In this way, you can also focus on curved areas more effectively.