The big TimeDelta headache

For questions about using Classic.

Post » Thu Oct 23, 2008 2:07 pm

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.
B
21
S
6
G
10
Posts: 1,024
Reputation: 7,445

Post » Thu Oct 23, 2008 2:48 pm

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.
Moderator
B
88
S
32
G
33
Posts: 3,005
Reputation: 27,432

Post » Thu Oct 23, 2008 7:05 pm

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 :P
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,580

Post » Thu Oct 23, 2008 7:45 pm

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 [/quote:2ufumjbf]

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)[/quote:2ufumjbf]

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. :lol:
B
21
S
6
G
10
Posts: 1,024
Reputation: 7,445

Post » Thu Oct 23, 2008 8:23 pm

[quote="PixelRebirth":1f2b8n6i]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?[/quote:1f2b8n6i]
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...[/quote:1f2b8n6i]
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 [/quote:1f2b8n6i]

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:1f2b8n6i]
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)[/quote:1f2b8n6i]

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. :lol:[/quote:1f2b8n6i]
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...
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,580

Post » Thu Oct 23, 2008 8:29 pm

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.
B
12
S
4
G
4
Posts: 238
Reputation: 2,426

Post » Thu Oct 23, 2008 9:17 pm

[quote="kayin":1a2fp02h]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[/quote:1a2fp02h]
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.[/quote:1a2fp02h]
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?[/quote:1a2fp02h]
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...[/quote:1a2fp02h]
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.[/quote:1a2fp02h]
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.
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,580

Post » Thu Oct 23, 2008 10:18 pm

[quote="Ashley":36ghe52w][quote="kayin":36ghe52w]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[/quote:36ghe52w]
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:36ghe52w]

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.[/quote:36ghe52w]
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]

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?[/quote:36ghe52w]
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:36ghe52w]

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...[/quote:36ghe52w]
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.
[/quote:36ghe52w]

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.
[/quote:36ghe52w]

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.[/quote:36ghe52w]
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.[/quote:36ghe52w]

If I can I certainly will!
B
12
S
4
G
4
Posts: 238
Reputation: 2,426

Post » Fri Oct 24, 2008 2:09 am

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
B
3
S
2
G
5
Posts: 351
Reputation: 2,377

Post » Fri Oct 24, 2008 4:10 am

[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...[/quote:1y7tg8ro]
I wouldn't advise this purely on the basis it will make motion less precise and you lose the smooth rendering.[/quote:1y7tg8ro]

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.
Moderator
B
88
S
32
G
33
Posts: 3,005
Reputation: 27,432

Next

Return to Help & Support using Construct Classic

Who is online

Users browsing this forum: No registered users and 5 guests