XWA Upgrade

Out of curiosity and an attempt to understand how the game handles transparency I started messing with the backdrop files. I'm sure many of you have explored this ad-nauseum in the quest to create the super backdrops patch, but I know the game can handle transparency in the concourse art as I have already experimented with it. With the dat files however the game seems insistent on replacing a specific color in the dat files. Below I create a mockup of what I was trying to address. On the left is what we have now, and on the right was my intended concept and attempt at the same star backdrop but with transparent edges to better fit in the new colored starfields.



However after loading the .png into the XWA Dat Editor and saving, it seems that no matter what setting I provide, the end result fills in the transparency and crops the edge.



I wonder what information you guys could impart to help me understand this. I was really hoping the task of feathering the different star and planet backdrop image edges was just a load of work someone didn't want to do, something I am more than capable of, to help out. Alas I get the impression you have already been down this road and hit a road block.

I imagine JeremyaFr might have some insight into what exactly his editor does when you load in a PNG with transparency and save.

EDIT: Correction, it looks like the dat editor preserves the transparency just fine, its the engine that doesn't seem to know what to do with it. Reopening a modified, saved dat file seems to keep transparency just fine.

After DTM released I think the first version of the Super backdrops, I tried exactly the same thing, exacting each and every image (and there are loads), feathering the edges of the planets, moons and so on to remove the edges, then inserting and replaced all of DTM's original images, only to test it in game and be very disappointed at the result.

So it was another project that found it's self in the recycle bin

Shame, I'm sure there's an answer if we dig. Well, I still have a few of my test backdrops just in case we figure it out.

I just now went so far as to save my work as a BMP with an alpha channel. (I think I did it right) I was hoping the game would prefer an alpha channel for feathering. Unfortunately it does not. There has got to be a solution. JeremyaFr, do you think this is an engine problem or something that can be solved with a tweak to the DAT editor?

The problem comes from the game engine.
When a backdrop with transparency is loaded, it is converted to 1555 format.

You can try this patch: This will use 4444 format instead of 1555 format.

Ok, I am unfamiliar with the exe patcher but I will give it a shot and report back.

Well, HOT DAMN IT WORKED. The feathered edges are gonna take a little tweaking, and they have a bit of a gradient but I personally prefer that over hard, black edges.



Jeremy you are a master.

Now that begs the question Darksaber, do you still have all your transparent versions or do I need to go thru them with DTM or something?

Just looking through my files, and I have the Planet.dat I changed sometime ago, I've just added the different starfields that are in v2 and created a new Planet2.dat

The problem is the Nebula.dat there is a lot of black background with those images, see we are just saving images from DTM's Dat's, he has the original images that might already have alpha transparent backgrounds, so instead of stepping on his toes, contact DTM first and ask your question.

Until then I'll hold off sending you the files, also he might want do it his self, dunno, but better to ask permission first

Also nice find Jeremy

Nah, its totally fine, makes sense, plus why do double work potentially. As a test, I modified the low orbit backgrounds to remove the starfield and have a transparent atmospheric haze. Problem is, at that resolution, the gradient transition is obvious. I did this hoping I could have a large gas giant rising over the horizon, sadly I don't think that will be possible.

The below image is layered as follows:
1. Spherical Starfield Backdrop, up, down, left, right, front, back.
2. Gas giant
3. Retouched low atmosphere backdrop (removed starfield with photoshop), down, left, right, front, back

interesting, but yes it doesn't work, nevermind it was a nice idea

Just remembered DTM is on holiday at the moment, so he can do anything for the time being until he gets back home

Lol,

Welcome back DTM, here's a shit-ton of work.

Hahaha.

That's some severe banding. These aren't still 256-color images, are they?

That would be a question for JeremyaFr, as I think it might happen in the exe conversion. The banding areas are fresh from new parts of the original image saved as a png.

Yeah that doesn't look ideal, but on the other hand I don't necessarily think it looks terrible either.

Nice, almost there. Above patch, is that related to the .Dat type "25" project?

Ual002, these are from my notes Jeremy wrote in past, just to bring you up to date if this is helpful . . .
"In dat files, images are 8-bits indexed colors (each color is 24-bit R8G8B8 ), with or without an 8-bit or 1-bit alpha channel. The palette contains up to 256 colors.
The main image types in dat files are:

type 7: 8-bit indexed colors and 1-bit alpha, rle compressed
type 23: 8-bit indexed colors and 8-bit alpha, rle compressed
type 24: 8-bit indexed colors and 8-bit alpha
type 25: similar to type 24 (currently isn't functional within the game engine) ????

Concourse images use type 7, 23.
In-flight images use type 7, 24, 25.

If a concourse image is not type 7 or 23, then the image is not drawn.
If an in-flight image is not type 7, 24, or 25, then the image is not loaded into a texture and the game crashes.

When importing an image, the editor will set the type to 24. In the dll, I added support for a type 25 which is 32-bit. Since this type is not functional in-game (WIP), I disabled it in the editor. So the imported images are reduced to up to 256 colors (each color being 24-bit). The current algorithm generates up to 128 shades per channel."



.

Edit: used PM for this thing

The reason for the banding is Jeremy provided a variation on the 16bit format, 4444 = 16bit
what you want is 8888 = 32bit

Trev

I will try again tonight and update you with the info you provided Trev, thanks.

Thanks Trev, but we would really need to know what the equivalent offset value would be to 8888

JeremyaFr wrote: ↑

Sun Jun 30, 2019 6:04 pm

Code: Select all

At offset 03156A, replace 7406 with 9090

This will use 4444 format instead of 1555 format.

Any idea what the value would be?

Yes.
But for now, it doesn't work. The game crashes when setting 32-bit format for backdrops.
I will try to solve it.

Thanks for the answer Jeremy, I thought there must be a reason why, but what we have now is a massive step up from what we did have

Ah, I misread Trev's info at a quick glance.

JeremyaFr wrote: ↑

Sun Jun 30, 2019 6:04 pm

Code: Select all

At offset 03156A, replace 7406 with 9090.

This will use 4444 format instead of 1555 format.

Hello,
I've added this patch to XwaExePatcher.

Hello,
Here is an in-game comparison of pixel formats: