ZDoom

If GZDoom RTX Mod works really well then what do you need GZDoom for? If its to implement missing features then I think its better to ask the GZDoom RTX developers to do that.

The key question here is whether "new Bitmap(loadbitmap)" is thread safe or not, since it might be both the UI thread and the background loader thread could be calling it. Not even sure if using Properties.Resources.UnknownImage directly instead would be safer. The way Microsoft implemented their ...

It is probably due to a race condition. Many years ago I tried to fix the threaded loading of images in UDB which was done completely wrong. The code basically didn't lock access to shared variables and it created win32 objects (such as System.Drawing.Bitmap) on worker threads while the win32 GDI ...

It was a deliberate design decision to not give a function like that. The canvas texture is allocated on the GPU and for that reason need strict resource control. Allowing zscript to create arbitrary textures with unknown lifetimes will create tons of problems for the engine. On top of that ZScript ...

For me it is the same: it only makes sense if it would be enough to make a living. As long as I must have a normal job I'd rather have the freedom to do whatever I want in my spare time with no strings attached.

You're welcome.

Doom originally used different light calculations for sides and flats. The vanilla light mode doesn't know if something is a side or a flat, so what it does instead is to look at the normal of the surface and see if its mostly horizontal or mostly vertical. If its horizontal it uses the side math ...

Just reply to my own comment about threads, it turns out that webassembly does support sharing memory between the threads now. However, you must enable it using HTTP headers (https://web.dev/articles/coop-coep):

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

Well at this point you have two options. First is to install the Web assembly DWARF debugging extension for Chrome and then pray the debugger can tell you something (unfortunately its very undeveloped and borderline useless). Or you begin adding printf/cout statements in the code to see how far it ...

Try delete the shader cache (pipelinecache.zdpc) in %localappdata%\zdoom\cache
Please let us know if that helps.

It could also be a driver bug. Keep an eye out for another release from NVIDIA. They sometimes release a couple of driver versions in short succession if they accidentally break something.

If it were up to me I'd remove the code. First of all the OS itself already boosts priority on foreground apps. Secondly, lowering the FPS to 30 (or whatever it is set to) already deprioritizes the app when its in the background. Third, we live in a multicore world today, so its not like it directly ...

Kex and GZDoom are completely different engines so the fact that it is happening to both indicates it isn't the game/engine that is doing it. It is more likely it is related to either a specific hardware component and/or subsystem in Windows. I have an ASUS monitor that freezes the mouse for a ...

We need Graf's personal feedback on this. The actual changes are minimal (change the color code of the progress bar and copy in the logo), but it could also simply be that Graf didn't like that kind of logo branding. It is probably worth mentioning here that the original startup screen code was ...

OK in that case I have no idea why Graf didn't just do that.

It does, but if you put it into bootlogo.png in GZD I believe it looks really pixelated. It needs the commits I talked about for it to look as nice and crisp as what you just pasted here.