Complete.Org: Mailing Lists: Archives: freeciv-dev: November 2002:
[Freeciv-Dev] Re: civ3 graphics system
Home

[Freeciv-Dev] Re: civ3 graphics system

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: jdorje@xxxxxxxxxxxxxxxxxxxxx
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: civ3 graphics system
From: Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>
Date: Fri, 22 Nov 2002 11:05:12 +0100

On Fri, Nov 22, 2002 at 01:36:27AM -0500, Jason Dorje Short wrote:
> Jason Dorje Short wrote:
> >Raimar Falke wrote:
> >
> >>On Thu, Nov 21, 2002 at 07:19:50AM -0500, Jason Dorje Short wrote:
> >
> >
> >>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've been looking at this civ3 modpack.  The tile system is slick, very 
> slick.  But it is nothing like either our civ1 or civ2 tile systems.
> 
> Most of the terrains are not properly tile-based - they draw the 
> intersections of tiles.
> 
> For instance, look at the xdgp file.  This file contains a 9x9 grid of 
> graphics.  But none of these graphics corresponds a freeciv "tile" 
> (which is a map square).  Rather, they contain the 3^4 = 81 different 
> ways that _d_esert, _g_rassland, and _p_lains can intersect.  Thus each 
> graphic contains one-quarter of the graphics for four different adjacent 
> tiles.  Note that this is FAR superior to the 6^4 system I had 
> suggested, since drawing a tile will take into account all 8 adjacent 
> tiles (not just the 4 orthogonal ones).

I think this is wrong since the bounding box of the tiles are
128x64. This is the same size that the other tiles have. And also the
same size that tiles have on the screen shot.

So we take the 4 major directions (N, S, W and E and not NE, NW, SE or
SW) and choose the graphic. But we don't draw the graphic at the
center of our tile but at where the grid lines meet. Very clever.

> xtgc = tundra + grassland + coast
> xpgc = plains + grassland + coast
> xggc = grassland + grassland + coast [1]
> xdpc = desert + plains + coast
> xdgp = desert + grassland + plains
> xdgc = desert + grassland + coast
> 
> 
> [1] Looks like there are two types of grassland.

> I'm not sure what happens when four different types of terrain
> meet. Perhaps the map generator guarantees this will never happen.

Looks so.

> And I'm also not sure what happened to arctic - does civ3 not have
> this terrain type?

xtgc contains it. Look at any other modpack.

> And it appears tundra cannot border desert or plains.

> The "X" here seems to indicate that these are the basic terrain types 
> (desert, tundra, plains, grassland, coast), which are being blended in 
> some sort of eXtreme fashion.  Or something :-).
> 
> Also note, if we add back in arctic and allow any tile to border any 
> other, we're back to needing 6^4=1216 tiles (instead of just the 
> 6*3^4=486 that they have).  But with the "draw the intersection" system, 
> they will look _much_ better.

> Irrigation is drawn on a per-tile basis.  Each irrigation file contains 
> a 4x4 grid of tile graphics, corresponding to the 2^4=16 possiblilities 
> for adjacent irrigation.  There are two different irrigation files, for 
> PLAINS and DESETT.  I'm not sure what PLAINS and DESETT are.

Irrigation is drawn for 3 different tech types.

> Mountains and hills are drawn on a per-tile basis.  'xhills' contains a 
> 4x4 grid containing the 2^4=16 possible hills.  'mountains' does the 
> same for mountains.  However, the graphic does not fill the entire tile 
> - an adjacent base terrain must be drawn "underneath" it to get the 
> right blending.  I'm not sure how the adjacent terrain should be chosen. 
>  I also suspect that mountains and hills are considered equivalent for 
> the adjacency check.

z-buffer. Start drawing with the farest tile. The nearer tile will
overdraw the farer tiles.

> Similarly, 'hill forests' contain 16 identical hills (identical to the 
> original 16, that is), but instead of being adjacent to an X terrain 
> they are adjacent to forest.  So there's forest on the slopes of the 
> hill.  'hill jungle' does the same thing, for adjacent jungle.  I 
> suspect that if a hill is not ENTIRELY surrounded by hill or jungle, the 
> basic tile will be used.
> 
> Similarly, there is a 'mountain forests' and 'mountain jungle' files for 
> mountains.
> 
> 'Mountains-snow' contains the 16 mountains tiles, but they have snow on 
> them.  I suspect these can also be blended naturally with the other 
> mountains and with hills.
> 
> Forests and jungles I still do not understand.

How much work would it be to produce a hack to use such graphics? 
Basic terrain drawing (no specials or cities). This would allow us to
see if we understood this correctly. And if we can get a GPL from one
of the artists ...

        Raimar

P.S.:
http://www.civfanatics.net/downloads/civ3/modpack/Warpstorm_Watercolor.zip
contains more files.

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "I do feel kind of sorry for Microsoft. Their attornies and marketing
  force must have tons of ulcers trying to figure out how to beat (not
  just co-exist with) a product that has no clearly defined (read
  suable) human owner, and that changes on an hourly basis like the
  sea changes the layout of the sand on a beach. Severely tough to
  fight something like that."
    -- David D.W. Downey at linux-kernel


[Prev in Thread] Current Thread [Next in Thread]