I’m trying to get rid of what I perceive as lag in my FPS experiment. I believe the problem I’m seeing is related to the fact that jMonkey is giving my Mouse Listener movement events after windows has already applied acceleration. This results in me seeing a small lag when I quickly move the mouse. I have tried using a RawInputListener but this doesn’t address the problem, as the raw delta mouse values are linearly correlated with the cooked “value” coming to my normal mouse movement event.
To support my suspicions I did a number of experiments: I have a RawInputListener printing the current “X” value out continuously, and I move the mouse back and forth as orthogonal as I can. When I move the mouse quickly to the left, and slowly back right, my absolute X position accumulates a large negative value. But when I change to quickly moving right, and slowly sliding back left, the X position accumulates a positive value. To me this is a sign that I’m not actually getting “raw” deltas from the low level mouse, but numbers cooked up post acceleration. This experiment should be easy to reproduce.
While what you say may be true, it is interesting that you perceive this as lag… because a perceived lag could be caused by and of a dozen other things… and is especially interesting because many of us notice no lag at all.
I definitely notice a lag if I move the mouse quickly. I’m using vsync, at 60 FPS rock solid. The lag is admittedly small, and I’m sensitive to details, but a number of friends of mine say they get sick when playing FPS games, and this kind of thing could be a contributing factor.
The first clue that it was acceleration lag is that if you print the event deltas the first couple are always very small, then there is a climb, and then a tapering off at the end. Even when you move the mouse VERY quickly, the first event is 1 pixel delta, which just can’t be right.
My Windows mouse settings are default… maybe you don’t notice because you have turned off acceleration? I don’t think games should be dependent on environmental user settings like this… they should be able to override for special circumstances. Even a 1 frame lag drives me complete nuts… I turned of Neverwinter Nights 2 after 20 minutes because the ingame mouse cursor lagged the mouse movement.
I’m saying that there is a whole other application that you’ve written that could have introduced noticeable lag in a variety of different ways… but we can’t see it so we can’t comment on that. If you’ve managed to introduce a one or two frame delay in your processing for some other reason (control versus app state ordering, enqueung callables, threading, whatever) then these will be 100x more noticeable than mouse acceleration. I think even they small lag induced by vsync will be more noticeable than acceleration differences.
Anyway, the values provided are directly from JInput. So you are welcome to go barking up that tree… if it were me, I’d look to the dozen more likely causes first.
My application is not complex enough to be the possible source of lag. I’m using a tweak off the “Fly Cam”. To reiterate, the actual event values coming to my MouseListener directly match my observation, namely that after moving the mouse quickly (in fact, hard tap or whack), the first couple of events (1/60 of a second each according to tpf) have very low values. So the lag is not just perceptible, but also predicted from the data.
I’ll look to see if JInput can be tweaked to tap into lower level mouse events.
Thanks,
JJ
PS, as example of bad FPS lag, take a look at the game Oblivion… serious lag with mouse, but none with Joystick.
So… you must perceive your mouse pointer to lag, also… since the values JME gets are 100% consistent with the actual mouse pointer movement.
Joysticks do not need to sample movement over a period of time to come up with their values… as they can detect that absolute value at any given moment. So of course they will feel differently. They are just two different forms of movement… it’s almost like comparing cursor keys to joysticks: they will feel different simply because they are completely different.
For my part, I feel like joysticks always lag because they only control how fast I’m looking… where as the mouse actually moves my eye as fast as I move the mouse in absolute terms. ie: a joystick I have to hold left and wait painfully while my character turns around 180 degrees… but a mouse I can get 180 degrees in a single jerk. It’s precisely this lack of control provided by joysticks that cause console games to often implement subtle auto-aiming.
I’m working on some font research and having fun with it. I saw the question and it was asked in just a certain way that piqued my interest. This may not have any bearing to your experiments but I do have some information to do with actual lag and perceived lag.
@pspeed has already hit the heart of the matter, so all I’m doing is just pretty much repeating what he expressed… just in the way that I think of them.
actual lag happens when our input devices take 1 to 2 frames of game logic / geometric updates to actually get to our “game” through the various event consumptions that are standard for any high level system. Once it hits the game it can then affect the information displayed upon the screen. We tend to get rid of actual lag by bypassing any “event consuming” systems between us and the raw input. So this is the first thing to check, and it looks kinda like you are doing so, by the conversation so far.
Next up is perceived lag, and this might where you are getting stuck at… First off… what class are you extending to make your base class for the game? You haven’t displayed any code on your game’s processing flow so I can only present conceptual situations for you to check against.
For your “lower levels” of game flow for… are you updating your game logic first? or your graphical updates first? This is one of the usual suspects for introducing perceived lag… especially if you are using a “software” displayed mouse pointer.
Is it a “threaded” situation? A certain type of graphical stability can be achieved by separating edit: graphical output side from the game logic and input side. It makes the overall game more robust (especially when loading graphical resources from disk or networked URI) but care must be taken to preserve the basic order of input->Game Logic->output… perceived lag can be introduced in this way, as well. especially if the Game Logic goes on a thread independant to the received input.
The Sampler/Shader issue, if your application has the output of one buffer serving as the input for another buffer, it may well be that perceived lag is being introduced into the system by not having the proper Bucket/Queue setup for your game’s display. Kinda like having a “game” on a GUI display, which is then part of a bigger game. Each improperly queued rendering will delay the display of input by one frame.
Those are the 4 known causes that I know of for “lag between input and output” Just make sure that your program in consideration for these issues and you should do just fine.
Oh, and bonus question to forum. Are there any other situations that I’m leaving out of the list? If I remembered them all, great.
I’m going to head back to my ttf font fun, and get more stuff done.
If you use hardware cursors thats as fast as it gets, but if you want to reduce delay disable vsync.
As a old school gamer from the CRT area I’m kinda pissed that someone decided 60hz is enough, back then we had 120hz for good reasons. (I’m so waiting for the first 144hz gsync monitors to become somewhat affordable)
@Relic724 I’ve identified the source of lag as Mouse Acceleration (and smoothing) from Windows itself, from before JInput. When I move the mouse quickly, I see low delta values for the first couple of frames, which is clearly correlated with the lag I see. I have yet to post on JInput forums to see if there is a way to get more raw data from the mouse.
My code is a simple clone of the FlyCam. All I have done is comment out the keyboard control, as I do that in my own custom logic (In an AppState). My FlyCam registeres for mouse events, and updates the cam each frame with no queuing. I don’t see lag in the keyboard control, just fast movements with the mouse.
@pspeed I don’t notice mouse cursor lag (too small?), but if I grab an entire window and move it quickly I believe I see the same effect. Note that I have my computer hooked up to a large screen TV, which I am very close to. This probably help accentuate the effects. (The TV is set to “Game Mode” of course, because I noticed the cinematic lag out of box immediately)
I largely agree with your comments on Joysticks. I find them worse to use for first person games. The only game I’ve ever had motion sickness issues with is Dark Souls 2, which is 3rd person with Joystick.
Final note: for those of us that see this, the effect is very real, and from web searching I’m not the only one. Apparently all modern PC FPS directly disable mouse acceleration.
ok, so that means you would want to test the behaviors of com.jme3.input.awt.AwtMouseInput (which is for a game that runs in a Window situation) and com.jme3.input.lwjgl.LwjglMouseInput (which is probably what you are looking for).
Does that help? (I haven’t experimented with mouse much… my types of games are not that … um… swirly? FPS ish? Where lag matters?)
And according to a lot of Info, It’s just you*. You said the magic word “Windows”, which does not allow games that aren’t Microsoft to disable acceleration. PERIOD. Windows 7+. So, grumble and moan or do something like this.:
Yeah, they (Windows 7+) don’t have acceleration listed on the mouse properties in the control panel anymore… They just absorbed it in as “a natural fact” and said F.U. to all twitch gamers.
edit: and then again… the lag may just be the bottleneck through to your tv… try on a different monitor? I know that Game Mode on most tv’s just has to do with color correction, from my experience. (They might have changed this recently, IDK)
