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

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

On Thu, Nov 21, 2002 at 07:19:50AM -0500, Jason Dorje Short wrote:
> Raimar Falke wrote:
> >On Thu, Nov 21, 2002 at 04:32:21AM -0500, Jason Dorje Short wrote:
> 
> >>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).
> 
> Look at pixmap_put_tile and pixmap_put_tile_iso in mapview.c.  Some of 
> the differences are because of isometric/non-isometric, but many are 
> because of the "new" versus "old" drawing systems.
> 
> >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.
> 
> I _strongly_ disagree.  The old system is fundamentally broken, whereas 
> the new system is elegant and extensible.
> 
> An example of the limitations the old system runs in to is that 2^4=16 
> tiles simply is not enough.  If you manually blend this tile with the 
> adjacent one, you have to assume all adjacent tiles look the same.  In 
> trident, this means that if desert and plains - or desert and arctic! - 
> are adjacent, there will be grassland between them.  To account for all 
> possibilities, you will need at least 5^4=625 tiles for each terrain 
> type, since each adjacent tile can be one of any of the 5 basic terrain 
> types (ignoring jungle).
> 
> In isotrident, the blending is done automatically using a mask (called 
> dithering in the code, although Vasco tells me it shouldn't be).  This 
> means grassland, plains, desert, tundra, and arctic (which are all 
> simple 2d terrain types) can easily intermix.
> 
> I've put up some screenshots at http://freeciv.org/~jdorje/.  Compare 
> trident.png to isotrident.png.  The difference between the two is 
> incredible.  The new system is overwhelmingly better.
> 
> Especially, look at the border between the grassland and desert in the 
> upper right of the screenshots.  Even this common scenario can't be 
> handled by the old system.
> 
> The new system is extensible.  Right now there is a single blending mask 
> that provides the border betwen two terrains.  To get a different 
> blending depending on what other tiles are adjacent, all we have to do 
> is change the mask.  Some thought will have to be given on how this will 
> work with eye candy, but this is not insurmountable.

While automatic blending is nice it can't produce the same results as
if it was done by hand. Look at
http://www.civ3.de/www/content/misc/images/terrain-original.jpg. Look
how the hills around the mine are blended. Look at how the south coast
is blended. Especially at the coast you can't tell which tile is ocean
and which is land. This is a good thing IMHO.

While I don't have any clue about how does the graphic engine of civ3
works the contents of this modpack
http://www.civfanatics.net/uploads2/cordy-terrain.zip reveals that
they also work with a system which is similar to our old one. Leaving
the extra height out of this the tiles of Mountains-snow.pcx are very
similar to our 16 tiles. In the x* files they blend three terrain
types. And yes these are a lot of tiles.

I think that the results show that they got this right. While I'm not
for coping their graphics/approach 1:1 I want to know why we don't do
the old way in the iso case. And the only answer I have is: because it
requires less graphics and so it was a solution which brought results
(i.e. a working iso-mode) faster.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Life is too short for reboots."