FRAME RATE

Getting Started Newbie Questions
#1

I’m spent the last month learning Corona SDK and brushing up on programming. Just a quick question about something that’s been nagging me.

I implemented two different ways to load my ENEMY for my game…

Implementation A… I load & create ALL then enemy one time before the game starts and keep all 75 enemy in an array  and set all the obj.isVisible = false. When I spawn or kill an enemy I just update obj.isVisible , I never destroy it from memory, ever. At least until the level is over.

Implementation B … I don’t load any enemy into memory before the game. I  create the enemy on the fly, as needed in a table. When I spawn then enemy I create it… when the enemy dies I delete it from memory and the table via obj:removeSelf() ob = nil… so I dynamically keep the enemy in memory during the level.

Implementation A works freakin great, never a problem with speed or anything

 Implementation B  works fine AT FIRST then the frame rate gets sluggish then slows down to a crawl and stops completely… ugh.I checked the memory usage for memory leaks… it goes up maybe 200MB if at all

The question is WHY does Implementation B slow the game down. Why does it not work as well as Implementation A.

Any ideas??

#2

200 MB is not small ammount

#3

It sounds like method B has a memory leak.  We can’t hemp much without seeing the code.

#4

I guess which Implementation is the best? Which way do professional companies do it? ? ? I discovered the memory leak--  its when I iterate through the FORLOOP and target enemies to kill. I can’t delete items from the table during iteration of the loop, so I make a SECOND table – when I make the second table equal to the enemy table I have memory leaks…

#5

As far as something works well I think that implementation doesn’t matter as far (unless it’s complete chaos :)).

#6

If your fully loaded method isn’t too much memory and if you’re constantly cycling them, then the first method is perfectly fine.  Loading images and creating new textures and objects to hold them and churning memory is CPU and GPU cycles.  It’s much faster to show and hide something already loaded.

But depending on the complexity and number of objects, holding them all in memory could cause other issues, but 75 small things shouldn’t be an issue.

#7

Thanks everyone for the advice :slight_smile:

#8

Other companies put objects into sprite sheets then just load the sprite sheet, from there you are simply accessing a already loaded image and do not take a memory hit. (well except for the actual imagesheet which is minimal)

#9

200 MB is not small ammount

#10

It sounds like method B has a memory leak.  We can’t hemp much without seeing the code.

#11

I guess which Implementation is the best? Which way do professional companies do it? ? ? I discovered the memory leak--  its when I iterate through the FORLOOP and target enemies to kill. I can’t delete items from the table during iteration of the loop, so I make a SECOND table – when I make the second table equal to the enemy table I have memory leaks…

#12

As far as something works well I think that implementation doesn’t matter as far (unless it’s complete chaos :)).

#13

If your fully loaded method isn’t too much memory and if you’re constantly cycling them, then the first method is perfectly fine.  Loading images and creating new textures and objects to hold them and churning memory is CPU and GPU cycles.  It’s much faster to show and hide something already loaded.

But depending on the complexity and number of objects, holding them all in memory could cause other issues, but 75 small things shouldn’t be an issue.

#14

Thanks everyone for the advice :slight_smile:

#15

Other companies put objects into sprite sheets then just load the sprite sheet, from there you are simply accessing a already loaded image and do not take a memory hit. (well except for the actual imagesheet which is minimal)