Collider Object

Here my proposal for the "Collider Object": just like the sprite object, with the difference that it stores in the memory only a monochromatic form.

Making colliders with the sprite object it's a waste of memory, since the informations about the aspect of the object are stored as a bmp, while the object will never actually appear in the game.

That's practically unrelevant in case of, i.e., a platform game character, but it could become essential in case of a beat'em up: several big characters, each with its ows colliders -> fighter's memory occupied doubles (and in that case we talk about several MB).

It could also be used for defining areas, as it can do Overlay object in MMF (i.e. where in the point-and-click adventure the character can walk; different terrain reactions on a golf game, and so on...)

Hope I made the point clear enough. It would increase efficiency in Construct (and solve some dramatic cases, like in the Beat'em up example). Why to store useless .bmp graphics when using colliders & similar? <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" />

What you're suggesting, if I'm understanding you correctly, is a sprite with a black and white image. I think a better option than a whole new object is being able to reduce the color depth of an image, so it uses less memory. That way, a whole new object is not needed, and it helps people optimize the application by only using as many colors as there are in the image.

..maybe a "collider" checkbox? Mmm...

Memory usage today is practically an irrelvant problem. I cannot imagine any 2D game that is working correctly that would use up all the memory of a modern system. Also, Construct tests collisions on the CPU with system memory - not GPU - and generates monochromatic bitmasks for collision testing. So it only uses one bit per pixel anyway which uses a negligable amount of memory (a 100x100 image's bitmask will be 9-10kb of system memory). If you have 1gb of RAM you can hold 100,000 unique 100x100 bitmasks. It's not a problem, something else will fill memory first.

Yeah you waste a little bit of VRAM but that's fast becoming a similar situation. You could reduce colour depth, but mixing colour depths with textures on the GPU actually requires a lot more processing - textures first have to be converted to a common format before you can do anything with them - so counterintuitively, using a lower colour depth will completely hamper performance at the saving of a small bit of memory when it's doubtful you were even anywhere near capacity.

However, an object which can define custom regions with a texture for zone testing and such could come in handy... on the wishlist I guess.

What you say it's right, but I was actually talking about game size.

If my beat'em up has, say, 20mb of fighter's sprites, with colliders that space would simply double. Same (or even worse) would be using huge bitmap zones for the golf game: totally unefficient, with reference to the executable size.

98% of things made in Construct will be DOWNLOADABLE games. And in downloadable games, file size really matters. 20mb more or less it's not a joke at all.

Construct saves images in PNG format so a simple two-colour mask would compress away to next to nothing.

ooo ... score 1 for Ash and Construct! 0 for PNG size!

sorry, had to say it XD

My very pleasure to be beaten such way <img src="{SMILIES_PATH}/icon_cool.gif" alt="8)" title="Cool" />