The SDL client

[Mathias Broxvall <matbr at ida dot liu dot se>]

Hi, I took a little look at what's been done at the SDL client this
weekend and have some questions/suggestions...

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 \ 

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).

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. It
probably wouldn't be a good idea if I started writing some dialogs 
displayed simultanesouly with the map (eg. sides/building/research etc.)
unless we have atleast some more infrastructure. Perhaps something along
the lines of having a number of structures (as below) which can be 
initialized by the drawing routines and read GDL data to describe what
actions to be taken when the mouse is clicked on various parts of the
screen etc.

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'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).

/

Mathias Broxvall
matbr@ida.liu.se