Spring RTS Engine

Could Spring be made to support .jpg map textures instead of .bmp or .raw
I have partly finished a map which comes in at 40mb thats repeat tiled all over and compressed with 7zip, in mapconv, compression is at 0.8,,
Q: who is going to download a 40mb map,,
A: nobody
Advice to all,, check ya filesize before spending weeks on a map.
Anyway,, here is a screenshot, maybe I can scale the map down from a size standpoint.

Oh if this map looks familiar, it is I used the heightmap from lava and two hills.

.smf files are compressed in the nvidia .dds format, which is far superior to jpeg anyway.

Ok thanks

EDIT,, Curiosity got the better of me so I loaded up a smaller version of the texture, 8192x8192 @192mb "not enough memory for the lager 10240 x 10240 300mb prefered texture" and saved it as a .jpg with medium compression "7" and the size was reduced to 12.5mb, which wipes the floor with nvdxt, from that result its realistic to assume the larger texture could be reduced to around 19 or 20mb or so, where nvdxt is only able to compress it to 59mb, thats an enormous differance.

I managed to get the full sized terrain texture saved as a .jpg, using medium compression I got it down to 14.9 mb with NO visible degradation of the image quality, which leaves me thinking why are we using bitmaps??

Cause bitmaps are easy to work with, and .jpgs are not. But If you have correctly tiled the terrain, the mapconv + 7zip should get it down really small. If compressing does not get the size down, me thinks you have not tiled your terrain properly.

Could we not sneak a higher main texture compression ratio out of the .dds format files? with the detailed texture overmapping the whole map anyways chances are players would almost never acctually knowtice texture archiving on the maps.

Maelstrom wrote:Cause bitmaps are easy to work with, and .jpgs are not. But If you have correctly tiled the terrain, the mapconv + 7zip should get it down really small. If compressing does not get the size down, me thinks you have not tiled your terrain properly.

Thats true Maelstrom, but we could all still work with bitmaps until the time comes to compile the map where you would just save the texture as a .jpg before compilation,, we are using image editing software after all.
I used 256x256 tiles for the entire map as far as I understand they should be 32 x32 or a multiple of so the map is properly tiled. Whats causing the large file size is the level of detail in each tile, which varies wildly depending on the graphic content in a given texture tile, I wanted a detailed texture but with the current system of map making we are limited to very small but detailed maps or large maps with far less detail, I don`t believe the graphics should be completely thrown out the window for the sake of expediency and compressing the crap out of textures is very noticeable, I suppose its a personal thing I hate seeing the artifacts caused by to much compression but thats just me.

What would be the point of saving it as a jpg to compress it? THe file size of the texture does not matter, as it is remade by the converter. The texture does not need to be downloaded at all. So I dont see how saving the texture would help filesizes of the map, as you dont download the bmp as it is.

Unless your saying that jpgs, being smaller woul work with the map converter better, thats the only thing that you could be talking about that makes sence to me.

I just wanted to know if it would be possible for people to be given the option of using a .jpg.
I don`t really understand how nvdxt compresses the texture but I do know that with this map texture I am curently working on in its current form nvdxt compresses it to around 59mb and photoshop or psp can get it down to 14.9mb at medium compression,, does it really matter where or what application does the compressing? I just want to know "is it possible for spring and or mapconv to be made able to work with a .jpg, the numbers don`t lie and there is no way nvdxt can get this particular texture down to anything near 15mb, at least not without making the map look as though it was textured with old carpet tiles that don`t quite match

As has been said above, it doesn't matter what format the input is in, the output is going to be the same unless you increase the .dds compression level when compiling... have you tried a value less than 0.8?

I think what he means is that instead of using .dds for the resulting texture, use a .jpg. Problem with this, although it is a good idea, is how Spring uses a tile based system. So, unless you wanted to change the source to take a straight image as the texture, or write a new mpa converter to take a picture and spit out a jpg tile file, and then modify the source to support jpg tiles, I dont see how this is going to happen.

The thing is that all modern gfx cards support dxt compressed textures in hardware meaning you can keep the texture compressed right until its put up on the screen. With jpeg compression you would have to decompress it on the cpu and then store the unpacked version in memory.

Thanks SJ and thanks for your patience everyone.
I think I should have asked can mapconv be made able to accept a .jpg input image for compilation in the normal manner.

Gnome,, I didn`t try a lower compression number but will give it a go.

just incase, for you people hard of sight.

Weaver wrote:Mapconv supports jpegs

Other random observations;

Bitmaps depths don't have to be 24 bit.

Your map texture and height map must be the right size, metal and type map can be different.

Undocumented stuff like this may not be bug free, so don't blame me if something goes wrong.

Well you can use a .jpg for the texture and the map works and looks good in game, but the map filesize is actually larger than if .bmp is used, mapconv just converts it all to .bmp in any case so the smaller source image file advantage is negated when the conversion back to .bmp occurs..

*facepalm*

It's not converted to bmp on compile. It is converted to the nvidia dds format which is far more friendly with video cards as SJ said, and can easily achieve or outclass jpeg compression if you use a higher compression factor (or in mapconv's case, a smaller number). Bitmaps are only in play before you compile, and as Weaver pointed out, you could use jpeg in their stead if you really wanted to. The map files that mapconv creates and Spring uses are not bitmaps and shouldn't be considered such.

wow that looks so good
could u release it? it would make a good crossing map which spring has few enough of

Gnome wrote:*facepalm*

It's not converted to bmp on compile. It is converted to the nvidia dds format which is far more friendly with video cards as SJ said, and can easily achieve or outclass jpeg compression if you use a higher compression factor (or in mapconv's case, a smaller number). Bitmaps are only in play before you compile, and as Weaver pointed out, you could use jpeg in their stead if you really wanted to. The map files that mapconv creates and Spring uses are not bitmaps and shouldn't be considered such.

Ok got it.
I think I was getting confused with the phase of compilation where the minimap is gererated, somewhere in there before the .dds is created it lists a bunch of bitmaps being generated,, bla bla bla.bmp or something.