28 replies to this topic

[jastey]

Fixpack just adds a file called MDOG_MO.bmp and that's it. That is why I am confused, because I don't understand how this fixes the pixelated animation. In the fixpack folder it is in the folder named "copy", in case you want to have a look at it.

 

The fixpack palette is nice indeed, but I would prefer having an animation that is different to the DOG_MOON one, if I have the possibility, to avoid confusion.

[Sam.]

Fixpack just adds a file called MDOG_MO.bmp and that's it. That is why I am confused, because I don't understand how this fixes the pixelated animation. In the fixpack folder it is in the folder named "copy", in case you want to have a look at it.

I'll try to offer an explanation without getting overly technical . The IE more-or-less uses 8-bit (256 color) paletted bitmaps in the Microsoft Windows 3.x format. In this format, the actual color data (red, green, and blue values that make up each color used) is stored in a "color palette" towards the beginning of the file, The actual pixel data in the bitmap file is merely an index into the color palette that specifies which color that particular pixel of the image should be. Now, the BAM file format (the file format of the animations in the IE games) behaves in a similar way. There are multiple "Frames" (images) in the BAM file, but they all use the color palette towards the beginning of the file. The data for each frame of the animation consists only of indices into the color palette which determine which color should be used for that pixel. The base animation (BAM files themselves) for the dog animation uses a color palette made up of colors that are shades of brown. What the MDOG_MO.bmp file does is OVERWRITE the brown palette in the BAM files of the base animation (MDOG) with a palette that is grey/black, thus the dog is colored grey/black. The problem with the original moon dog animation is caused by the MDOG_MO.bmp file itself, as it is what defines the moon dog animation's color. The problem is that when the original color palette in the MDOG BAM files is overwritten by the MDOG_MO one, the pixel data in the BAM files are still the same indices into the color palette, but the colors in the palette at those indices are no longer appropriate for that pixel. Thus, the colors of the moon dog animation looked scrambled, giving it the discolored/pixelated look. What the fixpack did was essentially rearrange the colors in the palette that is the MDOG_MO.bmp file so that the indices into the palette from the BAM files would be pointing at colors that are appropriate for pixel locations in the image.

I may not have worded that so well, but maybe you get the gist? lol

[Gwendolyne]

Thanks a lot, Sam !

 

I have written 10 tutorials for creating animation bam files.... but unfortunately in French....

 

And your post will save me time to translate the first one for jastey !

 

In fact, I used this tip to convert Arcanum animations : most of them are released in four versions (4 colors). "All" I had to do is convert one single animation - the white and black cow for exemple -, then apply the 3 others palettes to get a white and brown, a black and a brown cow !

[jastey]

That makes it clear, Sam.! Thank you very much for the explanation. It's so logical I am surprised it didn't occur to me before.

Thank you again for all your efforts!

[Tash]

I'm also rather new to BG animation format, but I don't want to start yet another topic here. So, here's a couple of questions:

 

1. Are the animation slots in ANISND.ids fixed to monster types? For example, does the game executable read slot 0x7E and see it as BG1 Simple Monster (i.e 0x7E = always and only BG1 type)? And even if I overwrite the animation files linked to this slot with, say, a BG2 animation, it won't be properly recognized as BG2 Monster type and will crash, correct?

 

2. Which file (if any is available as externalized) governs base animation speed (the speed at which creatures move/the number of points it moves forward as frames are played)? In other words, what determines that a Greater Werewolf moves slower than a Werewolf in-game, even though they have the same movement speed stat? I'd suppose this is hardcoded, as I can't find any info about it anywhere. Also, compare Wolf and Werewolf speed. Both are BG1 creatures, same base movement, but different in-game speed.

 

3. How do I know which animation sequence number does what? Say, I have all the frames for my animation ready, but I have no idea how to put them into sequences so that the game recognizes sequence x as attack, sequence y as dying etc. Is there a reference chart for these numbers? Are these hardcoded into specific animation slots? The tutorials available at Black Wyrm etc. are nice but none of them actually explain how to arrange frames and set up these sequences into proper numbers for the game to read.

 

Basically, what I want to do is fix the Werewolf animations. Currently what happens is that when Werewolf walks N, S, W, or E, it moves at similar pace to BG2 avatars. But when it walks in diagonal direction (SE, NE, NW, SW), it moves at double speed. Dunno how this is even possible... There must be a file (IDS? 2DA? Hardcoded?) that reads seperate animation sequences and tells the creature to move at this or that speed. I can't find anything related at IESDP. I also want to speed up the stand/idle animations as they play at half the speed and appear jerky. Funnily enough, for the second before you finish polymorphing the animation sequence plays at normal speed (as previewed in bam editor), then it slows down to a half. Which file governs that?

 

How do I know slot 0x7E is rigged? Well, extract Wolf bams and rename them to Werewolf scheme, put in override, and now Wolf animation suffers from the same issues. Normally, Wolf animation in its own slot moves at standard BG1 pace in all directions. If I rename Werewolf bams to Wolf ones, boom, issues gone. It moves super slow now, just like BG1 Wolfie, but at least at the same speed in all directions.

 

Even though I'm not sure if I want to do it, it would be nice to know how to set the base speed of Werewolves and Greater Werewolves to the same value through animation files. I know you can use opcodes, but if they have the same movement base stat, their animations should be fixed to move at the same speed.

 

Edit: Ah, BGEE has all of these externalized: EXTSPEED.2da. Unfortunately, TobEx doesn't have this feature as of yet.

 

Edit2: To those who care, I just tried BGEE on my PC and I'm disappointed. Not only does it look blurry and zoomed-out as hell at 800x600 (looks worse than the original), it introduces some new bugs and it doesn't fix those animation slots. Werewolves still appear to be glitched in the same way... You can move them to a new animation slot, set your own movement speed and it might work fine, though.

Edited by Tash, 01 July 2014 - 06:26 PM.

[Tash]

Well, all right. I've just learnt most of it the hard way, but I guess that's the only way, then . Working with BAMs is a pain.

 

Anyways, I found out that the only way to fix all of these issues is to convert Werewolf to BG2 split + mirrored format. Yeah, the shadows are gonna be wrong, but that's how all of these BG2 creatures look like, anyway. I'm currently testing the new animations and they work great. So, I guess expect a Werewolf fix soon. Probably gonna need Infinity Animations for that, but we'll see.

 

If only these BAM Workshops didn't randomly corrupt all the work...

[Argent77]

If only these BAM Workshops didn't randomly corrupt all the work...

You could try your luck with DLTCEP's BAM editor or the new BAM converter included in the latest snapshots of NearInfinity instead.

[Tash]

Yeah, you're right; I actually gotta use 4 programs to create BAMs. I can't even install BAM Workshop I, as it probably requires some ancient framework package, and I'm not getting these onto my system. So, currently, I use WinBiff for rapid file extraction, BAM WS II for palette and frame extraction, GIMP for edting and converting to indexed, BAM WS II again for importing edited frames in unpaletted mode (here's where some pixels get wrong, you fix them, then you have to convert back to paletted, and you gotta fix it all manually again), and, last but not least, DLTCEP for sequence setup, last-minute palette fixes and check-up.

 

Now, I tested some animation work, and it turns out that any BG1 animation type will glitch at movement speed above 9 (max in BG1); it will go faster when walking sideways, slower in standard directions, and sometimes it's the other way round. At speed set to 9 it's all fine and dandy. Problems appear when you wear boots or cast haste, though. I tried manually converting the Werewolf to BG2 type, and it worked somewhat OK (manually adjusted shadows), but not as smooth as I wanted. Oh well.

Edited by Tash, 05 July 2014 - 11:28 PM.

[Miloch]

1. Correct
2. Hardcoded (but yes, externalized in EE)
3. Try the reference picker program included with Infinity Animations (the reference chart)

If you want a faster werewolf, you'll want to drop frames from the relevant animation sequences. As you say, this is particularly noticeable for the standing/stance sequences, which are padded with so many extra duplicate frames that you can practically taste the were-choppiness (I have in fact fixed this). However, the walking animation has only 10 frames, so I think it might be reverse-choppy if you dropped some. It might be possible some fix for that (i.e. variable walking speeds) could be externalized, and I remember it being discussed at some point, but I don't know if there were any firm ideas or conclusions.