SDL2_gfx extensions

SDL Development
41

I’ve never encountered that, and it suggests there is more than one cause. If OpenGL is so variable that one cannot be certain what pixels will be drawn, it is going to be difficult for SDL_RenderDrawLine() to be implemented consistently across platforms.

42

If you want another reference, check out SDL_gpu’s implementation: https://github.com/grimfang4/sdl-gpu/blob/e3d350b325a0e0d0b3007f69ede62313df46c6ef/src/renderer_shapes_GL_common.inl#L317

It uses an incremental circle algorithm that avoids sqrt, sin, and cos in the loop. License is liberal, so if it helps, make SDL_gfx better!

43

Hello! Thank you for your great work @rtrussell

I was wondering if the updates to SDL_RenderDrawLine and recent SDL additions like SDL_RenderGeometry()could lead to some performance optimizations in the SDL2_gfx library and your extensions?

Would be happy to try and contribute to this effort if it seems like there could be performance gains. I’m still new to graphics programming but it seems that RenderGeometry() could prove useful for filled polygons and maybe polygons with border thickness (e.g. Drawing Polylines by Tessellation - CodeProject)

44

Only in the case of the Emscripten/WebAssembly version do I currently take advantage of knowing that SDL_RenderDrawLine() can be trusted to be pixel-perfect:

#ifdef __EMSCRIPTEN__
		result = SDL_RenderDrawLine (renderer, x1, y1, x2, y2) ;
#else
...
#endif

I hadn’t considered that SDL_RenderGeometry() might be useful but it’s an interesting idea.

1 Like
45

I hadn’t considered that SDL_RenderGeometry() might be useful but it’s an interesting idea.

If I can find some time this coming week, I want to take a shot at writing a filled ellipse, filled polygon, and polyline routine using RenderGeometry(). If anyone has recommendations for any open-source triangulation C libraries for arbitrary non-intersecting polygons I’d appreciate it :smiley:

I’m curious if it would outperform the current implementations in some cases.