READ THE RULES: Click here

Follow us on Facebook: https://www.facebook.com/xentax/ :)

16x8 pixel tiled graphics (.tpl)

Get your graphics formats figures out here! Got details for others? Post here!
User avatar
shakotay2
MEGAVETERAN
MEGAVETERAN
Posts: 2731
Joined: Fri Apr 20, 2012 9:24 am
Location: Nexus, searching for Jim Kirk
Has thanked: 675 times
Been thanked: 1407 times

Re: 16x8 pixel tiled graphics (.tpl)

Post by shakotay2 » Mon Nov 11, 2013 11:49 pm

mugi wrote:as for tga header.

use: 0001 0100 0000 0120 0000 0000 E001 6801 0800
Just to be sure: no typo?
This is my header, palette start marked by the short line:
Image
if you want the code to write the palette before the data, just move the bit of code at the end regarding writing the palette, to before writing the pixel data.
I know that, thx. :)
We are working on it. (it looks like for some reason the output randomly generates an extra "0A" bytes to the data, several can be seen at the first 10 entries of the palette, the rest somewhere in the data.)
With the original I had additional 251 bytes before the palette. But I don't see an error in the code so far.
(Added a +1 to the buffer sizes, inserted a fclose(stdout) to be sure but that should not be required.)
note: the tga you will generate with this header is a 256-color indexed (RGBA palette) TGA. a good deal of graphics editors do not display it correctly at all.
Yep, got this prob with gimp. Although I switched to indexed image mode it doesn't seem to load it as such. Or the above header is wrong?

edit: could be an issue with the file mode, binary versa ASCII.
Last edited by shakotay2 on Tue Nov 12, 2013 12:03 am, edited 1 time in total.
Bigchillghost, Reverse Engineering a Game Model: viewtopic.php?f=29&t=17889
extracting simple models: viewtopic.php?f=29&t=10894
Make_H2O-ForzaHor3-jm9.zip
"You quoted the whole thing, what a mess."

User avatar
mugi
beginner
Posts: 32
Joined: Wed Mar 23, 2011 8:02 pm
Has thanked: 3 times
Been thanked: 9 times

Re: 16x8 pixel tiled graphics (.tpl)

Post by mugi » Mon Nov 11, 2013 11:53 pm

the header is correct, but this is a TGA tailored for console game use and hence barely ever seen with pc's.
i use ps2 graphics artists tools to generate them.

User avatar
shakotay2
MEGAVETERAN
MEGAVETERAN
Posts: 2731
Joined: Fri Apr 20, 2012 9:24 am
Location: Nexus, searching for Jim Kirk
Has thanked: 675 times
Been thanked: 1407 times

Re: 16x8 pixel tiled graphics (.tpl)

Post by shakotay2 » Tue Nov 12, 2013 12:14 am

yes, each 0A is extended to 0D 0A. Don't know how this could work for paulguy. Maybe he's on a UNIX machine?
Don't remeber exactly how it's handled there.

An outfile has to be opened in binary mode ("wb").
Bigchillghost, Reverse Engineering a Game Model: viewtopic.php?f=29&t=17889
extracting simple models: viewtopic.php?f=29&t=10894
Make_H2O-ForzaHor3-jm9.zip
"You quoted the whole thing, what a mess."

User avatar
mugi
beginner
Posts: 32
Joined: Wed Mar 23, 2011 8:02 pm
Has thanked: 3 times
Been thanked: 9 times

Re: 16x8 pixel tiled graphics (.tpl)

Post by mugi » Tue Nov 12, 2013 12:18 am

he doesnt use windows as far as i know.
i'll see what i can do for that. As i'e stated many times to this point, my programming is a zero. i have no idea what's going on in that code :P

edit: SUCCESS!!

you are a genius <3

i ran the .tpl though the decoder, opened in hex editor and replaced 0D0A with 0A.
then wrote a TGA header for it, result below:

Image

there are still few minor distortions, but that's propably due to the poking it with hex editor :P
i'll try and have the code fixed sometime soonish~

User avatar
shakotay2
MEGAVETERAN
MEGAVETERAN
Posts: 2731
Joined: Fri Apr 20, 2012 9:24 am
Location: Nexus, searching for Jim Kirk
Has thanked: 675 times
Been thanked: 1407 times

Re: 16x8 pixel tiled graphics (.tpl)

Post by shakotay2 » Tue Nov 12, 2013 12:47 am

mugi wrote:
edit: SUCCESS!!

you are a genius <3
Nope, I surely know I'm not. :D
But you are on your way to. Since you're young (I guess) and talented.
i'll try and have the code fixed sometime soonish~
Here's the exe. As soon as you confirm it working properly I'll upload the updated code, if required.
PaulGuy_cons.zip

edit: hmm, well. the header has fixed values for width, height - this should be changed in next version.
Bigchillghost, Reverse Engineering a Game Model: viewtopic.php?f=29&t=17889
extracting simple models: viewtopic.php?f=29&t=10894
Make_H2O-ForzaHor3-jm9.zip
"You quoted the whole thing, what a mess."

User avatar
mugi
beginner
Posts: 32
Joined: Wed Mar 23, 2011 8:02 pm
Has thanked: 3 times
Been thanked: 9 times

Re: 16x8 pixel tiled graphics (.tpl)

Post by mugi » Tue Nov 12, 2013 1:08 am

it works perfectly even.
im not talented though, nor young :P

now that this problem is out of the way, im on my way to the next one.

it appears the developers were complete asses when making these files. i looked up at a character render;
yuz01.tpl which is one image, 42kB in size, and according to it's header the resolution is 512x128.

obviously it isnt so because there isnt enough data to draw that much x_x

is there a way to calculate the how many tiles an image of certain resolution would take ?
it could be used to estimate the resolution since it seems that the header data is just bogus. (i'll also have to test in-game does the resolution actually affect anything even, since it's obviously incorrect.)

uploaded yuz01.tpl for you if you want to take a look at it. Grab it Here
i'll have to call it a day now, gotta get up to work in 6 hours :P

thanks again though, even as incomplete as this extraction routine currently is, looking at the whole thing, i should be able to start testing things with it now.

User avatar
shakotay2
MEGAVETERAN
MEGAVETERAN
Posts: 2731
Joined: Fri Apr 20, 2012 9:24 am
Location: Nexus, searching for Jim Kirk
Has thanked: 675 times
Been thanked: 1407 times

Re: 16x8 pixel tiled graphics (.tpl)

Post by shakotay2 » Tue Nov 12, 2013 10:01 am

mugi wrote:it appears the developers were complete asses when making these files.
hehehe, it appears someone is not very thankful to the developers who just try to earn money by providing us with nice games... :D
is there a way to calculate the how many tiles an image of certain resolution would take ?
Since a 16x8 tile has 128 pixels just divide (width x height) by 128. But I don't see how this could help.

This is the closest hit I had (TextureFinder, width: 128, Format: 8888):
Image
by using PaulGuy_cons yuz01.tpl 48 512 80 41008
512x80= 40960 is the pic data size in bytes (resp. pixels in 256 color mode).
Bigchillghost, Reverse Engineering a Game Model: viewtopic.php?f=29&t=17889
extracting simple models: viewtopic.php?f=29&t=10894
Make_H2O-ForzaHor3-jm9.zip
"You quoted the whole thing, what a mess."

User avatar
mugi
beginner
Posts: 32
Joined: Wed Mar 23, 2011 8:02 pm
Has thanked: 3 times
Been thanked: 9 times

Re: 16x8 pixel tiled graphics (.tpl)

Post by mugi » Tue Nov 12, 2013 11:02 am

im at work atm so cant really check much at the time, but i ran it with few different settings before going to bed last night and i got it to display pretty close with 128x360 / 128x360 / 128/256 or something along these lines. i had issues testing different settings because the application does checks to not allow resolutions that exceed the data size and/or resolutions that arent multiple of 8/16.

i'll do some research and get some screenshots later today to see the approximate sizes of the files.

the reason i was thinking about calculating approximate resolution based on data size is exactly because it has to be dividable with 8/16,
so there arent TOO many possible sizes to test with images this small.
shakotay2 wrote:hehehe, it appears someone is not very thankful to the developers who just try to earn money by providing us with nice games... :D
well, it's more like i think it's just illogical. why go through all the trouble of using something like this when the SDK provides a ready to use library for gim that supports alpha and whatnot, or just use some other standard format ? :P

makes me wonder if they do things like this just to annoy hackers sometimes.
Either way, i dont really mind since i enjoy reversing silly fileformats.

User avatar
shakotay2
MEGAVETERAN
MEGAVETERAN
Posts: 2731
Joined: Fri Apr 20, 2012 9:24 am
Location: Nexus, searching for Jim Kirk
Has thanked: 675 times
Been thanked: 1407 times

Re: 16x8 pixel tiled graphics (.tpl)

Post by shakotay2 » Tue Nov 12, 2013 1:01 pm

mugi wrote:[...]i had issues testing different settings because the application does checks to not allow resolutions that exceed the data size and/or resolutions that arent multiple of 8/16.
I append a CodeBlocks project where such things will be allowed. Nevertheless it doesn't makes sense to read past the filesize. The width/height sizes must be adapted in this case.
PaulGuy_cons.zip
(Hopefully I didn't mess up anything.)

On another note: on the page before you wrote:
mugi wrote:another piece of code below, encodes back to tiled format. Again, not tested by me as i still dont have a compiler set up.
I'm not sure but seems this is just another un-tiling code: (upps, nope, it's indeed the encoder)

Code: Select all

	for(i = 0; i < height; i += TILE_HEIGHT) {
>>>		for(j = 0; j < width; j += TILE_WIDTH) {
>>>			for(k = 0; k < TILE_HEIGHT; k++) {
>>>				fseek(infile, offset + (i * width) + j + (k * width), SEEK_SET);
				fread(buffer, TILE_WIDTH, 1, infile);
				fwrite(buffer, TILE_WIDTH, 1, stdout);
			}
		}
	}
because the lines marked by ">>>" are the only ones that are different.
Last edited by shakotay2 on Tue Nov 12, 2013 9:02 pm, edited 1 time in total.
Bigchillghost, Reverse Engineering a Game Model: viewtopic.php?f=29&t=17889
extracting simple models: viewtopic.php?f=29&t=10894
Make_H2O-ForzaHor3-jm9.zip
"You quoted the whole thing, what a mess."

User avatar
mugi
beginner
Posts: 32
Joined: Wed Mar 23, 2011 8:02 pm
Has thanked: 3 times
Been thanked: 9 times

Re: 16x8 pixel tiled graphics (.tpl)

Post by mugi » Tue Nov 12, 2013 5:27 pm

i'll test out the tile encoder and see if it works, but i'd assume it does.
dont really see any reason why he'd write 2 un-tiling apps :P

it'slikely that the tile encoder has the same bug than the decoder though, where it changes 0A to 0D0A :/
need to check that out.

User avatar
shakotay2
MEGAVETERAN
MEGAVETERAN
Posts: 2731
Joined: Fri Apr 20, 2012 9:24 am
Location: Nexus, searching for Jim Kirk
Has thanked: 675 times
Been thanked: 1407 times

Re: 16x8 pixel tiled graphics (.tpl)

Post by shakotay2 » Tue Nov 12, 2013 6:02 pm

mugi wrote:i'll test out the tile encoder and see if it works, but i'd assume it does.
dont really see any reason why he'd write 2 un-tiling apps :P
The original files having the palette near the end
the decoded (tgas) have it near the beginning, right?
So I'm confused why both original codes place the palette near the end.

(edit: this is a bug with the first code maybe you should edit it to not confuse other users.)
it'slikely that the tile encoder has the same bug than the decoder though, where it changes 0A to 0D0A :/
need to check that out.
It doesn't write in binary mode so it surely will. (It's not a bug it's the wrong OS I guess.)

So here the slightly modified encoder from paulguy:
(compile it to paulguy_enc.exe for example)

Code: Select all

#include <stdio.h>
#include <stdlib.h>
#include <windows.h>

#define TILE_WIDTH (16)
#define TILE_HEIGHT (8)

int main(int argc, char **argv) {
	int offset, width, height, paloffset;
	long delta, filesize;
	FILE *infile, *outfile;
	char buffer[TILE_WIDTH+1];                       // you can delete the +1 I guess, just debugging remains
	char outfileName[256], palbuffer[1024+1];
	int i, j, k;
    	bool bErr= false ;

	if(argc < 6) {
		fprintf(stderr, "USAGE: %s <infileName> <offset> <width> <height> <paloffset>\n"\
		                "\tOutput goes to infileName+'.tga'.\n", argv[0]);
		exit(EXIT_FAILURE);
	}

	offset = atoi(argv[2]);
	width = atoi(argv[3]);
	height = atoi(argv[4]);
	paloffset = atoi(argv[5]);

	if (offset < 0) {
		fprintf(stderr, "Offset must be positive.\n");
		bErr= true;
	}
	if (width < TILE_WIDTH) {
		fprintf(stderr, "Width must be greater than TILE_WIDTH (%d).", TILE_WIDTH);
		bErr= true;
	}
	if (height < TILE_HEIGHT ) {
		fprintf(stderr, "Height must be greater than TILE_HEIGHT (%d).", TILE_HEIGHT);
		bErr= true;
	}
        if (bErr) exit(EXIT_FAILURE) ;

    	if (width % TILE_WIDTH != 0)
            fprintf(stderr, "WARNING: width should be a multiple of %d.\n", TILE_WIDTH);
    	if (height % TILE_HEIGHT != 0)
            fprintf(stderr, "WARNING: height should be a multiple of %d.\n", TILE_HEIGHT);

	infile = fopen(argv[1], "rb");
	if(infile == NULL) {
		fprintf(stderr, "Failed to open %s.", argv[1]);
		exit(EXIT_FAILURE);
	}

	strcpy(outfileName, argv[1]) ; //strcat(outfileName, ".tga") ;
	strcat(outfileName, ".tpl") ;
	outfile = fopen(outfileName, "wb");
	if(outfile == NULL) {
		fprintf(stderr, "Failed to open %s", outfileName);
		fclose(infile) ;
		exit(EXIT_FAILURE);
	}

	fseek(infile, 0, SEEK_END);
	filesize = ftell(infile);

	if(offset > filesize) {
		fprintf(stderr, "*** Don't set the offset past the filesize (%d)!\n", filesize);
        fclose(infile); fclose(outfile) ;
		exit(EXIT_FAILURE);
	}
	delta= filesize - offset ;
	if(width * height + offset > filesize) {
		fprintf(stderr, "Read with set width:%i, height:%i and offset:%i would go past the end of the file.\n\n>>> change w to %d or h to %d\n", width, height, offset, delta/height, delta/width);
		bErr= true ;
	}
	if(paloffset < 0 || paloffset + 1024 > filesize) {
		fprintf(stderr, "Palette offset must be a positive value and within 1024 bytes from the end of the file.\n");
        bErr= true ;
	}
    	if (bErr) {
        	fclose(infile); fclose(outfile) ;
		exit(EXIT_FAILURE);
    	}

	fseek(infile, 0, SEEK_SET);
	for(i = 0; i < height; i += TILE_HEIGHT) {
		for(j = 0; j < width; j += TILE_WIDTH) {
			for(k = 0; k < TILE_HEIGHT; k++) {
				fseek(infile, offset + (i * width) + j + (k * width), SEEK_SET);
				fread(buffer, TILE_WIDTH, 1, infile);
				fwrite(buffer, TILE_WIDTH, 1, outfile);
			}
		}
	}
    	fprintf(stderr, "%d B. pic data written\n", width * height);

	fseek(infile, paloffset, SEEK_SET);
	fread(palbuffer, 1024, 1, infile);
	fwrite(palbuffer, 1024, 1, outfile);
	fprintf(stderr, "Palette written\n");

	fclose(infile); fclose(outfile);
	exit(EXIT_SUCCESS);
}
Now it's rather simple to test: decode a .tpl then encode the resulting file. If you get the same as the original, well, then it's an encoder. :D

edit: yes, it works.
Use this cmd line: PaulGuy_enc egbg00.tga 1042 480 360 18
(We have an offset of +18 to the pixel data start (1042=1024+18) and the palette start (18=0+18)
because of the tga header in the egbg00.tga)
Last edited by shakotay2 on Tue Nov 12, 2013 7:17 pm, edited 3 times in total.
Bigchillghost, Reverse Engineering a Game Model: viewtopic.php?f=29&t=17889
extracting simple models: viewtopic.php?f=29&t=10894
Make_H2O-ForzaHor3-jm9.zip
"You quoted the whole thing, what a mess."

User avatar
mugi
beginner
Posts: 32
Joined: Wed Mar 23, 2011 8:02 pm
Has thanked: 3 times
Been thanked: 9 times

Re: 16x8 pixel tiled graphics (.tpl)

Post by mugi » Tue Nov 12, 2013 6:42 pm

it should work on the background files like egbg00 we tested things out with.

however, i've been analyzing the yuz01, along with few other character renders and it seems it's using a different type of encoding (mode flags maybe, which is yet another reason for me to believe that the file header in TPL is actually just a bogus)

i worked on aru01, which according to the header is 64x512 pixels, and in-game the character render is 151x208 pixels, meaning the image is either exactly that, or somewhat larger.
Another thing with these renders is that it seems that yellowish colors (skin tone and yuzuha's yellow clothes) somehow manage to turn blue, even though the rest of the palette is working properly.

also, i went though tons of horizontal resolution values starting from 64 all the way up to 256 and it seems that the 128 is the only one that doesnt distort the image too badly.
with this though as some blocks align just right, there's a 1-pixel wide line of data that's not on it's place between every row of pixel blocks.

if i'd have to guess, it means that the blocksize isnt the same as it is on the background images.

edit: the reason the original code places the palette at the end is because it was made before the idea of using TGA came along.

edit2: can you compile the executables please, i cant seem to get the code to build wiht TCC (i'll get a proper compiler at some point)

User avatar
shakotay2
MEGAVETERAN
MEGAVETERAN
Posts: 2731
Joined: Fri Apr 20, 2012 9:24 am
Location: Nexus, searching for Jim Kirk
Has thanked: 675 times
Been thanked: 1407 times

Re: 16x8 pixel tiled graphics (.tpl)

Post by shakotay2 » Tue Nov 12, 2013 8:57 pm

PaulGuy_decEnc.zip

Maybe we've got a little problem here concerning the recalculating of proposed width/height when
the user chosen values cause an EOF crosssing. For the decoder delta should be filesize-1024-offset.

Also the palette size is not always 1024 (0x400). Tell me if you face a problem so far.
Maybe it should become another param in the command line?
Bigchillghost, Reverse Engineering a Game Model: viewtopic.php?f=29&t=17889
extracting simple models: viewtopic.php?f=29&t=10894
Make_H2O-ForzaHor3-jm9.zip
"You quoted the whole thing, what a mess."

User avatar
mugi
beginner
Posts: 32
Joined: Wed Mar 23, 2011 8:02 pm
Has thanked: 3 times
Been thanked: 9 times

Re: 16x8 pixel tiled graphics (.tpl)

Post by mugi » Tue Nov 12, 2013 9:58 pm

currently my only issue is these alpha channeled character renders (i dont actually have to edit these, but they're built hte same way as the menu files that do contain text)
it would appear that:

- the resolution values of these images are complete nonsense.
- i assembled aru02.tpl from the decoded blocks by hand to get the picture, and there are not enough tiles to form a full image.
there might be some tile reordering code involved which somehow dumps dublicate tiles to save space or whatever. The tiles are also seemingly not in any sane order.

- the palette on these character renders is 0x400 in size, but goes completely bonkers when used. it's sort of like half negative image and half negative colors (blues turn reds, yellows to blues, etc)
i checked and the palette data is identical to original TPL, so it does not corrupt on converting.

TL;DR: we have a problem.

edit: tested out the encoder and it seems to work fine on the background images.
propably it works fine with the other images too, but that isnt helping much until i figure out how read them correctly :P

Image Image Image

Edit: d'oh.. I think the palette is actually BGRA, not RGBA.
The background image with the girl threw me off because the rocks look "normal" on it, but after i slept over it i realized tha the colors are off in that picture too.. The scene is inside a cave, so the rocks are actually supposed to be dark blueish color.

If you wish to experiment with this particular render, its aru02.tpl. Should be included in the \ch folder on the examples i posted in the original thread.
Actual image dimensions are 176x208 pixels/11x26 tiles. The data is missing 30 tiles worth of data.

edit2: could you implement this for decoder and encoder please?

BGRA<->RGBA decode

Code: Select all

for(i = 0; i < paletteentries * 4; i += 4) {
j = palbuffer[i];
palbuffer[i] = palbuffer[i + 2]
palbuffer[i + 2] = j;
}
corrected output:
Image

still cant compile the code myself :P
i'll try and get a proper compiler setup today so that i can do small modifications like this myself.

User avatar
shakotay2
MEGAVETERAN
MEGAVETERAN
Posts: 2731
Joined: Fri Apr 20, 2012 9:24 am
Location: Nexus, searching for Jim Kirk
Has thanked: 675 times
Been thanked: 1407 times

Re: 16x8 pixel tiled graphics (.tpl)

Post by shakotay2 » Fri Nov 15, 2013 9:43 pm

Didn't see your 2nd edit; is your compiler setup ok now?
Bigchillghost, Reverse Engineering a Game Model: viewtopic.php?f=29&t=17889
extracting simple models: viewtopic.php?f=29&t=10894
Make_H2O-ForzaHor3-jm9.zip
"You quoted the whole thing, what a mess."

Post Reply