Ok, bryan... time to take lesson #53 If you are running XGS/32 in 16bit color mode, there is the chance that the colors may not match exactly, and here is why... Dos int10, mode 13h, offers a 320x200 *pallette* based color lookup scheme. Each pixel on the screen is ONE byte, which is an index into the pallette, that stores 256 24bit pallette entries. So, you have a 320x200 screen, and a 768 byte pallette table. In theory, on any one screen, you can have a maximum of 256 distinct colors out of a possible pallette of 2^24 (16,xxx,xxx... whatever). Under XGS/32, choosing 24 bit color (sometimes 32, but the high order byte is unused), allows a direct mapping from the typical IIgs color to true RGB color, which means that the colors *should* match accordingly. However, 16 bit mode is a little different. There are usually two available modes for 16 bit color. They are known as R5G5B5 and R5G6B5. The first option uses 5 bits for each color value. Notice in the int10/13h mode, each color value is 8 bits wide. This means that the color has to be resampled, thus reducing color precision in order to fit into the allocated space of 5 bits. The second option uses 5 bits for the red and blue, but *6* bits of color for the green to fill the entire 16 bits. This is a bit trickier, as RGB values are balanced, meaning that if you increase the precision of any element, resampling will alter the balance, resulting in colors that are "slightly different". Think of it this way. If you take a song off a cd, and make an mp3 of it, it is compressing the audio using "lossy" compression. While the song may sound the same, there *are* differences that the ear cannot perceive. However, with color, the eyes are very sensitive. Small adjustments required to compress the color values into 16 bit wide fields results in a "lossy compression", resulting in minor differences in visible color. There is nothing you can do to fix it. If you run XGS/32 in 24 bit color mode, all these problems go away, as the color map between the real IIgs and the emulated one is the same. HOWEVER: If the IIgs video DAC applied its own signal and color hues, saturation, etc to the signal, as a result of the conversion to RGB, the colors will still be different, and this is a hardware difference, not software. "Bryan Parkoff" wrote in message news:5iidnSNQWNFe1dWjXTWQlg@giganews.com... > You may be surprised that exact color does not look the same. For > example, BIOS Video shows 16 out of 256 colors on 320x200 resolution that it > only uses 13h on INT 10h. DirectX 7-9 shows 16 out of 16,777,216 colors on > either 320x200 resolution and 640x480 resolution. Blue color is little > bright in BIOS Video than DirectX. Please explain why. > Try to compare XGS-DOS and XGS-Win32. You will notice that the colors > are not the same. XGS-DOS is the exact same as real Apple IIgs. The > problem is that XGS-Win32 makes exact color little darker. You use 16-bit > color that will show little dark blue color, but you use 24-bit color that > will show darker blue color than 16-bit color. You can notice why it is the > difference between 16-bit and 24-bit colors. > Do you have idea how to improve color-looking that should match the SAME > color between 16-bit and 24-bit? Or..should we change RGB function to > match? I always complain about the color problem, but XGS-DOS is much > better. Is it true that 16,777,216 is the maximum for colors? I have heard > that it may be billion color than 16.7 million color. > Is there a way that we can program Apple II Emulator to match real Apple > IIgs color? Or...should we add RGB scale/scroll in this emulator that it > allows the users to modify RGB scale/scroll that will cause the color to > change. Please adsvise.... > > -- > Yours Truly, > > Bryan Parkoff > BParkoff@satx.rr.com > >