bmacintyre@watsol.waterloo.edu (Blair MacIntyre) (01/28/88)
I have recently started a three-d fly-down-the-tunnel type game ( for
the fun of it ). As anyone who has ever done three-d anything knows,
this requires a lot of line clipping after the three to two-d
transformation. I was under the impression that the layers library
would handle this, but ...
when I get line that go very far off screen, the line drawing routines
behave very strangly ( I first thought it was the program, but when
I wrote my own clipping routine, everything started working ).
The strange behaviour was as follows:
- draw a line from point a to point b, both onscreen. ok.
- draw a line from point c to point b, with point c far of to the
lower left of the screen ( ie. large +y, large -x ).
- the line drawn:
- does not connect with point b. It connects corrently in the
x direction, but they values are off.
- is not even a line. The result is a jagged series of vertical and
sloped connected line segments.
Anyone seen anything like this? Is the layers library supposed to handle
this offscreen clipping? Or, if I have to continue to clip myself, does
anyone have a very efficient clipping algorithm?
Help!!
Thanx in advance,
Blair
===========================================================================
|\ /| .Oop Ack Thppft!
{o O} . bmacintyre@watsol
(")
U I haven't decided if I even HAVE an opinion, but if I do I'll be sure
to ask my employer if it represents his ...
( I doubt it though, I'm only a co-op student! )cmcmanis%pepper@Sun.COM (Chuck McManis) (01/29/88)
In article <3060@watcgl.waterloo.edu> (Blair MacIntyre) writes: > - draw a line from point c to point b, with point c far of to the > lower left of the screen ( ie. large +y, large -x ). I have seen similar problems. And they *always* relate to negative co-ordinates. I went back to doing some of my own clipping stuff. You don't mention it but are you rendering through the window's RastPort (clipped) or the Screen's RastPort (unclipped) ? --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
haitex@pnet01.cts.com (Wade Bickel) (01/29/88)
bmacintyre@watsol.waterloo.edu (Blair MacIntyre) writes: > >I have recently started a three-d fly-down-the-tunnel type game ( for >the fun of it ). As anyone who has ever done three-d anything knows, >this requires a lot of line clipping after the three to two-d >transformation. I was under the impression that the layers library >would handle this, but ... > when I get line that go very far off screen, the line drawing routines >behave very strangly ( I first thought it was the program, but when >I wrote my own clipping routine, everything started working ). >The strange behaviour was as follows: > - draw a line from point a to point b, both onscreen. ok. > - draw a line from point c to point b, with point c far of to the > lower left of the screen ( ie. large +y, large -x ). > - the line drawn: > - does not connect with point b. It connects corrently in the > x direction, but they values are off. > - is not even a line. The result is a jagged series of vertical and > sloped connected line segments. > >Anyone seen anything like this? Is the layers library supposed to handle >this offscreen clipping? Or, if I have to continue to clip myself, does >anyone have a very efficient clipping algorithm? > >Help!! If you are calculatating perspectives, I recently posted an article to comp.sys.graphics on this topic. Basically, I recommend that you do your own clipping. First clip in z before translating from 3-D to 2-D. Then translate to 2-d, and then clip in x and y. X and y clipping tends to be a special case which can be optimized according to needs. I tryed using the Layers Lib, but it seemed to do more of some things and not enough of others for my needs. Thanks, Wade. UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex ARPA: crash!pnet01!haitex@nosc.mil INET: haitex@pnet01.CTS.COM
bmacintyre@watsol.waterloo.edu (Blair MacIntyre) (01/29/88)
In article <40369@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: >In article <3060@watcgl.waterloo.edu> (Blair MacIntyre) writes: >> - draw a line from point c to point b, with point c far of to the >> lower left of the screen ( ie. large +y, large -x ). > >I have seen similar problems. And they *always* relate to negative >co-ordinates. I went back to doing some of my own clipping stuff. You >don't mention it but are you rendering through the window's RastPort >(clipped) or the Screen's RastPort (unclipped) ? Sorry, forgot that. I'm was using the window's rastport. Now I'm using the screens Rastport ( since I'm doing my own clipping - I read somewhere the screen's rastport is quicker because it doesn't do any clipping ... is this true? ) ps. anyone have any particular things they would like to see in a shell ( I'm toying with the idea of writing one ). Email me any thoughts. Thanx. -- |\ /| .Oop Ack Thppft! {o O} . bmacintyre@watsol (") ( I haven't decided if I even HAVE an opinion, but if I do I'll be sure U to ask my boss what he thinks of it ... )
cunniff@hpfclq.HP.COM (Ross Cunniff) (01/29/88)
In article <3060@watcgl.waterloo.edu>, bmacintyre@watsol.waterloo.edu (Blair MacIntyre) writes: > when I get line that go very far off screen, the line drawing routines > behave very strangly ( I first thought it was the program, but when > I wrote my own clipping routine, everything started working ). It is my understanding that the layers library has problems handling coordinates with a magnitude greather than 4096. > Thanx in advance, You're welcome, in retrospect. > Blair Ross Cunniff Hewlett-Packard System Software Operation ...{ucbvax,hplabs}!hpda!cunniff cunniff%hpda@hplabs.ARPA
cs178abu@sdcc8.ucsd.EDU (John Schultz) (02/03/88)
Yes, drawing to a rastport is faster than drawing to a window. (a big time noticeable difference). John
steveb@cbmvax.UUCP (Steve Beats) (02/03/88)
In article <780@sdcc8.ucsd.EDU> cs178abu@sdcc8.ucsd.edu.UUCP (John Schultz) writes: > > Yes, drawing to a rastport is faster than drawing to a window. (a >big time noticeable difference). > John I think you meant to say that drawing into a screens RastPort is faster than drawing into a Windows RastPort. This is true. Screen RastPorts don't have any layer info attached so no clipping is performed. Steve
cs178abu@sdcc8.ucsd.EDU (John Schultz) (02/04/88)
In article <3258@cbmvax.UUCP> steveb@cbmvax.UUCP (Steve Beats) writes: >In article <780@sdcc8.ucsd.EDU> cs178abu@sdcc8.ucsd.edu.UUCP (John Schultz) writes: >> Yes, drawing to a rastport is faster than drawing to a window. (a >>big time noticeable difference). >> John >I think you meant to say that drawing into a screens RastPort is faster than >drawing into a Windows RastPort. This is true. Screen RastPorts don't have >any layer info attached so no clipping is performed. > > Steve ...and drawing to your own View/ViewPort/RastPort is the fastest, but non-intuition compatible (not directly). The things we do for speed... John