I have done some more debugging and found the following:
The sprite for 210_4-0 is 15x21 pixels when exported from Daggerfall Imaging and so is Ralzar's replacement image 540_4-0.
I dumped the size and scale values for both images as DFU loads them in and there's something funky going on in the scale department that I can not explain:
Code: Select all
Image: 540_4-0:
Archive - record : 540_4-0 | GetBillboardMesh size: (15.0000, 21.0000)
Archive - record : 540_4-0 | GetBillboardMesh scale: (1.0000, 1.0000)
Sprite size: (0.3750, 0.5250)
----------------------------------------------------------------------------------------------------------
Image: 210_4-0
Archive - record : 210_4-0 | GetBillboardMesh size: (15.0000, 21.0000)
Archive - record : 210_4-0 | GetBillboardMesh scale: (-128.0000, -128.0000)
Sprite size: (0.2000, 0.2750)
Image 540_4-0 gets loaded through TextureReplacement.GetStaticBillboardMaterial and returns with that sprite size which is correct, 15 * 0.025 = 0.375 and 21 * 0.025 = 0.525
Image 210_4-0 gets loaded through MaterialReader.GetMaterialAtlas and for some reason, it's scale is returned as (-128.0, -128.0).
The code below calculates what I show as Sprite size:
Code: Select all
// Apply scale
Vector2 finalSize;
int xChange = (int)(size.x * (scale.x / BlocksFile.ScaleDivisor));
int yChange = (int)(size.y * (scale.y / BlocksFile.ScaleDivisor));
finalSize.x = (size.x + xChange);
finalSize.y = (size.y + yChange);
With the scale being 1, xChange and yChange end up as 0 because the fraction is just really tiny.
But, naturally, with the scale being -128, you end up substracting half the width and half the height, shrinking the sprite down. Is this intended behaviour?
================================================================
So, I did one more test by hardcoding xChange and yChange to 0 for record 4 of archive 210 and 540. The candle behaves like it should, it doesn't grow or shrink, just gets extinguished and relit.