[Solved]Löve performance issues on Ubuntu/Linux ?

[clmj]

Hi everyone,

Currently working on a prototype game (something real simple), I'm encountering performance issues while testing my game on Ubuntu.
I draw a tilemap of 24 by 18 on screen and then my computer acts like I'm playing a triple A game on Ultra settings and the games gets framerate drops.
I first thought I did something wrong with the code but couldn't find what, everything seems perfectly normal, so I tested the game on a Windows partition and everything went okay !

Is Love2D getting performance issues on Ubuntu ? Is it known ? Can I do something to enhance it ? Am I missing something ?

Thanks in advance,
Clément

[veethree]

I’m not aware of any Ubuntu specific issues. I’ve used love on Ubuntu before without a hitch. Could you post your code?

EDIT: I did a google and found this: https://love2d.org/forums/viewtopic.php?t=8322

[clmj]

It was entirely my fault.
I missed something in my code

Sorry for the noobism and thank you @veethree for the answer !

Ubuntu rules!

[BrotSagtMist]

That is not how you close a topic, you have to explain what actually happened.
And if there is a possibility that the same code runs fine on windows but fails on linux i want to hear how that can happen.

[clmj]

The mistake here was that when I tried to loop over my map table using two nested For loops in order to draw the map, I forgot to remove an other loop wich was there earlier in the coding.

Bad code : (24*18)*(24*18) = 186624 objects per frame

Code: Select all

    for i = 1, pmap.width * pmap.height do
        for r = 1, pmap.height do
            for c = 1, pmap.width do
                tile = pmap.data[r][c]
                love.graphics.draw(pmap.tilesheet.image, pmap.tilesheet.tiles[tile], (c - 1) * pmap.tilewidth,
                    (r - 1) * pmap.tileheight)
            end
        end
    end

Good code : 24*18 = 432 objects per frame

Code: Select all

        for r = 1, pmap.height do
            for c = 1, pmap.width do
                tile = pmap.data[r][c]
                love.graphics.draw(pmap.tilesheet.image, pmap.tilesheet.tiles[tile], (c - 1) * pmap.tilewidth,
                    (r - 1) * pmap.tileheight)
            end
        end

So it was indeed messed up.
As to why it lagged on Ubuntu (wich was a normal thing) and not on Windows I can't tell you.

[BrotSagtMist]

So there was a loop doing 432 times the exact same thing, i could imagine an optimizer should kick in and disable this loop for you automatically.
So you really do have an issue on ubuntu, this optimizer does not work.

[slime]

So there was a loop doing 432 times the exact same thing, i could imagine an optimizer should kick in and disable this loop for you automatically.
So you really do have an issue on ubuntu, this optimizer does not work.

No, just because a loop calls a function with the same inputs multiple times, doesn't mean it's work that can be automatically eliminated. That would only be true for a small subset of possible functions. In this case love.graphics.draw does a bunch of non-redundant work (as far as it knows), it will just sometimes look the same depending on the image being drawn, blend mode, opacity, shader code, etc.

[pgimeno]

In fact, the optimizer has no information on what love.graphics.draw does, and can't assume that it has no side effects that alter an external state. And it would be right to not assume that, because two love.graphics.draw calls with the same parameters don't always produce the same results as just one, when the alpha of what's being drawn is not 0 or 1 but something in between. Try this:

Code: Select all

local canvas = love.graphics.newCanvas()
function love.draw()
  love.graphics.setCanvas(canvas)
  love.graphics.print("Hello, world")
  love.graphics.setCanvas()
  love.graphics.draw(canvas)
end

After a very short while, the text will look much thicker and sharper than a single `love.graphics.print("Hello, world")` because the alpha keeps accumulating. That's what happens when you draw the same thing repeatedly with the default blendmode.

Things would be different for other blendmodes, but again, the optimizer has no information on that.

[BrotSagtMist]

AN optimizer. I was more thinking of CPU or graphic cards driver magic. Could that be plausible?
But right, drawing is not really predictable.

[BrotSagtMist]

Actually scrap that, i thought on that again.
Yes it might not be able to eliminate the draw call but youre forgetting about the table lookups here which are indeed eliminated by jit and there are quite a bunch in that loop. They should be easily enough to halve its speed and tip that over the edge of lag.
Of course i doubt myself that jit is failing on his install, but it remains a plausible explanation.