[comp.os.msdos.programmer] Need a good line drawing function for VGA

teittinen@cc.helsinki.fi (03/14/91)

Hello!

I'm writing a program that draws red-blue stereopictures on the screen
and I have a problem. Now I probably should tell you that I'm writing
this program in TC++. Anyway, because I draw two pictures of the object
in different colors, I don't want either color to wipe the other out. So
I use XOR-mode for drawing the lines (setwritemode(1);). But now the
problem is that when two lines in one image overlap, the overlapping
part is erased. And this is not too rare, for I draw wire-frame images
of the objects.

So what I need is possibility to draw lines using OR-mode. But here I'm
unlucky, Borland doesn't give me chance to use OR-mode for drawing lines
(even though my VGA hardware can make it easily). I could implement this
feature myself, but when I implemented line drawing algorithm in C and
compiled it, it was 3 times slower than Borland library function (I
timed it with Profiler). And because I'm trying to do some animation
here, I'd need as fast routine as I can get.

I'm turning to you, my fellow programmers, and asking if anyone has
an assembler version of a suitable VGA line drawing function that he/she
could share with me. I'd be very grateful to get this function. Or is
there a suitable function in (gasp) Microsoft C, must I turn to them ?
Please, don't say so! I'll do (almost) anything but that :-)

-- 
E-Mail: teittinen@finuh.bitnet               ! "Studying is the only way
        teittinen@cc.helsinki.fi             !  to do nothing without
Marko Teittinen, student of computer science !  anyone blaming you" -me

mcdonald@aries.scs.uiuc.edu (Doug McDonald) (03/14/91)

In article <1991Mar14.020823.5530@cc.helsinki.fi> teittinen@cc.helsinki.fi writes:
>Hello!
>
>I'm writing a program that draws red-blue stereopictures on the screen
>and I have a problem. Now I probably should tell you that I'm writing
>this program in TC++. Anyway, because I draw two pictures of the object
>in different colors, I don't want either color to wipe the other out. So
>I use XOR-mode for drawing the lines (setwritemode(1);). But now the
>problem is that when two lines in one image overlap, the overlapping
>part is erased. And this is not too rare, for I draw wire-frame images
>of the objects.
>
>So what I need is possibility to draw lines using OR-mode. 


I posted a set of assembler routines to do EXACTLY what you wish to do
soem time ago. IT was called egafast and was posted to, I believe,
comp.sources.misc. It should still exist in the early archives of
that group. IF not, I can send it to you be e-mail.


You do what you want by noting that one bit plane controls red and another
one blue. You simply instruct the VGA (or EGA) controller to write 
to ONLY the red plane when doing red and ONLY the blue plane when doning
blue - then you can use either XOR or OR mode quite well.


Doug MCDonald 

nyet@nntp-server.caltech.edu (prof. n liu) (03/15/91)

mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes:


>You do what you want by noting that one bit plane controls red and another
>one blue. You simply instruct the VGA (or EGA) controller to write 
>to ONLY the red plane when doing red and ONLY the blue plane when doning
>blue - then you can use either XOR or OR mode quite well.

This should certainly work... and guess what? MSC does in fact have an OR mode
for all graphics, if you are lazy (and, of course, assuming you have MSC
around :). Which brings me to another point.. is there an equivalent "driver"
standard like .bgi for msc and code to load them, or do you have to do
everything yourself - like writing svga routines from scratch (and, of course
coding line drawing algorithms like Bresenham's manually). What a drag.

Also, (speaking of RB 3d), i wrote up an animation program that will spin
and move various figures in 3d with glasses. Its in MSC 6.00, but the source
is REAL long considering i cannabalized some graphics 3d rendering code
from a CS class. If there's suitable interest i could post, ul, or email it.
Actually, it runs pretty slow unless you have a 387 (lots of floating point
stuff). I haven't gotten around to redoing it with integer math. But on a
25MHz machine with a 20+MHz 387 it hauls pretty fast.

nyet

gershon%gr.utah.edu@cs.utah.edu (Elber Gershon) (03/15/91)

In article <1991Mar14.182134.1368@nntp-server.caltech.edu> nyet@nntp-server.caltech.edu (prof. n liu) writes:
>mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes:
>
>
>>You do what you want by noting that one bit plane controls red and another
>>one blue. You simply instruct the VGA (or EGA) controller to write 
>>to ONLY the red plane when doing red and ONLY the blue plane when doning
>>blue - then you can use either XOR or OR mode quite well.
>
>This should certainly work... and guess what? MSC does in fact have an OR mode
>for all graphics, if you are lazy (and, of course, assuming you have MSC
>around :). Which brings me to another point.. is there an equivalent "driver"
>standard like .bgi for msc and code to load them, or do you have to do
>everything yourself - like writing svga routines from scratch (and, of course
>coding line drawing algorithms like Bresenham's manually). What a drag.
>
>nyet

Gee. Correct me if I am wrong but what the original author really wanted is
the combined color to be magenta (i.e. both red and blue are active). OR
will not do it! Both OR and XOR will operate on the color INDICES and not
on the color RGB components. If for example red index is 1 and blue is 3
then OR will return 3 or again blue (convert the numbers to binary)! XOR
will return 2, so all needs to be done is: 'setrgbpallete(2, 63, 0, 63)' or
setting the color table second entry to the magenta color.

Gershon

P.S. This does not mean that pixel OR may not be useful and that I would not
     like to see the BGI protocol supporting it.