ZDoom

shrug Doesn't really matter if it's only if the keep alive function is called, or if it also keeps its contents as long as it's being rendered, the point was that it's not all that hard to come up with a system that allows the engine to automatically manage the lifetime of the hardware resources. I ...

I never said the contents would be kept. Like I said, you'd have a "keep alive" function on the ZScript side. If the modder doesn't call it every frame, it's their problem if the texture loses its contents. That will work but then why not always just drop the texture if keep alive isn't called? You ...

If the engine destroys a texture due to not having seen it for a while there's no bringing it back. It could recreate it next time zscript/game uses it, but its contents will be lost. Effectively this will just be the 1024 limit anyway, except now you will notice by the textures turning black if ...

I meant the total GPU memory usage. 64 2048x2048 (16MB each) textures, 256 1024x1024 (4MB each), 1024 512x512 (1MB each), 1024 256x256 (256KB each; texture count limit kicks in instead). Keep in mind that Nvidia and AMD still sell GPU's with 8 GB of memory. The frame buffers and other engine buffers ...

I don't think its a good idea to let the user control stuff like this. Newer versions of GZDoom could increase the limit, but of course, those clinging to decade old graphics cards will then run into trouble. If you have it as a CVAR you just forward the nightmare to the mod: they will not know what ...

Just to clarify: the limit could be that you can allocate a maximum of 1024 textures and they can totally only use 1 gigabyte of memory. Exceed any of those and Canvas.Create will begin to return null or throw an exception.

When the game dies with "device lost", "could not allocate descriptor set" or "could not allocate image" nobody blames the mod - they blame the engine. The difference between Canvas.Create and what we have now is that today everyone (engine and mod) knows exactly how many textures they are going to ...

It isn't about making it impossible to mess things up. It is about avoiding solutions that are error prone and inevitably leading to people blaming the engine when they don't know why things blow up. I can think of a way to do it with the function AFADoomer suggested, but I'm not sure you're going ...

The modern GPU does not give the programmer complete control over how an image is rendered. The acceleration works by forcing certain constraints on the program and then accelerating the hell out of that specific method. Simply put, the GPU can only draw triangles. Either not clipped at all, or ...

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.