From 51fc7c6f22e645dc6076f6872a0da660d2242da2 Mon Sep 17 00:00:00 2001 From: avolkov Date: Wed, 26 May 2004 20:43:49 +0000 Subject: [PATCH] Planet surface rendering info git-svn-id: svn://svn.code.sf.net/p/sc2/code/trunk@1365 8092fc87-c524-0410-9efc-e669fe64eaf9 --- sc2/doc/devel/planetrender | 42 ++++++++++++++++++++++++++++++++++++++ sc2/doc/devel/strtab | 20 ++++++++++++++++++ 2 files changed, 62 insertions(+) create mode 100644 sc2/doc/devel/planetrender diff --git a/sc2/doc/devel/planetrender b/sc2/doc/devel/planetrender new file mode 100644 index 000000000..48e25f0fd --- /dev/null +++ b/sc2/doc/devel/planetrender @@ -0,0 +1,42 @@ +Planet surface rendering code +-------------------------------------------------------------- + +The way the planets appear on the screen (based on planet type +definition in plandata.c) is determined by several factors: + +1. Topography algorithm (PlanetFrame.Type) +2. Color map (PlanetFrame.CMapInstance) +3. Elevation -> colormap index xlat table (PlanetFrame.XLatTabInstance) +4. Base elevation (PlanetFrame.base_elevation) +5. Several others not covered here: faults, craters (blemishes) + +First, the planet topography is generated according to the algorithm +selected for the planet: TOPO_ALGO, CRATERED_ALGO, GAS_GIANT_ALGO. +TOPO_ALGO and CRATERED_ALGO use a fractal algorithm to pseudo-randomly +generate a surface, then 'craters' are added and, at the end, the map is +dithered for CRATERED_ALGO. GAS_GIANT_ALGO is of course different +because it needs to produce a series of ring-like structures with +'storms' added at the end. + +The topographical map is a rectangle with each pixel representing an +elevation level relative to 0, so the topography is expressed in terms +of elevation relative to base elevation. Base elevation is applied to +the generated map. + +At this point, the elevation levels are translated to the actual colors +using the xlat table and color map. First, the elevation is translated +to an index into the colormap using the xlat table (.xlt files), and +after that, the actual RGB color is drawn from the colormap (.ct files) +at this index. + +There are 3 colormaps per instance specified in PlanetFrame. The active +colormap is selected from these 3 based on the surface temperature of +the planet: cold, normal and hot. The framework is also laid down for +3 xlat tables (one per surface temperature), but, AFAIK, distinct xlat +tables are never actually used. Currently, there is only 1 xlat table +per instance in each file. + +The colormap files (.ct) seem to be in original DOS format. Probably +because they do not translate to the CLUT system very well. The colormaps +are carefully crafted and synchronized across all planet types to make +the entire system function properly. diff --git a/sc2/doc/devel/strtab b/sc2/doc/devel/strtab index 0d3af6eb9..f111db4f6 100644 --- a/sc2/doc/devel/strtab +++ b/sc2/doc/devel/strtab @@ -38,6 +38,26 @@ The full palette contains 256 values, which are the original 32 values multiplied by 1 to 8. +For .ct files (planet surface version; in ipanims) an item is as follows: + 1 Index of first color in this colortab. + 1 Index of last color in this colortab. + Then for each color (6 bits per channel): + 1 bits 0-5: red value + 1 bits 0-5: green value + 1 bits 0-5: blue value +The planet surface palette files were probably copied verbatim from DOS version +and left alone because they do no exactly fit into the whole CLUT system. + +For .xlt files (planet surface; in ipanims) an item is as follows: + 2*3 3 elevation levels (not used, probably informational) + 1*256 256 colormap indices each corresponding to a particular + elevation level 0..255; only colormap indices 128..255 + can be used currently because colormaps only define + colors 128..255 +The .xlt files combined with planet surface .ct files are used to select colors +for planet surface rendering. + + For .snd files an item is as follows: N-2 Signed, 8-bit, 1 channel PCM samples of the sound effect, where N = (length of string)