I'm not sure if Casey has a 120/144hz monitor but his development PC seems like it should be plenty powerful to handle it (though not sure of the exact specs he uses).

I realize 120fps is not considered "necessary" for the type of game Casey is making but it might open up the show to some interesting optimization discussion, at the very least having a smaller budget will make optimization issues more obvious. Things like VR also benefit from having at least 90, and people who own a 120/144hz screen will probably want the game to run 120fps or higher if at all possible.

Like all things related to monitors, it's hard to make a case for it since it's a "you have to see it" kind of issue. The best video I could find was one that filmed two monitors (a 60hz one and a 120hz one) and then ran it back at 1/4 the speed, so that they would run 15fps and 30fps respectively:

1/4 speed 60/120

Edit: For some reason just typing in links doesn't show. Here's also a video of someone using a monitor that supports switching to show that you can tell the difference.

Blind Test 60/120/144

Code Casey wrote in HH will run at whatever Hz you want. It doesn't have 60Hz hardcoded anywhere, except for fallback if you cannot get real refresh rate from OS. At startup HH will ask OS for your monitor refresh rate and will use that.

Having 120 or 90 Hz just because of VR really doesn't apply here, because game must be designed for that, and HH isn't.

That doesn't change how the game is developed to run at 60 though. All considerations are for 16.66ms frames, not 8.33ms frames. Console ports have historically had issues with 60 (going from 30) even on absurd hardware, so I don't think the assumption of "if we develop it for 60, it's just gonna work for 120" is sound, considering how much of a higher bar that sets compared to 30 to 60.

My comment on VR is a sidenote to developing at higher frame rate not HH. My point was that, for educational purposes, 120 covers a larger spectrum compared to 60. 120/144 are not uncommon these days. If someone plays mainly FPS they probably own one, and you can easily buy them from just about anywhere. Even TVs come at 144hz.

Casey said the game will be made to run everywhere, so I'm just suggesting the bar be raised a bit because 120/144hz are common enough that anyone can get one from their local computer shop more or less. Of course this is a completely philosophical point, since I just defined "any hardware" as "any hardware most people can buy with out making a special order to a specialized oversees manufacturer," but Casey's definition of "any hardware" might just very well be a fixed list that only includes 60hz monitors (and that would be fine). :)

felix_xb
That doesn't change how the game is developed to run at 60 though. All considerations are for 16.66ms frames, not 8.33ms frames.

The code passes delta for frame in game_input structure (dtForFrame member). And all relative motion calculation is using this dtForFrame variable to calculate motion. So there is no 16.66ms hardcoded anywhere.

If your CPU/GPU will be powerful enough to calculate and render everything in 8.33ms, then HH will run with 120fps just fine.

First of all, I know it's done though delta and it doesn't affect the physics. You're making me too much of an idiot in your mind. I'm talking about code that physically is unintentionally designed to only work at 60fps, regardless of hardware. And it's not something you can just say isn't there, because with out testing continuously it's always a gamble. It's no different then saying "my code worked for me, so it has no bugs." If you don't test you can't even tell if basic things like input works fine.

Secondly, if you want to argue it as "its the user's responsibility to just pump hardware into it" and ignore all other variables, then okey fine. There are 400hz monitors you can buy out there. The frame budget is therefore 2.5ms. You're telling me there's actually "consumer" hardware for that? That's an extreme example, but there are intermediate ones between 144 and 400 as well. (Before you make another totem version of my argument, no I'm not arguing for monitors above 144hz, I only presented the logical conclusion to your argument)

If we're gonna ignore hardware (by pushing it to the user's end) and just pretend it will work flawlessly everywhere even though we dont consider it when designing and writing the code then we might as well write it in java, since it's all about your CPU/GPU being powerful enough to calculate and render at your monitors refresh rate right? nothing HH needs to worry about. (I'm being sarcastic, if it's not obvious)

it's perfectly possible to have the physics engine run at 10 Hz while graphics is 400 fps.

All you really need then is decent interpolation between frames (and decoupled physics and graphics). I don't believe HMH is setup for this IIRC.

Why do you say that code "physically is unintentionally designed to only work at 60fps"? Can you clarify what do you mean by that? Because I don't think I understand what you mean by that. In my option code is not designed like that. It will run as fast as your machine will permit.

As for decoupling game state updates from rendering, code is partially set up for that - that's why we have background threads. They will update some of state (possibly AI, pathfinding, etc..) in background and won't be tied to rendering rate.

Why not fix the update rate with a fixed time step?

Example Pseudo-code:


This then decouples the input handling, game logic, and rendering entirely. This then would make game logic predictable and consistent as the time step is the same.

You could also extend it to extrapolate the positions of entities in the rendering code (kind of like Quake and many online games) by using the update_accumulator (lag buffer) to make it seem fluid (which means you can reduce the time step).

Why do you say that code "physically is unintentionally designed to only work at 60fps"? Can you clarify what do you mean by that? Because I don't think I understand what you mean by that. In my option code is not designed like that. It will run as fast as your machine will permit.

Hm. Let's say we lived in a world where monitors were commonly 30hz and there were also these 90hz ones. Okey now go watch for example some of Casey's latest debug episodes. Suddenly the problem of "windows is tacking so much of our frame time to detect if we're not using a xbox controller" switched from being answered with "that's almost a 5th of our frame time we need to fix it" to "but it's not a significant portion of time, we don't need to worry about it" / "we can deal with it later maybe".

In the context of this 30/90 fictional world where we support both, what's the point of developing using 30? What's the advantage here? Just because it so happens the machine we're on while developing is 30hz? — Hopefully you understand what I mean now

[ end 30/90 example ]

Casey uses a lot of good patterns but he also bases a lot of decisions on measurements. There's no guarantee the code Casey is using is always linear. You can make a "personal guarantee" but it's hard to back with anything solid, since how do you know that X technique in combination with Y library and in combination with Z hardware doesn't just plain scale non-linear sometimes. It's entirely possible 60 is the sweet spot where it works. Going from 60 to 120 and only needing double the hardware is the ideal, but what is it guaranteed by exactly? Also, even if we considered there aren't any "bugs" associated with switching (that somehow that can be guaranteed with out us just using 120) isn't making a "simple" game and relying on people having AAA-level hardware to run it a bit much? Yeah sure "simple" game at 120fps is a little less simple then older games, but then older games ran on much weaker hardware then even the low end phones use.

---

Just want to clarify again. I'm not saying HH needs to support 120fps or 120/144hz monitors or anything. I'm just saying that if it's intended to "run on everything" and those are included in "everything" then it makes more sense to develop it at 120fps so it can be said with confidence that "it will definitely run flawlessly" rather then the only statements that can be made being "should run" or "if you have [...] hardware maybe will run".

So I think you are confusing something... you do not have to render the game at the frequency of your monitor or be locked to that rate. A game can run at 60fps on a 120Hz monitor, it is just not going to get a lot of benefit.

Sure, it would be nice if the game was running at 120fps on a 120Hz monitor, but it's not necessary.

The actual answer is that if you design a game for 60fps instead of 120fps, it's twice as interesting :)

I actually mean that literally - a 30fps game is twice as interesting as a 60fps game, 15fps twice again, etc. "Optimization" is not something that lets you do an arbitrary amount of stuff with the same CPU just by working harder. There's a practical limit to what you can accomplish, and with optimization you are just asymptotically approaching that.

So yes, if you happen to construct a game which does not do enough simulation to need to run at 30fps but you're just lazy and let it run at 30fps instead of optimizing it to run at 60fps, that was probably a mistake. But if you actually use all the time in the 30fps to do interesting things that you can't do at 60fps on the same hardware, then the game would actually be less interesting at 60fps because you'd have to cut features.

So picking the framerate is important. You don't just go "there's a 140hz monitor so lets run at 140hz". That's a very bad idea. Instead you should ask "what is the lowest frame rate I think is acceptable for this game" and design to _that_ (for HH, I think it's 60hz).

If when you are done with everything in the design, you find that the profile looks promising for optimizing to a higher framerate, then by all means, go nuts at that point. But never intentionally limit the quality of the game just to hit a high framerate unless you are making that decision very consciously and understand that the game you're making is somehow "about" having a high frame rate (I don't doubt, for example, that a great game designer like Jon or something might have a design where it's like "the important thing here is that the frame rate is as high as possible" and that's the crucial thing, and then that project should be all about maxing out the frame rate, etc.)

- Casey

Edit: And also, I should add, that really "twice as interesting" is an understatement. It's actually likely to be be more than twice as interesting due to the fact that there's constant overhead that's per-frame. So for example, if it takes a total of 3ms to do constant overhead things like frame post-processing and input gather, etc., then the difference between 60hz and 120hz is actually ~14ms vs. ~5ms of work time, which is almost _three_ times more simulation and rendering time for the game, not two...

Going for lowest acceptable and then optimizing up is an interesting way to do it. I agree that it's probably the most economical way to do it; and least painful.

Though I have to wonder...

Given these two workflows,

1. design for lowest acceptable framerate --> optimize to higher framerate / lowend machines
2. design for highest supported framerate --> optimize lowest acceptable framerate for lowend machines (if needed) --> do extra interesting stuff for lower framerates

Is option (1) really always guaranteed to be better then option (2) ? I mean there's no doubt it should just work, and it's definitely guaranteed faster if you want to cut corners (like skip optimization work). But if we say assume that optimization, and as you mentioned "extra stuff that can only exist at the lower framerate" is absolutely mandatory then the workflow seems to be very risky with regard to refactoring.

For example, assuming you use option (1), doesn't that mean that if you say end up with HH running flawlessly on your machine but at the limit of the machine's capabilities, then your machine is now the minimum spec? Since any machine lower then your machine is technically not guaranteed to run it with out optimizations involved.

So now you go though an "optimization" step but that optimization step can literally involve ripping your game's guts out to get the result. So the question then becomes, if we're striving for getting as close as possible to the "ideal" state we want to get the game at (not the minimum shippable state) then...

Is it more cost effective to risk refactoring that's far more costly then coming up with the solution from the get go (option 1). Or, is it more cost effective to build the core of the game (albeit with potentially less "features") so it's guaranteed to run on everything by designing for the highest possible first, then scale down and add features once that's done, instead of before that's done (option 2).

An interesting dilemma.

-

Anyway, thanks for answering Casey. My suggestion was more for the sake of educational purposes, but maybe it's more educational if you just do it as you would if you weren't streaming any of it, so I guess 60fps it is.

In games, it is almost never acceptable to give players a different Gameplay experience. This is the actual fun part of the game. You can have terrible graphics, but if the game design is fun, people will still play it. You can always add better graphics. The gameplay is the thing people actually buy.

So the first part of building a game is always finding that fun space to play in. Then you can worry about optimizations.

And Casey has shown how to avoid tying ourselves too deeply to a single refresh rate.

Not to mention, this is a great area for you to explore, on your own, which is kinda the point ot HMH.

@BillDStrong, is that in reply to me?

I'm biased towards fighting games so um ya there's that.

Similarly I also consider the smoothness, fast action and colorfulness of games of higher priority then things like lighting, shadows and so on. Not that I disregard them by any means, its just not very interesting to have very well lit and shaded grey tones everywhere.

IMO quite a few genres, such as 2D games (in particular sidescrollers, bullet hells and similar), and people tell me competitive shooters (though personally I rarely play those), benefit more from smoothness then anything else (you have to be smooth to see the details).

From my perspective that basically all translates to get as high framerate as makes sense (and monitor refresh rate is where it usually makes sense) since at high speeds everything should "flow" on screen not teleport.

I'll try to prove the point...

Move your mouse left to right slowly (2s interval) between the following two points. I've left some white space so you can easily avoid the text cursor. Accuracy here doesn't matter, feel free to go over.











Now progressively move faster between those two points. And then faster and then faster still. An average consumer non-gaming laser mouse polls at around 120-130hz at that speed (90hz average). At some points you'll start seeing multiple mouses. Partly because OSes are pretty terrible at displaying mouse cursors (I guess).

To avoid OS bias too much please slow down just enough so you dont see doubles. Then pay close attention of how smooth the mouse cursor looks, then look at how smooth your hand looks while doing the motion? You can see all the detail, etc.

Try moving your hand as fast as you can. Unless you have super hands, you will find it really hard to get to the point of moving your hands fast enough that you create after images while you move. And that also, its really hard to move fast enough that you dont see details.

Most of the detail on your mouse is probably on the top and/or the side so just flick it left and right using just two fingers to hold it, see how fast you have to flick it to even get to a point where you can't notice details on it (its extremely hard). In case you're confused about what I mean by can't see details just take your hand off the mouse and flick it from the wrist really fast, you will easily get to a point where you can't quite make up the details on your fingers.

Anyway, that's why I appreciate framerate, the higher it is (and assuming your monitor is up to the job), the more details are visible while in motion, hence the more details actually exist.

The same difference as looking at the mouse on screen and your actual motion.

Also, details that require motion (regardless of your motion) will benefit the same way. You probably want to get smooth animations in the game not teleporting doodads. So even if you're character/whatever in the game is not moving framrete still feels like a essential component that ensures everything else actually works.

Fundamentally its a quantity vs quality tradeoff (kind of), so everyone's free to choose whatever they wish for their game.

felix_xb
Is it more cost effective to risk refactoring that's far more costly then coming up with the solution from the get go (option 1). Or, is it more cost effective to build the core of the game (albeit with potentially less "features") so it's guaranteed to run on everything by designing for the highest possible first, then scale down and add features once that's done, instead of before that's done (option 2).

Well the idea is more that the programmer should have some idea of what their budget is and what is reasonable to accomplish. So going into it, you want to know "I have 15ms to work with" or something like this, so that the programmer can make decisions about what is likely to be possible in that time. Obviously with games being as complex as they are, this is not a precise thing, but it's important to understand.

As you work through the production of the game, you generally want to try to stay in the zone of that budget on the higher-end machines, and then the expectation is that you can optimize up the lower-end to be within the budget. Generally you should not be doing a bunch of stuff that you don't have expectations about in terms of optimization. You might not do the optimizations up front (and probably shouldn't), but you shouldn't be making something you don't know how you would optimize later.

You also should not be doing things that will require a complete rewrite of the codebase to optimize. That's not generally what we mean by "optimization". The notion that you can "get it right from the get go" is really a fallacy, because since the entire game is one big machine (especially considering how many concurrent things there are - multiple cores on both the CPU and GPU, etc.), thinking you can make one piece optimal before you've got everything in place is probably erroneous thinking.

So generally speaking, I don't think the dichotomy you're getting at really exists at all. There's simply a notion of what is reasonable to attempt, and that is constrained by the mandatory frame rate. The only thing "picking 120hz" at the beginning really does is mean that you're going to be much less aggressive with your game design in exchange for knowing you can hit a high framerate. Personally, I am not very sensitive to frame rate, so I would essentially never make that tradeoff. I'm actually plenty happy at 30hz for nearly everything, and for non-action games I actually prefer 24hz. So I'd always have low frame rates and more complexity/quality. Other people believe they get something for 60hz, so they might make different design tradeoffs.

With VR, obviously it's a different story, because you have to be above 90hz or people get sick. So if you're making a game that's meant to be experienced in VR then you need to make those design tradeoffs and accept a more restricted game design and less complex graphics in exchange for knowing you can hit the frame budget. And in VR, this is not amortized either - you can't hit 90 "most of the time" and then miss occasionally, because that will still cause people problems.

So yeah, if VR is you're thing, expect to take your frame rate a lot more seriously and expect to have to make concessions in the design of your game and graphics as a result.

- Casey