The VG Resource

Happy New Year 2021! How are you guys? Made any new year resolution yet?

In this year, I want to completely rip sprites from Vanillaware. So far, the list is

Progress : on-hold, palette problem
- [Saturn] Princess Crown
- [PSP] Princess Crown
- [PS4] Princess Crown

Progress : up to WebGL, tessellation/blending/animation problem
- [PS2] Odin Sphere
- [PS2] GrimGrimoire
- [NDS] Kumatanchi
- [Wii] Muramasa The Demon Blade
- [PSP] Grand Knights History
- [VITA] Muramasa Rebirth + DLC
- [VITA] Dragon Crown
- [VITA] Odin Sphere Leifthrasir
- [PS3] Dragon Crown
- [PS3] Odin Sphere Leifthrasir
- [PS4] Odin Sphere Leifthrasir
- [PS4] Dragon Crown Pro
- [PS4] 13 Sentinels: Aegies Rim
- [SWITCH] 13 Sentinels: Aegies Rim
- [SWITCH] GrimGrimoire OnceMore
- [SWITCH] Unicorn Overlord

UPDATE : Step-by-step ripping tutorial
https://www.vg-resource.com/thread-38430...#pid668969
https://github.com/rufaswan/Web2D_Games/...steps.adoc

Let's talk about the sprites in these games, and also a bit about quad-rendering.

Quad-rendering - as in rendering a rectangle, is where the game data gives you only the 4 coordinates, and expect you to flip/scale/rotate the sprite parts accordingly, like this:

[attachment=11428]

Just like rotation, it is a lossy process. It creates jagged lines when reassembled.

As noted by Dazz, some console (like Wii) has anti-aliasing. The final sprite is slightly blurred to appear smoother on screen.

All my sprites are ripped without anti-aliasing.

Ripping sprite like this also reveal some "effect" sprites you couldn't get by assembling by hand using VRAM.

This is when Gradriel falling down. Notice her sprites was "squeezed" during landing.

[attachment=11427]

There are a lot more of these kind of sprites, especially on opening/ending related. It is like getting movie frames.

---

Let's talk about the current progress.

Princess Crown

The sprites are able to reassemble correctly, but the big problem is with its palette.

[attachment=11429]

There are 5 books on the floor, and the book's palette is determined by which book you give her. It's pretty much about digging data from the assembly code now.

And yabause is acting up on me. It refuse to break on memory address or on instruction. The weird part is it works before. I doesn't understand why it refuse to work now...

Muramasa The Demon Blade

If Princess Crown has palette problems, then Muramasa is blending problems.

[attachment=11430]

From my previous note on Legend of Mana thread, that black part is a mask for semi-transparency. On PlayStation, it is by additive blending.

But now I also have white color masks used for shadow!

Some sprites, like save portal, is in grayscale. How does that become blue in-game?

Like Pricess Crown, the emulator is not helping either. The screenshots I get from Dolphin is anti-aliased. I can't examine the image pixel-by-pixel to figure out the blending formula.

For comparison, this is the screenshot and the sprite.

[attachment=11431] [attachment=11432]

Is there a way to get a raw, unscaled and unfiltered screenshot?

Odin Sphere + GrimGrimoire

Both game uses the same file format, so I'll group them together.

The data format is very similar to Muramasa. I can guess where everything is pretty easily.

BUT the image/texture data is arranged in a very weird way. It is so weird I'm having problem in decoding them.

It is pretty amazing Raccoon Sam can decode these kind of data merely by just closely examine them.

In the end, there are still more work need to be done, more stuff need to be learned. 2021 will be a pretty busy year.

I'll post updates here when I made any progress. Until then, take care!
- Rufas

I was impressed with what you had so far on discord. I hope that you can fix Momohime's... little flub in the sheet. XD

It's time for another update! How are you guys doing?

I finally understand why PS2 image/texture is arranged in such a weird way - texture swizzling.

https://ps2linux.no-ip.info/playstation2...ezswizzle/
https://ps2linux.no-ip.info/playstation2...l?docid=75

In short, swizzling is about optimizing for GPU. Pixel data can be sent over multiple bus at the same time, thus achieve performance gain.

But swizzling is not compression. The pixel data are just switch around. They do not overwrite each other. THIS IS IMPORTANT!

For 4-bit images, the pixels are swizzled twice - first as pixels, then as blocks of 64 bytes. No wonder I couldn't understand them by simply closely examine them. It is way above my skill level.

Unfortunately, the code above isn't perfect either. For 8-bit images, it works nicely. But for 4-bit images, any image 128x128 or larger is having problem. 1/4 of the pixels end up overwriting each other.

And I think the code works only on square images. Portrait and landscape images have everything unswizzled at the wrong place. That requires debugging.

Since I can unswizzle 8-bit images correctly, I can start reassemble them.

On this update, I give you Gwendlyn (WIP) from Odin Sphere.



Like Muramasa, the sprites also has mask/alpha blending problem.

Let's see if I can solve all the problems by next week. Until then, take care!
- Rufas

Pretty sure PSP Princess Crown is just the Saturn game running on an emulator.

(01-09-2021, 09:41 PM)Magma Dragoon Wrote: [ -> ]Pretty sure PSP Princess Crown is just the Saturn game running on an emulator.

It is like Castlevania SOTN port to PSP / XBox Live actually. A lot of the assets from Saturn were reused, and the music *.pcm file is converted to PSP's *.at3 sound format.

Then they add borders around the screen to preserve the game aspect ratio:

[attachment=11466]

They also do some minor update by adding title card on entering a new area:

[attachment=11467]

They also added a bonus Gallery mode

[attachment=11468]

There are some new stuff in there, they doesn't just put Saturn ISO file in there and call it a day.

- Rufas

Got it solved! 4-bpp texture is multi-level swizzling. It also didn't help most of these images are in grayscale.

Instead of using a math formula to do everything, I decided to waste some memory and CPU power to unswizzle them by logic. Now, not only I can get 4-bpp at any size to unswizzle correctly, I also figured out how to handle landscape and portrait textures as well!

In short, for landscape texture 512x256 , you pad it to become a square 512x512 , and then unswizzle normally:

[attachment=11483]

For portrait texture 256x512 , you split them into two square 256x256 and unswizzle them independently. You join them back after that.

[attachment=11484]

I have everything on both GrimGrimoire and Odin Sphere on PS2 now. I can work on those too.

Until next update, take care!
- Rufas

Impressive work as usual.

If I where to give a bit of feedback, you should just export the stuff that uses an additive blending mode to it's own sprites, because there's no way to rebuild that on a single image.

Imo the best option if someone wanted to reconstruct the sprites would be to have 2 separate sprites, where in the sprite that is in additive mode you draw the pieces that have normal blending black, so that they can obscure the additive parts if they go behind the character.




If that's not possible, then I would prefer the sprites without the additive blending effects since those could still be added.

I'm considering the idea of making 2 separate sprites, but having problems doing so. in fact, looking at the parts texture, it already has half-transparency, so why do it needs additive blending anyway?

Additive blending is for console without alpha channel support, like PlayStation One. But both Wii and PS2 has alpha channel support. Why does additive blending still exists?

[attachment=11519]

Since normal half-transparent are blend normally, parts with additive blending will need to be separated into its own sprite.

But then, you'll noticed a problem - parts ordering. Not all masks are assemble last. So you'll get something like this:

[attachment=11520]

Even if I used the same formula in Legend of Mana to turn the mask into half-transparent pixel, it is still in white light. Compare it to the in-game screenshot, it should be in blue-ish hue.

https://gamefaqs.gamespot.com/wii/943228...images/255

My theory is it is may not be addictive blending, but something else. The mask to be blend with a color first before blend normally to the sprite.

But where does this blue color come from? I don't know.

It also doesn't help some masks is already in color and doesn't need to be blend with a color first.

[attachment=11521]

And then there are some weird parts. From the shape of it, it seems like a slash effect. Where does the color comes from? What have I missed?

[attachment=11523]

It's rather a mess here. I'll need some time to understand how everything works.

- Rufas

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.

Quote: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  )

It's nice to have more discussion on modern 2D sprites. It's can be pretty hard to find topics related to alpha-blending, gradient map, anti-aliasing kind of stuff. It's always good to have the knowledge of these thing available here.

---

Let's start with the first one. The texture/parts images for Odin Sphere/Muramasa are all palette image. PS2 Odin Sphere are 256 RGBA color 8-bpp texture with texture swizzling, and Wii Muramasa are 256 RGB5A3 color 8-bpp texture.

It is not until their remake on VITA that they change them to DXT 3/5 video codec, a lossy compression algorithm.
https://en.wikipedia.org/wiki/S3_Texture_Compression

Also, anti-alias is a filter. In GIMP, it uses "Scale3X edge-extrapolation algorithm". I suppose you can use any other algorithm to anti-alias as well, like 2xEagle, 2xSal, HQ2X, Bilinear, etc. Anti-alias also has level and threshold settings to consider.

https://docs.gimp.org/2.6/en/plug-in-antialias.html

If I can, I would prefer to assemble the sprites in raw pixel, and then let the users to use whatever anti-alias filter they want. They can also use the HD filter you shown me on your Legend of Mana project.

---

About additive blending, the math formula is just FG.rgb + BG.rgb . It doesn't use alpha channel, and therefore addictive blending affects the whole image (or the whole part).

The math formula for normal blending however, is (FG.rgb * FG.A) + (BG.rgb * (1.0-FG.a)) . The blending is in pixel level. If FG.a is 1.0 , then BG.rgb will become zero, and you'll get FG.rgb as the result.

Let's have an example: if FG is rgb(80,40,8) and BG is rgb(120,64,72)

Additive blending is
r = 80 + 120 = 200
g = 40 + 64 = 104
b = 8 + 72 = 80
the result is rgb(200,104,80)

But for normal blending, it will become
FG.a = 80 / 255 = 0.31
r = (255 * 0.31) + (120 * (1.0-0.31)) = 79 + 82 = 161
g = (127 * 0.31) + (64 * (1.0-0.31)) = 39 + 44 = 83
b = (25 * 0.31) + (72 * (1.0-0.31)) = 7 + 49 = 56
the result is rgb(161,83,56)

The result for normal blending is darker than the result of additive blending, because the (1.0-FG.a) part.

Did you noticed? If the BG is all zero, then you'll getting the mask back. The formula is revertible.

The formula I used to convert rgb(80,40,8) into rgba(255,127,25,80) is like this:
highest = 80
r = 80 / 80 * 255 = 255
g = 40 / 80 * 255 = 127
b = 8 / 80 * 255 = 25

You'll need to use a custom blending mode if you want to use my Legend of Mana rips. Just blend the half-transparent pixel with black pixel to get the mask back, then add it to the background pixel, and clamp it to max value 255.

---

On blending the mask with color via code, it is no surprise since they also do it with the fonts texture. What annoys me the most is the data didn't marked the part requires a color too. And also I can't find that blue color anywhere.

I do agree effects sprites are normally like this, and ofter just unrippable.

I already found the byte on blending. It has 3 values:
0 = normal blend
1 = additive blend
2 = ???

The weird part is on different value. It is int_16 , and has
Odin Sphere = 25 types (0 1 2 3 4 5 6 7 9 b d f 10 11 13 15 19 21 28 29 2d 2f 31 35 39)
Muramasa = 13 types (0 1 2 3 4 5 7 9 11 13 15 29 2d)

There are tons of testing need to be done.

---

Interestingly, when I was just starting out, I assembled my sprites in HTML, using CSS spritesheet. It would be very interesting to see it in WebGL + Three.js . Heck, even my Castlavania NDS maps are in HTML.

https://www.vg-resource.com/thread-31643.html
https://www.vg-resource.com/thread-37086...#pid660862

Take care,
- Rufas

Message me on discord (tombmonkey#9816) if you want to talk more about modern sprites, I have worked with skeletal animation for nearly a decade by now, and Vanillaware games were what got me interested in it originally.

I looked at the game for a while and I didn't spot anything that could be using a third blending mode, but if I had to guess what that third byte blending mode is from own experience, it's probably subtractive blending (for shadows instead of lights). If you see the flag on on anything post it and I can take a look and see if I can tell what it's doing.

The data for coloring the black and white images probably is, again talking from own experience, somewhere in each character's controller code, not on the animation information, the color range could even be hardcoded instead of using a palette file. Often when drawing these kind of sprites you can add interrupts via code to achieve special effects or modifications beyond what's in the animation data, a common example would be intercepting the rotation of an image and changing it on the fly so a character can look (or aim a gun) towards an specific point (in the spine examples I linked above you can see several ways you can tweak stuff in real time, these changes wouldn't be in the animation data).

And yes if you want to assemble the sprites as faithfully as possible while preserving the special effects it would have to be done in a non destructive way that supports blending modes, like html.

Messing around PCSX2 settings, it is amazing the graphic plugin have more settings than Dolphin emulator's one.

[attachment=11552] [attachment=11553]

Disabled Interlacing, turn off shaders, texture filtering, anti-aliasing, and force disable everything on advance, now the in-game screenshot looks like this:

[attachment=11554]

And with that, I can test around by examine the pixel value directly! Here are all the relevant assets to rebuild the screenshot:

https://www.mediafire.com/file/xhjrtj5ug...2.zip/file
NOTE : xxxx.0.png are blend 0, xxxx.1.png are blend 1, xxxx.2.png are blend 2.

For my calculation, the result for 3 blending type seems to be:
0 = normal blending
1 = additive blending @ 1/4
2 = additive blending

Looking at the screenshot again, I realized the pixelation is too much. The picture may end up too blurred when a filter is applied. In the spirit of 100% faithful rip, I'll be switching over to HTML, using WebGL + Three.js .

Time for another set documentations. Might take some time for another update.
- Rufas

Have you ripped anything? I'm not trying to sound demanding. I'm just excited.

Finally ripped some stuff out of VITA games. Comparing it to its PS2/WII version, the texture is at lower quality and has some unwanted artifacts in them. This is because they used DXT video codec to compress their textures, so the result is like convert JPEG to PNG.

Here are some comparison:

- Momohime (WII Muramasa)
[attachment=11603]

- Momohime (VITA Muramasa Rebirth)
[attachment=11604]

- Gwendlyn (PS2 Odin Sphere)
[attachment=11605]

- Gwendlyn (VITA Odin Sphere Leifthrasir)
[attachment=11606]

As a bonus, Okoi Mike from Muramasa Rebirth DLC:
[attachment=11607]

Sorceress from Dragon's Crown
https://i.imgur.com/fOSY995.png

Right now, I'm looking at the data files to figure out how to reassemble them. After that, all the Vita games have caught up with PS2/Wii ones, can all 6 games can be work concurrently, in WebGL + Three.js format.

Until next update, take care!
- Rufas

I can only be impressed with Rufas, this guy is a genius.