-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Object wrappers for Raylib structs #51
Comments
I know that you (schveiguy) wrote elsewhere that you're "not looking for a raylib-cpp style API reimagining" (not that that's really what this proposal is) but I think it's worth sharing how I successfully created such a class in my own project. I think it makes sense for anything tied to GPU memory to be an object, so that whenever it's no longer in use, the garbage collector can pick it up and the GPU memory can be freed from the object's destructor. Here is the class I made for OE-2D as a wrapper to the
That being said, there is a reason for not including something like this in Raylib-D, which is that the implementation may depend too much on how the game loads textures. For example, the definition above would make most sense if all textures are loaded at the same time, such as the beginning of a game level, and there isn't any index held continuously ( So my feeling at the moment is that adding such a thing to Raylib-D would make sense if we have come up with an implementation that's suited to a reasonably broad range of use cases, without having to give complicated usage instructions, but right now I'm not entirely confident that there is one. |
I'm leaning towards saying this is outside the scope of raylib-d. That doesn't mean there is not a place for such things in the ecosystem. I just think this might be too high-level for the goals of this library. To elaborate, I have written many different such objects for my various projects. Making the API elegant, and covering all the possible use cases, is really difficult. I don't want to say "this is the one true way for using object systems with raylib-d", when it could be wrong, or not fit into everyone's design. This would mean you may have to use raylib-d just for the raylib binding, but ignore the other stuff. simple things, UFCS functions, operator overloads, dealing with strings vs. C char pointers, these are all fair game. |
This is just an idea, borrowed from Raylib-CPP, to turn some Raylib structs into classes.
I don't think all of them should be.
Vector2
,Vector3
, andRectangle
should certainly remain as structs. ButTexture
is an example of one that may be better as a class.Of course, this would be a breaking change if we retain the old names. Perhaps the class for
Texture
can be called "ManagedTexture
" (since Raylib-CPP calls the baseTexture
struct from Raylib "TextureUnmanaged
").The text was updated successfully, but these errors were encountered: