[Freeciv-Dev] Re: Graphic resource editor, and an architecture proposal

[Jason Dorje Short <vze49r5w@xxxxxxxxxxx>]

Eric S. Raymond wrote:
> Per I. Mathisen <per@xxxxxxxxxxx>:
>
> > I don't see any attachments...
>
> My error.  I'll send it today, after I make the change to burst the artists
> attribute into an artists metadata file.
>  
>
> > This should have been documented somewhere, though. Perhaps someone should
> > write a general modpack README.
>
> If my architecture change is approved, one of the things I will deliver 
> along with my patch is a tile-editing HOWTO.
>  
>
> > > <para>The aggregate of all FreeCiv data files is functionally similar
> > > to a Windows registry, and even uses a syntax resembling the textual
> > > portions of registries.But the creep and corruption problems we
> > > noted with the Windows registry don't crop up here because no program
> > > (either within or outside the FreeCiv suite)
> > > <emphasis>writes</emphasis> to these files.It's a read-only
> > > registry edited only by the game's maintainers.</para>
> > I don't know if that is relevant, but savegames are also registry files,
> > and they are written by freeciv.
Tileset, ruleset, and savegame all use the same registry format, but 
they're all handled independently.  They are linked in many ways, though 
(for instancee the ruleset specifies tileset sprite names, the savefile 
specifies the ruleset to use, etc.).
> > > FIRST PROPOSED CHANGE: Replace the tile-array files with directories,
> > > one for each array, with the tiles as named files beneath them. Nuke
> > > all the tile-coordinate crap in the specfiles.
> > I agree. This would make it a lot easier to add stuff.
>
> You like it.  Dorje likes it, with reservations about backward compatibility
> which I have already addressed.  Paul says it's "exciting".  Should I take
> this as direction to produce a patch?
I would wait a couple of weeks to get some more feedback and hopefully 
hash the idea out a bit more.
> > > SECOND PROPOSED CHANGE: Consolidate all the tileset-specific graphics
> > > into one directory called 'graphics'. All image lookup calls dive
> > > into this directory. Hierarchy beneath it goes
> > > <role>/<type>/<size>/<style>.
> > ...
> >
> > > 2. Looking up a flag by nation and preferred size: ("flag", "usa",
> > > "30x30", "engels"). Look under graphics/flag/usa.  See that there
> > > are two directories,26x20 and 30x21.Aha!  That's a size.  By
> > > least-squares metric the closest match is 30x21.Look for "usa"
> > > under there. See a file.  Return it.
> > Don't agree. I think it makes more sense to standardize on a certain size,
> > at least for flags and misc images.
>
> I must disagree.  We can't count on either screen size or resolution 
> remaining constant.  Therefore, unless we're going to move graphics 
> to a scalable vector format and have the client auto-resize them, we
> need to be able to support multiple sizes.
Flag sprites are unusual (really all sprite types are unusual in some 
way, which is what makes this so difficult).  A flag may be used as a 
"theme" graphic, for instance in the player dialog or nation selection 
dialog.  But it is also (and more importantly) used as a "tile" graphic, 
drawn onto the mapview or cityview canvas.
The theme graphics may be used anywhere, but the desired resolution 
generally depends on the GUI and on the screen resolution.  Here a 
standard size makes sense, although not all interfaces may be happy with 
this standard.
The tileset graphics should generally be proportionally sized to the 
tileset.  Currently our tilesets are all about the same size, so this 
isn't too much of a problem.  But if we use a 128x64 iso-view tileset, 
that will be 4x the size of the current tileset.  Larger nation flags 
would probably be desirable.  And for small tilesets (e.g., tinydent at 
10x10 non-iso-view) a smaller flag is probably needed to get good results.
jason