[Devrous]

One of the things I know I'll need to do is upgrade to the newer FreeSpace Open version. However, I was wondering if anyone knew of any issues with doing so. FS2H was built on 3.6.9 and worked fine, but I'm worried about issues with going to the newer one. Would I be able to revert back if there were problems? Also, I've always ran it in Direct3D, not OpenGL. Now that I've got a much better comp then I did in the olden days I could probably run either, but OpenGL always made the explosions, shields and primaries show the whole black square of the image file when it showed up. Even the smoke was blocky and black.

Any advice would be most appreciated 

[Hades]

3.6.9 is a defunt build and I highly recommend using the new 3.6.13 nightlies as they have increased performance and more features. OpenGL is all that is supported now, and no, it does not do that to effects normally, it was probably an issue with your old computer.

Also I'd like to welcome you back.

[Devrous]

Many thanks, both for the swift reply and the welcome.

Just installed it and it certainly takes care of all my previous issues with missile trails and other sources of lag. However, the old OpenGL issue I had is still showing all the image; it isn't making the rest invisible as it should. The explosions block out the background and primary weapon images are flying block pictures 

Sounds like I need to convert the pcx and other image files into a different format. The old builds required 256 color, 16-bit images if I remember correctly. Has this been fixed/superseded?

[Herra Tohtori]

I think every in-game graphical asset should now work as 24-bit/32-bit DDS...

[Devrous]

Finally cleaned house a bit and removed all duplicate images in the effects folder. A few TGA and PCX files left but all I need to do is convert them to DDS and buy some space. So far the problem persists; running in OpenGL I still see the outline and fill of the original image. I'm guessing that straight Black is not the transparent color even though Direct3D recognized it as such. Odd. Do I need to replace the Black fill with the transparent Green used in places such as sun overlays (i.e. Sathanas' in final FS2 mission) and interface files?

Will continue tinkering.

[Herra Tohtori]

This is either a graphics card problem (hardware limitation or driver problem), or something related to your saving method of the in-game graphics.


What MediaVP's are you using?


If the problem happens with current, up-to-date MediaVP's, then it's probably a GPU/driver problem, in which case I ask you to tell us what GPU are you using, and with what drivers? Could you also post your fs2_open.log, that should tell us if something in OpenGL initialization fails.



If it's a data problem instead, here's what could possibly cause it on incorrectly saved textures:

Green is only used for 1-bit alpha on specific type of PCX files. You shouldn't use it for any other type of files. Most effects should use additive blending, which is achieved by making a 24-bit RGB texture with black background and no alpha channel at all. If a texture that is supposed to use additive blending happens to include an alpha channel, that can cause effects that you have described, since the game things it's supposed to use alpha blending for that effect and the alpha channel happens to be fully white - which will create an opaque black box around the effect.

If that is the case, you'll need to look into the settings of the program you are using to save the images, and make sure you eliminate the alpha channel where it is not needed.

But, if the problem happens on all mods (most useful test mod would be mediaVP's, because we know they should definitely work correctly  ), then it isn't a data problem.

[Devrous]

Running a 64-bit system in Win 7 on a GeForce 9800 GTX+ card. Other mods show up beautifully, so I'd have to say it's the alpha channel issue. Have managed to only use free programs so far, with images being edited in IrfanView and converting to DDS with DDS Converter 2. It is most likely a setting in one of those, though my initial guess is the converter. If it ends up being a problem I can't solve with a converter setting I'll have to create my DDS files another way.

Many thanks for the help! I'll post back when it's solved.

[Herra Tohtori]

I suggest switching to GIMP or Paint.net for image editing.


GIMP being my preferred suggestion, as I am unfamiliar with Paint.net and would be all but unable to help with that program, whereas with GIMP I would be able to give guidance quite easily. Besides, GIMP will offer you every tool you need for image editing, as long as you don't shy away from the interface design.

For converting to DDS, I suggest getting NVidia's DDS tools - either the traditional nvDXT command line utility, or the newer version which uses GPU power via CUDA to speed up the compression process.

I only use GIMP's own DDS plugin for importing DDS files, then save them as TGA or PNG, and use nvDXT on them to convert to DDS.


Also, familiarize yourself with the different DDS types so that you know which to pick when saving different types of files. Mainly, which ones have alpha channel and which ones do not. I think this wiki page would be a good resource to read through. Post any questions here or in the original GIMP thread.

[Devrous]

Thanks for the advice! I tried using GIMP but it didn't recognize DDS files. I must be missing a Plugin.

[Herra Tohtori]

http://code.google.com/p/gimp-dds/

Get the DDS plugin for GIMP 2.6.x from this link here.

EDIT: Specifically, this link here.

[Devrous]

Excellent! I think I have a new favorite tool   

Yes, the EFF and other effect files I had previously created were RGB-alpha 1 layer files with auto-generated layers under it presumably from the converter. Direct3D didn't have an issue with this but OpenGL sees it, as you pointed out, and it is drawing it opaque. I'll try to test is out, resaving the sequence as regular RGB 1 layer DDS files and watch what happens. Pain in my butt to have to redo every one of these; batch conversion?

[Devrous]

Removing the alpha channel all together seems to do the trick, only the outline is still barely visible instead of truly transparent. Guess I do need the alpha, just need to set the transparency >.<

[Devrous]

Hooray! Problem solved with the DDS files. Now I just have to convert a hundred or so files 

I'm curious why EFF is used instead of the native ANI files. The ANI are much smaller in size and can be made of the same hi-res images. Is it more efficient to use EFF?

[Herra Tohtori]

Removing the alpha channel all together seems to do the trick, only the outline is still barely visible instead of truly transparent. Guess I do need the alpha, just need to set the transparency >.<

Additive blending adds the contents of the texture on top of things seen behind it. That means the background needs to really be black ( #000000 ) for things to work correctly. I suspect that the background isn't truly black, but very dark grey instead.

The easiest way to confirm this is with the colour probe tool (keyboard shortcut O in GIMP). Easiest way to fix it is to either adjust Levels as required or increase contrast slightly with Brightness/Contrast tool.


EFF is used because ANI files only support 256-colour 8-bit PCX files, with 1-bit transparency option for certain textures, while EFF supports DDS textures (and PNG and TGA but those shouldn't be used for in-game usage).

This is bad because it limits the quality of textures with gradients and lots of different colours. The only type of texture that wouldn't suffer a quality hit would be additive blending, greyscale/monochrome textures, because they can only have 256 colours to begin with even in 24-bit images.

The PCX is also bad because it takes the same amount of video memory as an uncompressed 24-bit texture of same resolution, because the game needs to convert the indexed PCX file into a full bitmap for the GPU to be able to use it.

By comparison, a DXT1 compressed RGB image takes only one sixth the memory requirement of an uncompressed 24-bit texture of same resolution, and a DXT5 compressed RGBA texture takes one fourth of the memory of uncompressed 32-bit RGBA texture.

And the DDS files can be passed directly into graphics processor's memory. This also reduces CPU and system RAM overhead since it eliminates the PCX-> bitmap conversion process.


The only obvious flaw in the EFF files is that it isn't a container format like ANI, which means you end up with thousands of image files as opposed to frames being contained in one file. There have been talks about introducing animated PNG support, but that would mainly be useful for interface stuff; I don't think there has been any plans of designing an animated DDS container type file.

[Devrous]

Excellent summary. I have no problem dealing with tons of files - the naming convention alone takes care of things. I guess my misconception was that file size = faster load, as I was ignorant to the translation process for PCX. Thanks again; I feel smarter than I was 5 minutes ago 

Any way to batch convert the DDS files? My fingers may fall off if I try to resave every one of my DDS files one by one!

[Herra Tohtori]

Excellent summary. I have no problem dealing with tons of files - the naming convention alone takes care of things. I guess my misconception was that file size = faster load, as I was ignorant to the translation process for PCX. Thanks again; I feel smarter than I was 5 minutes ago 

Any way to batch convert the DDS files? My fingers may fall off if I try to resave every one of my DDS files one by one!

Load time matters for interface files - there the smaller filesize will result in better performance (smaller loading time), which is why PNG support was introduced - that allows lossless compression, which means smaller interface file size with no quality loss, which means 24/32-bit interface with comparative or only slightly higher load time performance to PCX, whereas with TGA's (even RLE TGA's) or uncompressed DDS files the loading times would be significantly higher.

In-game graphics, however, put a much bigger stress on the GPU and there the graphics memory load is the biggest worry, hence the extensive use of compressed DDS files, even though they take more space on the hard drive than other file types (PCX, PNG, TGA in some cases).



I suppose you can use irfanview to convert your DDS files to TGA/PNG and re-save those as DDS using nvDXT. If you have the original source files, though, it'd be better option to convert them directly to DDS, as consequtive DXT compressions will degrade quality cumulatively.

nvDXT, being a cmdline utility, has batch conversion in-built, but I have not had good luck trying to get it convert DDS to DDS.