LÖVE

Hello again, LÖVErs. I have a question about keeping the framerate consistent and making things run smooth. What are some methods for doing this? I have been trying to figure out how not to have so many pictures on the screen (so that it doesn't eat up CPU cycles). When one of the enemies in my little game is destroyed, for example, I just have them moved off the screen. I have been wondering about how to remove the enemy picture, data and all.

That would help to speed things up, but I'm sure there are better ways to make this more efficient, like we always try to do.

framebuffers or spritebatches are good ways to draw backgrounds while saving on framerate. As of LÖVE 0.7.1, love.graphics.print/love.graphics.printf are very inefficient and can cause large performance drops, but that will be improved in LÖVE 0.8.0.
If you're doing a lot of heavy lifting in love.update it can be a good idea to only update that portion of the update code every 30 or 60 frames.

There are always ways to improve performance, but beyond using the right tools for the job (framebuffers for example) don't spend too much time during early development optimizing, as you may have to rewrite large portions of your code later anyway.

Ertain wrote:When one of the enemies in my little game is destroyed, for example, I just have them moved off the screen. I have been wondering about how to remove the enemy picture, data and all.

When you don't need a certain image, just don't draw it -- not even off screen. That helps.

If you are really sure you don't need the image any more, you can just clear all references to it, and Lua will collect it automatically.

Yeah. Drawing off the screen is just as slow as drawing on the screen, so to have the best possible framerate, make your game only draw what's visible.

Taehl wrote:Yeah. Drawing off the screen is just as slow as drawing on the screen, so to have the best possible framerate, make your game only draw what's visible.

Of course, sometimes it can be slower to check for whether an image is in the screen area or not than to just draw it without any checks.

slime wrote:Of course, sometimes it can be slower to check for whether an image is in the screen area or not than to just draw it without any checks.

The absolute best way is to use a method that doesn't even have to bother checking for the location of an image. It scales much better.

Thanks for the help, guys. I shall not use the in-game print statements and stop drawing the images. But the framebuffers will be a problem, because they don't work on all OSes. So I'm going to have to at least check for the framebuffers and stuff.

Ertain wrote:Hello again, LÖVErs. I have a question about keeping the framerate consistent and making things run smooth. What are some methods for doing this? I have been trying to figure out how not to have so many pictures on the screen (so that it doesn't eat up CPU cycles). When one of the enemies in my little game is destroyed, for example, I just have them moved off the screen. I have been wondering about how to remove the enemy picture, data and all.

That would help to speed things up, but I'm sure there are better ways to make this more efficient, like we always try to do.

I would say those are standard problems. I do agree with what was said before, and I would add:
- don't do anything you don't need (calculations, drawings, etc)
- if you really have to do it, do it only once (move to love.load(), memoize, cache, etc)
- if it cannot be done once, do it only as frequent as it really is required (eg, change the value of timer every second, not every frame)
- move your busy code out of the main loop (move long-running operations to other threads, like love.thread)
- put more RAM (there is usually tradeoff between CPU and RAM usage)
- use clever algorithms (eg, do not recalculate the whole scene, only the part which really has changed, use clever sorting algorithms, use object partitioning for collision detection)
- check for efficient lua usage: avoid creating and destroying objects which have to be garbage-collected (so reuse your tables instead of recreating new ones)
- profile your code (find the slowest part and try to optimize it)

Taehl wrote:Yeah. Drawing off the screen is just as slow as drawing on the screen, so to have the best possible framerate, make your game only draw what's visible.

At least when drawing rectangles, I found that to be quite the opposite. When a couple hundred rectangles were on-screen, there was a slow down in framerate to the 200s I think. Then it went back up to the high 400s when not so many were around. Again, when drawing rectangles, I found by doing checks on what to draw, I had a frame rate drop of about 40-50 when drawing about 15-20 rectangles. But, it might different for images.

I was talking about drawing images (and I assume the same would be true about framebuffers, quads, and spritebatches). I don't know about simple things like rectangles.