summaryrefslogtreecommitdiff
path: root/regression
diff options
context:
space:
mode:
authorPatric Stout <truebrain@openttd.org>2021-02-22 21:17:55 +0100
committerGitHub <noreply@github.com>2021-02-22 21:17:55 +0100
commit78d96dad2a9ba82b0f5a9777349f1d40087be6e1 (patch)
tree69a068928a91947706532c2dc7b2d64dabf8bb80 /regression
parentc136dd2b3268f7aa7b8088814febd77108dcef30 (diff)
downloadopenttd-78d96dad2a9ba82b0f5a9777349f1d40087be6e1.tar.xz
Fix #6319: [Win32] don't use clipping; draw whole screen every frame (#8726)
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?
Diffstat (limited to 'regression')
0 files changed, 0 insertions, 0 deletions