[Solved] Yet another frame rate-related question

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.
Post Reply
Darkslime[Z]
Prole
Posts: 2
Joined: Wed Aug 31, 2011 6:05 pm

[Solved] Yet another frame rate-related question

Post by Darkslime[Z] »

I'm new to LOVE and these forums(and to Lua, really), but I decided to see what's up and try to program a few simple things. Like others, I assume, I soon ran into a slight problem regarding timing and frame rates.

After searching around this forum a little, I found that you can somewhat limit the frame rate by using the love.timer.sleep() according to dt. I also have been using dt in all my update functionality(update object movement, etc) as is recommended to do.

I have two problems with both of these scenarios. Basically, I have a player on the bottom of the screen that shoots bullets towards the top when you hold down the z button. For testing purposes, these bullets contain an event to make them veer to the right after a certain amount of time has passed.

The first problem is that as more bullets are drawn on the screen, the game's frame rate begins to slow down(I'm not using sleep(), I'm outputting 1/dt onto the screen). LOVE seems to want to stay at about 1000 updates per second, but once I have around ten or so bullets on the screen, it slows down to like 200. I obviously only want 60; maybe then it would be drawing at a constant rate.

That might not be as much of a problem if not for this second element. I'm giving the bullet objects a table to list events that modify its behavior - such as "at step 20, make y-speed 50". Each bullet keeps its own timer, which(at the moment) increments by 100*dt each time the bullet is updated. My current approach to this is: if the timer has exceeded the frame of the event between this update and the previous one, then execute the event.

The clear problem with this is that now when I fire a stream of bullets, they all end up at different y-positions(that is, they go up, then veer directly right at "step" 20, but plus or minus a couple of pixels). If I'm going to make patterns of bullets that require timing precision, this is going to cause everything to be off a bit. And since I obviously can't be sure about the value of dt every single frame, I can't get it so that a bullet's timer ends up exactly on every whole number.

Does anyone have any advice? Is LOVE suited to something that requires a bit more timing like this? I can upload my .love file if needed. I'm not too familiar with the language yet, so some of this might sound a little strange; if it does, I'll try and clarify it. :death:
Last edited by Darkslime[Z] on Thu Sep 01, 2011 4:07 pm, edited 1 time in total.
User avatar
kikito
Inner party member
Posts: 3153
Joined: Sat Oct 03, 2009 5:22 pm
Location: Madrid, Spain
Contact:

Re: Yet another frame rate-related question, it seems...

Post by kikito »

hello there!

First of all - you will get better and faster help if you upload a löve file displaying the problem you are having.

Second, have you considered not using sleep at all? Simply calculate the new position of the player and bullets using their speed and dt.
When I write def I mean function.
User avatar
GijsB
Party member
Posts: 380
Joined: Wed Jul 20, 2011 10:19 pm
Location: Netherlands

Re: Yet another frame rate-related question, it seems...

Post by GijsB »

make a timer when updating things=

Code: Select all

local timer1 = 0
local fps = 60

function love.update(dt)
 timer1 = timer1+dt
 if timer1 > 1/fps then
  --DO STUFF HERE
  timer1 = 0
 end
end
Rad3k
Citizen
Posts: 69
Joined: Mon Aug 08, 2011 12:28 pm

Re: Yet another frame rate-related question, it seems...

Post by Rad3k »

Or you can try using my version of love.run function. If you use it, you'll get constant (mostly) framerate and fixed dt in love.update.
User avatar
vrld
Party member
Posts: 917
Joined: Sun Apr 04, 2010 9:14 pm
Location: Germany
Contact:

Re: Yet another frame rate-related question, it seems...

Post by vrld »

If you want exact timing behavior, you can define parametric curve, where the paramter is the time that has passed and the target variable(s) are the x and y coordinate the bullet has to be at a given time. For example, to go up and then make a 90 degree right turn after 1 second:

Code: Select all

function right_turn(t, start_x, start_y, velocity)
    if t <= 1 then
        return start_x, start_y + velocity * t
    end
    return start_x + velocity * (t-1), start_y + velocity * 1
end
To change the speed at some timestep s:

Code: Select all

function speed_change(t, s, start_x, start_y, dx, dy, vel1, vel2)
    if t < s then return start_x + dx * vel1 * t, start_y + dy * vel1 * t end
    local r = s - t
    return start_x + dx * (vel1 * s + vel2 * r), start_y + dy * (vel1 * s + vel2 * r)
end
Does that help?
I have come here to chew bubblegum and kick ass... and I'm all out of bubblegum.

hump | HC | SUIT | moonshine
User avatar
kraftman
Party member
Posts: 277
Joined: Sat May 14, 2011 10:18 am

Re: Yet another frame rate-related question, it seems...

Post by kraftman »

GijsB wrote:make a timer when updating things=

Code: Select all

local timer1 = 0
local fps = 60

function love.update(dt)
 timer1 = timer1+dt
 if timer1 > 1/fps then
  --DO STUFF HERE
  timer1 = 0
 end
end
you should change timer1 = 0 to timer1 = timer1-1/fps
Darkslime[Z]
Prole
Posts: 2
Joined: Wed Aug 31, 2011 6:05 pm

Re: Yet another frame rate-related question, it seems...

Post by Darkslime[Z] »

Thanks for the quick replies, everyone.
kraftman wrote:
GijsB wrote:make a timer when updating things=

Code: Select all

local timer1 = 0
local fps = 60

function love.update(dt)
 timer1 = timer1+dt
 if timer1 > 1/fps then
  --DO STUFF HERE
  timer1 = 0
 end
end
you should change timer1 = 0 to timer1 = timer1-1/fps
I used this in the update() method, and everything seems to be hunky-dory after taking out all the dt factors in my movement routines. Game speed seems to be stable, and the bullets' movements appear exact. Thank you!

@vlrd: I'll keep your parametric code in mind in case something goes wrong. Thanks!
Post Reply

Who is online

Users browsing this forum: Bing [Bot], Google [Bot] and 4 guests