Live data from Hacker News

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

github.com

21–27 of 27 posts

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

#21

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.

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

#22

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

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.

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

#24
post #2

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?

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!

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

#25
post #4

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.

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

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

#26

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

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

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

#27
post #2

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?

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…

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

Post reply on HN