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?)
And what other things does DX9 allow us to do? :P
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 (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
Quoteas 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.
Nope, they are all .pics, saved with the latest version of Xnview. occasionally they work, occasionally they dont.
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.
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.
Mine have always worked. I never get any texture issues...:s
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.
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.
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.
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?
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.
QuoteSo 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
QuoteI put .dxtbz2 in the texture, but only had the .png's present and strangely it still worked...
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.
The xsi should be able to use .dxtbz2/.pic/.tga/.whatever.
However, all I see on this thread is vague handwaving and griping that something doesn't work. It is not a quality bug report.
-- GSH
Quote from: GSH on October 07, 2009, 11:48:58 PM
It is not a quality bug report.
That was already done in this case. It was resolved somewhat, but some wierdery still persists. If XSIs set to specifically load bz2dxt files will prefer the bz2dxts we are fine, if not then the fix you already made for this bug in the mantis to force it to definitely try bz2dxt, then pic, then etc did not fix it completely. Actually that seems to be why it loads white when it fails to load an alternate, where before the fix if file other than DXT was present it would either use the DXT or nothing, not it either uses the DXT or goes all white.
This thread wasnt really intended to go this way, AND we dont have all the XSI's for the AP N1 (like the rocket bombers for instance). Before i do anything to drastic ill put all the scource files together, and re-dxt them with the latest DXTGEN. See what happens after that...
For soemthing like this OM may allow some conversion to take place.
i converted my textures to .dxtbz2 and it works fine for me..
i believe the problem you are having is that the location and name of the texture is not exact inside the .XSI's, try making it point to exactly the place where the texture is, and the correct type of file it is, it should work fine then. (not joking.)
No thats not it rocket, i know when you specify a texture for .xsi it copies the directory too, but the stock models have this pointing to a Z drive, so we are fine on that.
if it helps the texture and glow texture have to be the same format and i think the glow texture has to be tranparent with that glowing part as the visible layer and that texture as the bottom layer
We know.