Note that right now, you have to enable the Prefer Wayland editor setting for native Wayland support to be used. Otherwise, XWayland will be used until native Wayland support is further tested and polished.

Exported projects will also use XWayland by default until native Wayland is made the default, but you can use the --display-driver wayland command line argument to force it if the game was exported with Godot 4.3.dev3 or later. --display-driver x11 also works to force X11 (and therefore XWayland).

I briefly tested Godot on Wayland on NVIDIA 545.29.06 and it worked pretty well for basic editor usage, although single-window mode is currently forced as multiple window support still needs to be figured out on the Wayland backend.

View this comment - View article - View full comments

This will probably be handy for those 100-player servers, which I assume are pretty draw call-heavy.

View this comment - View article - View full comments

I find Jazz

Quoting: SzkodnixThey are making a huge progress, however still they have a lot to do. For now, I can feel that the physics is different (turtle shells are rotating a bit, while doing a stomp you cannot move left or right etc.) but I guess with more time they will create a masterpiece!

Look at the second entry of the "upcoming" changelog :)

View this comment - View article - View full comments

QuotePlayers can now sprint when moving backwards.

At long last! I've always preferred games that let you do that (like Enemy Territory).

View this comment - View article - View full comments

Quoting: ShmerlIs it about fonts? It's a pretty messed up situation.

I don't remember specific font rendering issues when using HDR on any OS (although ClearType/LCD subpixel optimization is undesired on many displays that excel at HDR, such as OLED panels). Thankfully, these are easy to turn off, though I wish this was done automatically when such a display is detected.

View this comment - View article - View full comments

Quoting: SchattenspiegelStill funny that HDR is pushed by multiple parties without agreeing to one standard to make it a hassle free plug an play solution for the end-user first. But nice to see some advancement being made on Linux nonetheless. Keep up the good work!

A lot of the implementation mess is due to inconsistent settings in monitors/TVs, and the battle between Dolby Vision and HDR10+ on the movie side (with Dolby Vision largely dominating, despite not being royalty-free like HDR10+).

On the desktop side, it's not really about having parties agree to one standard, but games having HDR implementations that wildly in quality (with issues like raised/crushed blacks, lack of paperwhite setting, etc). There's also the issue with the Windows desktop looking bad on most displays with HDR enabled, but maybe Linux desktops will figure out a way around this like macOS does. In general, macOS probably has the best (i.e. most reliable) HDR implementation right now.

I expect this will even out over time (HDR debuted in 2016), but better start now so it's not delayed even further :)

View this comment - View article - View full comments

QuoteSpider-Man: Remastered and Spider-Man: Miles Morales also work, but don't look particularly good with HDR, which might not actually be a Linux problem specifically.

Spider-Man Remastered looks pretty good on my LG C2 42" in HDR on Windows 11 (after setting paperwhite to 200 nits in the in-game settings menu, and disabling dynamic tonemapping in the TV's settings to use HGIG instead).

I've also used the Windows 11 HDR calibration tool to further improve results (it's kind of a must-have for most displays, not sure if Linux has an equivalent yet). In general, if you want to do HDR on Windows, you really need Windows 11 to get good results – and an OLED or miniLED display, not edge-lit LCD.

View this comment - View article - View full comments

Quoting: EriI've been looking in to this a little and looks like the only APUs supported are the 7000 series. I know that using it to go from 30-40 fps to 60 creates too much input lag, but I thought it could be interesting to use it to go from 60 to 90 fps on the Steam Deck Oled, but unless they expand the supported hardware, looks like it won't happend.

Like upscaling, frame generation itself has some overhead. It's generally too much to handle for IGPs that aren't at the very top like a Radeon 780M. This is more noticeable the higher your input framerate is, since you'll have even less time to generate a frame.

Even on a RTX 4090, there's a glass ceiling with DLSS FG where you can't really reach more than ~220 FPS consistently no matter how lightweight the scene is.

View this comment - View article - View full comments

Quoting: Mershl

Quoting: TheRiddickMaybe one day steam deck will get some sort of RDNA2 frame gen going.

"AMD FSR 3 Frame Generation is recommended to be used in situations where pre-interpolation, post-upscaling frame rate is a minimum of 60. In ideal situations FSR 3 will produce images up to 120fps from a 60fps game input." - https://gpuopen.com/fsr3-in-games-technical-details/

It might be somewhat usable with 45 FPS input (to 90 FPS output for an OLED Steam Deck) but latency won't be great and most importantly, there will probably be too much overhead for the frame generation to be worth it. Upscaling can sometimes have similar issues on integrated GPUs like the Deck's.

View this comment - View article - View full comments

Quoting: CatKillerOLEDs would benefit from screensavers for the same reasons as CRTs did.

A black screen works very well for that, since it also provides the lowest possible power consumption while still providing instant resume times (if the display isn't actually put in suspend mode).

View this comment - View article - View full comments