41 replies to this topic

[Sam.]

File Name: BAMWorkshop
File Submitter: Sam.
File Submitted: 20 Aug 2014
File Category: IE Modding Tools

This has been hiding behind the scenes since sometime in 2011, and it should have been uploaded a long time ago. Thanks to Erephine for the majority of the update! (Note that it still only works with BAM V1 files.)

As the name implies, it's a patched version of BAMWorkshop I, fixing a few issues and making it a lot more convenient to batch/edit (frame & sequence navigation via keyboard, properly working offset edit boxes, etc). It's tested in as far as it's what I'm using in development, and I haven't run into any issues.

Not sure whether it's okay to distribute (don't have permission, which is in part why I haven't mentioned it before) but it's a 10 year old modding tool, so I think sending you the link is probably okay (?)

=== BAM Workshop I UNOFFICIAL PATCH notes ====

1.1.0.7->1.1.0.8 (Erephine)
	- Background and shadow colours are no longer reset on file load (preserving saved colours)
	- Editing of background and shadow colours enabled from palette editor
	- Offset edit boxes now correctly accept '-' signs typed into them
	- Ability to set shadow (second entry) colour when exporting to .gif (change via SetExportCol.exe)
	- Keyboard shortcuts added for frame/sequence navigation and common commands
	- About page updated to reflect current version

1.1.0.8->1.1.0.9 (Sam.)
	- Fixed small graphical glitch on About window
	- Included source code for SetExportCol.exe

1.1.0.9->1.1.1.0 (Sam.)
	- Changed the quick color selectors for the transparent/shadow colors from teal/pink to green/black
	- Created a schnifty new BAMWconfig.exe program that can be used to set not only the shadow color when exporting to .gif (depreciating SetExportCol.exe) but also the quick color selectors used for the transparent and shadow colors.  [Run "BAMWconfig.exe -about" from the command line to view the legal and copyright info]

Click here to download this file

 

Edit:  Download, with history, moved to GitHub.

[Tash]

Oh, Sam. Where were you when I needed this most? Now that I've learnt Workshop II and DLTCEP the hard way to get stuff done 100% without the infamous corruption. Thankfully this one loads up no problem and doesn't require some ancient runtime like the previous version. Thanks!

[Sam.]

Thankfully this one loads up no problem and doesn't require some ancient runtime like the previous version. Thanks!

The only errors that fall into this category I have encountered are because the installers for BAMWorkshop (and MOSWorkshop) are 16-bit and won't run in x64 environments.  One solution to this problem was proposed at Baldur's Gate Mods/CoM.  A simpler solution is to use Universal Extractor to extract the actual program executable from inside the 16-bit installer package.  This package of BAMWorkshop neither includes nor needs an installer.  BAMWorkshop should install its own context menu shortcuts (and file associations?) after you run the program a couple of times and Explorer is refreshed (a computer restart may or may not be required).

Edited by Sam., 20 August 2014 - 10:26 PM.

[Tash]

16-bit installer package.

 

I'm running a custom-made WinXP with disabled 16-bit functionality, so that's why. Anyways, your version works fine .

 

BAMWorkshop should install its own R-Click menu shortcuts after you run the program a couple of times and Explorer is refreshed (a computer restart may or may not be required).

 

Whoa, now hold on a sec. Does it inconspicuously add registry and context menu entries? THAT, I don't want.

Edited by Tash, 20 August 2014 - 07:41 PM.

[Sam.]

BAMWorkshop should install its own R-Click menu shortcuts after you run the program a couple of times and Explorer is refreshed (a computer restart may or may not be required).

 
Whoa, now hold on a sec. Does it inconspicuously add registry and context menu entries? THAT, I don't want. 

That isn't something Erephine or I changed. It is vanilla behavior. IIRC the installer had no option for NOT adding a file association and context menu items, it just did it. Even now that the installer has been bypassed, it is the vanilla behavior of the program to add them silently (based on what I have observed). It has been a while, but IIRC I think I manually edited the permissions of the registry keys/values to prevent the program from changing them so that I could use my own custom ones (so that the context menu items are distinguishable from those of BAMWorkshop II).

For the record, the installer would have set the following registry keys and values:

[Registry]
Reg1Path=HKEY_CLASSES_ROOT\.bam
Reg1PathUninstall=1
Reg1ValName=(Default)
Reg1ValType=0
Reg1ValData=BAMFile
Reg2Path=HKEY_CLASSES_ROOT\BAMFile
Reg2ValName=(Default)
Reg2ValType=0
Reg2ValData=Black Isle Animation
Reg3Path=HKEY_CLASSES_ROOT\BAMFile\DefaultIcon
Reg3PathUninstall=1
Reg3ValName=(Default)
Reg3ValType=0
Reg3ValData=[Program Files]\BAMWorkshop.exe,0
Reg4Path=HKEY_CLASSES_ROOT\BAMFile\Shell
Reg4PathUninstall=1
Reg5Path=HKEY_CLASSES_ROOT\BAMFile\Shell\Open
Reg5PathUninstall=1
Reg6Path=HKEY_CLASSES_ROOT\BAMFile\Shell\Open\Command
Reg6PathUninstall=1
Reg6ValName=(Default)
Reg6ValType=0
Reg6ValData="[Program Files]\BAMWorkshop.exe" "%1"
Regs=6

 

 

[Miloch]

Sweet. Guess I should check in here more often.

1.1.0.8->1.1.0.9 (Sam.)     - Small graphical glitch fix by Sam.

I know Erephine fixed some glitches - what was the one you fixed?

 

One minor thing that always bugged me about BAM Workshop is that it uses teal/pink for transparent/shadow pixels instead of the normal green/black. Don't suppose you could do something about that?

[Sam.]

Sweet. Guess I should check in here more often.

1.1.0.8->1.1.0.9 (Sam.)     - Small graphical glitch fix by Sam.

I know Erephine fixed some glitches - what was the one you fixed?

Just this:

 

One minor thing that always bugged me about BAM Workshop is that it uses teal/pink for transparent/shadow pixels instead of the normal green/black. Don't suppose you could do something about that?

Should already be possible, but you may just have to set it manually when creating new BAMs.

    - Background and shadow colours are no longer reset on file load (preserving saved colours)
    - Editing of background and shadow colors enabled from palette editor

 
 
If, however, you mean these little preset color selectors, then I'll take a look.  No promises, though:  I don't really do decompilers and machine language, which is what it would likely take...

[Sam.]

One minor thing that always bugged me about BAM Workshop is that it uses teal/pink for transparent/shadow pixels instead of the normal green/black. Don't suppose you could do something about that?

If, however, you mean these little preset color selectors, then I'll take a look.  No promises, though:  I don't really do decompilers and machine language, which is what it would likely take...
 

Turns out all it took was a Hex-editor, a little trial-and-error, and a beer .
 
New version V1.1.1.0:

1.1.0.9->1.1.1.0 (Sam.)

• Changed the quick color selectors for the transparent/shadow colors from teal/pink to green/black
• Created a schnifty new BAMWconfig.exe program that can be used to set not only the shadow color when exporting to .gif (depreciating SetExportCol.exe) but also the quick color selectors used for the transparent and shadow colors.  [Run "BAMWconfig.exe -about" from the command line to view legal and copyright info]

If anyone finds that the teal/pink colors are still cropping up somewhere, tell me about it so I can address it.

[CamDawg]

First: great that you're taking this on Sam..

IIRC the one feature I used from BAM Workshop II was the ability to un-palette, modify, and then re-palette a BAM, which was incredibly useful for quick-n-dirty icon recolors (assuming you could get it done before it crashed). BAM Workshop either didn't have this feature, or did it poorly (didn't keep the special transparency/shadow colors maybe?). Getting that working would be great.

[Sam.]

IIRC the one feature I used from BAM Workshop II was the ability to un-palette, modify, and then re-palette a BAM, which was incredibly useful for quick-n-dirty icon recolors (assuming you could get it done before it crashed). BAM Workshop either didn't have this feature, or did it poorly (didn't keep the special transparency/shadow colors maybe?). Getting that working would be great.

BAMWorkshop never had a feature like this (unlike BAMWorkshop II), so this would be a fairly major edit even if I had the source code, which I don't. My best (educated) guess is that BAMWorkshop was written (and compiled) in Microsoft Visual C++ 5.0/v6.0 (MFC), and as such, decompiling it would be... nontrivial (at best). As such, I'm afraid your request is beyond my skills at this point. Sorry to disappoint...

[CamDawg]

No worries, I'm still really happy with the progress so far.

[Miloch]

 

1.1.0.9->1.1.1.0 (Sam.)

• 
  
• Changed the quick color selectors for the transparent/shadow colors from teal/pink to green/black
• 
  
• Created a schnifty new BAMWconfig.exe program that can be used to set not only the shadow color when exporting to .gif (depreciating SetExportCol.exe) but also the quick color selectors used for the transparent and shadow colors.  [Run "BAMWconfig.exe -about" from the command line to view legal and copyright info]
• 
  

If anyone finds that the teal/pink colors are still cropping up somewhere, tell me about it so I can address it.

Looks good. I don't know how significant this is, but the last color is also getting set to transparent green, whereas in the actual BAM, it's a unique color. I think having duplicate transparent/shadow colors in the palette sometimes causes issues (and that last entry could be getting used in the BAM as well).

[Sam.]

Looks good. I don't know how significant this is, but the last color is also getting set to transparent green, whereas in the actual BAM, it's a unique color. I think having duplicate transparent/shadow colors in the palette sometimes causes issues (and that last entry could be getting used in the BAM as well).

Was this original behavior or is it new since my last edit? Can you send me the test BAMs before and after this happens?

[Miloch]

Was this original behavior or is it new since my last edit? Can you send me the test BAMs before and after this happens?

It does happen with the previous version too, apparently. I was just looking at mskade.bam from vanilla BG2, and comparing the exported BAM's palette in BAM Workshop with the original palette via DLTCEP. Not sure why it hoses that last palette entry for that BAM but not others even of the same or similar palette; for example, mskatw.bam has the proper last palette entry (RGB 8,8,0).

[Sam.]

Was this original behavior or is it new since my last edit? Can you send me the test BAMs before and after this happens?

It does happen with the previous version too, apparently. I was just looking at mskade.bam from vanilla BG2, and comparing the exported BAM's palette in BAM Workshop with the original palette via DLTCEP. Not sure why it hoses that last palette entry for that BAM but not others even of the same or similar palette; for example, mskatw.bam has the proper last palette entry (RGB 8,8,0).

I think I have figured out what is going on. Upon loading a BAM, BAMWorkshop sets all of the palette entries AFTER the last palette entry that is actually used in the BAM file to the same color as the first palette entry (or perhaps the transparent color, I haven't actually tested a BAM where the trans color was not the 1st entry). In other words, BAMWorkshop sets all of the unused palette entries at the end of the palette to "blank" (so to speak) values. This is true for all versions of BAMWorkshop going back to the original v1.1.0.7 release. This can, theoretically, be construed as a feature since it provides an obvious visual indication to the user of available palette entries (albeit a potentially incomplete list*) that can be set with custom colors (for use in manually editing frames).

*Only unused palette entries at the end of the palette are changed, not unused entries that fall before the last used entry.

[Miloch]

Ok, thanks for investigating, Sam. Like I said, I didn't know if it was significant... I've never noticed any obvious issues with it.

 

On the other hand, there is an issue with BAM Workshop I've always found supremely annoying. Every once in a while, it hits a BAM for which it can't seem to read the frame data. It'll just display blank green frames instead. Even if you go to "manage frames" they're all blank. An example from vanilla BG2 is spfearef.bam. It's a face coming out of the ground (fear effect) if you look at it in DLTCEP but dead blank in BAM Workshop. Offhand, I don't see anything odd about the BAM, except it has a duplicated shadow palette entry (0,0,0 at 1 and 3 in the palette). But I don't think that's too unusual, since spfdeath3.bam does too and displays fine in BAM Workshop.

[Sam.]

On the other hand, there is an issue with BAM Workshop I've always found supremely annoying. Every once in a while, it hits a BAM for which it can't seem to read the frame data. It'll just display blank green frames instead. Even if you go to "manage frames" they're all blank. An example from vanilla BG2 is spfearef.bam. It's a face coming out of the ground (fear effect) if you look at it in DLTCEP but dead blank in BAM Workshop. Offhand, I don't see anything odd about the BAM, except it has a duplicated shadow palette entry (0,0,0 at 1 and 3 in the palette). But I don't think that's too unusual, since spfdeath3.bam does too and displays fine in BAM Workshop.

This issue is essentially the same as the one being caused by the original version of BAM Resizer (where the rows of pixels were rendered misaligned). The problem occurs when a frame is Run-Length-Encoded and it has long "runs" of transparent pixels (>254 or 0xFE) which are broken up into runs of 255 or 0xFF pixels. Here is what I believe is wrong with the code:

From the BAM File Format page of the IESDP:

If this is a compressed frame, the data is compressed with a run-length-encoding scheme. The scheme is as follows:

• Any byte which is not the transparent index from the header represents itself
• The transparent index followed by a byte x represents (x+1) copies of the transparent index

When BAMWorkshop reads the RLE frame data, it defines the data type used to store "byte x" as an unsigned char (aka unsigned __int8 or UChar) which has a set range of 0 to 255. When x is set in the BAM as 255 (0xFF), BAMWorkshop tries to add 1 to it to get the total number of copies of the transparent index to render, but since the data type is limited to an unsigned char with a max value of 255, the number rolls around to 0. With the sourcecode, this shouldn't be that bad of a fix, but sadly machine optimized bytecode really just looks like devil's magic to me...   Hope that explanation was understandable...

As a workaround, you can load the BAM in DLTCEP, un-RLE then re-RLE all of the frames by going to Tools->Uncompress all then Tools->Compress all, and then resave the file. Alternatively, batch processing all of the BAMs you are going to want to work with with the latest version of BAM Resizer (with the resizing set to 100%) should ensure all of the BAMs can be properly loaded in BAMWorkshop.

[Echon]

Thanks for the update to BW. I guess I should check this subforum more often.

[Sam.]

Thanks for the update to BW. I guess I should check this subforum more often.

Or "Follow this topic" and let the forum software do the checking for you .

[Echon]

Or even better, follow the download file. I had not noticed that.