Spring RTS Engine

Wow, that's weird. Almost looks like it's either borking which mip it's reading, or the alpha's reversed...

you can try u8888 but it is not a good idea using it, it is a uncompressed
image, they are usually bigger than bmps, each tile file will be 6mb.

that map looks really good with dxt1, would look even better if dxt 3 and 5 were working.

u8888 had the exact same results. Probably the alpha. Strange, that works elsewhere in Spring.

Gonna try u888, no alpha...

yes, dxt5 and 3 works for units and skyboxes,

i will try using -dxt3 -32 u888 to see what happens.

u888 doesn't work, either, makes all sorts of terrifying colors.

Methinks that the .SMT reader doesn't bother asking for DevIL support, and just expects DXT1... that might be worthwhile to get fixed up.

So, I'll try DXT3, see what happens. Maybe needs an alpha control, to keep alphas always 1 / 255?

try -binaryalpha or -alpha_threshold 255, if 255 does not work change it to FF.

if they dont work use 0 or 00.

I'm trying the following right now:
I've checked the alphas, and they're white where they should be. However, Spring may be expecting all-white or no value for alpha, dunno. I'll have results back in a few minutes, this is going fairly slowly, probably because of color-space conversion.

i was trying
but got a problem, then i will have to start it again.

You can't combine -32 u888 and -dxt3, they're both commands specifying the output formats. Try -32 dxt3 instead. However, I'm testing the theory that Spring's expecting a 24-bit format now, maybe wait 5 minutes?

24 bit means no alpha, i will try -24 dxt3.

Hmm. Just finished. Every other line is white! And it just spat out the tiles, without assigning them to a location. My guess is that when it's reading the values, it's encountering more numbers than it knows what to do with... not that Spring can't deal with 24-bit u8888. Because the texture rendered just fine, where it was visible, it just wasn't placed right.

I'm going to try DXT1, -nomips, see what happens... ah, yeah, that might be the way to go with DXT3... I'll try that with DXT5...

Testing:

wont work, when spring reads the tile files it always expects 4 mipmaps,

8 mipmaps worked, with DXT1. <shrugs> at worst, it fails horribly, like a lot of these have done... if, in the end, we "merely" get to customize DXT1 output and filtering, I'm not gonna cry.

i will try this:
5 mips because the last mipmap is removed.

Forcing DXT5 to 24-bit thus far seems to be producing the correct alpha value. It all looks good, in theory. Ah, yeah, I was thinking about doing 9, to get the last one with DXT1, see if that changes performance at all. Probably not. Performance was better than with old MapConv, though.

i will look at the spring source in svn, to see how it loads the tiles.

old mapconv is faster because it used bmp tile files, no DevIL, DevIL has problems with bmps, it writes them wrong, nvdxt cant read bmps made using DevIL, i had t switch to png which is 2-3 times slower.

the smt tile loader takes a mipmap level and reads a certain amount of bytes from the file, for every 32x32 block it reads a certain amount of bytes, the amount of bytes is the SMALL_TILE_SIZE variable,

stored in the smt file, it is always 680, maybe increasing it would work?

DevIL handles JPG just fine, though. I'll do a comparision against PNG, see what speed looks like... almost done with this latest test...

the smt tile loader takes a mipmap level and reads a certain amount of bytes from the file, for every 32x32 block it reads a certain amount of bytes, the amount of bytes is the SMALL_TILE_SIZE variable,

stored in the smt file, it is always 680, maybe increasing it would work?

Yeah, that should work, I think / hope. However, it'd probably need a check of some kind, or older maps would get broken...

Just tested:
Very pretty. Now I'm going to convert the terrain to jpg, see if I can get more speed, that takes like 15 minutes...