Quoting: mborse

Quoting: soulsource

Quoting: salomFinally!
I promised my self back in 2018 to never (compile, use or learn) UnrealEngine until they give us proper Linux support and a native build

Why? If you want to do anything reasonable with Unreal, you'll need to set up a build environment for C++ scripting anyhow (yes, there is Blueprint, but as soon as your project grows beyond "game jam" size, Blueprint scripts become so large and convoluted, that they are hard impossible to read/maintain). After using Unreal for a few days, you'll find yourself in the situation that you'll want to modify the engine because your project gets blocked by a bug in it. That's then the point where you uninstall the precompiled engine, compile it from source, and ask yourself why you thought it was a good idea to waste time on the precompiled build in the first place.

(Edit: Please take this with a grain of salt. I'm currently working with Unreal professionally, and had enough opportunities to get frustrated by it.)

I was thinking about the same, but have a bit of frustrations with (custom) forks since UE development occurs so fast that i was bitten more than once by breaking changes in the APIs, even with what were supposed to be small point releases. Lighting and shading, BxDFs in particular come to mind. But back to the discussion, the lack of binary releases for UE is a non-issue since the target users are developers anyway.

Yeah, I've just yesterday had a similar experience with some custom optimizations in decal rendering, that we (for the moment) decided not to merge into our UE5 projects, because it would require non-trivial manual merging...

In general we are trying to stay as close to upstream as possible in our project-specific engine forks. Most of our changes are backporting some fixes from newer engine versions, or fixing some issue inside a function. We try not to change any public APIs if possible. If something can easily be fixed or worked around on the project side, we strongly prefer that approach, going as far as duplicating engine classes in-project if it makes sense (for instance we have our own modified copy of TOctree2).
The one area inside the engine that we do modify heavily per-project are the online subsystems. Our multiplayer use cases are significantly different from what Epic needs for their games, therefore we usually have to add some features to multiplayer session handling functions (just as an example, we need to update session metadata while the session is running and forward that change to all players in the session, what is not fully supported out of the box by some online subsystems)...

View this comment - View article - View full comments

Good.
There are imho two kinds of people who want NFTs in games: Publishers who want to scam gamers by making unfullfillable claims about the potentials of the technology, and gamers who do not understand the technology and therefore fall for the empty promises of those publishers.

View this comment - View article - View full comments

Quoting: salomFinally!
I promised my self back in 2018 to never (compile, use or learn) UnrealEngine until they give us proper Linux support and a native build

Why? If you want to do anything reasonable with Unreal, you'll need to set up a build environment for C++ scripting anyhow (yes, there is Blueprint, but as soon as your project grows beyond "game jam" size, Blueprint scripts become so large and convoluted, that they are hard impossible to read/maintain). After using Unreal for a few days, you'll find yourself in the situation that you'll want to modify the engine because your project gets blocked by a bug in it. That's then the point where you uninstall the precompiled engine, compile it from source, and ask yourself why you thought it was a good idea to waste time on the precompiled build in the first place.

(Edit: Please take this with a grain of salt. I'm currently working with Unreal professionally, and had enough opportunities to get frustrated by it.)

View this comment - View article - View full comments

Quoting: levellordIs it suitable for kids? I am sure my 9 year old will ask for it the moment she learn about it. Thanks!

I've just played for about an hour, but from what I've seen up to now I'd say it is.
There are some robot "rats" (for lack of a better word) that attack you, so there's some action, but there was no visible brutality. All that happens if such an enemy catches you is that it clings to your character and you have to shake it off by pressing a button.

However, the game is actually rated by the USK, as "Approved for children aged 12 and above" (description of age categories [External Link]), what might be a better guideline than my personal gut feeling :tongue:.

Edit: It also has an ESRB rating, and that one is ESRB-E 10+. (Description [External Link])
Edit 2: Source for Ratings is the PlayStation store. USK is shown if you visit the German store, ESRB if you visit the US store.

View this comment - View article - View full comments

Computer games in a car... What could possibly go wrong?

(Edit: Just to be clear, I'm joking. I'm expecting them to prevent access to games while driving.)

View this comment - View article - View full comments

Quoting: DemandredDiscovering this community since I got my steam deck. Thanks for this site !
Noob question, all games that run on the steam deck would work on a linux pc as well? Shall I jump into a linux experiment.... wait I just did. first time on a linux desktop to install the emulation on the deck.

While the general answer is "yes", there are some things to keep in mind when dealing with Windows-games running through Proton:

• Graphics drivers. The open source AMD Linux drivers and the closed source nVidia Linux drivers have some edge cases under which they behave differently. The most important one is the situation that a game runs out of video memory. In the case of the AMD open source drivers, that will lead to a performance drop because system memory is used as a fallback. With nVidia's closed source drivers, the game will crash. This means that if you have an nVidia card, some games might not work on the desktop that are working fine on the Deck (which uses the AMD open source drivers).
• There are some subtle differences between Deck and desktop when it comes to video playback, that I haven't fully understood yet. It might be that you need to install GE-Proton [External Link] on the desktop to get videos running in some games. I'd still try Valve's official Proton builds first, but if those fail to play videos, GE-Proton might get them working.
• For some titles Valve considers important, there might be Steam Deck specific fixes.

Long story short, the best experience on Linux is still offered by games that have a native Linux build, but Proton can get a lot of Windows games running too.
I'd recommend to check protondb [External Link] for Windows-only games you care about, especially if you are using an nVidia graphics card (-> check the GPU the users reporting failure/success were using).

View this comment - View article - View full comments

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