Vanillaware Ripping Project

[tombmonkey]

I geniunely don't understand why you are ripping Muramasa/Odin's Sphere without anti-aliasing, the antialiasing seems to be in the textures themselves and not added by the console's texture filtering.

It is additive blending, it's not for consoles with no alpha support, it's to achieve lighting effects.

What you have output is good, the images with black background are not meant to blend ONLY with the sprite, they are meant to blend with both the sprite and the background/other sprites to create lighting effects.

I will try to explain how it's used but hang with me I'm not good at explaining stuff.



This is the same image in normal blending mode with alpha map and in additive blending mode.

You can see how in normal mode it looks kind of dull, while in additive blending it "adds" the colors to what it's overlaying to produce more vivid colors, this is why merging with the sprite wouldn't work.


The effect becomes more apparent when you start overlaying several images in additive mode:



This is how Adobe's manual explains "Screen blending mode", which is, I think, pretty similar to additive blending modes used in most games.

Screen

Looks at each channel’s color information and multiplies the inverse of the blend and base colors. The result color is always a lighter color. Screening with black leaves the color unchanged. Screening with white produces white. The effect is similar to projecting multiple photographic slides on top of each other.

For the little ghost, I fear the game is coloring the additive black and white image via code, I went to look at it ingame and the glow is in fact colored, so the tinting must have been added via code, as you said it's hard to judge if stuff is right given Wii's default anti aliasing, but to me it looks like only the glow with black background is in additive mode in game while the rest is in normal blending mode.

The reason some are colored and others are black and white are probably merely optimization, an explosion/fire has too much color variation and detail to make it grayscale and just give it an uniform tint later via code, but a simple glow can just be saved as grayscale and tint later in engine.




Here's my wild guess of how the ghost sprite is rendered in engine, it probably maps a gradient map (or a simple tint) to the black and white sprite, then draws it in additive mode, then draws the rest of the sprite in normal blending mode going from the ordering in your assembled sprite. As you can see it gives it a glow effect like in the game.

Finally, a highly specialized 2D developer like Vanillaware likely has their own blending modes that are different that what can be achieved with standard use graphics programs layer blending modes.

If push comes to shove, I say that if you can identify the images that go in additive blending then just leave them out,

The nuclear option would be to edit the textures themselves before running the assembly script, cutting off the additive pieces out of one, and filling with black the normal blended images in the other, the first one should produce a pristine sprite, the blended one would have problems if it uses more than one image in additive blending at once.





Don't know if you can tell what pieces are meant to be used in additive mode from the code, if you can't and it comes to having to clear the additive pieces from the textures I can give you a hand to alleviate the workload.

Disclaimer: For me the ideal for these would be taking the animation files and atlas files and converting them into something Spine could import then render them using Spine itself ( or ask to have spine-ts added to the site so the animations could be seen in their intended method  )