Do bitblt function codes work?

Do bitblt function codes work?

[Amos]

It works!  It seems that from documentation point of view, at least,
it would have been better if bitblt() were the only function which had
an Fcode parameter.

Thanks much anyway,

-- 
	Amos Shapir		Net: amos@nsof.co.il
Paper: nSOF Parallel Software, Ltd.
       Givat-Hashlosha 48800, Israel
Tel: +972 3 9388551   Fax: +972 3 9388552        GEO: 34 55 15 E / 32 05 52 N

Do bitblt function codes work?

[dhog]

amos@nsof.co.il (Amos Shapir) writes:
>> This is correct behavior.  Since you're drawing the line with code 
>> 		segment(d, Pt(mid.x, r.min.y), Pt(mid.x, r.max.y), ~0, t);
>> using drawing function 0<=t<=15, you might expect 16 different
>> results.  But since the source function is the constant ~0, not a general
>> value, symmetries fold up and the number of results is reduced.
>> The possible answers are 0->0, 0->1, 1->0, and 1->1.  It is not
>> the full matrix of possibilities because the source is a single value (1).
>
>I have read this comment, and gather that this behavior is a feature;
>but I still can't see the rationale behind it.  How can the "value"
>parameter be anything but a constant?

It can be any constant you like.

>I tried all values, and I still can't find any combination that ANDs
>the pixel values of two bitmaps; e.g. in the given example, draw just
>the part of the segment which falls within the disc.

That's because segment() just draws a line.  It doesn't ``draw a bitmap''.
What you should be doing is drawing the line and the disc into separate
bitmaps (the screen can be one of them) and using bitblt() to combine
them.  Try changing your code thus:

25,26c25,27
< 		segment(d, Pt(mid.x, r.min.y), Pt(mid.x, r.max.y), ~0, t);
< 		bitblt(&screen, r.min, d, r, S);
---
> 		bitblt(&screen, r.min, &screen, r, Zero);		/* clear screen */
> 		segment(&screen, Pt(mid.x, r.min.y), Pt(mid.x, r.max.y), ~0, S);
> 		bitblt(&screen, r.min, d, r, t);

You should now see 16 distinct images, including the one you're after (at t == D&S).

Do bitblt function codes work?

[Amos]

In your message of Thu, 21 Dec 1995 08:53:56 GMT you wrote:

> > From: nsof.co.IL!amos (Amos Shapir)

> > On a PC with vga and "out of the box" drivers, the following program
> > generates only 4 distinct images, not 16.  It seems somewhere along
> > the line to/from the bitblt server, the lower two bits of the function
> > codes get hardwired to (binary)10.

> This is correct behavior.  Since you're drawing the line with code 
> 		segment(d, Pt(mid.x, r.min.y), Pt(mid.x, r.max.y), ~0, t);
> using drawing function 0<=t<=15, you might expect 16 different
> results.  But since the source function is the constant ~0, not a general
> value, symmetries fold up and the number of results is reduced.
> The possible answers are 0->0, 0->1, 1->0, and 1->1.  It is not
> the full matrix of possibilities because the source is a single value (1).

> For related information, see the comment in /sys/src/libgnot/gsegment.c.

I have read this comment, and gather that this behavior is a feature;
but I still can't see the rationale behind it.  How can the "value"
parameter be anything but a constant?

I tried all values, and I still can't find any combination that ANDs
the pixel values of two bitmaps; e.g. in the given example, draw just
the part of the segment which falls within the disc.

Happy new year, anyway
	Amos Shapir		Net: amos@nsof.co.il
Paper: nSOF Parallel Software, Ltd.
       Givat-Hashlosha 48800, Israel
Tel: +972 3 9388551   Fax: +972 3 9388552        GEO: 34 55 15 E / 32 05 52 N

Do bitblt function codes work?

[Rob]

> From: nsof.co.IL!amos (Amos Shapir)

> On a PC with vga and "out of the box" drivers, the following program
> generates only 4 distinct images, not 16.  It seems somewhere along
> the line to/from the bitblt server, the lower two bits of the function
> codes get hardwired to (binary)10.

This is correct behavior.  Since you're drawing the line with code 
		segment(d, Pt(mid.x, r.min.y), Pt(mid.x, r.max.y), ~0, t);
using drawing function 0<=t<=15, you might expect 16 different
results.  But since the source function is the constant ~0, not a general
value, symmetries fold up and the number of results is reduced.
The possible answers are 0->0, 0->1, 1->0, and 1->1.  It is not
the full matrix of possibilities because the source is a single value (1).

For related information, see the comment in /sys/src/libgnot/gsegment.c.

-rob