Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

999613 Posts in 39235 Topics- by 30648 Members - Latest Member: lonelytomato

April 24, 2014, 12:51:06 PM
TIGSource ForumsDeveloperTechnical (Moderators: Glaiel-Gamer, ThemsAllTook)Why deltas fluctuate and how to fix them - A rendering thought experiment
Pages: 1 2 [3] 4
Print
Author Topic: Why deltas fluctuate and how to fix them - A rendering thought experiment  (Read 2144 times)
FrankForce
Level 1
*


This tepid water is tasteless.


View Profile WWW Email
« Reply #30 on: April 10, 2013, 01:30:47 PM »

I don't see a satisfying argument in this. If the player wants to cheat there are plenty of ways to do so. Looking up for puzzle-solutions on youtube is just one of them. If you want to sacrifice quality of play for problems the vast majority won't even bother to encounter, it is your choice.

What if players don't even know they are cheating, they are just running your game on a slower machine and wonder why it is so easy because it's slow? Maybe it's not even a slow computer but it's just slow because I have updates running or some other reason. I'm sorry but you are really not thinking straight about stuff and the only way to solve your problems is to realize that and go back to basics. Not to be a dick but I've been doing this for a long time. I'm going indie now but in the past I've worked for Midway Games, Volition and Sony. What qualifications do you have that makes you think you know more then me or ThemsAllTook on the topic? I can't find anything on you other then some youtube videos, not even a single game I can play.
Logged
ThemsAllTook
Moderator
Level 10
******


Alex Diener


View Profile WWW
« Reply #31 on: April 10, 2013, 01:31:34 PM »

You can try. But you will always have the uncertainty that your input will be off up to one frame compared to the sequential solution.

I'll account for that and add detailed logging and a mode switch so you can compare synchronous to threaded. Will post here when done.
Logged
J-Snake
Level 10
*****


a fool with a tool is still a fool


View Profile WWW Email
« Reply #32 on: April 10, 2013, 01:46:44 PM »

they are just running your game on a slower machine and wonder why it is so easy because it's slow?
If the machine is too slow to handle it then why even bothering to catch-up if it cannot do it justice, better providing a set of options to reduce visual fidelity, vsync on/off options and stuff like that.

I see what you want to say. But all of it is disrespecting quality of play. I think the goal should be to provide the user the intended experience, not to account for all the faults he is responsible himself by crappily catching-up.
« Last Edit: April 10, 2013, 01:57:48 PM by J-Snake » Logged

Independent game developer with an elaborate focus on interesting gameplay, rewarding depth of play and technical quality.

Super Metroid Tournament: http://forums.tigsource.com/index.php?topic=38039.0

TrapThem: http://steamcommunity.com/sharedfiles/filedetails/?id=222597670
J-Snake
Level 10
*****


a fool with a tool is still a fool


View Profile WWW Email
« Reply #33 on: April 10, 2013, 02:40:15 PM »

You also seem to suffer from "I have to keep up with the wall-clock"-syndrom. It is a correct understanding when it comes to the necessity of hard real-time systems but it is a fundamentally flawed understanding in gameplay-systems. The main necessity is that the actual frame is reacting to the actual input, not so much that all the happening keeps up with the wall-clock. So here is where my solution is superior. You can expect that no screen and no update-rate is exactly at 60hz.
The monitors can be 59.7 or 59.9. You would rather want to update with their rates to be perfectly in sync (since possible) instead of trying to keep more exact 60fps. That will bring you in this stutter cicle of consecutive delays and catch-ups: You have heavily influenced a flaw and now you are trying to compensate this flaw with another flaw by averaging delta values despite it can only greatly make sense for causal systems.
Logged

Independent game developer with an elaborate focus on interesting gameplay, rewarding depth of play and technical quality.

Super Metroid Tournament: http://forums.tigsource.com/index.php?topic=38039.0

TrapThem: http://steamcommunity.com/sharedfiles/filedetails/?id=222597670
FrankForce
Level 1
*


This tepid water is tasteless.


View Profile WWW Email
« Reply #34 on: April 10, 2013, 03:15:10 PM »

J-Snake

The code you wrote "if (elapsedTime > 2.0 * frameTime)", will that ever be true on a computer that meets your requirements?

Think about it for a second. If your game runs as well as you say then it should never be true because the computer will always be able to keep up. Am I wrong about that?

In fact your solution works out to be identical to using a while loop in this situation. The only difference between the two methods is what happens when a computer is too slow for at least one frame to not be able to keep up and/or running on a lower refresh rate monitor. Follow me so far?

But you also say that you don't really care about players whose systems are too slow. Yet your code only does anything different when the computer is too slow to keep up....  am I making any sense at all to you? I hope so because I'm out of ideas and you've completely train wrecked this thread.
Logged
Gimym JIMBERT
Level 10
*****


Feminism is back!


View Profile Email
« Reply #35 on: April 10, 2013, 03:21:59 PM »

I thought it was a technical discussion, but when J-snake is involved it's not technical, it's philosophical (a vision of gameplay), problem is that people answer in technical way.
Logged


ILLOGICAL, random guy on internet, do not trust (lelebĉcülo dum borobürükiss)
J-Snake
Level 10
*****


a fool with a tool is still a fool


View Profile WWW Email
« Reply #36 on: April 10, 2013, 03:33:54 PM »

J-Snake

The code you wrote "if (elapsedTime > 2.0 * frameTime)", will that ever be true on a computer that meets your requirements?

Think about it for a second. If your game runs as well as you say then it should never be true because the computer will always be able to keep up. Am I wrong about that?

In fact your solution works out to be identical to using a while loop in this situation. The only difference between the two methods is what happens when a computer is too slow for at least one frame to not be able to keep up and/or running on a lower refresh rate monitor. Follow me so far?

Yes, that will be true, but it will also prevent it will never go above 2*frameTime in unideal situations. The point of it is that in slow downs it should properly interpolate. It will be even identical to the non-interpolated actual position, which is a plus. While in a while-loop deltas will vary wildly.

However your conclusion is wrong.  This solution is not identical to the one with "while-catch-ups" because I will never do catch-ups while a while-solution eventually will, even in non-bottlenecked 60fps on a 60hz screen. It is because the mesuared delta is not perfectly accurate and can vary. Have you seen complaints about xna's fixed timestep all over. That's the reason why.

Think about how the cycle of consecutive delays and catch-ups arises.
Look what people are observing on their machines: few seconds everything runs smoothly followed by few frames of "stop,jump,stop,jump..." and then the cycle repeats. You can explain on a conceptual level why this is prone to happen with a while-loop.
« Last Edit: April 10, 2013, 03:57:58 PM by J-Snake » Logged

Independent game developer with an elaborate focus on interesting gameplay, rewarding depth of play and technical quality.

Super Metroid Tournament: http://forums.tigsource.com/index.php?topic=38039.0

TrapThem: http://steamcommunity.com/sharedfiles/filedetails/?id=222597670
J-Snake
Level 10
*****


a fool with a tool is still a fool


View Profile WWW Email
« Reply #37 on: April 10, 2013, 03:50:44 PM »

but when J-snake is involved it's not technical, it's philosophical
I am both.
Logged

Independent game developer with an elaborate focus on interesting gameplay, rewarding depth of play and technical quality.

Super Metroid Tournament: http://forums.tigsource.com/index.php?topic=38039.0

TrapThem: http://steamcommunity.com/sharedfiles/filedetails/?id=222597670
FrankForce
Level 1
*


This tepid water is tasteless.


View Profile WWW Email
« Reply #38 on: April 10, 2013, 03:55:29 PM »

Yes, that will be true, but it will also prevent it will never go above 2*frameTime in unideal situations. However your conclusion is wrong.  This solution is not identical to the one with "while-catch-ups" because I will never do catch-ups while a while-solution eventually will, even in non-bottlenecked 60fps on a 60hz screen. It is because the mesuared delta is not perfectly accurate and can vary. Have you seen complaints about xna's fixed timestep all over. That's the reason why. Think about how the cycle of consecutive delays and catch-ups arises.

So, let me make sure I understand correctly. You agree that if that line of code gets hit in your game it will cause stutter. You also seem to agree it will happen even on an ideal PC because there is some measured time variance. You are willing to accept this stutter because somehow it makes the input better. Is that correct to say?

My method is designed minimize visual stutter and eliminate the delta fluctuations. My PC isn't super amazing but my engine runs super smooth in full screen mode. The input handling feels plenty responsive to me and is on par with any modern console game (I've worked on many). It wasn't always this smooth, I've been working on this game engine for about 5 years now. You can try my game engine and see for yourself.
Logged
J-Snake
Level 10
*****


a fool with a tool is still a fool


View Profile WWW Email
« Reply #39 on: April 10, 2013, 04:11:41 PM »

That line of code will only cause a stutter in a bottleneck situation so there is no down to it.
This line is constantly true when I run a 60fps game on 60hz screens since they are slightly slower than 60. It implies that the game is running perfectly smooth and the interpolation corresponds to the actual position on the screen, not somewhere in between when it is not necessary (it auto-adapts).

My system is not only minimizing visual stutter. It also maximizes more consistent and relyable input-response in a fixed update. You cannot get any better than this in its technical execution.

You have to build sportive scenarios in order to evaluate your engine since "feels smooth to me" isn't enough. If it looks consistent 60fps thanks to interpolation people will tend to believe it. Most people are also not able to tell the input-response of 30 vs 60 hz. They are more likely to tell it in a car-driving game than in games where they just randomly walk around. A hard test would actually be an engine to pass my requirements for TrapThem. I can often feel when a catch-up would steal 8% of a time-window for certain actions.

It basicly boils down to this, if you have catch-ups when there shouldn't be any then your solution isn't as ideal as mine regarding my specs. However your solution can cover a wider range of requirements, it is only that I don't consider them as important as keeping strictly to my specs.
« Last Edit: April 10, 2013, 04:26:01 PM by J-Snake » Logged

Independent game developer with an elaborate focus on interesting gameplay, rewarding depth of play and technical quality.

Super Metroid Tournament: http://forums.tigsource.com/index.php?topic=38039.0

TrapThem: http://steamcommunity.com/sharedfiles/filedetails/?id=222597670
ThemsAllTook
Moderator
Level 10
******


Alex Diener


View Profile WWW
« Reply #40 on: April 10, 2013, 04:19:18 PM »

You have to build sportive scenarios in order to evaluate your engine since "feels smooth to me" isn't enough.

Help us understand what you mean when you say sportive. The dictionary definition doesn't seem to make sense for the way you're using it. In what way are you evaluating your engine other than "feels smooth to me"?
Logged
J-Snake
Level 10
*****


a fool with a tool is still a fool


View Profile WWW Email
« Reply #41 on: April 10, 2013, 04:34:31 PM »

By "sportive games" I mean games where sudden changes of actions do matter.

My TrapThem is a good example. An input frame can already decide whether you stop or move over the next whole grid-cell. If you release the directional keys in an accidental catch-up frame after reaching a grid-cell, this frame is registered and you will walk to the next grid-cell despite you should stop. In my game a catch-up can steal 8% of the time-window in the movement-cycle.

All the talk basicly boils down to this, if you have catch-ups when there shouldn't be any then your solution isn't as ideal as mine regarding my specs. However your solution can cover a wider range of requirements, it is only that I don't consider them as important as strictly keeping my specs.
Logged

Independent game developer with an elaborate focus on interesting gameplay, rewarding depth of play and technical quality.

Super Metroid Tournament: http://forums.tigsource.com/index.php?topic=38039.0

TrapThem: http://steamcommunity.com/sharedfiles/filedetails/?id=222597670
Geti
Level 10
*****



View Profile WWW
« Reply #42 on: April 10, 2013, 10:32:03 PM »

Oh man, J-Snake threads are the best.

@OP: your solution is as ideal and simple as I've seen, though a quick google shows you might have been spamming this around a little Smiley

I don't have much more to add* other than delta fluctuation most of the time being a non-issue as most people have said. That doesn't mean it's not worth implementing, because if you've got a frame independent renderer it may as well work as well as possible (including degrading gracefully).

*(I'm holding off from smacking J-Snake. We all know he hasn't shipped anything and his game's full of bugs anyway.)
Logged

FrankForce
Level 1
*


This tepid water is tasteless.


View Profile WWW Email
« Reply #43 on: April 11, 2013, 12:06:31 PM »

@OP: your solution is as ideal and simple as I've seen, though a quick google shows you might have been spamming this around a little Smiley

Yeah, thanks! Sorry for the spam but I think this is worth sharing but I need to practice my blogging skills. At a certain point I realized that writing articles are a waste of time if I can't get anyone to read them. I would like to write more often about things that come up during development. Also, as an independent developer I need to use all my resources get noticed.

I agree that it may be subtle but I wouldn't call it a non-issue, it is always present unless corrected for. For years I put so much work into my engine trying to eliminate the stutter but there was always some present no matter what I did. I finally took the time to really dig into it to find this last piece of the puzzle and its under 10 lines of code...

Code:
// this buffer keeps track of the extra bits of time
static float deltaBuffer = 0;

// add in whatever time we currently have saved in the buffer
delta += deltaBuffer;

// calculate how many frames will have passed on the next vsync
const int refreshRate = GetMonitorRefreshRate();
int frameCount = (int)(delta * refreshRate + 1);

// if less then a full frame, increase delta to cover the extra
if (frameCount <= 0) frameCount = 1;

// save off the delta, we will need it later to update the buffer
const float oldDelta = delta;

// recalculate delta to be an even frame rate multiple
delta = frameCount / (float)refreshRate;

// update delta buffer so we keep the same time on average
deltaBuffer = oldDelta - delta;
Logged
Crimsontide
Level 3
***


View Profile
« Reply #44 on: April 12, 2013, 03:05:45 AM »

Let's observe it more closely: Whenever you press a key it is alway at least the duration of a frame so it will register (so delay is no problem)(analog-like inputs can act differently but it still doesn't make a plus on both sides(delays or catch-ups). But whenever you release a key it is nearly an instant moment. Now assume a game is accidently in two very fast update-frames in a row (like it would happen in TrapThem when I would use a catch-up loop). It practically means that the catch-up frame will take your input when you release it in that unfortunate moment. That is not what you wanted. TrapThem is a grid-based game, you cannot stop between the grid-cells. It would mean that at times you are more prone to go one grid-cell further than you should. The time it takes to reach the next grid-cell are 12 frames. In my solution you will always have them. In a solution with catch-ups you would take one frame away at times. And it is something you will feel. I tested all this and the difference is significant. I think people should thoroughly think the mechanical details through when they aim at sportive quality.

Alright, sure, I see where you're coming from. I think I have an alternate solution that gives the best of both worlds: Suppose you have a separate thread for input, which runs independently of your simulation and rendering thread(s). It's able to accept input at 60Hz or more, regardless of your render thread blocking on vsync or other such things. Each input event is given a timestamp when it comes in, and is queued up to be processed by the simulation thread. The simulation reads the timestamps of inputs as it processes them, and uses that to distinguish inputs that changed between two frames, even if it's catching up and processing both of those frames at once. It seems to me like this would allow your simulation to run at a constant speed, allow the renderer to miss a frame here and there if it can't keep up, and keep the high input resolution you desire.

Being able to implement this depends somewhat on capabilities of hardware, OS, development environment, and system APIs, but it should be doable just about anywhere if you either have preemptive multithreading or an input API that gives you timestamps.

Its a good idea, but can you really do it under windows?  The standard message queue doesn't have time stamps for messages.  Perhaps raw input does?  Not sure.  But the main thread in Windows holds the message queue (putting it on another thread is near impossible) which runs all your windowing code (since you want to keep the window on the same thread as the message queue thats running it), which in turn means most of your rendering code is again on the main thread.

As great idea as it is, I can't see it being easy to implement without OS support (and trivial with).

I really wish a gamer-orientated OS (or perhaps a mode for current OS's) was available that focused on latency and consistency and not just max fps or highest throughput.  Its seems silly that in many games it takes longer to get my input from my mouse to my screen 3 inches away than it takes to get the multiplayer data from another guy across the world.
Logged
Pages: 1 2 [3] 4
Print
Jump to:  

Theme orange-lt created by panic