11–20 of 27 posts
Earlier quoted context omitted.
Any reason to just use SFML over this?
SFML is a C++ library, so it provides some of the abstractions C++ has. If that's your cup of tea, I'd recommend SFML.
Finally, bringing (some of) the nice features of SFML to C. SFML, for me, has just the right amount of control over GPU things without having to really know the OpenGL pipeline.
Any reason to just use SFML over this?
Doxygen != documentation, especially in low-comment situations. Tell us more.
Everything else seems to be more pain in the ass than it is worth.
I looked at the demos and I still fail to see the point of using this over SDL2. SDL2 is already high performance and uses DirectX / OpenGL underneath. What exactly does this library bring to the table?
I think the main feature is being able to easily leverage shaders with a nicer API. Having done a fair bit of SDL over the years, dropping down to pure OpenGL and shaders can be a bit... low-level, which is to be expected. This seems to make that quite a bit nicer? Edit: For example, check out this http://dinomage.com/reference/SDL_gpu/group__ShaderInterface...
Doxygen != documentation, especially in low-comment situations. Tell us more.
Even if there is copious amounts of comments, doxygen is still pretty terrible. Unfortunately there's nothing better for C++. Everything else seems to be more pain in the ass than it is worth.
I looked at the demos and I still fail to see the point of using this over SDL2. SDL2 is already high performance and uses DirectX / OpenGL underneath. What exactly does this library bring to the table?
I think the main feature is being able to easily leverage shaders with a nicer API. Having done a fair bit of SDL over the years, dropping down to pure OpenGL and shaders can be a bit... low-level, which is to be expected. This seems to make that quite a bit nicer? Edit: For example, check out this http://dinomage.com/reference/SDL_gpu/group__ShaderInterface...
I looked at the demos and I still fail to see the point of using this over SDL2. SDL2 is already high performance and uses DirectX / OpenGL underneath. What exactly does this library bring to the table?
Announcing a cool new library, application, or hack by dumping people into a GitHub repo is not what I'd call especially good marketing (to the extent anyone cares, obviously.) This is getting to be a bit of a pet peeve.
Earlier quoted context omitted.
I think the main feature is being able to easily leverage shaders with a nicer API. Having done a fair bit of SDL over the years, dropping down to pure OpenGL and shaders can be a bit... low-level, which is to be expected. This seems to make that quite a bit nicer? Edit: For example, check out this http://dinomage.com/reference/SDL_gpu/group__ShaderInterface...
Is it possible to render textured quads of arbitrary shapes? I'm trying to make a runtime for Spine ( http://esotericsoftware.com/spine-runtimes ) and SDL's inability to do that directly without using OpenGL was the reason I couldn't use it. I don't see a way to do that in Sdl-gpu either - maybe I need to look at the source code.
Earlier quoted context omitted.
Is it possible to render textured quads of arbitrary shapes? I'm trying to make a runtime for Spine ( http://esotericsoftware.com/spine-runtimes ) and SDL's inability to do that directly without using OpenGL was the reason I couldn't use it. I don't see a way to do that in Sdl-gpu either - maybe I need to look at the source code.
If you want to render Spine 3.x models, you'll need to be able to render arbitrary textured triangles so meshes and skewing work correctly. Check out the new Spine TypeScript runtime (spine-ts), which renders via WebGL. Should be trivial to port to OpenGL (ES).