I am not in the position to decide which tech we use at the studio, however, as a Senior my voice is certainly heard when it comes to tech decisions.
And for Unity I can only say: No tech is worth the risk of dealing with such a shady company.
I am not in the position to decide which tech we use at the studio, however, as a Senior my voice is certainly heard when it comes to tech decisions.
And for Unity I can only say: No tech is worth the risk of dealing with such a shady company.
Me neither. I only (have to) use Windows at work, all my own PCs have been running Linux for decades…
I do know however, that WSL emulates most (but not all) Linux syscalls, so you can ran (nearly) all Linux programs on Windows - including WINE. There is also a driver in Mesa so that you can render 3D graphics from within WSL on any DX12 graphics card.
They will likely write their own emulator, but don’t forget about WSL. You can already run WINE on Windows, I wouldn’t be surprised if you could also run FEX+WINE on Windows for ARM.
by intercepting syscalls and executing them directly
Not only syscalls. FEX and Box64 also allow using native libraries instead of emulating them. That leaves basically only the game logic to be emulated.
Yep. The big question is if the gap will close enough that ARM chips indeed end up delivering better power efficiency with emulation than an AMD64 chip that delivers the same performance without emulation.
My bets would be on the native AMD64 chip ending up more power efficient. To be honest, I would not bet too much money though.
ARM based Deck would be a huge improvement to battery life. Don’t get your hopes up too high. You will need an emulation layer like FEX of Box64, and unlike WINE those do have quite a substantial overhead.
It is impressive how far those emulators have come, especially since they got the option to use native libraries instead of emulated ones, but the game logic itself will always need emulation…
This doesn’t mean it can’t be done, it just means that the ARM CPU needs to be pretty fast to counter the emulation overhead, and that’s why I have my doubts about the energy efficiency…
(Btw: I have tried running several AMD64 games on my A311D powered MNT Reform laptop with Box64. It’s impressive how well the emulation runs, and how many games are actually playable already. However, I also encountered a lot of games that don’t reach enjoyable FPS on that hardware. With a faster ARM chip though…)
It depends on what kind of patent. I just googled the term I had used before, and it is indeed what I expected it to be: https://en.wikipedia.org/wiki/Design_patent
And yes, that name is stupid. That’s why I am happy that my native language, German, has a better distinction between “Patent” (what you described) and “Geschmacksmuster” (design patent).
About patents being public: They are. That’s because the idea behind patents is that after they expire, anyone can use them to build the technology they describe. The temporary exclusive usage rights that they offer are meant as an incentive for inventors to publish their findings. The only problem is that the legal situation did not keep up with the creativity of patent lawyers… (I will stop now, otherwise this will turn into an endless rant about how broken the patent system is.)
I’m not sure how the term “patent” is to be interpreted here. It could be used like back in the days when Apple sued Samsung because their phone had rounded edges too…
Like a “design patent” (sorry, I’m not a native English speaker, so I’m unsure if this is the correct translation).
A lot of the pals in the game look quite close to Pokémon. Not identical, of course, but so similar that one just has to wonder if the design has been “inspired” by Pokémon…
Amnesia.
Short answer: Whales.
Long answer: Watch the South Park episode on the topic. They explain it in detail. It’s titled “Freemium Isn’t Free”.
Need to enshittify it enough to make the AI features feel like an improvement.
This. There is very little need for third-party tools, as long as you don’t want to install a whole lot of games. After all, the installation process only happens once per game, and also without tools it doesn’t take very long.
As a step-by-step guide:
I would be very surprised if they wouldn’t fix all 50 filesystems.
In all projects I have worked on (which does not include the Linux kernel) submitting a merge request with changes that don’t compile is an absolute no-go. What happens there is, that the CI pipeline runs, fails, and instead of a code review the person submitting the MR gets a note that their CI run failed, and they should fix it before re-opening the MR.
That’s a very good point. I hadn’t considered potential lack of domain knowledge at all. In that case Rust might even help, because it’s easier to write interfaces that can’t be used wrong - so that even someone without the needed domain knowledge might be able to fix compile issues without breakage.
Behind all the negative tone there is a valid concern though.
If you don’t know Rust, and you want to change internal interfaces on the C side, then you have a problem. If you only change the C code, the Rust code will no longer build.
This now brings an interesting challenge to maintainers: How should they handle such merge requests? Should they accept breakage of the Rust code? If yes, who is then responsible for fixing it?
I personally would just decline such merge requests, but I can see how this might be perceived as a barrier - quite a big barrier if you add the learning cliff of Rust.
I don’t know if this applies to CLAW, but many games back then had their audio stored as CD Audio Tracks. If that is the case, you might want to actually emulate a CDROM drive instead of just extracting the files. There is a CDROM emulator for Linux, called CDEmu, which can read CUE/BIN CD Images.
Oh, and that game seems to have an ancient 16-bit installer, which might not work on modern systems. However, according to WineHQ Appdb one can just copy the files from the CD and it works.
I know it’s a cross-post, but since this is not on the cheap, but rather on the libre side: Have you checked out the MNT Pocket Reform?
I only use my Steam Deck while I am away from my gaming (Linux-)PC. The reasons for this are that for me a big screen wins compared to the small (and relatively low-res) display of the Steam Deck, and also the games I usually play play way better with mouse and keyboard than with gamepad input… Also, the Steam Deck is relatively heavy, so gaming in bed or stuff like that also isn’t that enjoyable…
That said, the Steam Deck absolutely shines in situations where I cannot access my gaming PC. I usually take it with me when I go for a longer train ride, and also brought it along for vacation.
Compatibility wise I am in the situation that all the games I ever tried are working on the Steam Deck, but that’s mostly because I have been using Linux exclusively for decades, and have made it a habit to check if a game is going to work before buying it. Though, in recent years that habit slightly changed, thanks to the work Valve has put into WINE development. While back when I switched to Linux most Windows games would not run via WINE, nowadays one can expect that almost all games do. It is still a good idea to check protondb first, of course. Also, there are still a few games that need tinkering to get them to run, and protondb usually has some info on how to do that.
One negative point I have to mention is battery runtime. It strongly depends on what one is playing, but very demanding 3D games can drain the battery in 1.5 hours. However, I am talking about the old LCD model here, the newer OLED models run longer with one charge (though I don’t know how long actually).
Another negative is the display resolution. Most games don’t mind running on 1280x800, but some do. This can lead to illegible text, broken UI, or, as is the case with Stellaris, a different UI that is less convenient to use.
And last, but not least, performance. The Steam Deck GPU is just enough for the built-in display’s resolution, and also only under the assumption that games are reasonably optimized. I have not yet been in the situation that I would have gotten unplayable FPS, but I have heard a lot about games only running with 20 FPS, and needing upscaling… So, basically don’t expect it to run Crysis (yes, I know that joke is old, and that the Steam Deck can run Crysis just fine).
I haven’t looked at the schematics, so I am not certain which connection exactly would be needed. I only know that the Reform Mainboard and the Reform CM4 adapter don’t expose any way of writing to the eMMC other than booting the system first. The problem here is that the Banana Pi CM4 boot process first looks for a bootloader in eMMC, and only if it cannot find one there, tries the SD card. So, if one flashes a bootloader that gets recognized by the firmware, but that later fails to boot, one is stuck…
The I/O board on the other hand allows to connect to the CM4 via USB, and there is a weird, but supposedly working, procedure to erase the data in eMMC.
In any case, I now have a spare CM4 I/O board lying around, and if I ever choose to upgrade my Reform to the Rockchip SoM (or something even faster), I can then still use the CM4 as a small standalone PC.
Oh, that just happened. We didn’t have established processes for promotions for a very long time. The company was a tiny startup when I joined (quite literally in the cellar of the company founder’s place), with a really flat hierarchy and no distinction in seniority.
At the point when the company started to set up a formal process for promotions, I had already been there for so long, that I was considered one of the most experienced people, and that’s how I ended up being filed under “senior coders” in the employee list basically since that category existed… It also was a bit weird, as that happened to coincide with all the COVID lockdown chaos, and I never had a formal promotion talk, just an email with an amandment to my contract, which I didn’t even read too carefully, so I didn’t realize at first that this was not just the yearly pay increase 😉.
Oh, and believe me, the impostor syndrome is strong with me. I would not have promoted me to that role.