Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: Zacam on September 29, 2009, 10:42:59 pm
-
Based on the latest Nightly (5615) Flaming Sword and myself present to you builds with PNG support for Interfaces and possibly in EFFs as well.
Standard Release and Debug builds as well as Inferno Release and Debug builds to compare to the latest Nighly Builds for evaluation of any changes in performance.
I did not do the SSE build because, well, I'm lazy and if there _are_ any performance issues in the regular, we'd like to know so that we can resolve them at which point they (shouldn't) be present in the SSE builds either.
PDB files are provided for debugging purposes. Recommended to stick those in to the EXE dir as well, so that if there is an error, we can get on it.
Test the crap out of these, _EVEN IF_ you have _no_ interest in the PNG format or replacement Interfaces. _MOST ESPECIALLY_ the Inferno Build.
fso-WIN-20090928_r5615-PNG.7z (http://www.mediafire.com/file/vcnjiwgqomy/fso-WIN-20090928_r5615-PNG.7z)
MD5: ED813E3617BBD5CB2F61F3532814830F
fso-WIN-20090928_r5615-INF-PNG.7z (http://www.mediafire.com/file/nymoylztjoj/fso-WIN-20090928_r5615-INF-PNG.7z)
MD5: 79B956C42B6D1E64A39E66A8B4D1AB8B
UPDATE: 10/03/09
These two builds are identical to the above two builds save in one respect: They do not have the EFF Code Support that was introduced in SVN Commit 5508 (which then had a fix in SVN Commit 5510). All other fixes from all other commits are in place.
Why? Because it is a known factor that the Interface EFF code does introduce same hiccups in performance currently, I wanted a set of builds that supported PNG without that, to determine if there were any Performance issues explicitly with just the PNG support being in place. This way, PNG interfaces (non-EFF) can be tested independently of the EFF code.
fso-WIN-20090928_r5615-PNG-NoEFF.7z (http://www.mediafire.com/file/jm0d4oe3awn/fso-WIN-20090928_r5615-PNG-NoEFF.7z)
MD5: 589335F7D97661DD2A09CAF6C232F797
fso-WIN-20090928_r5615-INF-PNG-NoEFF.7z (http://www.mediafire.com/file/gnzdqeygjaz/fso-WIN-20090928_r5615-INF-PNG-NoEFF.7z)
MD5: AA1EDB9F06B5DE8D7D2F0018199F2910
-
What about the video memory usage? The PNG isn't supported by GPUs. Wouldn't it be better to use uncompressed DDS in the end?
-
Hence why these are Test Builds to evaluate performance, not just for support of PNG, but also to make sure that just adding the possibility to support them doesn't break anything else.
And for that matter, TGA, JPG and PCX don't have GPU support either. And DDS support passing is only as good as the application that is handling it.
-
Doesn't uncompressed DDS have a similar issue as TGA of being a massive file size?
-
Doesn't uncompressed DDS have a similar issue as TGA of being a massive file size?
Actually uncompressed DDS files are usually larger than run length encoded TGA files on disk since they DDS files do not support RLE. Something like a starfield (provided it's not too full of noise) compresses quite well with RLE, and thus file sizes can be smaller than the uncompressed DDS, or even compressed DDS would be.
System memory wise, uncompressed DDS files use less computational overhead and RAM since they can be passed directly to the VRAM while TGA files need to be decoded into raw bitmaps. When it's in bitmap form however it takes the same amount of memory as DDS in the video memory.
PNG is a lot similar to TGA in the sense that it utilizes lossless compression (better than RLE), and thus it can be useful for cases where actual video ram performance is not vital, but you want to reduce distribution size by, say, saving interface files as PNG as opposed to uncompressed DDS. Of course original format for interface files, PCX, is still smaller but limited to 256 colours palette, of which you may have to use one for one-bit transparency, and that limits the stuff you can do with the interface.
DDS files are superior for in-game graphical imagery though; the inclusion of mipmaps alone makes them worth using. Memory saving for the stuff that can be compressed is another big bonus.
-
But in instances where mip-mapping is not needed (Interfaces).
Some new test builds, the note up top about the edit should explain it adequately enough.