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)
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)