vsync limits frame rate to 60

General discussion about LÖVE, Lua, game development, puns, and unicorns.
Post Reply
Mark-Weston
Prole
Posts: 1
Joined: Thu Dec 14, 2017 11:12 am

vsync limits frame rate to 60

Post by Mark-Weston »

My solution in my own engine was to create an additional thread for logic and one mutex.
Then the main thread loop (drawing one) looked like this:
1. Lock the mutex.
2. Call the user code for drawing
3. Unlock the mutex.
4. Call the screen updating function which blocks.
While the updating thread loop looked like this:
1. Lock the mutex.
2. Call the user code for updating.
3. Unlock the mutex.
Voila, the blocking function (be it SDL_RenderPresent or glfwSwapBuffers) no longer interferes with the deltas.
There are a few problems, though:
1. I don't know if you'd be interested in this at all.
2. I don't know if non-rendering functions of SDL are safe to call from the other thread.
3. This would take away control of the run callback.
Anyway, just a suggestion. Maybe there's no need for a "solution", maybe this is not a problem to begin with.

I found it useful for physics - the faster the physics loop runs, the more accurate the results are, so they were not tied to 60 fps and ran at 100 fps instead.
User avatar
zorg
Party member
Posts: 3436
Joined: Thu Dec 13, 2012 2:55 pm
Location: Absurdistan, Hungary
Contact:

Re: vsync limits frame rate to 60

Post by zorg »

Hi, and welcome to the forums.

The vsync setting actually limits the speed of love.run to whatever (i'm guessing SDL) can ascertain of the screen the löve window is currently on. It might be 60, might be 75, 85, 120, 144, even 4 if for some reason the detection returns a faulty value (i have experienced such a thing); point is, you shouldn't rely on it being 100% perfect in all cases.

As for solutions, technically, you don't even need a mutex for syncing logic and rendering if you'd "double-buffer" your logic; have a past-state and a current state, and one variable that's available to both threads (either fake it with a löve data object, or create a c double with luajit's FFI), and in the update thread, only write to it the time elapsed between the two update states, and in the graphics thread, only read from it so you could interpolate between those two states. This only works if the update and draw rates are close to each other though, otherwise the interpolation would probably be off, so it's not perfect either.

In any case, feel free to share your implementation, people like to see how other people tackle (or even spot) issues. :3

(Also, to my knowledge, apart from love.graphics stuff and love.event.pump, everything else can be used in a separate thread.)
Me and my stuff :3True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.
Post Reply

Who is online

Users browsing this forum: No registered users and 70 guests