Cryptography nerd
Fediverse accounts;
@[email protected] (main)
@[email protected]
@[email protected]
Lemmy moderation account: @[email protected] - [email protected]
Bluesky: natanael.bsky.social

It’s not network effects (but slightly related), it’s opportunity cost.
Getting your app into yet another app store isn’t hard, but takes time, so you need to make sure it doesn’t cost devs more to add support for you than it earns them. The slightest fuzz and they’ll drop you if you’re small.
But stores like Gog are able to exist just fine. They’re big enough that many devs think it’s worth it to support them. If you want more devs to do so, tell them that’s what you want and show it will be worth it. And if you want to open another store, copy Gog & co
The Gameboy Advance could connect to a GameCube and Wii (both as a controller and to link games), GBC and N64 had the transfer pak
IMHO that was the best era of games, besides the NDS. I absolutely want the return of mobile + stationary modes in games, especially local multiplayer games. The GBA could for example show private game state to its player when used as a controller for a GameCube game! And you could bring your characters to your friend’s games without needing an Amiibo, you just linked your consoles together.
Look how far this dude went to recreate it;
So the term you want to look for is telescoping controller, when you’ll use it with a foldable.
Something like this one would be perfect with a Razr for DS emulation (but beware you have to check minimum supported width too for a clamshell foldable);
https://www.8bitdo.com/ultimate-mobile-gaming-controller/
https://www.androidauthority.com/gamesir-g8-plus-review-3463391/
https://www.androidcentral.com/how-turn-your-galaxy-z-fold-3-nintendo-ds

If you have a split game controller, I recommend using that over touchscreen controls. And using a controller like this plays better with a vertically aligned foldable phone (clamshell) rather than the pseudo-tablet sideways foldables, as you fully recreate the original physical controller layout
Some of the things make sense, but overall I agree.
3D display simply died, everybody did it for a while but so few things used it well that it wasn’t worth the cost (especially since it hurts quality unless you can get the player to use special glasses).
You could use touchscreen compatible stylus, but no extra features connected to it.
Definitely miss analog triggers, which also hurts emulation (GameCube). Something streetpass-like could’ve been put in the mobile app (which also is way too limited and supported by too few games).
Absolutely miss customization too.
Gen 1 Switch should also already have gotten a top side USB C port - with support for accessories like a camera + mic (which wouldn’t have necessarily been built in, but supported).
Switch 2 could benefit so much from better local discovery especially now that it has GameShare, you could have it passively advertise supported games so you could discover opportunities to play even games you don’t have (much like how Download Play used to work on the Nintendo DS and GBA)

Current Valve is trying to do what Google used to do with the Nexus phones. They’re setting a minimum standard for other companies and showing what the experience can be like.
After the next Steam Deck version (which they’re supposedly doing in-house) I suspect they’re going to get OEMs to make each following iteration, just like what Google used to do after the first few Nexus versions

Not entirely;
https://github.com/microsoft/ebpf-for-windows
Microsoft just want that 3rd party code to interact in a more predictable way with the kernel

No, the container environment uses default open source libraries. You don’t add any Steam dependencies to make software run in that environment. You can run it without Steam too. It’s just that Valve are the ones maintaining and updating this particular packaging of containers. When Valve releases new versions of their container (including updated default system libraries), you have to test compatibility with it or stick to using an older one. Similar to how Windows software versions would work best with different Proton versions.
You can use the Steam SDK when using it, and you can also choose not to.
Flatpack is a separate thing, which only handles Linux software within the regular desktop environment (a different method for packing software dependencies, managing system permissions, etc). The main difference is that Flatpack software can integrate with the regular Linux desktop environment, but the container based solution is fully separate from it (runs in gaming mode).

No, Wine (and Proton) is a compatibility layer (API translation, etc). Containers is an isolation method which hides the details of the OS from the software and gives it a standardized environment.
https://github.com/ValveSoftware/steam-runtime
No matter what Linux distribution you run Steam on, the only thing you need to do is to get the container system up and running. Once that runs, all software that runs in these containers will run on that device.

There’s a lot of similarities and differences - the Steam Deck’s gaming mode is able to run a very barebones OS, similar to the very basic OS that the Nintendo Switch runs, with the game running in comparable sandboxes with stable software interfaces.
But Nintendo worked with Nvidia specifically to develop a variant of their hardware dedicated for gaming, while Valve essentially put a Linux laptop in a handheld console format (IIRC they did get help from AMD, but it wasn’t the same kind of deep collaboration), which notably may have different components between different hardware revisions.
When you try to maximize game performance that makes a difference, because on the Switch you can reliably push the hardware to the limits and expect it to keep working and on a Deck you have to test the hardware before pushing it. And if you find a trick that depends on architectural quirks you have to special-case it to not break on other hardware. There’s no guarantee that rarely used hardware features (both physical, and CPU/GPU instructions, etc) will stick around on a future revision of a Deck, while Nintendo guarantees forward compatibility (with help from Nvidia).
Nintendo even worked with Nvidia to emulate the Switch 1 GPU when running games for the first Switch on a Switch 2! They’re even going so far that they’re patching the emulation layer on a per-game basis to fix games where the default emulation method fails! And the ability to do this depends on knowing the exact properties of the hardware revisions of both the original and new GPU! (there’s architectural differences in the GPU that would break some games unless it was emulated)
Now Lenovo also has devices running SteamOS on different hardware, so games that runs on both either needs special cased optimizations for both, or only generic optimizations, or they simply have to decide to support one specific model better than others (which could end up with a game looking worse on better hardware because the dev didn’t try as hard with that hardware)

Steam on Linux defaults to providing a container based standard Linux environment which is independent of the underlying OS, providing access to all the expected software libraries and OS calls that games need to run.
This is integrated into SteamOS. It’s also available via Steam on any other Linux distro. (And if you wanted to you could cut that part out and run it without Steam.)
When running Windows games it even runs Proton within this container environment.
That gives you a single very predictable and version controlled software environment.
Meanwhile Windows randomly deprecates stuff that somebody might have invested tons of development effort into (silverlight, mixed reality, etc)

OTOH I only have a PS5 because of Sony’s marketing budget, lol (non-slim version included with a Sony phone on contract, so technically also a way for them to clear stock, lmao)
But yeah, I don’t know any people with a recent Xbox here in Sweden. In the original Xbox era and the 360 era I think they had a big lead here, but after that I’ve seen much more Sony represented.

They’re probably building off Windows RT (the locked down variant designed for ARM tablets).
If they were smart they’d imitate some of how SteamOS runs games in a modified WinRT environment - TLDR do NOT start up the entire Win32 runtime and desktop environment by default, don’t run stuff like printer services and whatnot, just run a simplified sandbox and window manager with just the APIs needed to run the games similar to Proton. Then let the user switch to desktop mode as needed, but don’t run it when gaming.

It seems like there’s nothing special about the camera, hopefully you could use others.
The SD Express makes sense, they’re not just upcharging (you can use any manufacturer’s cards), it’s how they guarantee the storage is reliably fast enough for all games to prevent lag in loading speeds
But for the other accessories, sure. And charging for switch 2 edition upgrades is annoying.
All the RISC-V chips I see in the wild so far are stationary or tiny (like some new ESP wifi chips now run on RISC-V)
Mobile / laptop grade performance chips seems a few years away still, tons of optimizations needed (especially fast performance scaling and idle modes) for that