Factorio Forums

I just started 0.17 for the first time, and I appear to be getting a graphical glitch that is similar to screen tearing. Notably, however, vsync is enabled in both Factorio and (currently) force-enabled by drivers. It also doesn't appear to manifest in Steam screenshots, but it's possible that Steam "blocks" the render process long enough to make it a non-issue.

It is most significant at closer zoom levels; all that changing what vsync combination is active does is move the "bar" up or down the screen. This video (from my DSLR at 60FPS, pardon any moiré effects) was captured with Factorio vsync enabled and CCC forcing vsync. The attached log file comes from that particular session.

Just did some testing, issue goes away if I force OpenGL, so it's likely something DX11-related, either engine-side or driver-side. However, OpenGL runs a lot slower.

I have this bug as well, for me it goes away when I have "Wait for VSync" enabled in the graphics settings.

That's how things were set up for the video, though; vsync both in the in-game settings and being forced by the graphics driver. Very little difference between all four combinations of vsync-enable settings.

I just started up the standalone version of 0.16.51 for an unrelated reason, and I can confirm that tearing present in its default configuration (game vsync off, system not forcing vsync) is identical to that of this report (except it will "slide" up and down the screen), and goes away when I enable in-game vsync and restart.

Perhaps there's an issue with enabling vsync under DX11?

EDIT: I just tested 0.16.51 again, this time with game vsync off and system vsync forced on; it appears the system vsync forcing setting has no effect under Factorio, as I got the tearing. This leads me to believe that 0.17 has an issue with vsync under DX11, and that this isn't a system-specific issue.

I had the same problem, I changed the desktop wallpaper to an Aero theme, and it fixed it, I am however still using Win 7, I'm not sure if you are on Win 10 or not.

I'm on Win7, but I can't stand Aero; it shouldn't be entirely relevant, however, as someone who knows quite a bit about the difference between when desktop compositing is available or not.

Is it possible to launch the game to true fullscreen versus borderless window, though, to test by removing the desktop environment from the rendering pipeline entirely?

Not sure about true fullscreen, I've tried changing launch options in steam, but they seem to be unrecognised, I think the easiest way is to change to an Aero theme, just save your current theme and change to Aero when you want to play Factorio.
I had issues playing Fallout 4 aswell.

Can you try to edit Factorio's config.ini?
Change to (another possible value, "flip-discard", works only on Windows 10)

We do use v-sync correctly, as far as I can tell, but the whole thing is more complicated. If Windows or graphics driver detect the presentation target covers entire screen it can start taking shortcuts, and things start to behave differently.

During migrationg to DirectX 11, we used flip presentation model intially, but then it behaved little bit different than expected when v-sync was off, so I reverted to "copy" prensentation model that was used in Allegro until I have time to experiment with this more.

Turning off OpenGL and switching to flip does not remove the tearing.

EDIT: Are you equipped for ETW traces? If it helps anything, I can try to record a CPU+GPU trace, throw it onto Google Drive, and DM you a link to it.

If you mean equipped by knowledge, then I am afraid I am not. And have my doubts that it would yield anything I could fix.

Enabling v-sync in DX10+ is just passing 1 instead of 0 as SyncInterval parameter into IDXGISwapChain::Present function: https://docs.microsoft.com/en-us/window ... in-present

So far only thing I can think of we could do differently (since the flip presentation model didn't help) is to use exclusive fullscreen (which is planned, but will probably require lot support initially, so I don't want to do it now).

I was rather meaning in software terms (properly configured WPA etc.), but if you don't even know how to use the tools, it won't help much.

I might see what happens in the standalone ZIP version of 0.17 -- this can remove the Steam Overlay from the equation (which, even when disabled in settings, doesn't prevent the relevant DLLs from hooking to the executable and intercepting graphics calls).
EDIT: No dice

So, I decided to do a bit of ETW-based investigation, and results from within GPUView are somewhat surprising.

Firstly, I checked what 0.16.51 was like (I've deleted the trace, so much of this is from memory). Apparently, even when vsync was enabled, the system didn't appear to actually know the game was trying to vsync, so there was an immediate lack of vsync lines in the graph; it looked like things were timing instead based on checking what the current scanline was, but I don't recall if that was Factorio code or driver code.

So then, I checked what 0.17 was like with flip: A lot nicer than what 0.16 looked like, and hey, it's actually requesting vsync in a recognizable way, so I have those nifty blue lines. Note that a part of the CPU time during each frame went into atidxx64.dll, operating in a separate thread.

So then, 0.17 using copy instead of flip: Looks a bit more efficient, from a timings standpoint. The GPU packets take slightly less time to process, and there's possibly less context switch into the driver.

Then I looked at what OpenGL was doing...very different: First thing that stood out was the inclusion of the "flip queue" bar. Not entirely sure why it came out now instead of when testing DX11 flip, especially since there were never any flips queues, but it might be related to how OpenGL support is implemented in the driver.
Timeline stuff also got very different, but a big part of that is because the OpenGL support has a lot of software-side components that are called without external dispatch (which is why there's so much more going on in the main thread).

As a closing, something to potentially investigate: DX11 is resulting in two packets being sent to the GPU per frame. The first one (solid) is the "render" packet, the second one (hatched) is the "present" packet, which is executed after the render packet completes. According to some DX docs, the "present" packet is what triggers the switchover of presented frame (hence its name). Its executed position between the vsync lines approximately lines up with the "tear line" on the screen. And said docs also state the present packet should be getting put into the flip queue, which is mysteriously absent here -- perhaps its absence is causing the present packet to have an effect between vsyncs?

I too have the tear line on my screen (Win7, with desktop composition disabled & v-sync enabled), but it runs just above the minimap and I've been completely ignoring it.
I may try that tracing prog later to see how our results differ. (If I can tear myself away from playing.)

Apparently (according to a bit of research I just did), Desktop Composition acts as an indirect fix for this issue; it enforces double-buffering on all applications that run in a window (which includes Factorio), so only fully-rendered frames get pushed forward to the compositing pipeline. Desktop Composition can only be disabled in Vista, 7, and by going actual-fullscreen; 8 and 10 can't have it turned off outside of fullscreen without breaking core OS interfaces.

Thanks for the GPUView analysis.

Any way I look at it, it seems to me it is not worth it to try to make v-sync work with DX11 with DWM disabled, and it would be better to prioritize adding exclusive fullscreen option - at least as a checkbox without all the resolution selection shenanigans.

I was aware DWM makes presentation on screen always v-synced regardless of the option in our graphics options, but I didn't know v-sync would not be possible at all without DWM.

DX11 non-DWM vsync is a prerequisite for exclusive fullscreen vsync, though; DWM doesn't double-buffer any applications running in exclusive fullscreen.

Yes, I believe the problem is that DXGI swapchain doesn't own screen exclusively and that is somehow making it fail to v-sync, despite Factorio requesting it to do so.

Wait a second.

posila wrote: Wed Mar 13, 2019 10:35 am During migrationg to DirectX 11, we used flip presentation model intially, but then it behaved little bit different than expected when v-sync was off, so I reverted to "copy" prensentation model that was used in Allegro until I have time to experiment with this more.

Wouldn't D3DSWAPEFFECT_COPY be replicated with DXGI_SWAP_EFFECT_SEQUENTIAL instead of DXGI_SWAP_EFFECT_DISCARD? Just a crazy thought, but the permitted "corruption" etc. that _DISCARD has could be the culprit of at least part of the issue; the glitch is a band instead of a normal tear, and it looks like the data both before and after the band is "valid" (at least for the same frame).

I might see what happens if I can manage to throw that into the graphics settings structure with windbg tomorrow.

Allegro was doing following We were not using ALLEGRO_SINGLE_BUFFER, so afaik it always ended up being D3DSWAPEFFECT_DISCARD.

Try to set dxgi-swap-chain-buffer-count to some numbers larger than 1.

Honestly it looks like normal tear to me, the ther doesn't happen at the exact same scanline every frame so it looks like a band.