Re: [MiNT] XaAES: detect pixel-format-problem

[Paul Wratt <paul.wratt@gmail.com>]

On Tue, Dec 1, 2009 at 8:54 PM, Lonny Pursell <atari@bright.net> wrote:
>
> Pick some vdi pen, you have 256 to choose from in TC modes, lets say pen 1.
> Save the contents of pen 1
> Save the pixel at 0,0 -> v_get_pixel()
> Set pen 1 to full red
> Plot pixel 0,0 with pen 1
> Now blit 0,0 to a private buffer, to avoid any peeking into screen ram
> Now locate the 8 bits, you now have the location of the red component
> You can note the amount of shift, and offset , etc
> Repeat the process for green, but set the pen color to full green
> Same for blue...
> Put pen 1 back as it was
> Restore the pixel you overwrote
>
thanks, I will run something up.

> I also have some test apps somewhere that detect the mode, and display all
> sorts of technical bits, like planes, bits per component, shift amounts,
> offset etc, and even draws some tests using direct screen writes to see if I
> detected it correctly.  The drawing code uses the shift offsets and such
> that it gathered during detection.
>
those test apps might be useful for testing atm. Do you have a 1.17 XaAES issue?

> I palette based modes, planes 8 or less you do need to do it differently and
> I can't recall how I did it without looking at my code.  But typically 8
> planes is usually chunky mode on video cards/clones so it needs to be
> detected.  My Hades is this way.
>
atm "chunky" is beyond me, but I know there is lots of docs and plenty
of explanations (isn't planar the other format?)

On this note, the pixel format issue does NOT affect 256 color mode or
any other indexed palette mode (???), not even in 1.17. the only thing
(maybe) related to this, is when it "vr_transform"s the texture in
256, it comes back as 16 color..

Paul