Jump to content


Sam.

Member Since 10 Jun 2008
Offline Last Active Yesterday, 07:08 PM

Posts I've Made

In Topic: [RELEASE] BAM Batcher

18 May 2019 - 06:34 PM

Regarding the "Convert inventory BAMs to EE" component - if I understand correctly icons converted to EE style are not supported by the old engine. If that is the case then I'd like to request an option to completely remove unused small icon and cycle to make the file smaller and due to wrong icon showing up in Near Infinity with the current code. I can't think about any benefits at all in keeping the unused data.

This component adds the small frame as a second frame to the sequence that has the large frame.  The result is the classic Infinity Engine style of item icons that display the small frame when the item is in the inventory and the large frame when you pick it up.  My tests show this is true (identical behavior with the modified BAM) in vanilla (tested in ToB) and EE games.  If you are experiencing different behavior, please provide me a specific example I can use to reproduce.  Furthermore, IIRC this code does not add a single byte to the the pre-Zlib compressed BAM (Zlib compliant compression is context specific, so it's theoretically possible the modified BAM doesn't compress quite as well, but I doubt the difference could be more than a byte or so).  If you want to perform this modification using PS BAM, you can achieve even better compression and the filesize will shrink compared to the original.

 

Since the modified BAM works as intended in both the vanilla and EE games, and since the modified file is no larger than the unmodified version, I see no reason to depreciate or modify this component.  If you want to keep the EE style item icons (only the large frame is displayed), then you can certainly drop the small frame.  If there is an interest in this capability, I can add the functionality to PS BAM.

 

Note that "Convert inventory BAMs to EE" does NOT convert to BAM V2 files (which is not backwards compatible with vanilla games).


In Topic: PS BAM

07 May 2019 - 06:01 PM

I have committed some updates to PS BAM on GitHub.  Updates include:

  • Improved exception handling
  • Some code modernization
  • A couple significant speed improvements
  • A minor bugfix
  • The ability to read BAM V2 files (only with the x64 EXE)

Note that due largely to the fact that PS BAM is written in AHK (which is an interpreted language), reading BAM V2 files from their PVRZs isn't particularly fast.  If the BAMs only have a handful of frames (as AFAIK all existing BAM V2 files do), it won't be an issue.  If you try reading a BAM V2 that has multiple thousands of frames, it works but will take a long time (from hours to overnight).  Writing to BAM V2 files is not supported at this time.

 

Let me know if you have any questions or issues.  Feature suggestions are welcome.


In Topic: Cosmetic bugs of the DSotSC (icon BAMs)

03 May 2019 - 12:41 PM

Sorry for the delayed response.  I've been busy and replying to this kept getting bumped down the queue.

 

@Sam.

It did help with the icon size and offset. Now scroll is resized and positioned well. But second problem is still left: spell scrolls are displayed as generic scrolls. Problem is that those BAMs from DSotSC contain two DIFFERENT frames. frame 0 contains classic icon and frame 1 contains image of the generic scroll (which offset was wrong and now it is fixed). My classic game uses second frame as icon. First frame containing correct icon is ignored and all DSotSC spell scrolls have visually identical view of generic scrolls and are different by the name only.

 

Anyway, thank you, Sam. Your solution can fix glitched view of the bunch of icons, not only spells. 'Generic' view of spell scrolls is just a minor issue.

Maybe the frames are assigned to the wrong sequences?  If you're feeling a bit more ambitious, you can try switching them yourself.

 

"PS BAM.exe" --CompressionProfile Recommended --AdvancedFLTCompression 0 --AdvancedZlibCompress 0 --IntelligentRLE 0 --Compress 1 --OrderOfOperations PCE --LogFile "PS BAM Log.txt" --OutPath "C:\Path\To\Save\BAMDs" --Save BAMD *.bam

Then in the BAMD files, switch which frames are assigned to each sequence and then recompile them to BAMs via something like:

"PS BAM.exe" --ItemIcon2EE 1 --CompressionProfile Recommended --Compress 1 --OrderOfOperations PCE --LogFile "PS BAM Log.txt" --OutPath "C:\Path\To\Save\BAMs" --Save BAM "C:\Path\To\Save\BAMDs\*.bamd"

Alternatively, you could extract the frames as sequences of images using:

"PS BAM.exe" --CompressionProfile Recommended --AdvancedFLTCompression 0 --AdvancedZlibCompress 0 --IntelligentRLE 0 --Compress 1 --ExportFramesAsSequences 1 --ExportFrames "BMP,32V5" --OrderOfOperations PCE --LogFile "PS BAM Log.txt" --OutPath "C:\Path\To\Save" --Save "" *.bam

Then rename them (essentially swapping Sequence_0000 with Sequence_0001 and vice versa).  Then recompile them to BAMs with something like

"PS BAM.exe" --ItemIcon2EE 1 --CompressionProfile Recommended --Compress 1 --OrderOfOperations PCE --LogFile "PS BAM Log.txt" --OutPath "C:\Path\To\Save\BAMs" --Save BAM "C:\Path\To\Save\*_Sequence_0000_Frame_0000.bmp"

Note that I strung these together from memory and haven't actually tested them, and you will need to adjust the paths to whatever is appropriate for you.


In Topic: PS gui v3.04

28 April 2019 - 01:36 PM

I'm trying to convert a series of JPG files into an AVI, and then convert the AVI into an MVE for use in IWD2.  I used VirtualDub to create the AVI, which I can successfully play using Windows Media Player.  But when I then run PS GUI to convert it to MVE, I get this in pass 1

 

Exception EAccessViolation in module avi2mve.exe at 00002615.

Access violation at address 00402615 in module 'avi2mve.exe'. Write of address 010733D4.

 

I can only assume that VirtualDub created an AVI format that PS GUI doesn't like.  Any idea what settings I should use in VirtualDub that will produce a supported AVI format?  Thanks!

 

- TB

 

UPDATE: never mind.  Turns out BINKing the AVI with the RAD Video Tools did the trick.

I am unfamiliar with the internals of avi2mve; PS GUI is just a wrapper for the command-line program.  FWIW, I think the safest bet is to use a fully uncompressed AVI.


In Topic: Cosmetic bugs of the DSotSC (icon BAMs)

14 April 2019 - 04:09 PM

Great!
@Sam. , Will it detect correct icon frame by selecting ItemIcon BAM profile or it is required to tell it somehow which frame to drop and which to leave?
If not, how can we tell this tool to:
a) Drop frame which size is larger than 32x32 if we have anoter? I.e. to drop frame for EE and leave another frame containing icon for classic game?
b) Resize all frames to 32x32 size

Assuming the Item Icon was formatted properly for non-EE games,

"PS BAM.exe" --ItemIcon2EE 1 --CompressionProfile "Recommended" --LogFile "PS BAM Log.txt" *.bam

should do the trick. If it doesn't, send me the log file and the BAMs, and I'll figure out which of the other settings need to be tweaked.

 

FYI, the item icon BAMs in the original game had the larger frame in Sequence 0 and the smaller frame in Sequence 1.  To work the same way in the recent EEs, the smaller frame in Sequence 1 needs to be added as the 2nd frame in Sequence 0.  This is what PS BAM and BAM Batcher both do.