Normal angle of a sprite at different positions

This forum is currently in read-only mode.
  • Can we expect vector-based collision masks at some point? Or a polygon object? There would be a ready polygon editor with the physics behavior .

    exists already, its a custom collision mask

    [quote:8bjkiais]To be honest I gave up on this angle fairly quickly after I realised there was no way it was going to be simple and there is obviously a better way. Didn't think to do it for per axis like that though, so thanks for that

    I'd quite like an idea of how to find this elusive angle because I find it interesting, and I've not been able to come up with anything at all.

    i did mention what ashley was saying, although i dint really word it correctly, the part when i said push the object back the way its came,what ashley said is what i meant i problly should of said it clearer though.

    and ashley

    [quote:8bjkiais]The way normals can be calculated is by moving objects in a circle. If a ball, say, has collided with the edge of an arbitrarily shaped sprite, you can move the ball out by a radius (16 pixels works OK) and then collision test in a circle (say, at 4 degree intervals). By working out the average angle of the overlapping angles, you can calculate the approximate angle towards the surface, and inverting this gives you the normal.

    ive tried something similar to this in a gear collision engine which i made (i checkerd for overlap every tick, and then once it caught one it would sping the gear using a loop and would stop spinning after it was not colliding or finished a 1 tooth increment movement), 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

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • 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...

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)