LÖVE

Posted: **Sat May 24, 2014 10:16 pm**

I recently got a laptop for doing programming away from home (for the record, a Fujitsu Lifebook, I think p1620, not sure. It's running Windows 8).

For the most part, it's served me well, and I've made a satisfying amount of progress on general design for my platformer project, but, unsurprisingly, drawing graphics is rather slow, and now I'm getting to the point where... significant amounts of graphics are being drawn.

Right now, I'm wondering what general advice can be given on improving graphics performance in LOVE, not necessarily for this project specifically (I've got a couple of other games being fleshed out in my head). At some point, I'm going to take advantage of spritebatches, but unless they're liable to have a great effect, I'd rather put it off until I've got the game's general structure and resource handling better figured out.

What I don't understand is, the game's logic isn't much a problem (removing the draw loop cuts the performance cost of a single enemy instance to under a tenth), and reducing the size of the main character sprite (obviously by shrinking the source image, but dynamic scaling works almost as well) has a very noticeable effect on framerate. So much so that I doubt that I could draw just 640x480 pixels in a single call at 30fps, let alone a scrolling background which extends beyond the screen with at least a dozen objects on top of that... although I haven't strictly tested this yet, and plan to do so later.
As it is, I'm worrying that I'll have to a. abandon LOVE, write code-in-progress in lua and gradually convert portions into c++ as they're finalized, b. reduce the resolution, which means a significant change in visual style and/or gameplay, or c. just move development to my desktop (which means drastically less development time in general).

Posted: **Sat May 24, 2014 10:31 pm**

First of all: You did a good job at finding, what slows down your program. Many people, when trying to optimize their code, do not check beforehand, if they really found the bottleneck and then optimize the wrong part.

Spritebatches will almost surely speed up your drawing. As a rule of thumb, always try to minimize the number of love.graphics.draw-calls. With a Spritebatch you can remove all the drawing-calls for the objects and replace them by a single call.

Just in case you are really using assets in very different zoom-factors, you might want to have a look at the mip-mapping functionality of LÖVE. Implementing Spritebatches is more important, though.

And last, could you post a screenshot of what you are currently rendering? I would like to see, how many objects you have on screen.

Posted: **Sat May 24, 2014 10:35 pm**

A .love would also help us figure out what is slowing it down so much. That is, if you feel comfortable sharing your code.

Posted: **Sat May 24, 2014 11:57 pm**

First of all: You did a good job at finding, what slows down your program. Many people, when trying to optimize their code, do not check beforehand, if they really found the bottleneck and then optimize the wrong part.

My actual skill is behind what it should be (I've never been much a problem solver), but I have been programming for several years, and I've done a disproportionately large amount of reading and learning to that.

That said, I sure as heck will prematurely optimize anyways.

Yeah, problem-solving skills aside, I'm majorly lazy and undisciplined.
The only reason I benchmarked was for curiosity's sake, since I had already assumed that graphics would be my major bottleneck. I just didn't anticipate how big the difference was.

Spritebatches will almost surely speed up your drawing. As a rule of thumb, always try to minimize the number of love.graphics.draw-calls. With a Spritebatch you can remove all the drawing-calls for the objects and replace them by a single call.

"speed up" is one thing, "be a very significant component of bringing the speed to acceptable levels" is another.
As it is, I'm talking about drawing an enemy population in the range of 1-5, and as mentioned, just changing the size of the player, a single sprite, has a noticeable effect on performance.

Of course, this is the kind of thing I should be testing for myself. I'll try to get myself to work on it in the morning. Still, I figured it's worth mentioning in case anyone has anything to say about spritebatching that I might not know.

Just in case you are really using assets in very different zoom-factors, you might want to have a look at the mip-mapping functionality of LÖVE. Implementing Spritebatches is more important, though.

So far as I can anticipate, I won't be using graphics-scaling in the end-product - that was just a momentary workaround for the fact that my graphics weren't scaled small enough on export. I'm better at drawing than I am at pixel art, so the source graphics are much higher resolution than will be seen in-game.

And last, could you post a screenshot of what you are currently rendering? I would like to see, how many objects you have on screen.

A .love would also help us figure out what is slowing it down so much. That is, if you feel comfortable sharing your code.

I'll try to throw something more informative together in the morning, but at the moment, I prefer to keep everything as under wraps as possible, partly because I've announced a lot of incomplete projects in the past (back when my creative platform was Starcraft, before I was programming), and partly because... I dunno. Sorry.

I know that I'm not being the most helpful at being helped, but oh well. I'm certainly not holding anyone to anything.

Posted: **Sun May 25, 2014 2:12 am**

Garbeld wrote:At some point, I'm going to take advantage of spritebatches, but unless they're liable to have a great effect, I'd rather put it off until I've got the game's general structure and resource handling better figured out.

Aside from making sure you aren't doing anything silly (creating images or other LÖVE objects every frame, for example), taking full advantage of spritebatches will usually have the most effect out of anything.

Garbeld wrote:reducing the size of the main character sprite (obviously by shrinking the source image, but dynamic scaling works almost as well) has a very noticeable effect on framerate.

What's your code you're using for drawing? How big is the image? How many times are you drawing it in a single frame? Does the no-game screen run well or poorly for you?

Garbeld wrote:So much so that I doubt that I could draw just 640x480 pixels in a single call at 30fps, let alone a scrolling background which extends beyond the screen with at least a dozen objects on top of that... although I haven't strictly tested this yet, and plan to do so later.

Most LÖVE games do just that with no performance problems (on your average desktop or laptop, at least.)

Garbeld wrote:As it is, I'm worrying that I'll have to a. abandon LOVE, write code-in-progress in lua and gradually convert portions into c++ as they're finalized, b. reduce the resolution, which means a significant change in visual style and/or gameplay, or c. just move development to my desktop (which means drastically less development time in general).

Without knowing the code you've written I can't say exactly where the performance problems are coming from, but rewriting everything in C++ probably won't help at all because the bottlenecks are almost always in how the tools available are used, rather than in what the tools are.

On the other hand, that laptop is really old (2006-era hardware) and extremely low end even for its time. It has an integrated Intel GMA GPU, which is less powerful in a lot of ways than phones from several years ago.

Posted: **Sun May 25, 2014 9:51 am**

It might be your OS too.. I got a comparable laptop (actually even weaker, checked the p1620 specs) and I don't discover your problems. I will probably earn not much understanding when I suggest to upgrade Win8 to WinXP, but some Linux should work. Before all this it should be made clear that the OS is really the problem, ofc. Did you check other löve games? vapor.love2d.org has a big collection (you maybe need 0.8.0 then).

Posted: **Sun May 25, 2014 12:50 pm**

I tested the performance by writing a simple program, since I was doubting the loves performance.

On my computer i managed to get roughly 13k 32x32 pixel squares per frame on 32 bit love and around 19k squares on 64bit one.

Warning: This might not be pleasant for epileptic people to watch.

Posted: **Sun May 25, 2014 3:31 pm**

Are you running the newest drivers ?

Posted: **Mon May 26, 2014 11:43 pm**

Okay, so I made a little test thing. It prints dt for each frame in the top-left corner, as well as which test is running (see the code to figure out what each number represents). Pressing q cycles the test type.

On my desktop, I'm getting ~1000 fps.
(Using an updated version without vsync. Attached version, the one I used on my laptop, has vsync still enabled. They're identical, otherwise.)

My laptop's consistently getting a dt of ~0.118-~0.126 per frame, 7-9 fps, across the different tests.
The order of rank for the tests was about what I'd expect, with more calls etc. being slower, but only very, very slightly. When I had it calling love.timer.getFPS() instead of printing dt, most of them were impossible to distinguish between, or could only be differentiated by trying to guess which test causes the 8 to flicker into a 7 more often.
The only exception is that the love.graphics.rectangle() calls performed significantly faster (10-13 fps), which I wouldn't have expected.

(Before this version, I tried one or two tests not seen here while at work, but they had similar performance anyways)

In case anyone can't/doesn't want to download/can't use the attached love file, here's the code:

Code: Select all

--conf.lua

window = {}
window.w = 640
window.h = 480

function love.conf(t)
  t.identity = nil
  t.version = "0.9.0"
  t.console = true

  t.window.title = "Nothing"
  t.window.icon = nil
  t.window.width = window.w
  t.window.height = window.h
  t.window.borderless = false
  t.window.resizable = false
  t.window.minwidth = 1
  t.window.minheight = 1
  t.window.fullscreen = false
  t.window.fullscreentype = "normal"
  t.window.vsync = true
  t.window.fsaa = 0
  t.window.display = 1

  t.modules.audio = true
  t.modules.event = true
  t.modules.graphics = true
  t.modules.image = true
  t.modules.joystick = true
  t.modules.keyboard = true
  t.modules.math = true
  t.modules.mouse = true
  t.modules.physics = false
  t.modules.sound = true
  t.modules.system = true
  t.modules.timer = true
  t.modules.window = true
end

Code: Select all

--main.lua

local fps = 1/30
local fps_buffer = 0

function love.load()
  big = love.graphics.newImage((function() a = love.image.newImageData(640,480) a:mapPixel(function() return 255,255,255,255 end) return a end)())
  small = love.graphics.newImage((function() a = love.image.newImageData(32,32) a:mapPixel(function() return 255,255,255,255 end) return a end)())
  small:setWrap("repeat","repeat")
  small_sb = love.graphics.newSpriteBatch(small,20*15)
  small_q = love.graphics.newQuad(0,0,640,480,64,64)
  small_sbq = love.graphics.newSpriteBatch(small,1)
  small_sbq:add(small_q)
  mesh = love.graphics.newMesh({{0,0,0,0,255,255,255},{640,0,0,0,127,127,127},{0,480,0,0,127,127,127},{640,480,0,0,0,0,0}},small,"strip")
  for x=0,19 do
    for y=0,14 do
      small_sb:add(x*32,y*32)
    end
  end
  mode = 0
  d = 0
end

function love.update(dt)
  d = dt
end

function love.draw()
  if mode==0 then
    love.graphics.draw(big,0,0)
  elseif mode==1 then
    for x=0,19 do
      for y=0,14 do
        love.graphics.draw(small,x*32,y*32)
      end
    end
  elseif mode==2 then
    love.graphics.draw(small_sb,0,0)
  elseif mode==3 then
    love.graphics.rectangle("fill",0,0,640,480)
  elseif mode==4 then
    love.graphics.draw(mesh,0,0)
  elseif mode==5 then
    for x=0,19 do
      for y=0,14 do
        love.graphics.rectangle("fill",32*x,32*y,32,32)
      end
    end
  elseif mode==6 then
    love.graphics.draw(small_sbq)
  end

  love.graphics.setColor(0,0,0)
  love.graphics.print(d,0,0)
  love.graphics.print(mode,0,16)
  love.graphics.setColor(255,255,255)
  love.graphics.print(d,1,1)
  love.graphics.print(mode,1,17)
end

function love.mousepressed(x,y,button)
  
end

function love.keypressed(key)
  if key == "q" then
    mode = mode+1
    if mode > 6 then mode = 0 end
  elseif key == "escape" then
    love.event.quit()
  end
end

but rewriting everything in C++ probably won't help at all

Yeah, a few hours after I posted that I realized how nonsensical that was. I think that idea was the result of trying to reconcile my observations with fallacious assumptions.

That said, I am confident it can draw faster than is happening here. I'm going to running a few games on it.

Posted: **Tue May 27, 2014 12:01 am**

Garbeld wrote:That said, I am confident it can draw faster than is happening here.

Yeah, that's pretty weird. What does [wiki]love.graphics.getRendererInfo[/wiki] output? There's a chance that Microsoft's OpenGL software renderer is being used instead of your video card.

E.g.

Code: Select all

local info = string.format("Name: %s\nVersion: %s\nVendor: %s\nDevice: %s\n", love.graphics.getRendererInfo())

print(info) -- If you set t.console = true in love.conf, then this will output to the console.

function love.draw()
    love.graphics.print(info, 2, 2)
end

LÖVE

LOVE performance (framerate)

LOVE performance (framerate)

Re: LOVE performance (framerate)

Re: LOVE performance (framerate)

Re: LOVE performance (framerate)

Re: LOVE performance (framerate)

Re: LOVE performance (framerate)

Re: LOVE performance (framerate)

Re: LOVE performance (framerate)

Re: LOVE performance (framerate)

Re: LOVE performance (framerate)