daishiva

My program has never been able to export the bigobs file correctly. Doing a load/save to the original file will save it with just a couple bytes difference, but that is just enough to make them not display correctly in the original game. My theory is that the extra bytes are there to account for some hard coding in the exe, as all the other formats are 'optimal'. And you are correct, the original intent of the program is to view the graphics. Saving an exported image came after all the view framework is in place and the code is... not so great. It needs to be rewritten more generically and with save/load/export/import in mind.

This is incorrect, you need .net to run pckview.

Aye, but for some reason that one 'optional' byte seems to make things not work in the real game if left out. Its the weirdest thing

The first image in the tftd bigobs file has a 255 ONLY at the end of the first weapon (gauss rifle) and i have no idea why it is there or how to put it there on a consistent (not hard-coded) basis. This is the only problem with editing the bigobs file. .... That, and the program wont load up a image block exported previously. This is because the import function assumes 32x40 images when the bigobs images are 32x48. Yep I'll have to fix that.

If you are editing the large bigobs.pck file that contains more than one image, the program doesnt save it exactly how the game wants for some reason. If you do the following: open pck export one file to bmp import bmp over original image (no change) save There is just a few bytes that dont get saved, and it baffles me why that information was there in the original files in the first place. As a result, the weapons in game dont come up exactly right, sometimes more than one is shown, sometimes they are off alignment. As to what format you need All bitmaps are saved as 8-bit (256 color) bitmaps. The palette of the bitmap does not matter when importing, as the program assumes you are importing a previously exported image, so all it does is read the indexes of the bitmap and use the internal palette to display what you have loaded. If you are loading a image 'block', then it also assumes you are importing an exported image, where it can calculate each individual image location based on the width and height of the large bmp. At least that is how it is supposed to work. If you want you can send me your image (bmp) and i can look at it and see what new bugs you have uncovered =)

I just checked out the palette.dat file, the colors line up almost exactly between the hand-made and the originals. Thanks for the <<2 tip =) The battlescape palette for tftd is not in the palette.dat file it would seem Now we just have to figure out what that 6-byte block is for

Multiplying the backpals colors by a constant number does show that every 16 colors is a color gradient. I'm *fairly* sure that the background images only use a 'row' of 16 colors as this would allow you to simply offset each index by 16 and you have a completely recolored image that still looks good. Getting the exact colors seems to be more hit and miss though, as each monitor will display them just a tad different.

I made a background image containing every color and in such a way i could determine the color->index mapping. After loading it into the game, i took a screenshot (printscreen), wrote a program to look at the pixel colors and put them into a format i wanted, and poof, i had my palette =)

I reached the same conclusion you did about the palette structure. When i noticed that their palettes didnt match mine at all, i stopped looking at the files. Couldnt find a good mapping/equation to make the original colors somewhat close to mine either. Its possible I overlooked something extremely obvious though, so if you figure it out, i would love to know =)

Here you go =)

Actually I had the sizes wrong. My first clue should have been how things did not look nicely: couldnt read the numbers. How did I make them? I edited my xcview program to decode/export (not import yet) the files. There is no fancy compression for these files, its just an uncompressed bitmap in 160xfilesize/160 size tftd http://www.daishiva.com/images/interwin-tftd.gif ufo http://www.daishiva.com/images/interwin-ufo.gif

Here you go tftd http://www.daishiva.com/images/INTERWIN-tftd.gif ufo http://www.daishiva.com/images/INTERWIN-ufo.gif

Yeah i like that animation, its just as long in tftd too

For fun, I made an animated gif out of the explosion graphics awhile ago http://www.daishiva.com/images/explo1.gif http://www.daishiva.com/images/explo2.gif

The image is 320x200, might not be what the game runs in, but its what the image decodes to the .dat files are probably static-size image packs. Texture.dat are the textures used for the geoscape (pckview opens that)

Some notes: if a pck file doesnt have a TAB file, then it only contains one image. Sometimes the image is encoded using the pck encryption, sometimes its not encoded (one byte, one pixel). Just gota try it and see what comes out and what doesnt. the bigobs entries are larger than 40 pixels high. pckview opens these files, it just doesnt save a workiing file thats usable in game yet. x1.pck contains the explosion graphics, the sizes are 128x64. if a graphics file contains a background image (scr mostly) they are 320x200. medboard.pck for example: http://www.daishiva.com/images/med.gif

I would be led to believe that they were in UNITS/BREATH-1.pck

Link Hasnt been updated in awhile (as noted by the now broken link) but the information is correct to my knowledge

This information would be extremely useful if you wanted to ... say ... write a new executable for either the geoscape or battlescape portions of the game (without touching the other) That, and knowing what kind of information is passed between the executables, which I think is already known (in some format) since xcomutil does stuff with it. so in short, id say: Cool, keep up the good work =)

I believe they are in the respective language file found in the GEODATA directory. Havent directly tried this, but it looks like all the game text is there.

Its not a question of being open, ill tell you whatever i know. The stuff you have listed there, i did not know. On my website i have a document detailing the information that i DO know (image and map formats) because that is what i work with. If you ask, the people that know will usually respond. Scott would LOVE to make his program open source, but cannot due to legal restrictions. File formats/byte offsets i do not believe are covered under that, but you would have to ask him =)

Yeah the code in it is pretty outdated, i should update it some time =)

handobs are the same, just put the weapon over the built-up sprite, its just another card in the deck Really? Which civilian file is like that? And as for 'aligning' the images 41 or so pixels from one another, am I correct in assuming you guys dont know about saving individual tiles? Right click on an image, save it as a bmp and you will have that frame by itself, making it (i think) easy to align one frame with another.

Like a stack of playing cards, each image goes on top of the other Looking at the chryssalid images, i dont see why they would be any different than making, say, an aquatoid

The parts arent 'attached', every body part's topleft corner is drawn on the same location.