Re: [AD] Windowed drivers color conversion

["Eric Botcazou" <ebotcazou@xxxxxxxxxx>]

> Ok, cool! Now, the first thing we need is to get rid of that Win32 native
> parameter type; can you do it to accept different parameters?

Here's the direct translation into Standard C:

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)

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

> 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).

> 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 ?
- how many backbuffers do X and BeOs need in color conversion mode ?

> The function would also save the real screen line
> pointers in local module vars and return a blitter func that is aware of
> all this, and should be in the form:
>
> void _colconv_update_line_xx_to_yy(int line, int start_x, int end_x)

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

> These three functions should all be in a separated module IMO, and the
> windowed gfx drivers should take care about calling the line updater when
> needed, inside the driver line switching routines (as it already is in X
> and BeOS, don't know about Win32)

Same thing.

--
Eric Botcazou
ebotcazou@xxxxxxxxxx