Expose canvas texture creation to ZScript

[AFADoomer]

Requesting the ability to define canvas textures via ZScript instead of being limited to ANIMDEFS-defined values.

Maybe a new function under the Canvas class and lifting the code from ParseCameraTexture?
native static Canvas Create(String canvasname, int width, int height, int offsetx = 0, int offsety = 0, int usetype = TexMan.Type_Wall);

[dpJudas]

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 is garbage collected, making it even more tricky to know when such a canvas is no longer in use.

[AFADoomer]

I am not as familiar with the engine internals as others are... But I don't understand the difference between a mod author defining 5000 (or whatever random large-ish number) ANIMDEFS entries and using those versus creating the texture via code.

How do those two approaches (that call the same underlying engine functions to create the textures) affect the engine differently?

[Graf Zahl]

If they fail, one will crash the game in the middle of a level, the other won't even start up.

The far bigger risk is something else: Badly written code constantly creating new textures without stopping.
All things considered, it's not a good idea to give modders control over limited hardware resources. These can result in nasty performance regressions and other things and are very hard to diagnose.

[kevansevans]

I think a bunch of us would appreciate it if y'all would stop using the "modders might use it wrong" to shut down feature suggestions. It's bullshit. Do you know how many examples of malicious ZScript I could come up with? It's not difficult, and it's especially not difficult to make a mod that eats up a whole systems RAM.

[dpJudas]

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 to like it: basically, engine has an internal limit to how many textures and sizes you can request and you'll get a null back when you used them all. The deal is about as shitty as anything Vulkan offers: not specified what the limits are and your problem when it suddenly returns null (this is exactly the deal they offer with descriptor pools).

[kevansevans]

Allowing zscript to create arbitrary textures with unknown lifetimes will create tons of problems for the engine. On top of that ZScript is garbage collected

The deal is about as shitty as anything Vulkan offers

Are you able to go into a bit more detail as to why it'd be bad to request new textures? Because isn't that what the engine is doing already when it has to load in resources? Could a compromise solution be to A) Aggressively assume that these new textures are to be unloaded on say map change, and leave it up to the modder to manage and remake them, and or B) Give the modder the ability to remove the textures from memory themselves.

Or an alternative idea, the option to redefine an existing canvas when needed. That way the modder still has to outline what they need in ANIMDEFS, but can change its dimensions, offsets, flags, etc. on the fly.

[dpJudas]

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 have. With Canvas.Create a mod could slowly leak textures and eventually reach the limit Vulkan has internally and when that happens the game dies with an engine error. Only way to prevent it is for the engine to set its own internal limit to how many times it can be called and how much memory it can request. If we do that I personally have no objections to such a function.

[dpJudas]

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.

[Rachael]

I think it would be worth considering to put those limits inside user cvars. Because today those limits might seem generous, in 10 years they might seem a bit restrictive.

Also, if we're talking about limits, managing limits would be nice too, such as the ability to destroy canvas textures that are no longer needed and free the allocation.

[dpJudas]

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 kind of budget they have to work with and you'll get readme.txt files asking users to increase the limit. As someone that has to deal with the vulkan nightmare of limits varying between hardware, drivers and platforms, trust me, you do not want this.

[kevansevans]

nobody blames the mod - they blame the engine.

Haven't we universally agreed that people like this are idiots if they can't understand they're running a mod? I understand that it muddies the water when it comes to debugging the engine, but if someone comes into the community, kicking down doors, demanding the manager so they can complain that their version of GZ Mega Shit farded on their GPU and made it stinky, I think it's safe to dismiss them and write them off as unwilling to cooperate in finding out what the problem is. This isn't a unique problem to GZDoom.

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.

I think it would be worth considering to put those limits inside user cvars. Because today those limits might seem generous, in 10 years they might seem a bit restrictive.

From what I can gather from researching how much memory textures can take up, a single 2048x2048 at 8bpp would take up around 4mb of system memory (both in ram and gpu, 5.3mb if mipmapped), meaning the hard limit there would be 256 textures. I want to agree with Rachael on this being a harsh restriction to a degree, but realistically people would have to go out of their way to reach this limit. Could a more fair compromise be to make it a 2gb limit? Or did you mean each texture would not be allowed to exceed in 1GB of needed resources?

[dpJudas]

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 consumes somewhere in the range 500 MB to 1 GB. On top of that you have to add game textures. Other applications may be loaded too which uses memory. That's why I suggested 1 GB as the upper limit, but sure, we can make it 2 GB too - my card doesn't care as it has more.

The 1024 texture count limit is due to hardware limits for bindless textures. You can safely assume that on PC you can have 65536 textures like that. Anything higher and there will be a lot of GPU's that can't do it. Once again this limit is shared between other things we want to place in bindless textures as well: game textures, lightmap textures, light probe environment map, etc. If we ever hit the 65K limit the engine is sort of fucked as now you have to completely redesign its bindless strategy as it can't assume it can just assign a slot for any texture. It doesn't have to be as low as 1024, but its dangerous if we allow unlimited textures.

[phantombeta]

I really don't get why this is such a concern. If it's tied to names like the OP suggested, it's not that easy to accidentally leak textures. You'd have to be deliberately using procedurally generated names to do that.

Garbage collection isn't a problem, making Destroy mark the texture for release makes sure it gets deleted when collected, and gives modders proper control over deleting it.

And it's not like the engine can't manage lifetime automatically, either. It wouldn't be all that hard to have it delete a texture if it hasn't been used in the last frame, and ZScript hasn't called some "keep alive" function on it. Then it'd call Destroy, ZScript would see it as null, and then either the modder handles that properly, or gets a VM abort.

Kevansevans' suggestion of having to define the texture name in ANIMDEFS as a "modifiable canvas texture" would also work pretty well for most use cases people might want this for, and that doesn't allow leaking textures.

[dpJudas]

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 haven't rendered/used them for a while.

If the canvas name is always the same you could just define it as a texture in ANIMDEFS already as it is today, what problem does it solve then?

I brought up garbage collection because relying on the GC cleaning up anything but memory resources is generally a very bad idea. You never know when finalizers run (*) and as a result you could end up with a lot of extra textures no longer used but not collected yet. IMHO the proper way in a GC language is to have a Dispose/Destroy function that must be called. That's very easy for a modder to forget to do though.

*) In fact, one could argue finalizers was a terrible idea that was the wrong solution to resource management in GC languages.