Talk:PALETTES.DAT
Just for a bit of general --Darkfred 07:29, 13 June 2007 (PDT)information, it might be worth mentioning that some of the palette entries are used for colour cycling. For example the radar pings on the intercept console. That's achieved by shifting a whole block of palette entries to give the effect of movement. (Think KITT's chasing lights) The image doesn't change, but the colour that you see does. It results in a wave movement. If anyone remembers the shifting colours on ye olde Windows startup screens, this was achieved in the same way.
Other palette swaps include the greyscale background bitmaps that are used in the Geoscape screens. They keep the same palette entry, and the game only needs to shift these entries to different shades to change the shades of the backgrounds.
Come to think of it, anyone know what conditions change the normal backgrounds from red to purple? It seems to vary.
Also another random technical tidbit, the game uses mode 13h for its display. In other words 320x200x256clr VGA mode. It used to come standard on all SVGA cards as a safe mode to revert to. The first fifteen colours after the transparency were probably left behind for use by the console. They appear to match the old text mode 16 colour palette.
- NKF
In the case of the background images, the palette swaps are pulled from BACKPALS.DAT, but I never realised the intercept radar was a palette cycle, though it does make sense - I assume that's handled entirely by the executable.
Oooh, I didn't know mode 13 was a *real* display mode! I thought it was just a "prebuilt" mode that QBasic provided to "script kiddies". XD
Not sure what you mean about those fifteen colors and how "They appear to match the old text mode 16 colour palette". I checked QBasic's idea of what the default mode 7 palette should look like (mode 7 being a sixteen color only version of mode 13, but with multiple "screens" you could flip in and out of the display buffer - guess you could call it EGA?) and it doesn't match the colors in any of UFO's palettes. But, I dunno if the palettes QBasic used followed any real standard, or if I even know what I'm talking about. :)
- Bomb Bloke 04:56, 12 June 2007 (PDT)
- Xcom was built for mode 13h with a 6 bit ramdac, (hence the 0-64 color values). This was one of the few modes which was widely available and worked the same on all early pc's. It was started via interrupt 13h also called MCGA and the bios did all the setup work. I don't think there was a default mcga palette, but it could be the default EGA palette.
- The palette animation could be done either way, I will check on this, but it might just be easier to switch the pal to grayscale, and take a screenshot during the animation. Then look at the color values. In the windows version the palettes are entirely faked anyway so doing it via code wouldn't be any slower.--Darkfred 07:58, 12 June 2007 (PDT)
- It's actually interrupt 0x10, with AH=0, AL=0x13. The 6/18 bit entries in the palette table was, and still is standard for 8-bit palette modes in VGA. MCGA was also an actual card, between EGA and true VGA. Mode 13 has an additional benefit for 16-bit DOS mode programmers in that the entire memory map for the card (320x200x1 byte/pixel = 64,000 bytes) is available within a single segment, meaning no bank swapping is necessary (much faster). The Amiga version(s) of XCOM would have used a 4/12 or 8/24 bit color resolution though, depending on whether it was OCS/ECS or AGA. I can't remember which Amiga version I had though, or whether or not it looked "ECS-y" or not. -- Renegrade 09:47, 2 February 2010 (EST)
Not sure what you mean by "palette faking"... I know that if you take a screenshot in the CE version of the game (F12), the resulting image will be a 256 color job using whatever palette the game was supposed to be using at the time.
Hence my thought was to just take multiple screenshots of the animation, and check to see what the palette looked like. Sure enough, colors 112 through to 127 (16 in all) cycle through shades of green, whereas the image itself doesn't actually change.
- Bomb Bloke 17:53, 12 June 2007 (PDT)
- Good work! Very cool.
- This may be boring but I will explain what I meant by palette faking. Its interesting but not terribly useful unless you wanna mod the exe.
- Palette Faking: The CE version of UFO is actually rendered in 32bit color at 640x400. You can take a screenshot of this version using the PrnScn key on your keyboard. The image you get when you press F12 is from UFO's fake internal MCGA buffer.
- When UFO was converted to a windows application the developers cheated, they made a copy of the mode13h memory in the executable, which they use as if it was the actual screen. They also make a fake copy of the palette. Then after each frame is drawn they copy this into the 32bit DirectDraw surface. They convert from the MCGA format into 32bit and run an upsampling filter (2x to 640x400). This is why the edges of letters look smoother in-game then in screenshots.
- The upshot is that the CE game is the exact same game code, only wrapped with a mode13 emulator. Cool huh. This is what allows the Exe Splitter and filter changing mods to work, 90% of the work is already done. --Darkfred 22:03, 12 June 2007 (PDT)
- It also implies that those who did the Windows conversion were not the same programs who made the game. The original programmers would have done it seemlessly rendering into the DirectX buffer. The CE programmers may not have even had the sourcecode, the hack could be done without it. (although audio might not be so easy I donno). --Darkfred 22:07, 12 June 2007 (PDT)
- I believe the programmers that did the Win32 port may have had access to the source of the original executables. Lots of constants and other tables for both the executables seem to be lumped together at the end, which is why you can't always get a rough match for some variable offsets in the dos version and the executable version. They aren't just both of the original executables mushed together with a bit tacked on the end(or front) to get it to work with Direct X, as I originally thought.
- Come to think of it, pressing print screen in the CE does take screenshots, but the palette information isn't carried over, so the bitmap that ends up on the clipboard is ruined. - NKF
- My UFO version is calling DirectDraw and requesting a 640x400x32bit display mode. It also makes nice 32bit screenshots when i press printscreen, I just verified this. It may be that there is some difference between our versions? --Darkfred 23:34, 12 June 2007 (PDT)
- It's not the game. I think it might just be the way some implementations of Windows handles screen captures. For lots of players, the screenshots palette will not be captured, and because the individual pixel index colours aren't saved, the image on the clipboard is ruined and cannot be recovered. I guess your clipboard works a lot better than most of us! (Or I suppose it could be your display mode). Using Printscreen with the dos version of the game works fine though, and the palette information isn't destroyed. My old copy of Windows 95 used to doubled the dos screen's pixels as well. Oh well. For now, the Collectors Edition's special F12 screen capture key for UFO/TFTD is still the most reliable method to capture screenshots. No matter how the game is displayed, the screenshot is stored as a 320x200x8 TGA file in the game directory- NKF 00:36, 13 June 2007 (PDT)
- I don't see how the palette could be the problem though, my version of the game simply has NO palette. It is all converted to 32bit being put on the screen. And the screen doubling is using the SuperSai algorithm, which only works on 32bit buffers. The only thing I can think of is that perhaps it is receiving a 8bit buffer instead of the 32bit one it requests, but this doesn't make any sense. The most likely explanation is that the color problem is either a difference in our versions or a bug in your video drivers. --Darkfred 07:29, 13 June 2007 (PDT)
- It's not the game. I think it might just be the way some implementations of Windows handles screen captures. For lots of players, the screenshots palette will not be captured, and because the individual pixel index colours aren't saved, the image on the clipboard is ruined and cannot be recovered. I guess your clipboard works a lot better than most of us! (Or I suppose it could be your display mode). Using Printscreen with the dos version of the game works fine though, and the palette information isn't destroyed. My old copy of Windows 95 used to doubled the dos screen's pixels as well. Oh well. For now, the Collectors Edition's special F12 screen capture key for UFO/TFTD is still the most reliable method to capture screenshots. No matter how the game is displayed, the screenshot is stored as a 320x200x8 TGA file in the game directory- NKF 00:36, 13 June 2007 (PDT)
- I doubt it -- it's almost certainly a matter of exact environment. UFO/CE/W2K with the graphics fixup loader against NVidia drivers is palette-corrupted (just tested), so any chance of PrintScreen working normally on this platform is from using PrintScreen against an emulator. --Zaimoni 16:28, 13 June 2007 (CDT)
- I am beginning to think that my highres 32bit version is the result of one of the mods I installed, i just don't know which. This would explain why the code is done in this way, stubbed into the beginning of the executable. Come to think of it I don't have any flashing screen problems like I did before either. hmmm. Well it works and I really don't care at this point. --Darkfred 16:40, 13 June 2007 (PDT)
Under CE, a printscreen will give you an image with a corrupt palette. F12 gives you a proper image.
The only way (that I know of) to get a 2xSaI effect is to run Mok's executable. Best I could make out, most of his extra code is tacked onto the end of the file... Printscreen will work "correctly" with this version, though F12 will still give unscaled images. This version of the game also has a variety of other differences to the usual engine (never checked the full list, but I gather there's some timing tweaks as well as a different way of handling sound).
The game uses DirectDraw regardless. Without f0dder/Mok's patches, the graphics (usually) won't render correctly. f0dder blames the DirectDraw implementation in his patch documentation, which'll be why disabling hardware acceleration is another way of fixing things up.
The CE game is remarkably similar to the Dos version, but there's a handful of differences. Although the game handles most errors by either ignoring them or crashing, it actually responds to some of them with intellegent messages. For example, if you pass it an over-filled MCD array (easy to do when running my damage testing tileset, just visit anything larger then a scout ship in the desert), you'll get a pop up box complaining about there being "too many map codes". You also get missing file messages if the game can't find inventory screen images.
The most famous difference is the vertical waypoint bug (where a blaster bomb missile told to go directly up or down will instead fly off on an angle - The aliens often kill themselves with this one). Though it's still my guess that the coders who ported the game just changed as much code as they felt was needed to make the game compile as a windows executable, and left it at that.
- Bomb Bloke 02:06, 14 June 2007 (PDT)
TFTD's Depths
Just recalling what I deduced ages ago while playing the game using X-Comutil and the map and depth picker, I agree that the palettes are adjusted on the fly. Having a sea bed map appear grey on land but appearing blue in water was quite strange - it wouldn't make sense to duplicate all the images for the various depths. The simplest way to achieve this effect would be to tint the palette with blue, and just darkening the images to simulate depth would be quite easy. Also I recalled that in UFO that the background images in the various screens were all grey, but on-the-fly changes to the palette allow them to change between colours like red, olive and purple. They have their designated set of colours in the palette too if I'm not mistaken.
One good way to find out would probably be to replace an entire row of colours with the same colour, then observe what happens in the various depths. I was going to suggest pure white, but then you couldn't go up any further which would be needed for the tint. Perhaps a middling value like 128, 128, 128 for a flat grey.
- NKF
I started looking into the palettes in more detail so I could convert UFO graphics to TFTD's colors, and vice versa. I took a screenshot of TFTD CE and ripped the palette from that (as the colors for the battlescape didn't seem to be in Palettes.Dat).
After the first conversion, most of the colors seemed "ok" but some (eg. rocks) came out blue when Daishiva's PCK viewer declared them to be grey - and surface terrain (eg. grass and trees) looked decidedly off...
I then took a ton of screengrabs and eventually decided on a total of four palettes. I'd completely forgotten that TFTD used depth settings as well as time of day so it took me a little while to work out why the things kept changing.
It wasn't until I loaded up XcomUtil to force certain map types that I finally saw the light. Four palettes, four depth settings. One good example of the effect is the "atlantis" terrain (which makes heavy use of grey stone).
- Bomb Bloke 20:16, 1 January 2008 (PST)
I've been doing some stuff with the color-swapping SCR files and noticed that they index E0-EF, the second-to-final 16 palette entries. Currently the page says the BACKPALS.DAT palettes replace the 16 final entries. Is the page wrong or is there something I'm missing?
- Majorlag
Tactical Palette - last 16 colors.
The last 16 colors of the Tactical Palette are more exactly this, I believe:
240: 39,40,40 241: 35,37,37 242: 32,34,35 243: 29,31,32 244: 26,29,30 245: 23,26,27 246: 21,23,25 247: 18,20,22 248: 15,17,20 249: 13,14,17 250: 11,12,15 251: 9,9,12 252: 6,7,10 253: 5,5,7 254: 3,3,5 255: 0,0,0
(these are out of 63, rather than out of 255, as per VGA hardware registers)
I did a dosbox screencap from XCOM-DOS v1.4 and extracted the exact palette from the resulting PNG and got values that were evenly divisible by four, suggesting that dosbox merely multiplies the value of the register by 4 (left shift by 2) to make 24-bit graphics.
These values make more sense to me than the values I was extracting from the PNG.
Renegrade 23:23, 3 August 2010 (EDT)
- I got mine from TGAs taken by the CE version of the game (press F12 while playing), which also have factors of four (because most "conventional" image file formats don't use 18-bit colour values like the game itself does). Now that I check them again, I see the palettes of these screenshots don't 100% match either the values I use in my code (which are obviously wrong, as they don't all have factors of four - wonder how I managed that?!), nor the values you list here... Hmm. Wonder if they changed them for the CE version, or if the built-in screenshot function just fudges things? - Bomb Bloke 22:48, 6 August 2010 (EDT)
TFTD 'unknown' second palette
- The second PALETTES.DAT TFTD palette is marked as unknown - to me it looks like it is used for the ufopaedia (UFOGRAPH/UP*.BDY) files - it seems to match what I see in the game, unlike the other palettes