[Freeciv-Dev] Re: (PR#3708) new isotrident_shields tileset

["Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

On Sat, 2003-03-22 at 17:40, DHerding@xxxxxx wrote:
> Hello Jason,
> 
> Friday, March 21, 2003, 10:33:28 PM, you wrote:
> 
> 
> JS> When I try to use it, I get a bunch of warning messages like
> 
> JS> 1: warning: already have a sprite for f.serbia
> 
> This is strange. In fact, my isotrident_shields.tilespec has included
> "isotrident/flags.spec" as well as "isoshields/shields.spec", which
> probably leads to that warning. I used it because, in case someone
> updated his flags but didn't update his shields, Freeciv will show the
> flag instead of nothing when using isotrident_shields. See comment in
> tilespec files:
> 
> ; Below, the graphics spec files; must be somewhere (anywhere) in
> ; the data path. Order may be important for color allocation on 
> ; low-color systems, and if there are any duplicate tags (lattermost
> ; tag is used).
> 
> I thought this means that it wouldn't lead to problems when e.g.
> f.serbia is duplicate, and freeciv would simply use the one from
> isoshields/shields.spec. I also can't reproduce that warning.

You may need to compile with debugging, i.e., configure with
--enable-debug.  It is just a warning...

> JS> and then the isotrident_shields ends up looking exactly like isotrident.
> JS>  I also get this (under your "patch") when using trident_shields.
> 
> Maybe you didn't extract the files to the correct directories? (you
> must create a subdirectory 'isoshields' in the same directory where your
> 'isotrident' subdirectory is)
> 
> Also remember that e.g. in the GTK distribution, you have XPM files
> which are preferred against PNGs by Freeciv. When you copy the PNG
> files from my archive, make sure to delete any XPMs that have the same
> names.

I know I unpacked the files properly (otherwise there would have been
*no* change).  However, as I said my installation is cluttered.  I'm
running freeciv out of the source directory, while it may end up taking
the graphics from the installation directory if I (accidentally) have an
installed copy as well.  (As a side note, I'll be using a different
computer for the next week so this is not reproducible.)

My point is, although this is unusual it is not unique.  The tileset
should be able to deal with it.  That's why I recommend you don't
*change* any files, just *add new ones*.  All your new .png and .spec
files should (IMO) go into a single isotrident_shields/ directory that
you create.  Note that a "new" .spec file may make use of an "existing"
.png file.

> JS> I have a lot of other tilesets installed in different locations, and
> JS> possibly different PNG or specfiles are conflicting with each other. 
> JS> But this shouldn't happen if the tileset is structured properly.
> 
> JS> For development of the tileset, I'd recommend not *replacing* any of the
> JS> files from the standard distribution.  If you need to change something,
> JS> just introduce a new file (you can still use the old graphics files,
> JS> referenced by your own specfiles - just don't change any graphics or
> JS> spec files).  Then the tileset can be added to the set of contributed
> JS> tilesets, and it can be easily downloaded and used.
> 
> That's exactly what I tried to do. Take a look at units.png, or
> tiles.png. I only entered the graphics that are different from the
> isotrident ones, and my tileset will share the other graphics with
> isotrident / trident_shields.

Right - in this case (I think) you have simply created new .png files
(with just a few of the changed sprites), and new .spec files (that use
both the new and the old .png) files.

> The problem e.g. with isotrident/shields.png is that I can't use the
> original files because I need some transparent pixels left to the
> shields, and above it. But the authors of shields.png set the first
> shield to the upper left of the file, so I had to insert some
> transparent lines/rows to the file.

I believe you can do this by setting a negative offset for the grid -
but I heard a rumor that this doesn't work well with the win32 client.

> I'm aware that this will conflict with any other specfile that
> accesses shields.png/chiefs.png. But I think it's a necessary step to make
> possible what you described above.

Ideally, each sprite would have *no* padding, and its drawing offset
would either be specified by the tileset or calculated automatically. 
The problem is this is difficult to do with the current grid system.

jason