Entrances & building
Cursor drifting into the top-left corner?
For the Demo bug where the cursor continually moves toward the top-left corner, first check that Steam has applied the available Demo update. On October 2 the developer uploaded an input fix, and the original reporter later confirmed that it worked. This is evidence for a dated fix, not proof that every current input problem has the same cause.
Checked November 3, 2026. PC Demo reports from October 2, checked November 3. The thread does not identify an exact numbered patch, and we have not run the game to verify your installed build. These are sourced instructions and decisions, not our own gameplay test.
On this page
Match the symptom before trying a fix
The original report describes a pointer that keeps drifting up and left in the menu. Other players reported similar behavior. The developer discussed recently implemented controller support while investigating the issue.
| What you see | Best next check |
|---|---|
| Pointer continually travels toward the upper-left | Compare the October 2 fix and your Demo update/build. |
| Pointer stays still but Wine menus do not accept input | Use the separate CrossOver/Wine menu report. |
| Proton launches but tutorial mouse actions fail | Use the Linux input boundary. |
| Pointer works, but an object will not rotate | Check the active placement preview and documented R control. |
A controller was part of the investigation, but a report also came from a player without one. Do not assume every affected machine has controller stick drift.
Check the installed Demo before changing other software
- Confirm you are launching Oboro no Ichi Demo, rather than comparing a video or the unreleased parent listing with your installation.
- Check Steam’s available update/download state for that Demo. Let an available update finish before retrying the menu.
- Read and record the build number at the bottom-right of the initial splash screen, where the developer says it is displayed.
- Reopen the Demo and observe the pointer before entering a market. Can it remain still and select the intended menu item?
The source timeline is specific: an October 2 developer investigation was followed by an uploaded fix that morning, then confirmation from the original reporter later that day. It does not establish that a future patch cannot introduce a different input issue.
If the current installation still drifts
Keep a short record of the Demo build, Windows version or compatibility runtime, connected input devices and whether movement begins before you touch a controller. Include what happens when you use the menu, rather than only saying that the mouse is broken.
Compare that record with the original cursor thread and its latest replies. If reporting a new case, separate a recurring symptom on an updated build from an old recording of the pre-fix version.
The original poster had already tried disabling overlays without success. The thread therefore does not support “disable every overlay” as the established repair. It also supplies no verified driver replacement, save deletion or reinstall procedure. Start with the documented update evidence and preserve your existing settings and saves.
The menu is usable—or the remaining problem is specific
A successful check means the pointer stays where you leave it and accepts the intended menu selection. If it does not, you have a build and input-environment record that distinguishes a new case from the fixed October report.