Quoting: tuubi

Quoting: mborseIs it native on Linux? The article has a "Native Linux" tag. Is it native or Proton?

The original Dead Island and Riptide have native ports, DI2 does not. I guess the tag is for the Riptide giveaway.

Yeah, that's why I bought them, the native Linux support. It's a shame, native Dead Island 2 would be great, so would Dying Light 2 for that matter. It sucks everyone abandoned native Linux gaming.

View this comment - View article - View full comments

Instabuy for the native Linux support alone. But Quern was really good, so I'm looking forward to this one.

View this comment - View article - View full comments

Is it native on Linux? The article has a "Native Linux" tag. Is it native or Proton?

View this comment - View article - View full comments

Is it compatible with the SDL linux native port? The native Linux port was also ported to WebAssembly and it seems the remastered assets can be added: https://github.com/HomeworldSDL/HomeworldSDL [External Link]

View this comment - View article - View full comments

Intel only? Really? Are there any vendors selling Linux configured (no Windows tax) laptops with the choice of AMD CPUs, and combined GPU and/or NVidia cards? I have a Asus TUF Ryzen with Renoir and a RTX2060. Great machine, 2 NVME SDDs, 1x HDD. Great machine, and not so great screen. A wide gamut screen would be good, at least covering 99% AdobeRGB. But it seems that there are corners cut everywhere. And i certainly dont want intel. Wife has a XPS15. Amazing beautiful gorgeous screen. Except it buckled due to the heat from the CPU. Unusable piece of crap.

View this comment - View article - View full comments

Quoting: shawnsterpIdk,

I get that they promised a native build. But, i guess you have to decide what is more important: a native build for Linux or proper support for the platform. Granted, you have to decide what “proper support” means, but at its basic is “make the game run well on Linux”.

The mere fact that they have a comparison of the proton vs Linux build indicates that they have been indeed working on it, and have decided that the best performance comes via proton. So, this does bird feel like they are abandoning Linux or lying or whatever. It looks like they are trying to make it work well.

My takeaway from this is that — once again — Epic Games is playing a role in the quality of Linux gaming.

That's a terrible choice. Because you're paying the same and you're a 2nd class citizen. I bought all Feral Interactive games. I haven't played them all to be quite honest, my backlog is huge, and i suspect i won't play them all. Yet, i rather pay full price, 50+ euros, for a native build, with proper support, than being lied to in a KS project and then finding out at best i get to play the game under a fancified WINE.
I have the 1st Everspace, it's neat. This one looked neat as well, but no tux, no bucks. I still have my Quake 3 and Descent from Loki Games, Majesty Gold from LGP and tons others. Port them, and i won't be the only customer for sure. But this? Well. There are tons of other developers that need money and actually make native Linux builds. Probably not the latest and greatest AAA, but it's enough. If i want an AAA i might as well just get a console and save myself the hassle (and the waste of time)
Being a developer myself, i understand the pain. Knowing both UE4, UE5 and Unity from 1st hand (developer) experience, i get it. It's painful and sometimes production leads to towards legacy dead-ends where you're forced to make a choice you don't want to make. They probably ran into this situation and have my sympathy. But they still won't have my money. Perhaps we'll see a Everspace 3 in UE5 with a proper Linux native build.
Sorry guys.

View this comment - View article - View full comments

Quoting: Appelsin

Quoting: heidi.wenger

Quoting: fagnerlnfirefox improved a lot the startup time on snap and it's performing better in benchmarks than non-snap version.

So, the official snapped Firefox now works better than the old fashion one. How things change. And what negativity Canonical got from small but feisty band for this work in progress :huh:

I think most of the shit Canonical got was due to them literally trying to force you to use the snap, if you wanted to or not. Not because it shipped as a snap, which of course is up to them, but you couldn’t even uninstall it and sudo apt install “normal” Firefox, since *buntu was set up to install the Snap version even if you did the command to install apt/deb version. That, I think, was a mistake on their part, to think would go over well with people.

That’s some Microsoft level asshattery. “We know you tried to install Firefox, but we installed Edgeium instead.”

Are you telling me you can't purge that crap and mask it? I mean i'm totally fine building firefox from source, but if the system is coming out of the image with snap installed, configured, and its removal causing overall woes, i might reconsider my choices. Life is too short to fiddle with all the buzzwords that appear and fade away every N years.

View this comment - View article - View full comments

Quoting: soulsource

Quoting: mborse

Quoting: soulsource

Quoting: Dribbleondo

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.)

Fun Fact; Spyro Reignited's ability codebase is done entirely through blueprints.

Yep, the GameplayEffects framework is pretty powerful and helps structuring the blueprints to avoid ending up with Blueprints from hell [External Link].
What some other "Blueprint only" projects do is that they create the low-level building blocks in C++ and expose them as Blueprint nodes, so that only the high level logic is done in Blueprint. That has the advantage of having a small (-> readable) visual representation of the high-level flow, while all the low-level details, that would be hard to read in visual form, are implemented as text - and in addition, performance critical code paths tend to be in C++ then too.
(We used this approach for the mission setup in two of our games - the low level stuff was done by coders in C++, the high-level logic in Blueprint by designers, the bugs by a lack of communication between those two groups.)

Oh wow... i wish i could unsee some of those blueprints.
So in general terms do you prototype things in the editor blueprints and if worth it, you re-implement it as a building block? What criteria do you use mostly for this? Encapsulation factor for neatness, reusability, or both?
I agree about the lack of communication as well, specially when designers most of the times lack lower level knowledge that is useful, even if superficial.

Our general workflow has changed in the last few years. Initially we did prototype a lot of things in Blueprint with the goal to move the whole logic to C++ later for performance (nativising Blueprints was not supported back then), but found out that more often than not those "prototype" blueprints remain in the project until release for time reasons. This was an actual problem in Bus Simulator 18, when we added gamepad support later, because that required understanding very complex UI blueprints... Also, everyone who tried to make a bus mod for Bus Simulator 18 [External Link] knows that the bus blueprint setup was - let's just say I'm surprised nobody posted our bus base blueprint on Blueprints From Hell.

Since Bus Simulator 21 we try to do almost everything in C++, including prototypes. The main reason is readability and modularity, with performance being an added benefit. Emphasis on "try", because in BS21 some logic still happens in blueprints, and there are exceptions like the mission system. For the UI we added our own "framework" of sorts, where we back up most UI blueprints with a ViewModel on the C++ side, so that the view blueprint only needs to display the data computed by the view model and update itself when the respective event is triggered on the C++ side. For the missions the main reason to use blueprint was iteration times for designers when setting them up in-editor, but we also offer the option to create missions for map mods in BS21 [External Link], and all our modding support runs through blueprint.
What made prototyping in C++ viable was the addition of Live++ to Unreal. Though still some limitations apply on what can be done without an editor restart, this tool made iteration times for C++ changes nearly comparable to iteration times for blueprint changes.

The criteria when we moved code in BS18 from Blueprint to C++ were usually one of these two: Either we happened to have to modify some blueprint and it had already "grown organically" until it was utterly unreadable (so moving it over to C++ was synonymous with understanding what it does), or we found out during profiling that some code path in a blueprint was causing performance issues.

In Bus Sim 21 the first reason basically did not happen, because of the goal to also prototype in C++, but the second reason, performance, was still encountered quite often in late-game missions. (The Mission Helpers blueprint function library one can see in the mod kit is the result of that.)

Long story short: Both, neatness and reusability play a role for our decisions what to do in C++, with nowadays nearly all development happening in C++.

Thank you, it makes sense. I was kind of thinking if there was a point in having a (deep) technical artist develop a library of blueprints for prototyping purposes, to iterate fast, and then invest in implementing the most useful ones in C++ - at least to remove some of the excessive granularity of some of those blueprints from hell. I suppose it still makes sense, but all in all this hypotetical process would be much more tied to the C++ development team than to the technical artists, or designers from the get go, so we're back at the points you made. Thank you for your feedback and answers.

View this comment - View article - View full comments

Quoting: soulsource

Quoting: Dribbleondo

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.)

Fun Fact; Spyro Reignited's ability codebase is done entirely through blueprints.

Yep, the GameplayEffects framework is pretty powerful and helps structuring the blueprints to avoid ending up with Blueprints from hell [External Link].
What some other "Blueprint only" projects do is that they create the low-level building blocks in C++ and expose them as Blueprint nodes, so that only the high level logic is done in Blueprint. That has the advantage of having a small (-> readable) visual representation of the high-level flow, while all the low-level details, that would be hard to read in visual form, are implemented as text - and in addition, performance critical code paths tend to be in C++ then too.
(We used this approach for the mission setup in two of our games - the low level stuff was done by coders in C++, the high-level logic in Blueprint by designers, the bugs by a lack of communication between those two groups.)

Oh wow... i wish i could unsee some of those blueprints.
So in general terms do you prototype things in the editor blueprints and if worth it, you re-implement it as a building block? What criteria do you use mostly for this? Encapsulation factor for neatness, reusability, or both?
I agree about the lack of communication as well, specially when designers most of the times lack lower level knowledge that is useful, even if superficial.

View this comment - View article - View full comments

Quoting: gradyvuckovic

Quoting: elmapul

Quoting: gradyvuckovicI think sometimes the more technically skilled developers (or Linux users for that matter) forget that even among developers, there are those who are certainly capable of writing a bit of code and running a python script or clicking compile in an IDE, but struggle with something like compiling a complex piece of software through a build system like cmake, resolving dependency issues, etc.

worse, they forget that there is a magic thing called "learning curve"

Too right!

Even for the technically proficient, it takes an investment of time to learn how to use something, and the more complex / less documented / less user friendly that thing is, the bigger the time investment required.

In the case of porting some UE games from Windows to Linux, for some indie devs only really looking at the prospect of perhaps 10,000 sales total across all platforms, that time investment required to figure out how to obtain, compile and correctly configure UE, on top of all the 'first time user' learning required just to correctly setup and use Linux, wouldn't be worth it, for what would amount to possibly only a few hundred potential customers.

So anything that reduces the barrier for entry, is definitely a good thing.

There's a build script and a README with all the steps. It really isn't hard. It's even easier if you have a more or less "standard" distribution (by this i mean a Ubuntu LTS such as 20.04 for example), nothing too modern or too old. Configure and compile UE is trivial, or should be even to the most rookie of developers. If you have your own forks and game code upon it, writing portable standard code is a matter of good practice, and there are plenty of tools to assist you with that that even rookies can use (thinking about some static analysis tools, code conformance, etc). Note, i'm not advocating using UE or anything, but there are some (mis?)conceptions here that intrigued me, that's all.

View this comment - View article - View full comments