Jump to content
argent77

BAM format change in Enhanced Editions

Recommended Posts

I've noticed just recently that many BAM files in the Enhanced Editions look differently in game compared to how DLTCEP or NearInfinity is displaying them. Apparently the game sometimes uses the alpha components of the palette, mostly used in *C.BAM files for spell icons. A quick comparison didn't show any hints how the game determines whether to use alpha or not.

Is there a reliable way to detect whether alpha components of the palette are used by the game?

Share this post


Link to post

I haven't noticed it in the original games and judging by a quick test in vBG2, alpha-blended palettes don't seem to be supported. IESDP also states that alpha components aren't used.

 

Edit: SPWI106C.BAM (Blindness) is a good candidate for testing. Just copy it over from BG2:EE to vBG2 and you'll see a big difference when you open the spellbook after scribing the spell.

Edited by argent77

Share this post


Link to post

In this case, the BAM itself is radically different between the two games (left: BG2EE, right: BG2). Not sure what happened there; I have to say I prefer the crisper, original version.

post-1216-0-07733300-1417986873_thumb.gif

Share this post


Link to post

After applying alpha blending it looks rather good and can even be used for all kinds of different backgrounds.

post-3876-0-28623500-1417990623_thumb.png

 

I still like to know if there is some kind of indicator that can be used to determine whether to apply alpha or not. For now I'm simply scanning the BAM palette in NearInfinity for non-zero alpha components to determine the right blending mode, but I'd rather use a safer method if possible.

Edited by argent77

Share this post


Link to post

There is some more information on the internal handling of the BAM format here. Specifically: the supported BAM frame blending modes, the BAM frame dimension limit (which has essentially been lifted in the EEs), and when/if the shadow color of the palette is used.

I would like to know how the engine implements transparency/translucency (from a mathematical standpoint) into BAMs that themselves store no Alpha channel transparency information.

This is a great resource.
http://www.andersriggelsen.dk/glblendfunc.php

We support the following blend modes

Translucent(7) checked off
glBlendFunc(GL_ONE_MINUS_DST_COLOR, GL_ONE);

Blended(9) checked off
glBlendFunc(GL_DST_COLOR, GL_ONE);

And in IWD
Translucent(7) and Blended(9)
glBlendFunc(GL_SRC_COLOR, GL_ONE);


It seems the BAM frame size limit of 255x255 px (or perhaps 256x256 px) has been lifted in the EEs. Can you confirm this?

256x256 has been lifted(ish). If it's compressed the engine still needs to decompress that bam to render it, so going over that should still be avoided. If it's a bamv2, then we can send that data directly to the card, so it renders much faster(but then you skip the fancy effects you can do to a bam)


In which scenarios does the second entry in the BAM's Palette take on the special properties of being the "shadow" color, or does it always?

When the bam is rendering, it asks the palette system how many entries are reserved. If the 2nd entry matches the shadow color of 0x00000000, then it returns 2 Otherwise it returns 1. So basically if the 2nd entry is the shadow color, then it will treat it as such. Otherwise it just uses the 1 reserved entry of the color key green.

 

-Sam.

Share this post


Link to post

Just a sidenote: those blending mode bits are in the vvc/pro (or hardcoded for internally used animations), not in the bam itself.

Share this post


Link to post

Apparently the game sometimes uses the alpha components of the palette, mostly used in *C.BAM files for spell icons. A quick comparison didn't show any hints how the game determines whether to use alpha or not.

I've been re-investigating how the alpha bit of the palette entries work recently, and I'm hoping someone else can either confirm or deny my findings. To me, it appears that an Alpha value of 255 is fully visible (opaque?) while descending values increase the transparency. An Alpha value of 1 appears to be fully (or nearly fully - see below) transparent. However, and Alpha value of 0 seems to be fully visible (opaque) even if other palette entries have non-zero Alpha values. I would have expected an Alpha value of 0 to be fully transparent if any other palette entry had a non-zero Alpha value. As that does not appear to be the case, I am left with a question:

 

1. Is an alpha value of 1 completely transparent, or is the only way to make a pixel completely transparent to set it to the TransColor:

The transparency index is set to the first occurence of RGB(0,255,0). If RGB(0,255,0) does not exist in the palette then transparency index is set to 0

 

Share this post


Link to post

I have been playing around with alpha values so I can confirm that 0 is completely opaque and 1 is completely transparent (or transparent enough that you do not notice anything). The reason for this as I see it is backwards compatibility where the alpha values have been ignored/set to 0 for most .bam files.

 

Near Infinity's .bam preview actually renders alpha values which is cool. However as with most other .bam editors you lose the alpha values if you save the .bam in NI. I go instead the route of palette patching with WeiDU which can give some nice results.

Share this post


Link to post

I can confirm that an Alpha value of 1 is indeed treated as alpha=1 (i.e. almost fully transparent). It seems full transparency can only be realized by using palette index 0.

Moreover, the following line from IESDP is not quite correct:

The transparency index is set to the first occurence of RGB(0,255,0). If RGB(0,255,0) does not exist in the palette then transparency index is set to 0


It looks like palette index 0 is always treated as transparent color, regardless of how this palette entry has been defined (at least in the EEs).

Share this post


Link to post

Moreover, the following line from IESDP is not quite correct:

The transparency index is set to the first occurence of RGB(0,255,0). If RGB(0,255,0) does not exist in the palette then transparency index is set to 0

 

It looks like palette index 0 is always treated as transparent color, regardless of how this palette entry has been defined (at least in the EEs).

:ohmy: This seems to be the case in ToB as well. I don't have ToSC installed at the moment to test it there, but presumably it would be the same. It is astonishing this has gone so long without being noticed (or noted). Any other surprises, quirks, or documentation errors in the BAM V1 format I should know about?

 

Edit: Also, is BG1/ToSC the only game that does not support BAMC files?

Edited by Sam.

Share this post


Link to post

I can confirm that an Alpha value of 1 is indeed treated as alpha=1 (i.e. almost fully transparent). It seems full transparency can only be realized by using palette index 0.

 

Moreover, the following line from IESDP is not quite correct:

The transparency index is set to the first occurence of RGB(0,255,0). If RGB(0,255,0) does not exist in the palette then transparency index is set to 0

 

It looks like palette index 0 is always treated as transparent color, regardless of how this palette entry has been defined (at least in the EEs).

 

Older IE versions don't work the same way. There are various rendering codes even in the same engine (depending on hardware or software rendering). Though i don't know where this particular info came from, i can very well accept that some engine versions treat the transparent green value as transparent.

Share this post


Link to post

 

I can confirm that an Alpha value of 1 is indeed treated as alpha=1 (i.e. almost fully transparent). It seems full transparency can only be realized by using palette index 0.

 

Moreover, the following line from IESDP is not quite correct:

The transparency index is set to the first occurence of RGB(0,255,0). If RGB(0,255,0) does not exist in the palette then transparency index is set to 0

 

It looks like palette index 0 is always treated as transparent color, regardless of how this palette entry has been defined (at least in the EEs).

 

Older IE versions don't work the same way. There are various rendering codes even in the same engine (depending on hardware or software rendering). Though i don't know where this particular info came from, i can very well accept that some engine versions treat the transparent green value as transparent.

 

You're right. ToSC behaves (for me) the way currently described in IESDP: 1st occurrence of RGB(0,255,0) is the transparency index (regardless of where it is located in the palette).

 

Back to the topic of Alpha values, current behavior means that, e.g. RGBA(100,100,100,255) would render exactly the same as RGBA(100,100,100,0) thus any palette entry with AA=255 can be set to AA=0 with no change to how the animation looks or behaves in-game, yes?

Share this post


Link to post

*Sighs*

 

After some further testing, how BAMs are handled and behave depends largely on the game engine and even more so on the specific context in which it is used. In fact there is so little consistency I am disinclined to invest any more time testing. A short summary:

  1. All tested engine variants appear to support RLE.
  2. PST and BG1/ToSC are the only game engines I have found that do not support BAMC files.
  3. PST and ToSC sometimes assign the TransColorIndex as currently described in the IESDP (i.e. can be located anywhere in the palette), and sometimes force it to be Index 0. By "sometimes" I mean depending on the context in which the BAM is used. Other games appear to force the TransColorIndex to be zero, but this is hard to confirm with absolute certainty without access to the source code.
  4. All games have BAMs with frame dimensions greater than 256, but IESDP currently hints (or outright states) that the maximum allowed frame dimensions for most games is 256*256.
  5. No game engine I tested appears to have a true "hard limit" when it comes to BAM frame dimensions, but certain usage contexts do have "local" restrictions. For example, inventory item icons in vanilla games traditionally have "local" size limitation of 64x64 pixels for the large frame and 32x32 for the small frame. However, I got a 300x300 pixel single frame BAM to display in ToSC without any apparent problem. Larger sized (e.g. 500x500 px) frames also displayed, but cause a memory buffer overflow type of error on ToSC. In ToB on the other hand, I got a 1024x1024 px frame to display with no apparent issues. I tried a 2048x2048 px frame in ToB and it displayed fine but slowed the game down to an unplayable level. Supposedly the EE engines have lifted the "local" size restrictions (such as for spell animations) even further.

The end result of all this is that there doesn't appear to be any way to automatically detect if a random BAM has exceeded any sort of semi-universal size limitations, or for that matter even which palette index is actually the TransColorIndex :(.

Share this post


Link to post
Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...