Capped frame limit for no reason *sigh*

[pacman]

v-sync = input lag
Difference between 60 (without v-sync) and 120 is indistinguishable in minesweeper but it matters a lot in faster games.
How is it irrelevant if game listen to your fingers more times?
I wanted to lock the frame rate because of the delta time. It can get messy
Now if you have less FPS the game runs slower just like on NES. At the end of the day there shouldn't be any problem with changing variable to 60.

On Linux at work the game works fine
What are the possibilities?
Nvidia panel shows v-sync is off.
What else could cause it?

[Jasoco]

I sure as heck wouldn't want to play a game with VSync turned off. Screen tearing is ugly. And how is 60FPS going to have input lag? Input takes no CPU time at all.

Also, just because your GPU settings have VSync off, that doesn't mean Löve has it off too. Do you have a conf.lua file and is it set to false? If not then we have no idea.

You'll have to give examples of where your project is being hindered by so-called "input lag". There is absolutely no lag at all in your project as posted in the OT at 60FPS.

[zorg]

though i don't exactly know how love.run's execution is timed if vsync is on, but if it is off, then with the default love.run, your input handling speed is coupled to the framerate for the simple reason that they are both sequentially one after another in the same while loop.

if vsync forces love.run to run slower, then it will modify how fast the input gets detected simply because the intervals between detecting love's events in there will be bigger.

i'd vouch for a custom game loop with vsync off, but that's just my 12 HUF. ($0.05)
Edit: downside is either 100% cpu usage or slightly incorrect fps timings, depending on you calling love.timer.sleep inside love.run; if someone knows a way to get the best of both worlds, do tell me in pm or something.

[pacman]

I'm not a fan of screen tearing too, but I don't think I ever experienced it in its full ugliness.
I can fly in Quake World with hundreds of fasts per second™ (basically sanic can't touch me) and everything is smooth as elven butt.

V-sync slows down everything to make sure monitor will have one frame every display cycle. When you press "jump", welp, gotta wait for next frame. <1/60 of a second is hell of a time! Sometimes...

Other thing is that position = velocity * dt will differ depending on the dt... Less dt = lesser error.
Either way toggling fps from 60 to 125 made me stick to 125.

I have vsync = false in config file. I will try setting it to false with setMode later :<

[caldur]

Correct me if I got it wrong, but the way Love (and OpenGL) implements vsync is as follows: when vsync is enabled, the love.graphics.present() call, which is essentially an GL swapbuffer, is delayed to match the monitor refresh rate. Since the default love.run() calls love.update and love.draw within the same loop, the loop is essentially held still when waiting for the present(), hence the capped update frequency.

I am personally in favor of vsync, and to avoid the side effect of limiting update frequency is not quite difficult a task, just decouple the update and draw call by providing a custom love.run(). My version is something like this (vsync on while maintaining a constant 100 updates per sec)

Code: Select all

local frametime = 0
local accumulator = 0
local dt = 0.01  --specify the target update frequency here

while true do
        love.timer.step()
        frametime = love.timer.getDelta()
        accumulator = accumulator + frametime

    	while (accumulator >= dt) do
	        -- Process events.
	        -- Call update and draw
	        love.update(dt)
	        accumulator = accumulator - dt
	    end

        love.graphics.clear()
        love.graphics.origin()
        love.draw()
        love.graphics.present()
end

It's based on this article http://gafferongames.com/game-physics/f ... -timestep/ , and to bring it further you can always do the extra interpolation to cover the differences, as detailed in the last section of the article

[Evine]

If you want to be super crazy about input delay, just put in a delay until the very last millisecond, then check for key input and run the player code. It's best to work around the issue with vsync on to prevent screen tearing.

Code: Select all

function love.update()
code.game()--excluding player
timer.delay()--0.014ms
code.player()--All "time sensitive" key inputs here
end 

[Positive07]

Your game MUST be designed with crappy FPS in mind (30FPS) 0.3 seconds is more than the speed your hand can move at... even your keyboard skips keypresses if you move faster than that (because it needs to debounce the key... electronic explenation I dont wanna write here...) so it shouldnt matter, you will never experience "input lag".

You can calculate physics well enough at this speed too, you just need the correct algorithm (Roland has got a github with different algorithms implemented to check which would work better with different Frame rates)

And last, you cant see faster than this speed (well maybe faster than 30FPS yeah but not faster than 50) this is why you can't perceive the delay in the screen refresh.

My question now is... why would you go faster than a speed where you already cant react, not with your fingers or your eyes? and if you tell me that physics feel bugged when they are not running at 125FPS, then I'll tell you, that is because you are doing it wrong.

[zorg]

Your game MUST be designed with crappy FPS in mind (30FPS) 0.3 seconds is more than the speed your hand can move at... even your keyboard skips keypresses if you move faster than that (because it needs to debounce the key... electronic explenation I dont wanna write here...) so it shouldnt matter, you will never experience "input lag".

My interpretation is that it's not how fast he presses/depresses the keys, it's that how precise his timing is to either do one of those; and if the framerate and the logic rate is tied together, with low fps-es, the game's event handler WILL lag in love.run; as in, it will pull events in gigantic chunks instead of many small ones, and processing will jerk around instead of flowing smoothly, so to speak.
...also, while having the option to support crappy computers is an option, it's not really a necessity; it's just being decent to others.

And last, you cant see faster than this speed (well maybe faster than 30FPS yeah but not faster than 50) this is why you can't perceive the delay in the screen refresh.

Not exactly see, but many people are troubled by low flicker rates, both on screens and overhead neon lights; i do "see" the difference between 75Hz and 60Hz because with the latter, my eyes start to hurt after a short while. (BTW stereoscopics -> 2x60 Hz minimum )

[arampl]

@pacman: in main.lua I see code: "love.timer.sleep(next_time - cur_time)", line #186
It is the reason of frame limiting. It has nothing to do with v-sync.

[pacman]

Keeping it short and #nohate'ish
1. Making changes to love.run() may work but I don't feel comfortably enough to mess with anything that deep. That's why I'm using LÖVE
2. I don't need to design anything around crappy FPS because:
a) I may or may not care
b) I like the idea of capping FPS like it was on NES or (I belive) Need For Speed: Underground 2 where if there was too much happening you didn't jump from one place to another but smoothly move in slowmotion.
c) It's not like I want to make Watch Dogs in 125FPS. If I can't make 2d platformer working that fast, I'd rather jump out of a window than lower the cap to 60.
3. If you think human eye works in FPS... It's not.
4. If you think there is no difference above some magic number (50? 60? 61?)... There is.
5. I wouldn't expect such discussion on gaming'ish forum, but anyway, something doesn't let me achieve more than 100 FPS on this PC

Edit. The sleep() is for maintaining 125FPS. Problem is I'm getting 100 all of a sudden... Works fine on Linux.