[–] 9 points 8 months ago

Transferability is a right we believe should not be taken away, and we refuse to do that

Valve takes a cut of every 'transfer' between users involving money, and they don't allow transferability of games, the main thing people would want to transfer. If you're going to pretend like you're trying to help consumers by giving them control over their digital content, don't just do it for the type of content that makes you money.

With that said, I'm definitely on Valve's side with this. Age verification and anti-VPN spyware is all bullshit. Too bad I'm not a NY resident.

  • source
  • [–] 1 point 8 months ago (1 child)

    Nah, fuck them. They were no different from Google and Apple, and had monopolistic tendencies as well. If anything, Google is the lesser evil since Android is at least open source, whereas BB10 was as locked down as iOS.

    Blackberry also killed/sold off their hardware teams, so they have no capacity to make a comeback. All they have left is their nostalgia-loaded brand.

  • source
  • parent
  • context
  • [–] 6 points 8 months ago (2 children)

    Why, because you can't afford it (reasonable), because you think it helps Google (unreasonable), because you think it's a privacy risk (unreasonable), or because it feels icky (unreasonable)?

    The profits from Pixel hardware sales are a drop in the bucket for Google. I'm pretty sure the only reason it exists is so they can have insight and control over the hardware ecosystem, as without it they'd be driven by whatever Samsung wants to do.

    The walled Android ecosystem is where they make the bulk of their money, and Graphene actively pulls people away from that and to something objectively better. Graphene is fully de-Googled and safe from their spyware, and exists outside of their business model. Using and promoting Graphene actively hurts Google, even if you have them $1k for a phone.

    Also, there are plenty of cheap second hand pixels on ebay, and Google doesn't see a penny from those sales. Recycling is good for the planet anyways.

  • source
  • parent
  • context
  • [–] 7 points 8 months ago (1 child)

    but I mostly work with infrastructure and optimizing build systems.

    Besides source code, games also need to compile source assets. An example of this is textures; a dev might store them as PNGs in their source control, but the texture will need to be converted to a different format depending on the target hardware. On mobile, that might be something simple like PVRTC, or maybe supercompressed KTX. Geometry and animations also need to be compiled, usually from something like FBX to whatever runtime formats the engine uses, not to mention all the other copious amounts of custom data needed for the game.

    Shaders are a challenge because you can't fully compile them ahead of time. They're usually authored in some DSL (maybe HLSL/GLSL, but sometimes also an engine-specific custom language), and depending on the target graphics API they can be compiled to intermediate bytecode (eg SPIRV). However, that bytecode needs to be compiled by the user into the internal format needed by the graphics implementation (which can even change between driver versions on the same machine), which is why modern PC games need to compile shaders on first launch. Consoles with fixed hardware can avoid this problem.

    Beyond that, the shader permutation issue leads to games requiring a shitload of shaders for performance reasons, exacerbating the issues described above, both for the developer performing a release build, and for the user launching the game. This article describes the issue well.

    So add all that on top of the usual time it takes to (cross-) compile the engine and game code, which is often a massive C++ codebase of dubious quality, and sometimes also an outdated proprietary toolchain of dubious quality.

  • source
  • view more: ‹ prev next ›