Subject:
|
Re: LDGLite 1.0
|
Newsgroups:
|
lugnet.cad.dev.mac
|
Date:
|
Sat, 9 Aug 2003 01:39:22 GMT
|
Viewed:
|
1355 times
|
| |
|
|
In article <HJAzuG.18DA@lugnet.com>,
"Don Heyse" <dheyse@hotmail.spam.go.away.com> wrote:
> 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?
At screen resolution 1024x768, 32bit, issuing the following command
./ldglite100 -le -v800,600 mini.dat puts up the following window
http://users.rcn.com/cjmasi/before-moving.png (terminal reports ATi drivers)
moving the window (not resizing just moving) changes the contents to
white (terminal says nothing about drivers). Issuing a command that
causes the model to be redrawn finally gives the window with the model
in it, and the terminal reports the Apple Drivers are loaded.
Also interesting, if I do a "pagedown" to select different bricks, the
gray box with 4 lines appears, and the selected bricks appear and
disappear as I go through the model, but the model doesn't appear until
I do something that causes it to be redrawn
[Don's comment below refers to the terminal readout that reports a
driver switch that occurs when moving the window and redrawing the
model.]
> 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?
[I moved this, because my original post refered back to this problem,
and the organization was getting confusing.]
No, just clicking in the window or on the window bar doesn't do
anything. I have to move the window (which empties the window of its
contents), and then issue a command that causes the model to be redrawn
(a rotate will do). More intersting observations. The window that
appears initially is actually a combination of a scrambled terminal
window (black and green due to my terminal setting) and the last LDGLite
(-le mode) window. If I try to rotate the model, I get the same garbled
terminal, but the model is now the model view from the second to last
time the program was run. I can keep ping-ponging the model views by
mouse dragging, putting the window behing this one (the one I am typing
in), and then reactivating the window.
> 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.
OK
> > > 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.
[snip appearance change in -LE mode]
> 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.
Downloading the source now, I'll give it a try tonight (not that I know
what I am doing mind you).
> > > 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.
(Still talking 16bit colors here)
Hm... the -n2 and -n4 didn't do anything, but... doing ./ldgledit -v5
mini.dat causes the the Apple Generic driver to load immediately after
the ATi driver loads, and rotation is done without the flickering
original image. If however, I do ./ldgledit -v1024,740 mini.dat, the ATi
driver loads and the window goes to heck, until the window moves and the
model is redrawn, and then everything works fine. So, the culprit may be
the ATi drivers again.
So, with a 32bit color depth ATi drivers cause funky colors to appear
with screen resolutions >800,537. With a 16bit color depth, the ATi
drivers cause the the ghost rotation problem, and when resolutions are
pushed high enough, the screen drawning problems.
By the way, lauching ldglite in viewing mode ( ./ldglite100 -v3
mini.dat) at 16bit colors does not cause flickering. The ATi driver
losed, but the whole model rotates (dog slow :) but it rotates. At
higher resolutions (./ldglite100 -v1024,740 mini.dat still at 16bit)
the screen goes to hell until the window is moved and the model is
manipulated.
Doing ./ldglite100 -v3 -l3 mini.dat also works fine (16bit color
still). Rotation is done in block mode (fast) and there is no flicker.
In 32bit colors the same behavior is seen as noted before (funky colors
until the window is moved and the the model redrawn).
Chris
PS I'll be in Westfield full time starting Monday. I have been trying to
get ready for classes from home (classes start Sept 2), but I have been
"fixing" my other laptop instead. I'll have e-mail access, AIM, and cell
phone access (whenever I leave my bunker of an office, 0 signal in my
office) if we want to set something up. There is another AFOL joining
the faculty at Westfield, maybe I could find out if he is on campus yet.
|
|
Message has 1 Reply:
 | | Re: LDGLite 1.0
|
| (...) Ah yes, I see the problem. Since I didn't really expect the driver to actually report a change, I neglected to call the glutPostRedisplay() function, so it won't do a full refresh until you do something that makes it redraw. I'll fix that one (...) (21 years ago, 9-Aug-03, to lugnet.cad.dev.mac)
|
Message is in Reply To:
| | Re: LDGLite 1.0
|
| (...) 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... (...) That's interesting. It sounds like I *can* query the driver during a reshape and find out (...) (21 years ago, 8-Aug-03, to lugnet.cad.dev.mac)
|
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
|
|
|
|
