I am definitely looking forward to this.
4 Likes
I see the last post was from last year. Has there been any updates on this new API. I have a simple 3D API for my project that is currently using SDL_RenderGeometry() and a lot of matrix math. This API is exactly what I have been wanting for the last 10 years.
Before anyone brings up opengl or vulkan, I already know. I did consider using them directly but it would involve rewriting over 20,000 lines of code from using the 2D rendering API. The other reason I use the 2D rendering API is because it gave me a crossplatform rendering solution out of the box with caveats ( SDL_RenderGeometry does not seem to work with emscripten ).
I also have some questions.
-
Will SDL_Textures be usable with this API or will it have its own texture format?
-
How much of the 2D rendering API be usable with the new 3D one? For example, will SDL_SetRenderTarget() still be usable when rendering to a texture mapped on a 3D surface?
-
Will there be a way to switch between a 2D and 3D coordinate system? For example, if I render a 3D scene could I still use 2D coordinates for the HUD and UI elements?
- It will have its own texture formats.
- It depends. There’s a plan to eventually give the 2D renderer a backend based on the 3D API, but how much you’ll be able to mix and match the two remains to be seen. If you’re doing 3D stuff it’s only one extra step to also do your own 2D stuff.
- Yes. You’re providing the vertex descriptors and shaders, doing your own matrix math, etc., so the geometry you’re sending can be anything. 2D coordinates, 3D coordinates, whatever.
The new GPU API will be more akin to Vulkan or Metal. You’ll have to handle your own matrix math, vertex descriptors, shaders, etc.
1 Like
What isn’t working? It seems to work OK here: you can try this link to run a game rendered using SDL_RenderGeometry() (it takes a little while to load).
1 Like
Thanks. I think I was misunderstanding what the API was going to be. I thought it was going to be something similiar to the 2D API in that it provides high level functionality for those who were just trying to implement simple 3D functionality similiar to raylib.
This in itself is still a great thing though since it will save me time on implementing simple 3D functionality without having to worry about platform specific coding.
Did you build SDL2 from source or did you use the one that is installed when you use the “-s USE_SDL=2” flag?
Also, its cool to see another BASIC developer. I am asking about all this for my BASIC dialect RCBasic which uses the SDL2 2D renderer for everything.
I use the -s USE_SDL=2 flag. The only SDL module I’m considering compiling from source is SDL2_ttf; at the moment I’m using -s USE_SDL_TTF=2 but the version that gives me is too old to contain Harfbuzz.
I use a mixture of SDL_Renderer for 2D and direct calls to OpenGL for 3D and shader graphics. Fortunately SDL2 supports this mixed environment and it serves me very well, while OpenGL is available on all the platforms I support (Windows, MacOS, Linux, Android, iOS and Emscripten).
If and when any of those platforms drops OpenGL altogether (the first will probably be MacOS) the cross-platform nature of my app will fall apart! At that point it would have to move to using the new SDL 3D/shader API, if it’s ready, but in practice I’ll be too old for that to affect me personally.
I agree that sdl not getting a simplistic high level 3d api is a missed opportunity. The current 2d one can already be use for 3d, albeit it comes with innefciences ( see Am I using SDL_RenderGeometry correctly? - #3 by Sylvain_Becker )
So better 3d support would not have meant bloating sdl3
As an aside, could you share your 3d api built with RenderGeometry?
Currently half of the API is built in C++ and the other half is built with the BASIC programming language I develop so its not really useful to you. If you want to check it out anyway you can find it here: https://github.com/n00b87/Calamity3D
Note: In RCBasic, the SDL_RenderGeometry() function is called DrawGeometry().
1 Like