Performance issue due to graphical assets

Getting Started Newbie Questions
#1

Hi, I have been developing an endless running game wherein I am spawning some obstacles above the screen and re-positioning them back to the initial position once it exits the screen below(the bounds are about 200 pixels above and below the game screen). I am certain that there are no inefficiencies in the code, the obstacles are recycled instead of repeated destruction and creation, at a time no more than 50 display objects are displayed during the gameplay. To elaborate, I am using a list, consisting of the obstacles that had scrolled down the screen and are available for reuse. I am creating and destroying all the lists of display objects accordingly and have no doubts in that.   

But even after cautiously handling the display objects I am facing issues while running the game in low-end devices. Whenever a sprite(especially when large in size) enters the screen, the device experiences a jerk, dropping the fps significantly and then regaining at once. Even though I am not sure what is causing these irregular jitters, but from what I have noticed so far it is predominantly noticeable when a heavy display object (eg. cluster of display objects) enters the screen.

Did anyone else face this problem? I am pretty sure there is a way to rectify this.

Please let me know some methods in corona which can be used to handle display objects in a better way.

Thanks

#2

Since you mentioned low-end devices, I don’t think this is a problem. Your way of handling the assets seems pretty good but you can’t overcome the memory issues for low-end devices. If those devices are too important for you, you can try creating and loading smaller assets for low-end devices.

By the way, can you give an example of how much memory you are using when the fps drop happens? Maybe there is something that can be done to optimize your assets.

#3

Thanks for the reply.The memory consumed by the game was 36MB at about 408Mhz clock cycle. Given the nature of my game, which is low poly and simple 2D running game, it should be working flawlessly. I don’t know why all these jitters especially when a heavy sprite is spawned. Also there is a very significant drop in fps when the game just begins, it then gradually increases. 

I hope there is some way of optimising display objects. 

#4

Hi @leokarun,

So you basically “pre-load” a cache of various game objects and then place them into the runner cycle when needed? That should eliminate the potential skip from on-demand loading large images, so I must ask, what else are you doing when you place the images into the runner cycle?

Brent

#5

This is a how long is a piece of string problem…  There could be many reasons why spawning assets might be slow (although 36MB isn’t really that heavy.

A big win for you could be to load your graphics into textures (in scene create) and drawing them on demand in your enterFrame(). Remember to use @1x images for low end devices and @2x versions on decent devices.  Do not expect high res images to work remotely well on entry level devices with limited VRAM and slow GPUs.

More info here - https://docs.coronalabs.com/api/library/graphics/newTexture.html

#6

Hi Brent,

 As said, I am using two lists of obstacles, one being the list of obstacles currently under use and the other being the pool of obstacles which have been scrolled out and are available for reuse. Hence I am first checking for the availability of the required obstacle to be spawned in the obstacle pool(list of reusable obstacles), if I find one spawn that obstacle and remove it from the pool otherwise, create a new obstacle object.

As for using textures I am not sure if it will work on the current system I am working in. Thanks for the inputs anyway I’ll still give it a shot. 

Not to forget, in the process of removing an object from the table I am using table.remove() function. It is given in the corona documentation that It may affect performance a bit. Can that be one of the reasons? If yes is there any alternative for table.remove()?   

Thanks

#7

I use table.remove() in our endless runner game but it doesn’t affect the performance in any visible way. I don’t think that is the problem.

There may be a problem with your enterFrame or game loop if the reason is not the assets. You may be running a loop more than you need or something like this.

I assume you don’t want to share the code so can you share a short video on how and where the problem occurs?

#8

Using textures should not affect your code massively.  You preload the assets into texture memory and simply draw on demand (which is really fast).  You can fill textures onto rects or you can use as a source for newImageRect.

My game has tens of thousands of display objects being drawn via textures.

Are you using a lot of masks, filters, emitters or shaders?  If they are all being recreated often that will cause a hit in fps on creation.

#9

Regarding table.remove()…  I assume you have a table of objects that defines your display hierarchy?

Instead of having a big table where index 1 is the back most tile and index 50 being the front most tile.  Why not have two tables?

The first table has 50 integers as each one is a pointer to a second table of objects.  The second table will remain static and contain things like index 1 = straight piece, index 2 = corner left, etc.

Then to control progress you simply change the pointers in the first table?  This way you are only moving integers in a simple table rather then trying to shift objects around in memory (with your current structure).  

This will perform much faster and might stop the stutter when you shift your current structure around on “add new piece”.

#10

Thanks man, will try using texture and see if there is any performance upgrade. I will try posting a video by tomorrow if the problem persists. Anyways thank you everyone for your valuable inputs.

#11

@leokarun,

Are you using physics, and if so, when do you add the physical bodies to objects? Do you add them “on demand” as they are placed back in the runner sequence, then remove the body aspect once those obstacles are placed back in the cache? Or do you add physical bodies just once, in advance?

Brent

#12

Since you mentioned low-end devices, I don’t think this is a problem. Your way of handling the assets seems pretty good but you can’t overcome the memory issues for low-end devices. If those devices are too important for you, you can try creating and loading smaller assets for low-end devices.

By the way, can you give an example of how much memory you are using when the fps drop happens? Maybe there is something that can be done to optimize your assets.

#13

Thanks for the reply.The memory consumed by the game was 36MB at about 408Mhz clock cycle. Given the nature of my game, which is low poly and simple 2D running game, it should be working flawlessly. I don’t know why all these jitters especially when a heavy sprite is spawned. Also there is a very significant drop in fps when the game just begins, it then gradually increases. 

I hope there is some way of optimising display objects. 

#14

Hi @leokarun,

So you basically “pre-load” a cache of various game objects and then place them into the runner cycle when needed? That should eliminate the potential skip from on-demand loading large images, so I must ask, what else are you doing when you place the images into the runner cycle?

Brent

#15

This is a how long is a piece of string problem…  There could be many reasons why spawning assets might be slow (although 36MB isn’t really that heavy.

A big win for you could be to load your graphics into textures (in scene create) and drawing them on demand in your enterFrame(). Remember to use @1x images for low end devices and @2x versions on decent devices.  Do not expect high res images to work remotely well on entry level devices with limited VRAM and slow GPUs.

More info here - https://docs.coronalabs.com/api/library/graphics/newTexture.html

#16

Hi Brent,

 As said, I am using two lists of obstacles, one being the list of obstacles currently under use and the other being the pool of obstacles which have been scrolled out and are available for reuse. Hence I am first checking for the availability of the required obstacle to be spawned in the obstacle pool(list of reusable obstacles), if I find one spawn that obstacle and remove it from the pool otherwise, create a new obstacle object.

As for using textures I am not sure if it will work on the current system I am working in. Thanks for the inputs anyway I’ll still give it a shot. 

Not to forget, in the process of removing an object from the table I am using table.remove() function. It is given in the corona documentation that It may affect performance a bit. Can that be one of the reasons? If yes is there any alternative for table.remove()?   

Thanks

#17

I use table.remove() in our endless runner game but it doesn’t affect the performance in any visible way. I don’t think that is the problem.

There may be a problem with your enterFrame or game loop if the reason is not the assets. You may be running a loop more than you need or something like this.

I assume you don’t want to share the code so can you share a short video on how and where the problem occurs?

#18

Using textures should not affect your code massively.  You preload the assets into texture memory and simply draw on demand (which is really fast).  You can fill textures onto rects or you can use as a source for newImageRect.

My game has tens of thousands of display objects being drawn via textures.

Are you using a lot of masks, filters, emitters or shaders?  If they are all being recreated often that will cause a hit in fps on creation.

#19

Regarding table.remove()…  I assume you have a table of objects that defines your display hierarchy?

Instead of having a big table where index 1 is the back most tile and index 50 being the front most tile.  Why not have two tables?

The first table has 50 integers as each one is a pointer to a second table of objects.  The second table will remain static and contain things like index 1 = straight piece, index 2 = corner left, etc.

Then to control progress you simply change the pointers in the first table?  This way you are only moving integers in a simple table rather then trying to shift objects around in memory (with your current structure).  

This will perform much faster and might stop the stutter when you shift your current structure around on “add new piece”.

#20

Thanks man, will try using texture and see if there is any performance upgrade. I will try posting a video by tomorrow if the problem persists. Anyways thank you everyone for your valuable inputs.