Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix #6319: [Win32] don't use clipping; draw whole screen every frame #8726

Merged
merged 1 commit into from Feb 22, 2021

Conversation

@TrueBrain
Copy link
Member

@TrueBrain TrueBrain commented Feb 22, 2021

Motivation / Problem

When you move the mouse quickly, you can make it disappear. The 60fps patch made this more obvious, but it has always been there. Now, especially if you run 60Hz displays, this becomes nearly impossible to play the game.

I think the presented solution is shitty, as we have no clue why this is happening. It fully works around the problem.
But it does solve the issue and makes the game a lot more playable, with seemly no regression in terms of performance.

So I am PRing this anyway, in the hope this triggers someone else in saying: dude, you are doing NNN wrong. Or that we just accept reality, and go for a proper-functional game :)

Description

When we clip the region that is only been redrawn, something
weird happens on Windows. When pushing 60 frames per second on a
60Hz monitor, it appears that the clipped region is often shown
of another frame, instead of the current.

Examples of this are:
- pause the game, move your mouse to the left, and at the right
  speed it totally disappears.
- fast aircrafts seem to be in several places at once, weirdly
  lagging behind.
- in title screen, moving your mouse gives you the idea it is
  jumping places, instead of smooth movements.

In the end, if you do nothing, everything is correct, so it is
eventually consistent. Just when we are firing many BitBlt in
a clipped region, the in-between is not.

What goes wrong exactly, I honestly do not know. On every frame
that we push to the DC is a mouse painted, but visually it
sometimes appears like it is not. Recording with external software
shows it really is there.
It is also not our eyes playing tricks on us, as the first example
makes it really clear the mouse pointer really is not painted.

And to be clear, with the mouse this is easiest reproduceable,
as high-speed objects are influences by this most. But this happens
for all movement that redraws small regions.

Either way, not using clipped regions resolves the issue completely,
and there appears to be little to no penalty (I failed to measure
any impact of drawing the full screen). So better have a good game
than fast code, I guess?

Limitations

Checklist for review

Some things are not automated, and forgotten often. This list is a reminder for the reviewers.

  • The bug fix is important enough to be backported? (label: 'backport requested')
  • This PR affects the save game format? (label 'savegame upgrade')
  • This PR affects the GS/AI API? (label 'needs review: Script API')
    • ai_changelog.hpp, gs_changelog.hpp need updating.
    • The compatibility wrappers (compat_*.nut) need updating.
  • This PR affects the NewGRF API? (label 'needs review: NewGRF')
When we clip the region that is only been redrawn, something
weird happens on Windows. When pushing 60 frames per second on a
60Hz monitor, it appears that the clipped region is often shown
of another frame, instead of the current.

Examples of this are:
- pause the game, move your mouse to the left, and at the right
  speed it totally disappears.
- fast aircrafts seem to be in several places at once, weirdly
  lagging behind.
- in title screen, moving your mouse gives you the idea it is
  jumping places, instead of smooth movements.

In the end, if you do nothing, everything is correct, so it is
eventually consistent. Just when we are firing many BitBlt in
a clipped region, the in-between is not.

What goes wrong exactly, I honestly do not know. On every frame
that we push to the DC is a mouse painted, but visually it
sometimes appears like it is not. Recording with external software
shows it really is there.
It is also not our eyes playing tricks on us, as the first example
makes it really clear the mouse pointer really is not painted.

And to be clear, with the mouse this is easiest reproduceable,
as high-speed objects are influences by this most. But this happens
for all movement that redraws small regions.

Either way, not using clipped regions resolves the issue completely,
and there appears to be little to no penalty (I failed to measure
any impact of drawing the full screen). So better have a good game
than fast code, I guess?
@TrueBrain TrueBrain force-pushed the TrueBrain:win32-clip-region branch from 3c2fb78 to ab138f9 Feb 22, 2021
@TrueBrain TrueBrain changed the title Change: [Win32] don't use clipping, but draw whole screen every frame Fix #6319: [Win32] don't use clipping; draw whole screen every frame Feb 22, 2021
@TrueBrain
Copy link
Member Author

@TrueBrain TrueBrain commented Feb 22, 2021

Also addresses the initial forum thread linked in #7006 (just to create the reference).

@TrueBrain TrueBrain merged commit 78d96da into OpenTTD:master Feb 22, 2021
11 checks passed
11 checks passed
Emscripten
Details
Commit checker
Details
Check preview needs update Check preview needs update
Details
Linux (clang, clang++, libsdl2-dev)
Details
Linux (gcc, g++, libsdl2-dev)
Details
Linux (gcc, g++, libsdl1.2-dev)
Details
Mac OS (x64, x86_64)
Details
Windows (windows-latest, x86)
Details
Windows (windows-latest, x64)
Details
Windows (windows-2016, x86) Windows (windows-2016, x86)
Details
Windows (windows-2016, x64) Windows (windows-2016, x64)
Details
@TrueBrain TrueBrain deleted the TrueBrain:win32-clip-region branch Feb 22, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants