Sam.

I was working on downsizing/cropping some original artwork from 1024x1024px to the EE portrait sizes, and decided to do a little testing. I tested with BG2EE v2.6.6.0. My results seem to be contrary to conventional wisdom. Using ImageMagick I resized and cropped a test portrait to the three EE sizes: 210x330 Large, 169x266 Medium, and 54x84 Small. On a hunch I also made one that was 420x660 (I’ll call it G for Giant) and tried all of them in-game. On the Records screen (which conventional wisdom says should use the Large size), the Giant portrait was noticeably the clearest, the Large was a bit blurry, and the blurriness got worse with decreasing size. When I took a screenshot and counted the pixels of the portrait on the Records screen, I got 253x392px (I’ll call it H for Huge). The portrait overlapped the border by at least 1 column of pixels on the right, and a row of black/dark pixels between the portrait and the bottom of the frame around it, and 1-2 rows of black/dark pixels between the top of the portrait and the frame. I believed this was an indication the engine was maintaining aspect ratio when resizing the portraits. To be sure, I tried the original 1024x1024 portrait, but the same 253x392px with the same border was displayed on the records screen (with the aspect ratio clearly distorted). I then used ImageMagick to resize the original to 253x392px and tried it in the game. I compared the in-game screenshots for the Giant, Huge, and Large portrait sizes to each other and to the Huge size outside the game. The Huge was less blurry than the Large, but perhaps ever so slightly more blurry than the Giant (with a caveat). The Huge portrait displayed in the Records screen at a slightly different aspect ratio than did the Giant and Large. Comparing in-game and out-of-game Huge portraits, I could perceive no visual difference between the two. This indicates the game is distorting the aspect ratio of the Giant and Large portrait sizes. For the caveat: the difference in perceived blurriness was so minor I was probably just seeing artifacts caused by the different area ratios. All of this was tested with the “Scale User Interface” in-game option turned ON. When I turned it OFF and counted the pixels of the portrait on the records screen, I got 180x279 which is the same aspect ratio as the Huge listed above (actually the same area ratio would be 180x278.8932806 but it rounds to the nearest whole pixel). I maintain this is evidence all of my observations so far remain true with this setting turned off, it’s just that everything appears smaller on screen and so the differences would be harder to spot. Moving on to the portraits on the game screen, I again tested with “Scale User Interface” in-game option turned ON. I tested all three (Large, Medium, and Small) of the traditional EE portrait sizes as well as the Giant and Huge sizes specified above. On the game screen (which conventional wisdom says should use the Medium size), the Giant by far looks the worst, Huge is pretty bad too, and the Small is very blurry. Large and Medium are pretty close in my test case, but Medium is just a bit better. When I took a screenshot and counted the pixels of the portrait on the game screen, I got 76x118px. For comparison, Medium is 169x266px which means it is being downscaled significantly even when up-scaling the user interface. Comparing the Medium portrait to a 76x118px one sized/cropped with ImageMagick, the results are quite similar. Personally, I prefer the ImageMagick result in terms of detail vs blurriness. I also think ImageMagick’s 76x118px result is more accurate in terms of aspect ratio, but the difference is probably on the order of half a pixel. Note that the 76x118px game screen portrait has the same aspect ratio (within rounding) to the Huge one calculated from the Records screen screenshots above. I suspect that DPI scaling settings and monitor dimensions may play a role in this, for the sake of transparency I am testing on a modest 1920x1080 laptop screen with 125% DPI scaling with OpenGL version 4.4.0 – Build 21.20.16.4550 running on Intel ® HD Graphics 530. My takeaways: · BG2EE’s internal scaling algorithm: o Does not maintain aspect ratio o Is better at downscaling than upscaling, but only up to a certain point. Large factor downscaling produces inferior results to what can be achieved by 3rd party tools. · On my setup, ideal dimensions for the “Large” portrait size are 253x392px and NOT the conventionally accepted dimension of 210x330px. · On my setup, ideal dimensions for the “Medium” portrait size are 76x118px, but the conventional 169x266px size produces similar results depending on the scaling algorithm. · Using only a single (Large) portrait in both the “Large” and “Small” slots found within a PC/NPC’s CRE structure results in inferior results for the smaller portrait (depending on quality of the internal/external scaling algorithm). The unmodded EEs only allow to select a single portrait during character generation that is assigned to both slots. I would appreciate if anyone else testing under a different environment could confirm/deny my findings. @Bubb, I recognize this is not likely your area of interest, but if you have any particular knowledge about what the engine is actually doing here that would be very informative.

Try these with helm18.itm and VVCs as-is. Seems to work for me, but not sure how robust it is. I have a second idea if this one doesn't work out. [attachments removed] Edit: These weren't very good either. They fixed the issue with the gaps, but made the animations doubly dark because they were playing on top of each other. More importantly, rapidly pausing and unpausing while fully zoomed in de-synced the two animations, so it would gradually appear as if two separate ioun stones were circling, but buggy. Is is probably true of all split foreground/background animations, but was particularly noticeable here. The solution was that because the ioun stone animations didn't need to actually pass behind the character model (just over their head), and single animation+VVC could be used for the entire circuit, but the offsets had to be adjusted to get everything ordered right.

@paladin84 Sent you the modified BAMs at SHS. BTW, I misremembered how these worked. You don't need to edit the VVCs. You'll need to edit the items to play only the first VVC and not the second. Edit: That didn't work as I expected (same issue as here). Working on figuring it out.

I started playing around with it tonight. I can mostly automate the combining process with PS BAM. The VVCs will need to be edited to use only the first of the two BAMs (I've kept the offsets in that BAM the same). First one attached. However, the 1st and last frames end up in the same position but aren't the same graphically. Should I remove one or the other? After your answer I'll finish combining them tomorrow. [attachment removed]

The EEs don't limit BAM frame dimensions to 255x255 px like oBG2 did, so you can just combine the top and bottom halves of the animations into single frames. I can do it in the next day or two if you don't get to it first.

And @argent77 once again swoops in with the solution to all our problems. In this case an automated solution that eliminates the dark lines around overlay tiles when converting from palette-based tilesets to PVR(Z)-based tilesets. His method is different than mine, but objectively his approach is superior. And he released it before I could finish writing my own tool to do this, so I bow to the master.

This deserves it's own topic. At this point NI deserves it's own subforum (it actually has one over at Pocket Plane but no one uses it). I have questions, I have comments, once I try it for myself I'll have suggestions.

My attempt at a fix can be found here. I don't think it's so much an engine rendering issue as it is a graphical error built into the original tileset. I also don't think this is the only example, indicating a flaw in the original development process. I added two functions (ps_tileset_adjust_brightness and ps_tileset_adjust_brightness_scale) to my tileset manipulating WeiDU function library PS_Tileset for just this.

So let me get this right: a Sahuagin Scout who has eaten no less than four local fishermen and who is part of the vanguard of an evil army intent on invading the Sword Coast if not Baldur's Gate itself has been captured, and you want to give it a glass or bucket or barrel of water and send it on it's merry way? Okay, that's fine and quite empathetic of you, but I feel like such a course of action would have some repercussions down the road. [Note that I don't actually recall the backstory of this particular Sahuagin, but I feel the above scenario likely holds.]

WeiDU Highlighter for Notepad++ VScode support for WeiDU syntaxes

I remembered the search map, height map, and light map all being 4-bit. I remembered incorrectly: only the search and height maps were 4-bit. The light maps are 8-bit paletted, or (at least in the EEs) sometimes 24-bit. For the 8-bit ones, I could make a function similar to ps_tileset_replace_palette_entry but for bitmaps instead of tilesets. Handling 24-bit bitmaps isn't any more effort than adjusting the function to work on 8-bit BMPs. Of course, all this hinges on the colors being used in the light maps being the root of the issue, and even if it is you'd still need to know the colors causing issues and the colors you'd like to remap them to. Not so hard for 16-color (4-bit) palettes; much harder for 256-color (8-bit) palettes, unless Yovaneth used a standard set?; back to the drawing board for 16M colors (24-bit).

This function (ps_bitmap_swap_pixel) can be used to swap the lightmap pixel codes from the offending value to another one using WeiDU, rather than searching thru each area manually.

The server owner is aware of the issues. We're sorry for the inconvenience. I'm sure @Sam. will sort out your account validation when he's available. You should be good to go.

I fixed all of the split animations @Galactygon and I could find in BGEE/SoD/BG2EE/PSTEE, except for AM3017[A-D] and AM6200[A-D]. Those are the Machine of 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). From PSTEE I believe I did: It's always possible I've missed some, in which case if you get me a list I'll be happy to do them. Edit: I reread the last post for a third time and realized you may be saying the corrected animations for PSTEE have been committed but just aren't installed for that game yet, in which case nvm.

@Weigo I'm trying to test something out and I need an area (WED and palette-based tileset) that has at least one tileset animation (like a fireplace or the crystal in High Hedge), at least one door, and at least one overlay (water, lava, etc.). Do you know of any?