[solved!]Frame rate occasional lag

[IAsep-TrixI]

I've been working on a top down space shooter for quite a while, working on some basic mechanics to get it running.
I've come across an error in which sometimes when I run the game, it gets intensive frame rate lag.
Can anyone help me with this?
http://www.mediafire.com/?erarzd70c4yzee9
here's the link!
anyone on the interwebz are welcomed to answer

[Ranguna259]

FPS's good on my computer, thing is the bullets' image rotate even after they have been fired, make a table for each bullet with a fixed image rotation.

[DaedalusYoung]

I sometimes have this when LÖVE runs too fast. For example, I've made a simple program to make timelapses with, but if I run it as fast as possible, after a few frames, it starts lagging like crazy. I have to manually add a love.timer.sleep of 0.2 seconds, and every 60 frames, I let it sleep for a full second. It runs slower than possible, but if I don't do that, it will lag so much, it will slow itself down even more.

Also, harddisk starts going crazy at that point, which leads me to believe it is a memory issue. LÖVE's trying to do something in memory too fast for its own good, or something like that.

I've had it on my first project when trying to run it in 720p screen size, but that would run fine on 480p.

[IAsep-TrixI]

FPS's good on my computer, thing is the bullets' image rotate even after they have been fired, make a table for each bullet with a fixed image rotation.

I am trying to do that atm, but I think it is lagging because the inserted bullet tables arent getting deleted, I tried doing

Code: Select all

for i,v in ipairs(bullets) do
     if bulletDx = player.x + player.width + 50 then 
          table.remove(bullets, i)
     end           
end

but it somehow didnt work.Can you help on this?

[IAsep-TrixI]

I sometimes have this when LÖVE runs too fast. For example, I've made a simple program to make timelapses with, but if I run it as fast as possible, after a few frames, it starts lagging like crazy. I have to manually add a love.timer.sleep of 0.2 seconds, and every 60 frames, I let it sleep for a full second. It runs slower than possible, but if I don't do that, it will lag so much, it will slow itself down even more.

Also, harddisk starts going crazy at that point, which leads me to believe it is a memory issue. LÖVE's trying to do something in memory too fast for its own good, or something like that.

I've had it on my first project when trying to run it in 720p screen size, but that would run fine on 480p.

oh, so it doesnt have anything to do with my code? it's all love's fault? *awkward*

[Robin]

but it somehow didnt work.Can you help on this?

Well, you're going the wrong way to delete sequential entries in a table.

Code: Select all

for i = #bullets, 1, -1 do
     if bullets[i].x = player.x + player.width + 50 then 
          table.remove(bullets, i)
     end           
end

[DaedalusYoung]

oh, so it doesnt have anything to do with my code? it's all love's fault? *awkward*

Well, I'm not entirely sure about that, it looks to me that when I try to do a lot with images (since my system doesn't support Canvas, I need to make a new image every frame, until there's ways to manipulate the output screen directly, like copying, getting pixel data, etc), instead of just waiting until that's finished (and continue at a still reasonable 30fps), LÖVE keeps trying to maintain a high framerate and that makes the system go mad with too much memory operations. In turn sending the system and thus LÖVE to a crawl, but never able to recover, until you quit LÖVE (or make a pause system in the .love code).

[raidho36]

I haven't checked your code, but it looks like extensive garbage collector work issue. I'm entirely sure your code produces enormous amounts of garbage, and the GC needs to collect it time to time, and massive GC work causes your program to have severe lags. Make sure you reuse your data. Also note that string handling functions produce vast amounts of garbage.

EDIT:
Ok, I've checked the code and it doesn't looks like it has any kind of memory problems, although it doesn't removes bullets and they live forever. It runs fine on my PC.

[IAsep-TrixI]

I haven't checked your code, but it looks like extensive garbage collector work issue. I'm entirely sure your code produces enormous amounts of garbage, and the GC needs to collect it time to time, and massive GC work causes your program to have severe lags. Make sure you reuse your data. Also note that string handling functions produce vast amounts of garbage.

EDIT:
Ok, I've checked the code and it doesn't looks like it has any kind of memory problems, although it doesn't removes bullets and they live forever. It runs fine on my PC.

It should produce garbage, I just started I'm trying to get better though and also trying to remove any unnecessary code in my game

[raidho36]

I must be wasn't clear enough on that matter.

Lua is automated memory management language. It handles memory allocation for you, that is. And Lua specifically takes the whole responsibility for it, leaving you with bare nothing. Whenever you create any object, Lua automatically allocates memory for it. Deletion of the object is more complicated matter though, since Lua must know for sure you are actually deleted it. The trick here is that you can't manually delete anything, your best shot is to make sure there's no references to the object, so that to the app it's permanently lost. Nevertheless, the object is still exists in the memory, and now that you lost it, you can't do anything about it. In manual memory management languages this is called "memory leak" and is considered a serious design flaw, since such program would keep eating memory on and on until it finally crashes. In automated memory management languages, the language still keeps track of these objects; objects being in this state are considered no longer used - a garbage. Time to time garbage collector program would scan the memory for such objects and "collect" them, i.e. actually delete them from memory. This is a slow operation, and the more total memory used the heavier GC work payload is.

You may end up with garbage when e.g. you create a new table for a local variable and then discard it. And particularry, be careful with strings. String operations that create new strings (just about every single string function) may create a lot of second thought garbage, since you would i.e. only use string concatenation result and discard both of it's compounds, which are now garbage. This may create a lot of garbage very fast. The rule of thumb is not to create any temporary entities and keep them elsewhere as a static objects instead. Functions that would create tables for storing temporary data are the big sources of garbage, especially when called often.