CorsixTH
CorsixTH copied to clipboard
[Bug] Black bars in fullscreen (NVIDIA)
Describe the issue
Black bar or black flickering really strange bug inside the game all the time.
Steps to Reproduce
- just start the game with the GoG Version
Expected Behaviour
No Black Bars
Save Game
Save game attached to report: No
CorsixTH Version
0.66
Operating System
Windows 11
Theme Hospital Version
CD
Gamelog.txt
Are you using an NVIDIA graphics card?
yes 3070ti newest driver
Thanks for confirming. This is a known issue that appears to be upstream with NVIDIA. Please report to NVIDIA.
Though as we've had several reports of this in Discord now it's certainly affecting users.
The current workaround is to use windowed mode, or roll back your driver (maybe significantly).
See also below, apparently was fixed but may well have broken again. https://www.reddit.com/r/corsixTH/comments/sw62f4/important_nvidia_graphics_and_corsixth/
Could you also try 0.65 and see if it also happens in that release just for completeness (you may need to uninstall CorsixTH first, or use the windows portable version called CorsixTH-0.65.1-Windows-x64.zip
) https://github.com/CorsixTH/CorsixTH/releases/tag/v0.65.1
@TheCycoONE do you think if we may know if there's anything specific that may lead to this issue?
Windowed Fixed the problem.
Did you manage to get time to test 0.65 in fullscreen?
Additional Discord report:
Asterite — 31/12/2022 00:16 Hello guys, I've recently downloaded CorsixTH's lastest version (never had I used CorsixTH before) and when playing the game I have a long black line that's moving a little bit, on my screen, is it a known issue? Adding a screenshot in a min
And if I lower the resolution from 1920x1200 to, I don't know lets say 1280x1024, it becomes much, much bigger
Is there something I have been doing wrong? Lewri — 31/12/2022 01:34 Are you using an nvidia card at all? Could also be file corruption on the original files. Does it do it in windowed mode Asterite — 31/12/2022 02:10 Yes I am, I am using an NVIDIA GeForce RTX 3070 Ti.
~~A working setup: Windows 10 22H2 NVIDIA RTX 3060 Ti Driver Version: 527.37 (2022-12-01) Working on both 0.66 and 0.65~~ Edit: This setup only worked because the resolution was native
@Glurak18 are you able to test rolling back your NVIDIA driver to the above? UK English: https://www.nvidia.co.uk/download/driverResults.aspx/197309/en-uk US English: https://www.nvidia.com/download/driverResults.aspx/197300/en-us/ Other locales look up driver: https://www.nvidia.com/Download/Find.aspx?lang=en-us
Reported upstream: https://www.nvidia.com/en-us/geforce/forums/game-ready-drivers/13/509555/black-bars-in-fullscreen/
Didnt had time for Driver Rollback. Im rendering a lot of Videos atm.
I have similar issue with Intel iGPU but not with black bars but with black spots (smaller) . After some zooming, moving they disappear. I thought it will stop with the latest stable release but no. Do you also have this kind of issue?
I have similar issue with Intel iGPU but not with black bars but with black spots (smaller) . After some zooming, moving they disappear. I thought it will stop with the latest stable release but no. Do you also have this kind of issue?
Have you got a screenshot? Black spots sound like an imcompatibility with Direct Zoom. Try going into config.txt
and changing this setting to false.
-------------------------------------------------------------------------------
-- Direct Zoom: Avoid rendering to an intermediate texture when zooming.
-- Improves performance and reliability on some hardware.
--
direct_zoom = nil
No further reports since January -- assuming NVIDIA resolved
If NVidia fixed anything it's only a partial fix. For my particular setup (RTX 3070, 546.33) it works perfectly when run in native resolution (in my case 2560x1440) - anything less than that (even a single pixel in either dimension) will result in black lines or boxes obscuring parts of the screen.
Windowed mode shows no such issue. However it also performs no scaling, much like native resolution.
Note that the suggestion to disable Direct Zoom seems to resolve the issue in all resolutions in most cases. It leaves certain zoom levels still exhibiting the issue - such as the default zoom level when starting a new map - which can be confusing.
As none of us here (afaik) own a RTX 30 series card it's hard to replicate. While my partner has a RTX 3060Ti they haven't replicated this on their own setups.
@TheCycoONE checking again with you as I don't think this is CorsxiTH related unless you have any other ideas.
I now have a machine this can be replicated on in the method given by #2478 - though it's still probably not our issue
Reopening - lodging new ticket to NVIDIA (ticket 240203-000277 raised)
Problem narrowed down to code introduced in 0.66 so far. Communications with NVIDIA have been passed to QA.
it is your issue, you are writing into a resource at the same moment you are reading from it in your code somewhere,
the chromium issue has no relevance here, you aren't using the flawed windows api relevant to it
it is your issue, you are writing into a resource at the same moment you are reading from it in your code somewhere,
the chromium issue has no relevance here, you aren't using the flawed windows api relevant to it
@TheCycoONE @flackr are you able to confirm?
CorsixTH makes frequent use of intermediate textures for scaling content. Is it possibly not safe to destroy those textures immediately after drawing them with SDL_RenderCopy
. As an example, look at the scoped_target_texture destructor https://github.com/CorsixTH/CorsixTH/blob/master/CorsixTH/Src/th_gfx_sdl.cpp#L404
~scoped_target_texture() override {
if (!texture) return;
// Restore previous context.
SDL_SetRenderTarget(target->renderer,
previous_target ? previous_target->texture : nullptr);
SDL_RenderSetLogicalSize(
target->renderer,
previous_target ? previous_target->rect.w : target->width,
previous_target ? previous_target->rect.h : target->height);
SDL_SetTextureBlendMode(texture, SDL_BLENDMODE_BLEND);
target->current_target = previous_target;
if (scale) {
// If the target texture is already scaled, skip the global scale factor
// by drawing directly.
SDL_RenderCopy(target->renderer, texture, nullptr, &rect);
} else {
target->draw(texture, nullptr, &rect, 0);
}
SDL_DestroyTexture(texture);
}
My guess for what might be happening is that maybe a subsequent SDL_CreateTexture call can re-use the same memory before the previous texture has been drawn to the screen.
Direct zoom mostly avoids these intermediate textures but when running fullscreen we use them for better text quality in the intermediate rendering https://github.com/CorsixTH/CorsixTH/pull/1934
For clarity this is an animated version of the error. In the webm below the first few seconds the game is not in focus.
CorsixTH makes frequent use of intermediate textures for scaling content. Is it possibly not safe to destroy those textures immediately after drawing them with
SDL_RenderCopy
. As an example, look at the scoped_target_texture destructor https://github.com/CorsixTH/CorsixTH/blob/master/CorsixTH/Src/th_gfx_sdl.cpp#L404
Correct, on nvidia drivers and in particular hardware implementing Tiled Cache (Maxwell+) you risk a patterned corruption if you release on the end of the current frame rather than the beginning of the next, there is no guarantee that the resources have finished being used, where as releasing at the start of the next frame you can be sure nothing is still in flight from the previous.
The same issue for me running on RTX 3060Ti. Here's a screenshot:
I found 2 ways to fix this issue:
- Use dgVoodoo2
- Run CrosixTH from a virtual machine.
Both methods are valid and will fix this issue.
@onemast if you can compile yourself or use the artifacts from a recent pipeline run https://github.com/CorsixTH/CorsixTH/actions/runs/8115429082, the issue should be resolved.
@onemast if you can compile yourself or use the artifacts from a recent pipeline run https://github.com/CorsixTH/CorsixTH/actions/runs/8115429082, the issue should be resolved.
Thank you!