glob2-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Libraries (was Re: [glob2-devel] Glob2 salvage proposal)


From: Martin Voelkle
Subject: Re: Libraries (was Re: [glob2-devel] Glob2 salvage proposal)
Date: Fri, 28 Oct 2005 14:36:08 +0200

 

One good example is that I'm trying out libboost-filesystem for use in a
few places.  Boost (www.boost.org) is a large collection of well-written
C++ libraries, and the filesystem library allows me to (for example)
iterate over a directory as if it were a standard container.  In the
long-term, I would be very tempted to use this library all over the
code.  How objectionable is this idea, and where should I make a note of
it if it's acceptable?

One way that this does relate to the salvage proposal is rewriting the
interface in QT.  Presumably this means getting rid of SDL for graphics,
but what about the rest of SDL?  Would we want to get rid of SDL
entirely?  If so, does anyone know of another platform-independent
networking library?  I had been looking at socket++
(http://www.linuxhacker.at/socketxx), but I'm now starting to think we'd
need a lower-level API to do the work we want to do.

QT 4 does much more thant graphics: it does also gui, networking, filesystem and much more.
Only its sound support is almost inexistent. For this, we could go GStreamer (c++ bindings of course) or OpenAL. OpenAL is used by popular games like UT2004 (UT2003 too?). GStreamer seems more versatile (standard plugins handle many audio formats like ogg and speex, which reduces audio dependencies to 1), more used (in free software), but less oriented towards games (it probably lacks 3D audio).

Maybe there are OpenAL plugins for GStreamer? This would be really nice, because GStreamer's plumbing is great to handle dynamic composition of multiple sources. Using speex and ogg libraries with OpenAL directly would require us to write the plumbing (which is already there using SDL audio, but dropping more code is always good IMHO).

Martin


reply via email to

[Prev in Thread] Current Thread [Next in Thread]