The big TimeDelta headache

I tried several times to include TimeDelta in the movement engine for my pixel Jump'n'run. But I never managed to get it to work pixel perfect. I noticed that the very last part of the wiki article about TimeDelta basically says �don't bother with it if you're doing a low-resolution pixel-drawn retro game�, at least that's the vibe I got.

I came to think of my old Multimedia Fusion stuff and ran some cca files, which run all the same speed no matter what refresh rate. From what I understand it's because MMF is using a fixed framerate. I saw that there was a Vsync option in the runtime options, which I probably never used before. So I ran the MMF example at 60hz and 85hz. With and without Vsync it runs exactly the same speed, as far as I can tell at least.

My Construct game has obviously a big speed difference between 60 and 85hz when running it Vsynced. Running it with a fixed framerate does solve that problem, but like stated in the wiki article: �Fixed framerate mode... is a poor choice, because it will reduce the display quality by introducing tearing.� And yes, it looks really f****ed up, if you excuse the language.

I don't know what to do with this now. Can't use TimeDelta for pixel perfect stuff, can't use fixed framerate cause the quality is very bad. And I don't want to live with the speed difference either.

I'd love to have fixed framerate in Construct that doesn't affect quality that much, like it seems to be the case in MMF. But of course I don't know much if anything about the engines behind those programs and how they work and all that. You get the idea.

Maybe some pros can enlighten me a little and give some advice on this particular issue.

I don't know how much it'll help, but if part of your issue is the sprite being rendered on partial coordinates you can always set its x and y to round(.x) and round(.y). Not sure what else to tell you.

MMF suffers exactly the same problems regarding refresh rate and speed of gameplay as Construct - there are just different options available to handle it. In Construct, I strongly recommend you code your game to simply take in to account the 2-3% random variation caused by timer inaccuracies. It's not much and shouldn't affect your game much. If you absolutely insist on it being pixel perfect (and I still struggle to get my head round why this is absolutely necessary), you can enable the TimeDelta override in Advanced application properties. You can have your game V-syncing for high display quality, and have TimeDelta return a constant value so it plays out identically every time. However, this means your game will run faster on 85Hz monitors than 60Hz monitors. I have heard of 120Hz monitors, so it could be as much as twice as fast. But that's why TimeDelta exists. It's designed to solve that problem

I tried enabling the override already with very weird results. You would get randomly stuck in the ground for example. And since it doesn't fix the different speeds anyway, doing the events without TimeDelta would be basically the same, right?

Using round(.X) etc like Arima suggested is a quite good method and gives better results. But still you may get stuck where you shouldn't or detectors that are supposed to stop when they overlay solid objects actually stop 1 pixel before. Therefore other events may not be triggered...

[quote:2ufumjbf]MMF suffers exactly the same problems regarding refresh rate and speed of gameplay as Construct

But then I don't understand why my MMF stuff seems to run exactly the same speed on the tested 60 and 85hz with no special settings, just plain set X to X + 1 stuff. I know I'm stupid but I don't really get it.

[quote:2ufumjbf]If you absolutely insist on it being pixel perfect (and I still struggle to get my head round why this is absolutely necessary)

Like it says in the wiki:

"However, some specific games (such as low-resolution pixel-drawn retro games) require movements to be exact to the pixel."

At least I'd like to get close to the pixel perfect optimum. Maybe I should just start using many more pushout events or whatever you may call them.

I tried enabling the override already with very weird results. You would get randomly stuck in the ground for example. And since it doesn't fix the different speeds anyway, doing the events without TimeDelta would be basically the same, right?

Sounds like a bug in your code - by chance, without override, you might get the same sequence of timedelta values - so I doubt that is directly caused by timedelta override. And yes, your application becomes framerate dependent again. However, you can still use timescaling, and you have the useful ability to turn off the override and go framerate independent again!

[quote:1f2b8n6i]Using round(.X) etc like Arima suggested is a quite good method and gives better results. But still you may get stuck where you shouldn't or detectors that are supposed to stop when they overlay solid objects actually stop 1 pixel before. Therefore other events may not be triggered...

I wouldn't advise this purely on the basis it will make motion less precise and you lose the smooth rendering.

[quote:1f2b8n6i][quote:1f2b8n6i]MMF suffers exactly the same problems regarding refresh rate and speed of gameplay as Construct

But then I don't understand why my MMF stuff seems to run exactly the same speed on the tested 60 and 85hz with no special settings, just plain set X to X + 1 stuff. I know I'm stupid but I don't really get it.

I think by default it uses 50fps fixed framerate, V-Sync off (so the display tears). 'Fixed framerate' is a misleading name, because the gameplay speed is still completely framerate dependent anyway: if a low-end computer can only run the game at half the intended framerate, the game only proceeds half as fast. And bleh, tearing displays aren't nice :-

[quote:1f2b8n6i][quote:1f2b8n6i]If you absolutely insist on it being pixel perfect (and I still struggle to get my head round why this is absolutely necessary)

Like it says in the wiki:

"However, some specific games (such as low-resolution pixel-drawn retro games) require movements to be exact to the pixel."

At least I'd like to get close to the pixel perfect optimum. Maybe I should just start using many more pushout events or whatever you may call them.

Yeah, I wrote that - but I'm starting to disagree! You might argue that in your game your player can jump exactly 32 pixels high so you fill your level with 32 pixel high blocks to jump over. Then you turn on timedelta, and you get a 3% random variation, which means 50% of the time you jump ever so slightly less than 32 pixels, and you can't clear the obstacle. I think the correct action in this case is to design a game with 30 pixel high obstacles! In other words, allow for the small random variations. I can't see how this would be a serious issue if you are just starting out your game. I think it would make very little difference - and then you can use motion blur, timescaling, v-sync quality display, framerate independent runtime, etc. etc...

Okay, just use time override right now. just do it. I'm constantly bugging Ashley about stuff related to this and have done tons and tons and tons of testing. While I'd still like to see a more processor intensive mode that runs every bit of logic at 60fps (or whatever), I don't think Ashley is ever going to go for it (even though it's worth it for some people for that level of precision. I'd never, for example, make a fighting game in construct. Anyone who would is crazy. As an example).

But hey, we gotta work with what we got. Ashley has at least helped me make this situation a lot more manageable and recently agreed to implement some features that would allow great control over how the game speed works.

So why is Delta Time inaccurate? Construct has decimal based X/Y positions! It should be perfect! -- well not quite, as framerate flickers a lot, especially under load. usual flickers don't cause much of a variance (far less than 1%) but unstable framerate (For example, a quick drop to 10 fps due to some other processor load before jumping quickly back up) can cause some spectacular differences (10-20 percentin some tests. Not a common scenario but it can happen). So how can we fix this? We can't RIGHT NOW, but we can later.

Okay so this is my plan as someone who is also looking for a lot of precision. I've asked for GetRefreshRate, and GetFrameRate and SetTimeOverride. If we don't get one or two of these it'll be because there are otherways to go about it. Either way the capability will be there.

Anyways we use GetRefreshRate to get the baseline speed we want based on the computer. From there the process becomes something like... storing the FPS values for every frame say for the last 60 frames. Then periodically taking those values, cutting off the lower end extremes and finding an average. The time delta then slowly drifts toward that value over over the course of a bunch of frames. The exact process and values would have to be tested but this is the concept. What will it do? It'll smooth everything out, speed wise. Sudden/larger bouts of frame drop will slow down instead of jerking and skipping forward. You can even set a minimum framerate to use where say, if the framerate goes below 30, the game just slows down. All these things should not only make things look less jerky at lower FPS, but drastically reduce the problems of accuracy in delta time mode. You probably won't be able to be pixel perfect, but you can be 'a few pixels perfect'.

But we can't do this yet, so just use time override and develop your game. Before your done, these features will become available. When I get this system to work I'll be sure to share it with everyone in case they need something similar.

Oh and just one more time to say this to Ashley. Like i said. I wasn't going to be the last. This is just going to keep coming up. I know you might not quite understand, but some of us are crazy or making games where we sincerely think this is necessary. Heck, I'm scared of things that aren't even necessarily positionally related (but can't make a fuss about stuff I can't test yet). You might still want to consider a more 'extreme' solution, even if it doesn't make sense to you. Either way, I'll appreciate what I can get/have gotten.

While I'd still like to see a more processor intensive mode that runs every bit of logic at 60fps (or whatever), I don't think Ashley is ever going to go for it

Is this the idea of running logic at one rate and the display at another? I still don't understand how this confers an advantage. Sure, I could get the logic to run at 60fps, but if your display runs at 75 Hz, even with V-sync on, the display would update irregularly. I can't imagine it looking very nice at all! You may as well go fixed framerate if you want that.

[quote:1a2fp02h]I'd never, for example, make a fighting game in construct. Anyone who would is crazy.

Why? What is crazy about it? As far as I know, all commercial fighting games either adopt a timedelta or fixed framerate approach. Is that bad? Do they fail in some particularly important way?

[quote:1a2fp02h]So why is Delta Time inaccurate?

I'm not sure a widely varying framerate is responsible for TimeDelta inaccuracies. The timer Construct uses is extremely accurate (it can also be used to time sections of compiled C++ code down to microseconds). I think variations simply come from the 'quantization' effect of the game framerate. Even if you had an atomic clock accurate to picoseconds, this clock is only measured every 0.01 seconds at 100fps. The inaccuracy therefore comes from events which in the real world would happen between frames - eg. 0.005 seconds after running the logic. Since the logic only runs at 100fps, the event is delayed until the next frame.

Consider an object moving at 100 pixels per second at 100fps for one second. You'd expect it to cover 100 pixels, right? If there is a small variation in the framerate, the object would correctly only be set to 'moving' for 99 of those frames - or maybe 101. This is a deviation of TimeDelta * Speed, or in this case, about 1 pixel either way (a total of 2% error). I think the similar formulae for acceleration magnifies this a little bit more, maybe to 3% or 4% (I haven't done any specific tests here). Still, I maintain this variation is not significant enough to mean anyone should redesign their games!

[quote:1a2fp02h]Anyways we use GetRefreshRate to get the baseline speed we want based on the computer. From there the process becomes something like... storing the FPS values for every frame say for the last 60 frames...

1 / TimeDelta gives you the framerate by the way. This is an interesting idea, but I can't see how it helps. The whole point of TimeDelta is it means time in the game-universe proceeds at the same speed as in the real world! Tweening timedelta values sounds like it would break this. Also, I don't think any commercial games or engines use this method. I would be very interested if you found a case of this being used professionally. Part of the reason I am reluctant to use ideas like this is because if it was a good idea, I'm sure the professionals would be doing it - so I'd be a lot more attracted to your idea if you found some examples of its usage.

Since Construct's timer is very accurate, the gameplay still proceeds at the same rate even if the framerate is jumping wildly between 10fps and 90fps. The only difference is that the quantization effect is worse at low framerates. It might LOOK jerky - but that's only because the display is updating at an irregular rate (note this happens with logic and display at different rates). Imagine filming a car with a special camera that takes frames at irregular intervals and can play them back at the same speed they were recorded. Sure, the car would look like it was stuttering along - only because of the display updating irregularly. In the real world, the car moved perfectly smoothly.

[quote:1a2fp02h]This is just going to keep coming up. I know you might not quite understand, but some of us are crazy or making games where we sincerely think this is necessary.

I don't think you need to design your games to NASA precision. Again, find me a commercial game that adopts a different system to one available already in Construct. I'd be very interested.

> While I'd still like to see a more processor intensive mode that runs every bit of logic at 60fps (or whatever), I don't think Ashley is ever going to go for it

>

Is this the idea of running logic at one rate and the display at another? I still don't understand how this confers an advantage. Sure, I could get the logic to run at 60fps, but if your display runs at 75 Hz, even with V-sync on, the display would update irregularly. I can't imagine it looking very nice at all! You may as well go fixed framerate if you want that.

Perhaps a higher logic rate would be better! I'm not sure though how much the logic load would be. I really can't debate that one though. Only semi example I can think of is how FPSs run game logic server side and correct the clients predictions. Not sure thats even a good idea.

[quote:36ghe52w]I'd never, for example, make a fighting game in construct. Anyone who would is crazy.

Why? What is crazy about it? As far as I know, all commercial fighting games either adopt a timedelta or fixed framerate approach. Is that bad? Do they fail in some particularly important way?

Well true I could use fixed framerate. But I know for example I can play Guilty Gear XX #R on the PC with V-Sync and I have never seen something happen that shouldn't of. If there was ever an extreme drop in framerate, the actions would resolve themselves. Same goes with Melty Blood for the PC. Theres actually a hack for advancing gameplay one tick at a time for both thats used for hacked netplay. I don't know how this is accomplished. it might just be sheer superior programming.

[quote:36ghe52w]

[quote:36ghe52w]So why is Delta Time inaccurate?

I'm not sure a widely varying framerate is responsible for TimeDelta inaccuracies. The timer Construct uses is extremely accurate (it can also be used to time sections of compiled C++ code down to microseconds). I think variations simply come from the 'quantization' effect of the game framerate. Even if you had an atomic clock accurate to picoseconds, this clock is only measured every 0.01 seconds at 100fps. The inaccuracy therefore comes from events which in the real world would happen between frames - eg. 0.005 seconds after running the logic. Since the logic only runs at 100fps, the event is delayed until the next frame.

Consider an object moving at 100 pixels per second at 100fps for one second. You'd expect it to cover 100 pixels, right? If there is a small variation in the framerate, the object would correctly only be set to 'moving' for 99 of those frames - or maybe 101. This is a deviation of TimeDelta * Speed, or in this case, about 1 pixel either way (a total of 2% error). I think the similar formulae for acceleration magnifies this a little bit more, maybe to 3% or 4% (I haven't done any specific tests here). Still, I maintain this variation is not significant enough to mean anyone should redesign their games!

I'm just theorizing here. I have test results but no knowledge of constructs code. All I know is that when the frame rate is jittery, things are inconsistent -- noticably so to the player (which is bad. A few pixels is okay since the player wouldn't notice them). So I THINk this happens say..... You jump. You're on the last 'tick' of your jump but now the frame rate is lower. Lets say, worst case scenario, something happens and your frame rate drops to 10 (it happens). That last tick would now move six times farther! Thats what I think happens at least and its's the only way I can rationalize this. Maybe you can shed more light?

[quote:36ghe52w]

[quote:36ghe52w]Anyways we use GetRefreshRate to get the baseline speed we want based on the computer. From there the process becomes something like... storing the FPS values for every frame say for the last 60 frames...

1 / TimeDelta gives you the framerate by the way. This is an interesting idea, but I can't see how it helps. The whole point of TimeDelta is it means time in the game-universe proceeds at the same speed as in the real world! Tweening timedelta values sounds like it would break this. Also, I don't think any commercial games or engines use this method. I would be very interested if you found a case of this being used professionally. Part of the reason I am reluctant to use ideas like this is because if it was a good idea, I'm sure the professionals would be doing it - so I'd be a lot more attracted to your idea if you found some examples of its usage.

Yes, but if I'm using time override, wouldn't that not give me the real framerate? Which is the problem.

Anyways, I can't answer this. Theres not a lot of 2d platformers developed for the PC these days professionally. They have the mixed blessing of being designed for a console where they can be certain of things like framerate (but a million other hassles). I do know I've seen FPSs that start slowing down after a certain point instead of skipping frames. Especially during short spikes. as I've noticed. I might have to do some research on this. I think the reason though you wouldn't see this again, you don't see a lot of PC based, high precision 2d games.

[quote:36ghe52w]

Since Construct's timer is very accurate, the gameplay still proceeds at the same rate even if the framerate is jumping wildly between 10fps and 90fps. The only difference is that the quantization effect is worse at low framerates. It might LOOK jerky - but that's only because the display is updating at an irregular rate (note this happens with logic and display at different rates). Imagine filming a car with a special camera that takes frames at irregular intervals and can play them back at the same speed they were recorded. Sure, the car would look like it was stuttering along - only because of the display updating irregularly. In the real world, the car moved perfectly smoothly.

Now a situation between 90 and 10, yeah, theres not much you can do. But I find that the display just doesn't look good under any sort of stress. I'd expect anywhere around 30 fps to look decent and be playable. I want to do this, even if it's not usual, just because I'm dealing with what I got and want things to work as well as possible. The limitations on are end as the user probably prevents many methods used by professional programmers. I see a solution that makes lower framerates look smoother and eliminates one of my problems with accuracy. I think slight flunctations in speed is worth the tradeoff. Ic ould be wrong though and may change my mind after implementing it, but I'm in fairly good mind that'll help things a bit.

[quote:36ghe52w]

[quote:36ghe52w]This is just going to keep coming up. I know you might not quite understand, but some of us are crazy or making games where we sincerely think this is necessary.

I don't think you need to design your games to NASA precision. Again, find me a commercial game that adopts a different system to one available already in Construct. I'd be very interested.

If I can I certainly will!

I don't know if this is any help, but if i'm ever in the situation where i need a little more accuracy in my movement engines, i make a little 'for' loop

Make a global varible called like, 'MovementAccuracy'

change the sampling to linear

And then at the start of layout (or change initial value) set it to the amount of accuracy you want

I usually set it to around 50, the higher it is, the more accurate you will get, although i'm not sure the cpu load it would have if you made it too high

Then do something like this

when right arrow is down

--for "Move" from 0 to global('MovementAccuracy')

== Set Player.X to Player.X + 200 * (timedelta / global('MovementAccuracy')

(the -- indicates a subevent)

(the == indicates an action)

Basically, the 'logic' runs 50 times per tick (or however many you set your global to) as opposed to once per tick, but you still get to use timedelta and use all your cool motion blur and timescaling stuff!

Apply that to your jumping code or moving code or whatever and it's pretty much pixel perfect

I had an example running at 1 fps that only went one pixel out

Or another method i suppose would be having variables like: "JumpStart" and "JumpMaxHeight" and make it so when the player jumps, the jumpstart records the Y value at 'ground level' and set jumpmaxheight to the jumpstart minus however high you want him to jump.

Then if the difference between the player's Y and jumpstart goes beyond jumpmaxheight, manually set the distance and code in the falling. Although i suppose this method would be a little harder if you weren't using a custom movement, and for REALLY low frame rates it might still require the use of that 'For' loop i just mentioned

I hope i made myself clear

[quote:1y7tg8ro][quote:1y7tg8ro]Using round(.X) etc like Arima suggested is a quite good method and gives better results. But still you may get stuck where you shouldn't or detectors that are supposed to stop when they overlay solid objects actually stop 1 pixel before. Therefore other events may not be triggered...

I wouldn't advise this purely on the basis it will make motion less precise and you lose the smooth rendering.

Good point. I suggested it because I was guessing that the game he's making might have been using pixel art, which can look odd if rendered halfway between pixels. A better way to do it and retain the precision of the floating point placement is to have one sprite that's the platform object and a separate sprite for the animations that's set to the rounded position of the platform base object.

I don't know if this is any help, but if i'm ever in the situation where i need a little more accuracy in my movement engines, i make a little 'for' loop

Make a global varible called like, 'MovementAccuracy'

change the sampling to linear

And then at the start of layout (or change initial value) set it to the amount of accuracy you want

I usually set it to around 50, the higher it is, the more accurate you will get, although i'm not sure the cpu load it would have if you made it too high

Then do something like this

when right arrow is down

--for "Move" from 0 to global('MovementAccuracy')

== Set Player.X to Player.X + 200 * (timedelta / global('MovementAccuracy')

(the -- indicates a subevent)

(the == indicates an action)

Basically, the 'logic' runs 50 times per tick (or however many you set your global to) as opposed to once per tick, but you still get to use timedelta and use all your cool motion blur and timescaling stuff!

Apply that to your jumping code or moving code or whatever and it's pretty much pixel perfect

I had an example running at 1 fps that only went one pixel out

Or another method i suppose would be having variables like: "JumpStart" and "JumpMaxHeight" and make it so when the player jumps, the jumpstart records the Y value at 'ground level' and set jumpmaxheight to the jumpstart minus however high you want him to jump.

Then if the difference between the player's Y and jumpstart goes beyond jumpmaxheight, manually set the distance and code in the falling. Although i suppose this method would be a little harder if you weren't using a custom movement, and for REALLY low frame rates it might still require the use of that 'For' loop i just mentioned

I hope i made myself clear

This... actually seems like a potentially good idea. Granted what you said is not far off from how my engine already works, but it makes me think of things a little differently. The implementation I'm now thinking would be say.. use time delta to figure out how many times to run accuracy essential logic and run it X amount of times. I used to figure this wasn't reasonably possible, but if I'm looping the essential logic say 5-10 times normally, adding or subtracting a few reps should keep things in speed.

The problem for me though is still keeping animation properly in since (which operates with delta-time in mind). It's essential for me that animations line up exactly when they should. Any way to get around this would either involve... making my own animation engine from scratch or........ Bugging Ashley to implement a feature only I'll ever use (Something like telling an animation to advance a 'tick frame' instead of a whole frame of animation). Which is a waste of time. Alas. But for our opening poster, maybe this would work!

Anyways, Ashley.

http://allefant.sourceforge.net/wordpress/vsync

Nothing professional here and I'm sure a lot of stuff you already know. Still, it talks about the whole logic vs update thing I talk about. So at least my thoughts are somewhere on base and not some unique fabrication. Again for professional examples, I think they'll be hard to find simply because, well.. Again, theres not a lot of professional level 2d computer games these days. Though as I read around, I see a lot of this stuff mentioned, though nothing solid enough to further waste your time with.

I also saw some stuff mentioned somewhere about netplay like I said earlier about FPSs and how relying on delta time for a networked game could be a bit weird. I don't know how accurate that statement is, it's just what I read from some random internet person.

Edit: Actually now that I think of it, adding a feature like the one I'd need wouldn't be that hard I don't think and might be more generally useful. Just a command like "Random Object: Advance Animation X ticks". all the user would have to do to do what I want is set animation speed to 0 for whatever objects they want to control. Not saying you should do this, but I think it might be a valid option. I'm just brain storm thought.

Also: I'm curious how collision detection works. If I were to manually run logic several times a frame, would collisions work properly on the 'inbetween' updates, or do collisions only take into account the final or previous displayed state?

i'm pretty sure collisions update between frames

so with your animations, you want to basically control when the animation goes to the next frame?

I haven't worked much with animations on construct yet cause they seem kinda broken and the features i need aren't really in it (yet?), but would you not be able to say, always set animation frame to some variable, and when you want it to progress, just add one to the variable?

I could have interpreted you wrong though

Also i realise it's quite a roundabout way of doing things, a 'next frame' feature would be handy in some cases i expect

i'm pretty sure collisions update between frames

They do. I posted a test for detectorless hitboxes somewhere around here that changes the animation of a sprite to it's hitbox, runs an overlap check, then changes back to the original animation in the same tick.

Awesome to know, thanks guys. I figured that'd be the case, so thats good to know.

Anyways, as for the animation, a counter wouldn't really work. The problem here is that i need to be able to control how many ticks a particular animation stays out. Currently all my animations are set to speed 60 so I can exactly control how long everything lasts on the screen. If this was a simplier game (IWBTG), I could just use dead/repeat frames, but considering how many frames of animation I'll need in my current game, this just isn't sensible. To adequately do my own animation system I would have to have a string for every animation (or maybe just use an array) that lists all the animation data I need. That'd sort of suck.

Again though I'm just tossing out ideas and possibilities. I want to hear Ashley's thought on how sensible they are.

when right arrow is down

--for "Move" from 0 to global('MovementAccuracy')

== Set Player.X to Player.X + 200 * (timedelta / global('MovementAccuracy')

This is essentially saying:

+ Every tick

+ Repeat 10 times

-> Set X to X + 1

instead of:

+ Every tick

-> Set X to X + 10

In other words it's identical to the simpler one - the only advantage you get is if you do all your collision testing in subevents (collisions are checked on-the-fly when the condition is run). Then the ONLY advantage you get is fast objects are less likely to skip over small obstacles. It won't directly solve any problems with accuracy.

I checked out the link you posted Kayin - it's a very good article, the best I've read on the subject. However, I'm still not convinced by variable rate logic. Firstly, as the article mentions, it could substantially increase CPU usage, especially with a high logic rate. Secondly - and I don't think the article covers this - if logic runs at a rate which is not a multiple of the V-sync rate, then you can get uneven motion. Lets consider easy numbers - VSync = 50Hz and logic = 75fps - for every VSync you alternate between 1 logic update and 2 logic updates. This means between screen updates, objects will move twice as far every refresh. I don't think this would look as smooth as the current system we have. Interpolation is an interesting idea, but I fear it's too difficult to retro-fit it to our current engine (and it would make eventing a custom movement much harder).

Assuming there was some option to run logic at a multiple of the vsync rate (eg. 5x logic runs per vsync), and assuming timers and user input were updated between these separate logic executions, I guess it might be possible to reduce the inaccuracy by reducing the quantisation effect error. I think this could be programmed like Motion Blur, but without the rendering of logic-only runs.

If it's easy to program, I might give it a shot. I don't think I can truly have keyboard input update fairly in logic-only runs, but it might work. It is a very CPU intensive way of solving the problem though - I have no choice but to execute the full event list, not just the motion/timer based ones, in logic-only runs. And I don't know if it'll even help solve the problem significantly. What do you think?

By the way, I've noticed fullscreen games run with very consistent timedelta values - they are usually exactly equal to 1 / vsync rate. It's only windowed games which suffer random timedelta variations, probably because Windows treats fullscreen apps with a higher priority.