performance too LOW!

[T-Bone]

Perhaps it's better to put it this way: if you need that kind of performance, then Löve is probably not the right tool to use.

[Jeeper]

I do not quite see what you want with this thread zzz654321. If you think that Löve has too low "performance" and think that something else is better, then by all means do use that.

There are a lot of big and ambitious projects that have been made in Löve that do not suffer from performance issues related to the framework itself.

[Muris]

I am guessing you do not use sprite batches, and without using sprite batches on drawing stuff I think it is quite useless test. I am almost sure that you are more likely gonna be bounded by your gpu rendering unit, than LUAs performance. Also saying that you have 5000 polygons on your phone and 5000 on cocos animated doesn't excatly tell what you're even measuring. 5000 draws per frame? Per minute? 60 frames per second?

With same note I do manage to draw 12k quads per frame on 60 frames per second on my phone with sprite batches, but even that is terrible for measuring performance, since it also depends on quads size. The thing is that most of the quads are discarded since they try to draw same pixel multiple times.

Maybe the whole topic is april fools joke?

[jjmafiae]

(I know some of these tips do not apply in this case but I listed all my tips anyway )

Performance tips:

1. only draw what's visible on screen (even if the the object isn't visible the GPU still process it, so do a check)

2. remove any unused object on screen

3. use LUA optimizations ( http://www.lua.org/gems/sample.pdf )

4. compressed textures can seriously improve performance (especially load times and VRAM usage) you can use this tool to do it: http://pnggauntlet.com/

5. if you have alot of CPU calculations multithreading might be an option (https://www.love2d.org/wiki/love.thread)

6. when checking FPS don't do as the wiki says:

Wiki method:

Code: Select all

function love.draw()
   love.graphics.print("Current FPS: "..tostring(love.timer.getFPS( )), 10, 10)
end

Correct method:

Code: Select all

function love.update()
   FPS = love.timer.getFPS( )
end

function love.draw()
   love.graphics.print("Current FPS: "..tostring(FPS), 10, 10)
end

7. also avoid using "love.graphics.setColor" inside loops if possible because it seriously cripples FPS

and a small note: I actually agree Löve could use some optimization HOWEVER it is far from unusable in most cases

[slime]

compressed textures can seriously improve performance (especially load times and VRAM usage) you can use this tool to do it: http://pnggauntlet.com/

Compressed textures are formats like DXT5. That tool just creates a PNG, which still has to be decompressed when it's loaded (it's not a Compressed Texture.)

when checking FPS don't do as the wiki says

Both of your snippets of code do essentially the same thing, performance-wise. love.timer.getFPS doesn't even do any calculations on its own, it just returns a variable, so it's one of the cheapest love functions to call.

avoid using "love.graphics.setColor" inside loops if possible because it seriously cripples FPS

setColor is also very cheap (although not quite as cheap as getFPS or getWidth / getHeight.) Calling it before a draw call won't have a significant performance impact, compared to not calling it.


The most important performance tip is to profile your code, and figure out where your bottlenecks are and whether you even need to optimize anything at all.
http://blogs.msdn.com/b/shawnhar/archiv ... guess.aspx

Synthetic benchmarks often don't tell you anything useful about how something will perform in real-world situations, since they tend to do things that would never happen in real-world situations.

[jjmafiae]

Both of your snippets of code do essentially the same thing, performance-wise. love.timer.getFPS doesn't even do any calculations on its own, it just returns a variable, so it's one of the cheapest love functions to call.

from my own testing my games ran faster after moving the love.timer.getFPS check out of love.draw()

[T-Bone]

Both of your snippets of code do essentially the same thing, performance-wise. love.timer.getFPS doesn't even do any calculations on its own, it just returns a variable, so it's one of the cheapest love functions to call.

from my own testing my games ran faster after moving the love.timer.getFPS check out of love.draw()

Did you perhaps modify love.run? If not, take a look at the default one: https://love2d.org/wiki/love.run love.update runs just before love.draw, once per frame, so it shouldn't really change anything by just moving the getFPS call from one of them to the other.

[Jasoco]

6. when checking FPS don't do as the wiki says:

Wiki method:

Code: Select all

function love.draw()
   love.graphics.print("Current FPS: "..tostring(love.timer.getFPS( )), 10, 10)
end

Correct method:

Code: Select all

function love.update()
   FPS = love.timer.getFPS( )
end

function love.draw()
   love.graphics.print("Current FPS: "..tostring(FPS), 10, 10)
end

Why? The cost for calling getFPS couldn't be that high. Plus you're still calling it every frame anyway. That's what it's for. Getting the FPS every frame.

[jjmafiae]

6. when checking FPS don't do as the wiki says:

Wiki method:

Code: Select all

function love.draw()
   love.graphics.print("Current FPS: "..tostring(love.timer.getFPS( )), 10, 10)
end

Correct method:

Code: Select all

function love.update()
   FPS = love.timer.getFPS( )
end

function love.draw()
   love.graphics.print("Current FPS: "..tostring(FPS), 10, 10)
end

Why? The cost for calling getFPS couldn't be that high. Plus you're still calling it every frame anyway. That's what it's for. Getting the FPS every frame.

Yes but the problem is before the call was in love.draw() which is not meant to do that kind of calls, anyway what matters is that it works and it does at least in my testing.

[Kingdaro]

Yes but the problem is before the call was in love.draw() which is not meant to do that kind of calls, anyway what matters is that it works and it does at least in my testing.

Just because love.draw isn't meant for game logic, that doesn't mean you can't do calculations in it. Your little second step there even adds more of a hurdle because it's setting and retrieving global variable every frame, since you're so hellbent on being a stickler for the smallest increases in performance. In fact, this is probably the fastest possible way to do it:

Code: Select all

local getFPS = love.timer.getFPS
function love.draw()
   love.graphics.print(getFPS(), 10, 10)
end

Localizing the function, and no string concatenation. But in end, Lua is still fast enough to where it doesn't even matter one bit and people should really stop making a big deal over simple things like this. Just make a goddamn game.