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

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

On Thu, Nov 21, 2002 at 04:32:21AM -0500, Jason Dorje Short wrote:
> Raimar Falke wrote:
> >On Wed, Nov 20, 2002 at 04:12:12PM -0800, Jason Short via RT wrote:
> >
> >>To answer a question I've received...
> >>
> >>Eye candy is an idea Daniel had a little while ago, to give isometric
> >>tilesets the same variety that non-iso tilesets have.  Non-iso tilesets
> >>have lots of different copies of each tile, because that's the way the
> >>blending between tiles is done.  This is bad and meeans a lot of work
> >>must be duplicated - but it does allow for a lot more variety.  For
> >>instance the trident desert tiles have cactuses, skulls, rocks, and
> >>grass scattered around.  By contrast, isotrident's desert is very plain
> >>- just mile after mile of sand.
> >>
> >>The eye candy patch allows sprites to be declared which will overlay the
> >>terrain tile.  For instance in the desert the skull and cactus each have
> >>their own sprite, which is drawn on top of the desert at pseudo-random
> >>intervals.  Daniel has also created support for this in isotrident
> >>(although there is nearly unlimited room for improvement here IMO).
> >
> >
> >Why is a second way introduced here? Why not use the non-isometric
> >way? I.e. have 16 versions of the same terrain and use one depending
> >on the neighbors? If this isn't possible I'm for implementing the
> >isometric eye-candy also for the non-isometric case.
> 
> The isometric ('new') way is "better" than the non-iso ('old') way.  We 
> don't want to go back to the old way, which requires lots more tiles and 
> (arguably) doesn't look as good.
> 
> The long-term goal for the old method IMO should be for it to go away. 
> Vasco can correct me if I'm wrong here, but my understanding is that the 
> 'old' way was the original freeciv design.  When isometric mode was 
> written, this was taken as an opportunity to redesign things (also 
> that's the way civ2 works).  So the 'new' way, although it has nothing 
> to do with isometric mode per se (AFAICT), is associated with 
> is_isometric throughout the code.  In tilespec.c it's rather obvious 
> which is which (and in mapview_common also, I think), but in 
> gui-xxx/mapview.c it is not.
> 
> Thus, my feeling is that the old method should be left as-is for now. 
> As the reduction of gui-xxx/mapview.c continues hopefully we'll reach a 
> point where non-iso tilesets can use the 'new' drawing method.

This has nothing to do with mapview.c. It is all about what tilespec.c
returns via fill_tile_sprite_array(_iso).

I think that the "new" isometric system is worse. Reason: without
information about the neighbor tile you can't do anything depending on
them. This means that the isometric system will always have quadratic
(or parallelogram after the transformation) tiles. This is IMHO
bad. IMHO we haven't fixed this not because the new system is better
but because we don't have this much graphic content (only one instead
of 16 versions of a terrain tile). If we at some point fix this the
eye candy becomes rather useless. Because then you only have the
guarantee that the center region of a tile contains the original
terrain type and so you can only place the cactus or skull at the
center.

So if you want to improve the diversity of the isometric view I'm for
adding these 16 variations of the base tile. This gives diversity
_and_ non square tiles.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  This customer comes into the computer store. "I'm looking for a mystery
  Adventure Game with lots of graphics. You know, something realy
  challenging". "Well," replied the clerk, "have you tried Windows 98 ?"