mg@cidam.me.rmit.oz.AU ("Mike A. Gigante") (05/08/89)
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
tarolli@dragon.SGI.COM (Gary Tarolli) (05/09/89)
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....