On Tue, 16 May 2000, Antony Suter wrote:
OK, I guess I gotta respond to this one, being the author and
maintainer of the GGI target for SDL. I've also cc:ed this reply to the
GGI list.
> Currently Berlin uses GGI/GII for input and output. I suggest that an option
> might be to replace the use of these libraries with SDL instead. Perhaps SDL
> can be added as a target alongside GGI/GII so that the pros/cons can easiliy
> be evaluated.
Although I firmly belive that LibGGI and friends are a much better
solution in the long term for Berlin than SDL, I would actually like to
see this as well. We GGI people are firm belivers in the "everyone's
library target everyone elses' libraries and we'll quickly see who comes
top" theory of darwinian software evolution |->.
> http://www.devolution.com/~slouken/SDL/
>
> I think the advantages are:-
> - in addition to video output
GGITV.
> and input device support
LibGII.
> SDL has cross
> platform support for:-
> * sound
It is true that GGI does not handle sound at all currently.
LibGSI does, but despite the name it is not really a LibGGI-family
extension.
> * threads
Why do these need to be API-bound to the graphics/event system?
Use pthreads or glib or something like that for generic threads.
> * timers
Useful. Perhaps a LibGTimer could be written which would target
sources of periodic events (timers) and turn them into ggi_events.
> * endian independance
LibGGI's primitives are fully endian-independent, and we provide
the endianess info in the DirectBuffer stuct as well.
> (* CDROM audio)
Another non-GGI thing.
> - SDL is more up to date.
Please define "more up to date". LibGGI continues to be actively
maintained, and we are actually preparing for a final 2.0 release. Quite
a bit of stuff has been happening recently.
> - SDL seems to be more actively supported.
See above.
> - SDL is multi platform to Linux, MacOS, Windows and BeOS.
GGI does not support MacOS or BeOS yet, but we do support
Win32/DirectX.
> SDL has some support from LokiGames.
FWIW, Jagged Alliance 2 is being ported to Linux based on LibGGI.
> Under Linux, SDL supports both Xwindows and /dev/fb video ouput.
Under Linux, LibGGI supports X, Xlib, DGA, /dev/fb, KGI, Glide,
SVGALib, and many other targets environments.
> SDL already has OpenGL support in place as of version 1.1.
GGIMesa.
> Here is a raw #berlin IRC discussion about SDL pasted with permission of all
> participants.
>
> <ExModem> has there been any thought to coding Berlin to SDL rather than
> GGI?
> <stefan_> no
> <stefan_> at least not for my part. I don't know SDL at all
> <ExModem> it has cross platform support for video (inc opengl), input
> events, sound, threads, timers and endian-ness
> <ExModem> http://www.devolution.com/~slouken/SDL/
> <stefan_> you may discuss this on the mailing lists. You'll get better
> response there
> <graydon> I've played with SDL some, it's ok.
> <graydon> afaik it has no /dev/fb target, so we cannot consider it at the
> moment, but it's worth watching
> <stefan_> how much momentum does it have ? I'm sometimes sick of asking
> questions on GGI without any fruitful answers
> <graydon> oops, yes, sorry, it does have /dev/fb
> <ExModem> it is being updated regularly
> <graydon> SDL is imho better supported than GGI at the moment
Again, define "better supported".
> <stefan_> graydon: hmm, then may be you should reformulate the paragraph on
> the home page :)
> <ExModem> a look thru the introduction pages is very quick and informative
> <stefan_> graydon: and we should abstract the GGI stuff into some device
> layer or something
Go for it.
> <graydon> stefan_: yes, perhaps. might be nice.
> <ExModem> would it be easy to abstract the GGI and GII stuff?
> <stefan_> graydon: and if they already use it for multi media, may be we
> could use their expertise to let a lower level API hook into their API (i.e.
> be a mere wrapper)
> <stefan_> ExModem: that depends on how similar GGI/GII and SDL are
> semantically. I guess it is.
They are quite similar. I wrote the initial SDL/GGI port as part
of my participation in the LokiHack '99 contest, and while I was there I
got to meet and chat with Samn Lantinga, the author of SDL. He said that
LibGGI and LibGII were major sources of inspiration for parts of the SDL
design. He even credits GGI a couple of times in the SDL sources.
> <graydon> there's really only 2 tricky bits: we need to be able to target
> drawing libraries _at_ memory slabs used by SDL, and we need to be able to
> pull a thread out of an event poll in SDL in order to sreshen the screen.
> everything else is quite generic.
> <ExModem> i dont think the thread out of event poll would be a problem
> <graydon> no, SDL has good event handling.
> <graydon> I think both of them will work, I just haven't tried it in a
> while.
It'll work. The question is, will it work as well? I say no.
See below for my explanation.
> <graydon> last time I even considered it, I didn't know about libart, so I
> just gave up.
> <stefan_> graydon: hmm. ok, it seems for the libart DK it would be fine.
> What about the openGL DK ?
> <ExModem> i didnt have much success compiling the last release of berlin.
> ill download the latest snapshot.
> <graydon> there's actually a number of little libraries of various
> complexity build to talk to /dev/fb at this point.. XFB, SDL, OpenGUI..
Right, /dev/fb is the popular one, along with OpenGL.
> <stefan_> ExModem: it has a new build system.
> <ExModem> SDL 1.1 has opengl support built in
> <graydon> yeah, I know
> <stefan_> ExModem: what does this mean ? Some functions to initialize Mesa ?
A small set of 6-10 wrapper functions around the core GL API.
Similar to GGIMesa, GLX, WGL, etc.
> <stefan_> hmm, may be if we add SDL vs. GGI as a compile time option the GGI
> people will wake up :)
Not all of us have as much free time as the people on the Berlin
list appear to. Nevertheless, as I have mentioned before, we have not
been idle lately. I have been luckly enought to be able to work on LibXMI
development as part of some paid work I have been doing recently, and
Marcus has been doing a great job tightening down the last few loose ends
in GGI in preparation for a final 2.0 release. I hardly think we have
been sleeping.
> <ExModem> stefan_, ill have to research that more
> <graydon> stefan_: SDL can actually "target" GGI as a "backend"; somewhat
> ironic given that GGI is supposed to be the one choosing targets..
Like I said, "everyone target everyone else" is a good way to
shake out the good APIs from the bad. Confusing as hell and somthing of a
waste of effort, but....
> <stefan_> ExModem: yeah. You may mail to berlin-drawing or even
> berlin-design to continue this thread. It sounds promizing.
> <graydon> I dunno, we'd have to see how much work it'd take. I'd be curious
> to try tho.
It wouldn't be difficult, but it wouldn't be trivial either. I
would probably be easier and quicker for you to just hack GGI or an
extension to do what you want.
> <stefan_> graydon: yeah, there is so much redundancy
> <ExModem> if graydon and stefan_ dont mind i might post some of this
> discussion into the email
> <stefan_> ExModem: sure
> <graydon> definitely. it'd be nice to have a solution that many people
> already have installed; plus the SDL tree is much smaller and more portable
> than GGI. I've no problem using it if it works and is little effort to
> target.
> <graydon> but I'd want the OpenGL DK to work as well. it's no good to be
> throwing that out.
> <stefan_> graydon: absolutely. What does 'SDL supports openGL' mean ? Is it
> just a question of initializing Mesa to target at the appropriate device ?
> <graydon> not sure. trying to figure that out
> <ExModem> sdl can dynamically load the opengl library
> <stefan_> ExModem: the point is how I am supposed to talk to openGL, once it
> is loaded.
> <stefan_> ExModem: the openGL DrawingKit must be kept agnostic about all
> this, i.e. all it does is using the openGL API.
Again, if you stick to the GGIMesa API, I can give you
GLX/WGL/SDL-GL/whatever targets transparently and it is easy to not worry
about the details of platform-specific GL in Berlin.
And now my list of reasons why Berlin should choose GGI over SDL:
#1: SDL's design, while similar to and in many ways inspired by LibGGI's
design, is different in one fundamental way: first and foremost, it is a
gaming library. Its purpose is to make it easy for Loki to port Windows
games to Linux. This is why you see CDROM, music/sound, threads, timers,
GL and regular 2D graphics in one library. The most immediately obvious
consequence of this specializing design requirement is...
#2: SDL does not have extensions or dynamic targeting. LibGGI is built
around these concepts, and they make a powerful difference in the ease
with which users of the GGI library system can extend the system to meet
their own needs, without requiring a global API rev. This also means that
the solutions chosen can be as general-purpose or application-specific as
desired, because all users of the API aren't going to have to be burdened
with them. Good examples of this are...
#3: LibGWT. While SDL has only a simple set of window-mapper API
functions which let it control windowing when run in a GUI environment
like X or win32 (equivalent to GGI's LibWMH extension), LibGWT is a full
region (viewport) management library with region subclassing and event
routing, and per-visual window encapsulation and window-to-viewport
mapping. In other words, full region management a la X. LibGWT is the
viewports library I have mentioned to Berlin folks before. Its job will
be made a lot easier in the graphics department by...
#4: LibXMI. This is a GGI-aware port of the GNU LibXMI, which is used
primarily by the GNU plotutils package. XMI is based on the Xlib
primitives, and a such supports arcs and polygons, with stippling/dashing
etc etc. XMI also supports texel LUTs as well as per-pixel multisource
ROP for alpha/stencil/logic_op/etc lookups.
========
I don't think you'll see any of that stuff show up in SDL any time
soon, and a lot of it would be very useful to Berlin, too. Think it over.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
