Framerate drops?

[gslender]

Hi,

I’ve added explosions to my game, and in the Android device, I get few minor pauses or dropped framerates when the explosions appear… which in code it is creating a display object, loading the image/spritesheet, and then playing the animation - nothing too amazing.

On the simulator and an iOS device, these little pauses do not occur - so I’m thinking it is an Android issue. I’m using build 1151.

I’m thinking I need to load and prepare the explosion image in advance, but this will be complex and possibly expensive considering I will need to prepare a bunch of explosions that won’t be needed for most of the time, and I’ll need to manage a queue to pull them off and play them… not nice but doable if needed. I also don’t know if this will solve the problem given I’m just assuming that is the issue, but obviously I see the pause occur just before the explosion - I guess it could be collision code, but I’d have to strip the explosion code out, test and try to see if that still causes the problem.

Is any of this a typical issue or is something else at play?

G

[SegaBoy]

Generating display objects at runtime is a costly process, particularly on low-end devices. Pre-loading is the way to overcome this; however as you said this will add complexity, possible redundancy, etc…

However this is the part I find the most rewarding and challenging - it’s all about working out the best way to overcome the problem, and particularly the solution often comes down to design patterns.

[gslender]

Thanks for replying. Does excessive texture memory impact performance on the device but not in the simulator? I’ve just noticed I’m hitting 15MB and peak at 19MB when the explosions are shown. G

[SegaBoy]

The simulator is based on the spec of your computer - so you should never judge performance from the simulator. I don’t believe this is a Texture Memory issue, more the performance hit of generating a display object at Runtime.

[Danny]

Create a pool of explosions, say 10 (or whatever), and preload them.

Then the best way to proceed performance wise is:

1. Show explosion at requested x/y position.

2. After explosion is finished, reset it’s properties (alpha, reset it’s frame to 0, etc)

3. When you need another explosion, do #1 again.

reusing objects rather than destroying and re-creating is the most optimised way of doing things. It may take a little longer to implement but it’s more than worth it.

[gslender]

Cool. Thanks guys.

I’m still puzzled why I don’t see this issue for all the other actors and bullets that are loaded the same way? It has only become noticeable since adding explosions, and thus why I’m wondering about texture memory.

I’ve been lazy and just loaded sprites from individual image sheets, and decided I’d fix them all up near the end, so it is possible I’m being really inefficient and hit some memory limit.

If I were to implement a preloading object queue code, I’d best also do it for the enemy actors and bullets too yeah? But yet I see no issues with them at this stage?

G

[SegaBoy]

Generating display objects at runtime is a costly process, particularly on low-end devices. Pre-loading is the way to overcome this; however as you said this will add complexity, possible redundancy, etc…

However this is the part I find the most rewarding and challenging - it’s all about working out the best way to overcome the problem, and particularly the solution often comes down to design patterns.

[gslender]

Thanks for replying. Does excessive texture memory impact performance on the device but not in the simulator? I’ve just noticed I’m hitting 15MB and peak at 19MB when the explosions are shown. G

[SegaBoy]

The simulator is based on the spec of your computer - so you should never judge performance from the simulator. I don’t believe this is a Texture Memory issue, more the performance hit of generating a display object at Runtime.

[Danny]

Create a pool of explosions, say 10 (or whatever), and preload them.

Then the best way to proceed performance wise is:

1. Show explosion at requested x/y position.

2. After explosion is finished, reset it’s properties (alpha, reset it’s frame to 0, etc)

3. When you need another explosion, do #1 again.

reusing objects rather than destroying and re-creating is the most optimised way of doing things. It may take a little longer to implement but it’s more than worth it.

[gslender]

Cool. Thanks guys.

I’m still puzzled why I don’t see this issue for all the other actors and bullets that are loaded the same way? It has only become noticeable since adding explosions, and thus why I’m wondering about texture memory.

I’ve been lazy and just loaded sprites from individual image sheets, and decided I’d fix them all up near the end, so it is possible I’m being really inefficient and hit some memory limit.

If I were to implement a preloading object queue code, I’d best also do it for the enemy actors and bullets too yeah? But yet I see no issues with them at this stage?

G