Make it possible to single-thread portions that need it

[icefoxen]

In particular, pretty much any part of SDL2 that interacts with the hardware (so, most of it) is defined to only work properly from the program's main thread. So, for example, drawing can't be made into a system that consumes components containing an SDL2 Texture.

Because of this, it would be nice to be able to "pin" components to a particular thread or some such, so they will only get run by that thread. The world is an imperfect place.

...though upon consideration, when doing drawing with SDL2 the order you draw things matters and specs can't really specify that anyway, so maybe trying to do drawing with an ECS is misguided in the first place.

[OvermindDL1]

Better to build commands (either via vulkan-like command buffers, there are libraries that give such an interface on opengl, or via literally building up custom commands that can be processed later and then passed to sdl).

[icefoxen]

Yeah, probably. The only downside to that is... okay, well, it's harder. :-P Basically instead of having the state of your ECS system "be" the command buffer and just be kept in the right order even through entity inserts and deletes, you have to build and order your drawing state as an extra step.

So for my next question, is there a good way to do this through specs? I'm imagining it as a sort of map-reduce operation, where you have a system or some such that runs on each entity and produces a list of drawing commands, which then get coalesced into a buffer afterwards rather than having each function try to lock and modify a shared buffer...

[kvark]

@icefoxen specs by itself doesn't provide any facilities for command buffers, it's vastly out of scope. However, if you are using something like gfx-rs, the symbiosis should be effective. You'd have one or more systems, each constructing their own command buffers and sending them to the paint thread. That one would get all the command buffers and execute them in a proper order. A simple example (with just one rendering system) can be found in https://github.com/kvark/yasteroids.

For example, consider one system to be constructing the main "forward path" command buffer, then extra 2 systems filling up the command buffers for shadow occluders, rendering into their respective shadow maps that are used by the forward path.