When is that useful as a default?

No I mean when is it useful to move instead of copy as a default? When do you want a op b to move a&b?

Why has Rust chosen to move here as a default?

It says what branch I am on in my .gitmodules

I think that means you are on master?

Yeah IIRC there's another location somewhere inside .git that defines that commit of the submodule the submodule is at

Hence you have to manually update the submodule to get a newer version

If I make an edit in a submodule, commit it, and then look at my parent repo, it shows a new commit hash as the submodule reference

The filepath modified is showed as just "CaveGame/imgui" though

Let's talk threaded content loading: It seems very attractive for me to on the loading thread to make a call to a wrapped function that makes a promise, adds it to a queue, then waits on the future and then returns a Texture*, and the main thread iterates over the promise queue (with one loading thread, just 1 item) once every frame and loads the textures

This would allow for very nice code on the loading thread, i.e. just Sprite s{ contentLoader.LoadTexture("...") } without having to consider the fact that the texture won't be available immediately

However, do you think I am shooting myself in the foot by always stopping the loading for a frame when some content needs to be loaded?

C++

That's what I currently do, main thread has to preload all needed textures and pass them as pointers to the loading thread

Indeed it would make sense to me to load textures dynamically when requested, since that's what my loading/world generation thread is for

True, and loading thread wouldn't know about frames, it would just pause until the main thread ticks over to the next frame & performs the loading

Hmm I think I've confused you with terminology, loading thread = world generation thread

Current approach fills a struct of texture pointers on the main thread, and passes that to the world generation thread, which passes the textures to the tilemaps, entities etc.

But this is becoming unmanageable, annoying to pass around a lot of stuff as variables like that

2D, why does that matter?

So I'd want the world generation thread to be able to request the textures by path, just like my main thread can, and then use them directly

Procedural, and I don't feel like constructing entities on an asynchronously run thread is "more work than it should"

Can't do OpenGL calls from non-main thread

@TomTsagk No, the pointers are pre-filled on the main thread, as it's the only thread that can load textures

world generation thread uses said pointers as initializers to sprites what whatnot

@TomTsagk Yup, gameplay state holds a future to the generated world, and displays a loading screen while the future isn't completed

I would lose a frame for every non-threadable item of content I would load, i.e. spawning entities with 5 textures will take at least 5 frames to complete (off by one most likely, so 6). Probably not a big deal, but I can't come up with anything nicer without introducing a lot of complexity to my initialization

To make the usage API nice as my ThreadedContentLoader::Load could essentially be implemented as return contentLoader.ProperlyMutexedPromiseVector.emplace(params).get_future().wait()

I.e. make promise, add to queue on main thread, wait on the future to complete, return pointer to loaded item & continue like all this was performed in sync

Again, the loading thread can't & won't load anything, it needs to request things to be handled on the main thread

It's to have a nice flow in my object initialization code

I can just create a sprite for my entity instead of requesting a texture, waiting for it & then finding out somehow what entity was missing a sprite

Yup, with the current architecture. I actually just realized that with the blocking approach, I could just parallelize stuff inside the world generation thread, and that would allow for more than 1 content load per frame

Framerate won't be affected obviously since it's the world generation thread that gets blocked

It's generation times that are affected

It's a one time process before any gameplay happens, think something like Spelunky

Yeah idea is enough.

It's just a longer "Generating World..." screen between levels

Currently there's no need to do anything special on the main thread when loading is happening, everything happens normally, gameplay state just renders a text instead of the world while the world isn't ready

Yeah, currently in release builds the loading screen just flashes for like a frame, but debug builds show it for a second or two due to iterator validation being super slow

Not really, just a cave generation, spikes & an exit door that triggers another level to be made

Will need some kind of pathfinding at least to make sure a valid path to the exit exists

Well that was pretty easy to implement, decided to just check the thread ID at the top of each loading function, and then call the same loading function again

if (std::this_thread::get_id() != MainThreadID)
{
    m_Mutex.lock();
    auto future = m_ThreadSafeLoadingTasks.emplace(key).Promise.get_future();
    m_Mutex.unlock();
    return future.get();
}

void TickMainThreadProcessing() override
{
    Assert(std::this_thread::get_id() == MainThreadID);

    std::lock_guard guard(m_Mutex);
    while (!m_ThreadSafeLoadingTasks.empty())
    {
        auto& item = m_ThreadSafeLoadingTasks.front();
        item.Promise.set_value(std::apply([this](auto... params) { return Load(params...); }, item.Parameters));
        m_ThreadSafeLoadingTasks.pop();
    }
}

std::apply is awesome

Yeah, I have a tuple of the parameters already ready for a cache map, so it's easy to just store that, and unpack to reuse the same function

Not really, it's easier to pass a tuple to my content loader base class, this is sort of a base class hell due to type erasure usage, but I have

class LoaderImpl<Texture> : public LoaderBase, public LoaderCacheBase<std::tuple<std::filesystem::path, TextureInterpolationMode, TextureWrapMode>, Texture>

Makes specifying that into a neat longish one liner :D

Hmm I haven't found a use for that yet, what do you need to do?

There's probably a reason why an enum won't work?