Talk:PALETTES.DAT - Revision history

Volutar: /* 6 bytes "buffer" at the end of each palette */

2013-01-24T03:37:39Z

6 bytes "buffer" at the end of each palette

← Older revision		Revision as of 03:37, 24 January 2013
Line 129:		Line 129:
	== 6 bytes "buffer" at the end of each palette ==		== 6 bytes "buffer" at the end of each palette ==

	According palette functions this "buffer" doesn't mean anything, those bytes are not even touched anywhere. Just some trash data. It addresses to 774Pal_Number, and uses only first 768 bytes (2563).		According palette functions this "buffer" doesn't mean anything, those bytes are not even touched anywhere. Just some trash data. It addresses to 774Pal_Number, and uses only first 768 bytes (2563). So, I believe, there's no purpose to show those in the Page, it just confuses people.
	--[[User:Volutar\|Volutar]] 22:35, 23 January 2013 (EST)		--[[User:Volutar\|Volutar]] 22:35, 23 January 2013 (EST)

Volutar: /* 6 bytes "buffer" at the end of each palette */ new section

2013-01-24T03:35:51Z

6 bytes "buffer" at the end of each palette: new section

← Older revision		Revision as of 03:35, 24 January 2013
Line 126:		Line 126:
	[[User:jonnyh\|JonnyH]]		[[User:jonnyh\|JonnyH]]
	: 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		: 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

			== 6 bytes "buffer" at the end of each palette ==

			According palette functions this "buffer" doesn't mean anything, those bytes are not even touched anywhere. Just some trash data. It addresses to 774Pal_Number, and uses only first 768 bytes (2563).
			--[[User:Volutar\|Volutar]] 22:35, 23 January 2013 (EST)

Jonnyh: /* TFTD 'unknown' second palette */

2012-09-26T14:39:33Z

TFTD 'unknown' second palette

← Older revision		Revision as of 14:39, 26 September 2012
Line 124:		Line 124:

	== TFTD 'unknown' second palette ==		== TFTD 'unknown' second palette ==
	[[User:jonnyh:JonnyH]]		[[User:jonnyh\|JonnyH]]
	: 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		: 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

Jonnyh at 10:37, 26 September 2012

2012-09-26T10:37:53Z

← Older revision		Revision as of 10:37, 26 September 2012
Line 122:		Line 122:

	: 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? - [[User:Bomb Bloke\|Bomb Bloke]] 22:48, 6 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? - [[User:Bomb Bloke\|Bomb Bloke]] 22:48, 6 August 2010 (EDT)

			== TFTD 'unknown' second palette ==
			[[User:jonnyh:JonnyH]]
			: 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

Bomb Bloke: /* Tactical Palette - last 16 colors. */

2010-08-07T02:48:25Z

Tactical Palette - last 16 colors.

← Older revision		Revision as of 02:48, 7 August 2010
Line 120:		Line 120:

	[[User:Renegrade\|Renegrade]] 23:23, 3 August 2010 (EDT)		[[User:Renegrade\|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? - [[User:Bomb Bloke\|Bomb Bloke]] 22:48, 6 August 2010 (EDT)

Renegrade: New section: Tactical Palette - last 16 colors.

2010-08-04T03:23:27Z

New section: Tactical Palette - last 16 colors.

← Older revision		Revision as of 03:23, 4 August 2010
Line 88:		Line 88:

	- [[User:Majorlag\|Majorlag]]		- [[User:Majorlag\|Majorlag]]

			== Tactical Palette - last 16 colors. ==

			The last 16 colors of the Tactical Palette are more exactly this, I believe:

			<PRE>
			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
			</PRE>

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


			[[User:Renegrade\|Renegrade]] 23:23, 3 August 2010 (EDT)

Bomb Bloke at 08:09, 27 June 2010

2010-06-27T08:09:05Z

← Older revision		Revision as of 08:09, 27 June 2010
Line 57:		Line 57:
	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 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 [[~~TERRAIN~~\|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 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\|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.		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.

Renegrade: Regarding mode 13h

2010-02-02T14:47:17Z

Regarding mode 13h

← Older revision		Revision as of 14:47, 2 February 2010
Line 20:		Line 20:
	: 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.		: 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.--[[User:Darkfred\|Darkfred]] 07:58, 12 June 2007 (PDT)		: 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.--[[User:Darkfred\|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. [http://en.wikipedia.org/wiki/MCGA 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. -- [[User:Renegrade\|Renegrade]] 09:47, 2 February 2010 (EST)

	-------		-------

Majorlag at 05:48, 14 January 2009

2009-01-14T05:48:30Z

← Older revision		Revision as of 05:48, 14 January 2009
Line 81:		Line 81:

	- [[User:Bomb Bloke\|Bomb Bloke]] 20:16, 1 January 2008 (PST)		- [[User:Bomb Bloke\|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?

			- [[User:Majorlag\|Majorlag]]

Bomb Bloke: /* TFTD's Depths */

2008-01-02T04:16:15Z

TFTD's Depths

← Older revision		Revision as of 04:16, 2 January 2008
Line 69:		Line 69:

	- [[User:NKF\|NKF]]		- [[User:NKF\|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).

			- [[User:Bomb Bloke\|Bomb Bloke]] 20:16, 1 January 2008 (PST)