Algorithmic patents amount to patenting maths which, by very longstanding precedence, is not a thing, for good reason. Same goes for business methods and other stuff.

In the EU there’s only one way to patent software and that’s if you’re using it to achieve direct physical ends. E.g. you can patent washing machine firmware in so far as you patent a particular way to combine sensor data to achieve a particular washing result. Rule of thumb: If, 30 years ago, you’d have an electromechanical mechanism to do the task then you can patent the software that’s now replacing it.

Oh: It’s also possible to patent silicon, that is, you can patent your hardware acceleration methods for video decoding. That doesn’t extend to decoders running on general-purpose hardware, though.

If you want to monopolise your brand-new hash algorithm there’s a simple way: Don’t publish the source, use copyright to collect royalties… though that doesn’t mean that reverse engineering is outlawed, especially if necessary for interoperability. Practically speaking nope hash algorithms just can’t be protected which is fair and square because it’s academia who comes up with that kind of stuff and we paid for it with taxpayer money. Want to make money off it? Get tenure.

Very relatedly: If you’re a EU citizen make sure to sign this initiative.

If not a EU citizen do not sign it, that’d be the opposite of helping, but do enjoy numbers go up from afar. Also you can spread the word that’s fair game.

2+3: Try to fetch image, if you get it proxy it, if your storage gets full use LRU eviction, once evicted or some amount of time has passed delete it and don’t fetch again, ever. Fall back to pure 3 if there’s ever any issues with anything, including you not particularly feeling like implementing smart caching: Our referrer privacy is not your responsibility.

You can’t automate generation of shape keys. An artist needs to go over every single asset and make it work for every single extreme point on every slider, then make sure that the automatically derived in between points look good and fix those if required, in all slider combinations.

And it’s probably still going to clip during some animations because going over absolutely everything is just prohibitively expensive.

Why is the term “Body Type A” and “Body Type B” present at all when there are clear pictures of the two options that speak for themselves? It feels like just going out of the way to include “the corporate approved buzzwords intended for maximum synergy with the brand!”

“Type A” and “Type B”, I assure you, are not things corporate or marketing came up with. This is programmer speak for “I don’t want to name it but can’t call it foo and bar either because normies will be seeing it”.

As said: This is a re-release. The game and its assets was originally never designed to support anything but a strict binary, but the pronoun vs. body type thing was trivial to do, so they did it. And then for some reason avoided “male” and “female” because face it that sounds like a good idea especially if you’re not overthinking it and the labels were left in because probably also easier to do. Or just didn’t consider the alternative.

That is: You’re assuming intent when there’s simply economy of action. You might call it laziness, but then the people who did that release had 10000 other things to do besides that.

Putting in half a dozen body types and a boob slider shouldn’t be a ton of work

Body types no but you also need armour and clothing for everything. You quickly get a combinatorial explosion which you can then reign in with shape keys (“sliders”) which make all assets harder to develop.

That’s morph targets and you just increased the budget for the character model and every single set of clothing and armour by a whole magnitude. Might even influence animations, though I guess with Elden Ring being the game that it is those are the same for everyone.

Games that do this aren’t being progressive or inclusive, they’re changing the color of the cup that my drink comes in and pretending it’s an entirely new beverage.

The thing is… if you use “dude” and “chick” in the body type descriptions you’re implying gender identity. There may be better options that “Type A” and “Type B” but dude and chick ain’t it because it simply means male and female.

In a very flexible system, you could use more granular options like “wide shoulders”, “wide hips”, “boobage”, etc, to freely mix+match everything. It’s also expensive to develop and even more expensive to create clothing for and a gazillion times more expensive to make really good-looking clothing for (fabric folds and flow aren’t easy). From a developer’s perspective, looking at the work involved really makes you want to say “We’ll just tell the player they’re now Geralt of Rivia and that’s it”.

I think for most games the appropriate choice would be to have an early radio button, saying “male/female/it’s complicated”, the first two options hiding every enby option including pronoun selection. That’s right-out trivial to do and just good UX. And yes the body types should be called male and female, you already selected “it’s complicated” so it’s clear that when you’re selecting a body, you’re selecting a body, not identity.

As to laziness: Eh. Noone’s going to start a research programme on how to do things in an optimal way for a re-release. Someone had a look at the code and assets and thought “hey we can support separate pronouns and bodies without doing anything more than providing an option” and that’s exactly what they did, using the extent of knowledge and consideration that was already in-house. Yep, it very well can happen that if you take your foot out of one thing, you put it right into another.

As to “primary/secondary”: One of the options has to be to the left, or on top, of the other. Ain’t no way around that. I mean you could put option B on the left of option A to cancel things out but now you’re being confusing. More importantly you can make it so that none is selected by default.

Am I onto something or is this all crazy talk?

Yes and no you’re being quite personal, and I include your perspective shift into the POV of others in that, about things that will never make 100% of the people 100% happy because technical reasons. The perfect is the enemy of the good and all.

I’m not sure if you could call Talos Principle indie. Croteam is an ancient company (of Serious Sam fame), they sold out to their publisher some years ago (Developer Digital). Wikipedia says 42 people, that’s about the same ballpark as Wube (Factorio), way smaller than Coffee Stain (123), which yes vibes heavily indie (Goat Simulator!) but is part of Embracer Group.

If you look at Developer Digital and Embracer group they’re not really that small – certainly not smaller than CDProject Red, which is very much throwing AAA money at their projects and definitely had their own big business culture fuckups. They’re simply more distributed, instead of orchestrating one or two big projects they have multiple studios working largely independently on small to mid-sized projects. Talos and Satisfactory are AA scale.

Is Wube indie? Well, at least at the start they were, growing with Factorio’s early access. Still independent, as far as I know. Budget-wise they’re certainly not operating on a shoestring, though… you also have to take into account that they’re taking their sweet time for everything. Also AA.

A would be stuff like Celeste. That’s a broad category, I wouldn’t really call anything B unless you don’t have separate coder, writer, sfx/msx and gfx. Maybe toss the writer but anything under that and you’re smaller than minimum demo group size.

All this is to say: Can we please stop dividing the industry into “AAA” and “Indie”. CD Project Red is independent. They’re doing AAA. One is budget, the other is whether the studio has a corporate overlord lording over multiple studios. Game quality is a third measure. System requirements yet another: Factorio has no issues melting your CPU even though it’s highly optimised, then you have B-budget projects which melt your box because the dev has never heard of polycount and a background prop toothbrush has 400 quads… per bristle.

Satisfactory did it earlier.

Should all be in place. Even nvidia driver support. It’s one of the rare cases where I actually support nvidia on a technical level, that is, having explicit sync is good. I can also understand that they didn’t feel like implementing proper implicit sync (hence all the tearing etc) when it’s a technically inferior solution.

OTOH, they shouldn’t have bloody waited until now to get this through. Had they not ignored wayland for a literal decade this all could’ve been resolved before it became an issue for end-users.

Programs can’t set position or size of windows, period, at most they can ask and then hope they don’t get ignored and it’s good that way. Window management is responsibility of the compositor, not of applications.

At least KDE has support for it that’s about on X11 level, a proper-proper solution is still in the pipeline. And yes you’re seeing right it’s been there for four years.

And nobody wants to rewrite Xorg or understand the code (other than very basic security maintenance).

That’s precisely the point: All the devs got tired of it and started wayland instead.

X12 might happen at some point when wayland is mature, as in a “let’s create and bless a network-transparent protocol so we might have a chance of getting rid of XWayland in 50 years” kind of move.

Yep that’d be Wayland devs maintaining XWayland, which is part of the x.org codebase. There are no “X11 devs”, they’re the ones who started Wayland to get rid of that bowl of spaghetti!

I argue that X11 would have hyperactive development, if we did not have Wayland

Wayland was started by the X developers because they were sick and tired of hysterical raisins. Noone else volunteered to take over X, either, wayland devs are thus still stuck with maintaining XWayland themselves. I’m sure that at least a portion of the people shouting “but X just needs some work” at least had a look at the codebase, but then noped out of it – and subsequently stopped whining about the switch to Wayland.

What’s been a bit disappointing is DEs getting on the wayland train so late. A lot of the kinks could have been worked out way earlier if they had given their 2ct of feedback right from the start, instead of waiting 10 years to even start thinking about migrating.

Making screenshots does, too, which is why that functionality gets implemented at the compositor level. And so will screenreaders. In fact looking at my settings panel KDE does have support for Orca. Dunno how well it’s working but it’s not like the issue is being ignored.

That does not seem to be a stray and yes there’s definitely reasons to take potshots at Gnome. They still don’t support server-side decorations. Everyone is absolutely fine with them not wanting to use them in their own apps, have them draw window decorations themselves, and every other DE lets gnome apps do exactly that, but Gnome is steadfastly and pointlessly refusing to draw decorations for apps which don’t want to draw their own decorations. It’d be like a hundred straight-forward lines of code for them.

And that’s just the tip of the iceberg when it comes to breakage you have to expect when running Gnome.

Wayland kinda is an x.org project in the first place. AFAIK it’s officially organised under freedesktop but the core devs are x.org people.

x.org as in the organisation and/or domain might not be needed any more, but the codebase is still maintained by exactly those Wayland devs for the sake of XWayland. Support for X11 clients isn’t going to go away any time soon. XWayland is also capable of running in rootfull mode and use X window managers, if there’s enough interest to continue the X.org distribution I would expect them to completely rip out the driver stack at some point and switch it over to an off the shelf minimum wayland compositor + XWayland. There’s people who are willing to maintain XWayland for compatibility’s sake, but all that old driver cruft, no way.

Also, you need a supported card. I have a potato going by the name RX 5500, not on the supported list. I have the choice between three rocm versions:

1. An age-old prebuilt, generally works, occasionally crashes the graphics driver, unrecoverably so… Linux tries to re-initialise everything but that fails, it needs a proper reset. I do need to tell it to pretend I have a different card.
2. A custom-built one, which I fished out of a docker image I found on the net because I can’t be arsed to build that behemoth. It’s dog-slow, due to using all generic code and no specialised kernels.
3. A newer prebuilt, any. Works fine for some, or should I say, very few workloads (mostly just BLAS stuff), otherwise it simply hangs. Presumably because they updated the kernels and now they’re using instructions that my card doesn’t have.

#1 is what I’m actually using. I can deal with a random crash every other day to every other week or so.

It really would not take much work for them to have a fourth version: One that’s not “supported-supported” but “we’re making sure this things runs”: Current rocm code, use kernels you write for other cards if they happen to work, generic code otherwise.

Seriously, rocm is making me consider Intel cards. Price/performance is decent, plenty of VRAM (at least for its class), and apparently their API support is actually great. I don’t need cuda or rocm after all what I need is pytorch.

Because allow/blocklist are just as old if not even older and are way clearer terminology.

“white” and “black” there are metaphors, the “master” in git branches and SCSI isn’t.

See at some point you have to ask yourself the question whether you’d be opposed to the change if blue-haired college students really into performative politics weren’t a thing. Imagine the idea coming from your slightly computer-illiterate 60yold shop floor boss saying “I don’t want to think about the terms here, I want to do CAD/CAM. Speak English, whippersnapper”.