Checking against a mask for collision at just one pixel is just a single yes/no check against a value in an array (and yes, there are probably more clever algorithms out there involving collision masks). The reason it works is only because you have a limited number of pixels to check with.

For doing something like platform movement, you only realistically need to check maybe 6 or 10 pixels for a single sprite to be able to reliably say if you have a collision going on against the collision mask and you'll generally know more about the collision than if you simply did a check against a collision polygon.

I was searching through the forums looking to see if there were any plans to implement precise collisions and was a little flustered to find that the primary concern here was performance. A lot of types of games though require a significant amount of different types of level geometry and to put it bluntly, polygonal collision is often inadequate for these purposes and computationally expensive to use for level geometry anyway (since you have to perform lots of additional checks as your level geometry expands). If you have large amounts of static solids, you can simplify collisions significantly by applying a collision mask and checking collisions at a single point (8 or so single point collision checks should be perfectly adequate for most platform game character movement systems for instance)

Now, I understand that doing full collision meshes for sprites is a problem. It makes perfect sense why collision polygons would be preferable for that, but for level geometry such as for a platform game or an overhead adventure game, I would suggest that polygonal collision can actually be very expensive compared to doing collision against a mask... especially if you only need to check the collision at a single point. When you have large quantities of unmoving sprites that you can depend on staying in the same place all the time, you can simply throw every collidable pixel into a 2d boolean array with memory needs at one bit per pixel. That can actually add up rather quickly...

So anyway, I have a feature I'd like to suggest and you all can feel free to use it or not, whatever floats your boat really. I won't be offended.

Collision Mask Object - Can make a collision mask out of all sprites on a given layer

has the following properties:

int resolution

somewhat complicated... but since even at one bit per pixel collision masks for modern high resolution games could be really expensive it would be useful to be able to skip around a bit. When converting geometry using a resolution value of 2 for instance, only every other row and column of a sprite would be read into the collision mask. Meanwhile collision checks would be divided by two on each dimension.

Provides the following functions in the event editor:

boolean checkCollision(int x, int y) //pretty self explanatory right?

As for actually generating the collision mask... I'm not sure how it should work exactly. Assigning objects is a bit of an implementation decision, but I imagine the most convenient way to do it would be to have all of your collidable sprites on a single layer and have a tool for generating the collision mask from the sprites in the scene editor when the collision mask object is selecting. Then it could dump the collision mask into some manner of blob.

It might be useful to also have the collision masks automatically be subdivided so that large clusters of empty space don't need a full set of collision data. All sorts of optimizations could be made on that end of course. Subdivisions could be full collision, full non-collision, or point to a blob mask to save memory at the expense of computation time.

So implementation details aside, this really is a feature that I think is going to be somewhat necessary for a lot of people and I think C2 would really benefit from having something like it.

Ugh. Just ugh. Do you really not comprehend the purpose of a function limited demo? Killing the free version would destroy the entire market for the product. People don't buy software like this without trying it first.

And 100 events is bloody near useless for making anything more complex than a tech demo or a really simple flash-style game. Serious users can not make due with the free version so this idea that there are free-riders out there mooching off of Scirra for their own benefit is a farce.

Thanks for the expedient response and useful information.

Note: This has been a problem for a while. R81 just indicates that it's still a problem in the current build.

A couple others and myself have been playing with Construct 2 a bit and ran into a bit of an odd behavior with events that may or may not be classified as a bug... but regardless it's less than desirable for what we are trying to do.

Suppose we have a sprite object with variables to track control in the following manner:

sprite.up = 0

sprite.up_pressed = 0

And then we have an event at the beginning of the frame as follows:

System.Every Tick
    sprite.set(up = 0)
    sprite.set(up_pressed = 0)

Keyboard.Up arrow is down
    sprite.set(up = 1)

Keyboard.Up arrow pressed
    sprite.set(up_pressed = 1)