> 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]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]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.
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]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!