A Boy and His Blob Wii ANB files

[Daxar]

Colors are easy to change; I wasn't really worried about that.

The issue I was pointing out there was the garbled pixels here and there on the image. What do you mean by "Wrong start offset"? For the compression, or the makeTexture() method?

[Ploaj]

For the makeTexture(); the decompression seems to work fine now.

I'm not sure why it's not working, though. You could just try something like changing the initial pointer value to 1.
Or it could be something with the syntax of this

Code:

buffer1[i1++ + 1]

Sorry that this became a little more complicated than expected

Edit:
Maybe do it this way? I'm not sure if it will make a difference.
It just looks like it's reading the buffer wrong somehow.

Code:

RGBQUAD colorQuad = makeColor(buffer2[i2++], buffer2[i2++], buffer1[i1 + 1], buffer1[i1]);
i1 += 2;

[Daxar]

Yep, that was it. Maybe Java and C have slightly different orders of operation when it comes to incrementing and adding. Weird.



Thanks for the help! Off to revisit my sprite stitching code. Turns out my earlier observation of having to scale images to fit was wrong; I had just been rounding the sprite coordinates improperly while stitching. In reality, all the duplicated pixels around the edges should have been cropped by my code already. Oops. Nothing quite like realizing you coded it wrong right after uploading all the DuckTales and BloodRayne images. XD

EDIT: Piecing works great, too.

I'm working on boy_hop.anb at the moment. The only problem here is that I'm not 100% sure how multiple images are handled. It doesn't look like there's another LZX header after the first? Your decompressor stops at 0x2BD3, which looks like it might have another header after it... only the decompressed size is different?

[Ploaj]

That's amazing news!

I put how to read the other textures on the previous page.

Basically after the first 8 bytes in the file is a repeated section that gives all the frame info. The image offsets are among the first set of bytes.

It's 34 bytes per frame and the second set of 4 bytes is the new texture offset.



Edit:
And yes, the sizes will be different. It's a different texture every frame. You can find the new width and height in the frame part after the texture offset. They are shorts.

Edit:
Wow...
I just made my script read floats instead of ints
...
and that was all it needed to work...



Sorry about giving you all that unneeded work, Daxar
But thanks so much for helping me with this! I'll give you credit for everything.

How do you round the coordinates? Some of the ones I tested have been off by a pixel.

[Daxar]

For the UV coordinates, just multiply by image width and height, add 0.5, and cast to int. That'll round them to the nearest pixel.

Better yet, just use my program instead, it "just works" with all the anb files I've tried (Which is quite a few; redblueyellow gave me some a while back).

Let me know if you need me for anything else, or if it crashes/behaves strangely on any file in particular.

[Ploaj]

It works great!

Could you make it output to a folder with the filename, instead of frames in the output?
Like it make a folder called "Boy Hop" and put the frames inside with numbers formatted with 3 digits? Like "001" "002" "010" etc...

I know this sounds specific, but it makes sheeting them MUCH easier

[Daxar]

No worries.

Does this work ok?

EDIT: As an aside, what program are you using to sheet? I probably should look into something similar, as I'll likely be revisiting BloodRayne and DuckTales with my newfound anb knowledge...

EDIT2: Source code for anyone interested.

EDIT3: Come to think of it, because of how the images are centered on each sprite, it might be easier to stitch together sheets programmatically for a cleaner animation. Let me know if you'd like me to do this.

[Ploaj]

It works great!

I made a WIP sheet maker with java.
http://www.vg-resource.com/thread-27036.html

It's somewhat buggy(as you can see on the second page), but it works with general use
I'm going to make a GUI for it too.

Check out how fast I can get a neatly organized sheet with it --> http://i.imgur.com/PRcqIH2.png
It even aligned them in frames, so they are easier to use

Bigger sprites might be best to keep in zips, though. It depends, I suppose.

Edit:
It would be cool if you could export them still in frames, but correctly spaced. Like all have the same width and height and centered properly.
My sheet maker can center them, but not as accurate as doing it whilst ripping them.

[Daxar]

Nice! I'll have to give your program a shot, then.

New version should center properly. Tested it out on blobba_summon.anb, which jumped all around before, and it looks great. Good luck on the rip!

[Ton]

I'm excited. This game is so cute.

[Carpaccio]

I noticed the only thing missing is that uh..."King Blob" thing from penultimate series of levels. You know, the one you drop the rock on? He's pretty cool, was just wondering if this would work with him.

[Daxar]

It works for me, anyway.


I'm assuming Ploaj just hasn't gotten around to making the sprite sheet for him yet.

[Ploaj]

Actually, I made the sheet, but overlooked uploading it.
It's up now

I didn't know what to call him, so "King Blob" works for now. (He's called "Blobba" in the files)

[Egop3105]

Bit of an old thread, but I was wondering if anyone had had any luck with the tsb files? I believe they contain the background images of the game, along with the lyb files I think. Can someone give me some pointers on how to go about extracting the backgrounds to say png images? Here's a link to the game files (without anb's and wav's) https://mega.nz/#!FRZRBIbT!QCTvH3gTMO5MA...vP4zDF0IOk (or if you don't need al those files, here's just the ones for the forrest level https://mega.nz/#!BNpQ0CjI!adDRns8M-QzzN...J_DSw6dR1Q ) Thanks!