Love keyboard input delay

[holothurian]

Hey guys! I've been messing around with a very basic love game using ammo, and I have a simple character set up using the most basic vanilla settings shooting bullets. However, the character movement using the example code provided with ammo seems slightly... delayed. If I make the player move in a circle the corners feel like they are notably behind my keyboard presses, and there is a delay as the square comes to a halt after releasing the key (the default code follows). This is consistent over two different computers. This seems odd to me, as I am sure the program is running at hundreds of fps and updating so quickly this should be nigh on instantaneous.

This is the code in his example, source is https://github.com/BlackBulletIV/ammo/w ... ck-Example:

Code: Select all

function Player:update(dt)
  local xAxis = 0
  local yAxis = 0
  if love.keyboard.isDown("left") then xAxis = xAxis - 1 end
  if love.keyboard.isDown("right") then xAxis = xAxis + 1 end
  if love.keyboard.isDown("up") then yAxis = yAxis - 1 end
  if love.keyboard.isDown("down") then yAxis = yAxis + 1 end
  
  self.x = self.x + Player.speed * xAxis * dt
  self.y = self.y + Player.speed * yAxis * dt

Is there a slight known delay in love's input handling, or am I just slightly mad? My friend agrees with me that it feels delayed, so I hope we are not suffering from collective dementia...!

Also, on an entirely unrelated note, is it possible to get access to raw mouse data using love without writing a c plugin?

[Roland_Yonaba]

I just tried, and I don't have such a problem.
Here's my love.

Maybe you want to play with love.keyboard.setKeyRepeat.

[holothurian]

Thank you Roland. That still feels slightly delayed to us (try moving it in a square shape alternating between directions and noting when the corners occur relative to your keypresses to get an idea). We are going to try moving our keyboard movement into the love.update function next as a test. We are also still wondering if there is a way for us to get mouse x and y position relative to camera rather than world, as we are using mouse x position to turn a player-centred camera, but every time the player moves it alters the mouse's absolute position, which causes rotation, etc.

[slime]

Have you tested with vsync off?

Code: Select all

function love.load()
    love.graphics.setMode(800, 600, false, false, 0)
    [...]
end
[...]

[holothurian]

Hmm Slime that does feel slightly better. I didn't realise love defaulted to vsync on! But nonetheless I would be surprised if that had a huge effect because you are rendering so many more frames that there shouldn't be a huge difference between the frame presented and the frame vsynced.

EDIT: We tested with VSync off in fullscreen, and it feels really quite snappy now. Thank you to both of you who commented. Any insight on how we can go about getting absolute mouse position rather than mouse position relative to world ? Even better would be raw mouse position. We could write a c plugin to do this, but it would lose us portability and I don't want to hate on linux dudes!

Double Edit: We bodged in a correction for this, but I am still interested in a general sense if there is a neater way of getting mouse information in love/lua.

[Boolsheet]

Drawing a simple square is probably done in microseconds. With the usual 60 Hz refresh rate, you'll now wait 16 ms before you see the frame on the monitor.

LÖVE should be rather fast in processing such events. Latency added by SDL, the window manager or the OS is sadly out of its control.

You mean you want the cursor position relative to the screen instead of the window? SDL only gives window positions and that's what LÖVE uses.

[holothurian]

Yeah Bool we found that once we made it full screen the feeling of looseness was mitigated to a significant degree. This was probably something to do with windows. Thanks for the info on how love gets mouse data, we shall investigate sdl!

Ideally we just want the difference in the mouse's x position relative to each frame. As it is we are just applying a camera movement correction so the movement of the camera doesn't change that, as we are using the mouse x position to determine camera angle - kind of like a top down version of doom.

[Boolsheet]

I've heard that Aero (which always uses vsync, I think) adds latency to input events. I don't have the equipment to measure that properly, so I don't know if that's true.

Ah. LÖVE doesn't use SDL's relative mouse positions (yet), but there is an issue on the tracker for it.

[slime]

If you're using Windows Vista or 7 (or 8?), Aero adds ~33ms of input lag in windowed programs if it's enabled. You could try running the game in windowed mode with Aero off, and see if that's a similar experience to fullscreen.

[holothurian]

If you're using Windows Vista or 7 (or 8?), Aero adds ~33ms of input lag in windowed programs if it's enabled. You could try running the game in windowed mode with Aero off, and see if that's a similar experience to fullscreen.

Thank you, this is exactly our problem. Is there no way we can address that in love/lua, or is our only option to force the game to run fullscreen? I have an absolute loathing of laggy controls!

Although this does mean linuxbros can be smug.