You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Anything using the RenderingDevice for low-level draw and compute
Describe the problem or limitation you are having in your project
The current interface for RenderingDevice uses RIDs, which make type checking impossible.
This leads to potentially hard to debug errors and makes the interface harder to understand.
In addition, many of the RIDs need to be manually freed using rd.free_rid()
This again can lead to memory leaks as well as requires a lot of boilerplate code from the programmer
Describe the feature / enhancement and how it helps to overcome the problem or limitation
A set of classes that implement the various things provided by RenderingDevice, in a way that adheres to RAII, allows for much more readable code.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
i.e. the classes RDTexture1D, RDTexture1DArray, RDTexture2D, RDTexture3D, ...
Each has a constructor taking the dimensions of the texture, the data format and the usage bits as arguments (and an optional RenderingDevice, if not supplied uses the default).
It then creates an appropriate RDTextureFormat, RDTextureView and an RID via the rendering device.
Upon deletion, it frees the appropriate RID.
It keeps track of its associated RD and checks if two the user tries to use incompatible RDs in different places
It also exposes all the ways this texture could be used with the RenderingDevice as methods, i.e.
creating a uniform via RDTexture2D.uniform(binding: int)
getting the data via RDTexture2D.get_data(layer: int) which wraps rd.texture_get_data(...)
copying from one to another via RDTexture2D.copy_from(...) and RDTexture2D.copy_to(...) with error checking for invalid RIDs, different RenderingDevices, different data formats...
If this enhancement will not be used often, can it be worked around with a few lines of script?
The point of this enhancement is to reduce boilerplate and prevent hard to debug errors, there is no short way to do this
Is there a reason why this should be core and not an add-on in the asset library?
It is possible to do this in an addon, however it seems to me that it would be good for the engine to provide a more friendly interface for RenderingDevice out of the box
The text was updated successfully, but these errors were encountered:
I am currently working on implementing this in gdscript to get an idea of the scope, because it is easier to prototype there
But I would be happy to contribute this to the engine source if there is any interest in having this be part of the engine (although is is likely a large project that would take a while to implement)
Calinou
changed the title
Typesafe and RAII compliant interface for RenderingDevice
Add a typesafe, RAII compliant interface to RenderingDevice
Feb 16, 2025
Describe the project you are working on
Anything using the RenderingDevice for low-level draw and compute
Describe the problem or limitation you are having in your project
The current interface for RenderingDevice uses RIDs, which make type checking impossible.
This leads to potentially hard to debug errors and makes the interface harder to understand.
In addition, many of the RIDs need to be manually freed using
rd.free_rid()
This again can lead to memory leaks as well as requires a lot of boilerplate code from the programmer
Describe the feature / enhancement and how it helps to overcome the problem or limitation
A set of classes that implement the various things provided by RenderingDevice, in a way that adheres to RAII, allows for much more readable code.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
i.e. the classes
RDTexture1D
,RDTexture1DArray
,RDTexture2D
,RDTexture3D
, ...Each has a constructor taking the dimensions of the texture, the data format and the usage bits as arguments (and an optional RenderingDevice, if not supplied uses the default).
It then creates an appropriate
RDTextureFormat
,RDTextureView
and an RID via the rendering device.Upon deletion, it frees the appropriate RID.
It keeps track of its associated RD and checks if two the user tries to use incompatible RDs in different places
It also exposes all the ways this texture could be used with the RenderingDevice as methods, i.e.
RDTexture2D.uniform(binding: int)
RDTexture2D.get_data(layer: int)
which wrapsrd.texture_get_data(...)
RDTexture2D.copy_from(...)
andRDTexture2D.copy_to(...)
with error checking for invalid RIDs, different RenderingDevices, different data formats...If this enhancement will not be used often, can it be worked around with a few lines of script?
The point of this enhancement is to reduce boilerplate and prevent hard to debug errors, there is no short way to do this
Is there a reason why this should be core and not an add-on in the asset library?
It is possible to do this in an addon, however it seems to me that it would be good for the engine to provide a more friendly interface for RenderingDevice out of the box
The text was updated successfully, but these errors were encountered: