Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!sgi!tarolli@dragon.SGI.COM
From: tarolli@dragon.SGI.COM (Gary Tarolli)
Newsgroups: comp.sys.sgi
Subject: Re: getgpos()
Summary: getgpos answer
Message-ID: <32307@sgi.SGI.COM>
Date: 8 May 89 21:46:44 GMT
References: <8905080045.AA13626@uunet.uu.net>
Sender: daemon@sgi.SGI.COM
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 34

In article <8905080045.AA13626@uunet.uu.net>, mg@cidam.me.rmit.oz.AU ("Mike A. Gigante") writes:
> 
> 
> I have the following code fragment:
> 
> 	ortho(-14.0, 14.0, -14.0, 14.0)
> 	move2(-14.0, -14.0)
> 	....
> 	getgpos(&xw, &yw, &zw, &w)
> 
> the result is that xw = yw = w = -1.0, not -14.0 as I expected from
> the description of getgpos.
> 
> This is inside a library to supplement GL (actually it is the extra routines
> from GNU-digs to add hershey fonts etc) so I don't have access to the original
> calls to ortho etc.
> 
> I have got around the problem by recoding to use relative calls (rmv, rdr
> and so on) so that the answer is really for my curiosity...
> 
> Mike
> P.S. I am using a PI withfull graphics and FP options

In the getgpos(3G) man page, it says "getgpos returns the current graphics
position after transformation by the current matrix".  Ortho (and I hope you
meant ortho2 because ortho takes 6 parameters) loads the current transformation
matrix with a matrix that scales user space into Normalized Device Coords,
or -1 to 1.  That is why -14 ends up coming out as -1.

If you really want the current gpos in user coords, why not just save it
youself, with a MOVE(x,y,z) macro that saves the values in some global data.

If you are doing relative drawing, eg. a stroke font, then you are probably
best off with you relative drawing solution....