Sorry your browser is not supported!

In my game I have an animated sprite where its shape varies quite considerably (it's an animal that lashes out at the player).

In order to have sufficient collision detection I have to update the sprites' shape every frame. Without doing this sprite collision detection is very poor. The result of this, however, is a frame rate drop of ~20 FPS which looks terrible.

I was wondering if:
a) anyone had ran into this problem before and if so, how did you solve it,
b) if TGC had considered giving us the possibility of pre-drawing the physics sprite shapes so that updating the sprite shape didn't need to be called each animation frame?

Thanks

I believe that his is pretty expected behaviour since there are quite a bit of calculations needed to get the shape. But there may be a way around it...

The command SetSpritePolygon Can be used to set a predefined shape.

However, you would need to add the shapes yourselves since there does not seem to be a way to get the polygons from a predefined shape.

I have used the same method in projects before. I only noticed slow down if a lot of sprites were being updated. I just made sure I didn't have too many sprites changing their shape. Also, you can reduce the amount of points the shape uses, but obviously on a complex shape this will be no good to you. Are you getting slow down with just one sprite?

As a solution, could you not use a number of sprites with roughly the same size and let them represent the animial?

Ok I implemented a solution inspired by max such that I have 1 main sprite showing the animation and I create individual sprites for each frame of the animation, each with their own physics shape. For the melee attack of my animal that's a total of 18 sprites. 17 of which are not animated and are invisible.

When attacking I correct the position the sprite corresponding to the animation frame and check its collision with the player.

It works and I no longer get any lag, but I think the solution is not very elegant. I am going to suggest a feature request to TGC such that when you assign an animation image to a sprite and update its shape that the shape is precalculated for all frames. This would make sprite management so.much more easy and has a very positive performance boost.

It's probably the fact that it has to scan the whole image and built a frame around it with as few lines as possible. That's never gonna be quick.

My first thought is the same as yours, to have lots of pre-calculated sprites, but I have an alternative as well.

You can set the polygon shape yourself with raw data. Like - say you took note of the lines you need on the sprite, like a sequence of XY coordinates. Well, you could delete the physics shape when the sprite frame changes, then re-apply your own collision shape. That should be much much faster than letting AppGameKit do it itself - and it would lend more control as well - like, having a base line that doesn't move, for platform collision for example... just the sort of thing that might mess up if you change the shape automatically - like a shape could be created that already intersects other sprites, not ideal.

I've been meaning to write an editor for manually setting physics shapes - any sprites that need it will tend to be on a sprite sheet - so really it's the only way apart from sticking to box or circle collision. The way that AppGameKit specifies the shape is quite straightforward - I've even used it to make a 2D planet terrain with hundreds of segments, no issues at all. I did this with DBPro years ago, making a 2D shooter - I just had a big array full of the 2D coordinates and an index - so for a specific image number, I find it in the index which tells me where in the coordinates array to start building the shape.

This obviously takes a bit of planning, but I think it's well worth doing - it'd save you a lot of headaches and free up your games resources - no need to have a copy of every collision enabled frame in your project.

Also - only change the frame if it's actually changing. Like, store the current frame, then only change it if the new frame is different - that way you won't be updating frames that don't need to be updated.

I had this issue with dFenz...
What I ended up doing is skipping so many sync() frames before updating the shape.
So if the animation has 12 frames then I'd make sure to only update the shape every 5 sync() calls (at 60FPS). It helped a lot, but I did have to drop it.
Van B is mentioning a similar method.

Also if you manually set the shape it is much less CPU intensive than having set sprite shape do it on its own. And the fewer the points of the polygon, the better. Not sure if Circle is better than squares/triangles though, but it might be since I think it only requires 2 measurements for the boundaries.

hmm interesting stuff here i just came up with an even simplier solution...


lets say you have a very complex character , this character posses a shield and a sword.

you use 2 sprites , 1 for ground collision just static collision..
and another for the Sword and Shield.. yeah.. you dont need 2 , 1 is enough.

my method is to switch everytime the 2nd sprite , once shield and set its image to the sheild image , check collision do what ever...

then just a few lines after
change the 2nd sprite to the sword and change its image to the sworkd image , reposition on the x,y with the most accurate offset you can , then check for collision again only that this time it will "act" as the sword...

if 2nd sprite collision on now it ment that now the character's sword hit something...

i always try to keep as less sprites as i can both for display and collision but keeping the visuals the same as much as i can .. and somehow i always get 100 percent visuals but the collision i get is about 85 - 95 percent accurate which is good not perfect and it runs fast enough.

also dont forget that if your not doing a realistic simulator of somekind... most users wont even notice if its 90 percent accurate collision as long as it will be fun to play... like most ppl dont really care about the tech stuff... the visuals today are more important.. so.. just keep that in mind.