Sdl and ggi?

SDL Development
1

hi there

what are some of the similarities and differences between sdl and ggi?

pete

2

hi there

what are some of the similarities and differences between sdl and ggi?

Well, I’ll respond, but I welcome comments from the GGI team. :slight_smile:

SDL and GGI both do graphics, but SDL is designed more as a cross-platform
framebuffer access library, where GGI is more of a general graphics interface
ahem. :slight_smile:

GGI is designed to be a graphic library interface for Linux, though it
has some targets that work on other UNIX platforms.

GGI supports more interesting display targets, i.e. display onto the
face of a cube, display to AAlib (ascii display), etc.

SDL is a faster, and covers more aspects of multimedia projects
(sounds, threads, etc.)

The SDL graphics system is designed to be a low level framebuffer access
library, while GGI is designed to be a more complete graphics API.

In my experience, with a few exceptions, line and circle drawing are
not very speed critical in games, so they are not supported in SDL.
There are many third-party libraries built on top of SDL that have
their own own line and point drawing routines.

Anyway, I hope that covers most of the similarities, but again, comments
are welcome.

Note, OpenGL is coming soon. :slight_smile:

See ya!
-Sam Lantinga (slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

3

dear all,

The SDL graphics system is designed to be a low level framebuffer access
library, while GGI is designed to be a more complete graphics API.

that makes SDL sound more ‘low level’ than ggi. drawing on the face of a
cube sounds delicious. i searched the web before posting my question, and
here’s what someone had posted on a page:

  • sdl is higher level than ggi
  • development on ggi has slowed to a crawl; sdl is being aggresively
    developed

that was about all i could find on the subject.

In my experience, with a few exceptions, line and circle drawing are
not very speed critical in games, so they are not supported in SDL.
There are many third-party libraries built on top of SDL that have
their own own line and point drawing routines.

cool. can someone throw out some names for me to look into? i’ve been able
to use SDL to do things that i never thought i’d be able to program, but it
would be cool to look into things that make the programming even more
convenient.

pete

4

hi`

Sam Lantinga wrote:

SDL is a faster, and covers more aspects of multimedia projects
(sounds, threads, etc.)

With faster you mean color conversion and RLE blitters, right? That
reminds me, is the GGI impl. that got hacked into SDL during LokiHack
already in the CVS version?

The SDL graphics system is designed to be a low level framebuffer access
library, while GGI is designed to be a more complete graphics API.

And while we are at it: “ClanLib” is designed as a high level all
purpose library :wink: So basically SDL, GGI and ClanLib are usually used
for different tasks. E.g., I wouldn’t use GGI to convert existing games
(SDL is best for this purpose) as it lacks some some basic platform
independent functions and I wouldn’t use it to create a new one from
scratch (that’s what ClanLib aims to help at), but using it as a display
target (like fbdev, x11, directx, openptc, …) is a nice application
for GGI. GGI e.g… is both a display target of ClanLib and SDL (dunno
really for SDL, but I saw CivCTP running on a cube using GGI so I know
it works ;-)).

Note, OpenGL is coming soon. :slight_smile:

How is OpenGL support going to look like? Will you be able to blit to an
OpenGL rendering context? And if yes, how will this be done - by using
OpenGL to blit or by using ‘mixed’ X and OpenGL ‘rendering’ (I am
lacking the right words - hope you get what I mean).–
Daniel Vogel

666 @ http://grafzahl.de

5

Sam Lantinga wrote:

hi there

what are some of the similarities and differences between sdl and ggi?

Well, I’ll respond, but I welcome comments from the GGI team. :slight_smile:

OK....

SDL and GGI both do graphics, but SDL is designed more as a cross-platform
framebuffer access library, where GGI is more of a general graphics interface
ahem. :slight_smile:

GGI is designed to be a graphic library interface for Linux, though it
has some targets that work on other UNIX platforms.

Actually, LibGGI A) Should run on most version of UNIX in existence,

and B) now runs on Win32/DirectX as well. We are trying to make LibGGI
as cross-platform as possible.

GGI supports more interesting display targets, i.e. display onto the
face of a cube, display to AAlib (ascii display), etc.

LibGGI contains a very sophisticated dynamic retargeting system.

LibGGI and its associated LibGGI extension libraries can swap out their
rendering back-ends at runtime, chain together multiple rendering
targets in a generic fashion, and all of this dynamic retargeting can be
controlled automatically via /etc/libggi.conf type files or
programatically with ggiOpen(“display-aalib”), ggiOpen (“display-x”),
etc.

SDL is a faster,

In some areas, SDL is quite a bit faster than LibGGI:

  • PTC helps a lot

  • The SDL code is better optimized in general

    But there are also some areas in which LibGGI is faster:

  • LibGGI’s X target can ‘cheat’ by virtue of the fact that it can make
    use of a LibGGI “helper target” called ‘mansync’. The mansync helper
    can be attached to any target which supports the mansync API, and it
    lets you schedule your flushes based on a timer and the MANSYNC_FPS
    environment variable. I put ‘cheat’ in quotes because if your X display
    refresh rate is 75fps, there’ nothing to be gained by flushing at the
    end of every software frame 200 times a second. Thus, turning down the
    MANSYNC_FPS can greatly increase your effective drawing speed while
    producing no noticeable display glitches. Sam and I spent a while
    during LokiHack trying to figure out why some of the SDL demos ran so
    much faster on SDL-on-GGI as compared with native SDL-on-X, and this was
    the reason.

  • Because of its inherently more modular and flexible design, LibGGI’s
    in-memory working code footprint will be smaller than SDL’s. One of the
    core design goals for LibGGI is to modularize everything to the point
    that no code which is not being used in the current rendering path
    should be resident in memory. This isn’t as big of a deal on good OSes
    like Linux which do demand paging and shared copy-on-write executables,
    but it still helps.

  • LibGGI’s flexible targeting system allows you to implement more
    rendering functionality as targets, rather than extending the API
    itself. For example, to convert from palletized modes to hi/truecolor
    modes (or the reverse), all you need to do is hook the ‘palemu’ or
    ’trueemu’ targets onto the end of the target chain. This allows us to
    keep the core API code small and generalized.

and covers more aspects of multimedia projects
(sounds,

LibGGI does not handle sound at all.

threads, etc.)

We don't handle cross-platform threading (yet), although we do use

pthread mutexes to implement generic cross-platform mutex support.

The SDL graphics system is designed to be a low level framebuffer access
library, while GGI is designed to be a more complete graphics API.

I'd describe GGI as being more abstract than SDL.  SDL takes a much

more here-and-now pragmatic approach to solving the problem of
cross-platform multimedia API abstraction. Although it isn’t exactly
flattering to LibGGI to say this, I’d compare GGI vs. SDL to Linux vs.
the HURD |->. The HURD’s design is much more modern, modular and
’clean’ than Linux’s, but right now you can sure get a lot more done
with Linux |->.

So, both SDL and GGI have their strengths and weaknesses.  This fact is

why I wrote the GGI target for SDL - it provides a way to make use of
the best features of both APIs and shows both APIs where their weak
points are. Hopefully both SDL and GGI will improve as a result.

In my experience, with a few exceptions, line and circle drawing are
not very speed critical in games, so they are not supported in SDL.
There are many third-party libraries built on top of SDL that have
their own own line and point drawing routines.

Anyway, I hope that covers most of the similarities, but again, comments
are welcome.

Note, OpenGL is coming soon. :slight_smile:

GGI alread has this one, in the form of GGIMesa.  GGIMesa is a LibGGI

extension library which more or less provides the same type of minimal
OpenGL-wrapping API as GLX, WGL, FXMesa, etc. I assume that SDL’s
OpenGL support (SDLGL?) will be designed along similar lines.

Jon

6

psalzman at landau.ucdavis.edu wrote:

dear all,

The SDL graphics system is designed to be a low level framebuffer access
library, while GGI is designed to be a more complete graphics API.

that makes SDL sound more ‘low level’ than ggi.

Not really.  I'd say that SDL and GGI are mostly at the same level,

with each having some aspects that are lower- or higher-level than the
other.

drawing on the face of a
cube sounds delicious.

Once Sam and I got SDL-on-GGI to work with Civ:CTP, all I had to do was

run the little cube3d.c demos which comes with LibGGI and link each
face’s ggi_visual context to that of a running GGI program (which
Civ:CTP was at that point). The rendering was dog-slow because all the
3D math was done in software, but a GGIMesa-enhanced cube3d.c which used
hardware rendering would be plenty fast. Something else to write when I
get some free time…

i searched the web before posting my question, and
here’s what someone had posted on a page:

  • sdl is higher level than ggi
  • development on ggi has slowed to a crawl; sdl is being aggresively
    developed
LibGGI 2.0 is in late beta right now, which partially explains why

development has been so slow lately. I personally have been focusing my
development time on KGI, which is the GGI project’s kernel graphics
device driver interface.

Jon

7

Daniel Vogel wrote:

hi`

Sam Lantinga wrote:

SDL is a faster, and covers more aspects of multimedia projects
(sounds, threads, etc.)

With faster you mean color conversion and RLE blitters, right? That
reminds me, is the GGI impl. that got hacked into SDL during LokiHack
already in the CVS version?

Yes, but I'm not yet done updating the GGI target code to work with

some of the changes to SDL that Sam has made since LokiHack. I’m
working on this right now and I should have some patches to Sam soon.

The SDL graphics system is designed to be a low level framebuffer access
library, while GGI is designed to be a more complete graphics API.

And while we are at it: “ClanLib” is designed as a high level all
purpose library :wink: So basically SDL, GGI and ClanLib are usually used
for different tasks. E.g., I wouldn’t use GGI to convert existing games
(SDL is best for this purpose) as it lacks some some basic platform
independent functions and I wouldn’t use it to create a new one from
scratch (that’s what ClanLib aims to help at), but using it as a display
target (like fbdev, x11, directx, openptc, …) is a nice application
for GGI. GGI e.g… is both a display target of ClanLib and SDL (dunno
really for SDL, but I saw CivCTP running on a cube using GGI so I know
it works ;-)).

This is a pretty good description of the current situation.  LibGGI's

cross-platform support will get better as time goes by of course, but
right now SDL has us beat hands down in that department. As for
ClanLib, it is written in C++ while LibGGI is all in C code, and also it
handles a lot of higher-level state which LibGGI doesn’t handle
(networking, sprites, sound).

Jon

8

really for SDL, but I saw CivCTP running on a cube using GGI so I know
it works ;-)).

Got an URL for a screenshot? That sounds cool! :slight_smile:

-bill!