Spring reads PCXs preferentially over BMPs! damn you all to

Caydr · Post by **Caydr** » 13 Jan 2006, 06:09

Gah! Subject line was too short. This needs to be fixed... at least BMPs don't crash the game apparently, but the problem is that spring will read any PCX unitpic before it reads a BMP unitpic, even though the BMP one is specified.

Gnomre · Post by **Gnomre** » 13 Jan 2006, 06:45

.. Never did for me when I still had the pcxs in the image dir... of course, that was several versions of the engine ago, but I don't see why that'd change. You have "buildpic=afg.bmp;" in the FBI, right?

On a semi-related note, I ran a test a couple nights ago. I batch converted the SWTA buildpics from 24bit BMP to DDS, JPEG, and PCX. Here are the results:

24bit BMP (perfect quality) = 3.39 MB
DXT1 DDS (compression artifacts not noticable in game) = 592 KB
50% compression JPEG (looks bad, but tolerable given spring's squashing) =344 KB
PCX: 3.34 MB

Surely, you say, JPEG obviously reigns supreme here. It's smallest, so the archive will naturally be smaller. Well, I'll let the results when compressed in a 7z archive, all with the same compression settings, speak for themselves (do note that the only difference between each archive is the filetype used for unitpics):

BMP: 11.4 MB (As seen in the current SWTA release)
DDS: 11.2 MB (negligible size difference, higher quality bmps go in for sure)
JPG: 11.0 MB (still not worth the quality loss)
PCX: 13.2 MB (obviously these aren't handled well by 7z)

So, with SWTA's 130ish units, the difference is only 400 KB with a very large loss in quality. There's no reason at this point to use anything other than BMP (even if you're doing an initial port from OTA, you should batch convert the PCXes!). 7zip basically cancels out any benefits gained from running image compression on the pics before compressing the entire mod itself.

Post by **Yeha** » 13 Jan 2006, 14:15

There is one added benefit of using dds over any of the other formats, and that is it allso take less ingame memory if compressed since it doesn't decompress during runtime.
In your example the dds version would take 592kb memory while all other format would require 3.39mb.

Caydr · Post by **Caydr** » 13 Jan 2006, 18:56

Gnome, the size difference is not so negligible in a mod with 391 buildpics. It's a difference of about 7 mb between JPG and PCX compression, AFTER 7zipping. The reason bmps work fine for you is that there isn't a PCX waiting to take its place. Since AA has all those OTA units, the buildpics included with Spring take precedence. So for instance, if I use BMPs, the only unit the arm commander has which has a high quality buildpic is the Dragon Eye. This is because there's no "armeyes.pcx" in the ota content archive. And believe me, aside from the extra memory usage as Yeha mentions, JPG is the ultimate format for buidpics. At 85% quality, there is virtually no discernable loss to quality yet the filesize is 2.5 kb compared with 28 kb for a pcx or 12 for a BMP.

@Yeha, yes, I figured as much. That's why I tried DDS... all I got were white boxes regardless of the compression technique I used. Even with and without alpha layers on any of the DXT compressions.... just a white box ingame.

Armsolar.dds:

This is with DXT3 and an alpha layer. Same result without an alpha layer. Same result in DXT1 or 5. If ANYONE knows a way to fix this, PLEASE speak up!!

Gnomre · Post by **Gnomre** » 13 Jan 2006, 22:45

Hmm, alright Yeha, that makes it worth it then. I will keep the HQ BMPs around though, no point in throwing them out :)

http://wormhole.tauniverse.com/images/s ... sworks.jpg <-- filename speaks for itself. The jpeg compression hurts more than the dds'.

I'll try to find where the hell PS is storing the batch conversion script I had to create specifically to make those dds files... when I do, I'll get it to you.

FLOZi · Post by **FLOZi** » 14 Jan 2006, 01:46

If you have a correctly setup FBI it should read the BMP

I couldn't even get PCX to work at all with the A&A BPs

Doomweaver · Post by **Doomweaver** » 14 Jan 2006, 01:50

Yeha, does that mean if DDS was used, more space would be free in the 2048x2048 limit? Because that would be awsome!

Gnomre · Post by **Gnomre** » 14 Jan 2006, 02:20

Uhh, the unitpics don't apply to the 2048 3do texture limit...

Anyway, I can't figure out where the hell PS stores this stuff. Here's a screen of the dds save settings I used:

Caydr · Post by **Caydr** » 16 Jan 2006, 03:02

Unbelievable. Just unbelievable. I have to believe what I'm about to say is complete bunk, since this engine is advanced enough that I'd think the devs would realize this problem and account for it... I'd think this except that I've seen it with my own eyes.

Someone add what I'm about to say to the wiki somewhere, as it's of great imporantance...

The following tags give a white box:

buildpic=armsolar.dds;
BUILDPIC=armsolar.dds;
buildpic=armsolar.DDS;
BUILDPIC=ARMSOLAR.dds;
buildpic=ARMSOLAR.DDS:

The following tags work:

BUILDPIC=armsolar.DDS;
BUILDPIC=ARMSOLAR.DDS;

Both "BUILDPIC" and ".DDS" MUST be capitalized. That's the whole problem and the whole solution to my problem.

Gnomre · Post by **Gnomre** » 16 Jan 2006, 07:33

Caydr · Post by **Caydr** » 16 Jan 2006, 07:38

I can't come up with any other explanation. All I know is, if I use any of those "white box" combinations, that's exactly what I get... I can't explain it, I don't want to, I'm just happy that for some reason it's working. I can replicate the problem any time you want, if you want proof. Maybe it's something specific to my mod, or the fact that there's already similarly-named PCXs.... or something. Like I said, I'm just going to smile and nod.

Spring RTS Engine

Spring reads PCXs preferentially over BMPs! damn you all to

Spring reads PCXs preferentially over BMPs! damn you all to