Map API

[renrutal]

I've been looking at the code all night yesterday searching for the right function call, but I couldn't find it. Maybe I should just ask directly to the ones who made the code:

I'm looking for the map loading function, so I could just #include the proper header, compile and call it; it's for an external map analysing program. This is the pseudo-code of what I'm planning to do:

Code: Select all

// I'm not including the obvious checks, includes and other real things

#include <Spring/ArchiveStuff.h>
#include <Spring/MapStuff.h>

int main(int argc, char *argv[])
{
    CArchive archive (argv[1]); // It'll handle all compression, errors and give me an open file
    CMap map (archive); // Loads the map from the archive
    CMetalmap metalmap (map);

    /* Do the metalmap analysis and print info about it.  */
    /* Close the files and clear everything else to exit.   */

    return EXIT_SUCCESS;
}

[renrutal]

*Yawn* No one? Okay, I shall make one then. An alternative to the one used in Spring.

So, tell me, what a map needs , and as importantly: what Spring needs from a map?

[jcnossen]

Map reading code is located in SmfReadMap.cpp. The map format is defined in mapfile.h

[renrutal]

Some questions:

1) Why the map format is an all-in-one binary file instead of a directory structure with multiple files and meta-file descriptor? What are the pros of such structure?

2) I've read the map handling files... well, it's a mess and I really can't understand why there are some data type choices, or even what the variable names really mean... maybe a better way to understand a map are the ingredients needed to make one, and I don't know them all. So:

a) What is exactly the Texture Map? A 32bit full bmp file? A raw file? A lot of indexed tiles? What are the accepted sizes?

b) The height map is just a 8-bit greyscale? Raw? Size?

c) What is the metal map technically speaking? Same format as the height map?

d) What is the feature map?

e) How do you set the map characteristics like tidal power, max and min wind, gravity, map name, etc? Please gimme an example with all the options.

f) How do you place features in the map?

[Maelstrom]

The map sizes can be found in any of the wiki tutorials.

All the picutres are 24bit (full RGB) BMP files.

The texture map (originally) is just a huge bmp file. It is broken up into peices by the map compiler, and is tiled. That is, if a 32x32 section of the picture is identical to another 32x32 section of the picture, they both reference their data to a tile. Its just some simple compression.

The height map is again a 24bit BMP file, but is drawn in grey scale. My tutorial has example pictures, you can look at them for ideas.

The feature map is used to place features such as Crystals, Wrekages, different Trees, and stuff like that. Look at Acid Bridge, Alaska, or a few other maps for example features.

The Metal map is another 24bit BMP. It is drawn in 'red scale' (like grey scale, but only on the read channel). an rgb of 1,0,0 would give full metal, and an RGB of 0,0,0 would give no metal.

After passing these files through a compiler (see Maps:Compiling), you will get two files. A .smt, and a .smf. No idea which file does what, but they contain almost all the information about a map. All that is needed now is a .smd file. This is simply a text document, and can be opend in something like Notepad. This file contains information like Tidal, Sun Direction, Wind power, start positions, description, and stuff like that.

When you have these three files, you have to compress them using 7-zip. This is again covered in the compiling tutorial. You can also open up other peoples maps using 7-zip, to have a look at their files.


Hope this helps

[Gnomre]

Once compiled the maps are in DDS format, not bitmap...

[renrutal]

Once compiled the maps are in DDS format, not bitmap...

Great! I was wondering that with all the DDS talk. Now it makes my life a bit harder

I see. Texture map is really indexed then, like in TA. I wonder why it supports multiple of 1024 instead of 512. Since 1024 means 2 map sizes, all the maps are multiple of 2.

Greyscale in a 24-bit BMP is weird, but using 24 bit for all the files is understandable. How many height levels are there in Spring maps, 256?

Metal map as red scale, maybe it's because it's just easier to draw. 256 levels of metal then.

It beats me why the scale is 1:8 plus 1 pixel

BTW, what the feature map colors mean?

The other options seem to be autogenerated... ok. It's so weird I can't find them in MapConv's source.

[Das Bruce]

Its +1 because there are so many blocks of texture for the heightmap, but if there wasn't that extra heightmap value the last block would dangle off the edge.[/code]

[Maelstrom]

(This is for Mothers MapConv btw, the 'normal' map compiler sucks)

Feature map colours:
Green (0,255,0) - A Geovent
Green of 200 (0,200,0) to (0,215,0) - The 16 different tree types. Note that Spring crashes if trees are on or close to the edge
Blue 0 (0,0,0) to 255 (0,0,255) - The grass density, where 0 = no grass and 255 = full grass
Red (255,0,0) - Place the FIRST feature as defined in fs.txt, found in the 7-zip with the map. Again look at Acid Bridge, Alaska ect for examples
Red (254,0,0) - Place the SECOND feature in fs.txt
Red (253,0,0) - Place the THIRD feature in fs.txt
ect

[Weaver]

Its +1 to define corners of an 8x8 pixel grid (rather than centers) the engine can then give every pixel a height value!

There was once some suggestion that the height map could contain 16bit raw data, if it is still lurking in the code I'd like to try out sometime.

The metal map and type map, are often quoted as needing to be 1/8 texture size or 1/8 +1 the fact is you can put any size you like (with correct aspect) into the standard mapconv. (I haven't tested this in mother's)

Also note the the type map is used by the game at half the height map resolution, which can cause some interpolation issues. eg Using a map with 0 and 255 typemap values can lead to areas with a 127 value which you may not have defined.

The gradient cost map seen when you press F2 is derived from the height map. Only 1/4 of the height map values are used, so it is possible for height map features that are small and carefully placed to have no gradient cost at all. This map is only used for movement, building placement uses height data directly.

Also the last time I checked it looked like units did not consider better routes based on the movespeeds defined in typemaps.

I apologise if this goes beyond the scope of what you were looking for.

[Maelstrom]

units do take the fastest route, even with modified terrain. This is most obvious in a map called PCB or something, where there are very thin 'roads' where the speed is doubled. Units take this route over the direct approach, even though following the roads is a 'longer' trip.

[Weaver]

LOL , I must be be blind, that was my map and test bench! I am glad it works as it should thanks Maelstrom.

[renrutal]

Also note the the type map is used by the game at half the height map resolution, which can cause some interpolation issues. eg Using a map with 0 and 255 typemap values can lead to areas with a 127 value which you may not have defined.

So what is this typemap?

[Das Bruce]

Defines the speed modifiers for different types of unit.

[Weaver]

... and map hardness.

[renrutal]

Ok, so we have:

Texture map, multiple of 1024, composed of two things:
- a tilemap containing a mapping to 32x32 tiles(is the tile size variable?)
- a list of 32x32 tiles, 24bit.

Height map, 1:8 + 1 pixel size, 8bit.
Metal map, 1:8 + 1 pixel size, 8bit.

A feature map, only used to make it easier to fill the map with features, but for real, it's just used to make a text file with a list of features.

We have the map's inner options.

Typemap, 1:16, used to set some special terrain options.

[Maelstrom]

Try actually making a test map by following the tutoroials in the wiki. Then you will get a better understanding of how things work.

The 32x32 tile size is not veriable.

[mother]

There are a whole bunch of files that get compiled into 2 files.

These two files are:


The smt file, which contains the 32x32 DDS format tiles.
The smf file, which is the map metafile.

If has the map header, some representation of what tile goes where, the minimap [dds format], the heightmap[unsigned short(?)], the vegitation map (like 1/64th texture IIRC), a feature header (lists the featuretypes used, seperated by nulls.), then the feature map using data structures containing an int featuretype and a location.

I've not looked at the actual smf format in a while, so excuse me if Im a bit off on the above [specifically the order in which some of the stuff is placed] :)

-------
I don't think there is a simple map-load function that you could easily use. Do you need the graphics, or just the metadata? What are you trying to do with the maps?

[edit]Tomorrow I will try and have a look at the smf format and give you a slightly more definitive answer if that would help[/edit]

[renrutal]

I don't think there is a simple map-load function that you could easily use.
Do you need the graphics, or just the metadata? What are you trying to do with the maps?

I'm trying on thing but this thing is leading me to a bunch of other things:

I'm into AI development and I'm trying to do a metal map analysis to find the best metal extractor placement given the map. I'm going to make a CLI program to test these algorithms, it shall just load a map given the file name and output a text file with the analysis.
For that I need to make a Map class(es) to represent the Map as a standalone object, and from this object I'll take the necessary data, such as height map, metal map, extractor radius, etc.
I'm planning to release that Map class to public.

[jcnossen]

Aren't you making it a bit hard for yourself? Just test the various algorithms within the AI...