|
In lugnet.cad.dev, Travis Cobbs wrote:
> In lugnet.cad.dev, Don Heyse wrote:
> > Sorry about the self reply, but now I'm really curious about this.
> > I found myself an old G4 EMac with a Geforce2 and OSX Tiger for testing
> > and everything worked ok. It also worked on an Intel Macbook with
> > the Intel GMA X3100 graphics. So I guess that means I've got the
> > universal binary build process down.
>
> Here's my info:
>
> Vendor: Intel Inc.
> Renderer: Intel GMA 950 OpenGL Engine
> Version: 1.2 APPLE-1.4.56
Hmmm, I guess that's slightly different from the GMA X3100, which
seemed to work for me. If you get a chance, try and run it with
-n4 on the command line. That should render everything in the back
buffer like 99.99% of the opengl programs out there.
Thanks again,
Don
|
|
|
In lugnet.cad.dev, Don Heyse wrote:
> Hmmm, I guess that's slightly different from the GMA X3100, which
> seemed to work for me. If you get a chance, try and run it with
> -n4 on the command line. That should render everything in the back
> buffer like 99.99% of the opengl programs out there.
The -n4 didn't have any noticeable effect. What exactly does n4 mean. I know
it means "draw to back buffer", but what does the n and the 4 mean?
--Travis
|
|
|
In lugnet.cad.dev, Travis Cobbs wrote:
> In lugnet.cad.dev, Don Heyse wrote:
> > Hmmm, I guess that's slightly different from the GMA X3100, which
> > seemed to work for me. If you get a chance, try and run it with
> > -n4 on the command line. That should render everything in the back
> > buffer like 99.99% of the opengl programs out there.
>
> The -n4 didn't have any noticeable effect.
Arrgh, that's not good. It worked for me whenever I had a problem
like that. I guess I'll have to use the OSX flush function. Are
you by chance using partially transparent windows, or something
fancy like that?
> What exactly does n4 mean. I know it means "draw to back buffer",
> but what does the n and the 4 mean?
It's hooked to an ldlite variable that tracks what level is
being rendered (P=1, Part=2, Model=4, Other=8). Don't ask me what
other means. I think this was documented with the 2.4 release notes
for ldlite, but I lost track of that. I posted the ldlite 2.3
release notes as the ldlite sourceforge web page at some point, but
that doesn't mention it. So I suppose it's possible that I made the
whole thing up myself 6 years ago, but my memory from that time is
gone now.
Have fun,
Don
|
|
|
In lugnet.cad.dev, Don Heyse wrote:
> In lugnet.cad.dev, Travis Cobbs wrote:
> > The -n4 didn't have any noticeable effect.
>
> Arrgh, that's not good. It worked for me whenever I had a problem
> like that. I guess I'll have to use the OSX flush function. Are
> you by chance using partially transparent windows, or something
> fancy like that?
Nope. It starts out partially under my dock, which I keep on the left. I can't
remember if I ever moved it completely out from under the dock or not, but I'm
pretty sure I did. (As a note, I looked around, and it appears that
HIWindowGetAvailablePositioningBounds is the Carbon API to use to avoid
overlapping the Dock; GLUT REALLY should use that automatically when you ask it
for a maximized window.)
--Travis
|
|
|
In lugnet.cad.dev, Travis Cobbs wrote:
> In lugnet.cad.dev, Don Heyse wrote:
> > In lugnet.cad.dev, Travis Cobbs wrote:
> > > The -n4 didn't have any noticeable effect.
> >
> > Arrgh, that's not good. It worked for me whenever I had a problem
> > like that. I guess I'll have to use the OSX flush function. Are
> > you by chance using partially transparent windows, or something
> > fancy like that?
>
> Nope. It starts out partially under my dock, which I keep on the left.
> I can't remember if I ever moved it completely out from under the dock
> or not, but I'm pretty sure I did. (As a note, I looked around, and it
> appears that HIWindowGetAvailablePositioningBounds is the Carbon API
> to use to avoid overlapping the Dock; GLUT REALLY should use that
> automatically when you ask it for a maximized window.)
Hmmm, a partially obscured window. Sounds like a clue. I'll have to
run some tests with a side mounted dock on the G4. And I should probably
look back and see what I did on windows when the annoying popup tooltips
were driving me nuts.
Thanks,
Don
|
|
|
In lugnet.cad.dev, Don Heyse wrote:
> Hmmm, a partially obscured window. Sounds like a clue. I'll have to
> run some tests with a side mounted dock on the G4. And I should probably
> look back and see what I did on windows when the annoying popup tooltips
> were driving me nuts.
Well, I pulled the window out from under the dock, and that didn't help. On an
unrelated note, why will it only open models in the current directory? If I
give the full path to a model in a different directory, it fails to load it.
--Travis
|
|
|
In lugnet.cad.dev, Travis Cobbs wrote:
> In lugnet.cad.dev, Don Heyse wrote:
> > Hmmm, a partially obscured window. Sounds like a clue. I'll have to
> > run some tests with a side mounted dock on the G4. And I should probably
> > look back and see what I did on windows when the annoying popup tooltips
> > were driving me nuts.
>
> Well, I pulled the window out from under the dock, and that didn't help.
Yeah, but the hint helped me. With the side mounted dock I was able
to reproduce the problem (or a problem at least) on the G4. I cleaned up
some of the buffer swapping and window reshaping code, and it seems
to work better for me now. Of course I seem to be moving further and
further away from glut with every fix. Oh well. If you want, you could
try out this one and see if it's better on your system.
http://ldglite.sf.net/ldgliteosx1_2_3beta5.zip
> On an unrelated note, why will it only open models in the current
> directory? If I give the full path to a model in a different directory,
> it fails to load it.
I've started looking into that. It does the same thing on linux, I think.
I suspect I broke that a while ago when I added some code on Windows to
find the path to the executable in order to run lddesignpad plugins.
It's been a long time since I did much testing on anything but windows.
Have fun,
Don
|
|
|
In lugnet.cad.dev, Don Heyse wrote:
> Yeah, but the hint helped me. With the side mounted dock I was able
> to reproduce the problem (or a problem at least) on the G4. I cleaned up
> some of the buffer swapping and window reshaping code, and it seems
> to work better for me now. Of course I seem to be moving further and
> further away from glut with every fix. Oh well. If you want, you could
> try out this one and see if it's better on your system.
>
> http://ldglite.sf.net/ldgliteosx1_2_3beta5.zip
Yep, that fixed it.
--Travis
|
|
|