SDL

I assume the OP recently watched the video of Ryan C. Gordon porting ioquake3 from SDL2 to SDL3 [1]. He uses the linked tool to automate a lot of the migration. SDL3 ships with a Coccinelle file [2] to handle all the Enum and API renames and it also comments areas that need manual fixing. [1] https://ioquake3.org/ioquake3/ryan-c-gordon-ports-ioquake3-f... [2] https://github.com/libsdl-org/SDL/blob/main/build-scripts/SD...

The current status of X11 is that it works. The current status of Wayland is that it doesn't. It's really that simple. I think this exchange can help you understand my position better: https://github.com/libsdl-org/SDL/pull/9345#issuecomment-201... >Wayland has a myriad of unresolved problems regarding surface suspension blocking presentation and the FIFO (vsync) implementation being fundamentally broken leading to reduced GPU-bound performance. To which someone replies: >If we do this, we are basically accepting these issues are unfixable for the next ten years (SDL4). Having this as the default in SDL3 (which isn't being used yet!) is important for signaling to other stakeholders that we actually do need to get solutions in place for detected issues. To which the committer says: >SDL is not your tool for "signaling to stakeholders" abou

SDL can be used to provide something similar to what you describe. https://github.com/libsdl-org/SDL/blob/main/docs/README-andr...

*sdl2::render src/sdl2/render.rs: https://github.com/Rust-SDL2/rust-sdl2/blob/master/src/sdl2/... SDL/test /testautomation_render.c: https://github.com/libsdl-org/SDL/blob/main/test/testautomat...

The current SDL GPU API does not intend to use this shader language. Instead, users are expected to provide shaders in the relevant format for each underlying graphics API [1], using whatever custom content pipeline they desire. One of the developers made an interesting blog post motivating this decision [2] (although some of the finer details have changed since that was written). There is also a "third party" solution [3] by another one of the developers that enables cross-platform use of SPIR-V or HLSL shaders using SPIRV-Cross and FXC/DXC, respectively (NB: It seems this currently wouldn't compile against SDL3 master). [1] https://github.com/libsdl-org/SDL/blob/d1a2c57fb99f29c38f509... [2] https://moonside.games/posts/layers-all-the-way-down [3] https://github.com/flibitijibibo/SDL_gpu_shadercross

Wayland works well on the Steam Deck because Valve controls the whole system. Because they have their own Wayland compositor (Gamescope), they're able to implement protocols to work around issues in Wayland without being delayed by the bureaucratic process of getting them approved. Here's an SDL pull request where a graphics developer at Valve discusses how two protocols necessary for good GPU performance haven't been added to Wayland yet so Valve added equivalent protocols to Gamescope as a workaround: https://github.com/libsdl-org/SDL/pull/9345 One thing to note is that the Steam Deck only uses Wayland for its fullscreen gaming mode. When you exit to its desktop mode (meant for running non-Steam software), it switches to X11.

The linked project doesn't use any ObjC files at all. SDL2 has a bunch of Cocoa files[1] so you did use Cocoa even if unknowingly. [1] https://github.com/libsdl-org/SDL/tree/main/src/video/cocoa

Correct. It's explained here: https://github.com/libsdl-org/SDL/pull/9345#issuecomment-201... XWayland has special hooks into the compositors that normal wayland clients don't get.

Best comment: https://github.com/libsdl-org/SDL/pull/9345#issuecomment-201... > SDL is not your tool for "signaling to stakeholders" about what is important. But but but I need engagement for my team!

I don't know for sure, but could it be this? https://github.com/libsdl-org/SDL