Subject:
|
Re: LDGLite 1.0
|
Newsgroups:
|
lugnet.cad.dev.mac
|
Date:
|
Fri, 8 Aug 2003 13:51:52 GMT
|
Viewed:
|
2451 times
|
| |
|
|
In lugnet.cad.dev.mac, Tom Bozzo wrote:
> In lugnet.cad.dev.mac, Christopher Masi wrote:
> > Congratulations on the 1.0 release.
Thanks, but it sounds like the congrats are a bit premature at this
point. Oh well, I guess I can live with 1.0.1 or 1.0.2 or 1.0.99 or
whatever...
> > At 800,600 (32bit colors) resolution the ATi driver loads, and then
> > LDGLite switches to the Apple driver (the window behavior and the
> > printout from the terminal is included below) after the window is
> > manipulated. Anyway to get it to switch right away would be very
> > cool.
That's interesting. It sounds like I *can* query the driver during a
reshape and find out if it's changed. What a relief! Do you actually
have to change the shape or size of the window, or just move it?
I don't think I can make it switch myself without resorting to Mac
specific function calls. It'll be a while before I'm ready to do that
though.
> > No more trail lines in when moving a piece in -LE mode. I did
> > manage to get trail lines during rotation---they went away at the
> > end of the rotation---but I haven't been able to reproduce it.
That's probably because I draw everything but the selected part
in the GL_BACK buffer during rotation. I'll have to think about
how to handle that.
> > However, the model's appearance changes---the transparent
> > pieces look different---when the model is manipulated. See the
> > pictures below
> > Model before brick movement
> > http://users.rcn.com/cjmasi/-LE,-v3,32bit,before-edit.png
> >
> > model after brick movent and rotation (I hit 9 key again to get the same
> > view)
> > http://users.rcn.com/cjmasi/-LE,-v3,32bit,after_edit,after_view_change.png
>
> Chris (and Don),
>
> I can reproduce this. It appears that changing between standard
> views after editing (not necessarily spinning) will do it. The
> behavior is actually different for me with the Apple OpenGL versus
> ATI. With Apple, the trans color just disappears, like Chris's
> pictures. With ATI, a pattern shows up in the trans color while
> spinning, as in the following image (trans-neon green 2x1 plate in
> center, also note the 43722/3 wedge plates' outlines don't disappear
> when spinning in the filled-box mode):
>
> <<file:///Users/tombozzo/Desktop/Picture5.jpg>>
Hmmm, I don't seem to have direct access to files on your desktop... :^)
However, I think I may have the answer. Apparently the glPixelStore()
functions may be left in an abnormal state by the partial color buffer
restores required to move a part. Try adding this to the end of the
rendersetup() function in main.c
glPixelStorei(GL_UNPACK_ALIGNMENT,1);
glPixelStorei(GL_UNPACK_ROW_LENGTH,0);
glPixelStorei(GL_UNPACK_SKIP_ROWS, 0);
glPixelStorei(GL_UNPACK_SKIP_PIXELS, 0);
And what the heck, add this as well:
glPixelStorei(GL_PACK_ALIGNMENT,1);
glPixelStorei(GL_PACK_ROW_LENGTH,0);
glPixelStorei(GL_PACK_SKIP_ROWS,0);
glPixelStorei(GL_PACK_SKIP_PIXELS,0);
Maybe that'll fix it up.
> > I also noticed at 16bit colors the rotation problem appears to be that
> > the original view, the view of the model before begining rotation,
> > fickers as the model rotates beneath it. (I know, stop using 16bit
> > mode.. I just couldn't help it:)
I think this is another artifact of the GL_FRONT buffer problem on the
Macs. Don't know why it's different in 16 bit mode. Perhaps it's
because it has enough memory to allocate the triple buffered mode I
saw mentioned in some of the descriptions of this problem. I suspect
the only way to fix this is to completely abandon writing in the front
buffer. Can you try -n2 on the commandline (see the readme.txt file)
to see if it fixes this? If not, how about -n4 instead? These are
supposed to make it render in the back buffer instead. However I
think they only work when you're not in LEDIT mode.
> > ./ldglite100 -LE -v800,600 mini.dat
> > GL_VERSION = 1.1 ATI-1.2.22
> > [...]
> > GL_VENDOR ='ATI Technologies Inc.'
> > GL_RENDERER ='ATi Rage 128 Pro OpenGL Engine'
> > GL_RGBA_BITS: (8, 8, 8, 8)
> > GL_DEPTH_BITS = 24
> > GL_STENCIL_BITS = 8
> > Buffer Swap Mode = 0
> > Editing mode = 1{1}
> >
> > LDGLite starts up with a jumbled window.
> > Grab window bar and move window. Window turns white, and nothing appears.
> > Press a view button (like 2) and terminal says
> >
> > GL_VERSION = 1.1 APPLE-1.1
> > [...]
> > GL_VENDOR ='Apple'
> > GL_RENDERER ='Generic'
> > GL_RGBA_BITS: (8, 8, 8, 8)
> > GL_DEPTH_BITS = 32
> > GL_STENCIL_BITS = 8
> > Stencil buffer disabled for XOR with Apple driver.
> > Buffer Swap Mode = 0
> >
> > and the model appears.
That's weird. It sounds like GLUT doesn't call the reshape callback function
(which prints the GL_*** messages) until after you do something. Is this just
a question of window focus? Can you click in the window with the mouse or on
the title bar to get it to fix itself up?
Don
|
|
Message has 1 Reply:
 | | Re: LDGLite 1.0
|
| (...) At screen resolution 1024x768, 32bit, issuing the following command ./ldglite100 -le -v800,600 mini.dat puts up the following window (URL) (terminal reports ATi drivers) moving the window (not resizing just moving) changes the contents to (...) (21 years ago, 9-Aug-03, to lugnet.cad.dev.mac)
|
Message is in Reply To:
| | Re: LDGLite 1.0
|
| (...) Chris (and Don), I can reproduce this. It appears that changing between standard views after editing (not necessarily spinning) will do it. The behavior is actually different for me with the Apple OpenGL versus ATI. With Apple, the trans color (...) (21 years ago, 8-Aug-03, to lugnet.cad.dev.mac, FTX)
|
6 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
