Legend Of Mana: Assembled Bosses/Monsters Sprites

[Mortifier777]

Ok, i just give up with LOM ripping and assembling, its way TOO much work and no one seems to care anyway... here its what i did with Du Inke: https://imgur.com/a/9QL8xgb

Better to focus on other ripping, LOM assembling its tedious as hell, and being me alone sucks.

[rufaswan]

Don't give up hope just yet! It *IS* possible after all!

Hi, I'm the SaGa Frontier 2 ripper from the other thread, and I had the very same problem when ripping the battle sprites from that game, but I managed to pull it off and ripped everything - battle sprites, map sprites, backgrounds, unused stuff...

Since Legend of Mana also a Square game in 2D artwork, I though I might give it a try. So far, here is my progress to auto-reassemble back the sprites:
http://www.mediafire.com/file/xewv4art7s...09.7z/file

After all, a game is just a program. A program that needs x,y coordinates to draw stuff on the screen. If you can find out where those data are, you can write a script to extract and reassemble the whole thing.

This problem can be solve, just like a puzzle.

Don't give up!

Cheers,
- Rufas

[rufaswan]

Got some free time today, so let's do some ripping.

Today I'm bring you the "big" update. "Big" as in boss sprites size big. I have Drakonis, Du Inke, and Mantis Ant:

http://www.mediafire.com/file/cmwniul5fv...01.7z/file

It is still not completely accurate yet, but I'm getting there.

Apparently, to reassemble the sprites, not only I need to vertical/horizontal flip some parts, I also need to rotate them as well.

This ends up being way more challenging than SaGa Frontier 2 ones.

Oh well, guess I'll just have to sin() and cos() my way out of this mess.

Cheers,
- Rufas

[Ton]

Good luck! I'd love to see more from these games!

[rufaswan]

IT IS DONE! Rotation is the last challenge for me to reassemble the sprites. Now it looks amazing!

Just one small thing I don't like about rotation though - it produced jagged lines. But there is nothing I can do about it, since "rotation" is just moving pixels to a new location. If the game is in HD, then those jagged lines will be less obvious as we'll have more pixels to work with.

With that said, let's enjoy some sprites! Today I bring you the "All Boss" update:

http://www.mediafire.com/file/2oa3y0nzf0...ss.7z/file

Getting a little burned out here, so I'll take a break for now. I'll be looking at those map files when I come back.

Cheers,
- Rufas

P.S. I trimmed all the excessive blank space but still keep enough space for sprites to animate correctly in this update. Let me know if you like this newer format or not. Thanks!

[rufaswan]

Finally it is here! All the sprites, objects, maps, backgrounds is ripped and reassembled just like in the game.

Speaking about the map files, those files are weird and crazy. Sometimes it just makes no sense why they are designed like that. For one, they mixed both 4-bit/16-colors and 8-bit/256-colors together in one file, with no clear way to tell them apart.

Then they have those image data in multi-columns. 4-bits ones is in 4 columns (64x256), 8-bits ones is in 2-columns (32x256). You'll have to extract 16x16 tile from there.

Then, in a poor attempt to save space, they auto adjust 4-columns into 1-column. There are no flags whatsoever to warn you about it.

Then, when you think all palette are either 16 colors/32 bytes or 256 colors/512 bytes, they throw you a 64 colors/128 bytes palette in your face.

... seriously, it pisses me off. Who made this crap?

Luckily, I have enough passion and determination to find ways to work around these nonsense. So here is the final result:

http://www.mediafire.com/file/gnb6hlkzsp...55.7z/file
(FILE INFO : it has 140,504 png and ~826 MB unpacked)

EDIT: Updated release (+fixes):
https://www.vg-resource.com/thread-29275...#pid659190

It would be a great help if anyone can organize all the images as spritesheets (with correct names) and upload them to the site.

Cheers,
- Rufas

[SmithyGCN]

Try getting other peoples' attention. I'd do it, but I'm working on my film (and a retired spriter nonetheless). I'd hate for these sprites and all your hard work to go to waste.

[Barack Obama]

I played the game 8-9 years ago and looked through the files.

- The map objects and backgrounds are full of duplicates and their animations are missing. For example, take the jungle folders and look at the plants, they have only one frame of three or four.
- Looking at the Deathbringer and other bosses, it's difficult to tell when one animation ends and the next begins.

All in all, putting this on sheets requires extra effort with savestates and Animget. Savestates to jump to different locations and bosses and Animget to get a look at the different animations. It's easy to tell what is what if the boss pulls his idle 3 or 4 times in a row and then attacks, and pretty hard if you have the files with each animation only existing once.

I will probably not participate in assembling them on sheets, but I can help in another way.

Here is a very useful tool called Sheet Maker:
https://mega.nz/file/gcwGUKJL#UnzvISG0zF...WwK125oAmA
I assemble all of my multi-image CrossCode rips with Sheet Maker and attached an easy-to-understand manual to it.

I can also provide savefiles from nearly all locations in the game, including boss fights:
https://mega.nz/#!oVJWAQAA!pFjtQx97vA8fY...vDYTf80a5Q (275,1MB)
They are savestates made with epsxe and can also be used with PSX VRAM Viewer to get the missing map object animations.

[rufaswan]

@SmithyGCN and @BarackObama Thanks for your interest and look through my rip. Let me know if you find any problem with it.

Looking at the Deathbringer and other bosses, it's difficult to tell when one animation ends and the next begins. [...] It's easy to tell what is what if the boss pulls his idle 3 or 4 times in a row and then attacks, and pretty hard if you have the files with each animation only existing once.

You guys are pretty funny. Really!

When I released my SaGa Frontier 2 rip, I got "Your archive has tons of duplicates. Please use a duplicate file remover to delete them so we can take a look". And now, I got "We can't work with them because you have only unique sprites."

There really no way to please everyone over here.

Back to the problem, when I am hacking the game, I stumped upon a data structure that looks suspiciously like animation sequence and timing data. If that turn out to be true, then what do I do with it? Release it as a text file? Make even more duplicates over a bunch of folders? Make Animated PNGs? How do I release it?

- The map objects and backgrounds are full of duplicates and their animations are missing. For example, take the jungle folders and look at the plants, they have only one frame of three or four.

Thanks. I just checked the pixel data and my debug log, and you are right.

I apologize for making an incomplete release. I was too focus on debugging the script and I missed it. Sorry.

Guess I'll have to re-rip all the map files then.

But then, I came across this image at LParchive.org and it left me terrified:



So apparently, THERE IS SEMI-TRANSPARENT ON SPRITES! The ax is semi-transparent! But my rip have them all opaque:



That's sucks! Really, really sucks! Now I'll have to redo everything!

Never expect there is alpha-blending too!

...Sigh

Let me know if you notice even more problems.

Thanks,
- Rufas

[Barack Obama]

"We can't work with them because you have only unique sprites."

In theory it's possible to work with them, but you need a lot of try and error. This is why context from the game is so important (idle, moving, attack 1, attack 2, hurt, etc.).

I must also say, the animations in the "wm" folder are pretty good. Some of them are a bit unclear where they belong to, but the animations itself are arranged good enough. I guess they need little to no effort to get them on sheets, provided that Sheet Maker is used.

For the information in the text files: Is it possible to use the data inside them to arrange the pictures in your folders? If yes, Animget wouldn't be neccessary to put them into context. Maybe you could put them into a .zip file and upload it per attachment in your next post? It would be interesting to take a look.

About the semi-transparency: Most of the bosses consist of several pieces and yes, the developers were able to freely manipulate every single piece. I wouldn't worry about this, because if someone really wants to use these sprites, he would work with the pieces and use the animations as a reference.

I also want to mention something from the folder "mana_all_bosses" and its subfolder "bon_bs00_img_0", picture 9-12. Here you can see single frames which don't really make sense, since they wildly change position and don't look like defense/hurt frames. Looks like they belong to the walk cycle, maybe your tool glitched out?

[SmithyGCN]

It looks fine to me. I wouldn't worry about it, rufuswan.

[rufaswan]

I must also say, the animations in the "wm" folder are pretty good.

But there are some bad sprites down there. For example /wm/wmap/manal/* are broken because I didn't do any alpha-blend there. Considering there are rotation like the sprites from /ana, it would be surprising to know if /ana didn't have any alpha-blending stuff too.

For the information in the text files: Is it possible to use the data inside them to arrange the pictures in your folders? If yes, Animget wouldn't be neccessary to put them into context. Maybe you could put them into a .zip file and upload it per attachment in your next post? It would be interesting to take a look.

I also want to mention something from the folder "mana_all_bosses" and its subfolder "bon_bs00_img_0", picture 9-12. Here you can see single frames which don't really make sense, since they wildly change position and don't look like defense/hurt frames. Looks like they belong to the walk cycle, maybe your tool glitched out?

Just finished writing a script to extract those data, and it looks like this:

Code:

anim_0 = 0,5   1,4   2,3   3,4   4,5   5,5   6,4   7,4   8,4   9,4  
anim_1 = 0,5   1,4   2,3   3,4   4,5   5,5   6,4   7,4   8,4   9,4  
anim_2 = 42,3   0,0   43,5   0,3   44,4   0,3   45,3   0,3   46,3   0,3   loop  
anim_3 = 117,3   0,0   118,5   0,3   119,4   0,3   120,3   0,3   121,3   0,3   loop  
anim_4 = 11,3   0,0   12,3   0,0   13,3   0,0   14,4   0,0   15,4   0,0   16,3   0,0   17,5   0,0   18,3   0,0   19,3   loop  
anim_5 = 10,1   0,158   10,5   0,0   25,3   0,0   24,3   0,0   23,3   0,0   22,3   0,0   21,4   0,0   20,3   0,0   19,3   loop  
anim_10 = 52,2   53,3   138,20  
anim_20 = 114,2   0,0   115,1   2,253   116,1   0,3   loop  
anim_21 = 114,2   0,0   115,1   2,253   116,1   0,3   loop  
anim_23 = 116,10  
anim_24 = 0,20  
anim_25 = 116,2  
anim_27 = 113,34  
anim_29 = 98,3   99,3   100,3   101,3   102,4   103,5   104,6   105,20   90,3   106,2   107,4   108,9   109,3   110,3   111,3   112,2   113,10  
anim_30 = 0,20  
anim_31 = 55,3   56,2   57,2   58,2   59,8   60,2   61,3   62,4   63,3   64,3   65,3   8,3   9,4  
anim_32 = 75,3   76,3   77,5   78,2   79,2   80,8   81,3   82,2  
anim_33 = 55,3   0,0   56,2   0,0   57,2   0,0   58,2   0,0   59,3   0,0   66,2   0,0   67,2   20,6   68,2   50,9   69,2   50,10   70,3   50,10   71,2   50,10   72,1   loop  
anim_34 = 55,3   56,3   57,3   58,3   59,3  
anim_35 = 83,2   59,2   83,2   59,2   83,2   59,10  
anim_36 = 84,4   85,4   86,4   87,5   88,6   89,8   90,3   91,4   92,5   93,5   94,2  
anim_37 = 95,2   96,2  
anim_38 = 97,2   64,4   65,3   8,3   9,3  
anim_40 = 130,2   0,0   131,2   0,0   132,2   0,0   133,2   0,0   134,2   0,0   135,2   loop  
anim_41 = 142,2   120,0   loop  
anim_42 = 142,4   120,0   72,1   15,0   73,2   0,0   74,2   0,0   129,3   0,0   57,5   0,0   56,2   loop  
anim_43 = 130,2   0,0   131,2   0,0   132,2   0,0   loop  
anim_44 = 136,2   20,0   137,2   40,0   137,2   46,0   141,2   loop  
anim_45 = 73,2   0,0   139,2   0,0   140,2   0,0   57,2   0,0   56,2   0,0   55,2   loop

They are in sprite id and fps pair. So for "0,5 1,4 2,3", it means
sprite 0 for 5 fps (or 83 ms)
sprite 1 for 4 fps (or 66 ms)
sprite 2 for 3 fps (or 50 ms)

The weird one you are talking about is sprite 10, which is used on anim_5. From the data, we can see the sequence is 10-25-24-23-22-21-20-19-loop. By checking the actual sprites, it is just how the boss walking backwards (retreating?).

If you want, I can create a bunch of anim_* folders and copy the sprites to there, something like
copy 010.png -> anim_5/001.png
copy 025.png -> anim_5/002.png
copy 024.png -> anim_5/003.png
...
In a way, that's even more duplicates for you guys.

Interestingly, I check the debug log of the sprite on my last post (/ana/twr_bs01_img_1/055.png), I couldn't find anything that can be used as alpha-blending. Every byte is already been used, there are no such data inside. It is so weird.

Learning on how to do alpha-blending now. So far, I see alpha-blended image ended up way more colors for my own CLUT file format. Needed to create a new file format for this.

Take care,
- Rufas

[Barack Obama]

If they're meant to bring an order into the animations, then duplicates are fine.

And as Smithy said, don't worry about the transparency. It's probably something that isn't even in the code, but a feature from the editor where the game was created in. I guess this is why you're not finding any data about it.

[SmithyGCN]

Why aren't more rippers ripping like this? There are games like the DS Castlevanias and Magical Starsign that could use it.

[rufaswan]

Keep crunching numbers night by night, I begin to understand how Playstation do alpha-blending.

For example, this sprite:
       

Don't you find it strange the clouds are black? It doesn't matter how transparent you make it, the clouds is still black and not going to become white.

As it turns out, that's because the clouds isn't an image to begin with. It is an alpha mask. If you add the value of both foreground and background pixels together, you'll get the same value from the in-game screenshot:
   

Since alpha mask are grayscale, we can also say any 16-color palette that are grayscale are actually alpha mask. And indeed, sprites with semi-transparency has grayscale parts:
       
(/ana/twr_bs01_img_0/070.png)

From Wikipedia, there are different modes of blending too. The clouds on Norn Peak has the data value of 1, which is additive blending. I also see data value of 3, like Roa.

I haven't figure out what 3 is yet, all I know 3 is less brighter than 1. The pixel value may decrease after the blending.

Need more research on the subject.

Why aren't more rippers ripping like this? There are games like the DS Castlevanias and Magical Starsign that could use it.

@SmithyGCN It is more technical to rip from game files than on VRAM. For one, you don't have to deal with decompression and decryption. VRAM is just raw image data, and there are many VRAM ripping tools and tutorials for non-technical ripper.

On the other hand, The Legend of Mana map files on /map/*/*.prs are compressed. You'll need some knowledge on MIPS assembly to understand how to decompress them.

And then we have reassembling parts into sprites. Even from the same game, the parts data is not the same for /ana/*/*.img , /wm/wmland/*.dat , /wm/*/*.dat + *.tim pair , /map/*/*.prs.dec . You'll need to write tools for each of them.

That's just too technical for most casual ripper.

By the way, I just took a quick look over 3 NDS Castlevania game files, and it seems pretty straight-forward. Files on /data/sc and /data/sc2 are just pixel data, 4-bit, 128 width. Corresponding files on /data/so are the sprite parts data.

What is missing is the sprite groups data to reassemble all required parts into a sprite. And figure out 3 unknown bytes on the sprite parts data.

I also need to find the palette data. Where do you get 286.cvpal and 290.cvpal for Loretta on Potrait of Ruins?

In any case, I'll look more into it only after I've finish up with Legend of Mana rip. Don't bite more than you can chew. Finish a project first before start another one

Take care,
- Rufas