281–290 of 462 posts
> Larian does not provide support for the Linux platform. This is a huge nitpick but I wish they'd just say "other Linux distros" instead of the "Linux platform". It's fine to pick and choose one (or a few) popular distro(s) to support, like SteamOS. It's not reasonable to expect support for all possible Linux software environments. It's already crazy that they support so many hardware combinations, even on just Wind…
Earlier quoted context omitted.
Not that I'm aware of. I thought that was weird at first as well, but I assume it might be in a way to protect the engineer. Unfortunately, singling out any individual developer, even for praise, can attract unwanted negative attention online. By acknowledging the passion and the work without naming the person, Swen gives them full credit internally while shielding them from becoming a public target. This doesn't eve…
This is an interesting perspective... I'd be at a loss to think of an example of an engineer who's been publicly pilloried (having been highly regarded for great work) for the failings of their company. Perhaps you could cite and example? Seems enormously more likely to be the all to familiar story in the games industry of not providing credit to individual devs. Something that goes back to the earliest days of Atari…
I can't think of specific names anymore since it's been a while since I have played it, but a lot of the developers for World of Warcraft used to be and likely still are active on Twitter. For a lot of them, the community knew fairly well which features of the game or which class they were responsible for. When I used to look at the replies to some of their Tweets (even ones completely unrelated to WoW), they were often full of complaints about their area of perceived responsibility.
I fully understand every engineer who just wants to put their head down and work on their stuff they're passionate about without having to also be public-facing. Even in a small company like mine, some of our devs constantly complain that some customers know that they are responsible for certain features of our product and email them directly rather than going through the proper support channels.
Your point about the games industry often struggling with providing proper credit to devs is well taken - it's absolutely an issue. But in this case, Vincke did actually do that, in a way. He could've just kept quiet and let the playerbase think it was a company effort, but instead he publicly highlighted and recognized the passion and work of one of their engineers (even though anonymously). That engineer can look at the countless positive replies to that post and get the nice fuzzy feeling without getting dragged into the spotlight.
> Larian does not provide support for the Linux platform. The Steam Deck Native build is only supported on Steam Deck. I though the steam deck would be the reason why developper start building their game for linux, but it seems like it's a bigger issue than just making a "linux file". Once they have rewritten the code for the steam deck, what would prevent them to compile the game for Debian and other linux distribut…
I would assume the issue is all the variation in different distros. Plus the driver/hardware combinations. While some setups would just work they don’t see it as worth spending the time doing the validation/patching required. The steam deck is 1 device to test, with a single software stack. Much easier to target, and with a known customer base. Which brings up the other issue that they would be unlikely to make their…
On the other hand, that stack can only contain so much, and a lot of Linux bugs involve sound subsystems, GPUs, and compositors/X11/window manager configuration issues. You can't quite target the Linux runtime and assume everything will just work, but at least you don't need to target specific versions of glibc and libxml2 anymore.
Earlier quoted context omitted.
Yes but that limits you to command line applications. GL and X11 (and I assume Wayland) are always linked dynamically. Granted, those don't suffer from glibc's "DLL version hell", but not sure what happens when you link the main executable statically against musl and then load DLLs which dynamically link glibc. Another option is to dynamically link against an old glibc version, the Zig toolchain makes that easy also…
glibc doesn't suffer from DLL version hell as long as you are not doing anything stupid (like using private symbols). If you commit to using just the "C library" bits you can compile a binary linked against glibc on a distro from 1998 and it will work on modern distros just fine. There are many issues with libraries breaking backwards compatibility on Linux (like pretty much all GUI ones) but glibc, X11, OpenGL (and…
There's probably an obscure linker trick to force an older glibc version number, but if that's the case it really should be the default since the C stdlib is supposed to be ABI backward compatible anyway.
Earlier quoted context omitted.
I played it on Steam Deck when it first came out (docked, standard HD display). It was perfectly acceptable, as long as you're fine with semi-stable 30 FPS and cranking down the graphics a tad. The only real problem that I encountered was that the game wouldn't recognize or remember my input settings, and would always default to controller-only, so I would have to attach a controller to navigate to the menu to switch…
It played tolerably until act 3, same with my M1 MacBook Pro. Act 3 was awful on both.
Earlier quoted context omitted.
It's not like we have seen anything in gaming that wouldn't be possible on PS3/Xbox360 era hardware, certainly not in terms of complexity. Just remember that stuff like red dead redemption ran on those things with all of 512 MB of unified memory. It ran and looked better than borderlands 4 does on current consoles.
I think you're looking back with rose-tinted glasses. The 360/PS3 was a huge jump forward but very limited by today’s standards. RDR was one of the better looking games of the generation but could not maintain a steady 30fps at 1080p/i (and I’m not sure it was even true 1080). The PC version came later, had higher resolution textures and other graphical improvements so it compares more favourably to modern games when…
The performance problems in modern games are often not caused by fillrate-vs-resolution bottlenecks though, but by poor engine architecture decisions (triggering shader recompilations in the hot path).
Earlier quoted context omitted.
Or in the case of Borderlands 4 and a plethora of other Unreal Engine 5 titles: they’re optimized for nothing and there aren’t even options to turn off most of the expensive graphical effects, despite the engine being able to scale down to mobile devices.
Yeah, UE5 games don't even run well on 5090s these days -_-
This is absolutely unacceptable and if this happens with nearly every big release, then that also speaks badly of the engine itself. Similarly to how languages like C++ are very powerful and can be used to great effect... and people almost inevitably still write code that has memory safety issues. That comparison should make a few ears perk up, my point is that fewer developers should use Unreal Engine 5 if they can't use it well (same as with the languages).
Frankly, I place more trust in studios that have their own engines or use literally anything other than UE5, like what happened to KDC:2, a modern game that looks good and runs great across a wide variety of hardware. Or how they fixed Cyberpunk 2077, it took a while to get there but now both the visuals and performance are quite good across the board.
If there was ever a game to play with KB+M, this is it. I don't get the need to stuff everything into a handheld. It's not Mario kart!
I just don't want to play anything with a kb and mouse anymore because it just feels like being at work when I'm sitting at a desk using the same setup I just spent all day on.
1000x this.
When I grab the deck it's downtime mode for me now, keyboard/mouse time is work or side-project mode.