[Freeciv-Dev] (PR#2496) SDL client needs theme graphics

["Jason Short via RT" <rt@xxxxxxxxxxxxxx>]

[bursig - Thu Dec  5 22:56:42 2002]:

> Patch add acces to sprite hash table outside tilespec. This is used in 
> SDLClient to load GUITheme/City Icon from specfiles.

We need a resolution for this problem.

The problem is that the SDL client has many more theme graphics. 
Currently these are help in freeciv-test/data/theme, and have to be
copied over to freeciv to work.  And currently, they are loaded manually
by the freeciv client.

SDL-client needs these graphics to work, and some of them could come in
handy for other clients.

I see four alternatives here:

1.  Rafal's original patch simply makes sprite_hash available outside
tilespec.c.  Since all sprites in the tileset are loaded into
sprite_hash, we could add these sprites to our default tileset and let
the SDL client manually retrieve them from the hash.  The advantage is
that this is really simple.  The disadvantage is that this ends up
fragmenting the tilespec specification; each client can add new
"required" tags all willy-nilly.  So it is IMO only a temporary solution.

2.  An alternative would be just to copy the graphics files into
data/theme and let SDL load them manually (which it is already set up to
do).  This is also really easy, and avoids polluting the tilespec files.
 It also means the other clients don't have to load these graphics
(which is good, since they don't use them).  But it does not allow easy
changing of the theme graphics (which is a goal).  And we don't really
want to put the files into one place and then move them later (since CVS
doesn't handle this well) if we can avoid it.  So is theme/ a good
place?  This is also a temporary solution.

3.  We could add the graphics files to the tilesets and have them be
loaded by the common code.  Now there will be pointers to them somewhere
in struct named_sprites.  The advantage is that the tileset stays
cohesive; anyone can use these sprites but they are guaranteed to be
nameed consistently.  We can add documentation about them, etc., and
count on it to be correct.  The disadvantage is every time a new theme
graphic is added, it must be added here and loaded by all clients.  And
that the theme graphics really don't belong here...although many are
there already.

4.  We could create a separate themespec and tilespec concept.  This
would mean introducing a themespec.[ch], and duplicating a little bit of
code from tilespec.c (or they can use common functions).  Theme graphics
are loaded into a theme_hash, just like they are loaded into sprite_hash
by tilespec.  Now we can either allow the loading of graphics to be done
individuall for each GUI - making theme_hash public like in step #1, or
we can load it into a theme struct in themespec.h like in step #2. 
There are advantages and disadvantages of both, as discussed above.

If, in fact, the restructuring of the graphics data (disk storage,
access, and memory storage) is imminent, it would make sense to use a
temporary solution (I suppose I prefer #2).  But really any of them
seems okay to me at this point (so long as #1 or #2 are only temporary
solutions).


As a side note, the difference between theme and tile graphics is very
subtle - many graphics are used as both theme _and_ tile graphics, and
should probably be included in both specs.  In generaly, theme graphics
should be sized appropriately to the resolution or DPI and tile graphics
should be sized based upon the desired tileset size.

jason