Sdl-gpu: A library for high-performance, modern 2D graphics with SDL | Hacker News Reader

Sdl-gpu: A library for high-performance, modern 2D graphics with SDL

github.com

119 pointsvmorgulis26 comments

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'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.

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 agree. I think the main purpose is a "2D Accelerated Rendering" replacement that allows for shaders and other custom techniques.

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).

Oh awesome. Thanks Mario!

GPU_TriangleBatch() lets you submit an array of triangle vertex data. That way you can integrate with Spine, librocket, and everything else like that.

Worth noting that the Allegro library also has a shader API:

http://liballeg.org/a5docs/trunk/shader.html

Are you talking about the low level SDL2 API or the simple game API?

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.

Hey, SDL_gpu dev here! :) There's actually a lot that is special about SDL_gpu, but most pertinent are:

* Higher performance (it automatically collects and submits batches instead of separate draw commands for each sprite and redundant state changes)

* Shader API

* Arbitrary geometry rendering (triangles)

* Can be integrated with explicit OpenGL calls

* Full blend state control (not just "ADD", "SUB", "MULT")

* Built-in primitive shapes (points, lines, tris, rects, ellipses, polygons, even arcs)

* Uses a style familiar to SDL 1.2 users that I wish SDL_Renderer had gone with...

* Came out before SDL 2.0 and is compatible with SDL 1.2 and 2.0

* Loads BMP, TGA, and PNG files

* Rotates and scales about the center of images, making reasoning about the resulting corner coordinates more obvious (adjustable via anchor settings)

Hope that helps!

> Rotates and scales about the center of images

You can specify the rotation point in SDL2. Calculating corner coordinates is simple trigonometry.

But the rest seems useful.

Thanks.

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?

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.

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 ;)).

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).

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.

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.

xserver?

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).

Reply on news.ycombinator.com