Is RLE compression supported or not?

[TheJamsh]

I know in earlier versions of BZ2 (1.0-PB4a) RLE compression in .tga files was definately NOT supported. I would crash anytime i saved a texture with this. I Know however that .pic files can be .rle compressed, so perhaps it was a .tga only thing?

However lately i have definately seen .pic files saved with .rle compression and they seem to work fine. Is RLE fully supported now we are into DX9 (assuming it was graphics engine related). I also wouldn't mind knowing which is the best format to use, as i have a suspect feeling that this is the reason why we have the DXT vs PIC bug appearing on occasion.

Any pointers? (what does RLE even mean?)

[AHadley]

And what other things does DX9 allow us to do?

[GSH]

Ever since BZ2 switched to OpenIL.dll for .bmp reading, RLE has been supported for .bmp files. (As to what it is, see http://en.wikipedia.org/wiki/Run-length_encoding ). It's not related to DX9; I think pb4a would do the same thing. All .pic files have RLE compression enabled 100% of the time. It's a required part of that file format; in .bmp files, it's optional.

-- GSH

[mrtwosheds]

as i have a suspect feeling that this is the reason why we have the DXT vs PIC bug appearing on occasion.

Hmm, My (uncompressed) texture folder for LOS is currently 91.5 mb in size, and I have never seen this bug at all. Maybe the bug is with what you are making your images with.
My dxtbz2's are made from .pic's or .png's some older ones may be from .tga.

[TheJamsh]

Nope, they are all .pics, saved with the latest version of Xnview. occasionally they work, occasionally they dont.

[mrtwosheds]

Well... The .pic's I make with Photoshop, convert to dxtbz2, and load into game always work, 100%, every time.
I don't really know what this "bug" is as I have never seen it.

I do of course, name the textures as whatever.dxtbz2 in my .xsi, so if I did load a whatever.pic  I guess bz2 would probably not find it anyway as these finding alternative things tend to only work one way.

[TheJamsh]

The bug essentialy ends with models turning up bright white in game because the .dxtbz2 file just isnt used, and seeing as there is no .pic to fall back on, you just get the model without textures.

Im going to re-save with latest version, all with RLE on. See what happens. I think that somewhere along the line, an OLD version of DXTGen was used.

[AHadley]

Mine have always worked. I never get any texture issues...:s

[mrtwosheds]

If there is no .pic, then you should make sure the xsi points to the .dxtbz2 only.
I don't see the point in deliberately referencing a texture that will not exist.
The code that replaces a .pic or .tga with a .dxtbz2 is only needed because GSH would not want to remove the .pics from the an original install of bz2 or replace all the assets that link to them.

[TheJamsh]

Well in my case, the .pic texture was a glowskin, so actually it wasn't referenced by ANYTHING. When a .pic was present, it was found fine, but when it existed only in .dxtbz2 format, the whole tank turned white. This wasn't an issue with the texture because it displayed perfectly fine with the .pic there.

[mrtwosheds]

A stock skin I assume, so you had

skin00.pic  -and- skin00.dxtbz2
skinco.pic -and- skinc0.dxtbz2

from stock and patch
and then added

skina0.pic, which worked
OR
skina0.dxtbz2 which made all the textures disappear.

This Does not surprise me at all.
Provide both formats if you are adding glow or team skins to stock textures, to complete the set of textures the program is expecting to find.

[VSMIT]

So if you went into the xsi in notepad and changed all of the texture file extensions to dxtbz2, it would only use the dxts and not pics?

[TheJamsh]

i know it looks for pics or whatever from experience. my effect textures are all in .png format to assisrt framerates (less memory on big effects, i hope, with DXT's being even less). I put .dxtbz2 in the texture, but only had the .png's present and strangely it still worked...

MrTwoSheds, these news textures are both for stock vehicles AND for new vehicles, but every one has the full set of textures, not in the same directory though. That shouldn't make a difference.

[mrtwosheds]

So if you went into the xsi in notepad and changed all of the texture file extensions to dxtbz2, it would only use the dxts and not pics?

You would have to ask the programmer about how it actually works, what I am trying to point out is that there are 2 processes going on here
00-a0-co from original bz2 and then .pic, tga, jpg etc or dxtbz2 from the patch, if you expect it to cope with any combination of formats/extensions and naming conventions you will probably encounter odd effects.

You also need to consider BZ2's use of materials...If you make two different models that use identical materials (texture, color, shinyness etc)
Within the bz2 code this can become one material, different models will inherit material property's from each other! This can cause allot of confusion.
I had several models that all suddenly became brightly lit, like I had put __e on allot of whole models It occurred after I loaded my mod into a new install/patch, It was caused by one model using that particular material as the texture for Its eyepiece light, everything else using that same material became lit by the __e on one frame of one model.
I have absolutely no idea how materials will respond to textures with the same name/different extensions/combinations of formats and 00 a0 c0.

Materials may well explain

I put .dxtbz2 in the texture, but only had the .png's present and strangely it still worked...

[Nielk1]

It was hinted, by OM I think, that with a correctly formatted object you can effect all textures and make them appear as edited on a map. For example muddy. This would be one hell of a hack if we could ever find how to do it. I think it may be related to the __e thing.

Jamsh, lets do a test with the models in the XSI set to *.BZ2DXT instead of *.pic.