- 01Describe what feels wrong
- 02Establish a baseline you can repeat
- 03Change the preset alone first
- 04Evaluate a frame limit separately
Based on the linked sources and original analysis. No first-hand playtesting is claimed.
The verified graphics lead
Low graphics is a useful first comparison when He Who Watches performs poorly. In a September 6 discussion, developer Danga identified volumetric fog as the likely reason a player's GPU load differed sharply between Medium and Low. In a separate September 5 reply, the developer stated that Low disables volumetric fog. These statements support testing the preset; they do not establish that fog causes every stutter or that Low guarantees smooth performance on every machine.
The hub-performance report also described irregular movement animation. The developer considered that worse than expected and asked for feedback from the pause menu while the problem occurred. That remains an important distinction: a likely explanation for one graphics-load difference is not a confirmed diagnosis for every symptom in the same report.
The workflow below is original general troubleshooting built around that narrow developer lead. It has not been benchmarked on a test machine for this article. Use it to make a clean comparison in your own setup, preserve the results, and decide whether you have a useful workaround or an issue that needs a report.
Describe what feels wrong
Start with the visible symptom. Is motion consistently slow, does the image pause at intervals, or does an input appear to skip part of its animation? Does the problem happen while standing still, turning, or moving through a hub? These observations are more useful than a single statement that performance is bad.
If you have a frame-rate display already available, record the values you see, but do not let one number replace the description. A game can show an acceptable average while still producing noticeable pauses. Conversely, a lower but steady rate may feel more predictable. The support question is about your observed experience, not just the highest number reached in an empty scene.
Keep crashes and system restarts in a separate category. They call for a different response from a modest frame-rate difference. Do not repeatedly run a scene that makes the whole machine restart just to collect another performance sample. The crash-and-feedback page explains how to record that symptom without treating it as an ordinary benchmark.
Establish a baseline you can repeat
Choose a location you can return to and a short action you can repeat, such as a small turn or a brief movement along a visible part of the hub. Record the chamber name, graphics preset, resolution if available, frame limit if you use one, and whether the machine is on its normal power setup. Keep the test short enough that the room state remains easy to recover.
Observe the same action a few times before changing a setting. A one-off pause during a transition may not represent the steady behavior of the scene. You are looking for a pattern clear enough that a later comparison can meaningfully differ from it. Do not spend an entire play session collecting numbers when a brief observation already establishes the problem.
The baseline is your local reference, not a universal benchmark. Another player can use the same preset on different hardware and obtain a different result. Record enough context to make your own before-and-after comparison fair without presenting it as a promise for everyone else.
Change the preset alone first
Select Low in the game's graphics options, using the menu labels visible in your copy. Return to the same scene and repeat the same short action. Keep other settings unchanged for this first comparison where practical. The purpose is to see whether the preset change produces a noticeable difference under similar conditions.
The original player report changed both graphics quality and the frame limit. Its result therefore does not isolate the effect of one variable on its own. The developer's fog explanation makes the preset a strong lead, but a controlled local comparison can tell you more about your particular setup than copying several changed values together.
If Low clearly helps, you have a practical setting choice. You do not need to restore a poor configuration repeatedly to prove the improvement. Note what became better and what remained unchanged. A reduction in load with persistent hub pauses is a different result from both symptoms disappearing, and the difference matters for a useful report.
Evaluate a frame limit separately
If the game exposes a frame limit in your current menu, you can compare a lower limit as a second test. Keep the graphics preset fixed while making that comparison. This is general graphics troubleshooting, not a developer-confirmed cure for this title. Use a value that makes sense for your display and preferences rather than copying another player's number as an ideal target.
Observe whether the limit changes consistency, responsiveness, and the symptom you originally described. A lower target can change how hard the system works, but the actual result depends on the setup and scene. Do not infer a specific temperature or load reduction without measuring it on your machine.
If you change the frame limit and the graphics preset together for convenience, record them as a combined test. That is still useful if the goal is a comfortable configuration. It simply cannot tell you which change produced the improvement. Honest labeling preserves the value of the result without claiming an experiment you did not perform.
Compare hubs with smaller scenes
The developer noted that hubs are larger, while also saying the reported behavior sounded worse than expected. You can help distinguish a scene-specific issue by comparing the same basic action in a hub and a smaller room you can access. Keep the graphics settings fixed during that comparison.
Record whether the problem appears in all hubs you have checked or only one named chamber. Do not generalize from the one space where you first noticed it. A report about a particular hub gives the developer a more focused place to investigate than a statement that all large areas are broken when you have tested only one.
If the problem follows a particular view within the hub, note the visible landmark or direction. This does not prove which effect or object is responsible, but it can make the behavior easier to reproduce. A short view description is often more useful than an unsupported guess about the rendering engine.
Keep motion problems distinct
An animation that appears to cover two tiles at once is not automatically an input-binding problem. Likewise, left and right turning the character instead of moving sideways is not automatically a frame-rate problem. Compare the final position and facing direction after one deliberate input. This helps you decide whether to investigate timing, input state, or both.
The known Shift workaround has a specific symptom and a developer answer of its own. Use that page if rotation replaces sideways movement, especially after the overlay. Do not combine it with graphics changes unless you have observed both issues and are testing them separately. Otherwise you may lose the ability to tell which change helped.
If the scene pauses but the final action is correct, say so. If the final state itself differs from the input you expected, say that instead. The developer can use those distinctions to separate a visual presentation issue from an action that may have been processed differently.
Record system context without guessing
Include the operating system, processor, graphics device, memory, and whether you are playing through a compatibility layer when you can identify them. Use the names reported by your system rather than a vague description such as a gaming laptop. You do not need to expose unrelated personal information to provide useful hardware context.
If you are unsure about a component, mark it unknown until you can check. Do not infer a graphics model from the brand of the computer or from a marketing sticker. Precise information is useful, but invented precision can send support in the wrong direction.
Also record whether other demanding work was running during the comparison. This is not a reason to blame every background application. It simply helps explain why two local observations may differ. Keep your tests under broadly similar conditions if you want to attribute the difference to a game setting.
Interpret GPU usage carefully
High GPU usage by itself does not identify a bug. Its meaning depends on the workload, settings, frame target, and the symptoms you observe. The developer's comment gives a likely explanation for the difference between two presets in one report, not a threshold above which every system is malfunctioning.
If you already monitor usage, record it alongside the scene and settings rather than as an isolated number. A value from a hub and a value from a menu do not form a clean comparison. The same applies to measurements taken after different lengths of play or with other work running in the background.
Do not copy another player's temperature values as a safe or unsafe limit for your hardware. This page is not a hardware diagnostic manual. If the computer itself shuts down or restarts, stop treating the session as a performance test and use appropriate device support along with a factual game report.
Avoid unsupported optimization recipes
The sources here do not establish special launch flags, registry edits, deleted configuration files, or a game-specific driver override that fixes hub stutters. A long list of such changes would make the article look comprehensive while reducing the reliability of its advice. Start with the documented preset lead and ordinary observable comparisons.
General maintenance, such as keeping supported software current, may be appropriate for your system, but it should not be advertised as a proven He Who Watches fix. If you change a driver or operating system component for your own reasons, record the before-and-after state and avoid changing several other variables in the same test.
Do not sacrifice a working setup to chase a target from someone else's machine. The useful outcome is stable, comfortable play on your hardware. A modest preset that works consistently can be a better practical choice than a more demanding one chosen solely because a comparison video used it.
Use the numeric values now shown in menus
The September 4 patch adds displayed values beside sliders. Where your relevant option uses a slider, record that displayed value rather than describing its position vaguely. This makes a settings comparison easier to repeat and a support report easier to interpret.
The change does not establish the names or ranges of every option. Read the current labels in your menu and preserve them in your notes. If you are comparing with another language, include a screenshot or a short description of the function rather than assuming a translated label is identical to an English guide.
Keep a small settings record for the configuration you prefer. If you experiment later, you can return to that known local baseline without remembering where several sliders happened to be. This is especially useful when the setting that affects comfort is different from the setting you are changing for performance.
Decide whether the workaround is enough
If Low removes the problem and the visual result suits you, continuing with it is a reasonable practical outcome. You can still report the original behavior if you have a clear description. There is no requirement to keep troubleshooting after your own goal of comfortable play has been met.
If Low improves load but not the pauses, keep the two results separate. The preset may be useful while another issue remains. That is more informative than saying it did not work at all. It tells the developer which part of the reported experience changed under the recommended comparison.
If there is no visible improvement, stop repeating the same test without a new question. Gather the scene, settings, and symptom details and use the feedback route. A negative result is useful evidence when the conditions are clear; it does not need to be converted into a confident theory about a bottleneck.
Send feedback while the problem is relevant
In the hub-performance thread, the developer specifically asked for a pause-menu feedback report while the lag was occurring. Follow that route if the game remains usable enough to do so. Describe the hub, the action, the preset, and whether the same behavior appears elsewhere. Include the result of your Low comparison.
A short report can state that a named hub pauses during a simple turn, a smaller room does not, and the preset change reduced load without changing the pauses. That is a report pattern, not a claim about your machine. Use only the observations you actually made and leave untested comparisons out.
If you attach a recording, keep it focused on the reproducible moment. Explain the input and the expected motion so the developer can distinguish a deliberate pause from the problem. Mark secret areas appropriately if posting publicly, and avoid exposing unrelated desktop content in the capture.
Recheck only when something relevant changes
After choosing a workable setup, revisit the issue when a relevant update, hardware change, or new developer instruction gives you a reason. Repeating the same benchmark every session adds little information. A dated note makes it possible to compare a later change with the state you already documented.
Do not assume that any new patch fixes performance unless its notes or your observations establish that result. The September 4 announcement covers puzzle and menu changes, not a universal stutter fix. Keep a later improvement tied to the build and conditions where you observed it.
The useful support loop is small: describe the symptom, compare one setting in the same scene, keep the result, and report a persistent issue with context. That makes the developer's fog lead actionable while preserving the distinction between a confirmed setting behavior and an unresolved performance diagnosis.
Read a small comparison log
Imagine a local log with three entries: a hub on the original preset, the same hub on Low, and a smaller room on Low. This is a suggested test structure, not benchmark data from this article. The first pair asks whether the preset changes the symptom. The second pair asks whether the remaining behavior depends on the scene. Keeping those questions distinct makes the results easier to interpret.
If the hub improves on Low and the smaller room is also smooth, you have a practical configuration to use. You can report the original issue with the settings context, but you do not need to keep changing options merely to produce a more elaborate explanation. The local goal of stable play may already be met.
If the hub improves only partly while the smaller room behaves well, name the remaining symptom. It might be a brief repeated pause, an abrupt animation, or another visible effect. Do not collapse the partial improvement into either completely fixed or no difference. The distinction gives the developer a clearer picture of what the preset affects.
If both scenes show the same problem, the comparison has not isolated a hub-specific issue. That does not prove the cause lies outside the game. It simply means that scene size, under the conditions you tested, did not separate the cases. Include the result and move to a relevant support question instead of inventing a conclusion.
If the measurements vary too much to interpret, shorten the test and stabilize the conditions. Use the same view, action, and settings for the next observation. A noisy comparison is a reason to improve the observation, not a reason to select whichever number supports your preferred theory.
Keep the log small enough to remain readable. A handful of clearly described comparisons can be more useful than hundreds of values with no scene or settings attached. The developer needs to know what changed and what did not. Your own future self needs the same information when deciding whether a later update affected the issue.