Re: The SDL client

[Stan Shebs <shebs at shebs dot cnchost dot com>]

Mathias Broxvall wrote:
> 
> First, a minor point. The xconq/images/Makefile.in need a fix to install
> also the .bmp images:
> 
> 52c52
> <       for i in `ls $(srcdir)/*.gif `; do \
> ---
> >       for i in `ls $(srcdir)/*.gif $(srcdir)/*.bmp`; do \

Heh, good catch - I haven't tried installing this version yet...

> Secondly, how about using libSDL_image to handle image loading - this
> would make it easier to read the .gif images used elsewhere in xconq as
> well as .png images for fancier (24bpp) screen graphics. I imagine that
> a future SDL client propaly needs lots of small images acting as widgets
> and large images as backgrounds/helpscreens/... which would seem to
> motivate an image loader supporting more than just .bmp images (which
> usally takes up lots of space for larger images - ie. bad packing
> algorithms).

PNG is in the plan - see item I253 in doc/PROJECTS - but I was expecting
to call it directly.  Xconq's image machinery works with all interfaces
that do bitmap graphics, and it would be a little difficult to use the
SDL image library to get surfaces, then convert to Mac pixmaps, etc.
Another thing that came up this weekend is that Xconq's image families
provide a handy link between game designs and interface elements, so
for instance if we make cursor images into image families, and add some
new globals, game rules can specify cursors.  SDL_image would be a
sensible choice for interface elements that are common to all games
though.

> Also, IMHO - it would be good if the framework for deciding where things
> should be drawn on the screen is settled for as quickly as possible.

Amen.  I spent way too much time playing artist this weekend (and then
playing Diablo again, when I was just supposed to be studying its cursor
behavior :-) ), and so I haven't settled on an interface framework, sorry.

> struct panel {
>   SDLRect r;
>   void (*draw)(struct panel*);
>   void (*mouse_clicked)(struct panel*);
>   void (*mouse_moved)(struct panel*);
> };
> 
> (I'm assuming we don't want to do the drawing stuff with C++ and
> inheritance - correct?)

I looked at the existing SDL-based libraries, and they use lots of
inheritance, but I don't think we need anything that heavyweight.
We need panels (both popup and drawer-type), buttons, scrollable list
and text boxes, and that's about it.

> I'll start writing some form of new_game_dialog this week, it seems like
> that stuff can be done quite indepedently from the rest of the SDL client.
> (It needs its own event loop).

That would be a good experiment.  Chances are that the details will
have to change as other pieces get built, so it's best to think of as
a prototype, not try to polish too much yet.  For instance, we'll
probably want to end up with a single event loop, and treat things
like the new game dialog as a mode, since it will be easier to handle
network traffic and display updates in translucent dialogs if there
is a single path for handling events.

Since you mention the new game dialog, this reminds of something that's
been discussed a little previously, which is to separate the new game
dialog into two stages.  The first would be to select a set of game
rules, and the second would be to select a scenario, preferably in the
same screen as variants.  The first screen presents Xconq the meta-game,
and after that you've focussed on a particular game, and then choose
a random game or scenarios.  This change would entail a little tinkering
with the library and the other interfaces, so it's not going to happen
this week, but you can expect to need to change the startup sequence
a bit in the future.

Stan