On Mon, 4 Jun 2007, Toby Collett wrote:
> Geoffrey Biggs wrote:
>> I'm in favour of not needing to depend on SDL for the player core if at
>> all possible. It may provide portability (and do so very well), but less
>> dependancies is usually better if you don't need that much from the
>> library.
>>
>> As I mentioned earlier, and as Toby said, portable sockets is not that
>> hard to write. Toby is correct in that there is only some extra
>> initialisation for Windows and then they behave the same. Going back to
>> the very first post, other problems mentioned were the need for an XDR
>> library (SDL won't help us here), endian-related issues (hton* and ntoh*
>> seem to do the job just fine, and it wouldn't be hard to write functions
>> to do other primitive data types, of which there are a very limited
>> number). The timer is easy enough to abstract away and Windows does
>> have a high-resolution timer available as part of the Win32 API.
>> Threading is a bit more difficult, but I have twice in the past written
>> threading systems that work on both Windows and Linux; the calls are
>> named differently but the fundamentals are the same.
>>
> There is a pthreads port for windows, it has worked fine for me in the
> past. If we are distributing windows binaries then less people will need
> to build from scratch anyway, making it easy to build against player
> rather than player itself should be the focus (and maybe some automated
> nightly builds?)
I must admit, that personally I don't like Windows. I've choosen SDL as
cross-platform library not only for making Windows binaries but also to
make Player (and Stage) work with things like AmigaOS, BeOS, MorphOS and
so on. From the other hand, as someone mentioned before, people with
wallets use Windows and authorities of PJIIT (where I'm maintaining
Virtual Robotics Laboratory) are examples of them - I must have at least
Player client libraries and application for Windows to prove them that
Virual Laboratory works fine - that was the primary reason for creating
playerlibsdl.
SDL does not suggest in any way how application should be written. It can
use SDL just for networking, threads, timing, plugins loading
(SDL_loadso) while GUI still can use gtk/glib pair, Qt or even GLUT (or
Highgui from OpenCV). I was also wondering about using SDL for GUI "by the
way" (if we're using SDL for low-level issues, why can't we use it for
GUI?). There is actually demo GUI library for SDL called GUIlib, but in my
opinion it's too simple. Once xfig code was used to create librtk2, why
can't we get SDL GUI from other open-source SDL-based project? Many SDL
games have nice GUI, most promissing is the one used in openttd project
(imagine Stage and Playerv looking like that!).
SDL does not limit programmer to use any specific language. Of course,
people who loves C++ libraries that provide namespaces will not be
satisfied (as SDLmm project seem to be dead back in 2001), but for those
who have nothing about using C style calls in C++ code it's a good
solution.
So while thinking about portable Player we shouldn't focus only on BSD
sockets replacement (or coexistance with winsock by separating both with
#ifdef WIN32), but also:
- threads (is pthread for windows good enough, is pthread on rtos like
QNX or systems like AmigaOS available? From the other hand, is thread
model in SDL_threads good enough? Or maybe let's use thread available in
C++ STL templates, looks like there are headers for them in MinGW, which
does not provide any other thread models when installed from scratch)
- timing (if code must be portable, forget about using usleep, nanosleep,
even gettimeofday may be problematic)
- dynamic structures (glib is used for lists, STL templates can be used
instead in C++ code)
- plugin loading (different systems do this different ways, SDL_loadso
seem to be solution)
- hardware access (well, SDL is not a solution here! We can access audio
and joystick "by the way", just because we're using SDL). I guess the main
reason for running Player (as a Server this time) on Windows is the
ability to start Stage simulation (during the classes for example when
all the machines in the classroom are Windows PC's). Of course someone can
make Video For Windows driver for camera devices or prepare smart way to
avoid usage of termios.h, but these are sounds of the future. BTW, Player
uses OpenCV for some drivers, while OpenCV can have access both to
Video4Linux and Video For Windows cameras, why can't we rewrite camera
driver to make use of it?
- required libraries. Today these are: boost, glib2, gtk2 (with
companions like pango, atk, cairo and so on), libgnomecanvas2 (used only
if available), libjpeg, zlib, gsl, OpenCV. Last two are used only for some
drivers and there are ports of both for different systems. Zlib and
libjpeg are as common as we may not be worry about them. glib/gtk2 are
also available on many different systems, but we may drop them if we feel
that less dependencies is better (we can use SDL-based gui as I mentioned
above). I don't know much about boost, why it is used (for threads I
guess), what systems support it and so on.
- endianess (for example in libplayerxdr), SDL seem to be the best
solution for it, but also glib/gtk and other cross-platform libraries
provide means to deal with endians. Keep in mind, that to have portable
Player code we can't rely on glibc rpc/xdr, we must have our own
implementation that does the same thing!
Cheers,
Paul
|