Hi, I just wonder if there is any possibility to develop SDL_gfx further? Or is there any other SDL library that is better than gfx when it comes to drawing shapes (lines, polygons, etc.) and rotating/zooming images? Because I’ve tried SDL_gfx, and I’m not especially impressed by it. We used it in a school project to perform image down-sampling and rotations, and drawing lines.
What bugs me with the library is that it claims to use anti-aliasing for resizing/rotating images; that however only seem to be true for up-sampling (since it uses interpolation), not for down-sampling. For the latter to be anti-aliased, sampling of multiple pixels from the source image for each pixel in the destination image is required in some form, either if it is done at the moment when the image is being down-sampled, or if a blurred version of the source image is kept in memory (blurring requires sampling of pixels in a surrounding area). The latter can be good if a series of combined down-samplings and rotations of the same image are going to perform, using the same scale factor but different angles. The blurring radius should be inverted proportional to the scale factor. Then you pick out either interpolated pixels values or pixels directly (depends on the degree of blurring) from the blurred image when the actual down-sampling/rotation is carried out.
Then about the shapes, I’ve only tried the line function out. What I don’t like about this is that all lines seem to have the width 1. No double values for start and end values for the lines can be given, only integer values. From what I have seen of the rest of the functions, no anti-aliased shapes can be filled and vice verse.
Otherwise SDL_gfx fulfilled the purpose quite well. It saved us time which we didn’t have to write own code to do the same things (but better).
SDL_gfx is best suited to applications which use SDL for most drawing
but need to draw a few lines or shapes or rotated images. If your
application makes use of these excessively or exclusively, OpenGL
would probably be better.On Sun, Dec 13, 2009 at 12:13 PM, TriKri wrote:
Hi, I just wonder if there is any possibility to develop SDL_gfx further? Or
is there any other SDL library that is better than gfx when it comes to
drawing shapes (lines, polygons, etc.) and rotating/zooming images?
It’s not a part of SDL proper, but it is very popular. To contribute
to that project, you’d have to send patches or communicate directly
with Andreas (email address is found on the official site, above).
Have you looked at the source code yet? If your patches represent
significant improvements in line with the goal of the project, I’d
expect them to see release pretty quickly.
Another project that you might consider is Sprig (I’m the maintainer,
of course), though it has some similar design to SDL_gfx: http://code.bluedinosaurs.com/SPriG.html
If you’re interested in advanced features without using OpenGL, then
you might want Anti-grain Geometry: http://www.antigrain.com/
Good luck,
Jonny DOn Sun, Dec 13, 2009 at 10:01 AM, Brian Barrett <brian.ripoff at gmail.com> wrote:
SDL_gfx is best suited to applications which use SDL for most drawing
but need to draw a few lines or shapes or rotated images. If your
application makes use of these excessively or exclusively, OpenGL
would probably be better.
On Sun, Dec 13, 2009 at 12:13 PM, TriKri wrote:
Hi, I just wonder if there is any possibility to develop SDL_gfx further? Or
is there any other SDL library that is better than gfx when it comes to
drawing shapes (lines, polygons, etc.) and rotating/zooming images?
I haven’t looked at the source code, and yiu’re right, I don’t really know what the goal with SDL_gfx is. I thought it was a project which many people have been invonled in, but apparently it was made by only one person. It feels like I don’t want to mind his business. There seem to be a lot of projects out there, hm, hard to choose.
I haven’t looked at the source code, and you’re right, I don’t really know what the goal with SDL_gfx is. I thought it was a project which many people have been involved in, but apparently it was made by only one person. I kind of feel like I don’t want to mind his business. There seem to be a few libraries out there, next time I might consider one of them. Hm…
Jonny: Your project seems interesting, does your scaling functions use sampling from surrounding pixels when down-sampling? How is up-sampling performed? Can your polygons be filled and in that case how do you check if a pixel is inside of the polygon? Do you divide the polygon (if it is a complex one) into smaller, convex polygons for easier anti-aliased drawing?
Anti-Grain Geometry also looks interesting, very nice layout on the page, and I like the fact that it can draw vector graphics.
Then I wonder what the main purpose is with SDL? Is it to provide a minimalistic set of functions with which one easily can write platform independent graphic functions without having to write special code for different systems?
On the other hand, SDL_gfx is a SDL add-on library (since it starts with SDL I guess), and has a great advantage because of its name, which SDL could and should make use of. In other words, it lies within the interest of SDL to develop SDL_gfx further. I mean, if someone decides to develop some better SDL graphics library, what should that library be called? SDL_gfx is already taken, but that is one of the first things you will come to think of. Is there any other suitable name for such a library? The name should be descriptive, and if SDL_gfx is the best describing name for such a library, that library should probably be further developed.
I see a few options here, what do you think the best thing is to do:
To develop the SDL_gfx library further, to extend it and make it better?
To create a new, better library with a different (SDL_*) name?
To re-create each part of the library as separate SDL add-on libraries?
I didn’t write the scaling or polygon code in Sprig (and I have finals
this week), so it might be a while before I can answer your questions
about that.
I think out of your suggested options, the first one is best. Talk to
Andreas or just send him a patch for any features that you come up
with. If they’re not accepted or they have wider usage, then you
might consider making a new library.
Sometimes the SDL_* names are a little troublesome, but if the
delineation is clear on wikis everywhere, we shouldn’t have too much
of a problem. I’m always interested in help improving Sprig, too. If
you’d like to contribute, check out the source: http://code.google.com/p/sprig/
Jonny DOn Mon, Dec 14, 2009 at 8:33 PM, TriKri wrote:
On the other hand, SDL_gfx is a SDL add-on library (since it starts with SDL
I guess), and has a great advantage because of its name, which SDL could and
should make use of. In other words, it lies within the interest of SDL to
develop SDL_gfx further. I mean, if someone decides to develop some better
SDL graphics library, what should that library be called? SDL_gfx is already
taken, but that is one of the first things you will come to think of. Is
there any other suitable name for such a library? The name should be
descriptive, and if SDL_gfx is the best describing name for such a library,
that library should probably be further developed.
I see a few options here, what do you think the best thing is to do:
To develop the SDL_gfx library further, to extend it and make it better?
To create a new, better library with a different (SDL_*) name?
To re-create each part of the library as separate SDL add-on libraries?