[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] XaAES sources for FreeMiNT 1.16.3
howsit Johan
On Mon, Dec 7, 2009 at 7:33 PM, Johan Klockars <johan@klockars.net> wrote:
>> 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).
>
sound like a good time to use "vq_scrninfo()." What are its impact for
non-fVDI's
>> 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.
this is the kernel, so "standard" SpareMint Libs used to compile MiNT
code:
if (screen.planes > 8)
{
MFDB scr, dst;
struct rgb_1000 srgb, rgb;
short pxy[8];
union { unsigned short w[64]; unsigned long l[32];} b;
(*v->api->wr_mode)(v, MD_REPLACE);
(*v->api->l_type)(v, 1);
(*v->api->l_ends)(v, 0, 0);
(*v->api->l_width)(v, 1);
vq_color(v->handle, 0, 1, (short *)&srgb);
// display("saved %04d, %04d, %04d", srgb.red, srgb.green, srgb.blue);
rgb.red = 1000;
rgb.green = 1000;
rgb.blue = 0;
vs_color(v->handle, 0, (short *)&rgb);
(*v->api->line)(v, 0, 0, 0, 0, 0);
scr.fd_addr = NULL;
dst.fd_addr = &b;
dst.fd_w = 1;
dst.fd_h = 1;
dst.fd_wdwidth = 1;
dst.fd_stand = 1;
dst.fd_nplanes = screen.planes;
dst.fd_r1 = dst.fd_r2 = dst.fd_r3 = 0;
pxy[0] = 0;
pxy[1] = 0;
pxy[2] = 0;
pxy[3] = 0;
pxy[4] = 0;
pxy[5] = 0;
pxy[6] = 0;
pxy[7] = 0;
vro_cpyfm(v->handle, S_ONLY, pxy, &scr, &dst);
vs_color(v->handle, 0, (short *)&srgb);
switch (screen.planes)
{
> 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.
>
or is it "shifted" or intel-ish
> 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?
>
There have been a number of checks, and (atm) XaAES does not have any
difference.
This might explain why it is apparently on happening on certain ARAnyM
"platforms" running 1.17, ie mintara.prg
this suggest to me possibly kernel related, other wise there would be
a wider report.
I seriously lean toward this idea, simply because current builds of
MiNT & XaAES (1.17) are not usable in ARAnyM.
I have used the AFROS Live CD on a couple of machines, all this the
same result. NOTE: none of those machine were running NVidia cards
(modern). But at the same time, if only MiNT+XaAES are swapped for
v1.16.3 (not emutos or fvdi) ther is no problem.
I can see that it wont be fixed until more people are affected by it,
atm anyway, or until someone takes the time to "debug it".
It show that there should be a better way to detect the pixel format,
and after discussions on this thread (and others), I looked at using
Lonny's suggested algorithm. But the source shows no practical results
from this.
Note, the source above confirms 1.17 on ARAnyM can use 256 color mode
correctly, if for no other reason that it cant fail the test..
BTW I get E0E000 for red+green
Again, how does use of "vq_scrninfo()" in XaAES impact on MiNT when
used with other VDI's. XaAES is going through some upgrades and bug
fixes right now, enough to warrant a beta release, so it can be
slotted in.
On a side note, if you were provided with a list of fVDI fixes for
XaAES are you able to check and fix any issues fVDI atm?
Paul