Trouble compiling 28*28 map

[Beherith]

Hey folks, im having some trouble compiling a 28*28 map. (600mb texture)

Both users and mothers mapconv fails on it. Mothers says it cant open texture file (totally standard properly sized bmp), users just crashes after trying to load texture.

I managed to get a test compile done with Springmapedit, but for some reason it couldnt import my metal map and my feature map for my geos. It was expecting some funky format for features. But I dont want to make a final compile with SME because I cant set tiling compression, and it results in an 80 mb map, which I find unacceptable.

[smoth]

try saving your bmp texture as a jpg mapconv has issues with large file sizes.

[Beherith]

Thanks, jpeg worked :) It even failed with a 300mb png tho.

[Frostregen]

Sounds like a feature request

1. The "funky feature format" or .fff,
err "feature map format" -> .fmf, is just the same format as it will be "compiled" later within the smf. (This is to store rotation, which mapconv-bmp's cannot do)

2. Metalmap failed? Was there some kind of error inside the black window after trying to load?
(May be hidden under renderwindow)

3. How does tiling compression work?
-By blurring the whole map, creating more identical tiles?
-By just ignoring little differences and using a similar tile anyway?
-Both?
-Something else?

[Beherith]

Well, I imported a standard metalmap, size 1793*1793 (28*28), and nothing happened, even after waiting alot. No metal spots show up in SME metal view and in spring.

How do I place geos in SME?

IIRC tiling compression works by ignoring small differences in tiles and using the same ones instead.

Btw, editing maps this size in SME is quite a pain even though I have a nuclear plant of a pc. Might be that I only have 2gb ram, since it allocated 2gb on the spot for a 32*32 map :)

[smoth]

3. How does tiling compression work?
-By blurring the whole map, creating more identical tiles?
-By just ignoring little differences and using a similar tile anyway?
-Both?
-Something else?

The map converter slaps your texture ino 1000s of dds tiles, then does a very shit compression where by it halfasses tile comparisons and then gives you a map with a series of tiles worse than early avi video compression.

the blurryness comes from in game mipmap levels.

[Frostregen]

@Beherith:
If the map does not load, there should be an error in the console.

I checked the sizes. Since the metalmap is a texture, working on tiles - not on vertices, the dimension is without the +1. (Yes, mapconv expects the +1 pixel, but I don't know why...makes no sense to me) (Inside Spring it is without +1 pixel too...)

Make it 1792*1792 and it should work. (The console should have printed a message indicating the wrong(unexpected...) size)

A 32x32 map should only allocate around 1 GB. (2 GB only, if you used quicksave...)
Main memory eater is the texturemap with 768 MB.
I have 2 GB of RAM too, and it works ok.
You can improve the fps by lowering the LOD levels a bit.

@smoth:
Sounds like you love this feature
I'll look into it. I only need a hashing algo for compressed DXT1 textures, which maps tiles appearance in a linear way (So i could strip of the least significant bits, and done)
(Currently it reuses only 100% identical tiles)

[Forboding Angel]

behe, mothers mapconv does not support png