Common rendering problem with uncapped frame rate in many SDL2 ports

[vadrig4r]

In multiple SDL2 ports, enabling uncapped frame rate/interpolation without VSync results in a bending/warping/skewing of rendered vertical objects when the player's view moves quickly from either physical motion or mouse turning. The warping happens in the direction of motion (move left, top of vertical object leans left and vice versa), and results in a kind of 'leaning tower of Pisa' effect. It is most noticeable when closely facing a wall (such as the first corridor after the starting stairs in MAP01) and strafing side to side whilst running. It is also very noticeable when circle strafing near pillars. The effect *only* occurs in full screen for the ports I've tested, it does not occur in windowed modes. It is much more pronounced than any usual tearing that might occur.

 

The ports I have tested are:
- Crispy Doom (5.6 to today's daily build of 5.7.2), 5.5 and every version prior does not feature the bug
- PRBoom+ (2.5.1.5.r4526), the SDL1-based 2.5.1.4 does not feature the bug
- Eternity Engine (4.00.00 Völuspá to 4.01.00-pre-918-g981220d0)

- Doom Retro (3.5.3) interestingly does not appear to have this problem, much like Crispy 5.5
- GZDoom (4.3.3) similarly functions normally with rendering interpolation enabled and VSync disabled, though it does not use SDL on Windows as far as I am aware

 

The problem does not occur in these ports without using uncapped frame rate/interpolation. It also does not occur when using uncapped frame rate/interpolation in combination with VSync. The issue is that on most of these ports VSync introduces unplayable input delay or other issues. This seems to be a somewhat recent introduction as I didn't come across it a few years ago; also, as I mentioned it doesn't seem to be present in Crispy 5.5 or PRBoom+ 2.5.1.4. All testing performed on a 64 bit Windows 7 SP1 machine with fully updated drivers using a 60 Hz 1920x1080 LCD monitor.

 

Is anyone else experiencing this behavior?

 

Some other posts referencing either the warping or VSync input lag:

- These two seem to reference the warping effect

- These reference input lag with VSync enabled

 

 

 

 

 

 

 

[Mr.Rocket]

4 hours ago, vadrig4r said:

Is anyone else experiencing this behavior?

Not so much, although I have experienced it before.

I've noticed on Gzdoom if I run windowed mode, it tends to be smoother.

[VGA]

Well I didn't read all that but did you just describe screen tearing? That is a problem with your monitor's refresh rate not being synced, that's why Vsync exists. Or buy a monitor with Freesync or GSync.

 

You can also try to limit the framerate. Nvidia has an option for that.

[Linguica]

What you are describing sounds like a rolling shutter effect but in reverse. Rather than a CMOS sensor scanning from top to bottom and so capturing continued motion in successive lines as it scans down the image, with vsync off your computer is pumping out multiple frames during the 60hz update that are being displayed in horizontal slices. As you turn left a pillar will continue to move to the right from your point of view during the course of a single frame so the bottom will be further to the right and the whole thing will appear to lean to the left.

[Urthar]

I always use V-Sync across all ports. I've only experienced noticable mouse issues with PRBoom+

[marver0PS]

You could try limiting your framerate to 1 or 2 below the refresh rate, either through an ingame cap or a program like RivaTurner.

[VGA]

13 minutes ago, marver0PS said:

You could try limiting your framerate to 1 or 2 below the refresh rate, either through an ingame cap or a program like RivaTurner.

Nvidia has added a framerate limiter option to their drivers. Which you can set on a game by game basis.

[slayermbm]

I experience the same distortion effect when playing the latest versions of crispy and prboom+. I thought it was just a normal side effect with VSync disabled, like screen tearing. Interesting. 

[seed]

Yup, same here, and I experience it in all SDL-based ports with VSync ON and uncapped framerate. GZDoom is the only port I use that has no such issues - and also doesn't use SDL.

[VGA]

3 hours ago, slayermbm said:

I experience the same distortion effect when playing the latest versions of crispy and prboom+. I thought it was just a normal side effect with VSync disabled, like screen tearing. Interesting. 

But ... it is just screen tearing.

 

@seed

You see this with Vsync On? Huh?

[seed]

10 hours ago, VGA said:

 

@seed

You see this with Vsync On? Huh?

 

Yes, prolly because SDL sucks.

[vadrig4r]

19 hours ago, Linguica said:

What you are describing sounds like a rolling shutter effect but in reverse. Rather than a CMOS sensor scanning from top to bottom and so capturing continued motion in successive lines as it scans down the image, with vsync off your computer is pumping out multiple frames during the 60hz update that are being displayed in horizontal slices. As you turn left a pillar will continue to move to the right from your point of view during the course of a single frame so the bottom will be further to the right and the whole thing will appear to lean to the left.

Very interesting, that seems to describe the 'leaning' effect well. I wonder what change could have introduced this behavior, and why it seems only to affect some SDL2 ports after a certain point in time.

16 hours ago, slayermbm said:

I experience the same distortion effect when playing the latest versions of crispy and prboom+. I thought it was just a normal side effect with VSync disabled, like screen tearing. Interesting. 

Yes, glad to see I'm not alone. As I stated it is far more noticeable/distorting to the rendered output than any usual tearing, and that I've pinpointed the patch that introduced this behavior (as exhibited on this machine at any rate). In prior patches with VSync disabled, any tearing is minor to scarcely noticeable, and does not create this clear 'leaning' effect as mentioned in Linguica's post.

14 hours ago, seed said:

Yup, same here, and I experience it in all SDL-based ports with VSync ON and uncapped framerate. GZDoom is the only port I use that has no such issues - and also doesn't use SDL.

Do you also experience this problem in SDL1-based ports (you can quickly tell by the .dll names in the port directory)? I could not find a single SDL1 port that produces this behavior on my machine, so that's an interesting datum. That VSync doesn't mitigate the effect for you is also very curious, thanks for your input.

12 hours ago, VGA said:

Nvidia has added a framerate limiter option to their drivers. Which you can set on a game by game basis.

 

But ... it is just screen tearing.

 

@seed

You see this with Vsync On? Huh?

I will test out-of-game frame rate limiters to see if it has any effect on the warping. Again, if it is purely a form of screen tearing, it is an *extremely* exaggerated instance of it, and one that was not present in past versions of these SDL2 ports (at least, on my machine), or frankly like anything that I've experienced in years of computer gaming without VSync/Swap Interval.

[seed]

1 hour ago, vadrig4r said:

Do you also experience this problem in SDL1-based ports (you can quickly tell by the .dll names in the port directory)? I could not find a single SDL1 port that produces this behavior on my machine, so that's an interesting datum. That VSync doesn't mitigate the effect for you is also very curious, thanks for your input.

 

Just to be clear, because I think we're misunderstanding each other, my point was regarding input lag with VSync and uncapped framerate ON, not the shutter effect in reverse (I get that too without VSync or capped framerate, and it's normal as far as I understand).

 

Regarding input lag, most SDL1-based ports I've tried have broken mouse input on newer versions of W10 (think of 2.5.1.4 of PrBoom and the OG D64 EX for instance), so there's no way to tell since the mouse skips when turning around in them. The only SDL1 port that seemingly still worked fine in terms of input (although I didn't try using VSync - which I'm hearing is pretty bad in SDL1) was Hammer of Thyrion for Hexen 2 which is currently yet-to-be-migrated to SDL2.

 

I'm assuming either the input or VSync in SDL simply sucks, there's no way it'd be broken literally in all SDL2 ports I've tried (even Quake ports!) and everything that isn't relying on it to work is perfectly fine. For that reason alone, if I knew programming and would make a port (or fork an existing one), nuking SDL and re-basing it would be among the very first things I'd do.

[vadrig4r]

23 minutes ago, seed said:

 

Just to be clear, because I think we're misunderstanding each other, my point was regarding input lag with VSync and uncapped framerate ON, not the shutter effect in reverse (I get that too without VSync or capped framerate, and it's normal as far as I understand).

Ah I see, you're correct I did think you were referring to the rendering effect. I have the same issue with significant input lag as a result of VSync in most ports and so tend to avoid it at all costs.

 

Incidentally, I browsed the Crispy Doom thread and came across this recent post by maxmanium, in response to another post that seems to mention the rendering issue:

 

Setting 'force_software_renderer' to 1 in Crispy Doom 5.7.2 does indeed fix the leaning/rolling shutter bug! With the software renderer enabled (and presumably the hardware/OpenGL renderer disabled) and VSync still disabled, tearing is minimal and unobtrusive, and the extreme leaning/warping is solved. Doing so also doesn't introduce any input lag as in the case of enabling VSync. Perhaps this information might help developers understand what is causing this behavior? I'm also curious if similar options exist for other ports.

[seed]

28 minutes ago, vadrig4r said:

Setting 'force_software_renderer' to 1 in Crispy Doom 5.7.2 does indeed fix the leaning/rolling shutter bug! With the software renderer enabled (and presumably the hardware/OpenGL renderer disabled) and VSync still disabled, tearing is minimal and unobtrusive, and the extreme leaning/warping is solved. Doing so also doesn't introduce any input lag as in the case of enabling VSync. Perhaps this information might help developers understand what is causing this behavior? I'm also curious if similar options exist for other ports.

 

Crispy has no GL rendering, GL is only used for image scaling and a few things, but apart from that, it's still Software.

 

The input lag might be related to the framerate interpolation, from what I've been reading through some posts, which is not working correctly. It was said that it might also be due to using such a stone age version of GL (2.1) for things which prevent it from working correctly, but considering that it happens in other non-Doom ports that are also based on SDL, I'm not so sure about it. I mean even ports like Yamagi or vkQuake have input lag with VSync ON, and the latter is a Vulkan-based fork.

[VGA]

@seed

 

Test that force_software_renderer solution.

[drfrag]

 That's a software fallback and it's slower, disables vsync, by default Crispy (and Choco forks) use a hardware accelerated renderer (obviously 2D) on GL 1.3 and above i believe. I've also noticed that disabling Smooth Scaling in RUDE (Crispy's option) i got a 10x performance boost fullscreen on linux with a very old Ati card. You could try that too.

 Crispy already uses fake fullscreen by default BTW (same as Choco).

[vadrig4r]

On 4/2/2020 at 1:35 PM, drfrag said:

 That's a software fallback and it's slower, disables vsync, by default Crispy (and Choco forks) use a hardware accelerated renderer (obviously 2D) on GL 1.3 and above i believe. I've also noticed that disabling Smooth Scaling in RUDE (Crispy's option) i got a 10x performance boost fullscreen on linux with a very old Ati card. You could try that too.

 Crispy already uses fake fullscreen by default BTW (same as Choco).

I tested disabling Smooth Scaling, it didn't seem to affect either the warping effect or VSync input delay. So it seems whatever this is, it is related to some point in the process of converting the SDL canvas to an OpenGL texture? If any port dev wants more spec or setup details let me know I'm happy to help.

[VGA]

If this visual glitch isn't monitor related, is it visible in recorded video?

[vadrig4r]

41 minutes ago, VGA said:

If this visual glitch isn't monitor related, is it visible in recorded video?

I was wondering this. I will get a recording setup and see if it's able to be captured.