Re: [AD] Windowed drivers color conversion

["Angelo Mottola" <a.mottola@xxxxxxxxxx>]

> struct UPDATE_RECT {
>    int width;      /* in pixels */
>    int height;     /* in pixels */
>    int pitch;       /* in bytes */
>    void *surface /* address of the start of the rectangle */
> }
>
> void _update_xx_to_xx(struct UPDATE_RECT *src_rect, struct UPDATE_RECT
> *dest_rect)
>

Hummm, ok, I've looked over the windowed Win32 gfx driver, and I think I've
understood how the color conversion works. Cool if you could modify the
update routine to accept that kind of structure and not a DDSURFACEDESC
structure...

> The width and height fields of dest_rect are actually not used by the
code.

Huh?? It seems these are actually used inside update.s, to know how many
lines to convert...

> > Also, I've not seen a set of functions to convert truecolor to paletted
> > pixels... Have I missed something, or this type of conversion is not
> > supported by the asm code?
>
> Not supported at all. Same thing for 15-bit to every other color depth
(but
> color conversion to 15-bit is of course supported).

I don't think it'd be that hard to add 15bit support at this point.
Truecolor to palette would require much more work, and I'm a bit lost in it
currently, so maybe this is a job for Michael or Peter, who coded the X and
BeOS drivers (that support also this kind of conversion).

> > BLITTER_FUNC *_colconv_init(screen bitmap, pitch, allegro depth, real
> > depth) void _colconv_exit()
> >
> > The first would check if conversion is needed (depths differ), and if
not,
> > return NULL immediately. If they differ, a new internal temp bitmap is
> > allocated of the specified depth, and the screen bitmap being created
> > (this function is meant to be called inside the gfx driver init code)
> > would be altered to make its line pointers to point to the new temp
bitmap
> > lines (of the wanted depth).
>
> I'm a little lost:
> - what's exactly the 'screen bitmap' ? Does it wrap the actual screen
(video
> memory) or is it already a backbuffer ?

It depends. On QNX I think I can make it to point directly to the real
display RAM. But on BeOS and X that is another buffer of the same depth as
the real display. When you use putpixel() on the screen, you actually work
on a memory buffer of the color depth you specified with set_color_depth().
The line switcher then does the color conversion from this buffer onto
another buffer that's of the same depth as the real screen, and that is
system dependent (it's an XImage under X if I'm right). Later the system
updates the window taking data from this system dependent buffer, clipping
the displayed region as needed (taking care of window overlapping, etc.);
how this is done is OS-dependent and it's not relevant here.

humm, now I think the init routine I proposed doesn't really fit in this
scheme at all... What do you suggest to make an unique API?

> - how many backbuffers do X and BeOs need in color conversion mode ?

One of the depth specified by set_color_depth.
Another of the real screen depth (but this is still not the real displayed
video RAM)

> Not very efficient: the overhead per line would be far too high. The asm
> code is optimized for multi-line conversion.

One point for you =)

--
Angelo Mottola
a.mottola@xxxxxxxxxx
http://www.ecplusplus.com