![Razz :P](./images/smilies/ms-razz.png)
Managing a consistent framerate
Forum rules
Before you make a thread asking for help, read this.
Before you make a thread asking for help, read this.
- BlackBulletIV
- Inner party member
- Posts: 1261
- Joined: Wed Dec 29, 2010 8:19 pm
- Location: Queensland, Australia
- Contact:
Re: Managing a consistent framerate
Doh! Why didn't I think of that one!
Thanks.
![Razz :P](./images/smilies/ms-razz.png)
- Taehl
- Dreaming in associative arrays
- Posts: 1025
- Joined: Mon Jan 11, 2010 5:07 am
- Location: CA, USA
- Contact:
Re: Managing a consistent framerate
BlackBulletIV wrote:Don't forget the width and height! It's also best to use the getWidth/Height functions (or some variables), to make your code more abstract, as in, less reliant on outside conditions.
I was trying to show the most minimal form. He may not be using width and height, after all.Taehl wrote:A very simple way
Earliest Love2D supporter who can't Love anymore. Let me disable pixel shaders if I don't use them, dammit!
Lenovo Thinkpad X60 Tablet, built like a tank. But not fancy enough for Love2D 0.10.0+.
Lenovo Thinkpad X60 Tablet, built like a tank. But not fancy enough for Love2D 0.10.0+.
- BlackBulletIV
- Inner party member
- Posts: 1261
- Joined: Wed Dec 29, 2010 8:19 pm
- Location: Queensland, Australia
- Contact:
Re: Managing a consistent framerate
Oh, I'm using the width and height of the screen.
Booted, suited, and ready to get executed.
Re: Managing a consistent framerate
I dread to think how many times I'm -not- doing this is UnLöve.... D:miko wrote: You don't want do access global variables and make a call to get*() on every iteration. So the modified example would be:
Code: Select all
function love.draw() local width, height=love.graphics.getWidth(), love.graphics.getHeight() local draw=love.graphics.draw for i, enemy in ipairs(enemies) do if enemy.x > -enemy.width and enemy.x < width and enemy.y > -enemy.height and enemy.y < height then draw(img_enemy, enemy.x, enemy.y) end end end
Do you recognise when the world won't stop for you? Or when the days don't care what you've got to do? When the weight's too tough to lift up, what do you? Don't let them choose for you, that's on you.
- BlackBulletIV
- Inner party member
- Posts: 1261
- Joined: Wed Dec 29, 2010 8:19 pm
- Location: Queensland, Australia
- Contact:
Re: Managing a consistent framerate
I've personally taken the route of caching those values in love.graphics.width and love.graphics.height, and then of course adjusting them whenever something changes. This would be much faster and convenient, and it's certainly practical, because the width and height will hardly ever, or not at all, change.
Re: Managing a consistent framerate
You mean you just store them in a global var? It's probably faster than storing them in a local value in each function that uses them in an iteration, even if it is calling a global. Perhaps you could still uses the locals, but pull the value from the globals instead of issuing love.graphics.get*() and it would be faster still? Hmmmm.BlackBulletIV wrote:I've personally taken the route of caching those values in love.graphics.width and love.graphics.height, and then of course adjusting them whenever something changes. This would be much faster and convenient, and it's certainly practical, because the width and height will hardly ever, or not at all, change.
Do you recognise when the world won't stop for you? Or when the days don't care what you've got to do? When the weight's too tough to lift up, what do you? Don't let them choose for you, that's on you.
- slime
- Solid Snayke
- Posts: 3154
- Joined: Mon Aug 23, 2010 6:45 am
- Location: Nova Scotia, Canada
- Contact:
Re: Managing a consistent framerate
The performance increase is marginal when compared with the real bottlenecks a typical LÖVE game has. ![Razz :P](./images/smilies/ms-razz.png)
I do that too (store graphics getWidth/getHeight in global variables) but mainly for convenience. xres is a lot faster to type than love.graphics.getWidth().![Smile :)](./images/smilies/ms-smile.png)
![Razz :P](./images/smilies/ms-razz.png)
I do that too (store graphics getWidth/getHeight in global variables) but mainly for convenience. xres is a lot faster to type than love.graphics.getWidth().
![Smile :)](./images/smilies/ms-smile.png)
- BlackBulletIV
- Inner party member
- Posts: 1261
- Joined: Wed Dec 29, 2010 8:19 pm
- Location: Queensland, Australia
- Contact:
Re: Managing a consistent framerate
No, not a global variable. A variable nested inside the table love.graphics. The only global there is love itself. I'm not quite sure what you're meaning by that last sentence, but if you made love.graphics.get*() just return a value stored in Lua, I certainly think it would be faster (no going up to the C level).Lafolie wrote:You mean you just store them in a global var? It's probably faster than storing them in a local value in each function that uses them in an iteration, even if it is calling a global. Perhaps you could still uses the locals, but pull the value from the globals instead of issuing love.graphics.get*() and it would be faster still? Hmmmm.BlackBulletIV wrote:I've personally taken the route of caching those values in love.graphics.width and love.graphics.height, and then of course adjusting them whenever something changes. This would be much faster and convenient, and it's certainly practical, because the width and height will hardly ever, or not at all, change.
Re: Managing a consistent framerate
Of course! It is a lot quicker to type.
The performance increase isn't the real issue though. What this is really about is writing optimised code. Whilst the purpose of optimised code is pretty much for performance, writing such code is just good practice and I believe that it is good to get into that mindset. Write the best code you can. A good example of this philosophy would be using that lua strict module. There's no real need to use it, but it helps you write optimised, clean code which inevitably has several benefits other than performance increase.
Optimised code = good code. In most cases anyway.
![Very Happy :D](./images/smilies/ms-glad.png)
BlackBulletIV posted while I was typing....
And, I meant doing this:
The performance increase isn't the real issue though. What this is really about is writing optimised code. Whilst the purpose of optimised code is pretty much for performance, writing such code is just good practice and I believe that it is good to get into that mindset. Write the best code you can. A good example of this philosophy would be using that lua strict module. There's no real need to use it, but it helps you write optimised, clean code which inevitably has several benefits other than performance increase.
Optimised code = good code. In most cases anyway.
![Very Happy :D](./images/smilies/ms-glad.png)
BlackBulletIV posted while I was typing....
Oh, I see. That's cool but it's even quicker to type out a var name using a global outside of love.graphics.No, not a global variable. A variable nested inside the table love.graphics. The only global there is love itself. I'm not quite sure what you're meaning by that last sentence, but if you made love.graphics.get*() just return a value stored in Lua, I certainly think it would be faster (no going up to the C level).
And, I meant doing this:
Code: Select all
width = love.graphics.getWidth()
height = love.graphics.getHeight()
function iterator()
local w = width
local h = height
for i = 1, 10 do
love.graphics.setColor(255, 255, 255, 10 * i)
love.graphics.rectangle("fill", 10 * i, 10 * i, w - 20 * i, h - 20 * i)
end
end
function love.draw()
iterator()
end
Do you recognise when the world won't stop for you? Or when the days don't care what you've got to do? When the weight's too tough to lift up, what do you? Don't let them choose for you, that's on you.
Who is online
Users browsing this forum: Bing [Bot], SugarRayLua and 1 guest