Jump to content

daishiva

Members
  • Posts

    92
  • Joined

  • Last visited

About daishiva

  • Birthday 08/01/1981

daishiva's Achievements

Sergeant

Sergeant (2/5)

0

Reputation

  1. 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.
  2. This is incorrect, you need .net to run pckview.
  3. 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
  4. 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.
  5. 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 =)
  6. daishiva

    Palettes

    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
  7. daishiva

    Palettes

    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.
  8. daishiva

    Palettes

    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 =)
  9. daishiva

    Palettes

    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 =)
  10. daishiva

    Spk Editing

    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
  11. daishiva

    Spk Editing

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

    PCK

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

    PCK

    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
  14. daishiva

    PCK

    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)
×
  • Create New...