-
Notifications
You must be signed in to change notification settings - Fork 3
/
notes.txt
134 lines (88 loc) · 4.62 KB
/
notes.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
MapConv dependencies: boost_regex, boost_filesystem, DevIL.
optional: libtxc (using texcompress_nogui)
The line-endings in fs.txt need to be native.
TODO Learn enough about it to let it be able to cache the texture-tiling
stage and just read the height/metal/features back in again.
This is complicated by geovent placement automatically graffiting over
the texture map.
TODO What does that lowpass algorithm actually do? It looks like it bases
each point of the new heightmap on a weighted average of the twenty-five
point square centered on it, so it'd be a global smooth?
Note: this has only been ported to x86 Linux. Despite the presence of
byteorder.h, it doesn't do the *on-write* swabbing, so a map compiled on a
PowerPC can't be read by anything. :(
For all I know, we're getting the maps upside-down. :S
TODO Check a map compiled under Linux works on Windows...
texcompress
------------
Windows uses the same compressor as always; this is for Linux.
Dependencies: boost_regex, boost_filesystem, DevIL, GL, GLU, GLEW, SDL.
Converts the images given on the commandline (loaded with CBitmap) to the
format required by MapConv, whatever it is. The data is written to
<filename>.raw, which is what Linux mapconv looks for.
This hasn't been tested with any real, serious texture map; just the
tiling-convenient ones in the samples. It may be very slow with, say,
something made by a terrain renderer.
Very crude; I copied hunks of SDL and OpenGL code out of rts/ and spent far
too long fiddling with it to make it go, rather than learning the calls.
It depends entirely on the local OpenGL implementation, so the computer
you're compiling maps on probably needs to be able to run Spring, at least a
little.
TODO
* Check for the type of compression
* GLX rather than SDL?
* check for license issues (GPL vs ?)
Referred to the GIMP's dds plugin for implementation:
http://nifelheim.dyndns.org/viewcvs/gimp-dds/trunk/dxt.c?rev=23&view=markup
Spec.:
http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_compression.txt
On Debian systems, /usr/share/doc/libglew-dev/glew.html looks
like links to the specification for probably every OpenGL extension GLEW
knows about.
Actual image sizes
-------------------
Texture map: A multiple of 1024 by a (possibly different) multiple of 1024.
An unknown amount of Spring and MapConv depend on map sizes being
divisible by 1024.
Metal map: xsize / 2 by ysize / 2.
Internally rescaled to that size, so technically any.
Feature map: xsize by ysize.
The featurehandler *might* be trying to rescale each geothermal placement to
deal with odd-sized images. It does it with ints, though, so I'd avoid using
it.
Oops. Also, the fs.txt-feature placement code assumes the featuremap is
one-eighth the size of the map, I think.
The grass placer rescales the featuremap to xsize/4, ysize/4, apparently the
size of the 'grass-map'. It's binary, and random; the brighter the blue, the
more likely you'll get grass there (on *this* run of mapconv). 0 blue
probably disables it, and 255 blue guarantees grass.
Bitmap.cpp, Bitmap.h, byteorder.h, FileHandler.cpp, FileHandler.h,
filefunctions.h,
are (often cut-down from) the (ported) ones under rts/. Must remember to
merge bugfixes when they happen.
With a bit of luck, MapConv will pass into obscurity in a year or two (from
2006).
* It'd be much easier to make sure heightmaps line up correctly with
the texturemap using nerd256's interactive editor.
http://taspring.clan-sy.com/phpbb/viewtopic.php?p=65100#65100
* This demo of Zaphod's new terrain renderer appears to create a map
with an image of the heightmap, the tile used on the ground, and the
tile used on the mountains. This gives me great hope that a MapConv
won't be needed at all(!); just pack up your source image files with
their .smd.
http://spring.clan-sy.com/phpbb/viewtopic.php?t=3821
These are ready when they're ready, though, so in the mean-time I guess
we still use MapConv.
Proper credit for original source (tarballs!)
----------------------------------------------
0.62b1 spring.clan-sy.com taspring_0.62b1_src.zip
Interesting. So MapConv used to be packed with Spring...
Uber fileuniverse.com UberMapConv-083105.sd7
Looks like the original latest release of Mother's mapconv.
I dunno which is the too-optimized binary and which isn't.
tclap tclap.sourceforge.net tclap-1.0.5.tar.gz
http://sourceforge.net/projects/tclap/
Templatized C++ Command Line Parser. Tarball included
to be on the safe side, or something.
Mental note: there's more than 256 colours on the featuremap in samples/1,
so the GIMP will smash information when trying to index it.