search

ValveSoftware / Source-1-Games

Source 1 based games such as TF2 and Counter-Strike: Source
636 stars 74 forks source link

All Wayland-capable Source 1 Games - System DPI/Scaling is not respected #5436

Open jrelvas-ipc opened 8 months ago

jrelvas-ipc commented 8 months ago

Games which have DXVK support (via -vulkan command argument) are also capable of using SDL2's Wayland backend (via SDL_VIDEODRIVER=wayland env). This mostly works, however, the game is not DPI aware and sees the "scaled" resolution instead of the actual resolution. For instance, on my laptop's UHD display, the scaling is x2, so effective in-game resolution is halved:

imagem

This does not occur when running the game via XWayland.

A workaround has been proposed upstream at https://github.com/libsdl-org/SDL/issues/8768, however, it's my understanding that DPI is something that the game/program itself is able to account for. I've tested Counter Strike Source 2, and it doesn't seem to be affected by this issue.

I've confirmed that this issue is present in the following games:

Portal 2 behaves slightly differently: Higher resolutions are exposed, but the surface is rendered out of bounds from the window (1/4th visible, consistent with 2x scaling), then immediately scaled back to normal (with no apparent change in pixel density):

Gravação de ecrã a partir de 2024-01-29 09-23-10.webm

This issue is also likely present on Left 4 Dead 1 and Left 4 Dead 2, but I don't own those games so I can't check.

AwesomeCoder412412 commented 8 months ago

+1, I would be a very happy man if tf2 worked smoothly on Wayland. No idea if this helps, but when running tf2 through wined3d's dx9 -> OpenGL translation layer, I frequently run into this same issue. It's fixable though, so if this one isn't fixable by the end user it's probably a separate bug.

misyltoad commented 8 months ago

I would be a very happy man if tf2 worked smoothly on Wayland.

Using Wayland natively (at least with vsync enabled) will simply lead to a worse experience with no advantages right now as multiple commits in-flight with FIFO is entirely broken without the commit_queue protocol that is in progress.

Regarding DPI stuff,

Perhaps we need to use the Window pixel size vs not or something, not sure yet.

AwesomeCoder412412 commented 8 months ago

Replying to https://github.com/ValveSoftware/Source-1-Games/issues/5436#issuecomment-1911395553

Thanks for the explanation! I suppose I'll just stick with X for the time being.

jrelvas-ipc commented 8 months ago

A workaround has been proposed upstream at https://github.com/libsdl-org/SDL/issues/8768, however, it's my understanding that DPI is something that the game/program itself is able to account for. I've tested Counter Strike Source 2, and it doesn't seem to be affected by this issue.

SDL3 has just merged this workaround. However, there are no plans to backport it to SDL2. (will only be available via sdl2-compat)

jrelvas-ipc commented 8 months ago

Portal 2's behavior is actually slightly different:

1920x1200 is still considered the "native" resolution, however, higher resolutions are exposed in settings. They still don't work correctly, though; the game's surface is rendered out of bounds from the window (1/4th of game visible, size consistent with 2x scaling), then immediately scaled back to normal (with the same density as "native"):

Gravação de ecrã a partir de 2024-01-29 09-23-10.webm

Jackaed commented 5 months ago

Will source games move to SDL3 at any point, either through SDL2-compat or otherwise? If not, what can we do in order to get this issue fixed?

jrelvas-ipc commented 5 months ago

Will source games move to SDL3 at any point, either through SDL2-compat or otherwise? If not, what can we do in order to get this issue fixed?

I'm guessing this will become a bigger priority once the Wayland FIFO protocol is ready. (Either switching to SDL3 or adding in support for DPI/scaling). Maybe @Joshua-Ashton can shed more light into this?