SDL-based implementation of player libraries

[Paul Osmialowski]

Hi all,

Some time ago I've proposed at playerstage-users that Player/Stage should
be built on SDL/SDL_net to make it more portable. It was some time after
I've ported libplayerc (1.6.5), playerv and videoplayer to MinGW. At that
time, the only problem i had to resolve was sockets usage (BSD vs
Winsock). Then new Player was released. This time porting became much
harder due to usage of xdr serialization. I had to write my own
implementation based on glibc code with usage of SDL endian-related
functions. Also I used SDL_net to replace BSD sockets in libplayerc.
Finally I've extracted these libraries from Player tree:
- libplayerxdr
- libplayerjpeg
- libplayerc
- rtk2
Then I tried to compile playerv and videoplayer using these libraries for
both Linux and Windows (using MinGW crosscompiler to build Windows
binaries). It wasn't easy, due to some nonportable nasties in Player code.
In my opinion, Player code should be cleaned a bit in some future. Some
noticable flaws are:
1. Usage of different naming styles for integer types (ie u_char, u_int,
uint, u_long and so on instead of uint8_t, uint32_t and so on). I suggest
to use only one naming style, the one proposed by stdint.h (or
SDL_types.h, but it may be not that nice). No other styles are available
in MinGW, and I guess there are more development enviroments that would
suffer from that.
2. No return values in some int-type functions - it causes a warning only,
but it looks ugly anyway.
3. Some others I don't remember now

My SDL port has unfortunately some caveats too:
1. I didn't know what to do with ___FLOAT_WORD_ORDER in XDR serialization,
finally I've set it to SDL_BYTEORDER in replace/endian.h and it should
work for most popular CPU's, but users of exotic architectures should be
warned that it may not work properly.
2. It still depends on things that may not be 100% portable, but I guess
they're available *almost* everywhere. These are:
- gettimeofday() from sys/time.h
- stdint.h (yep, SDL offers SDL_types.h instead)
- sys/param.h (for PATH_MAX only, I guess)
- limits.h (for *_MAX, LASTUNSIGNED and so on, I guess)
- zlib
- libjpeg
- g_usleep from glib in client programs (normally it was nanosleep() which
seem to be the safest sleep function in the world, unfortunately not
available on MinGW, Solaris and some other systems).
Probably SDL offers sufficient replacement for these things, but I didn't
feel that it's necessery to work them out.
Whole source tree (with Windows DLL's included) is available here:
http://king.net.pl/playercontrib/SDL
it contains Makefiles that I've prepared.
I also have crosscompilation MinGW tree for x86 Linux suitable to unpack
in user's home directory, but it's 38MB big .bz2 image so I don't have any
suitable place to publish it. It contains SDL, SDL_net, SDL GUIlib, glib2,
gtk2, zlib, libjpeg, pango, atk, cairo, expat, fontconfig, fteetype,
gettext, lcms, libart, libexif, libpng, libiconv, tiff, xpm_nox and
libxml2.

I hope someone will make use of my job. I guess it may be the very first
step to SDL-based Player which would be the most portable robotic
software. SDL would cover topics like networking, endianness, threads,
types convention, shared libraries loading and very limited access to the
hardware (audio and joystick for now, other hardware access would be still
system-dependent). This woluld lead to native Player (and Stage!)
compilation for sysyems like M$ Windows (many of the students here hate
Cygwin, that makes Player hard to use during the classes!). I guess it
won't be an easy task since Player uses more libraries that may cause
portability problems: gsl, boost (wasn't good old C++ with good old STL
enough?), opencv, libgnomecanvas and so on.

Cheers,
Paul

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[Reed Hedges]

SDL might be a good overall solution but there are other options for some of the

Post by Paul Osmialowski
At that
time, the only problem i had to resolve was sockets usage (BSD vs
Winsock). Then new Player was released. This time porting became much
harder due to usage of xdr serialization. I had to write my own
implementation based on glibc code with usage of SDL endian-related
functions. Also I used SDL_net to replace BSD sockets in libplayerc.

I've never had major problems using sockets in general on MinGW using winsock2
(there are several variants on the winsock lib I think, I link to libws2_32.)
Never tried building Player though. What about XDR makes it harder?

Post by Paul Osmialowski
- gettimeofday() from sys/time.h

Here's a replacement for MinGW, can be substituted using autoconf. There's a
more accurate time function available in the Windows SDK winmm.lib library, but
you might need Visual C installed to get that library.


#include "replace.h"

#if HAVE_SYS_TIMEB_H
#include <sys/timeb.h>
#else
#error gettimeofday replacement needs sys/timeb.h
#endif

/* Sets tv with seconds and microseconds, but microseconds only
has milisecond accuracy on windows. Timezone is not set
but it's deprecated and nobody uses it anymore.
*/
int gettimeofday(struct timeval* tv, struct timezone* tz)
{
#if HAVE__FTIME // from autoconf check for the _ftime function
struct _timeb timebuff;
_ftime(&timebuff);
tv->tv_sec = timebuff.time;
tv->tv_usec = (timebuff.millitm) * 1000.0;
return 0;
#else
#error The replacement for gettimeofday() needs the windows _ftime function
#endif
}

Post by Paul Osmialowski
- stdint.h (yep, SDL offers SDL_types.h instead)
- sys/param.h (for PATH_MAX only, I guess)
- limits.h (for *_MAX, LASTUNSIGNED and so on, I guess)
- zlib

This is small and could be included with the player source.
Or you can get it here: http://www.gimp.org/~tml/gimp/win32/

Post by Paul Osmialowski
- libjpeg

Also available at http://www.gimp.org/~tml/gimp/win32/

Post by Paul Osmialowski
- g_usleep from glib in client programs (normally it was nanosleep() which
seem to be the safest sleep function in the world, unfortunately not
available on MinGW, Solaris and some other systems).

I use this on Windows. Like gettimeofday, not as accurate, but it's fine if it
doesn't matter exactly how long you need to sleep for.


/* A *much* less accurate version of usleep. It may only have accuracy of a few
hundred ms. */
int usleep(unsigned long usec)
{
#ifdef HAVE_WIN32_SLEEP // from autoconf check for Sleep() function
# warning using Win32 Sleep() function.
Sleep(usec/1000.0);
#else
# ifdef HAVE__SLEEP // from autoconf check for _sleep() function.
# warning Using private Win32 _sleep function.
_sleep(usec / 1000.0);
# else
# error the usleep() replacement requires the Windows _sleep() or Sleep()
function!
# endif
#endif
}



Reed

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[Paul Osmialowski]

Post by Reed Hedges
SDL might be a good overall solution but there are other options for some of the

Well I did't say to add another dependency, rather to use SDL in order to
remove (some) other dependencies.

Post by Reed Hedges

Post by Paul Osmialowski
- g_usleep from glib in client programs (normally it was nanosleep() which
seem to be the safest sleep function in the world, unfortunately not
available on MinGW, Solaris and some other systems).

I use this on Windows. Like gettimeofday, not as accurate, but it's fine if it
doesn't matter exactly how long you need to sleep for.

Again, my point is that there are several replacements for free-world
functions in MinGW, but we wouldn't have problems like this one (with
g_usleep) if we only rewrite whole thing using SDL (which itself also
offers portable sleeping function). We could gain one code for all
systems.

Paul

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[Paul Osmialowski]

Post by Reed Hedges
I've never had major problems using sockets in general on MinGW using winsock2
(there are several variants on the winsock lib I think, I link to libws2_32.)

Yup, neither me, but this time I wanted to prepare source code that
compiles everywhere. My happy users now have client library that does not
need whole Player to be installed and compiles everywhere.

Post by Reed Hedges
Never tried building Player though. What about XDR makes it harder?

The bigest one: There's no sunrpc (and therefore XDR) for MinGW! I had to
rewrite it myself using as much of the code taken from glibc sources as
possible.

Thanks for function replacements code!

Paul

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[Brian Gerkey]

Post by Paul Osmialowski
Also I used SDL_net to replace BSD sockets in libplayerc.
- libplayerxdr
- libplayerjpeg
- libplayerc
- rtk2
Then I tried to compile playerv and videoplayer using these
libraries for
both Linux and Windows (using MinGW crosscompiler to build Windows
binaries).

hi Paul,

I just tested and was able to build your SDL-based player package on
Mac OS X, as well (with a couple of Makefile changes). This sounds
promising, and I'm interested to learn more about SDL.

I'll look into the changes that you made and see what we can do with it.

brian.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[Paul Osmialowski]

Post by Brian Gerkey

Post by Paul Osmialowski
Also I used SDL_net to replace BSD sockets in libplayerc.
- libplayerxdr
- libplayerjpeg
- libplayerc
- rtk2
Then I tried to compile playerv and videoplayer using these
libraries for
both Linux and Windows (using MinGW crosscompiler to build Windows
binaries).

hi Paul,
I just tested and was able to build your SDL-based player package on
Mac OS X, as well (with a couple of Makefile changes). This sounds
promising, and I'm interested to learn more about SDL.

hi Brian,

Well, Makefiles are the weakest part of it, as autotools should be used
for it.

Finally I've found a good place for my
MinGW+glib2+gtk2+SDL+SDL_net+SDL_GUIlib crosscompilation image. It is
here: http://vlab.pjwstk.edu.pl/~vlabdemo/mingw/mingw-xgcc-20070517.tar.bz2
It was built on FC6 so I'm not sure if it's able to work on older
Linuxes. This image should be unpacked into user's home directory.

Cheers,
Paul

Post by Brian Gerkey
I'll look into the changes that you made and see what we can do with it.
brian.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Playerstage-developers mailing list
https://lists.sourceforge.net/lists/listinfo/playerstage-developers

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[Richard vaughan]

I too, am looking at SDL. It looks like it might help with my plans
for Stage-3.0. This would *require* Player to build as an SDL app
(using the SDL runtime requires replacing the main() function).
Having looked at SDL today, and Paul's summary email (but not yet his
code), this is something I'd like to look into more.

Any comments from anyone with SDL experience?

Richard/

Post by Brian Gerkey

Post by Paul Osmialowski
Also I used SDL_net to replace BSD sockets in libplayerc.
- libplayerxdr
- libplayerjpeg
- libplayerc
- rtk2
Then I tried to compile playerv and videoplayer using these
libraries for
both Linux and Windows (using MinGW crosscompiler to build Windows
binaries).

hi Paul,
I just tested and was able to build your SDL-based player package on
Mac OS X, as well (with a couple of Makefile changes). This sounds
promising, and I'm interested to learn more about SDL.
I'll look into the changes that you made and see what we can do with it.
brian.
----------------------------------------------------------------------
---
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Playerstage-developers mailing list
https://lists.sourceforge.net/lists/listinfo/playerstage-developers

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[Sidney Cadot]

Hi Richard

Post by Richard vaughan
I too, am looking at SDL. It looks like it might help with my plans
for Stage-3.0.

Did you consider porting Stage to Qt instead?

Cheerio,

Sidney



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[Paul Osmialowski]

Post by Sidney Cadot
Hi Richard

Post by Richard vaughan
I too, am looking at SDL. It looks like it might help with my plans
for Stage-3.0.

Did you consider porting Stage to Qt instead?
Cheerio,
Sidney

Isn't Qt too heavy? If Stage is still considered to be plugin for Player
we must remember that Player itself must be fully scalable (so it should
be able to run on full-blown PC as well as on low-memory PDA's even if
they don't run Qtopia). SDL is known to work everywhere (people play
SDL games on their PDA's) and it doesn't seem to be that heavy. I would
rather drop glib/gtk dependency and use SDL-based GUI similar to those
used in openttd project (http://www.openttd.org/screens.php) and prepare
librtk3 that make use of it. Also I would like to suggest not to use
dynamic containers from glib in C++ code and use those offered by STL
templates instead. I guess all C++ compilers nowadays provide STL headers.

Cheers,
Paul

Post by Sidney Cadot
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Playerstage-developers mailing list
https://lists.sourceforge.net/lists/listinfo/playerstage-developers

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[Sidney Cadot]

Post by Paul Osmialowski

Post by Sidney Cadot
Did you consider porting Stage to Qt instead?
Cheerio,
Sidney

Isn't Qt too heavy?

That depends on what you mean by "heavy". And "too". ;-)

Post by Paul Osmialowski
If Stage is still considered to be plugin for
Player we must remember that Player itself must be fully scalable (so it
should be able to run on full-blown PC as well as on low-memory PDA's even

if

Post by Paul Osmialowski
they don't run Qtopia).

I don't see why this would be desirable. I do not see how running Stage
simulations on a PDA could be useful in the real world. (though it would be
cute).

The real advantage of a Qt version would be that you'd have a good-looking
version running on the Unix, Mac, and Windows versions, without going via
non-native X emulation on the Mac/Windows platforms. Plus (important, IMHO:)
Qt is a joy to program in.

On a related note: I do not personally consider it such great idea that the
simulator is a 'player' plugin - quite the contrary. If Stage is going to be
redesigned anyway, I would advocate to separate it further from the "player"
app; basically, to have it as a fully independent application. I am
interested to discuss the merits of both approaches, and I think that would
be a clever thing to do before embarking on a redesign.

The main problem with the current approach is that most GUI frameworks
assume responsibility for the main event loop. This is conflicts deeply with
the current setup where "player" is in charge of the main thread.

Cheerio, Sidney



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[Paul Osmialowski]

Post by Sidney Cadot

Post by Paul Osmialowski

Post by Sidney Cadot
Did you consider porting Stage to Qt instead?
Cheerio,
Sidney

Isn't Qt too heavy?

That depends on what you mean by "heavy". And "too". ;-)

Post by Paul Osmialowski
If Stage is still considered to be plugin for
Player we must remember that Player itself must be fully scalable (so it
should be able to run on full-blown PC as well as on low-memory PDA's even

if

Post by Paul Osmialowski
they don't run Qtopia).

I don't see why this would be desirable. I do not see how running Stage
simulations on a PDA could be useful in the real world. (though it would be
cute).

I didn't mean that Stage should be able to work on PDA's (however, it
would be nice to have this), I only remarked that currently Stage needs
Player and Player should be able to run everywhere. Personally I don't see
nothing wrong in Stage being Player's plugin. Also I think it would be
desirable to have possibility of running Stage simulation plugin with no
visual output (for example, deliberative planners may use Stage simulation
to test proposed plan before execution on the real devices, there's no
need to have GUI companion during this). SDL may be helpful also in this
case, since there's no need to initialize all subsystems in main()
function, they can be initialized as they're needed (for example, Video
subsystem would be initialized only when Stage with GUI is used,
otherwise, Player as an SDL app is still capable to be started in remote
shell session).

Post by Sidney Cadot
The real advantage of a Qt version would be that you'd have a good-looking
version running on the Unix, Mac, and Windows versions, without going via
non-native X emulation on the Mac/Windows platforms. Plus (important, IMHO:)
Qt is a joy to program in.

I don't know how it is done on MacOSX or things like Photon/QNX, but on
Windows SDL doesn't use X emulation. No Cygwin is needed for that either.

Post by Sidney Cadot
On a related note: I do not personally consider it such great idea that the
simulator is a 'player' plugin - quite the contrary. If Stage is going to be
redesigned anyway, I would advocate to separate it further from the "player"
app; basically, to have it as a fully independent application. I am
interested to discuss the merits of both approaches, and I think that would
be a clever thing to do before embarking on a redesign.
The main problem with the current approach is that most GUI frameworks
assume responsibility for the main event loop. This is conflicts deeply with
the current setup where "player" is in charge of the main thread.
Cheerio, Sidney
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Playerstage-developers mailing list
https://lists.sourceforge.net/lists/listinfo/playerstage-developers

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[Sidney Cadot]

Hi,

Post by Paul Osmialowski
I didn't mean that Stage should be able to work on PDA's (however, it
would be nice to have this), I only remarked that currently Stage needs
Player and Player should be able to run everywhere.

Ok. I agree that having 'player' run on lowly systems is a must (after all,
it also has to run on embedded robot controllers), but the ability to use a
'simulation' plugin on such systems is more a nice-to-have than anything
else.

Post by Paul Osmialowski
Personally I don't see nothing wrong in Stage being Player's plugin.

At least in the current design of Stage, there is not a proper distinction
between the "model" part of Stage (i.e., the simulator proper) and the
"view/controller" part (i.e., the GUI).

In a proper design, having the "model" part as a Player plugin is an option
(although I see serious issues there, too), however IMHO the
"view/controller" part should _definitely_ not be inside a plugin. All GUI
frameworks that I am aware of want control of the main event loop, and this
clashes bigtime with a gui-as-a-plugin player (because 'player' wants the
same control of the event loop).

Post by Paul Osmialowski
Also I think it would be desirable to have possibility of running Stage

simulation plugin with

Post by Paul Osmialowski
no visual output (for example, deliberative planners may use Stage

simulation.

Post by Paul Osmialowski
to test proposed plan before execution on the real devices, there's no
need to have GUI companion during this).

While this is definitely an interesting application, I can only see this
work if there is an API to instantiate a "simulation" instance at runtime
(by a player client) -- if only for the simple reason that the timeline of
speculative execution is different from the timeline of the "real world".

This is a different discussion altogether from the GUI framework selection,
though.

Post by Paul Osmialowski
SDL may be helpful also in this
case, since there's no need to initialize all subsystems in main()
function, they can be initialized as they're needed (for example, Video
subsystem would be initialized only when Stage with GUI is used,
otherwise, Player as an SDL app is still capable to be started in
remote shell session).

I figure that this is not a unique feature of SDL.

Realistically, I think there are four contenders that could offer a
cross-platform GUI framework:

(1) wxWidgets: not my favorite by any stretch of the imagination, but it has
a BSD license. I have some experience with it and on the whole, I think it
is rather bad. The code base and programming model are messy.

(2) Qt: my personal favorite. It has commercial-grade documentation and
quality assurance, but it is basically GPL (which may be a bit of a problem,
although for Player/Stage it seems a good choice). Its signals-and-slots
programming model is awesome.

(3) SDL: Don't know a lot about it, other than that it is pretty good at
what it does. The main disadvantage that I can see is that it focusses on
providing raw access to the screen and other hardware, while it does not
emphasize integration in the platform's native GUI (correct me if I am wrong
here). I am sure you can put up a window, but can you make an application
that looks/feels like a native app? With proper dialogs etc.? What does the
programming model look like?

(4) GTK: I think it is not very nice to work with. And it doesn't port well
to Windows/OSX.


Now my take on this is that it would be time well spent to formulate a
couple of requirements for a new Stage, then grade all options w.r.t. the
requirements. It's a boring job and it's more exciting to just jump head-in,
but this would definitely help to get all advantages/disadvantages of the
different options in focus.

Post by Paul Osmialowski
I don't know how it is done on MacOSX or things like Photon/QNX, but on
Windows SDL doesn't use X emulation. No Cygwin is needed for that either.

I am pretty sure SDL works natively on the Mac, too. I wonder first and
foremost how difficult it is to make a GUI-app that "feels good" on Windows
and OSX. I have seen zero examples of GUI programs made in either wxWidgets
or GTK, that work properly on the Mac, Linux, and Windows. For Qt, there is
at least Opera and Skype.

Cheerio, Sidney




-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[Richard vaughan]

Thanks all for the feedback about SDL, and particularly to Paul for
all his work. Here are my thoughts so far.

FAQ candidate: Why is a Stage a library and Player plugin, and not a
standalone app?

Engineering reasons:

Stage used to be a standalone app that talked to a Player (if
present) using shared memory. The redesign as a plugin allowed me to
eliminate a lot of code - now there is no Stage-specific code in
Player at all, permitting independent releases. It was also a great
sanity check for the plugin model - if it works for Stage it should
be good for most other uses. I fixed a few problems with the plugin
design along the way.

Also, Stage is not much use as a standalone app. You have to be able
to talk to the robots somehow, so you need a robot interface. Player
is a great interface, and it comes with lots of meta-drivers , e.g.
VFH, AMCL. The Stage package is useful standalone as a C library -
you use the Stage native API to talk to robots. In this mode your
controller binary contains all of Stage, giving you the best
performance with no IPC overhead. Of course, it's easy to wrap
libstage with another IPC API to create your own app.

Research reason:

Much more interesting scientifically is that Player clients on real
robots can run copies of Stage in their heads to rehearse actions
[ http://www.cs.sfu.ca/~vaughan/doc/vaughan_sab06.pdf ]. That is the
most important reason why I made Stage a library and a plugin.


Future development:

This leads me to something Brian and I have talked about. The Player
project could specify a very simple robot C API, which it would use
internally. Stage could present this API. It could look like a
minimal version of libplayerc:

p_laser_get_data( player_device_t* dev, player_laser_data_t* data );
p_laser_set_cmd( player_device_t* dev, player_laser_data_t* data );
p_laser_request( player_device_t* dev, player_laser_req_t* req,
player_laser_reply_t** reply );

If this API was standardized, Player client code could be compiled
against libplayerc like now, or libplayercore, or libstage/libgazebo.
Various middleware layers could be added or skipped without changing
client code. I plan to write a version of this into Stage anyway,
which will be used by libstageplugin and my own standalone apps. We
can see how that goes and talk later about whether it gets used
elsewhere.

Oh, and the Qt suggestion - Qt is a nice framework. I get the feeling
that SDL is lighter weight, and it is native C (Qt is C++). Moving
away from BSD sockets for Player is a big step, as is adding an
unusual dependency like SDL, so we should take care. Getting easy
access to OpenGL and the sound hardware in a platform independent way
is going to be very important for me. Paul has done a lot of work on
SDL already, and a proof of concept like that is worth a lot in my book.

Also, I think it's time we ran on Windows right out of the box. And
that means shipping Windows binaries. There, I said it.

Richard/

Post by Paul Osmialowski

Post by Sidney Cadot

Post by Paul Osmialowski

Post by Sidney Cadot
Did you consider porting Stage to Qt instead?
Cheerio,
Sidney

Isn't Qt too heavy?

That depends on what you mean by "heavy". And "too". ;-)

Post by Paul Osmialowski
If Stage is still considered to be plugin for
Player we must remember that Player itself must be fully scalable (so it
should be able to run on full-blown PC as well as on low-memory PDA's even

if

Post by Paul Osmialowski
they don't run Qtopia).

I don't see why this would be desirable. I do not see how running Stage
simulations on a PDA could be useful in the real world. (though it would be
cute).

I didn't mean that Stage should be able to work on PDA's (however, it
would be nice to have this), I only remarked that currently Stage needs
Player and Player should be able to run everywhere. Personally I don't see
nothing wrong in Stage being Player's plugin. Also I think it would be
desirable to have possibility of running Stage simulation plugin with no
visual output (for example, deliberative planners may use Stage simulation
to test proposed plan before execution on the real devices, there's no
need to have GUI companion during this). SDL may be helpful also in this
case, since there's no need to initialize all subsystems in main()
function, they can be initialized as they're needed (for example, Video
subsystem would be initialized only when Stage with GUI is used,
otherwise, Player as an SDL app is still capable to be started in remote
shell session).

Post by Sidney Cadot
The real advantage of a Qt version would be that you'd have a good-
looking
version running on the Unix, Mac, and Windows versions, without going via
non-native X emulation on the Mac/Windows platforms. Plus
(important, IMHO:)
Qt is a joy to program in.

I don't know how it is done on MacOSX or things like Photon/QNX, but on
Windows SDL doesn't use X emulation. No Cygwin is needed for that either.

Post by Sidney Cadot
On a related note: I do not personally consider it such great idea that the
simulator is a 'player' plugin - quite the contrary. If Stage is going to be
redesigned anyway, I would advocate to separate it further from the "player"
app; basically, to have it as a fully independent application. I am
interested to discuss the merits of both approaches, and I think that would
be a clever thing to do before embarking on a redesign.
The main problem with the current approach is that most GUI
frameworks
assume responsibility for the main event loop. This is conflicts deeply with
the current setup where "player" is in charge of the main thread.
Cheerio, Sidney
---------------------------------------------------------------------
----
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Playerstage-developers mailing list
https://lists.sourceforge.net/lists/listinfo/playerstage-developers

----------------------------------------------------------------------
---
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Playerstage-developers mailing list
https://lists.sourceforge.net/lists/listinfo/playerstage-developers

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[Sidney Cadot]

Hi Richard,

Post by Richard vaughan
FAQ candidate: Why is a Stage a library and Player plugin, and not a
standalone app?
Stage used to be a standalone app that talked to a Player (if
present) using shared memory. The redesign as a plugin allowed me to
eliminate a lot of code - now there is no Stage-specific code in
Player at all, permitting independent releases. It was also a great
sanity check for the plugin model - if it works for Stage it should
be good for most other uses. I fixed a few problems with the plugin
design along the way.

I will agree that good case can be made for the simulator proper to be
implemented as a Player driver. A driver, after all, is nothing more than a
piece of software that provides any number of interfaces to something that
is an (actual or simulated) piece of hardware, and this is true for the
simulator.

Having the simulator GUI run from within a plugin, though, makes me cringe a
bit -- it is at least an unusual design. Perhaps it would be possible to
split the GUI and simulation functionalities.

Post by Richard vaughan
Also, Stage is not much use as a standalone app. You have to be able
to talk to the robots somehow, so you need a robot interface. Player
is a great interface, and it comes with lots of meta-drivers , e.g.
VFH, AMCL. The Stage package is useful standalone as a C library -
you use the Stage native API to talk to robots. In this mode your
controller binary contains all of Stage, giving you the best
performance with no IPC overhead. Of course, it's easy to wrap
libstage with another IPC API to create your own app.

I like the idea of libstage (the simulator part) as a library; but I would
prefer that the GUI part be less entwined. The Stage world needs models,
their behavior and their polygon representations (for all the raytracing),
but the rendering (using GTK primitives) seems a bit out of place. I'd
rather see a possibility to implement different backend renderers next to
each other: GTK, SDL, Qt, OpenGL, ... With callbacks in place to interact
with the world models from the keyboard/mouse using the diverse rendering
backends.

Post by Richard vaughan
Oh, and the Qt suggestion - Qt is a nice framework. I get the feeling
that SDL is lighter weight, and it is native C (Qt is C++).

Yes, Qt is probably heavier weight, is C++ (which, I too, have mixed feeling
about), and worst of all, it takes control of your build process (using
"qmake" and the moc preprocessor). You do get a lot in return for that
though.

The bottom line: you wouldn't want to subjugate Qt to Player/Stage; rather
(and this is an important point): the Player/Stage API should be good enough
to make it possible to write a Qt-based app to control a simulation, in much
the same way that the current GTK GUI works (from a users PoV). Similarly,
you should be able to write a GLUT-app that does this, and an SDL version,
and a GTK-version, ... That means there needs to be a properly defined
interface between the simulator and the GUI.

Post by Richard vaughan
Moving away from BSD sockets for Player is a big step, as is adding an
unusual dependency like SDL, so we should take care.

I think it would be unfortunate to make a forced dependency on SDL.

Post by Richard vaughan
Getting easy access to OpenGL and the sound hardware in a platform

independent way

Post by Richard vaughan
is going to be very important for me.

This I don't understand. The way I look at it, OpenGL would be just another
backend renderer that could be hooked up to the simulator. A backend could
also support sound. But why the emphasis on SDL, or OpenGL - shouldn't the
focus be on making the Stage architecture support /any/ backend, rather than
any specific one?

Post by Richard vaughan
Paul has done a lot of work on SDL already, and a proof of concept like

that is worth a lot in my book.

I would love to have a look at it.

Post by Richard vaughan
Also, I think it's time we ran on Windows right out of the box. And
that means shipping Windows binaries. There, I said it.

No argument there. I would be happy if I could compile even just Player in
MinGW, so that I could run up our robot swarm control app in Windows for
demo purposes -- oddly enough, the guys with the wallets tend to be more
impressed with windows-based demos. Go figure.

Cheerio, Sidney



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[Richard vaughan]

Post by Richard vaughan

Post by Richard vaughan
Getting easy access to OpenGL and the sound hardware in a platform

independent way

Post by Richard vaughan
is going to be very important for me.

This I don't understand. The way I look at it, OpenGL would be just
another
backend renderer that could be hooked up to the simulator. A
backend could
also support sound. But why the emphasis on SDL, or OpenGL -
shouldn't the
focus be on making the Stage architecture support /any/ backend,
rather than
any specific one?

My experimental branch uses OpenGL to render geometry to produce
robot sensor data. When hardware accelerated this could be very fast.

Two more points - Stage used to be decoupled from its GUI back in the
day (Arena & XS). This introduced significant overhead in IPC, and,
more significantly in practice it meant that drawing stuff to aid
debugging (I mean, who gets coordinate systems right first time?) was
asynchronous and didn't play nice in the debugger. It is **really**
useful to be able to draw geometry synchronously when developing
models, let alone the Stage engine.

Eventually Stage will just talk graphics3D and Player's driver will
handle the rendering - want a different backend? use a different driver.

Richard/


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[Richard vaughan]

Post by Sidney Cadot
In a proper design, having the "model" part as a Player plugin is
an option
(although I see serious issues there, too), however IMHO the
"view/controller" part should _definitely_ not be inside a plugin.
All GUI
frameworks that I am aware of want control of the main event loop,
and this
clashes bigtime with a gui-as-a-plugin player (because 'player'
wants the
same control of the event loop).

Player/Stage (i.e. Player with the Stage plugin) already works this
way. Most users don't see any "clashing bigtime". Most frameworks,
including GTK+, allow event polling inside a custom main loop. GLUT
is a naughty exception. I think FreeGLUT solves that problem. SDL
allows custom main loops.

Post by Sidney Cadot

Post by Paul Osmialowski
Also I think it would be desirable to have possibility of running
Stage

simulation plugin with

Post by Paul Osmialowski
no visual output (for example, deliberative planners may use Stage

simulation.

Post by Paul Osmialowski
to test proposed plan before execution on the real devices,
there's no
need to have GUI companion during this).

While this is definitely an interesting application, I can only see
this
work if there is an API to instantiate a "simulation" instance at
runtime
(by a player client) -- if only for the simple reason that the
timeline of
speculative execution is different from the timeline of the "real
world".

You can already do this by spawning new instances of Player/Stage.
Your code can generate cfg and world files as needed. Don't forget
about all the work the OS can do for you.
However, an internal API for doing this is part of the plan, as
writing text files is pretty ugly.

Richard/


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[Sidney Cadot]

Hi Richard,

Post by Richard vaughan
Player/Stage (i.e. Player with the Stage plugin) already works this
way. Most users don't see any "clashing bigtime".

That's true, from a user's perspective it is all fine and dandy. I am
talking from a software designer's perspective, though; then, having a GUI
controlled from a plugin is pretty funky.

Post by Richard vaughan
Most frameworks,
including GTK+, allow event polling inside a custom main loop. GLUT
is a naughty exception. I think FreeGLUT solves that problem. SDL
allows custom main loops.

Yes, all these frameworks /allow/ that, but that doesn't make it the right
thing to do. In general, I think it is a mistake for /any/ piece of software
(be it a GUI toolkit or a robot control framework) to assume it is in
control of the master thread.

Post by Richard vaughan

Post by Sidney Cadot
While this is definitely an interesting application, I can only see
this work if there is an API to instantiate a "simulation" instance at
runtime (by a player client) -- if only for the simple reason that the
timeline of speculative execution is different from the timeline of the

"real

Post by Richard vaughan

Post by Sidney Cadot
world".

You can already do this by spawning new instances of Player/Stage.
Your code can generate cfg and world files as needed. Don't forget
about all the work the OS can do for you.

I hope you agree that's not the most elegant way of doing things.

Post by Richard vaughan
However, an internal API for doing this is part of the plan, as
writing text files is pretty ugly.

Phew :)

Cheerio, Sidney



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[Geoffrey Biggs]

I think a misconception may need to be cleared up here. To my knowledge,
SDL (Simple Direct*Media* Layer) does not provide a cross-platform GUI
framework. It is designed to provide cross-platform access to the sorts
of OS-specific facilities that games need: graphics rendering, sound
output, input polling, etc. Not windows, buttons, menus and so forth. So
it can't be compared with Qt, GTK and similar.

Personally, I think the ideal solution would be to use SDL for all the
media stuff and Qt for the windowing stuff, but that's just because I
have experience with and am quite fond of both.

Using SDL for the player server and client libraries to abstract away
OS-specific issues around networking and timing would also be nice, but
we need to consider if it will give an unwarranted library dependancy,
given that it's not that difficult a job to abstract away such
facilities that we need ourselves (I've done it more times than I really
wanted to already in other projects, commercial and not). One way to
avoid the dependancy on SDL, at least on the server side, could be to
provide a libplayersdl alternative to libplayertcp, and only support
that for the Windows release.

Geoff

Post by Sidney Cadot
Realistically, I think there are four contenders that could offer a

...

Post by Sidney Cadot
(3) SDL: Don't know a lot about it, other than that it is pretty good at
what it does. The main disadvantage that I can see is that it focusses on
providing raw access to the screen and other hardware, while it does not
emphasize integration in the platform's native GUI (correct me if I am wrong
here). I am sure you can put up a window, but can you make an application
that looks/feels like a native app? With proper dialogs etc.? What does the
programming model look like?

[Sidney Cadot]

Hi Geoff,

Post by Geoffrey Biggs
I think a misconception may need to be cleared up here. To my
knowledge, SDL (Simple Direct*Media* Layer) does not provide a

cross-platform GUI

Post by Geoffrey Biggs
framework. It is designed to provide cross-platform access to the sorts
of OS-specific facilities that games need: graphics rendering, sound
output, input polling, etc. Not windows, buttons, menus and so forth.
So it can't be compared with Qt, GTK and similar.

That's what I am worried about. The simulator /will/ need a menu bar, and
all that stuff.

Post by Geoffrey Biggs
Personally, I think the ideal solution would be to use SDL for all the
media stuff and Qt for the windowing stuff, but that's just because I
have experience with and am quite fond of both.

Out of curiosity: what functionality do you like about SDL that you cannot
get out of Qt? The only thing I could think of is sound.

Cheerio, Sidney



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[Toby Collett]

This has got a little sidetracked from where it started, which was using
SDL to make the player *core* more portable. There is currently a very
clear separation of UI code and server code in player. Slightly less so
in stage, but still some.

SDL was proposed as a way of making the sockets layer more portable,
while I think this is an important goal (This is currently tagged for
player 2.2, which should be much closer than 2.1 is to 2.0), I have not
had trouble in the past getting sockets code to run on both windows and
linux, from memory there is one extra call in windows to initialise the
sockets and then they behave in the same manner.

In theory porting the player core and client libraries to native win32
(without minGW?) should not be difficult. The hardest part would be
getting the build process working nicely, and this has been done before
in many projects. The player drivers and utilities are a different
kettle of fish, but it would be easy enough to pick the low hanging
fruit from these and disable the others for the windows build.

With respect to Qt, it may be suitable for some aspects of the player
project, but I personally would not want it in the core libraries. Also
with respect to Qt's build process, yes you need moc, but you dont need
qmake, in fact even in Qt oriented projects I have undertaken I tend to
shy away from qmake as it is fairly limiting in your build targets (or
alternatively my understanding is limiting of my use, same result either
way :). Gtk is easy enough to get running in windows, there are windows
binaries for it available, so there is really no need to reimplement the
existing UI's to get a windows port running.

So what we need is a windows user to take on board the windows port
(which if we agree to SDL in the core is already underway) and to have
all the changes merged into player head so that their are not two
versions to maintain.

Toby

Post by Sidney Cadot
Hi Geoff,

Post by Geoffrey Biggs
I think a misconception may need to be cleared up here. To my
knowledge, SDL (Simple Direct*Media* Layer) does not provide a

cross-platform GUI

Post by Geoffrey Biggs
framework. It is designed to provide cross-platform access to the sorts
of OS-specific facilities that games need: graphics rendering, sound
output, input polling, etc. Not windows, buttons, menus and so forth.
So it can't be compared with Qt, GTK and similar.

That's what I am worried about. The simulator /will/ need a menu bar, and
all that stuff.

Post by Geoffrey Biggs
Personally, I think the ideal solution would be to use SDL for all the
media stuff and Qt for the windowing stuff, but that's just because I
have experience with and am quite fond of both.

Out of curiosity: what functionality do you like about SDL that you cannot
get out of Qt? The only thing I could think of is sound.
Cheerio, Sidney
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Playerstage-developers mailing list
https://lists.sourceforge.net/lists/listinfo/playerstage-developers

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[Geoffrey Biggs]

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.

Basically, I agree with Toby in that the hardest part of providing a
Windows binary is, in fact, the build system. A port of autotools is
available for Windows
(http://gnuwin32.sourceforge.net/packages/autotools.htm), although I
haven't used it so I don't know how good it is. We could also provide a
Visual C project, if we want to make things really easy for people.
They're not very hard to setup.

Geoff

Post by Toby Collett
This has got a little sidetracked from where it started, which was using
SDL to make the player *core* more portable. There is currently a very
clear separation of UI code and server code in player. Slightly less so
in stage, but still some.
SDL was proposed as a way of making the sockets layer more portable,
while I think this is an important goal (This is currently tagged for
player 2.2, which should be much closer than 2.1 is to 2.0), I have not
had trouble in the past getting sockets code to run on both windows and
linux, from memory there is one extra call in windows to initialise the
sockets and then they behave in the same manner.
In theory porting the player core and client libraries to native win32
(without minGW?) should not be difficult. The hardest part would be
getting the build process working nicely, and this has been done before
in many projects. The player drivers and utilities are a different
kettle of fish, but it would be easy enough to pick the low hanging
fruit from these and disable the others for the windows build.
With respect to Qt, it may be suitable for some aspects of the player
project, but I personally would not want it in the core libraries. Also
with respect to Qt's build process, yes you need moc, but you dont need
qmake, in fact even in Qt oriented projects I have undertaken I tend to
shy away from qmake as it is fairly limiting in your build targets (or
alternatively my understanding is limiting of my use, same result either
way :). Gtk is easy enough to get running in windows, there are windows
binaries for it available, so there is really no need to reimplement the
existing UI's to get a windows port running.
So what we need is a windows user to take on board the windows port
(which if we agree to SDL in the core is already underway) and to have
all the changes merged into player head so that their are not two
versions to maintain.
Toby

[Toby Collett]

Post by Geoffrey Biggs
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?)

Post by Geoffrey Biggs
Basically, I agree with Toby in that the hardest part of providing a
Windows binary is, in fact, the build system. A port of autotools is
available for Windows
(http://gnuwin32.sourceforge.net/packages/autotools.htm), although I
haven't used it so I don't know how good it is. We could also provide a
Visual C project, if we want to make things really easy for people.
They're not very hard to setup.
Geoff

Post by Toby Collett
This has got a little sidetracked from where it started, which was using
SDL to make the player *core* more portable. There is currently a very
clear separation of UI code and server code in player. Slightly less so
in stage, but still some.
SDL was proposed as a way of making the sockets layer more portable,
while I think this is an important goal (This is currently tagged for
player 2.2, which should be much closer than 2.1 is to 2.0), I have not
had trouble in the past getting sockets code to run on both windows and
linux, from memory there is one extra call in windows to initialise the
sockets and then they behave in the same manner.
In theory porting the player core and client libraries to native win32
(without minGW?) should not be difficult. The hardest part would be
getting the build process working nicely, and this has been done before
in many projects. The player drivers and utilities are a different
kettle of fish, but it would be easy enough to pick the low hanging
fruit from these and disable the others for the windows build.
With respect to Qt, it may be suitable for some aspects of the player
project, but I personally would not want it in the core libraries. Also
with respect to Qt's build process, yes you need moc, but you dont need
qmake, in fact even in Qt oriented projects I have undertaken I tend to
shy away from qmake as it is fairly limiting in your build targets (or
alternatively my understanding is limiting of my use, same result either
way :). Gtk is easy enough to get running in windows, there are windows
binaries for it available, so there is really no need to reimplement the
existing UI's to get a windows port running.
So what we need is a windows user to take on board the windows port
(which if we agree to SDL in the core is already underway) and to have
all the changes merged into player head so that their are not two
versions to maintain.
Toby

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[Paul Osmialowski]

Post by Toby Collett

Post by Geoffrey Biggs
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

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[Jack O'Quin]

Post by Geoffrey Biggs
Basically, I agree with Toby in that the hardest part of providing a
Windows binary is, in fact, the build system. A port of autotools is
available for Windows
(http://gnuwin32.sourceforge.net/packages/autotools.htm), although I
haven't used it so I don't know how good it is. We could also provide a
Visual C project, if we want to make things really easy for people.
They're not very hard to setup.

SCONS is probably worth a look (http://www.scons.org/).

I have not used it myself but people whose judgment I respect are
using it for large open-source projects. It is implemented in python,
and claims to have good support for Linux, Unix, OS X, and Windows.

It appears to be fairly stable and mature at this point, and a *lot*
cleaner than the automake tools. The SCONS equivalent of a
Makefile is a SConstruct file, which is written in Python.

[Paul Fitzpatrick]

Post by Jack O'Quin

Post by Geoffrey Biggs
Basically, I agree with Toby in that the hardest part of providing a
Windows binary is, in fact, the build system. A port of autotools is
available for Windows
(http://gnuwin32.sourceforge.net/packages/autotools.htm), although I
haven't used it so I don't know how good it is. We could also provide a
Visual C project, if we want to make things really easy for people.
They're not very hard to setup.

SCONS is probably worth a look (http://www.scons.org/).
I have not used it myself but people whose judgment I respect are
using it for large open-source projects. It is implemented in python,
and claims to have good support for Linux, Unix, OS X, and Windows.
It appears to be fairly stable and mature at this point, and a *lot*
cleaner than the automake tools. The SCONS equivalent of a
Makefile is a SConstruct file, which is written in Python.

I agree about the difficulty of supporting building on diverse platforms
(especially those that fall outside the GNU toolchain), and the utility
of tools like SCons that make this easier.

CMake [1] is an alternative to SCons that is also worth a look.

We've been using CMake for YARP [2] and it does the job. Compiling on
Linux, Windows, and OS X works well, with good support of people's
favorite IDEs: gcc/make on Linux; various versions of Visual Studio on
Windows, along with cygwin/mingw; Xcode and gcc/make on OS X; and
various other permutations. So developers and users are happy building
YARP in their own quirky ways, without any time being wasted keeping all
the build files up-to-date.

The downside of CMake versus SCons is the language; the authors of CMake
rolled their own, and it is a bit ugly compared with python. The upside
is that the language doesn't introduce an extra dependency, and it is a
pretty good language for the job. There are a bunch of big projects
using CMake there days, including KDE [3]. The CMake mailing lists are
also very active and responsive, and there seems to be a healthy
community there.

Cheers,
Paul

[1] http://www.cmake.org
[2] http://yarp0.sourceforge.net
[3] http://lwn.net/Articles/188693/


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[Geoffrey Biggs]

I've heard good things about CMake. The language certainly couldn't be
any more obtuse than writing autotools scripts. :)

Geoff

Post by Paul Fitzpatrick
I agree about the difficulty of supporting building on diverse platforms
(especially those that fall outside the GNU toolchain), and the utility
of tools like SCons that make this easier.
CMake [1] is an alternative to SCons that is also worth a look.
We've been using CMake for YARP [2] and it does the job. Compiling on
Linux, Windows, and OS X works well, with good support of people's
favorite IDEs: gcc/make on Linux; various versions of Visual Studio on
Windows, along with cygwin/mingw; Xcode and gcc/make on OS X; and
various other permutations. So developers and users are happy building
YARP in their own quirky ways, without any time being wasted keeping all
the build files up-to-date.
The downside of CMake versus SCons is the language; the authors of CMake
rolled their own, and it is a bit ugly compared with python. The upside
is that the language doesn't introduce an extra dependency, and it is a
pretty good language for the job. There are a bunch of big projects
using CMake there days, including KDE [3]. The CMake mailing lists are
also very active and responsive, and there seems to be a healthy
community there.

[Paul Osmialowski]

Post by Paul Fitzpatrick
CMake [1] is an alternative to SCons that is also worth a look.

No, please, no cmake. It does NOT work on hardened gentoo (I guess
problems with ProPolice's stack protector) that I'm using on my server,
where Player is available for public audience (and since it is open to the
world, it must be hardened gentoo to make it work safely).


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[Radu Bogdan Rusu]

Post by Toby Collett
This has got a little sidetracked from where it started, which was using
SDL to make the player *core* more portable. There is currently a very
clear separation of UI code and server code in player. Slightly less so
in stage, but still some.

Toby, we'd also have to think about the drivers (which is sort of one of the main reasons
people dive into Player). I'm afraid that some of them will just not work in Win without
major modifications. :-/ There are a bunch of libraries we are dependent on, especially
when it comes to exotic drivers.

Cheers,
Radu.
--
| Radu Bogdan Rusu | http://rbrusu.com/
| http://www9.cs.tum.edu/people/rusu/
| Intelligent Autonomous Systems
| Technische Universitaet Muenchen

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/