mapconv compilation issue. noob mistake?

[floatingpoint]

Hello, I am new to the forum and map making. And after 3 full days have FINALLY got my first test map to compile without crashing and with the texture visible.(My biggest issue was with gimp default bmp export format not working. (had to choose the option to remove color header information and also select 24bit bmp instead of 32bit if anybody else is fighting this.))

Now i have an inexplicable problem that maybe someone can shed some light on.

screen00007.png

edit: figured out how to take a screenshot of the issue:

The metal spots on the texture all line up PERFECTLY with the metal map. The height map seems to be different from everything else once compiled.

(1.81 MiB) Downloaded 2 times

The texture and height maps do not line up perfectly. There is significant warping. In some places on the map it lines up, and in other places it is off by quite a bit. When I overlay the height and texture images in gimp they line up perfectly. Maybe it has to do with the compression or tiling options? I don't understand the compression and tiling stuff very well and i have seen some comments to the effect of "pro map builders don't use compression" What is the preferable -z option string for a basic map with no fancy crap.

here is my mapconv batch file:
-----------------------
MapConv -x 200 -n 100 -o FP_MyIsis_V2 -t _Texture.bmp -a _Height.png -m _Metal.bmp -f _feature.bmp -z "nvdxt.exe -dxt1a -nmips 4 -Sinc -quality_highest -file"
----------------------

I can zip up all the images too if that is relevant.

Thank you for any help.

[Forboding Angel]

What were the dimensions of the texture map and the height map?

Don't use compression. It sucks.

Well, thanks to knorke, if you looked at the map development page in the wiki, you would have gotten no decent information.

http://springrts.com/wiki/Map_development

^^ Follow that and you'll be fine.

[Silentwings]

I don't think the problem is with the compression/tiling - like forb says the first thing to check on is the dimensions of the height/texture/metal maps. I'd also recommend not using the -z argument while you're bugfixing. (maybes it's needed on linux? idk)

It would help greatly if you could pastebin the output from mapconv. The person who knows most about mapconv and who can almost certainly solve your problem is Beherith.

Most map makers do use compression. Almost all maps that are played online currently use compression. With current net speeds if its >30mb or so you'll struggle to get enough people together who can be bothered to download it.

Luckily the compression in mapconv works very well and you can use -c to control how much compression it applies (I recommend -c 0.6). Of course if you're making maps for your particular game that you'll release as a standalone object one day, you won't need compression for sake of download times and you might even decide not to use any.

[Forboding Angel]

No, do not use compression. Period.

A highly complex texture of a 16x16 map will compress to 27 mb once archived.

The less complex your texture is, the smaller it will be. Mapconv compression should not be used, ever. Why? Because the benefits of mapconv compression do not take place until the point where you have highly visible artifacts,

Mapconv compression will not get you any results worth having.

[Silentwings]

Mapconv compression will not get you any results worth having.

Almost all maps that are played online currently use compression.

[Johannes]

I don't think that's true.

[Beherith]

The -z param you supplied is unnessessary, as that is the default. A -c of 0.2 gives you a little file size edge, while remaining nearly unnoticable.

I suspect there could be a version conflict; delete all previous versions of your map from the spring data folders, and double check your file sizes.

Another possibility is that your heightmap or texture map is getting flipped. Please try compiling with the -i option.

Other than that, welcome to Spring! Its always nice to see new mappers :)

[floatingpoint]

Thanks for the help everyone :). Given the replies it sounds like mapconv compression is not the likely culprit. I will try the -i option as it sounds totally reasonable that the heightmap is getting flipped.

The replies leave me a bit confused about compression but that may be a different thread question another day. Filesize is way low on my list of concerns right now, I just wanted to make sure it wasn't affecting my current problem.

Thanks for the link to the PROPER wiki page for mapdevelopment noobs. I think that is ultimately the one that I took the most information from. As a new map maker I had a hell of a time finding good information on the subject. There is alot of contradictory and old information and it is tough to figure out what is the current best tools to use. ie. mapConv vs MothersMapConv vs mapConvNG? Use an smd file or the blueprint lua stuff? I'm not really looking for an answer here but trying to point out the confusion to the community. I am sure you all have well established workflows and haven't had to think about this from the eyes of a noob for awhile.

And thanks for the welcome, I have been playing Total annihilation with roommates and friends since the original. And am constantly blown away by the developments in spring. Thank you all for helping to make it happen.

d-_-b

PS
When I get a chance I will see if the -i options works and let you know, else I will post the mapconv output.

[Forboding Angel]

Another possibility is that your heightmap or texture map is getting flipped. Please try compiling with the -i option.

Other than that, welcome to Spring! Its always nice to see new mappers :)

Oh shizzle. Nice catch behe

[floatingpoint]

beherith with the win1 -i option in mapconv fixes my issue. WHY i need to flip the heightmap is a mystery to me. But i am fine with mysteries so long as I can do what i need to.

Thanks!
d-_-b

[Forboding Angel]

Because everything in spring is backwards (and no, I'm not kidding -_-)

[Beherith]

The reason you need to flip the heightmap is that Spring's origin (0,0,0) is in the top left corner. Most images use the bottom left corner as origin.