[Freeciv-Dev] images implementation (was: Minor adjustment of Norwegian flags and shield....)

[Jeff Mallatt <jjm@xxxxxxxxxxxx>]

At 2000/08/06 17:08 , you wrote:
>[I can't help to notice that you keep removing the freeciv lists from
>the Cc: list.  Is it just oversight, or do you have some reason to
>keep the discussion private?]

No real reason -- I just didn't think it would be interesting to everyone.
However, now that the subject has broadened, that may be completely wrong.
So, I'm changing the subject and sending to the freeciv-dev list.

>Jeff Mallatt <jjm@xxxxxxxxxxxx> writes:
>>
>>><STUPID QUESTION> Why not keep all the flags in one long column,
>>>rather than having several in each row?  The main disadvantage (unless
>>>there is some xpm magic that I don't know about) would be that this
>>>layout doesn't look good when you load it all into the GIMP or
>>>whatever, but if the preferred form for new flags as well as fixes to
>>>old ones is a small xpm file then this wouldn't be much of an issue.
>>></STUPID QUESTION>
>>
>> Not stupid.  A potentially good idea -- I can't think of any problems,
>> beyond it maybe being difficult for some graphical editors to deal with --
>> but I just tried Gimp, and it worked fine with a 45x4500 image.
>> 
>> Also, I'm not certain that it would solve the merge problem -- that depends
>> upon how clever patch is. :)
>
>What merge problem?  With a maximum of one line per flag, different
>patches that modify flags formerly in the same row will no longer
>interfere with each other.  There might not be too much in the way of
>"unique lines" for patch to grab hold off in case of offset patches,
 ^^^^^^^^^^^^^^

This is my only worry.  Don't know until a test is performed.

>but since the flags all have a fixed size I see no reason why this
>would ever occur.  Old flags can be patched in place, and new ones
>added to the end.  The only problem that I can see is when the need
>arises to remove a flag entirely.  In that case, it would be enough to
>move the last flag on top of the one being removed.  As long as not
>too many different people do not try to remove too many flags at the
>same time, this shouldn't pose much off a problem.

Even a single flag appended will completely disrupt the "unique lines" at
the end of the file.  Again, if patch is clever enough, it may work.

>> Ultimately, it would be nice if a Nation could be built into a small
>> bundle that wouldn't depend upon "group" flags/shields files.
>
>True.  This would also make it easier to implement "mix and match"
>nation.rulesets efficiently.  I think you could get away with simply
>embedding the flags in the current nation.ruleset files, in much the
>same way that maps are embedded in savegames.  It would no longer be
>possible to edit them directly with a paint program, off course.  (Or
>one could write the images from a picture into the nation.ruleset at
>build time.)

If you put the entire .xpm file into a ruleset file, then just extracting
the appropriate lines would yield an editable .xpm file.  A simple perl
script could be written to do it.

Also, I'm not sure that putting images in rulesets is a good idea.  The way
things work now, that would imply that we transmit the images from the
server to the client across the (potentially slow) wire.  Yes, this has
advantages of flexibility, but it may become unreasonably slow to connect
to a game.

>> But, this could get difficult...
>
>You'd have to splice together little pixmaps from all over the place.
>A pain in the revered behind to write, but presumably not too
>difficult.

The difficult part is that you're not just adding a (singular) flag, but
that you are adding several (the Engels flag, the Trident flag, the Shield,
perhaps more in the future... perhaps Engels/Trident may not exist in the
future...).  The best way to do this, IMO, is not to tie an image and
ruleset entity together by name, but provide "hints" so that the client can
choose the correct flag on the fly.

Also, if this is implemented correctly, common routines could be used to
provide the same in-ruleset-images functionality to more than just Nations:
Units certainly.  Perhaps Terrain?

jjm