Palettize colours?

[LLcooL]

[Phantom]

I think you should use a color cube (64Kb table containing the nearest match for every color to the palette) for this. That will cause cache problems, but I think it will be a lot better then using GetNearestColor.

[Digby]

Are you having to call that API on a per-frame basis?  I haven't seen the source to Lemmings, but you should really try to avoid that sort of thing and only use palette indices instead of RGB color values when running on palettized hardware.<br><br>

[Phantom]

I was thinking: Suppose we (I? ) make a version of EasyCE that supports palettized devices. It could be done like this: We start with a palette (I'll get to that in a moment). For each of the 65536 possible 16bit colors we look up the best match in the palette. When we need to display a 16bit image, all we have to do is lookup each 16bit color in this array to obtain a reasonable match in the table. The table is just 64Kb, so this could work.<br><br>The palette is determined 'sometimes', for example, when you just loaded a new level backdrop. The image is quantized, using an octree or whatever, so that a decent palette is generated that can be used to display that image in 8-bit mode. A call to 'generate_palette' or whatever should not take longer than 500ms or so.<br><br>This could work, and all apps could work just fine on 8-bit devices. EasyCE could start with a generic palette; apps can be optimized for 8-bit devices by just calling 'generate_palette' with the right timing.<br><br>Hm. Could be cool.

[Digby]

I think if there were enough 256-color devices out there that I wanted to support with my upcoming software, I'd write code that targetted the devices specifically instead of relying on a mapping function in a 3rd-party library.  With a palettized device I can move twice as much pixel data than with a 16-bpp device.  If I used your library my app would be using 16-bpp sprites and only able to move 2 pixels of data in one read/write.  Not to mention the overhead of doing the color conversion when the data gets to the display RAM.  <br><br>Some would argue that not every app needs to worry about performance issues like this.  I would counter that if that were the case with my app, then I would be using GDI and DIB sections instead of GAPI.<br><br>If you want to do something like this, write a private version of gx.dll that implements this scheme under the hood.  That way, you should be able to run games written for 16-bpp on a 256-color device as long as they respect GXIsDisplayDRAMBuffer and call GXEndDraw every frame (as every good GAPI app should).<br><br>