Optimization tips

[BlackBulletIV]

There doesn't seem to be a way to remove individual items from a Batch, would I have to clear everything and add them all back if I wanted to remove 1?

So so far it seems Sprite Batches are really good for things that won't move or get changed often, that don't need to be updated every frame.

Also, is there any way I can use canvases to speed things up even more? I keep thinking I could draw the backgrounds and static tiles onto a canvas, so that I only draw it once, and only redraw that canvas when I change anything, but then I could do the same thing with a sprite batch and update the sprite batch when I need to.

That's the trouble with SpriteBatches, you can't remove stuff. As of 0.8, you can modify entries, but still can't remove them.

I'm not sure whether canvases would be faster, but it would seem so, as it's like a single image. Besides, if you're drawing tiles, you can effectively delete and replace tiles by clearing a section of the canvas and drawing over the top of it, like this:

Code: Select all

love.graphics.setCanvas(canvas)
love.graphics.setScissor(x, y, tileWidth, tileHeight)
canvas:clear()
love.graphics.drawq(tiles, quad, x, y)
love.graphics.setScissor()
love.graphics.setCanvas()

[kikito]

Any general tips would be awesome

Beware of blind optimization. If you don't measure where your game is being slow, you might spend months optimizing the wrong thing.

[OmarShehata]

Any general tips would be awesome

Beware of blind optimization. If you don't measure where your game is being slow, you might spend months optimizing the wrong thing.

That is super good advice.

What methods do you guys use to determine what's slowing down your game? So far I've been slowing going around the game, removing chunks of code and seeing how it affects the fps.

[Jasoco]

It's useful to place some temporary debugging code that times how long certain parts of your code are taking. Using the following template:

Before a bunch of code:

Code: Select all

timeBefore = love.timer.getTime()

After a bunch of code:

Code: Select all

howLongItTookToExecute = love.timer.getTime() - timeBefore

This will return how long a section of code is taking. You can then either print it to the console or use some debugging printing in the draw function to print out the values you are getting. For instance you can see how long your update takes vs. your draw. Or how long specific parts of the updating or drawing are taking individually by using different debug variables for the returned value.

Once you find out what's taking so long you can then work on making it faster.

[BlackBulletIV]

Be sure to check your FPS (frames per second) too. You can get the current FPS by calling love.timer.getFPS; you'll want to print it out to the screen. If you think something is a performance hog, run the game with it on and again with it off. For small things, you won't be able to tell a difference, but if it is big (such as an inefficient shader), it'll show. Be sure to turn V-Sync off when doing this; that way you'll be able to get over 60 FPS.

[Saegor]

...

What methods do you guys use to determine what's slowing down your game? So far I've been slowing going around the game, removing chunks of code and seeing how it affects the fps.

if remove some code before launching

by experience, i know that drawing is worse than calculating

[BlackBulletIV]

by experience, i know that drawing is worse than calculating

If you're talking about the performance of visual calculations versus logic calculations, it depends. It's that rendering is more draining in most games (especially modern 3D ones), though there are some which rely heavily on logic (advanced AI, for example).

[OmarShehata]

I was using the love's timer method a while ago, but I was always getting tiny values, or almost 0 that I thought it'd be only good for timing really large functions.

I gave it another go though, this time I made it take 1000 readings of the time and get the average. And I got some really interesting results.

...
by experience, i know that drawing is worse than calculating

It's funny because that's exactly what I assumed. I was shocked when I removed all my rendering code (basically getting a black screen with an fps counter) and still had just 25 fps, (this is with Vsync off, so I was expecting 500 fps).

So I did some tests, got some data and did some graphing.



"Time Taken" is the time for everything when a small level is loaded. "Time After" is after a big level is loaded.

You can see how both rendering and the update take about the same amount in normal circumstances, but when a big level is loaded, the update takes twice as long as the rendering.

You can also see that the red bars shoot up so high for things that involve objects. So my whole problem is that, the more objects that are in game, (not just on screen, in-game) the slower things are going to get.

I never thought my update could be slower than the rendering (and this big level doesn't even have hundreds of thousands of tiles, it's barely 2k tiles).

So I've come to the conclusion that I simply need to not update things that are out of the screen. And I added some code that checks if all objects are within the boundaries of the screen before updating anything. And despite checking every frame for every object if it's within bounds, I got a huge increase in fps.

So I guess now I just need to figure out the best way to know when to update which objects. So, quadtrees? Hilbert curves?http://blog.notdot.net/2009/11/Damn-Coo ... ert-Curves

Simply adding my stuff to a two dimensional array that I can access with Objects[x][y] and I wouldn't have to loop through everything?

[OmarShehata]

Also some pie charts because I really wanted to make a pie chart.

[slime]

Use love.timer.getMicroTime instead of getTime for performance timing.

Also be aware that your GPU runs in parallel to your CPU. The only real CPU time taken by love.graphics is when a) LÖVE has CPU-side (non-OpenGL) code involved in the graphics operations, b) data (such as vertex positions) is sent to OpenGL or rendering commands are issued, and c) the CPU and GPU need to synchronize, such as when love.graphics.present is called.
It can be difficult to profile exact rendering times because the GPU is often doing much of its work in between when the initial rendering commands were sent and when love.graphics.present is called right after love.draw.

You can try using a LuaJIT build of LÖVE if you aren't already (no code adjustment needed), and see if that speeds up your update time.