Colour palettes

[+Spaced Cowboy]

Can anyone point me to a genuine verified-works NVDI-style colour palette file ? Or can anyone confirm that the one in XaAES/.../pal/nvdi.pal is actually correct ? I'm having some real trouble trying to get my parse-the-colour-RSC file code to work.

 

For example, here's two icon files - the top one is what I'm parsing out, the bottom one is the render from the site - and it claims to be using an NVDI palette to do the rendering.

I'm getting the correct data from the file, so the structure of the icon is correct, but the colours are all wrong. The thing is that if I look at the hex values of the colour in the "correct" icon, the top left corner of the dark grey box (the first visible pixel) has RGB of 128,128,128. According to my dump of the XaAES nvdi.pal file...

static RGB _palette[256] = {
	/* 000, 0x00 */ {255,255,255},
	/* 001, 0x01 */ {0,0,0},
	/* 002, 0x02 */ {241,0,0},
	/* 003, 0x03 */ {0,230,0},
	/* 004, 0x04 */ {0,0,241},
	/* 005, 0x05 */ {26,202,186},
	/* 006, 0x06 */ {255,255,0},
	/* 007, 0x07 */ {230,51,153},
	/* 008, 0x08 */ {217,217,217},
	/* 009, 0x09 */ {128,128,128},
	/* 010, 0x0a */ {128,0,0},
	/* 011, 0x0b */ {0,128,0},
	/* 012, 0x0c */ {0,0,128},
	/* 013, 0x0d */ {0,128,128},
	/* 014, 0x0e */ {182,161,57},
	/* 015, 0x0f */ {128,0,128},
	/* 016, 0x10 */ {0,0,51},

...

 

... that is colour index 9 (and there's no others, I checked). I'm getting index 16 (0,0,51), which is why you can see the darker outline around the icon.

 

I looked at the actual binary file loaded in, in planar format, and I don't see a way to get two bits set for that pixel. Here's the dump

I've circled the bytes on each plane that form the first pixel that isn't white. Assembling those plane by plane has to either give {0x00, 0x00, 0x00, 0xFF, 0x00, 0x00, 0x00} or (if the highest bit of the plane comes first) {0x00, 0x00, 0x00, 0x00, 0xFF, 0x00, 0x00, 0x00} for the first 8 pixels. Either way, I only see 1 bit being set in each of the 8 pixels, so getting '9' would be ... difficult. The MFDB looks ok...

 

 

I'm presumably doing *something* wrong, but it's not clear what. If there's a good example of the code to actually parse colour icons out there, I'd appreciate someone pointing me towards it

 

[mikro]

nvdi.pal is used by XaAES by many people so it should be fine.

 

I'm not 100% sure about this but are you sure that the palette file contains RGB values and not the VDI ones (0 - 1000, IIRC) ? 

[+Spaced Cowboy]

8 hours ago, mikro said:

nvdi.pal is used by XaAES by many people so it should be fine.

Yep, I thought so too

 

8 hours ago, mikro said:

I'm not 100% sure about this but are you sure that the palette file contains RGB values and not the VDI ones (0 - 1000, IIRC) ? 

Oh it does, I was converting it to RGB 888:

int main(int argc, char **argv)
	{
	if (argc == 1)
		{
		fprintf(stderr, "Usage: pal2h <file.pal>\n");
		exit(-1);
		}
	
	FILE *fp = fopen(argv[1], "rb");
	if (fp == NULL)
		{
		fprintf(stderr, "Cannot open %s for read. Exiting.\n", argv[1]);
		exit(-2);
		}
	
	uint32_t magic;
	fread(&magic, 1, 4, fp);
	if (magic != '10AP')
		{
		fprintf(stderr, "%s is not a palette file. Exiting\n", argv[1]);
		exit(-3);
		}
	
	printf(
		"#ifndef _palette_header_\n"
		"#define _palette_header_\n"
		"/* Palette generated from %s */\n"
		"typedef struct\n"
		"	{\n"
		"	uint8_t r;\n"
		" 	uint8_t g;\n"
		"	uint8_t b;\n"
		"} RGB;\n\n"
		"typedef struct\n"
		"	{\n"
		" 	RGB rgb;\n"
		" 	uint8_t a;\n"
		"} RGBA;\n\n"
		"static RGB _palette[256] = {\n",
		argv[1]);
	
	for (int i=0; i<256; i++)
		{
		uint16_t rgb[3];
		fread(rgb, 6, 1, fp);
		for (int j=0; j<3; j++)
			rgb[j] = ntohs(rgb[j]);
		printf("\t/* %03d, 0x%02x */ {%d,%d,%d},\n", i, i,
			((int)rgb[0] * 255) / 1000,
			((int)rgb[1] * 255) / 1000,
			((int)rgb[2] * 255) / 1000
			);
		}
	printf("\t};\n"
		"#endif /* ! _palette_header_ */\n");
	
	}

 

The values I'm getting out *look* correct in terms of the maths (white is 255,255,255, black is 0,0,0,...) it was just whether the order was correct that I was thinking about. Which it probably is, of course. Just clutching at straws at this point...

 

Cheers

 

 

[mikro]

Maybe worth asking on atari-forum.com or FreeMiNT mailing list: https://sourceforge.net/p/freemint/mailman/freemint-discuss/.

Edited September 29, 2023 by mikro

[+Spaced Cowboy]

Thank you - advice on the mailing list did actually get me to a working state  

[+Spaced Cowboy]

Well, that's the first pass at a complete "TOS" version (ie: not NVDI 5 or Magic or any other newer stuff) of the VDI written in about a month as a client/server implementation using (in this case unix) sockets to communicate between the application and the display-server. Multiple clients should be able to connect simultaneously, giving a form of multi-tasking. 

 

Not that this looks at all impressive (actually, sort of the opposite of impressive ) but the below is a small selection of stuff that was rendered out by the test-app, just to make sure things at least semi-work...

 

 

What it does show are user-defined fill-patterns and line-styles, vro/vrt_cpyfm, writing modes, flood fill, text alignment, markers, outline text, and in my case the line styles etc. work as you up the width of the line, plus you have arbitrary text rotation  It seems a lot faster than my TT as well  

 

The next step will be to write a unit-test app that can be scripted to compare output of a "real" TOS (probably actually an emulator) vs the output of the current code for each of the display functions. Then it's on to the AES.... I'm only trying to match this all up to the 'C' level API, so not everything is a perfect fit (example: running vex_motv, you have to provide a C function, and the arguments to the function are the x,y co-ords, the values aren't passed in d0.w and d1.w), but it's pretty damn close, and good enough for my purposes.

 

 

[mikro]

It took me a while to grasp what is your project about, definitely one of the more unique things I have seen for our platform.

 

[Cyprian]

what a great project - the GEM on the XL.

I would buy that device.