mapconv

[user]

i will edit the tile size on mapconv code not spring, editing on mapconv
will have no problem for old maps.

so switch to jpg?, there are lots of other image formats suported by devil.

[user]

i will post here the formats suported by devil, just wait a few minutes.
i will post only the formats it can save.

windows bitmap: .bmp
C-style header: .h
direct draw surface: .dds
jpeg: .jpg, .jpeg, .jpe
pallete: .pal
Z soft: .pcx
portaple network graphics: .png
pnm .pbm, .pgm, .ppm, is pnm good?
raw data: .raw
sillicon graphics: .sgi .bw .rgb .rgba , these are just like .raw images
targa : tga
and tif: .tif .tiff , these are raw data, like .raw or .sgi

[Argh]

Well, since the temp files are all PNG, it won't make any difference in the DDS compression rates, and it took forever to convert from JPG to PNG to make the tiles. Hmm...

Yeah, switch to JPG. It's smaller, and JPG --> DDS should be a lot faster than anything --> PNG --> DDS.

I think that will be faster than PNG when converting to DDS, by a very wide margin, and it won't have an alpha channel to screw stuff up.

[Argh]

Well, now I'm going to really test nvcompress, see what happens. I don't have CUDA support, and it doesn't have nearly as many features as nvdxt does, but CUDA-qualified users might be able to process giant maps at a very fast speed, might as well see how well it actually works...

[user]

do you know why the SMALL_TILE_SIZE variable is 680?

[user]

i think it is the amount of bytes for a rgb 32x32 dxt compressed image with 4 mips.

what would be the size for a rgba 32x32 dxt3 or 5 compressed with 4 mips?

[Argh]

Better yet, 8 mips... then we get the entire speed benefit...

[Argh]

16 bytes per pixel (uncompressed)... so lemme do the math...

[user]

i will make an option for choosing the small_tile_size, so we can test it very quickly.

and it is 1 byte per pixel for every color in every mipmap

[user]

changing the tile size wont work, look here:

https://spring.clan-sy.com/svn/spring/t ... /mapfile.h

it is defined in mapfile.h in the source, i could maybe try to edit the source, increase tilesize, and make the maps version to 2.

[Argh]

Aha... that explains a lot, then. The map-file reader would have to support more than one version, to support, say, 9 mip levels (really gotta wonder why 4 was chosen as the default)... otherwise you'd break every existing map

That also explains why DXT1 works, but DXT5 doesn't, though- it has that extra 8 bits per pixel...

[user]

yes 10 mips(default in nvdxt) would make maps much more detailed, i think it would.

and when was the last update to the smf map file format?

dxt3 and 5 works for units and skyboxes, i dont understand why for maps not.

[user]

i will test

Code: Select all

nvdxt.exe -file temp\*.png -nmips 8 -dither -point -dxt1 -fadeamount 0

to see if its really line free.

mapconv 1.0 will use jpg for the tiles, and will have an option for
a text file with a bunch of options such as ignore height when
creating features.

[Argh]

when was the last update to the smf map file format?

Er, tbh, I doubt if it's been updated since it was first released.

I am testing this, to see if there aren't any lines:

Code: Select all

nvdxt.exe -file temp\*.png -nmips 5 -dxt1 -box -fadeamount 0

[Argh]

No lines, whatsoever. And good performance, too. I boosted the maxheight up to 700, just to really distort it (it's supposed to be around 400-500) and no problem. I'll try something crazy, like 1200 next.

I swear it was probably that silly fade setting, this whole time...

[user]

just found out why the size is 680.

look at mapfile.h:

Each 32x32 tile is dxt1 compressed data with 4 mipmap levels. This takes up
exactly SMALL_TILE_SIZE (680) bytes per tile (512 + 128 + 32 + 8 - ).

the size of 32x32 is 512. ((32*32)/2)
the size of 16x16 is the size of 32x32 / 4.
the size of 8x8 is the size of 16x16 / 4.
the size of 4x4 is the size of 8x8 / 4.
in bytes.

[user]

jpg is faster,but not alot,

and what would be cool to add to mapconv for version 1.0?

it has -w text file , that takes a file with options, such as ignore height
when creating features.

[aGorm]

Not thats Ive entirly read this... but speed in compileing is not an issue. Let it take as long as it needs, Its not like every user will have to do it.

And Jpg's aren't lossless, rule of thumb don't re compress compressed files with another compressor. So don't remove PNG support, as there lossless, best to keep things in teh lossless world till the end.

Also, smf was updated, and we lost a lot of maps (and the ability to do 64 x 64 maps...) with it. Are you planning on leaving spring backwards compatible with current maps?

Anywho, As long as when you finish this it works I'll be happy. I cant compile anything with your current versions without getting odd artifacts, so I look forward to a nice stable finished product. Hurry up

aGorm

[user]

ok, some will want to use jpg, others png, or tga, or whatever cool format they want, so now i will make an option to switch the format.

we dont have the ability to make 64x64 maps, since mapconv end is
50x50 no more than that(maybe increased).

texcompress is probably the worst compressor, it makes the maps look diferent than they should.

and dont use bmps, they are bad.

version 1.0 almost done.

lots of formats for the temp tiles will be supported, including dds,h,raw.

[Argh]

Yeah, I tested everything I could, nvdxt.exe had the best results.

JPEG at full resolution is practically lossless, aGorm. If you want truely lossless, but with fairly fast compile times, having looked into this a bit I think that TIF is the best format to use, it's basically a raw format, 100% lossless.

Version 10 with the options I noted gave me a standard map with no lines at all, even when maxheight was raised to 1200. I think that just getting rid of the fade was all that was necessary there, but overall, this is an amazing improvement over the old mapconv, even if we don't add any new map version options...