Star Wars Bounty Hunter (GameCube) .GCT

[Puterboy1]

I would like to convert these into something viewable please, I think they may be texture/image files.

[Allen]

Please try this noesis script.

Edit:
Updated.
Added texture type identification.

[Acewell]

everything works fine in the smaller gct files but the base
offset variable breaks in the larger level gct file.
i think there is a padding calculation to be made.
sample here:
https://www.mediafire.com/file/pfu416c3 ... e.zip/file

[Puterboy1]

everything works fine in the smaller gct files but the base
offset variable breaks in the larger level gct file.
i think there is a padding calculation to be made.
sample here:
https://www.mediafire.com/file/pfu416c3 ... e.zip/file

Quite right. Not all of the texture files are perfectly presented. Some half one half of an image on the other side.

[Acewell]

if you change line 24 from this:

Code: Select all

baseOfs = bs.tell()+28

to this it works out for that larger sample:

Code: Select all

baseOfs = bs.tell()+2876

it seems some padding calculation is needed only between the header table and data.

i'll see if i can find more larger samples to compare.

[Puterboy1]

if you change line 24 from this:

Code: Select all

baseOfs = bs.tell()+28

to this it works out for that larger sample:

Code: Select all

baseOfs = bs.tell()+2876

it seems some padding calculation is needed between the header table and data.

i'll see if i can find more larger samples to compare.

This is the image problem I am talking about.

[Acewell]

This is the image problem I am talking about.

which file?

[Puterboy1]

This is the image problem I am talking about.

which file?

Did you not see the image I put up? It has two halves on the wrong side.

download/file.php?id=8013

[Acewell]

Did you not see the image I put up? It has two halves on the wrong side.

and i asked you which file, as in file name. no one can do a thing with the image you posted.

edit
the problem you see was likely caused by the base offset
issue from the first script that i was already discussing with Allen.
you got to give him time to fix it before you go exporting any images.

[Allen]

everything works fine in the smaller gct files but the base
offset variable breaks in the larger level gct file.
i think there is a padding calculation to be made.
sample here:
https://www.mediafire.com/file/pfu416c3 ... e.zip/file

Acewell, thanks for correcting me!
I thought the file had at most 2 pictures. At present, no good padding calculation algorithm has been found, and only the "file size minus the header data size" can be used for calculation.

The script has been updated.

[Acewell]

all is working good so far, thanks Allen!

[Puterboy1]

all is working good so far, thanks Allen!

If you wanted the file with the imagery on the wrong side, here it is.

[Acewell]

If you wanted the file with the imagery on the wrong side, here it is.

that image is correct, that is the way the data is stored.
there is likely another file telling the game engine how to handle it.

@Allen
i believe the first byte (your texUnk) in the header description is for the image type,
for example diffuse, normal, specular, etc.
it looks consistent with the images, especially in the larger archives.
you can use this info to append a letter to each image name when exported
to distinguish them since there are multiple images with same names.

[Puterboy1]

If you wanted the file with the imagery on the wrong side, here it is.

that image is correct, that is the way the data is stored.
there is likely another file telling the game engine how to handle it.

@Allen
i believe the first byte (your texUnk) in the header description is for the image type,
for example diffuse, normal, specular, etc.
it looks consistent with the images, especially in the larger archives.
you can use this info to append a letter to each image name when exported
to distinguish them since there are multiple images with same names.

I hope this means that images like the one I presented will be presented and exported correctly. Also, since either of you seem to have the game, have you checked the other files for anything interesting or a solution?

[Allen]

@Allen
i believe the first byte (your texUnk) in the header description is for the image type,
for example diffuse, normal, specular, etc.
it looks consistent with the images, especially in the larger archives.
you can use this info to append a letter to each image name when exported
to distinguish them since there are multiple images with same names.

Thank you, I think you are right!
After analysis, are the following types correct? Actually I don't know much about the type of texture.
texType:
0=diffuse no alpha
0x2=specular alpha(black color)
0x4=Reflection
0x10=diffuse alpha(black color)
0x20=DXT1 alpha
0x80=atlas or duffuse no alpha
0x90=atlas or duffuse alpha(black color)

When equal to 0x80 or 0x90, I think if there is another type of suffix file with the same name, it is a textures atlas, otherwise it is a diffuse map.

I hope this means that images like the one I presented will be presented and exported correctly. Also, since either of you seem to have the game, have you checked the other files for anything interesting or a solution?

I don't have a game, I only have a sample from you.

[Allen]

If you wanted the file with the imagery on the wrong side, here it is.

that image is correct, that is the way the data is stored.
there is likely another file telling the game engine how to handle it.

@Allen
i believe the first byte (your texUnk) in the header description is for the image type,
for example diffuse, normal, specular, etc.
it looks consistent with the images, especially in the larger archives.
you can use this info to append a letter to each image name when exported
to distinguish them since there are multiple images with same names.

I added a numeric type suffix to the file name to distinguish it.
People can modify it according to their own requirements.