Reskinning and Image Modding

[Spiff]

This tool only exports the first image in a .res file. Since each .res can contain more than one layer (and in a lot of cases, do) it'll need to be changed to reflect that if anything substantial needs to be changed in those .reses.

Mind uploading the source, Trav?

[theTrav]

This tool only exports the first image in a .res file. Since each .res can contain more than one layer (and in a lot of cases, do) it'll need to be changed to reflect that if anything substantial needs to be changed in those .reses.

It's supposed to save each layer with an incrementing _number.png suffix... Is it not doing that? do you have an example .res that I should be using as a test case?

Mind uploading the source, Trav?

http://haven-client.googlecode.com/files/havenresexsrs.zip
It's pretty ugly, I really just bashed loftar's code together and made minimal changes to it

[sabinati]

This tool only exports the first image in a .res file. Since each .res can contain more than one layer (and in a lot of cases, do) it'll need to be changed to reflect that if anything substantial needs to be changed in those .reses.

It's supposed to save each layer with an incrementing _number.png suffix... Is it not doing that? do you have an example .res that I should be using as a test case?

Mind uploading the source, Trav?

http://haven-client.googlecode.com/files/havenresexsrs.zip
It's pretty ugly, I really just bashed loftar's code together and made minimal changes to it

it is not doing that, all i have are _0.png. check out walls and trees, it's only the shadow

[Spiff]

Thanks TheTrav

you missed an i++:

TestTextureExtractor.java

Line 51
AFTER

Code: Select all

            ImageIO.write(img.img, "PNG", new File(filePath + imgFile.getName() + "_"+i+".png"));

ADD

Code: Select all

         i++;

Fixed link for the lazy: here

[theTrav]

ahh, thanks spiff!

now TAKE OFF THOSE STUPID GLASSES, GET A HAIRCUT AND GET A JOB YA HIPPIE!

[theTrav]

As an aside, I had a crack at re-encoding the png's to .res format this morning, as usual it's slightly harder than I originally thought, nothing impossible though. The .res files contain a bit more data than just the image layers, I will want to preserve that if we're going to replace the Resource instance properly.

I'm tossing up between saving the extra layer byte arrays as metadata files when I do the export or alternatively re-processing the .res files when I convert.

The latter would be a bit more of a PITA but it also means that if the non image data has changed you could still import your modded png's without re-exporting...

I'm not sure people really need that though as you could theoretically keep your modded png's in a separate folder structure and just blat it over the exported one as part of your packaging workflow...

I guess at this point it's probably more important to get something that works than to get something that's convenient/good to use, so if anyone's modding, I recommend you create a separate folder structure containing your modified files that mirrors the existing structure so that you can easily modify updated haven-res.jar versions.

[Spiff]

now TAKE OFF THOSE STUPID GLASSES, GET A HAIRCUT AND GET A JOB YA HIPPIE!

is this better?



Thanks for doing this Trav, I've looked and looked and looked at the .res files and yet they still make zero sense to me.

I guess at this point it's probably more important to get something that works than to get something that's convenient/good to use, so if anyone's modding, I recommend you create a separate folder structure containing your modified files that mirrors the existing structure so that you can easily modify updated haven-res.jar versions.

I've just been including it in a separate <something>-res.jar file with the same file structure. As long as you include it on the path-class first, it'll supercede the normal haven-res file. That way you don't have to re-download, modify, and re-upload the entire 16.7 MB file every time it gets updated.

[theTrav]

Thanks for doing this Trav, I've looked and looked and looked at the .res files and yet they still make zero sense to me.

first few bytes will be ascii signature for "Haven Signature 1"
next two bytes are resource version

Then layers. Each layer is:
NULL terminated layer name
next four bytes is the size of the layer (number of bytes left to read)
remaining bytes for that layer is binary data for whatever loftar has put in there. Could be an image, could be some audio, could be some code, could be an anim.

All the different layer types are defined in Resource.java as subclasses of Layer. They have constructors which take the byte array and handle deserialisation and they have an init method in case any non deserialization related initialization is required (eg, Animation layers will probably need to build up a list of Image layers that have already been deserialized)

Order of layers is not supposed to be important.

EDIT - probably worth mentioning is that Loftar uses unsigned bytes in his storage, whereas java only supports signed bytes (or vice versa I forget) so that's what all the Utils.ubyte16c(byte[]) is about

[loftar]

I'm tossing up between saving the extra layer byte arrays as metadata files when I do the export or alternatively re-processing the .res files when I convert.

Just FYI, we use a couple of convenient shortcuts that you may have use for.

We manipulate most sprite data as XCFs (the native format of the Gimp), where the layer names contain the relevant data for constructing such things as Z order and ID (the "neg" layer is constructed from an XCF layer containing color-coded pixels). The offset and size are added by the routines that autocrop the XCF layers (they are usually larger than technically necessary to make it simpler to draw). For images simple enough not to need XCF, we just store them as PNGs with the relevant information directly in the filename (for instance, an image with Z index 0 and ID 1 could be called "foo.0.1.png") -- the resource contructor program concatenates all files that have identical names before the first dot into the same resource file. The handling of metadata in filenames and layer names make ancillary files unnecessary, so I just thought that you may want to reuse that idea, though I guess it wouldn't be reasonable to construct XCF files from Java.

Order of layers is not supposed to be important.

That is correct. Since layers are built from multiple files in a directory, I couldn't order them even if I wanted, so you may consider that an invariant.

java only supports signed bytes (or vice versa I forget) so that's what all the Utils.ubyte16c(byte[]) is about

Yeah. Isn't that a pest? :-/

[theTrav]

Yeah. Isn't that a pest? :-/

Actually I don't really understand the benefit of unsigned bytes very well... Some sort of storage/networking optimization so you can send large numbers over the wire with less overhead?

I guess in your case bandwidth is an issue so it's probably worth it...