Meziu
commented
1 year ago citro2d will undoubtedly need a lot of work to get working with an existing citro3d-rs wrapper. For this reason (and for the fact that it’s still unknown to us how much work citro3d will take to properly wrap) I’ve never been sure about wrapping citro2d directly over the original library. Instead, I’d like to see how much of its work we can lift directly into citro3d-rs and then work on a (partial) reimplementation using citro3d. After all, citro2d is in itself a wrapper around citro3d, so we shouldn’t have many issues working on that after we finish working on this wrapper.
As such (even though I’m ok with the changes proposed by this PR) I would suggest you to work with your own libraries and implementations for the time being as I don’t feel like rushing the development of our features and impls that aren’t yet final.
I started writing a wrapper with bindings for citro2d and it uses its own function to instantiate and configure a C3D_RenderTarget. Because citro2d relies on citro3d I think citro2d-rs should integrate with citro3d-rs as much as possible. The C3D_RenderTarget can't be used outside of the wrapper if the raw pointer is crate-private.
It's the first time I write bindings and wrap an existing library code, so I'm probably doing a lot of mistakes. For now the code is heavily inspired by citro3d-rs and citru-rs.