Sam.

But that is the "large icon" - it has 31x29 px and I didn't see any greater version of that icon. Not in EE, at least, and I don't have the old TotSC anymore. You must have a different version of the game than I analyzed. For future reference, you can just snatch them from here instead of extracting them yourself if that's easier.

Thanks, but that looks like the small icon, which supposedly didn't have a shadow to begin with. What I was trying to ask for was the shadow removed from the large icon so that it matches (comparatively speaking) the small icon. I played around with it myself again today until I had something I'm happy with. I'll keep plodding along, but I'm sure there will be more that give me trouble. IMISC70 is an interesting case. It's the only item icon I've processed so far where the small icon distinctively and undeniably has a shadow. Keep it or remove it? I'm inclined to call it an oversight and remove it, but decided to poll the audience.

That isn't necessarily the plan for EEFP, but it'll probably be an option in a mod. After some internal debate, I figured to hell with trying to draw fuzzy lines between what did and didn't count as an issue and just do them all, going in chronological order with the game's releases as later games often included large portions of the item icon BAMs from the previous games verbatim. I guarantee no timeline on completion. I've been slowed down by a particularly couple of weeks IRL. I'm keeping this in mind, but haven't gotten that far yet. Do you have an exhaustive list? These are fantastic and exactly what I was hoping for, thank you! I'm also struggling with removing the shadow form IMISC59 (TotSC) if you're willing to continue helping?

Polymorph Other and the squirrel paw moves the weapon out from the equipped weapon slot, so this one can be circumvented. See also SLTSTEAL.2DA and mods like Epic Thieving. Not that I'm suggesting any of this equipment be made undroppable or removed. It's a cool feature not a flaw that there are ways to tease out powerful items or XP from unexpected sources for the non-roleplaying power users. I enjoy getting the Helm of Opposite Alignment from the demonknight (before BD ducked that up) and the third ring of wizardry from Winski Perorate every playthrough, to name a couple.

+1

Sam's point that the copy in Candlekeep might have been added in error is convincing, so I would think it wins out if the imagined intent of the game designer is of paramount importance. That said, I found the comment that replacing Batalista's Passport with a Ring of Fire Resistance in the Gibberling Mountains "would significantly impact the early game" to be incredibly surprising - so much so that I wonder if it was made in the belief that there would be no magic ring in AR5500? Something about the original wording of the proposal led me to believe the suggestion was to "remove" the ring from the Gibberling Mountains. The post has since been edited, so I can't be sure if my initial interpretation was warranted or in error. Regardless, I still feel this is the correct place for the canonical item. The description from TotSC is: I would say the description itself indicates that there are multiples of this ring and/or very similar ones (eyeing the original BG2 variant), all having the same origin. I see no reason to swap any of these with a more generic version. Also, I'm against messing with the original game developer's easter eggs.

I've been updating PS BAM, creating scripts, and building toolchains to help automate this as much as possible while still allowing human inspection for quality control. Some BAMs are one and done, while others require pixel by pixel level edits in the vein of 1pp (which have been integrated into the EEs). I'm over 100 item icon BAMs in of oBG1 (TotSC), but the going is slow, as predicted. I'm willing to continue on this trek (which will likely take months), but I could use some help. So far in particular I could use some help removing the shadows from the mage robes. Specifically iclck10, iclck11, iclck12, iclck14, iclck15, and iclck17 (but all of them really). Theo goal is to keep the original graphics as original as possible while resolving the stated inconsistencies/issues. @Lava are you interested?

The PVRz format for area animations and doors has resulted in graphical glitches (usually described as seams or black lines between the tiles). Some have been reported and fixed, but I doubt all of them have. Here is an example of one such report. Is there a list of any such issues that remain in the current builds? I can describe how I have gone about fixing it for mods, but the process is currently a bit tedious. More to the point, is this something EEFP is interested in addressing?

On this one I disagree. It is general opinion (if not fact) that the later chapters of oBG1 were made in a bit of a rush. My belief is that the Ring of Fire Resistance was purposefully and thoughtfully put in that hidden crack (before the container highlighting button was added to the engine) in the Gibberling Mountains first, and was added to the Candlekeep catacombs (perhaps without considering that the item should have been unique) well after the fact. Moreover, that ring is one of the more defining features of that area, and I believe taking it away would significantly impact the early game, IMO in a negative manor. A bit off point, but I have never personally been bothered by finding multiple copies of fairly generic but technically "unique" items in a playthrough. With that being said, I respect that some people feel strongly to the contrary.

I agree, but I could be considered biased based on where I live, so didn't want to weigh in unless someone else brought it up. To me, the originals seemed to strongly favor American spellings.

I can't recall ever seeing this happen. Guess I slaughter everything in sight too quickly for it to matter... After killing every monster, bandit, thug, and animal on the Sword Coast, I began to wonder who the real monster is...

It has been suggested once or twice over the years, and to date I'm not aware of anyone with the skills to make it happen taking it seriously enough to do it. It could have a place in a mod, but I'm not sure it should be in this mod.

I have a multi-lingual oBG2+ToB on DVD that had an install option of like 6 or so languages. Was such a thing ever made for IWD?

Personally, I interpret it as this one.

As promised, here it is. You can select whatever background color you want, and hover the mouse over each image to view it with transparency enabled. The shadows are only made 50% transparent if they are RGBA(0,0,0,0) at palette entry 1. If there is a real desire to also do this for RGBA(0,0,0,255) at palette entry 1, I can accommodate.

Like I said, I'm unfamiliar with the language and didn't spend all that long trying to decipher it. All I can say is that from personal experience, I am not happy with how it handles palettes. You assume you have an existent and appropriate palette to pull from, and that all frames use the same palette. Unless you have taken extreme and meticulous care to ensure this is the case, it won't be. Could bammer be improved? Absolutely and that would be great. Better tools available to modders and developers is never a bad thing. Will bammer be improved? Maybe... but I won't hold my breathe. If bammer is improved, will it be a magic fix for all the issues there are with item icons? I think not. Regardless of the above, you are of course welcome to take on fixing/improving anything you like in whatever manner you deem best. If the community agrees it's a solid improvement or correctly fixes a genuine bug, it'll end up in a fixpack or tweakpack.

http://iesdp.gibberlings3.net/ and https://iesdp.gibberlings3.net/ no longer redirect to https://gibberlings3.github.io/iesdp/ Can we get that back? My browser history autofill keeps putting the old link at the top of the stack, and without careful scrutiny I tend to click the wrong one.

And so it begins...

This will also fix this bug. Preview:

The images in my table essentially have the alpha channel turned off. Looking through the item icon BAMs from BGEE, SoD, and BG2EE, none of them are BAM V2, and there are only a handful of BAMs that have alpha values in the palette other than 0 or 255 (both values render as completely opaque). They are IAX1H19, IBLUN40, ISTAF25, ISW2H22, OHRICLK3, and SPWI920A all in BG2EE. I'll see about re-exporting them with alpha enabled for comparison. BAM V2 isn't supported in all applications, and I'm unsure if they can be used for item icons. Even if they could, no modding tool I'm aware of can currently perform the bin packing across multiple files, so you'd end up with 1 PVRz page for each BAM, which would be a non-starter. Presumably, they would be storing the offsets in the BAMD file, not in an extra chunk in the PNG itself. However, they don't even seem to be doing that. Instead, they are leaving the offsets in the compiled BAMs at 0 and letting the engine calculate the offsets on-the-fly based solely on the dimensions of the frame. Beyond that, how deep down the rabbit hole do you want to go? I played around with bammer (Beamdog's BAM building tool) a few years back, and while I'm not familiar with the Go programming language, I have poked around the source code just a bit. It appears to reserve pure green in palette index 0 for the transparent color, and then quantize the image down to 255 colors, which of course also includes the green of the background which may or may not get mixed with other colors in the process. Then the original image is mapped back to the combined palette. The result is either a duplicate of the transparent color in the palette, or an off-green palette entry that probably isn't used. Furthermore, bammer often hardcodes a non-shadow color (not pure black) in the shadow index of the palette in addition to two additional hard-coded palette entries. This false shadow color palette index is rarely even used, as the actual shadows in the image don't use this color. This is the source of many of the warnings issued by PS BAM in the comparison table. The end result is that each BAM may use up to 4 fewer colors in the EEs than they did in the classic games. Furthermore, looking at the quantizer, it does not appear that the alpha channel is even being fed into the quantizer to generate the palette. If this is really the case, then trying to map the original RGBA colors to the palette generated is going to result in huge errors if the original image had semi-transparent pixels. I haven't studied the code extensively, but I get the feeling this is a straight median cut quantizer. A modified median cut algorithm would produce much better results, tho with very small images like these, it might not be that noticeable.

This also definitively fixes all multi-part area animation desynchronization issues.

PS BAM is extraordinarily good at compressing BAMs, far beyond any other tool available. Smaller mods, smaller games, faster downloads, faster rendering in-game. There are significant benefits. AFAIK, only oBG1 and oPST do not support the BAMC format, in which case use a version of Miloch's "Decompress a BAM" patch when installing on those games. Am I missing something else? This seems to be a significant source of errors and inconsistencies, and I STRONGLY recommend against doing that at this stage of development of the EEs. It may have made sense early on, but that is no longer the case. They will simply end up reintroducing many of the issues we are attempting to address. Bammer was a nice idea, but it has flaws. Edit: and if we're aiming for backwards compatibility, transparency handling must be kept in mind.

I have done some initial research into the current state of the item (inventory) icons in the Baldur's Gate series of games: oBG1 (AKA TotSC v1.3.5521), oBG2 (AKA ToB v2.5.26498), SoD v2.6.6.0, and BG2EE v2.6.6.0. I have attempted to capture all item icons, regardless of whether or not they are explicitly used by any item files. If you find any I have missed, please bring it to my attention. It is also likely a few BAMs which are not item icons have slipped through my filtering into this list. Included are a list of warnings given by PS BAM for each item icon, along with a separate estimation of the primary palette index used for the shadow (which is assumed to exist) on the large item icon. Here is the comparison. Exactly how a BAM is rendered depends on the game engine and engine version, game configuration settings, context of usage within the game, computer hardware, and also sometimes graphics settings at the OS level. After more than a decade of studying BAMs and how they are rendered, the following are some general rules to follow to ensure the optimal display of a BAM under all possible scenarios. The transparent color should be pure green RGBA(0,255,0,0) at palette index 0. No other palette entry should be this color; therefore, no pixel that should not be transparent should use this color. The shadow color should be pure black RGBA(0,0,0,0) at palette index 1. This color at this palette entry is generally rendered as ~50% transparent. No other palette entry should be this color; therefore, no pixel that should not be rendered as a semi-transparent shadow should be this color. Outside of the IE, an alpha value of 0 in 32-bit images indicates that color is completely transparent and an alpha value of 255 indicates that color is completely opaque. However, for backwards compatibility purposes in a BAM's palette, an alpha value of 0 is treated as completely opaque whereas an alpha value of 1 is almost completely transparent. As a result, any program intending to render a BAM must scan the alpha values in the palette. If any alpha value is non-zero, the BAM is rendered as 32-bit (and any alpha values of 0 are made 255). However, if all alpha values in the BAM's palette are 0, then it can be directly rendered as a 24-bit image. The takeaway is that there is no functional difference between a BAM palette using alpha values of 0 and 255, but using 0 can result in more efficient rendering at no cost and with no functionality sacrificed. This is relevant only for EE games. Additionally, the following best practices specifically apply to item icon BAMs. For reference, traditionally an item icon consists of two frames. Sequence 0 contains the large item icon (with a shadow) that is displayed when the item is picked up in the inventory. Sequence 1 contains the small item icon (without a shadow) that is displayed when the item is placed in an inventory (including backpack) slot. The large item icon (Sequence 0) must be no larger than 64x64 px. The X and Y offsets of this frame are calculated according to the following rules: CenterX=Width//2 CenterY=Height//2 In the classic engines, the small item icon (Sequence 1) must be no larger than 32x32 px. The X and Y offsets of this frame are calculated according to the following rules: CenterX=(Width-32)//2 CenterY=(Height-32)//2 In the EEs, the "small" item icon (Frame 1 in Sequence 0) must be no larger than 64x64 px. I suspect (can't verify as offsets are ignored) the X and Y offsets of this frame should be calculated according to the following rules: CenterX=(Width-64)//2 CenterY=(Height-64)//2 In the above, // is a floor divide (drop the remainder) The EEs do not use the small item icon and BG2EE has, in general, dropped this frame from the BAMs entirely. Instead, the EEs use the large item icon (with the shadow) for both when the item is picked up and when it is placed in an inventory slot. However, the classic item icon behavior can be restored by adding the small item icon as a second frame to Sequence 0. Doing so is backwards compatible with the classic engines. In oBG1 and oBG2, the small icons filled the inventory slot and would become bigger than the slot when picked up. In the Enhanced Editions, the inventory slots are larger (doubled in size). As a result, the smaller frame from the original icons is too small, even when used. The EEs use the larger frame in order to fill the larger slots, which are now sized to fit an image up to 64x64 px (used to be 32x32 px). Issues to consider At the engine level: IIRC, the EEs used to (pre v2?) calculate the inventory icon offsets as follows. If the X and Y offsets were 0, then the frame would be centered automatically based on the width and height of the frames. If the X and Y offsets were non-zero, those values would be respected and used to center the frame. See above for details on how they should be calculated. The current EE behavior (from v2 onwards?) does not seem to behave this way. Instead, any frame offsets are completely ignored, and are instead centered based solely on the frame width and height. The EEs (particularly SoD) seem to have made an effort to center the large item icon based on the primary image (excluding the shadow). This places the shadow down and/or to the right of the center of the inventory slot. For obvious reasons, this can't be done when the large frame is approaching or at the maximum dimensions (64x64 px). If the frame dimensions were respected by the engine, this modified centering could be done simply by adjusting the frame X and Y offsets by the number of columns and rows of pixels made up exclusively of shadow. With a well-formatted shadow, this would be easy to do programmatically. Since the frame offsets are not currently respected, however, this modified centering has been performed by adding rows and columns of transparent colored pixels to the frame to artificially adjust the width and height (which are then used to center the frame). Many of the item icon BAMs (both original and new) have been done this way in SoD. To me, this seems like a major regression of engine behavior. It has no conceivable benefit (other than masking the laziness of having not made appropriately sized "small" item icon frames), and comes at the cost of requiring extravagant and byte-consuming manipulations of the frame images themselves in order to reproduce the old behavior. At the BAM level: (in no particular order) At some point, a few of the item icon frames used in the EEs got hosed compared to the originals. Examples include imisc1j and IMISC5N in SoD and BG2EE, IMISC61 and IMISC61 in SoD, ISW2H22 in BG2EE, etc. No shadow at all on the large icon. A few examples include IBOLTS01, IMISC13 in SoD, and IMISC17, IMISC18, and IMISC19 in BG2EE, and IAX1H44, IMISC72 and IMISC73 in all games. Clearly bad shadow color (noticeably not black). See IBRAC26, IGLBGRE1, IMISC40, IMISC43, etc. Beamdog has generally inserted a mid-level grey color, RGBA(128,128,128,255), into the palette entry 1 (the shadow color) of item icons. Not only is this (IMHO) a poor choice of shadow color, but this palette entry is rarely (if ever) even used for the actual shadow in the frame. Shadows using pure black, RGBA(0,0,0,0), but not located at palette entry 1. Shadows using an off-black color (e.g. RGBA(1,1,1,255) in imisc3n), sometimes located at palette entry 1 but more often not. Use of an alpha value of 255 in an otherwise non-semi-transparent BAM. While not strictly wrong, I feel it is sub-optimal for reasons explained above. This is trivial to correct with PS BAM. Noticeable differences in icon sizes between items of the same type. See IRING01 vs IRING02. While you wouldn't want to upscale ALL icons to the max 64x64 px (i.e. a sling bullet shouldn't be the same size as a two-handed sword), there is some room for improvement. See also https://forums.beamdog.com/discussion/81852/bg-ee-sod-bgii-ee-inconsistent-icon-size/p1 Transparent color that is not pure green (usually BAMWorkshop's colors). See ISW1H58 etc. This is trivial to correct with PS BAM. Inconsistencies between games for the same item icon. See IXBOW06 and ICHAN01. Personally, I generally prefer the oBG1 style over the oBG2 style where applicable. Where BD has done the best job of updating/improving the icons (IMO) are the scrolls and spell icons. See SPPR417A as an example. They have also improved the shadows of some item icons. See ICHAN01. Inconsistency in the function of scrolls between SoD and BG2EE, and within the same game. Specifically, whether the scroll gets rolled up when picked up. See SPWI101A vs SPPR732A etc. Inconsistency in shadow offset direction (sometimes down, sometimes right, sometimes both) and offset amount (see IBLUN06 vs IBLUN07). Inconsistency in magnitude of shadow offset. See IBZPLO01. Inconsistency in shadow size (a handful of shadows are considerably smaller than the original item). For example, see IBLUN09. Some of Beamdog's new item icons are larger than 64x64 px. Depending on game configuration settings (like Scale User Interface) and possibly OS level display settings (like DPI settings), these icons can overflow their bounding box in the user interface (inventory screen, store screen, etc.). They should be trimmed, and if still too large, scaled down. Anything else I haven't thought of or noticed? The way I see it, the most thorough (and effort intensive) method of resolving these issues would be this: For each item icon, pick the best one available between all games, preferably one with a "small" item icon (with no shadow). Correct the transparent color if needed. Set all alpha values in the palette from 255 to 0. Remove any existing shadow from the large frame Resize frames up or down as necessary, leaving enough space (within the 64x64 px limit) to re-add the shadow back later. Replace any remaining pure black pixels with a slightly off-black color. Trim all frames. Create the small item icon if necessary Create a pure black shadow at consistent offsets on the large icon, and save this as a third frame. Optional alternative: Either recreate or upscale the original small item icon to be twice the original size. This will become the "large" item icon with no shadow. Rebuild the item icon BAM with the proper transparent and shadow colors at the proper palette entries, and with 3 frames. Sequence 0 Frame 0 is the large item icon frame with the shadow Sequence 0 Frame 1 is the large item icon frame without the shadow Sequence 1 Frame 0 is the small item icon Calculate the proper frame offsets as described above. Optionally, adjust the offsets to account for the rows/columns taken up by only the shadow. Compress the BAM. Use this new BAM in all the EEs, and backport them to the classic games via a mod, to be installed very early in the install order. Modify the Enhanced Edition game engines to respect the item icon frame offsets if they are non-zero, but calculate them automatically if they are 0. Between PS BAM and Imagemagick, I think I can mostly automate 2, 3, part of 4, part of 5, 6, 7, 8, 9 with some guidance, possibly some of 10 with some guidance, 11, 12, 13, and the mod part of 14. What I'd need significant help on would be 1, 4 simply for the amount of time and effort involved, 5 if we want to scale any of them to be a consistent size within family, deciding the offset of the shadow for 9 (doesn't necessarily have to be the same amount for all item types), probably some instances of 10 since I'm no artist, the native EE usage of 14, and of course 15 is out of my hands. Number 4 is significantly more complicated than you might expect, and I know of no straightforward way to do 5 that gives universally optimal results, so some trial and error is in order. Considering the scale of what I'm proposing, this quickly becomes a significant time sink. Does this all seem like a reasonable assessment of the current situation? Worth the effort, or should the scope be scaled back to only those item icons that are obviously and visibly broken in-game? I fully recognize that not everything in this list constitutes a "bug" in the context of EEFP, but a good number of them may. I'm looking for feedback on what, if anything, we may want to address here. For example, some shadows are clearly the wrong color while others are a bit off but hard to distinguish in-game. Where to draw the line?

The large and medium wyvern animations do not have shadows, while the small and tiny wyvern animations do, which seems like an oversight. I have attempted to generate some. While they're not perfect, I'm of the opinion they are significantly better than none at all. Two variants each are attached for the large and medium wyvern. Take your pick of which you prefer. If any true artist wants to tweak then, I can provide the component parts or help facilitate converting images into BAMs. MWYV_Shadow_Sizes.zip Edit: However, due to this engine quirk, the large wyvern animation will not display a shadow in game even when one is added. I have yet to test if adding "extend_direction_test=8" to the INI file is enough, or whether an engine edit is necessary. Edit2: It appears an engine edit is needed. Vampire animations in the Baldur's Gate games have shadows. While the developers clearly made them this way, it isn't D&D cannon. I have made versions of the male vampire, female vampire, and Bodhi animations without shadows, cleaning up many bad shadow pixels in the process. This may be more of a tweak than a fix, but here they are: VampireNoShadow.rar

[Bug] Multi-part area BAM animations show visible lines between the sections What is currently happening Multi-part area animations show visible lines between the sections What should be happening Multi-part area animations should not show visible lines between the sections Steps to reproduce the bug Start a new IWDEE game with default characters Using the console, move to area AR1105 Click through the dialogue until the cutscene plays and the portal animation is activated Notice the visible lines between the sections of the portal animation, particularly the left and right portions of the top half. If available, a fix Place the attached BAMs in the override folder, as appropriate for each game See that the visible lines are gone Notes Because the EEs allow BAM frame dimensions larger than 255x255 px, this issue can be fixed by recombining the split animations into the top left section's BAM and blanking the BAM frames for the other sections. Fixing the issue in that way does not require an engine fix or modifying the area files. This should cover all of BGEE, SoD, BG2EE, and PSTEE except for AM3017[A-D] and AM6200[A-D]. Those are the Lum the Mad (which I don't think should be combined) and Melissan replenish (I don't understand the mechanisms of how/when these are played). Note that these have received minimal testing. Let me know if I've missed anything. SplitAnimationsCombined_20210501.zip