using fast loops and one problem arised, it has to be very precise to work properly, meaning it needs to check every pixel step, and it lags the system having to do all of these checks, also if something gets too far lodged into another object it would run a continuous loop
Yes, you have to do a lot of collision checks - doing this with the interpreted event system isn't going to be anywhere near as fast as the C++ implementation in the Construct runtime. Maybe it could be a system expression.
Still, I like the idea of all objects having an editable 'hull' - a polygon you can draw around it. Both Physics and the dynamic lighting engine need a polygon instead of a bitmap mask and it would save you entering the same polygon twice. And a 'vector' collision alternative for Sprites could actually be fairly handy, but that's less of a priority. Animated sprites would make this a little trickier though... maybe it should be in the picture editor...