## Managing a consistent framerate

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
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

Optimised code is good, to a certain level. You must be very careful how much you optimise, usually the more you optimise, the uglier things look in your code. For example, if optimised code were the only factor we cared about, we'd be coding in machine code, or at least assembly.

Oh I see what you were saying. I think it would be theoretically faster, but the speed gained would be so small that it wouldn't be worth it.

Lafolie
Inner party member
Posts: 804
Joined: Tue Apr 05, 2011 2:59 pm
Location: SR388
Contact:

### Re: Managing a consistent framerate

Yeah, that's what I meant by "most cases".

I have learned a lesson about this in the last couple of days anyway. My menu code has become somewhat convoluted. Eh, it works, no point in re-writing it. That reminds me.... I should go and finish that. -!
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.

pekka
Party member
Posts: 206
Joined: Thu Jan 07, 2010 6:48 am
Location: Oulu, Finland
Contact:

### Re: Managing a consistent framerate

I don't know if this optimization has been covered, but it is a useful technique to know to squeeze some performance out of the most time-critical parts of your code.

The upvalue optimization consists of replacing table accesses before function invocation with upvalue accesses. This means that you don't call love.graphics.draw, but you put the draw fn into an upvalue and call it from there. It has some noticeable timing benefit in this example where I use it on the standard fns table.insert and table.remove.

Code: Select all

-- function with direct table access
function table_test(mytable)
for i = 1, 500000 do
table.insert(mytable, i)
end
for i = 1, 500000 do
table.remove(mytable)
end
end

-- same function with accesses of the "table" table replaced by upvalues
do
local insert = table.insert
local remove = table.remove

function table_test_upvalues(mytable)
for i = 1, 500000 do
insert(mytable, i)
end
for i = 1, 500000 do
remove(mytable)
end
end

end -- do block

print "Golly, let's run some timing tests"

t = {}

start = os.clock()
table_test(t)
stop = os.clock()

print ("first test took " .. (stop - start) .. " os.clock() units")

start = os.clock()
table_test_upvalues(t)
stop = os.clock()

print ("second test took " .. (stop - start) .. " os.clock() units")

print "OK, cool, but let's do them again in reverse order"

start = os.clock()
table_test_upvalues(t)
stop = os.clock()

print ("second test now took " .. (stop - start) .. " os.clock() units")

start = os.clock()
table_test(t)
stop = os.clock()

print ("first test now took " .. (stop - start) .. " os.clock() units")

You can also use local variables instead of upvalues. Remember to test how much of an effect it has on execution speed if you do. Optimizing without testing the effects is pretty much useless.

I remember reading somewhere (in PiL?) that using upvalues is faster than using tables, though I don't know if that is generally true. Anyway, on my system with the command-line Lua interpreter I got a benefit of above 10% in execution speed with this change using the above testing program, so in this case it was apparently true. That seems like a major difference, but then again, do you often call the same function 500000 times in a row? In real situations the benefits will be smaller!

Those os.clock() units look a lot like seconds to me, but I was too lazy to check in the docs that they really are

(Also note that if you change the remove call to remove the first item from the tables each time, the tests suddenly take ages to run. It's useful to remember that this is how Lua tables work.)

BlackBulletIV
Inner party member
Posts: 1261
Joined: Wed Dec 29, 2010 8:19 pm
Location: Queensland, Australia
Contact:

### Re: Managing a consistent framerate

Thanks for the information, a handy thing to keep in mind.

And yes, os.clock() is definitely seconds.

bartbes
Sex machine
Posts: 4946
Joined: Fri Aug 29, 2008 10:35 am
Location: The Netherlands
Contact:

### Re: Managing a consistent framerate

Guys.. os.clock is cpu time..

BlackBulletIV
Inner party member
Posts: 1261
Joined: Wed Dec 29, 2010 8:19 pm
Location: Queensland, Australia
Contact:

### Re: Managing a consistent framerate

In seconds right? It certainly seems to move by seconds.

bartbes
Sex machine
Posts: 4946
Joined: Fri Aug 29, 2008 10:35 am
Location: The Netherlands
Contact:

### Re: Managing a consistent framerate

Yeah, but cpu time is not real time.

vrld
Party member
Posts: 917
Joined: Sun Apr 04, 2010 9:14 pm
Location: Germany
Contact:

### Re: Managing a consistent framerate

os.clock:
Returns an approximation of the amount in seconds of CPU time used by the program.
I have come here to chew bubblegum and kick ass... and I'm all out of bubblegum.

hump | HC | SUIT | moonshine

BlackBulletIV
Inner party member
Posts: 1261
Joined: Wed Dec 29, 2010 8:19 pm
Location: Queensland, Australia
Contact:

### Re: Managing a consistent framerate

Well then, I learnt something new. But the explanation of "seconds" is still partly right, just not in real time.

Ertain
Citizen
Posts: 55
Joined: Fri Nov 19, 2010 9:38 pm
Location: Texas, U.S.A.
Contact:

### Re: Managing a consistent framerate

I am at my wits end. I can't figure out why, at the end of my little demo here, it completely freezes up. I don't know if it's all of the ships I'm drawing, or it's a combination of the drawing and the collision detection.

If you guys wish to sample my game, here it is.
Attachments
love_project1.love
Sample game
(363.61 KiB) Downloaded 59 times
Booted, suited, and ready to get executed.

### Who is online

Users browsing this forum: No registered users and 39 guests