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

Quoting: DamonLinuxPLAlso, looks like that version of Half Life is a fully native Linux build. So no longer toGL.

GoldSrc has had native OpenGL support for a long time (also in the Windows port where it was the only hardware-accelerated option after SteamPipe), so it never used ToGL like Source 1 did.

This recent update does bring software rendering to Linux, which is welcome even though it doesn't look that different from OpenGL with texture filtering disabled (you do get some vertex wobbling that depends on screen resolution, and no viewmodel if the FOV is non-default).

View this comment - View article - View full comments

Quoting: JustinWoodUnrelated, but I'm curious as to why this mod doesn't touch MGS1. Couldn't find anything on the Github specifying why it wasn't touched up.

MGS1 in the Master Collection runs via PS1 emulation. It's not a native PC port like MGS2 and MGS3. It's why it has these wobbly polygons :)

For MGS1, the best ways to run it are the PS1 version via DuckStation or the community-modded PC version. With modern emulation or PC patches in place, I'd say the PS1 version is slightly better overall, but the PC version has some exclusive features like weapon hotkeys if you play with a keyboard.

View this comment - View article - View full comments

Quoting: Liam DaweIt's not a question of saves, that's the point of Steam Cloud. But syncing settings? That's a no.

I'd say the correct approach is to have separate configuration files for preferences (should be synchronized) and system settings (shouldn't be synchronized). Preferences are things like HUD configuration or gameplay options, while system settings are graphical, audio or input options.

This can be a lot of work to implement in some engines (especially if relying on a premade settings mehnu asset) so I understand why most studios don't bother though.

Funnily enough, Unreal Engine 1-2 came pretty close to realizing this ideal 20+ years ago with its `User.ini` and `System.ini` configuration files, though the separation is kind of blurry in practice.

View this comment - View article - View full comments

Quoting: Pecisk"Fixed Old School Runescape and other games on systems with 128+ virtual cores."

Hahaha, what. This sounds so strange bug that I have to know what weirdness this causes and how you can have so many cores.

There's an xkcd for it™:

View this comment - View article - View full comments

Quoting: sonic2kkWhile I absolutely agree with you that they need more people who can merge, two people at least can merge PRs: Yuri Sizov and Rémi Verschelde. Juan Linietsky likely can also merge PRs, as I believe Rémi and Juan were the main folks behind Godot originally. However I don't think others can, though there are other core reviewers (Hugo Locurcio, Clay John, KoBeWi, A Thousand Ships).

Pressing the merge button isn't the most important part of the work. (In some projects like Rust, most merges are handled by a bot.)

The majority of the work is reviewing and testing a pull request, which takes a while for any nontrivial pull request (especially when you need a real world project to test it).

Reviewing PRs is something anyone can do, even if you're not an existing contributor. GitHub's features are designed around this – you don't have to be an organization member or a prior contributor to leave a review, although it will be displayed as "non-binding". These non-binding reviews are still valuable to us (as long as you don't just press Approve without writing a description :)).

We have a website that references pull requests that need a review: https://godotengine.github.io/godot-team-reports/

Many PRs are also in limbo not because of the implementation, but because we don't know how much the feature is needed. This is usually due to the PR lacking a proposal, or the proposal not seeing much activity. New features in particular need to have significant community demand before they can be merged.

View this comment - View article - View full comments