@woodhu_man: Yeah, I think that was just a derp on my part. The .anb files you sent me were more than likely totally fine.

New version! Should fix all the troubles with the pakfiles I mentioned above.

Version 0.2

* Tweaked some variables to fix segfaults on .anb files with smaller images
* More sane program defaults. Now, -offset=24 is default, and -add is default as well, which generally results in better piece reconstruction. You can disable it with -noadd. This causes a duplicated pixel border on the edges of the images, but those can be easily removed by hand.

That should cover it. It works great now with all the .anb files I have (I should probably buy the actual game so I can test it on all of them, but meh). Let me know if you have any issues or run into an .anb file that causes it to fail.

Oh, and for posterity, the image data itself is stored as a 256-entry palette, with 4 bytes per entry. After the palette it's one byte per pixel. Kinda strange-yet-cool in my opinion. 256-color palettized 32-bit images? It seems to work great, though, because of the cartoony aesthetic they've got going.

It also looks like a lot of the frames are all out of order. Not my fault, but still strange that some of the animations would be split in the middle and such.

(07-02-2014, 02:53 PM)Daxar Wrote: It also looks like a lot of the frames are all out of order. Not my fault, but still strange that some of the animations would be split in the middle and such.

I've seen this happen in a couple of games, including Bastion. This is usually so that the frames are arranged in such a way to keep the image size as small as possible. In Bastion there was data for the rectangles (x, y, width and height values) for each frame in each animation. There may be similar data for BloodRayne somewhere in some other files.

That makes sense. I'm sure it simplifies their game logic someplace, kinda like the scrambled-tile images. Just feels strange is all.

EDIT: Obligatory GIANT RAYNE fistpump!


Why? Because woodhu_man was awesome and sent me all the game's .anb files that didn't work, so now I can safely say the program works with everything! Hopefully, anyway. I think. Unless something looks off, in which case let me know. But as far as I'm aware, every single last image from the game is now decompressible. So hooray!

This excludes gallery[1-8]/gallery[1-8].anb, as they don't even look like they're beginning to be in the same format.

Download Version 0.3 here!

Oh, and in other news, look what leftover gfx I found inside:

Does somebody wanna try this program with the files from A Boy and His Blob?

EDIT2: Oh, and I finally bought DuckTales: Remastered, so that means one thing:


A new version of wfLZEx!

wfLZEx v1.0

New stuff!
* Autodetection of image format! And support for a lot of new anb types (All of them, as far as I know). Thanks to Random Talking Bush for singlehandedly figuring basically all of them out.
* Drag-and-drop support! Yep, I completely broke it without realizing it. Oops. Thanks mr.walter for noticing.
* General stability fixes and that sorta thing
* Completely disregards most commandline flags now. Well, except -nopiece. It should "just work" for any of the game's anb files, however.

So now you spriter folks have no excuse. Hop to it and all that. Let me know if you find anything.

... Good lord it's beautiful.

(07-05-2014, 07:27 AM)Daxar Wrote: Does somebody wanna try this program with the files from A Boy and His Blob?

Oh hell yes.

EDIT: So I tested some of the .anb files in A Boy and His Blob, and no files showed up in the 'output' folder. I'm assuming that means it did not work for the game.

I'll send you some of the .anb files to check, Daxar, to make sure I'm not completely screwing up.