Yeah, I’d assume that a 75mph impact between human/deer and a vehicle is going to go badly regardless.
There is a lot of evidence that a low front with a significant upward slope (where a struck pedestrian is pushed up over the vehicle) is much safer for pedestrian collisions, but for quite awhile now the style has been flat or aggressive grills. Far from just the cyber truck that’s guilty of this
There’s two competitions here, windows vs Linux, and steam vs epic.
Of those two, I consider windows vs Linux the more important competition for consumers. And Linux is the underdog there, so I think Linux doing better will help more people than any other result of this.
So the question becomes, is this good or bad for Linux? More official support for Linux is good obviously, but also Valve funds a lot of open source projects and generally invests a lot of money in Linux (and I’m very doubtful that Epic will do anything similar). So arguably Valve doing better and having a larger monopoly might do more good in the long run, if it helps counteract the windows monopoly. Of course, that would only matter if Epic on Linux actually dents Steam’s market share in any meaningful way, which seems unlikely.
Heroic is a great option, and will likely remain most people’s preferred way to play Epic games on Linux/SteamOS. After all, a lot of windows users prefer heroic there as well due to the bloat/slowness of the official Epic launcher.
That said, official support is always good. It both represents that Linux is growing and a viable alternative to windows, guarantees better support from games on the platform in the future, and pressures other companies to also support Linux.
Basically this (and GoG adding support) are big deals, even if it’s not because we really needed their official support to have a good way to play their games.
Proton is really meant to work through steam, UMU is meant to replicate how reliably games run through steam+proton without steam. There’s a reason that heroic and all the other game launchers are switching to UMU as the default for running games.
My basic understanding is that, in addition to proton, steam provides a set of Linux runtimes, to make sure that the converted system calls from proton always match up with the correct standardized runtimes on the Linux system, regardless of distro. They also provide winetricks/protontricks as needed for games. There’s also some system variables passed to tell proton/etc that the game is running through steam and has this setup. Finally steam distributes shader caches, which both improve performance, and bypass proprietary video codecs by replacing them with open source friendly video files.
UMU is basically replicating all of this except the shader/media distribution, hopefully allowing games to run as reliably outside of steam as they do inside of it.
As always, Tim Sweeney only cares monopolies and alternative platforms when it’s financially beneficial.
Yes, I expect they’ll just make a Linux client and rely on UMU or some other open source project to actually get them to run.
I don’t expect them to meaningfully push the Linux platform forward as Valve has done.
Are you saying that they’ll intentionally sabotage attempts to play Microsoft store/game pass games outside of their platform due to malice, or that they’ll constantly break their own systems through incompetence and vibe coding?
A fair stance to take
A valid point
Great! Glad that worked for you
Also, AAA is struggling with games being too large. Every game is so expensive and has so many years of development that it’s hard for a studio to survive a flop without a major publisher. But the major publishers are pushing for studios to pursue games that have a really high flop rate (live-service, competitive shooters/etc). Additionally because every game has so much money invested in it, the studios are scared to try anything too different or unique, resulting in the games having a bland “design-by-committee” and not offering anything meaningfully different from what’s already out there. Features are intentionally held back so that the game will have content to drip-feed the players later, resulting in lacking content at launch.
I really think the AAA industry needs to downside, split up many AAA studios into multiple AA projects.
It uses a Steam Deck motherboard, which isn’t available as a replacement part, so you’d have to have a full deck. It might be a good option for steam decks with a broken screen though, since that part is completely replaced.
You’ll probably have better luck with heroic, but for steam try these
I would install them through heroic rather than lutris or something else.
Alternatively you can add them as a non-steam game and run them through steam, although if the game has an installer you might need to run the installer and then change the target in steam properties to the game executable. Overall this method is a lot messier than heroic.
I was fine with Doom Eternal’s weapon wheel, since it slowed down time it gave me time to pick what I needed. If you’re wanting to do quick weapon swapping like some high level players do that obviously won’t cut it though. That said, I had the back buttons already mapped to dash/jump/chainsaw/etc so couldn’t use them for weapons.
One way you could set it up is with control overlays, where you have one button cycle through multiple weapons. So you could have a back button that switches to super shotgun, but with a second press switches to the regular shotgun. Repeat that for the other weapon types with the other back buttons.
Are you playing this on the Deck? It’s pretty impressive that it’s playable at all considering how terribly it ran at launch (well, wouldn’t run at all originally, but then ran terribly on Deck after getting some specific proton patches)
You would think this would encourage better optimized software, but I doubt devs will actually do that. Most modern code practices are about ensuring that code is more easily maintained, often at the cost of performance. Breaking “clean code” rules can easily make programs run 10-25x faster, but will be much harder to maintain.
We also seeing a lot of vibe coding now, which mixes clean code practices (which are well documents online) with messier, less well planned code.
If you adjust the sensitivity, you can make it not require very much movement.
That said, I personally haven’t found a use case where I prefer it over other options.
Some newer monitors can support stuff like HDMI-CEC, HDCP (aka DRM to prevent copying video feeds), and EDID handshakes. Your motherboard, especially if it’s older, is probably getting hung up trying to resolve these during boot.
You can go into the monitor’s settings and try disabling extra features like HDMI-CEC, upgrade your motherboard bios, switch to display port (or display port->HDMI cable), or try disabiling legacy boot. There’s probably some other stuff to try, but that should give you somewhere to start.
You can also gather more info, like if it happens with other HDMI monitors (specifically newer monitors only or all HDMI).