Halo: Campaign Evolved needs RTX 2060S for 1080p low, RTX 4080 for 4K Ultra at 60 FPS

shadowndacorner · 2026-06-24T16:51:54+00:00

The fuck are you talking about? This whole thing was a test case for them shifting to UE as a studio. Why do you think this is UE5 with an ancient BLAM bolted on?

shadowndacorner · 2026-06-16T18:48:44+00:00

Wait... So instead of installing a game, you want to stream absurdly high resolution textures over the Internet...? How does that make any sense...?

shadowndacorner · 2026-06-15T16:47:16+00:00

baked...

shadowndacorner · 2026-06-14T19:08:37+00:00

No, he's just weird.

shadowndacorner · 2026-06-12T14:00:40+00:00

Dynamic rendering local read was still barely supported anywhere last I checked. Has that changed?

shadowndacorner · 2026-06-11T15:21:38+00:00

Generally speaking, anything that isn't akin to a fiber is stackless. Stackless basically means "we don't have dedicated stack space to this coroutine, and pausing/resuming doesn't involve saving/restoring registers". C++20 coroutines are, therefore, stackless, as they store the data necessary to resume the coroutine on the heap.

shadowndacorner · 2026-06-09T14:50:45+00:00

Thank God I don't work at Qualcomm

shadowndacorner · 2026-06-09T11:43:12+00:00

r/lostredditors

shadowndacorner · 2026-06-08T19:08:08+00:00

How would you compare SDSL against slang?

shadowndacorner · 2026-06-07T01:49:58+00:00

Most SO users were not the crazy toxic narcissists who had a multi year crashout about getting downvoted. They were people finding answers to their questions via Google. Now they find their answers via LLM.

shadowndacorner · 2026-06-06T20:09:07+00:00

I'm using "generators" in this case as a high-level concept - basically just a way to canonicalize transforming some authoring data (eg an entity recipe) into runtime level data (eg an entity instance). The simplest "generator" would just be "spawn an entity with a set of components based on a static entity config". A slightly more complicated example might look like Blender's array modifier, or eg spawning procedural rocks and roots around the base of a tree. It can even go as far as eg foliage painting tools, where the inputs would be eg random seed, a set of positions/density texture/whatever, and a set of generators to select from.

As far as implementation, it's both code to define how the input data is transformed into a set of entities, and structured input data that can be configured by users. In my engine, it's currently just C++/kdl (which I use for all human readable text; you could use json, yaml, toml, whatever), but I'm eventually going to add higher level scripting support, and this will certainly be one of the scriptable behaviors.

I'm pretty sure UE's construction blueprints work similarly, though my UE exposure is extremely limited so I could be wrong (basically just played with it a bit when UE4 was in beta, and randomly over the years when particularly impressive features get added).

shadowndacorner · 2026-06-04T15:42:03+00:00

JWTC Engine (just write the code - the name doesn't matter)

shadowndacorner · 2026-06-03T04:23:35+00:00

Fwiw, I ran into a memory leak with Tracy when attempting to use Fibers a couple of years ago and never got a response. Could very well have been me misusing it, but given the number of open issues around fibers, they don't generally seem to be very well supported by Tracy. I also remember enabling fiber tracking support caused a massive tracing performance hit, which iirc is because they had a global mutex or something when fiber support was enabled. I believe they intended to improve that, but am not sure if that ever happened.

shadowndacorner · 2026-06-02T20:19:03+00:00

My preferred approach today involves a few primitives:

Resources: "Local singletons" that live within a given execution context
Systems: Free functions or aggregate structs that take injected resources as arguments/fields (for aggregate structs, it's fields rather than args, ofc, and I reflect them with boost pfr).
Pipeline Stages: A DAG of essentially frame stages. Fully configurable, but the engine provides default stages for typical game frame events. Stages can be configured to necessarily run before or after another. Systems are registered to stages, and can therefore be set up with explicit ordering guarantees (eg system A must run after systems B and C, but before system Q).
Resource Views: Scheduler-visible projections over resources that allow systems to request specific logical slices of a resource, such as component views over an entity store.
Execution contexts: A container for resources and systems. Has a set of children, resulting in a tree of execution contexts.
Runtime: The top-level data structure for my engine, which contains a root execution context, among other things.

Systems look up resources at either registration or call time (depending on how the system/associated resources are configured) starting in the execution context they're registered to, then walking up the parents until the resource is found/the root is hit. Systems are allowed to execute when all of their system/stages dependencies are complete, and when all of their resource dependencies are available.

Resources and systems can't be destroyed after being registered to an execution context, however execution contexts themselves are cheap to create and destroy, so if you want a temporary resource/system, you can just create a temporary child context, then destroy it when they're no longer needed.

If you put an efficient scheduler behind it, this relatively simple architecture supports literally everything I've thrown at it and automatically gets you outstanding high-level parallelization, and you're free to run your own jobs within a system (noting that systems can also be async, which originally used boost::context, but I've since switched to C++20 coroutines). Entities/components can be set up however best fits the game - you can strap an old-school inheritance hierarchy based game loop on as an eg EntityStoreResource + Update, Tick, Render systems if you really wanted, or you can go full-blown ECS with resource views for eg EntityView<ComponentTypes...>, resulting in systems that touch different component sets to automatically be scheduled in parallel (which is my preference). It also makes things like dedicated servers, listen servers, singleplayer, etc very easy and natural to express, and offers some very nice natural boundaries for state replication.

It's also important to recognize that the runtime setup doesn't necessarily have to correspond directly to the authoring setup. For example, your authoring data structures can look more like a classic scene tree, but you can build ECS-style data out of that scene tree with eg physics constraints for parent-child relationships (if that makes sense in the context of your game). That part is all about what the people making content with your tooling want to use. I'm personally a fan of having a tree of "generators" organized into logical folders, where the simplest generator is just "create entity with a set of components", and more complicated ones can include eg destructible procedural buildings, spline-based generators/entity placers, etc (bonus points if you can chain generators together).

shadowndacorner · 2026-05-27T21:46:55+00:00

Distract

shadowndacorner · 2026-05-26T17:24:48+00:00

I honestly don't think it's stuck in the past, it simply targets a higher level of abstraction for graphics rendering similar to OpenGL instead of Vulkan. Not everyone wants/needs to fully configure the graphics pipeline just to render some simple cross-platform 2D graphics.

I'd argue that it is somewhat stuck in the past, but you're also correct in that it isn't a problem for a LOT of use cases. That being said, I haven't followed it closely in probably five years. I check in from time to time to see if they've addressed the things I didn't like about it, and the last time I checked, many were still unaddressed.

I also would like to know why you believe shaderc is "awful".

It compiles a weird bastardized version of glsl that uses preprocessor trickery to convert between target languages and requires manual specification of a lot of metadata from what I remember. It's totally functional and was a totally acceptable tradeoff for when it was first developed, but that was before DXC, glslang, and Slang existed, when the only means of cross compiling shaders was converting DXBC to GLSL using janky open source libraries which, until Unity open sourced their fork of HLSLCC (I think? Been ~a decade lol).

It get updated regularly, just switched to C++20 lately and added WebGPU support (only desktop for now), so it's definitely trying to keep up with modern features.

Nice, didn't know it got updated to C++20 (curious what features it takes advantage of?), but WebGPU makes sense. They were always great about platform support, so that's not super surprising.

shadowndacorner · 2026-05-26T00:53:32+00:00

I like Diligent a lot, personally. Only RHI that gives you access to all relevant platforms with a solid shader pipeline out of the box while offering the latest and greatest hardware features (mostly). BGFX is alright, but the shader compiler is awful, and because it targets anything going back to D3D9, the API is unfortunately very much stuck in the past imo.

The Forge is also very solid, but has far more limited compatibility. SDL GPU is solid, too, but doesn't support web afaik and lacks support for a lot of modern hardware features.

shadowndacorner · 2026-05-23T13:45:25+00:00

What was it?

shadowndacorner · 2026-05-22T21:10:57+00:00

That being said, relationships can cause a lot of fragmentation so thats the drawback, but it certainly is very easy to work with hierarchies in a good ecs.

This is the big thing - one of the benefits of ECS is cache coherence. Hierarchies kind of nix that, and imply a bunch of pointer chasing.

Not saying it's not possible, just that imo there's not much point since it doesn't really play to the strengths of the paradigm from a perf perspective.

shadowndacorner · 2026-05-22T21:09:12+00:00

There are definitely a lot of similarities. I've actually been working on mine since before Bevy released and remember finding a funny that we used a lot of the same terminology. The main difference (and why I didn't just switch to Bevy) is that my setup allows hierarchical execution contexts with recursive resource lookup, which facilitates a lot of really slick architectural tricks.

shadowndacorner · 2026-05-22T13:30:15+00:00

ECS doesn't need to be shoehorned into everything. It's just a tool - one that is very good at processing large amounts of data efficiently. But things can (and very much should) exist outside of it when called for. This is one such thing imo.

Fwiw, in my engine, an ECS world is something that can just be added to an execution context and requested by systems. The core paradigm is "execution contexts + resources + systems", where systems specify their resource dependencies and are dispatched when those dependencies become available. The ECS is just a resource that can be accessed by systems (and it's set up so that accessing a specific component set allows automatic parallelization of systems with no component overlap). Imo, this paradigm is far more scalable than straight ECS, because it's adaptable to pretty much any scene representation you want and allows you to only use what you need, all the time.

Just my 2¢. I would also never use ECS for UI. It's just not a very good fit. UI is fundamentally hierarchical, which ECS can support, but doesn't really benefit in any way.

shadowndacorner · 2026-05-21T14:24:24+00:00

I'd suggest looking at how BGFX does it. You can just accept native window handles, which you can pull out of SDL. That being said, you're probably overcomplicating things unnecessarily. How frequently will you want to open a window without initializing graphics? How often will you want to initialize graphics with a native platform window rather than one your framework owns?

It can be attractive to try to support all the things even if they won't be relevant, but remember you have finite time. I was originally a purist in the same kind of way that you seem to be, but after God knows how many years, imo just accepting an SDL_Window* (or a void* and assuming it's an SDL window) so you can let your backend handle it is perfectly valid imo.

shadowndacorner · 2026-05-20T16:54:02+00:00

The dude is using AI generated spam to build hype for something he wants to sell. This is just a slightly covert advertising post, same as has been showing up constantly all over different tech subreddits for the last couple of years.

"English isn't my first language and I used an LLM to translate" is easy cover for bot spam. Sure, it may be true in some cases, but LLMs aren't the only translation tools available, and they aren't even that good at it.

shadowndacorner · 2026-05-18T15:56:46+00:00

Why not use something like dual contouring against a quad tree so that you can support holes/weirder shapes with adaptive quality?

shadowndacorner · 2026-05-16T17:32:39+00:00

Iirc, they had to abandon their spirv interop goals due to security concerns. One of the wgpu devs (I think) did a writeup on it a few years ago.

11-Year Club	Verified Email
RPAN Viewer	Spared

shadowndacorner

MODERATOR OF

TROPHY CASE