Some clarification of various bits follows:-
For SDL using OpenGL, essentially SDL opens the window for you and then you
make standard OpenGL calls. I have an example of this compiled and running
on my system.
"Jon M. Taylor" wrote:
>
> On Tue, 16 May 2000, Antony Suter wrote:
>
> > - in addition to video output
>
> GGITV.
Sorry, I meant normal raster buffer output to your computer monitor.
> > * 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.
Im not sure how cross platform pthreads or glib is.
> > 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.
My list wasn't exclusive and purposefully left out the many options
available on each platform.
> > SDL already has OpenGL support in place as of version 1.1.
>
> GGIMesa.
The SDL OpenGL support uses your existing OpenGL libraries (using OpenGL
hardware if you have it setup), but has its own SDL window open function to
use so that SDL knows about the window.
> 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,
Its design purpose doesnt make it a bad choice for possible use in Berlin.
Its addition of cross platform support for sound, threads and timers are
good things for future needs of Berlin.
> #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
Dynamic targeting? I dont fully understand what you mean. SDL has a range of
output options on each supported platform. I don't know if you can select
between them at run time.
> #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
This would almost irrelevant to Berlin, as Berlins goal is to do all this in
new ways. It is one of Berlin's research areas.
> #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.
Again this is irrelevant to Berlin for the same reasons.
> 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.
Berlin is a ground up new design and is a research platform so I disagree.
--
- Antony Suter ([EMAIL PROTECTED]) 'Rohaan the Examiner'
- "And how do you store the nuclear equivalent of the universal solvent?."
