[taylor]

Mine is 12ms, and I can notice it, but it's not too bad.  In most games I don't really notice it at all but the color blurr/shift in FS is noticable with stars, jumpnodes, small texture details, and things of that sort.

[Vasudan Admiral]

Ok, I've now done a complete clean install of FS and FSO, and have so far only added the latest media VPs. Using the standard flak, you can clearly see the problem:
http://sectorfiles.net/ti-file-dump/VasudanAdmiral/Pics/BlackBoxBug.jpg

When you open that exact file (yellow_glow.tga) up in PS, it has no alpha channel at all. This is what I was experiencing with some of my own weapon effects earlier - though they have no alpha channel, they get the black box around them. Taking the entry for the graphic from "@Laser Bitmap:" and putting it in "@Laser Glow:" removed the box and all was fine again.
The table entry in question here is the mv_flak-wep.tbm, in the $Pspew section: "+Bitmap:  Yellow_glow"

It doesn't appear to be universal however - I just tried it with the mekhu effects - which is another TGA with no alpha map, in the "@Laser Bitmap:" field. No problems at all. :\ I think it must only appear if the weapon has certain properties. Possibly a trail - I'll try that now.

Edit:
Errm, ok. An hour or so more testing, and I think I've been caught out by a few little bugs and mistakes pretending to be a big one. :\
There is a second Yellow_Glow.tga in the maps folder - the one that I think comes as the yellow glowpoint for those glowpointed pofs. Even though this version also lacked an alpha channel, when I deleted it the black box vanished in-game.
The odd bit about this is that I marked the one in the effects folder before I started testing, and checked it appeared in game, to make sure exactly this sort of thing could not possibly be happening, so I have no idea how that can be. :\

The custom effects I was having trouble with also appear to have sorted themselves out - though I don't know how that works either, seeing as I haven't touched them in any way. 

[taylor]

Both of the yellow_glow.tga files, in data/effects and data/maps, have an alpha channel:

Code: [Select]

[taylor@dragon VP]$ file data/effects/yellow_glow.tga data/maps/yellow_glow.tga
data/effects/yellow_glow.tga: Targa image data - RGBA - RLE 256 x 256
data/maps/yellow_glow.tga:    Targa image data - RGBA - RLE 256 x 256
In fact, they are the same exact file:

Code: [Select]

[taylor@dragon VP]$ md5sum data/effects/yellow_glow.tga data/maps/yellow_glow.tga
43dcb46d6a6d252020e79a33ae8ceb52  data/effects/yellow_glow.tga
43dcb46d6a6d252020e79a33ae8ceb52  data/maps/yellow_glow.tga
The Mekhu effects don't have an alpha channel though so it makes sense that those work fine.


EDIT:  Forgot the actual point of this.   The alpha patch for mv_effects only includes one of the fixed yellow_glow.tga files, in data/effects.  I forgot to ever include the one in data/maps, which is why models will use the one with the black box and effects won't.  And since data/maps is searched for images before data/effects, that's why removing the one from data/maps make it work, the game will just use the first one it finds.

[Shade]

You need both. Sparky_hi simply adds some extra hi-res art, it does not replace everything.

[Vasudan Admiral]

Both of the yellow_glow.tga files, in data/effects and data/maps, have an alpha channel:

Code: [Select]

[taylor@dragon VP]$ file data/effects/yellow_glow.tga data/maps/yellow_glow.tga
data/effects/yellow_glow.tga: Targa image data - RGBA - RLE 256 x 256
data/maps/yellow_glow.tga:    Targa image data - RGBA - RLE 256 x 256

Ah, well that would explain it then. Thanks.
Since opening the image in photoshop apparently won't tell you if an image really does have an alpha map or not, what's the best way to find out?

[taylor]

Since opening the image in photoshop apparently won't tell you if an image really does have an alpha map or not, what's the best way to find out?

It's been so long since I've used Photoshop that I'm not really sure.  Being on Linux, and of that sort (ie, UNIX hacker), I just have a magic file to help identify image formats used by the game, and in a way that makes them easy to identify to me.  When using GIMP though, I just look at the channels dialog and it will have a Red, Green and Blue channels, plus an Alpha channel if one exists.  If I'm not on the command line then that's how I tell.  I'm pretty sure that PS will have something similar still, I think it did before, but it's been about 5-6 years since I touched PS.

[WMCoolmon]

You can download the GIMP for Windows, as well. Decent little image manipulation tool.

[Vasudan Admiral]

Already have, along with the dds plugin, but now I'm even more confused:

If I open both ParticleSmoke01_0002.dds from the original mv_effects.vp, and the same file from Taylors alpha patch in gimp/photoshop, both of them tell me that apart from mipmaps, they're identical. They _both_ appear to have a white alpha map. Is there some setting on both the dds plugins for gimp/photoshop that I'm missing? Something that might be opening all dds files with a default alpha map?

[Shadow0000]

Actually, the DDS in the mv_effects.vp v3.6.8 Zeta are DXT5, see it has 16 KB, while the ones in the patch are DXT1, see it has just 10 KB.

TGA also manages kind of this way, the ones in mv_effects.vp v3.6.8 Zeta are "TGA Type 2", while the ones in the ones in the patch are "Type 10" (aside from being 24-bit now). Just in case:

Type 1: Color Mapped Images
Type 2: True-Color Images
Type 3: Black and White (Unmapped) Images
Type 9: Run-Lenght Encode (RLE), Color-Mapped Images
Type 10: Run-Lenght Encode (RLE), True Color Images
Type 11: Run-Lenght Encode (RLE), Black and White Images

The problem with RLE Compression is that it makes other compressions algorithms less effective (Zip/RAR/7z/etc.), so it makes the Uncompressed size smaller, but the Compressed size bigger...

[taylor]

If I open both ParticleSmoke01_0002.dds from the original mv_effects.vp, and the same file from Taylors alpha patch in gimp/photoshop, both of them tell me that apart from mipmaps, they're identical. They _both_ appear to have a white alpha map. Is there some setting on both the dds plugins for gimp/photoshop that I'm missing? Something that might be opening all dds files with a default alpha map?

Shadow0000 already hit on this, but I'll add some to it, since I did the conversion.  The originals were/are DXT5, which means that they are 32-bit.  The game will see those as having a full alpha channel and then try to use the new blending mode for them.  The ones in the alpha patch are DXT1, 24-bit to the game, so the game doesn't identify them as qualifying for the new blending mode.  Of course, those DXT1 images are actually 32-bit but since the game only supports 24-bit DXT1 it doesn't care.  So, both the ones in the mediavp (that are DXT5) and the ones in the alpha patch (that are DXT1) have an alpha channel, but in the case of the DXT1 versions the game just ignores it.

The DXT1 having an alpha channel is because of how they were converted, the DXT5 were just resaved as DXT1.  Since the DXT5 versions had an alpha channel though the format used for saving was automatically fixed at DXT1a (1-bit alpha) rather than DXT1c (color only, no alpha).   Normally I would get rid of the alpha channel and then save it as DXT1, but I converted those particular files a long time ago and have just never gone back to fix them.

Hopefully that answers your question without getting you too confused in the process.

The problem with RLE Compression is that it makes other compressions algorithms less effective (Zip/RAR/7z/etc.), so it makes the Uncompressed size smaller, but the Compressed size bigger...

Yeah but it lives uncompressed much more than compressed so in the end it doesn't really matter than much.  And there is only like a 10-15% difference in size so it's not that big of a deal anyway.

Eventually it will make more of a difference when we start using CVPs, but I'm hoping that most images will be in a DDS format by that point anyway.

[Don-DiZzLe]

Whats the optimization flag for my processor cuz i dont see it here http://linuxreviews.org/howtos/compiling/safe-cflags/

I have a AMD Athlon64 3200+ processor

[taylor]

Whats the optimization flag for my processor cuz i dont see it here http://linuxreviews.org/howtos/compiling/safe-cflags/

I have a AMD Athlon64 3200+ processor

With a 64-bit processor (if you are running a 64-bit OS) the code already adds -m64 which turns on quite a few options already, -Os is used as an optimization flag if it's a release build (sort of a mix between -O2 and -O3), -funroll-loops is used for both debug and release builds, and -march=athlon64 is already added as well.

Just a note that -fomit-frame-pointer is generally considered unsafe for FS2 code, but it may work fine for you.  And though I've had no real issues with it in the past, it won't be added as a default option in CVS or any code release.

[Don-DiZzLe]

OK but Im on a Ubuntu Dapper 32-bit system.

So is this the right "compile_fs2_open" for my system:

#!/bin/bash
# fs2_open Compile Script
# These are only examples, uncomment to enable optimization.
MY_CFLAGS="-march=athlon64 -O3 -pipe -fomit-frame-pointer -ftracer -funroll-loops"
if [ -e ./fs2_open/ ]; then
   cd fs2_open
   if [ -e ./Makefile.in ]; then
   make clean
   ./configure CFLAGS="$MY_CFLAGS" CXXFLAGS="$MY_CFLAGS"
   make
   else
   ./autogen.sh CFLAGS="$MY_CFLAGS" CXXFLAGS="$MY_CFLAGS"
   make
   fi
   else
   echo "No fs2_open directory found."
fi


One more thing Im looking here http://gcc.gnu.org/onlinedocs/gcc-3.4.1/gcc/Optimize-Options.html and I see a whole bunch of extra options besides O3. Which should I use for greater performance?

[Vasudan Admiral]

Hopefully that answers your question without getting you too confused in the process.

It does indeed - many thanks.

[Darklord42]

The windows version works fine for me. But the Mac one I am having alittle trouble.  When ever I start a mission after the breefing i click on start mission and the entire program crashes. I know this could be a multiple of reasons but i am unfamiliar with the debug version on the mac.

[Porthos]

I don't know if anyone else has noticed this but in the Shrouding the Light campaign, using this build, Lightspeed's weapon effects are replaced by the default weapon effects. You still have the audio recordings for the effects though.

[taylor]

The windows version works fine for me. But the Mac one I am having alittle trouble.  When ever I start a mission after the breefing i click on start mission and the entire program crashes. I know this could be a multiple of reasons but i am unfamiliar with the debug version on the mac.

There should be a crash log in ~/Libarary/Logs/CrashReporter/ for FS2_Open.  Send that to me and I'll take a look.

[ARSPR]

While playing Derelict's "The Stars are Right" I've found two issues that I have mantised:

+ There's a severe performance drop between RC2 and RC3 (Mantis 961).

+ Sometimes textures blink to white (at least in both RC2 and RC3). (Mantis 962). Could it be related with this Descenter's post in Media 3.6.8 zeta thread: (http://www.hard-light.net/forums/index.php/topic,39905.msg828254.html#msg828254)?

[Ace Pace]

Will test to see if this is a one off, but I got a hard crash in FSport latest version. Mission was first mission with Herc, with the suicidal aten. Crash was in recieving orders. I'll try and replicate it.

EDIT: mission name is tenderizer, while the mission also went ahead, so I crashed, but game registered that I finshed the mission.

[Don-DiZzLe]

What are the best (optimize) options for compiling a fs2_open_r build for a Athlon64?

I already have these options "-march=athlon64 -O3 -pipe -fomit-frame-pointer -fprefetch-loop-arrays -fforce-addr -funroll-loops"