[freeciv-data] Re: adding nations more easily by splitting flags

Jason Short <[email protected]> Sat, 12 Jul 2003 19:50:50 -0400
Newsgroups gmane.games.freeciv.data
Message-ID <[email protected]>
--On Saturday, July 12, 2003 13:14:52 -0500 Mike Kaufman 
<[email protected]> wrote:

> proposal: move flags into individual png files.
>
> benefits: facilitate adding and/or removing nations easily by freeciv
>           non-cognicenti. merge redundant flags.png files from trident/
>           and isotrident/ directories. make isotrident_shields easy to
>           accomplish.
>
> problems: flags sprites in trident and isotrident have different sizes,
>           specifically differing amounts of transparency. Also,
> shields.png           for trident_shields needs to be updated
> concurrently with any           added nation.
>
> cons: only a single [uniform] grid in png files will be allowed: pngs
> other       than the flags.pngs will have to be modified.
>
> method: create a data/misc/flags directory and create a png file for each
>         nation named for example "italy.png". Each png would have a 2x1
>         (or 1x2) grid with the regular flag in the first space and the
>         'shields' flag in the second. The .spec file would be located in
>         the data/<tileset>/ directory.
>
> specifics:
>
> to create spec files that can deal with multiple graphics files and
> different transparency sizes,

I think this is a step in the wrong direction.  Specfiles should be 
simpler, not more complex.  This new functionality should drop the grid 
complexity and just give a filename - one sprite per file.

> change header [file] to [file_*]
> gfx = <filename>
> ; specify the  the size of the grid. we no longer need [xy]_top_left since
> ; we only allow one grid.
> grid  = { "dx", "dy", "is_pixel_border" }
> ; each tile can have a different width, height, and offset from the top
> ; left of the sprite. a scaling feature can be added later.
> tiles = { "row", "column", "width", "height", "x_offset", "y_offset",
> "tag" }
>
> and use secfile_get_secnames_prefix(file, "file_", &num_files) to access
> each
> graphics file.
>
> spec files with multiple [grid_*] sections must be changed: probably means
> pngs
> will have to be split.
>  o trident/roads.spec -> 2 grids
>  o isotrident/terrain1.spec -> 3 grids
>  o isotrident/terrain2.spec -> 2 grids
>
> so a flags specfile would look like:
>
> [spec]
> options = "+spec3"
>
> [info]
> artists = "..."
>
> [file_italy]
> gfx = "trident/flags/italy.png"
> grid  = { "dx", "dy", "is_pixel_border"
>   26, 20, 0
> }
> tiles = { "row", "column", "height", "width", "offset_x", "offset_y",
> "tag"  0,  0, 30,  30,  0,  0,  "f.italy"
> }
>
> [file_iraq_old]
> gfx = "trident/flags/iraq_old.png"
> grid  = { "dx", "dy", "is_pixel_border"
>   26, 20, 0
> }
> tiles = { "row", "column", "height", "width", "offset_x", "offset_y",
> "tag"   0,  0,  30,  30,  0,  0, "f.iraq_old"
> }

[misc_sprites]
sprites = {"name, "file",
  "f.italy", "trident/flags/italy.png",
  "f.iraq_old", "trident/flags/iraq.old",
}

> the _shields specfile would be similar except:
>
> [file_italy]
> gfx = "trident/flags/italy.png"
> grid  = { "dx", "dy", "is_pixel_border"
>   26, 20, 0
> }
> tiles = { "row", "column", "height", "width", "offset_x", "offset_y",
> "tag"  0,  1, 45,  45,  0,  4,  "f.italy" ; why this is 45x45? holdover
> from engels? }
>
> this is not a complete proposal by any means. I haven't actually attempted
> to do this so for all I know there are serious flaws here.

Hard to say.  Under my suggestion, though, we leave the existing 
functionality in place (meaning existing tilesets don't need changes) and 
simply add a new set of specfile tags.

I agree with the concept: the flags (and eventually other graphics) should 
be split up, making it easier to add new nations.  But editing the 
specfiles should be made easier as well.

Another choice is:

[misc_sprites]
directory = "trident/flags"

and then the files are named after the sprite name in that directory, e.g. 
f.italy.png and f.iraq_old.png.  This means no specfile editing is needed 
(good!), but I'm not sure if it's feasible.

jason