Quoting: Eike

Quoting: soulsource

When writing my posting, I wondered if I should mention that I am programming for 38 years and that I'm professional software developer for over two decades. It seems I should have.

I know all you've written. But you left out that every single call into the Windows(!) API has to be translated, during runtime. It is not native, it is translated into native. Like a human language interpreter doesn't make English native German - they translate.

Unless I'm misunderstanding something, there's no need to translate - at least not more than what happens on Windows. Since directly interfacing with the Windows kernel isn't supported (syscalls aren't stable between Windows versions), the calls to the kernel functions are always going through the (stable) API offered by Windows libraries (kernel32.dll, user32.dll,...). If now the dynamic loader loads the libraries offered by WINE instead of those offered by Windows, all those function calls instead call the implementation offered by WINE.

I do get your point though, that there's (typically) an additional indirection involved. On Windows the API libraries can probably forward most of their public API calls directly to syscalls, while WINE typically (there are exceptions, like futex2 on Linux) targets platform independent (-> user space) APIs instead. So, instead of going "Program -> kernel32.dll -> Windows kernel", on WINE it's a "Program -> WINE kernel32.dll -> some platform independent API in another library -> Linux kernel", what could be called "translation".

(Or are you talking about function calling conventions, which differ between Windows and Linux? I'm not sure how those are treated by WINE's libraries, but I would assume that the functions visible to Windows programs are using the same calling convention as their Windows counterparts...)

View this comment - View article - View full comments

Quoting: GuestWe've done it. We've actually reached a point in the debate where not only is using Proton better than native titles, it's all actually been native the whole time.

Who said it's better? The "native" discussion is actually answered quite well on the WINE FAQ [External Link].

View this comment - View article - View full comments

Quoting: Eike

Quoting: EagleDelta

Quoting: elmapulbecause they dont want to fix it if anything breaks on wine.
plus we have an history of harrassing developers who call their wrapper (wine/virtual programing) version an native build.

This drives me nuts as a programmer. As WINE/Proton is not emulation, but an implementation of Windows/DX/other APIs in Linux/UNIX-based systems, as such things running in WINE are running natively as all WINE does is map APIs to native APIs/calls (well, for the most part).

That's why it's not native. It has to map to native, during runtime. You're running EXEs and DLLs on Linux. Don't know about you, but that wasn't my goal when switching to Linux.

The program code is native already (x86 instruction set with AMD64 extensions). WINE contains an independent reimplementation of various libraries shipped with Windows. So, instead of calling functions in Microsoft's Direct3D implementation (as example), programs running under WINE call into WINE's Direct3D implementation (which, opposed to Microsoft's implementation, internally uses other graphics libraries like Vulkan to make the code independent of graphics driver - therefore the term "mapping").
This is not only true for graphics libraries though, but for almost (WINE isn't 100% complete) all libraries that come with Windows, what includes low-level libraries for accessing basic system functionality.

In other words, the code is still running 100% native, it just might show different performance/behaviour to Windows because the libraries might be faster/slower, and the Windows API documentation might not always perfectly reflect real-world behaviour of Windows libraries (and of course there could be bugs in WINE).

Also, EXE/DLL is just a file format. The distinction if a program's machine code is stored in an ELF file or an EXE file is similar to the one if an MP3 stream is stored inside an MKV or an AVI file. WINE contains a reader for EXE files, and if you want to, you can set up your Linux kernel to just use WINE's EXE reader [External Link] if you try to launch an EXE file directly.

View this comment - View article - View full comments

Quoting: melkemind

Quoting: Mountain ManI've wishlisted it, but I'm not going to be an early adopter. I'll let others take that risk, and if the user reviews are positive, then I'll buy.

I would recommend all Nvidia users wait. Even if it's Steam Deck verified, that only guarantees it works on AMD.

I can second this.
Unreal Engine has some long standing bugs regarding VRAM usage of render targets, causing frequent OOM-crashes for nVidia users on Proton.

The AMD drivers just swap some VRAM to system RAM in such a case. This could cause performance issues if that VRAM were actually used (what happened in Old World when Vulkan was enabled - at least before the latest update, which I haven't played yet), but since those VRAM allocations in Unreal happen by accident and only remain allocated for one frame, they aren't noticeable to players.

View this comment - View article - View full comments

Just to clarify: Denuvo has two very different products, and by just talking about Denuvo, it's not always clear which is meant.

The one most commonly requested by publishers is Denuvo Anti-Tamper. It has only one purpose, and that is to verify at certain points while the game is running, that the game's binary has not been modified. If implemented correctly (meaning: those checks are only being run when opening a menu, on the loading screen, etc.) it does not have any negative impact. Also, by itself, it's not a DRM. However it makes sure that DRM from some other source (usually Steam) has not been cracked by verifying executable file integrity.

The other Denuvo product is Anti-Cheat, which is a rootkit. This tool collects data on syscalls from games, and sends the data to the cloud for server-side processing. According to the developer it does not collect any data beyond the game/kernel interaction itself, so if that statement is to be trusted, the data collection is not worse than what could be done with in-game telemetry, just collected at a lower (harder to manipulate) level.

That said: I personally prefer DRM-free games, but don't have any big issues with Denuvo Anti-Tamper either (as long as it's used together with Steam DRM - other DRM providers that might or might not still exist tomorrow are a different story).
Anti-Cheat is something I avoid though, because the only thing that makes it not-spyware is that the developer promises that it isn't.

View this comment - View article - View full comments

Quoting: Craggles086

Quoting: soulsourcePSA: I had to learn the hard way that "Steam Deck Verified" does not mandate any gamepad support. As long as the game is playable with touchpad/touchscreen, it can get the green checkmark.

Any Controller??

Think you might need to look again.

Steam Controller should have better success than either XBox controller or PlayStation controller, as the config should be directly mappable to the SteamDeck controls, should just work out of the box in the same way as Steam Deck controls.

Plus you have community configurations. Touchpad should just work with right pad.

That's not what I meant. I meant that games can get verified as long as they are playable with touchscreen, touchpad or stick-mouse. Take Strange Horticulture [External Link] as example. That game does not have gamepad support, but can be played with mouse-only input after changing a setting (by default it needs keyboard input too - and does not open the on-screen keyboard automatically - but that game-feature can be disabled). It has the green checkmark though...
Of course those games can be played on the deck, but one has to suffer those imprecise mouse-substitutes, what is just a much worse experience on the deck than what is offered by games with full gamepad support.

View this comment - View article - View full comments

PSA: I had to learn the hard way that "Steam Deck Verified" does not mandate any gamepad support. As long as the game is playable with touchpad/touchscreen, it can get the green checkmark.

View this comment - View article - View full comments

Quoting: ObsidianBlkno matter then directional input I give, the menus always scroll up

I've had this too. I think (but am not certain) that some element above the current screen has the UI focus, and that, even though the focus is moving correctly based on input, the scrollbar moves "towards" the element that's actually in-focus off-screen.

View this comment - View article - View full comments

My biggest issue at the moment is that (at least for some games - One Deck Dungeon for instance) the input does not work after disconnecting an external gamepad until the whole Steam Deck gets rebooted. Just restarting the game does not have any effect.

My second biggest issue is https://www.reddit.com/r/SteamDeck/comments/t8qa15/i_am_having_problems_with_the_wifi_of_the_steam/ [External Link] - and yes, disabling power saving helps (a lot), but it does not fully fix the issue.

View this comment - View article - View full comments

Sorry, I just have to ask:
Is it coincidence or intentional that this article and the one about Tyrant's Blessing are right next to each other, given their very similar screenshots?

View this comment - View article - View full comments