ZDoom

[quote="drfrag"]With the command line that Rachael posted one should be able to fetch only one branch and there are other methods explained at Stack Overflow but i don't know if it's possible with TortoiseGit.[/quote]

[quote="Graf Zahl"]The problem is the fetch, it'd pollute the local data with everything from that other repo which I do not want in my local copy, especially if it's just go get access to a single commit.[/quote]

Don't ask me. ¯\_(ツ)_/¯

I know what he's saying, but this is why you consolidate repositories if you're really worried about such things. Git is designed from the ground up to handle multiple workflows like this seamlessly. Unless your disk space is really really tight, this shouldn't even be a problem, and eventually Git cleans it up anyway.

[quote="Rachael"]Cherry-picked[/quote]
Thanks. :wub:

With the command line that Rachael posted one should be able to fetch only one branch and there are other methods explained at Stack Overflow but i don't know if it's possible with TortoiseGit.

The problem is the fetch, it'd pollute the local data with everything from that other repo which I do not want in my local copy, especially if it's just go get access to a single commit.

git fetch https://github.com/drfrag/gzdoom legacy
git cherry-pick 3993aca50808d3e9156764a02d9c3ca2b7d37956

[code]git fetch https://github.com/drfrag/gzdoom legacy
git cherry-pick 3993aca50808d3e9156764a02d9c3ca2b7d37956[/code]

Not difficult - Cherry-picked as [url=https://github.com/coelckers/gzdoom/commit/cbb5f8a0dc7c3b7facfb348672d09310b41bd289]cbb5f8a0dc7c3b7facfb348672d09310b41bd289[/url]

Can you please make a PR from that commit? It's not that easy to cherry pick it out of another repository.

Has happened to me several times with the legacy build and MinGW debug builds.

Unrelated but vid_rendermode can take weird values which causes funny effects when looking up and down.
Pushed a fix here:
https://github.com/drfrag666/gzdoom/commit/3993aca50808d3e9156764a02d9c3ca2b7d37956

I need a call stack from the main thread next time someone experiences it. It could also be crashing due to it going out of bounds somehow, which overall is more likely as the variables controlling the worker threads are guarded by std::mutex and std::condition_variable.

I've had this happen to me before. The crash was so random, and I have experience with random crashes enough that I really didn't want to try and track down the exact cause of the issue to make a report.

I had it happen once on Master and today 3 times altogether on Texture_Cleanup, but those might be related to broken texture data having trashed some memory.
But the one time on Master was totally out of the blue.

I'm not able to reproduce this on master. Is this on some branch?

If the source of the problem is what you're describing, then the call stack of the main thread should be past the DrawerThreads::WaitForWorkers function when it crashes.

It now happened multiple times to me that when I switched from software to hardware I got a crash in MemcpyCommand::Execute.

Apparently some worker thread is left hanging, even after the software renderer has been taken down.