> Regarding the polygon object suggestion. Didn't Construct Classic support pixel based collisions, couldn't the code for that be ported?
>
> I know it was more of a "hack" back then but I guess if it works, it works.
That's why we have polygon, per point is way too slow for html5.
I don't think that's the case any more, especially with WebAssembly. The main reasons for polygon collisions are:
- it's simpler
- easier for user to edit
- likely faster than per-pixel checks (regardless of implementation)
- other parts of the engine need a polygon e.g. Physics & ShadowLight, so you need a polygon anyway. So you may as well use the polygon for collisions too.
- per-pixel collision was extremely difficult to get right in Classic - lots of difficult bugs, even years down the line when we thought it was mature, and often the bugs crashed the game or corrupted memory
- if there are N collision systems, you need N^2 algorithms, because every type of collision has to be able to collide with every other type of collision. Adding new collision types becomes exponentially more work, which is a very good reason to only support one, or the very fewest possible. (E.g. if you add per pixel collisions, we'll also need poly-pixel intersection tests, which means rasterising polygons to a bitmap... lots of tough code to write there, and carries opportunity cost accordingly)
- I've always asked for, but never seen, a convincing case where something really definitely needs per-pixel collisions and just can't be done with polygon collisions. So as far as I can tell polygon collisions are perfectly sufficient for game design purposes.
As is typical with designing complex software, there's a lot more to it than performance or "just port the old one".