Re: [MiNT] XaAES sources for FreeMiNT 1.16.3

[Johan Klockars <johan@klockars.net>]

> XaAES does this:
>
> In detect_pixel_format a colored line is drawn (red 1000, green 1000, blue
> 0). Then the pixel at x=0 of that line is read with vro_cpyfm and the
> word/long at that place is examined to get to know the pixel-format.

That's one way to do it which may often work, if implemented correctly.
But only trying maximum colour values does not tell you order of the
individual bits, which may not always be what you expect.

I don't understand why no one ever seems to use vq_scrninfo(). If it
has problems on some hardware, that should be easy to patch. Applying
patches once, in one place, is certainly better than having every
application doing it's own kind of detection code (often less than
perfect).

> In 16 bit-depth the value on cygwin-aranym is EF40 which is in bits:
>
> 1110 1111  0100 000

So, it looks like we might have 11101 for the red value, and 11101 for green.

> So, if the above is correct: what are the bits for red/green/blue?
>
> If I use (1000,0,1000) I get:
>
> E81D, which gives
>
> 1110 1000  0001 1101

Again, 11101 for red, and now 11101 for blue (with one apparently
unused bit before the latter).

> and with (0,1000,1000)
>
> 075D, which gives
>
> 000 0111  0101 1101

11101 green and 11101 blue (unused bit between them).
(You missed a zero at the beginning.)

> All this says to me is that red must have more bits than green and blue.

No. You have five bits each for red, green and blue. With bit 5
(between green and blue) seemingly unused.

However, the real problem is that you keep getting 11101 rather than
11111 for what should be maximum colour values.

> Maybe the fvdi-source can tell, did not look yet.

I would be surprised if fVDI or the ARAnyM fVDI driver managed to turn
11111 into 11101, but I suppose it is possible. Depending on what
method is used to write to the actual screen (SDL? OpenGL?), the
problem might be there as well.
For that matter, I suppose it is possible that the hardware only uses
four bits per colour component (skipping one bit), but that is
unlikely.


If I've interpreted later messages in this thread correctly, the
problem supposedly goes away when using an earlier MiNT kernel. To me
that sounds very strange, especially considering what we're seeing
here.
Or was there perhaps different code in XaAES as well when using the
earlier kernel?

/Johan