vadrig4r

Thank you very much for the comprehensive reply. Following your procedure step-by-step with the crispy-doom-20220915-win32 autobuild resulted in the same failed Alt-Tab behavior referenced in my original post. (For completeness I had %DOOMWADDIR% already set with a directory containing only the final versions of the official IWADs) Following your procedure with the test build that you provided, however, worked perfectly! Both Alt-Tab and the Windows key function as expected. Please let me know if you would like me to PM you any additional hardware or driver information that might be useful.

Is anyone experiencing being unable to alt-tab in Windows still? I believe this was an SDL bug introduced in 2020/2021 but I'm still experiencing it in 5.12 and the latest autobuild (20220909-win32). The same issue also affects the latest Chocolate Doom versions for me (3.0.1 release and 20220909-win32 autobuild). Alt-tab simply leaves the full ingame image on the display (no visible taskbar) and brings up the OS cursor unable to interact with anything, requiring terminating the program. Using Alt+Enter to toggle between windowed and fullscreen still functions properly. Does anyone have a workaround for alt-tabbing besides switching to windowed mode? This is on a Win 7 x64 Pro machine.

Very interesting project! For the record Doom 2 maps are running at a stable 60 FPS at 1080p on my 3.16 GHz Core 2 Duo machine with an OpenGL 3.3 capable video card. Also meant to add that the dashboard is a very nice feature and that the 'Valve Classic' skin hit me with some serious nostalgia.

Really appreciate this, great work @Doomkid

Which version of Crispy Doom are you using? I haven't experienced the 'music slider affects sfx too' behavior since about 5.0 on my machine.

You said you are running Arch, are you using the proprietary or open source ('Nouveau') NVIDIA driver? The GT 610 is on the legacy GPU list so you might want to check the wiki to see which driver is optimal to use. Like Gez said, I would expect better performance than that whilst running Ultimate Doom (depending on your resolution).

Are you trying to use a UK English language setup with a US layout keyboard or something?

Stunning.

Just got around to playing this one @meapineapple, really enjoyed the map! Loved the aesthetic design, was very reminiscent of Quake 4/Doom 3 era levels and plenty of nice detailing. Fun monster layout and ambushes that were a great introduction for my first time using the D4V mod. The grand finale was a blast—literally, my face, blasted. Overall I can recommend it to anyone who wants an enjoyable, intense, medium-sized wad playthrough that shows off D4V's capabilities!

Welcome mate, it's a great community, happy Dooming.

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

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.

After some testing, on my machine the significant input lag associated with VSync was introduced between 5.5 and 5.6 (input lag not present in 5.4/5.5 and present in 5.6), which as might be expected is concomitant with when this warping seems to have been introduced.

This seems to reference the exact issue I encountered as described in my thread here: As you stated, setting force_software_renderer to 1 fixes the extreme warping/tearing that Linguica likened to a reverse rolling shutter effect. As I mentioned in the OP of that thread, this particular behavior seemed to been introduced between 5.5 and 5.6 (at least on my machine). I'm glad there's at least a temporary fix in Crispy Doom, but I'm curious as to why it seems to have been introduced in multiple SDL2 ports having not been present in past versions (or in other games), and if there's any possibility of solving the problem at the source (which seems to be related to SDL's use of hardware rendering). As always thanks for the excellent work on this important port, fabian et al.

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.