That’s not due to new hardware, battery life is a conscious decision from design/marketing teams. Newer hardware, if it’s worth anything at all, can accomplish more operations at the same TDP as the previous generation. Or more accurately, new hw should always have better performance per watt than older hw (*generally. Of course there are always hardware architecture differences that can dramatically affect performance of very specific scenarios for better and worse, but I’m talking about on-average).
But that doesn’t stop hw manufacturers from bumping up the TDP recommendations to sell their latest chips (why new nvidia GPUs always suck another 100W of power each gen), and it doesn’t stop OEMs from using a higher TDP limit to sell the performance of their handheld (why newer handhelds seem to have worse battery life).
The team that designs a new handheld could use the newer compute hw with the same battery capacity and:
- the same TDP limit, resulting in a marginal increase to performance at the same battery life
- a lower TDP limit, resulting in the same performance in higher battery life
but they often determine neither of those will sell units as well as using a slightly higher TDP limit for higher performance review numbers at the cost of battery life.
This is why I like that SteamOS has a deliberately configurable TDP limit in the flyout menu, per-title! This gives the player manual control over what they consider important rather than leaving it up to a marketing team or some buggy power limit heuristics. Just one more reason why I’m excited to see wider adoption of SteamOS.
Anti-cheat is an arms race. We just find ourselves at a point where the arms race has progressed to the point where the best known strategy for securing a play session means ostracising custom hw/kernel configurations.
But I have to think it’s only a matter of time before even that’s not enough, (since there already exist ways around kernel level anticheat, including AI-based techniques that are entirely undetectable).
My guess is the logical conclusion involves a universal reputation based system, where you have an account with some 3rd party system (maybe VAC) that persists across all games you play. It will watch your gameplay, and maintain a (probably hidden) “risk of cheating” score. Then matchmaking for each game will use this score to always pair you against other accounts with a similar score.
Actually, it might not be a “risk of cheating” score so much as a “fun to play with” score. From a gameplay perspective, it’s just as fun to play against a highly skilled non-cheating human, as it is a bot that plays identically. But it’s less fun to play against a bot that uses info or exploits that even the best non-cheating players don’t have access to (ex. wallhacks). So really, the system could basically maintain some playstyle-profile for each player, and matchmaking wouldn’t be skill-based, but rather it would attempt to maximize the “fun” of the match-up. If a player is constantly killing people unrealistically fast, or people who play with them tend to drop early, this would degrade their “fun” score and they would tend to be matched only with other unfun players.
I think this would be the only practical way to fight cheating without even more invasive methods that will involve just deanonymizing players (which I think some studio will inevitably try in the near future).
Yeah, idk why everyone seems to legitimately think devs are going to just quietly revert back to usermode anticheat. I could see Riot patching an actual root kit before that happens.
But yeah, more likely MSFT will lobby for hw that is more annoying than secure boot or TPM to get working with linux, every windows app after that point will rely on it “because turnkey security!”, and if you ever manage to disable it none of those apps will work on your machine in any OS (if they even worked through proton at all).
It’s still giving third party software kernel level control over your device, so you’re still giving up any possibility of privacy and probably leaving yourself wide open to a backdoor attack, but that has been normalized. So to the degree that what people accept as reasonable these days is unreasonable, yeah, that’s why I think MSFT will try it.
In b4 msft creates a level between kernel and user level for this stuff to sit at. It will have read-only access to all of kernel memory, and will otherwise function the same, but when it crashes it won’t take the OS down, just certain programs that rely on it.
What will they call it? “Observer” level? “Big Brother” level? “Overseer” level? Probably just something to do with “Verifying Trust/Integrity”. Google will also want to quietly stick something for “Web Integrity” there.
Looks like GoL has a plot over time. Linux adoption is starting to hockey stick, definitely above linear growth, this is getting exciting! I would guess, if it hits somewhere around 5-10% and keeps this hockey stick shape, we’ll really start to see the game industry justify giving it more attention.
This will come with both good and bad, I expect it’s only a matter of time before some game tries a native kernel level anti-cheat, aka root kit, on Linux.
Not wanting to run steam is fair, but they asked about proton, not steam.
Anyway, from a quick Google, it sounds like it likely wasn’t proton complaining about a lack of SM6.6 support, but actually GoT itself. It’s up to the translation layer (in the case of proton, DXVK I believe) to report what DX features it supports, and it sounds like it was telling the game it didn’t support SM6.6 for whatever reason. Might just be a matter of playing with some of the launch params.
If I’m going to game stationary, something with more than 10W of horsepower would be nice.
I agree that the steam machine was too early. People hadn’t been fully disillusioned by the planned obsolescence of their console libraries yet. Today, in a world of $600+ consoles that are impossible to find within 2 years of their release, hardly any worthwhile exclusives, and Nintendo trying to make you repurchase the old games at full price again, a steam console could potentially sweep the industry.
If running on an obscure platform avoids cheaters, that’s still security by obscurity. I assume it’s only a matter of time before the number of cheaters using that client grows to the point where they either have to invest in anti-cheat there, or cut support for the platform.
MacOS is not an open platform, so as long as apple support their efforts, they will be able to have kernel mode anti-cheat there when they want it.
Their post is a bunch of PR hidden by funnyspeak
I disagree, I think they said pretty plainly that they rely on security by obscurity, which is fundamentally at odds with an open platform that gives you control over your hardware. They’re not wrong, they can take their shitty anti-cheat arms race and shove it.
Why are you asking some rando in a gaming forum? You don’t need to be a security expert to know that you don’t want any random app having kernel level access to your devices just to play a game. It doesn’t take a security expert to know that. The purpose of pointing it out isn’t that we know what the best solution is, it’s to tell studios that this solution isn’t the holy grail they act like it is.
It sure doesn’t. I had a bunch of beautiful screenshots I took using The Invincible’s photo mode. It saved them all to the emulated AppData folder in compatdata. When I was done with the game I uninstalled and went to grab the pics, only to learn I picked the wrong order to do that in :(. This was as of 2 months ago.
Yep, as much as I benefit from valve’s push on Linux, I know it’s not out of the kindness of their hearts, it’s out of self preservation.
I would gladly use epic’s store if it gave devs more of the profits, but it’s just incredibly immature. Basic options are missing, and it doesn’t support Linux. I can try to work around their shortcomings as much as possible using bottles and proton, but eventually I can’t play their games due to their invasive anti-cheat. On top of that, they seem to be building a walled garden of micro transactions that’s just a worse version of NFTs. They really don’t want me as a customer, and I’m not going to argue.
This is what Nintendo wants people to think. They want you to think hacking your own hardware is synonymous with copyright infringement. And it’s categorically not. Just like collecting knives isn’t synonymous with committing murder.
I agree that Yuzu was toeing a fine line when they should have instead steered far clear of it and only supported playback of homebrew apps without encryption, but that’s not to say they did anything ethically wrong. Backing up your own files shouldn’t be a right we lose just because of criminals walking around “wink wink, nudge nudging” each other. Punish the murderers, not the knife sellers.
No, I mean charging money for pirated copies of games
Bowser helped create and support online libraries of pirated videogames for its customers, and several of the enterprise’s devices came preloaded with pirated videogames.
This behavior was never condoned by the Yuzu developers
Piracy was never our intention, and we believe that piracy of video games and on video game consoles should end.
Sucks that laws like the DMCA make it illegal to bypass encryption for the sake of emulation or other fair use
IANAL, but there are a bunch of carve outs for these purposes.
It’s unclear how this would have actually shaken out, but probably just because Nintendo is Nintendo, it would have gone in their favor. And yuzu didn’t want to be the one to set bad precedent for any future endeavors.
I agree that there should be better control in steam over what games are prioritized for both updates and shader caching.
But I was under the impression that most shader precaching was done by compiling locally in the background (via fossilize), not downloading. I agree that a 10GB download for AHIT is sus, but I don’t see anywhere on the screen that denotes it is downloading shaders.
Nonetheless, the shader pipeline problems of these new APIs (both pipeline explosion and caching) are not solved yet. IMO caching is not solved because GPU vendors don’t allow their new drivers to work with “old” shader pipelines. They have no incentive to (it would require extra driver work, and you couldn’t force users to use your latest compiler optimizations), and gamers don’t know to ask for it.
Someone else already explained the licenses, but to your second point, yes, nothing stops any other launcher from using proton, which is what all the other open source launchers do. And yes, no one “needs” this project, just like we don’t “need” any standards for anything, but it could make things a lot cleaner and easier to support.
Good luck 🤞