Subject:
|
Re: LDGLite 1.0
|
Newsgroups:
|
lugnet.cad.dev.mac
|
Date:
|
Sat, 9 Aug 2003 14:19:40 GMT
|
Viewed:
|
2103 times
|
| |
|
|
In lugnet.cad.dev.mac, Christopher Masi wrote:
> "Don Heyse" <dheyse@hotmail.spam.go.away.com> wrote:
> > 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
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 today.
> > Can you click in the window with the mouse or on
> > the title bar to get it to fix itself up?
>
> 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'll have to see that one to really understand it. Sounds like the
a death struggle in the ATI driver.
> (Still talking 16bit colors here)
> Hm... the -n2 and -n4 didn't do anything,
Probably because the odd GL_FRONT implementation. Tell me, do you get
to see the model draw itself like everyone else, or do you have to wait
until it's done, and then it suddenly pops up all finished. I'm talking
about non-LEDIT mode here (no -le or -LE):
ldglite -l3 -v(something) model.ldr
or
ldglite -l3 -n2 -v(something) model.ldr
> 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).
I can't keep keep this straight. I think it's time to start a table
of window sizes and their various problems on old OS X machines. I
could put it in the readme file so anyone who wants to use this knows
what to avoid. If it boils down to simply avoid the ATI driver, I
guess I'll be more motivated to dig up some Apple specific code to do
that.
> 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.
Cool. I'll send you my work email and maybe we can fix up some of
these driver issues during lunch, and perhaps even work on an NELUG west
kinda thing.
Don
|
|
Message is in Reply To:
 | | 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)
|
6 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
