next »

[FrankForce]

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.

Aha, I think I get it now. You are mainly talking about how if someone presses a key really fast it won't be registered? This is also an issue of someone presses the same key twice within the same frame? What you need to do is set up an input buffering system. Rather then polling the instantaneous value of whether the key is currently up or down. My game engine does this.

When I say "is best when" I mean it that way. The specification for better is: reacts more consistently to input and better performance for cpu-bound games.

No, both ThemsAllTook and I concur that your engine will not work properly if the refresh rate is lower then the time step. I suppose you are technical correct but the implication is wrong. For example I could say "My car drives best when it has gas." While correct this implies that it can drive without gas, maybe if you were rolling down a hill or someone was pushing which is possible but misleading.  It makes more sense to say "My car only drives properly when it has gas."

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.

That would be a really nice setup! I'm not sure how much variance will be introduced by the os and stuff even if it is on it's own thread. There needs to be time stamping at the hardware layer to really do it properly. I think this is probably overkill at least for me at this point. I have separately threaded input that keeps a buffer and tracks sub frame input like keys that may have went up/down one or more times. That seems to be enough for now.

[ThemsAllTook]

Not sure about this, it will certainly be worse for a light-weight game like TrapThem since it is natively in sync with all the happening the way it is.

It sounds like it's not, though - your simulation doesn't run at a constant speed. With all of your focus on perfect simulations, I'd have expected that to be of value to you.

A delay is always a benefit and not a con for the player in Trapthem.

Sure, but do you really want to be handing out that benefit in situations where the system is overloaded or your screen refresh rate is something other than 60Hz? If I play it on an old computer that's only capable of running it at 30Hz (or less), or play on a display running at less than 60Hz, I'm going to have a sluggish gameplay experience that makes things much easier than if I were playing on a more capable system. It is a game design issue though, and not having played your game, I can't judge for myself whether it makes sense or not. It just seems like you're allowing your game design to be negatively influenced by a technical hurdle that could be overcome without too much trouble.

[J-Snake]

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.

Aha, I think I get it now. You are mainly talking about how if someone presses a key really fast it won't be registered? This is also an issue of someone presses the same key twice within the same frame? What you need to do is set up an input buffering system. Rather then polling the instantaneous value of whether the key is currently up or down. My game engine does this.

I am talking about the fundamental difference in pressing and releasing a key. For some cases buffering can be appropriate, in my game it certainly isn't. In general buffering is a flaw trying to correct another flaw. Many games/situations are not about registering a combo-input. In ideal case they are about reacting to the actual input in the actual happening.

[J-Snake]

It sounds like it's not, though - your simulation doesn't run at a constant speed. With all of your focus on perfect simulations, I'd have expected that to be of value to you.

It is important to set a mindset that games (in general) are not simulations in the sense of keeping up with the wall-clock. The main thing that is important is that every frame is exectuted like it should, regardles it is perfectly displayed with the wall-clock or not.

[ThemsAllTook]

It is important to set a mindset that games (in general) are not simulations in the sense of keeping up with the wall-clock. The main thing that is important is that every frame is exectuted like it should, regardles it is perfectly displayed with the wall-clock or not.

Of course. But if you can do both, why wouldn't you want to?

[J-Snake]

You don't do both in a threaded solution. You might buffer the last input-frame in order for it to make sense at all. Then it means that the used input is not in sync with the actual happening at the point of an update. While in a sequential solution it is always perfectly in sync: the actual happening is using the input it actually receives, not a buffered one.

[ThemsAllTook]

You don't do both in a threaded solution. You might buffer the last input-frame in order for it to make sense at all. Then it means that the used input is not in sync with the actual happening at the point of an update. While in a sequential solution it is always perfectly in sync: the actual happening is using the input it actually receives, not a buffered one.

I dunno, I think you could have as little or less input latency with a threaded/buffered input system as with a synchronous one. The kernel has to buffer your events in some form anyway to deliver them to you. I'll see if I can make a working prototype of this concept tonight...

[FrankForce]

J-Snake: Lets say I'm running your game and want to cheat. All I need to do is run another program to make my computer really slow. Then when I play your game it will run in slow motion so I can win much easier and get a high score. Do you see why this is bad? If your game was networked it would completely break things.

If someone tried to slow my game to 30 fps it would not run at half speed but instead skip every other frame and still be basically normal.  If they slowed it down to 15 fps it would still run at the same speed only skipping 3/4 of the frames! They would have to slow it down below 15 fps which is what my min frame rate is capped to and deal with the long gaps between frames, it wouldn't be very playable like that.

[J-Snake]

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.

[J-Snake]

You don't do both in a threaded solution. You might buffer the last input-frame in order for it to make sense at all. Then it means that the used input is not in sync with the actual happening at the point of an update. While in a sequential solution it is always perfectly in sync: the actual happening is using the input it actually receives, not a buffered one.

I dunno, I think you could have as little or less input latency with a threaded/buffered input system as with a synchronous one. The kernel has to buffer your events in some form anyway to deliver them to you. I'll see if I can make a working prototype of this concept tonight...

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. It is because you will poll it up to one frame earlier. It is a logical consequence if you think about it.

[FrankForce]

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.

[ThemsAllTook]

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.

[J-Snake]

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.

[J-Snake]

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.

[FrankForce]

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.

[gimymblert]

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.

[J-Snake]

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.

[J-Snake]

but when J-snake is involved it's not technical, it's philosophical

I am both.

[FrankForce]

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.

[J-Snake]

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.