Signed Kernels are problematic for some users. While the distribution-supplied kernel binaries are fine for most users, there are always those who want to (or need to, due to hardware quirks or bugs) tinker with the kernel compile-time configuration, or the kernel source code itself…
In Physics we mostly used right-hand, but X-right, Y-up, and Z pointing towards the viewer.
But that’s details. The only important choice is between left- and right-handed, as that affects the signs in the cross product (and some other formulas - generally everything that cares about which rotation is considered positive).
Near-Mage. It’s a point-and-click adventure from the same studio that also made Gibbous, and set in the same world. However, the theme is much lighter. Gibbous was (while still a comedy) about cosmic horror. Near-Mage is fantasy.
While I definitely recommend the game, it is lacking a bit when it comes to riddles. Most point-and-click adventure games have lots of them, where you need to think, give up, and then just try random stuff until something happens. This is almost completely missing in Near-Mage… There is almost always a quest goal that directly tells you what to do - up to the point that situations that give you a choice are explicitly marked as such.
On the other hand, just like Gibbous, the game is beautifully drawn and animated, and all dialogues are fully voiced. The characters are likeable and - call me a furry if you want - really cute. What keeps me playing is mostly the world - there is always new stuff to discover, even in late-game, and the mix of fantasy and (what I assume to be) Romanian folklore is great.
I have to both agree and disagree here.
Disagree because it doesn’t look that bad.
Agree because there is a reason I haven’t used the Deck with a big screen in months.
Two things to add regarding question 1:
The Steam Deck GPU is optimized for the built-in screen, which has 1280x800 pixels. FullHD is more than twice the number of pixels. The GPUs fragment fill rate will therefore not be sufficient to play many games at FullHD native. The Steam Deck has built-in FSR upscaling though, so if you are not sitting directly in front of the screen, it will look OK-ish…
The second thing is refresh rate. On the deck itself you can set the screen refresh rate to 40 Hz. For many, many games the built-in GPU will not manage 60 FPS even at 1280x800, but it quite often manages to do 40, which still feels OK-ish.
Most external screens don’t support 40Hz though, so you will be stuck with either limiting your framerate to 30 FPS, or you will have to live with either tearing or unsteady framerate.
I now have run into the issue that I myself cannot play Minecraft on my Linux laptop, which is an ARM machine and the ARM Mali GPU does not support the OpenGL version that Minecraft requires. (It also needs some hackery, as the Java-written Minecraft uses some native code libraries.)
I’m now playing VoxeLibre instead, which runs mostly fine on my laptop.
This. So much this.
The “backlog” is not something to work through, it is a lesson to learn: Do not buy a game unless you have time and are motivated to play it that very moment. If you buy it to play it “later”, or “next week”, you very likely are not going to play it, and it is just wasted money.
(The same is true for books, by the way. And when it comes to books, I refuse to learn this lesson.)
What is stopping you from playing Minecraft itself on Linux?
I haven’t played it in a while, but it did work perfectly fine last time I tried it. It is written in Java, after all.
While I am not aware of any way to run custom software on the Steam Deck while it is on standby, you can drastically reduce the power drain if you shut it down fully instead of leaving it on standby. You can either use the “Power” menu after pressing the steam key, or long-press the power button to get the option to do so.
I would not say “lazy”.
There are a lot of bold promises in Unreal Engine 5 advertisements, that get taken up by publishers and producers - and then end up in the game budgets…
And then, near the end of the project, when it turns out that performance isn’t good because the advertisement promises have been a bit too bold, there is no money for optimization left…
Also, if I am allowed to do some absolutely shameless self promotion: Bus Simulator 21 is verified, and 18 is playable.
I need to give two perspectives here. One from my day-job as a gamedev, and one from my hobby as a gamedev.
The main difference is that in my spare time I do not have to suffer working on Windows.
So, first about work: I have switched from an nVidia card to an AMD one in 2022, because my work PC’s nVidia card had too little VRAM to run the editor of Unreal Engine 5. Editor performance was abysmal (due to the nVidia card’s limited VRAM) and running out of VRAM also frequently caused the editor to crash.
After I switched to an AMD card, those crashes were gone and performance of the editor was way better too (because it now had enough VRAM to no longer fall back to system RAM). However, Unreal kept complaining about a driver bug regarding synchronization, that never led to any observable issues other than running into a (continuable) assert on editor startup. I am still using this card, and after some driver update, that warning went away.
The AMD card is working flawlessly for me, and I honestly do not want to switch back.
There is one thing that I need to highlight though: The nVidia rendering debugging tools (most important: nVidia Insights) are locked to nVidia hardware. AMD’s tools are not locked to AMD hardware. So, if you use an nVidia card, you get access to all tools, while on AMD cards you need to make do with the tools you get from AMD (or Intel, or Microsoft).
In my spare time I luckily don’t have to use Windows, and on Linux the AMD drivers are, in my opinion, superior to the nVidia drivers in almost all aspects. The most important thing about them is that they are open source, so you can actually edit the drivers, and mesa (the open source project that contains the OpenGL runtime) has some pretty amazing debugging features.
The AMD Linux drivers also integrate way better with the various desktop environments. With the nVidia drivers you more or less need to use the nVidia Control Center for some settings, what is not the case with the AMD ones.
The one drawback I see on Linux, compared to the nVidia drivers, is that setting up OpenCL is a little bit more involved with the AMD drivers - but since you nowadays can combine the open source drivers with the ROCm OpenCL runtime, that’s not that a big deal any more.
Last, but not least: In my experience the AMD drivers are “more strict” when it comes to using graphics APIs and shader languages correctly. Back when I still used an nVidia card, I caused several bugs that only surfaced on a coworkers’ AMD card. In all of those cases the bugs were actual bugs in my code, that only worked because they accidentally did the right thing on nVidia due to implementation-defined behaviour…
It’s the Windows way. There applications typically also ship all dependencies. Either statically linked, or as a DLL files in their install folder.
It’s not a good solution, but for games that’s imho OK.
I’ll give you my point of view as game developer.
Disclaimer first: I work as a coder, everything I say about publisher interaction is second-hand knowledge.
We have made one Linux game. It was the first one of our two “indie” titles (quotation marks, because both of them ended up being partially funded by a publisher, so they weren’t really indie in the end), where we had promised a Linux build on Kickstarter, long before a publisher got involved.
The main reason why we did not do native Linux in our publisher-funded games is quite simple: Our publishers didn’t pay us for it.
There are actually some publishers who are very keen on getting native Linux versions for their games, but we sadly have not released a game with any of them yet…
The publishers we released games with did not agree to the buget that we think is needed to do a Linux port of sufficient quality. If we would lower the price for doing a Linux port to the point where our publishers would agree to it, we would take on a lot of financial risk ourselves, so this is sadly not an option.
If everything worked as it is advertised by engine developers, making a Linux version would be quite cheap: Just click a few buttons and ship it. This is, sadly, not the case in real-life, as there are always platform specific bugs in game-engines. Our one Linux game was made with Unity, and we had quite a few Linux-only bugs that we forwarded to the Unity devs (we didn’t have engine source code access), and had to wait for them to fix… For the engine we mainly use nowadays, Unreal, we have a rule-of-thumb: “Engine features that are used by Fortnite are usually well maintained.” There is no native Linux version of Fortnite… (We did try Unreal’s Vulkan RHI in Unreal 4.26 for Steam Deck support in one of our games. Let me put it this way: The game in question still uses Direct3D on Steam Deck.)
So, from experience we expect that the chance that we would have to find and fix Linux-specific engine bugs is quite high. Therefore we have to budget for this, what makes offering a native Linux version relatively costly compared to the platform’s market share. Costly enough to make our publishers say “no”.
This, by the way, also answers the question why publishers are willing to pay for the way more expensive console ports. There are also way more console players, and therefore potential customers out there…
(I can only guess, but I would expect publishers to be even more reluctant to pay for native Linux, now that WINE works so well that getting a game running on Linux needs typically zero extra work.)
As a gamedev I never saw this as a big issue. Just run Debian Oldstable on your build server, link whatever you can statically, and you are good.
(However, I am talking on a purely theoretical level here - we only released one Linux game, and that was before I joined the company. I will explain our actual reasons in a separate post.)
It isn’t that easy to go indie though, unless you do gamedev as a hobby and have another source of income.
I am working at what was a small studio (about 10 persons) when I joined, and has meanwhile grown to more than 50 employees.
I am a coder, and therefore don’t have direct insight into our finances, so please take everything below with a grain of salt. It is also intentionally vague because I don’t want to violate any NDAs.
Over the years we have started two indie projects, that both were completed and released, but both in the end had a publisher funding a part of the development. So, while they were indie initially, the released products cannot be called indie any more… The reason why we went for publisher contracts for those two projects were manyfold, but an important part was simply that we needed a way to cover our running costs. We are doing gamedev as a day-job, after all, so it needs to pay for our rent, food, etc… (Other important reason for going with a publisher were marketing, customer support,… All the things that we as developers have no experience in.)
Now that we have grown to medium studio size, we are hoping that we can at some point fund an indie project by making enough profit with other, publisher-funded projects. We have several projects running in parallel anyhow, and if 3 of them would yield enough money to pay a 4th project that would be fully our own, we would definitely go for it.
However, the market situation is tough, and we currently cannot afford to do that. Almost all profit we make goes into developing prototypes that we need in order to have a realistic chance to get the next publisher-funded project…
Two years ago it was a lot easier to get publisher contracts. Back then we were quite optimistic about being able to fund a fully independent project, but then the market changed, getting new publisher-funded projects has become a lot more difficult, and right now doing an indie project is (for us) not financially possible…
So, what we are doing now is that we are taking our game ideas and presenting them to publishers. The prottypes I mentioned? Most of them are for our own ideas. Having something the people at the publisher can play goes a long way in convincing them that a game-idea is fun. That’s not indie, but it is as close as we can get to making the games we want to make. While the last year has been tough, with publishers being very, very, very cautious about new ideas, the situation seems to slowly change, and we might eventually get funding for one of our own ideas. Maybe. If we are lucky.
You can’t build a game studio without funding, and that is where the problem lies…
Publishers have become very risk-averse ever since Embracer went downhill. They basically only invest in <literally the same game as some previously successful title>…
I would rather not waste money on a Windows license I am not going to use.
(Not that I would buy an Ally, I already have a SteamDeck.)
I fully second the sentiment that there is no good reason to switch distribution once you have found one that you like.
However, if your goal is to learn something new, and you don’t care about having to nuke the install and start over, then you could go the crazy route and install Linux From Scratch. It is unlikely to yield a maintainable result at first try, but if learning is your goal, this is your best shot at it.
Or you could go the not-that-crazy route and use Gentoo, which is basically Linux From Scratch, but automated. Setting it up is way quicker (couple of hours - except if you configure the kernel by hand), and you will with near certainty get a maintainable system on first try, but it is also far less educational, given that the automation does most of the work for you. (I have switched from Debian to Gentoo 10 years ago, after trying it on my netbook for some time, and I could not be happier. It only does what it should, is rolling release, and only very rarely has issues.)
I would only recommend those two approaches on a second PC though, without immediately switching the main PC over. Linux From Scratch is, as said, unlikely to yield a maintainable installation on first try, so you will likely nuke the install again. Gentoo, while perfectly usable as a daily driver, is certainly not everyone’s beer, and you might simply want to switch away again because you don’t like it.
If you count DOSBox as emulation (what it definitely is - unlike WINE it actually emulates an x86 PC and peripherals):
I’ve played both on the Deck, and they both work great. (Btw: I did not use Settlers 2 as an example for my DOSBox setup guide by chance. I picked it because it is an amazing game and still fun nowadays.)