[Freeciv-Dev] Re: (PR#2369) iso-view eye candy

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

Daniel L Speyer via RT wrote:
> On Wed, 20 Nov 2002, Jason Short via RT wrote:

>>- Eye candy types are linked after we receive ruleset data.  This will 
>>allow things to work under alternate rulesets (untested).
> 
> What's the issue here?

For each terrain type (that is, terrain type ID) the server sends the 
client information about the terrain.  This includes the name of the 
terrain, as well as what graphics to use for the terrain.

For instance, the sprite t.swamp is traditionally used for the T_SWAMP 
terrain.  But as far as the client knows, the server could completely 
redefine this and send a different string telling the client to use 
different graphics.

All of this is done so that modpacks may work intelligently.

get_terrain_name returns the name of the tile, as sent by the server. 
But this isn't known until we connect to a server.  This is what first 
clued me in that something was wrong.  I used the terrain name to build 
the eyecandy sprite name - which is less than ideal since it is 
capitalized.  However, it automates the process and will allow things to 
work intelligently if for instance the server redefines T_GRASSLAND as 
"Ocean" (or, more likely, as something completely unknown).

I'm not sure how much of this functionality currently works in CVS.  It 
looks like the _number_ of terrain types is hard-coded by T_COUNT.  But 
I do not want to break future developments.

Note that hills, mountains, and forests are drawn "over" another terrain 
type.  I'm not quite sure how this works with rulesets, but for eyecandy 
it means it will be very difficult for tileset authors to make useful 
eyecandy for these terrain types.  I haven't figured out a good way 
around this - but since terrain types already have more variety (in the 
same way trident does) it is not as much of an issue.

>>- The number of eye candy sprites is not limited to two per terrain type.
>>
>>- Only one eye candy can be shown per terrain type (of course, you could 
>>just make another graphic with the combination).
> 
> I think this may need a little reworking.  Your formula puts one or no
> eyecandy on each tile with equal probability.  In my examination, I found
> that to be too much.  It will probably be nessesary to include blank
> eyecandies.

It certainly does have its issues.  However, with an unlimited number of 
eyecandies drawing them independently is not an option:

- It will take O(n) time.
- It becomes progressively harder to make sure the eye candies don't 
conflict.

I also found that with a higher chance of no eyecandy things just didn't 
look good in the current case.

> Consider: to duplicate the present desert eyecandy effect, 24 eyecandies
> will be needed:
> 15 blank
> 4 with a cactus
> 4 with a skull
> 1 with both
> 
> Granted, each candy need be *drawn* only once, and multiply referenced by
> the spec file, but this is a rather tiresome way to do it.

True, and if you can find a better way to do it that would be great.

But here I think there is a good alternative: instead of spending your 
time doing that, the tileset author (i.e. you) could instead make 2 or 3 
new eye candies.  This will probably give much better results anyway.

> Perhaps some mechanism should be included for stating probabilities in the
> specfile?  Even so, mannually drawing combinations requires exponential
> effort, but the numbers are likely to remain small enough for this to be
> sane.

I thought of that, but I haven't yet seen how to make it workable.

>>- A view option is provided controlling whether eye candy is drawn. 
>>(There's no MUI support, and win32 support is untested.)
> 
> This has always been there.

Err, say what?

> And one change omitted from the list:
> 
> - Multi-dither is removed from the patch, hopefully for seperate inclusion
>   later

Oh, yeah, I forgot about that :-).

Actually, the main point of this was to separate multi-dither from eye 
candy.  They are completely separate effects.  Eventually, I think 
multi-dither should get some of the same fixes eye candy has 
(unrestricted number of blending masks, for instance).  But this is a 
separate issue.

Note also I've opened a new RT issue for this, and made the 
eyecandy+multi-dither issue its parent.  The same should be done for 
multi-dither, whenever we/you/I get around to preparing that patch for 
inclusion.

> All in all, it looks good.  And thanks for picking it up when I dropped
> it.

No problem.  But let's get some combined effort to get this this 
finished and into CVS.

jason