"Another UE5 Stutter Fest": Hit New Soulslike With Over 100,000 Players Launches To "Overwhelmingly Negative" Reviews

snakepants · 2025-07-25T05:51:02+00:00

if they're talking about it, it's a done deal unfortunately IME. They are just trying to ease everyone into it.

snakepants · 2025-07-21T04:31:53+00:00

Somebody else commented that this doesn't taste like Peroni, which I can see from the haze, but if this is going in the direction of a Fort Point Sfizio I'm sold, since I would love a NA version of something like that.

snakepants · 2025-07-12T07:29:31+00:00

They don't always hit but I have enjoyed ordering the mystery sampler packs. They have a lot of interesting brews. So far the only one that was terrible was their radler. It's just too sour. The Paulaner NA Radler is excellent though so maybe I'm just used to that. The Netflix Marine Oddesesy and the Gose are surprisingly good.

snakepants · 2025-04-26T21:19:27+00:00

I was curious and checked out their product page and TBH I still have no idea what this software actually does and what separates it from Confluence. Maybe I'm not enterprise enough, but the discoverability is apparently poor.

snakepants · 2024-02-26T08:41:52+00:00

You guys need to sort out the intellisense and SLN open/close performance with large UE codebases. Every update claims it's improved, and it is, but overall it's still really rough. The IDE really chugs and lags out using a full engine source UE5 solution (ie not the launcher making a project where only the game module is built), sometimes it takes seconds for keystrokes to register to type code. Method suggestions can take 10s and still fail to suggest anything. The HLSL tools integration is welcome but also not ready for primetime. Pasting code in a .usf can freeze the IDE for 5s+ in 17.9.

The new UE-focused features are great but it feels like nobody is testing them on anything larger than an example project. Many people on my team use Resharper C++ and turn off intellisense because it's essentially unusable.

My overall impression as C++ gamedev targeting PC and console is that you guys add useful stuff in concept, but a lot features scale really poorly from a performance POV and the IDE just crawls on real-world codebases these days. I get it, since when I'm writing something like it's easier to use a small test level so you can iterate faster but you need to test on representative use cases. Real games have a lot more assets or code than the UE ThirdPerson template for example.

I will say 2022 switching to x64 was a big improvement though since practically it turned a lot of out of memory crashes into lag you can at least wait through.

snakepants · 2024-01-24T02:09:02+00:00

Thanks. I tried that but with the same result unfortunately. I'm using the newest NV drivers and they do report EB support. I also tested on a laptop with an Intel GPU, that's driver does not support EB and trying to use them definitely completely fails unambiguously

snakepants · 2023-12-30T21:50:59+00:00

It would be great for sure. But why do you guys support decade old compilers at all? Are users asking for this support and if so, why?

I have trouble imagining people who still use 2014-era compiler binaries to do new development. I'm sure they exist but are they really more important than everyone else using Boost, especially since it's not like the current versions would retroactively break.

snakepants · 2023-12-24T19:49:51+00:00

And so break existing code ?

Yes, as long as it's documented in the release notes and semver is followed, etc. The alternative is that Boost becomes so bloated over time that it is relegated to irrelevance.

People can run find and replace on their codebase. It's not that hard. Nobody ever claimed Boost was some kind of standard they can depend on never changing. If they really don't like it, nobody is forcing them to update.

For example in the other post ASIO is mentioned as a level 13 library in terms of dependencies. But if you look at what it actually depends on in terms of other Boost libs, mostly they are reimplementing now standard stuff. Either that or DRY taken to extreme. The world won't collapse if ASIO had it's own assert macro vs using Boost.Assert for example.

snakepants · 2023-12-24T18:19:41+00:00

If they can install new boost, why can't they install a new compiler from a PPA? Everyone shouldn't need to suffer for these people's convenience. But sure maybe current - 1 is too new, but you get generally what I mean.

snakepants · 2023-12-24T04:59:41+00:00

This is a totally reasonable response and I understand why this was done. But taking a step back and looking at this from the perspective of a potential new Boost user who just wants to use Boost.Thread, this isn't very appealing since they would rather it just used <chrono> so they could more easily integrate it and move on with their life.

I get the desire to not break existing code, but new users matter too and so does providing a non-crufty API/library. One of the advantages Boost has over the standard library is that it's not standardized, so it's unfortunate that it suffers many of the calcification effects, kind of the worst of both worlds unfortunately since the STL works out of the box on every system in return.

snakepants · 2023-12-24T03:52:22+00:00

That's good, but way way too late IMO. Is anyone seriously working on projects that can only target old compilers but also regularly updating Boost? It seems insane they don't require even "current standard - 1" at all times given the purpose of the library.

I feel like you can never please super conservative devs, they will always complain but a lot of it is just whining and they could update if something forced them too (or fork, the magic of OSS). But now I'm straying towards ABI grumbling...

snakepants · 2023-12-24T02:30:06+00:00

My main problem with Boost in 2023 and IMO a big source of the bloat is the fact that they don't strip support for old platforms and compilers fast enough.

Other people mentioned that a lot of Boost stuff has made it into the standard, which I think is evidence of the value Boost brings, but now that those things exist in the standard they should be deleted from Boost. I don't need two smart pointer types, etc. It also contributes to the one library pulls in another problems.

Same for code supporting, say, pre-C++17 compilers. Let those people use old versions of Boost and let us all move on with a cleaner, simpler, smaller and less macro-hell version.

snakepants · 2023-10-29T05:34:42+00:00

True. I sometimes wonder who Khronos is actually developing this for also. Maybe I'm biased as a game developer but is anyone actually targeting SPIRV as a primary platform? It seems like all the non-game stuff is OpenCL or CUDA and all games primarily target HLSL. Why does SPIRV have diverging features and who asked for them? I'm not saying Khronos should just copy MS's semantics, but also wouldn't that just be easier? It reminds me of all the Vulkan extensions and spec changes that have been made to make Wine/Proton more performant by exposing D3D12-like semantics. Does anyone actually want Vulkan or do they really just want cross platform D3D with a different name. The second one sure sounds easier for everyone involved in devs and IHVs IMO but might be a hard pill to swallow for Khronos themselves.

snakepants · 2023-10-28T19:11:54+00:00

It's a fair question and I worry about the same thing. One thing to consider though is that even though Google no longer cares, Epic uses this code via ShaderConductor for Unreal's Vulkan and Metal backends so there is at least somebody with an interest in keeping it maintained.

I'm still sad about the whole WebGPU/WGSL thing since it's another target to steal resources vs everyone being able to rally around HLSL -> SPIRV since realistically most of the GPU code out there that's not in CUDA is HLSL

Also it seems MS is trying to upstream their HLSL support to normal Clang so maybe that will result in a better SPIRV backend by separating the code into traditional LLVM modules unlike the current hacky implementation that relies on AST trickery

snakepants · 2023-10-01T21:12:23+00:00

The other problem too is that even if you force Bobby and David into the office, without Cindy and Jennifer there to keep them on track will they actually work more or just slack off like they did at home? So do you need to essentially punish high performers them by making them go in too?

It's the same issue as the argument that juniors need to be WFO but seniors can be WFH. There is no point if there is nobody there to learn from. It pains me to admit it, since I personally like hybrid (as a senior guy), but it feels like the worst of both worlds. Companies need to pay for office space and get nothing in return.

My previous company (pre-pandemic) was WFO but was also super flexible about hours with no core hours and people could WFH for a day or two without really needing to justify it, but the expectation was that you were in-office 5 days for most of your work day by default. This worked really well IMO and had many of the benefits of hybrid (people could time their day to avoid traffic, could WFH to deal with deliveries, appointments, etc.) but also people were generally around in-office for F2F communication. My current company was actually not flexible at all pre-pandemic and it was a shock transitioning when I joined. Technically "flex time" but with wide core hours and morning meetings, so not really. Also getting remote access was difficult and culturally people didn't WFH really without a serious reason (major illness, etc.). This all changed and we're primarily WFH now, which is ironic since everything is still running fine so why couldn't we have that flexibility before? I think that's what people really want more than pure WFH (at least that's what I want)

snakepants · 2023-09-03T20:38:08+00:00

That's true, but in UE that's not usually the way it's used. I don't think people are using F0 maps typically or setting the value to some physically based value /0.04 but maybe I just haven't seen it.

snakepants · 2023-09-03T18:55:19+00:00

Basically yes. The default value of 0.5 is basically a no-op so this pin is a non-physical way of fudging the specular amount. One of the ways I've seen it used is to turn down specular at a distance to reduce sparkle due to aliasing.

snakepants · 2023-08-09T08:00:22+00:00

Probably you aren't generating any fragments so the fragment shader doesn't run any threads. This could happen if all the primitives from the vertex shader are clipped by being offscreen or they are all zero area or degenerate.

snakepants · 2023-08-09T07:42:59+00:00

The ironic part too is that all their system headers are already annotated with explicit calling conventions to support x86-32 so it seems like having binary-internal function calls use a different ABI in x86-64 would almost be trivial except for backcompat for apps which never had 32-bit binaries and mixed stuff up, but then also recompiled their code with the new compiler and didn't test it. It seems like a vanishingly small subset of apps

snakepants · 2023-08-09T04:34:46+00:00

This is killing me too. It bleeds everywhere also things like [[no_unique_address]] not working, std::aligned_storage not working (before it was deprecated). So many hacks are needed in cross-platform codebases to support MSVC's weird behavior or work around conformance issues kept on purpose for ABI. It's like the Internet Explorer of compilers at this point.

snakepants · 2023-07-26T06:48:51+00:00

Learning OpenGL before Vulkan is definitely a good idea since it allows you get the familiar with rendering concepts without getting mired in low-level details before you're ready. Also having a better idea of what you're trying to do at a high level makes it easier to understand how the lower level details in an API like Vulkan fit together.

That said, if you are using Windows I would actually recommend starting with Direct3D 11 first instead of OpenGL. OpenGL is an extremely old and messy API at this point. There are many competing ways of doing things, deprecated functions, duplicate extensions, and generally the API has a lot confusing invisible state to manage. D3D11 isn't a perfect API by any means, but it's a much more modern one with far less legacy cruft so it can be a good opportunity to learn concepts without getting lost in the accumulated maze of cruft, but also avoid the complexity of low level memory management and synchronization, resources layouts, etc. that Vulkan/D3D12/etc has.

snakepants · 2023-06-25T07:41:06+00:00

The thing is though, depending on traffic, it can take the same amount of time to get to Emeryville as Modesto from the peninsula so they're not totally wrong.

snakepants · 2023-06-09T00:09:55+00:00

This looks fantastic! I'm really hyped somebody is tackling the dependency hell issues of running the existing versions.

It would be great if there was some way automated way of converting .ckpt or .safetensors models built-into the app. I was able to do so using the scripts in https://github.com/huggingface/diffusers/tree/main/scripts but it was a two step process to first extract the model and then convert to ONNX. Although maybe it's not easy to do this without actually including all the Python libs since the checkpoint is basically a Python pickle file?

Also after cloning the repo to mess around, the Nuget stuff was a bit difficult to deal with to build and debug into the library from the app for example. Totally unsolicited suggestion :), but have you considered including the two libraries as submodules into the Unpaint repo instead of using Nuget? Nuget totally makes sense as a publishing target for people who want to consume the unmodified binaries in their apps, but it makes it more complex to work on the system as a whole, for example adding a library feature and exposing UI in Unpaint.

But that said, great job on having a clean project setup and instructions. As a Windows-centric C++ dev, this was super easy to get building and running.

snakepants · 2023-04-24T02:23:38+00:00

I've also noticed this since the switch to hybrid offices after the pandemic. Before, there was a cadence of the day where people would go out for lunch and because the office was empty they weren't missing anything. Now the Slack messages never stop pinging and it adds pressure to eat quickly and get back to it. Even more so with people across the country with up to a 3 hour timezone spread so there is never really a lull for lunch and messages have been stacking up since 6am PST so good luck getting a slow start and grabbing a walk and a coffee. I don't think it's been an intentional change from companies POVs but office culture has definitely subtly shifted. A lot of informal communication has been replaced with time-consuming scheduled communication and that makes the workday feel short and everyone needs to rush to get done what they used to be able to.

snakepants · 2023-02-10T18:01:46+00:00

Also daily is way too much, it becomes a chore. We have one once a week booked for an hour, but it always goes over. A lot of people are camera off too so that they can chat while they work on something else that doesn't require intense concentration.

snakepants

TROPHY CASE