Announcing SDL2_gfx

Hi folks,

I’ve started porting over the popular SDL_gfx library to SDL2 and named
it appropriately SDL2_gfx. It builds on the Renderer infrastructure for
the primitives (lines, circles, etc.) part - the rest (rotozoom,
framerate) is unchanged or has been removed (filters). Some stuff is
also not working quite right yet either (textured polygon) but at least
it does not crash :slight_smile: … so consider this an early Alpha release quite
under development.

Current sources are available via SVN at:

Patches and contributions are welcome.

Thanks,
Andreas

Hi Andreas,

Wouldn’t it be a terrible good idea to reconsider the color format used by SDL_gfx? There are now 2 formats for color: SDL_Color as used by the SDL2 graphics primitives, and Uint32’s for SDL_gfx. In practice this is very inconvenient, and at that, it does not serve a real purpose.

When a designer switches from SDL1.2 to SDL2 he has to modify a lot of code. So maybe now is the best time to give up about backward compatibility issues regarding SDL_gfx. It would be very nice when SDL from now on used one single color format.

wboe

wboe, if I recall correctly (haven’t used SDL_gfx in a while), it’s
possible to cast a SDL_Color into an int like this:

SDL_Color some_colour;

Uint32 same_colour;
same_colour = *(int *)SDL_Colour;

This is possible because SDL_Colour is 4 bytes, each are 8 bits, and there
are 32 bits in an integer, and 8*4=32.
However, I think this casting isn’t ideal because it doesn’t take machine
Endian-ness into account. Andreas/anyone, can you confirm this?

But at the very least, you can use:

Uint32 same_colour SDL_MapRGB http://wiki.libsdl.org/moin.cgi/SDL_MapRGB(
your_pixel_format, some_colour.r, some_colour.g, some_colour.b );

The efficiency isn’t really an issue here, because you also have to
remember that Andreas is trying to maintain some sort of consistency and
backward compatibility to the original SDL_gfx, so it wouldn’t make sense
to switch to SDL_Color.
Recoding some of your app may seem tedious, but by my estimation, it’s
worth it. There are many times that I’ve spent a week of spare time
programming stuff for a project, only to tear it out and recode it with a
library that works differently than I expected. It’s the nature of
programming, I guess (also the nature of bad planning, something I’ve been
known to have).

If you want to make an easy conversion, make a macro/define that you can
easily stitch into your code to convert your SDL_Colour to Uint32 (if
you’re using one consistent pixel format).

That’s all to say that I don’t think this is really in the scope of
SDL2_Gfx, but I’m not a dev on it - just my two cents.

-AlexOn Tue, Sep 11, 2012 at 2:52 AM, wboe <w.boeke at upcmail.nl> wrote:

**
Hi Andreas,

Wouldn’t it be a terrible good idea to reconsider the color format used by
SDL_gfx? There are now 2 formats for color: SDL_Color as used by the SDL2
graphics primitives, and Uint32’s for SDL_gfx. In practice this is very
inconvenient, and at that, it does not serve a real purpose.

When a designer switches from SDL1.2 to SDL2 he has to modify a lot of
code. So maybe now is the best time to give up about backward compatibility
issues regarding SDL_gfx. It would be very nice when SDL from now on used
one single color format.

wboe


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL_gfx uses either a RGBA Uint32 with a fixed format of 0xrrggbbaa, or
4x Uint8 values for r,g,b,a respectively as input to the drawing
functions. This interface was not changed in SDL2_gfx.

Since the render interface for pixels and lines in SDL uses Uint8’s when
setting the color (not SDL_Color), the best format for SDL2_gfx is
actually to pass the 4 r/g/b/a values to the drawing functions as they
can be passed along “as-is” to SDL. Passing a Uint32 requires a
decomposition inside SDL2_gfx.

As for SDL_Color as input, that is a good suggestion. I’ll have a look
to see if this can be added this as a third (or new default) color
interface.On 9/11/2012 6:22 AM, Alex Barry wrote:

wboe, if I recall correctly (haven’t used SDL_gfx in a while), it’s
possible to cast a SDL_Color into an int like this:

SDL_Color some_colour;
Uint32 same_colour;
same_colour = *(int *)SDL_Colour;

This is possible because SDL_Colour is 4 bytes, each are 8 bits, and
there are 32 bits in an integer, and 8*4=32.
However, I think this casting isn’t ideal because it doesn’t take
machine Endian-ness into account. Andreas/anyone, can you confirm this?

But at the very least, you can use:

Uint32 same_colour SDL_MapRGB
<http://wiki.libsdl.org/moin.cgi/SDL_MapRGB%20>(
your_pixel_format, some_colour.r, some_colour.g, some_colour.b );

The efficiency isn’t really an issue here, because you also have to
remember that Andreas is trying to maintain some sort of consistency
and backward compatibility to the original SDL_gfx, so it wouldn’t
make sense to switch to SDL_Color.
Recoding some of your app may seem tedious, but by my estimation, it’s
worth it. There are many times that I’ve spent a week of spare time
programming stuff for a project, only to tear it out and recode it
with a library that works differently than I expected. It’s the
nature of programming, I guess (also the nature of bad planning,
something I’ve been known to have).

If you want to make an easy conversion, make a macro/define that you
can easily stitch into your code to convert your SDL_Colour to Uint32
(if you’re using one consistent pixel format).

That’s all to say that I don’t think this is really in the scope of
SDL2_Gfx, but I’m not a dev on it - just my two cents.

-Alex

On Tue, Sep 11, 2012 at 2:52 AM, wboe <w.boeke at upcmail.nl <mailto:w.boeke at upcmail.nl>> wrote:

Hi Andreas,

Wouldn't it be a terrible good idea to reconsider the color format
used by SDL_gfx? There are now 2 formats for color: SDL_Color as
used by the SDL2 graphics primitives, and Uint32's for SDL_gfx. In
practice this is very inconvenient, and at that, it does not serve
a real purpose.

When a designer switches from SDL1.2 to SDL2 he has to modify a
lot of code. So maybe now is the best time to give up about
backward compatibility issues regarding SDL_gfx. It would be very
nice when SDL from now on used one single color format.

wboe

_______________________________________________
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hi Andreas and MrOzBarry,

I want to answer both of you. Of course it it possible to translate one color format into another, all you have to do is write some functions, or make a double list of the colors that you are going to use. But all this adds to the complexity of a program, and that’s the last thing that a designer needs.

For the same reason it is more convenient to have a color representation constisting of one value, not 3 or 4. Because Sam has choosen SDL_Color for his graphics functions, I think other library writers have no choice!

wboe