Should Xconq use SDL?

SDL Development
1

Some of you may be familiar with Xconq, which is a generic strategy
game engine that I’ve been working on since 1986. (Home page is at
http://sourceware.cygnus.com/xconq)

Xconq started out as a simple X10 (that’s right, before X11) clone
of the old WB Empire game, and has since evolved into a rather
complex engine whose declarative game design language can handle a
wide variety of games. For instance, Civ can be (mostly) written in
Xconq’s GDL. Xconq also provides its own GUI for players, and to
date, interfaces have been written using X10, X11, Xt/Xaw, Motif,
tcl/tk, and Mac toolbox.

The reason I’m writing here is that I’m not satisfied with the current
state of Xconq’s GUI. I switched from Xt/Xaw to tcl/tk to get better
toolkit and a Windows port, but it’s taken a lot of custom widget work
to get tk to do the right things fast enough on Windows, the existing
tk widgets are unattractive, and it’s complicated to connect Xconq’s C
code to tcl scripts. The Mac interface, while superior in many ways,
is Mac-only, and it’s a lot of redundant work to maintain it alongside
the tcl/tk interface.

So I’ve been looking around at alternatives. Here are the basic
requirements:

  1. Fast 2D graphics. Xconq’s library includes maps of up to 250K
    hexes, with multiple data layers; graphics system must be able
    to draw all of it.

  2. Multi-platform. Unix/Linux, Mac, Windows.

  3. Multiple windows. While most of the action is in a single
    map window, players often want extra windows for aux displays.

  4. Widgets. Xconq needs to support lots of knobs and switches,
    since it’s aimed at experienced and sophisticated game players.

  5. Sound. Mac Xconq is the only version with sound currently.

  6. C API.

  7. GPL or LGPL sources.

From the past several months of investigation, SDL seems to fulfill
the most requirements, widget availability being the most problematic.

One that concerns me is that SDL games seem to fall into two
categories. I see simple arcade-type designs, and the big commercial
games ported by Loki; which makes me think there is a huge amount of
infrastructure work needed to use SDL with a more complex game.
What’s the largest completed open-source game using SDL?

Thanks for reading this far, and hopefully this is enough background
to answer the big question: should Xconq adopt SDL as its standard
interface library?

Stan

2

The reason I’m writing here is that I’m not satisfied with the current
state of Xconq’s GUI. I switched from Xt/Xaw to tcl/tk to get better
toolkit and a Windows port, but it’s taken a lot of custom widget work
to get tk to do the right things fast enough on Windows, the existing
tk widgets are unattractive, and it’s complicated to connect Xconq’s C
code to tcl scripts. The Mac interface, while superior in many ways,
is Mac-only, and it’s a lot of redundant work to maintain it alongside
the tcl/tk interface.

OK. First off: If you want a GUI, you will have to build the code yourself. SDL
is a low level frame buffer manipulation library, with extra addons for input,
sound, CD-rom access, events, and an OpenGL binding. If you DO go with SDL and
build the code yourself, please opensource it and give us a copy. :slight_smile:

  1. Fast 2D graphics. Xconq’s library includes maps of up to 250K
    hexes, with multiple data layers; graphics system must be able
    to draw all of it.

Hardware blitting is pretty good… testsprite gets ~50 fps on my P/200 with
XFree86 3.3.x.

  1. Multi-platform. Unix/Linux, Mac, Windows.

Yup.

  1. Multiple windows. While most of the action is in a single
    map window, players often want extra windows for aux displays.

This it doesn’t have. I am constantly threatening to do this for my own use.
Maybe eventually I will, but at present the functionality is not there.

  1. Widgets. Xconq needs to support lots of knobs and switches,
    since it’s aimed at experienced and sophisticated game players.

Nope.

  1. Sound. Mac Xconq is the only version with sound currently.

Yup.

  1. C API.

Yup.

  1. GPL or LGPL sources.

Hell yeah! :slight_smile:

One that concerns me is that SDL games seem to fall into two
categories. I see simple arcade-type designs, and the big commercial
games ported by Loki; which makes me think there is a huge amount of
infrastructure work needed to use SDL with a more complex game.
What’s the largest completed open-source game using SDL?

Quake. :slight_smile:

My opinion on SDL is that you do have to build a little bit of infrastructure
in order to make your game work, but you should be doing this anyways, or else
you are a sloppy programmer. SDL provides low level multi-platform access to
system internals, and nothing more. If you’re looking for a more powerful
solution which provides rendering engines et al, you might want to look at
Clanlib. (Even though IMHO it’s … well, I won’t mention my views on ClanLib
since Daniel Vogel subscribes to this mailing list)

Thanks for reading this far, and hopefully this is enough background
to answer the big question: should Xconq adopt SDL as its standard
interface library?

Interface: No. Unfortunately there are no really suitable cross platform
interface routines – all the “good” stuff (MFC… well, it’s not really good
stuff IMHO, QT, GTK) are fairly platform specific with the odd spinoff port
that doesn’t really work. What I was looking at for a while was adding multiple
window code to SDL, then rewiring GDK on top of that, so that GTK+ would be
truly multiplatform. Suffice it to say, I don’t have the time, or the energy,
or the money at this point in time. Maybe, eventually I will… bribes will be
accepted gratefully. :-)>S

3

Thanks for reading this far, and hopefully this is enough background
to answer the big question: should Xconq adopt SDL as its standard
interface library?

Interface: No. Unfortunately there are no really suitable cross platform
interface routines – all the “good” stuff (MFC… well, it’s not really good
stuff IMHO, QT, GTK) are fairly platform specific with the odd spinoff port
that doesn’t really work. What I was looking at for a while was adding multiple
window code to SDL, then rewiring GDK on top of that, so that GTK+ would be
truly multiplatform. Suffice it to say, I don’t have the time, or the energy,
or the money at this point in time. Maybe, eventually I will… bribes will be
accepted gratefully. :slight_smile:

For a look at the interface libraries available (some of which are portable) go here:
http://www.geocities.com/SiliconValley/Vista/7184/guitool.html#free_toolkit

4

vining at pacificcoast.net wrote:

Thanks for the feedback!

The reason I’m writing here is that I’m not satisfied with the current
state of Xconq’s GUI. I switched from Xt/Xaw to tcl/tk to get better
toolkit and a Windows port, but it’s taken a lot of custom widget work
to get tk to do the right things fast enough on Windows, the existing
tk widgets are unattractive, and it’s complicated to connect Xconq’s C
code to tcl scripts. The Mac interface, while superior in many ways,
is Mac-only, and it’s a lot of redundant work to maintain it alongside
the tcl/tk interface.

OK. First off: If you want a GUI, you will have to build the code yourself. SDL
is a low level frame buffer manipulation library, with extra addons for input,
sound, CD-rom access, events, and an OpenGL binding. If you DO go with SDL and
build the code yourself, please opensource it and give us a copy. :slight_smile:

It’s certainly a possibility…

Thanks for reading this far, and hopefully this is enough background
to answer the big question: should Xconq adopt SDL as its standard
interface library?

Interface: No. Unfortunately there are no really suitable cross platform
interface routines – all the “good” stuff (MFC… well, it’s not really good
stuff IMHO, QT, GTK) are fairly platform specific with the odd spinoff port
that doesn’t really work. What I was looking at for a while was adding multiple
window code to SDL, then rewiring GDK on top of that, so that GTK+ would be
truly multiplatform. Suffice it to say, I don’t have the time, or the energy,
or the money at this point in time. Maybe, eventually I will… bribes will be
accepted gratefully. :slight_smile:

For Xconq, I’m now thinking about a sort of hybrid transitional
approach, where SDL gets to own a single window, but the rest of the
interface is tcl/tk - the example combo program on the SDL pages seems
to work well enough. Eventually players would migrate to the SDL
window for normal play, and tcl/tk could be left for things like map
and scenario editing, where the look of the interface isn’t so important.

I think your idea about gtk widgets would work; but when you’re done
you’re left with, well, gtk widgets. Not very interesting for games
actually. Good games are interesting with respect to their reimpls of
standard widgets - oftentimes the widgets lack basic behavior, like
dragging in scrollbars, but widgets offer such a good opportunity to
immerse the player further into the game world that developers almost
always do widgets specialized for the game.

Stan