Making map filesizes smaller

[LOrDo]

I'm currently in the process of making a 24x24 map, unfortunatly, the filesize is so large that I don't see how I can realisticly release it.
Is there any other way to make the maps overall filesize smaller other then changing the compression to a rediculous amount?

(I can show teaser screenshots of the map if thats what it takes for a response :D)

[Neddie]

Uhm... I don't think you can apart from reducing quality of the images used.

[pintle]

how about some teasers just for the hype-generating value?

[ralphie]

Use more tiling textures.

[Neddie]

Uhm... I don't think you can apart from reducing quality of the images used.

We already covered that, ralphie.

[LOrDo]

Bryce uses prodcedural generated textures. So I always find putting in tiling images difficult.

[smoth]

Use more tiling textures.

lies.

Look people. The problem isn't necessarily the using more tiles but how the tile's similarity is compaired. There is a problem with it. I doesn't not really do a good job compairing tiles and often times will use the wrong one. "but I used a repeating tile blah blah" well guess what, it repeats soo often that when it uses a bad tile you cannot tell because: A, the detail texture is covering it or B, your tiles all look so similar it is hard to tell.

No the mapconv does a shitty job of compression and uses the wrong tiles frequently. I am not taking up the task of fixing it either. "using tiles" doesn't work. It only seems to work. Mapconv is really quite crude.

[ralphie]

What on earth are you talking about?

[hunterw]

let me try to explain.

compressing textures in spring is acutally really quite similar to the method used in OTA...everything is cut up in to 16x16 (or is it 32x32?) tiles. all of them are compared, and if two tiles are similar, only one is saved and it is referenced in place of both of the others.

when using mapconv, the -c number is an arbitrary value that determines the tolerance range for how similar tiles can be. if the number is high, tiles that are sometimes very dissimilar will be merged, your map will be a smaller size, and you may notice some ugliness. if the number is low, tiles that are sometimes very similar will not be merged, your map size will be huge, but your original texture will be preserved.

this tiling compression has to be done, or a 16x16 map will be about 120 megs. i usually use 0.2 or 0.3 to avoid ugliness but still have a reasonable sized map.

to see what tiles look like when they are dissimilar but are compressed/merged, look at altored divide.

[LOrDo]

I haven't understood this entire thread...but to sum it up I'm screwed?

[hunterw]

to sum it up, keep using different -c values until you have a good balance between not too ridiculously huge of a download and not shitty looking

also (obviously) have the ultra compression set for the .sd7 archive

[LOrDo]

I heard rumors about sd7 being the source of desync, is this at all true?

[smoth]

we know that sd7 can cause slowdown as you read the file so there is suspicion about it causing issues for machines that are on the slower end.

[Tobi]

The map is entirely loaded on the start though, so at worst people on really slow machines drop out of the game on start.

(I measured the difference between sdz and sd7 once, sd7 was about 6 times slower to load then sdz)

[very_bad_soldier]

It seems to be vital to disable solid archive functions in 7zip when crunching the map. An enabled solid function takes ages to load in spring.

[silent303]

yes i can confirm what very bad soldier says, solid archives are crap for sd7 and spring.