Tag: wine

Categories
video games

Valve’s Pre-Release Teardown of the Steam Deck Shows You How to Replace the SSD

Valve published this video to YouTube today demonstrating how to open up a pre-production Steam Deck, replace the custom analog stick modules, as well as the SSD, and very much warning against doing so:

I’m not sure how I feel about the warnings. In the past I’ve definitely felt bad about breaking or inadequately modifying things that I’m working on but that is also a necessary part of learning how to modify, fix, and build electronics. The parts in modern electronics are delicate and often made to be unserviceable by the companies who design them, this is “for our protection” as users but it is also clearly for their benefit. The longer things are usable and repairable, the less money these companies make on new sales.

That also doesn’t mean the executives at these companies want users to have a bad experience. I can’t be sure of this, but from my experiences my understanding is that these decision makers want users to have a great experience and be motivated to upgrade by new features as well as repairs that are so expensive they make recycling broken hardware a better option.

Valve is also not in a great position with regard to supporting the users of their hardware but may be getting better. It’s one thing for a huge company like Apple who has physical retail stores to lock users out of repairs, there is an argument there that I disagree with from Apple that Apple can provide the best support. Valve has none of that retail presence to repair, replace, and even just troubleshoot hardware near their users. I think that’s why they made this video, essentially arming the more experienced hardware repair technicians to have access to repair these devices when they start breaking down. Valve even makes a promise in the video about upcoming Steam Deck part availability for people doing repairs.

As an example, according to a friend in Australia all Valve hardware sales and returns are done through the local EB Games chain. Apple does the same thing. In several countries where Apple does not have a physical retail presence they train third parties in how to service iPhones, iPads, and Macs. I once started but did not complete that training before my life took me elsewhere.

There are also still criticisms I have about Valve’s attitude regarding Linux porting which, to the best of my knowledge, is still putting people who are in the business of porting games to Linux natively out of work as well as advising developers not to port games natively and instead relay on Valve’s Proton Windows API compatibility layer/emulation to make games run under Linux.

The one “bright spot” in the Steam Deck’s software support is that Epic’s Easy Anti-Cheat middleware is promising Linux support. Previously, anti-cheat middleware locked out some Linux users running games under any Windows API Compatibility layer/emulation like Valve’s Proton and simply wasn’t available for native ports. Now, Epic has promised that Easy Anti-Cheat is available for both Native Linux and Mac game ports, including the Linux-based Steam Deck, and will be supported in WINE and Valve’s Proton. Unfortunately the decision to allow WINE and Proton to run these games is still only in the hands of developers and publishers who may not be interested in providing any support to Linux and macOS, quoting Epic:

To make it easy for developers to ship their games across PC platforms, support for the Wine and Proton compatibility layers on Linux is included. Starting with the latest SDK release, developers can activate anti-cheat support for Linux via Wine or Proton with just a few clicks in the Epic Online Services Developer Portal.

This makes it more likely that games using Easy Anti-Cheat will be able to support WINE or Proton, assuming business interests about support costs and other middleware doesn’t get in the way, but when those games get that support the compatibility is a coincidence that can disappear with any future updates.

Valve is still the wrong company to be making hardware and software decisions that affect the rest of the game industry. Valve are presumably, by majority of their income, a store for third parties. The people running stores have different motivations from places that exclusively make and sell hardware products and what software decisions are best for developers. Although I think the people who work at Valve clearly are trying to make the Steam Deck as open as possible and often do make the best decisions for developers and users, the motivations of people running a store are to sell things, maximize their own profit, and not to make good products for the overall health of an industry of developers who are still overworked, abused, not organized, and ruined by the success of the wealthy who are making decisions for the rest.

There is nothing the workers at Valve can do to change that unless they are organized to reject the false non-hierarchical model of Valve’s workplace, gain equal decision making abilities, and their independence from the store business.

The first Steam Decks are still supposedly shipping before the end of the year. Valve has never responded to any of my requests for comment. If you’re a game developer who is interested in commenting on this story please feel free to comment below or get in touch over E-Mail. My address is zjs@zacharyjackslater.com.

Categories
video games

Ethan “flibitijibibo” Lee May Retire from Programming Due to Valve’s Proton

Earlier today I spoke with Ryan C. Gordon, the internet’s #1 icculus, to get his opinions on Valve’s new seemingly anti-native Linux gaming stance. The long and the short of it is that Gordon is seeing the bright side. If the Steam Deck is successful, it will give thousands of people playing games their first desktop Linux experience and they might become the argument for native ports once that platform takes off.

True, too, is that the option to plug in a keyboard, a mouse, and a monitor, using a USB-C dock, and start using Linux. That could be many people’s first experience with Linux on the desktop. It could be good if Valve does a good job with SteamOS 3.0.

However, I remained incredibly skeptical that this is necessarily going to end up going well for Linux users. Valve has not only stated explicitly that game developers do not need native ports, but according to developer Ethan “flibitijibibo” Lee, Valve may also be reaching out to developers and asking them to use Proton instead of native ports:

Lee is perhaps the person with the second longest career bringing games to Linux and working on gaming technologies that make that easier. Lee’s FNA utilities have enabled at least 83 games to be ported away from Microsoft’s deprecated XNA SDK to the more modern FNA SDK and then onto platforms like the Nintendo Switch, Linux, modern versions of macOS and Windows, Xbox One, iOS, tvOS, and Google’s Stadia.

Here is my conversation with Lee, which occurred over email. Names and my questions are in bold. The only edits I’ve made to Lee’s responses are to italicize product names as well as to italicize whenever Lee used underscores to indicate italics.

Jack Slater: How do you feel about the Windows API Compatability Layers like WINE and Valve’s fork using Proton?

Ethan Lee: It’s an essential preservation project, one that I actually worked on for about a year! It helps get access to dead Windows games which I think is really important, just as it has been for FNA and equally-dead XNA games.

Slater: What kind of experience do you think people will have playing games on the Steam Deck using Valve’s Proton?

Lee: The same as those on Linux, honestly – I don’t suspect the experience will magically be any different than what we see on the issue tracker, which is huge and has tons of loose ends and titles yet to be investigated (big surprise, there’s only 20,000 of them and this only covers ~10% of them):
https://github.com/ValveSoftware/Proton/issues

Slater: You have said that Valve is reaching out to game developers and asking them to consider switching from native Linux ports of games to Proton’s compatibility layer, do you know or could you speculate as to why they’re doing this instead of encouraging native ports?

Lee: To be clear: The issue is primarily situations where developers have historically shipped native, and may not have shipped their next title as native yet. This is common, as much of my portfolio will show. I suspect there’s a disconnect here where only one title is examined without looking deeper into it, and so an unintentional partnership comes out of it. The one that seemed to get mixed in with this is, from what my partners have told me, is an e-mail sent to those requesting kits that, much like the developer documentation, prominently features Proton and makes no mention of why you want to care about native. This is probably a case of just not thinking about the wording and the communication, or worse, not thinking about the consequences of obscuring the information until it’s too late.

I don’t know if there is any intent to erase native games on purpose, but consider that the only reason I’m aware of these communications is specifically because of my partners, whom I make Linux games for.

Slater: Do you know if Valve is offering any incentives in return for developers who are willing to switch their games from native Linux to Proton?

Lee: I mean, do they really have to? That’s the beauty of a loss leader, just sink money into it and undercut everyone else to get what you want.

Slater: How will this change your plans for Linux game ports going forward?

Lee: I have my remaining contractual obligations, but short of a complete 180 from Valve that is very very loud I have to walk away and go do other things for a living. A course correction is unlikely, as they seem abnormally confident that developers will just magically come to me after the device’s inevitable success, which is basically asking me to just casually accept that I’m going to endure even bigger losses than I already have with an empty promise that my business will turn around based on a third party’s big risk that they think anyone can endure. It feels very like much I built my own casket having worked on Proton, and as they’re shoveling dirt onto me they’re going “don’t worry, you’ll be fine when someone else finds you!”

Slater: Will this change your FNA development plans?

Lee: I’m currently talking to the other maintainers about transfer of administration roles. I suspect things will change a little since I was super involved in day-to-day maintenance even when I stepped away from working on FNA all the time a couple years ago, but I trust that they’ll do a good job even long after I’ve stopped programming.

Slater: Even Valve’s website for the Steam Deck says “no porting necessary.” What could Valve do to repair this situation with people who handle porting games to Linux?

Lee: So in my most recent conversation with Valve I mentioned 2 things:
1. The developer docs absolutely need to include native somewhere. If your plan is to migrate to native you can’t hide this stuff forever, if you try it’s going to feel like a bait-and-switch and developers will just walk away the second you start to ask for the investment that you repeatedly insisted was not necessary to begin with.

2. If you’re going to intentionally tank businesses who work on native, the least you could do is subsidize work on stuff that native specifically cares about. I and every other specialist could name a million things that would fit this bill, just in the last week the FNA team has been talking about Wayland support, which includes drafting numerous new EGL extensions and Wayland protocols, and other things like Linux high-resolution timer precision, which we’ve discovered is actually a big pain in the ass to track vs. Windows where you can just set the timer resolution and know that your sleeps will be at a certain level of precision. These are tough problems that need people looking at them, and native cares about this stuff! Instead the money’s just getting dumped into crap like the Synchronization Primitive of the Month that basically nobody making production-quality software can ship.

Slater: Early rumored reservation numbers for the Steam Deck seem to be going well for Valve with the figures for the larger NVMe storage tiers. Do you have anything else you’d like to say to people considering a reservation or who are on the fence about keeping their reservation?

Lee: Buy it if you want, lord knows this interview’s not going to stop you, just don’t be surprised if the AAA and “indie” businesses produce the most cynical outcome imaginable if the operating system is what makes the device interesting to you. Were Valve’s attitude different I probably would have ordered one, knowing that incoming business would allow me to do so. But that business isn’t coming, so I can’t and won’t.

Slater: Is there anything else you’d like to discuss that we haven’t yet?

Lee: I guess follow https://music.flibitijibibo.com/ if it turns out I still know how to be a music producer?

Slater: John Carpenter has so many incredible movies. They Live, The Thing, Big Trouble in Little China, and Escape from New York & L.A just to name a few. Which is your favorite and do you feel like The Thing made it’s way to Washington and has taken over Valve?

Lee: It’s between The Thing and Halloween – though I guess I like Halloween mostly based on Carpenter’s attitude toward scoring and soundtracks, which up until watching and researching it I hadn’t thought of scoring the way he does.
Tell you what, if you (yes you, the reader!) read this and hated me for it, I’m actually the Thing and the real me died a long time ago. That’ll preserve my reputation, right?

Before Valve brought a native Steam client to Linux, the only games Linux users had were from a very small cottage industry coming from indies who developed for Linux and developers like Ryan Gordon and Ethan Lee. When the other writers at LinuxGames.com and I heard rumors about Steam coming to Linux, we were incredibly happy for that news and then it finally happened. Linux gaming was back, and 2014’s Steam Dev Days launch with Steam Machines and SteamOS truly seemed like a moment where Valve was championing the native port.

Then SteamOS & Steam Machines floundered, and now here we are again with the Steam Deck except this time Valve has changed the focus to their Proton Windows compatibility layer. Although we had hints in 2018 never would I have expected Valve to potentially end native Linux gaming along with the careers of prolific developers like Ethan “flibitijibibo” Lee.

I am very disappointed to learn that the long and incredibly successful career of a fantastic developer who has been responsible for so many games coming to Linux and other platforms may be over due to Valve’s takeover of this corner of game and platform development suddenly discarding native games for Linux with the launch of the Steam Deck. I wish Lee well whichever way this turns out, but I suspect that once Valve has made up their mind about the path for Linux development this is just how it will be.

Valve’s profit motive may have both been the reason for the resurgence and, depending on your perspective, now the death of native Linux gaming.

I have reached out to Valve for comment and will update this post if I hear back from them. If other news surfaces regarding native games on Linux, it will get posted here.

If you’re a developer who wants to speak about the issue of native ports on Linux, or a Valve employee who wants to speak on or off the record, please get in touch.

Categories
linux video games

Windows Pretendulation Is Bad Even When Valve Does It

Valve’s Pierre-Loup A. Griffais announced that they’re including their brand new fork of the WINE Windows pretendulator in a new beta product for Steam. They call it Proton. WINE is an open-source Windows API emulation layer that lets Linux users play Windows games without rebooting into Windows. I call this process “pretendulation” because it isn’t emulating the entire operating system, but it is still far from native.

That sounds good, more games for Linux, right?

Well, when I started writing about Linux gaming 18 years ago there was a commercial, closed-source, fork of WINE called WineX. WineX had a lot of fans, it was developed by people who had been working on Wine, which was a more generalized product for Windows software, to target game software. These developers of WineX (later called Cedega) did a good job at writing the software, but it had a number of issues.

One of those WineX issues was that Windows compatibility is a moving target. Any progress the WineX developers made to support new versions of Microsoft’s DirectX game software programming interface were usually still years behind where modern games were. If the latest Battlefield game came out and it only worked with DirectX 8 and WineX was still on 6 or 7, it was going to be a while until they could support that new game.

Even though new DirectX versions are less of a headlining feature in Windows these days, compatibility with a wide range of games is going to be a problem for Valve’s Proton as well. 

Any emulation, or translation, layer, is also going to introduce some amount of performance overhead. You can’t emulate a PlayStation 3 or Dreamcast at full speed on a lot of expensive computers today, but you can buy the original console for $50 that plays those games perfectly. The same issue happens with emulating Windows APIs under Linux. Some games will only have a very small hit to performance, but others might be more of a problem and you won’t get the same framerate that you do under Windows.

So there are compatibility and performance issues, that’s it, right? Nope, there’s one more technical hurdle. When something breaks, you’re not going to know if it’s the game or the emulation layer. I imagine this will infuriate some developers.

Valve claims that games they’ve tested and whitelisted in this beta have an almost identical gameplay experience to Windows, and they acknowledge the performance overhead. Valve doesn’t acknowledge the negative effect this will have on real native ports of games. Back in those WineX days there were some developers and publishers who cancelled their plans for native Linux ports because Windows pretendulation was “good enough” for them, even when Wine or WineX didn’t provide a great experience for players.

“Good enough” Windows API emulation eventually turned into developers porting their games with Wine wrapped up into a library, giving Linux players some of the half-assed ports they have today.

One additional issue that wasn’t a problem with WineX, these improvements to Wine are only designed to work with games on Steam. You won’t be playing Battlefield  5 with Proton. Although Valve’s fork of Wine is open-source, unlike the old WineX fork which had its source closed behind an agreement that the executives at Transgaming later deleted and refused to acknowledge.

Proton is an interesting technology, but a bad thing for anyone who loves Linux gaming and wants native ports of games brought to Linux.