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?
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).
I've used this library before. It is really good. The biggest difference that I can point out is that you can use shaders with SDL-gpu. Also - it plays nicely with the standard SDL2 lib.
And is there any way to see the demos or at least some screenshots without spending all night trying to get CMake working under Windows?
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.
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.
I've found SFML to be quite inefficient if you use it naively (e.g. by using their built-in render target implementation or by creating a lot of sf::Sprite objects). There's no batching and they reset the current shader after every draw call so it never lazily sets it which can cause performance problems on some drivers. They set a LOT of OpenGL state unnecessarily. It's okay for prototyping things or if you really don't care but if you want to do things efficiently you need to start pulling it apart (or just go straight to OpenGL).
There's always CSFML, an official binding of C to SFML. I don't know C++.
I am finding C to be a break from all of the new PLs I've been playing with. A sort of return to basics for me. It was my first language (well, after BASIC ;)).
Making a library nobody uses is even a bigger pain in the ass than spending considerable time writing proper documentation. For software developer documentation is a large part of the developer experience. Without it, a large portion of potential users will switch to a less optimal but well documented solution. Documentation matters.
I've never met a computer where 2D graphics were faster with a GPU. (Try benchmarking and see for yourself. 2D graphics is mostly blitting pixels, where a GPU will only slow things down.)
I might agree or disagree depending on the details.
Lower latency? Yeah, CPU wins easily.
4k resolution 2D composition? Well, GPU is pretty likely to win this one...
CPU has pretty low latency, easily better than what GPU can achieve. But on the other hand GPU has insane bandwidth, high degree of parallelism and hardware ROPs.
It's really going to depend on what you're doing with the graphics. As soon as you start emulating basic shaders for effects on the CPU by comparing and writing to a screens worth of pixels you'll see where the bottleneck ends up.
On the other hand if you're wanting to make something with the graphical complication of Mario or Mega Man ( purely sprites - no effects - lighting and other things maybe done with alpha blending ) then you might find it makes sense to stick to working with the CPU.
Ever tried rotating and scaling dozens of high-def sprites per frame in software (CPU)? Not good. Plenty of games can benefit from that ability.
Besides that, you can render so many more sprites if you properly batch them. I could get maybe a few hundred identical particles going around 60 fps with software rendering. With the GPU, you can make particle systems with thousands of sprites (or tens of thousands with a GPU newer than 2012).
What exactly does this library bring to the table?