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 [External Link] 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/ [External Link]

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

Quoting: SalvatosIt’s sad but true: when you accept everybody’s help, sometimes you’ll get contributions that aren’t really as helpful ;)

Unfortunately, translation platforms like Weblate generally lack a way to organize translators in a way that they are always reachable. You could have a separate chat platform, but this isn't the best way to ensure contributors are reachable even years after they've contributed to the project.

View this comment - View article - View full comments

Quoting: GuestLinux version on day one, let's go!

Sad to see CS:GO being completely replaced this time rather than being a separate game, though. Just imagine all the community servers having close to no players now...

There's a CS:GO demo viewer branch which should remain usable to connect to community servers (via `/connect` commands). I suppose people will be developing web-based server browsers eventually.

View this comment - View article - View full comments

Quoting: GuestPerhaps I should clear that backlog first, eh?

Any game in your backlog is 100% off, as long as you already have it :)

View this comment - View article - View full comments

Quoting: legluondunetDo they plan to support "StarWars - Episode 1 racer" because this game is a pain in the ### to play on Linux.
You can play this game it with wine but there are annoying bugs and no multiplayer.

Support is planned at some point, according to the developer: https://www.reddit.com/r/emulation/comments/167mp7r/dreamm_21_released_for_windows_macos_and_linux/jyzwfdp/ [External Link]

Quoting: spacemonkeyDoes this do any enhancement? Because I can confirm that the Steam version of Star Wars: Jedi Knight: Dark Forces II already runs great on Steam Deck (only the menu's are 2 fps for some reason)

To play with enhancements, I would recommend https://github.com/shinyquagsire23/OpenJKDF2 [External Link] personally. I've used it to play the full game and it's quite a nice experience.

View this comment - View article - View full comments

There's also the Phantom Edition [External Link], but it doesn't have native Linux support and source code isn't available. It apparently runs great in WINE though.

View this comment - View article - View full comments

Quoting: redmanThe first thing that I thought was: Will Yamagi Quake II [External Link] will be improved by this ?

Improvements will likely trickle down to source ports like what happened with Quake 1 last year (especially in Ironwail). This includes using assets from the remastered version [External Link] (new maps/models), but also various QoL features.

That said, it'll be a while until a source port is able to implement all new features and tweaks found in the remaster. Some of them (such as the increased tickrate) require deep changes in the engine and gamecode, breaking mod compatibility.

View this comment - View article - View full comments

Quoting: PikoloYou don't yet get a usable OpenGL driver when using open source drivers on an Nvidia card. That's what Zink compatibility will be necessary for.

Nouveau has supported OpenGL for more than 15 years now. It's not as well-tested as on AMD or Intel, but it should be functional barring regressions.

If you're referring to the NVIDIA open kernel driver, does this mean that this new approach will get rid of the Mesa OpenGL implementation entirely? Relying 100% on Zink in its current state feels risky to me, not to mention the overhead it has compared to a well-optimized OpenGL implementation.

View this comment - View article - View full comments

Ironically, `WINE_FULLSCREEN_FSR` is really nice for old games, as it prevents them from switching fullscreen resolutions which can mess up your desktop (especially if the game crashes). I wish there was a plain and simple option in stock WINE to do this, but there's only `WINE_FULLSCREEN_INTEGER_SCALING` (which is good in some scenarios, but not all).

The "Emulate virtual desktop" option in winecfg also prevents resolution switching, but it doesn't seem to be effective 100% of the time and it spawns an ugly desktop window when the game starts.

View this comment - View article - View full comments