To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.cad.devOpen lugnet.cad.dev in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 CAD / Development / 10798
Subject: 
Re: LPub 4 Status
Newsgroups: 
lugnet.cad.dev
Date: 
Sun, 20 Apr 2008 22:51:25 GMT
Viewed: 
13517 times
  
In lugnet.cad.dev, Travis Cobbs wrote:
   In lugnet.cad.dev, Don Heyse wrote:
   Kevin, if you want to test it I put a beta of just the executable here.

Apparently this is working for others, but when I run it (on an original MacBook in OS 10.4), all I get is a bus error. Did you compile it as a Leopard app?

Err, I rushed it and sorta botched the build. So a few files got built with no PPC code. I rebuilt it, but didn’t get a chance to borrow an older machine to test it on yet.

Hey, maybe (probably) you know this. What’s involved in supporting a G3, or say OS 10.3? I don’t know my way around the compiler switches well enough yet to turn off altivec or use the older libraries.

Don


Subject: 
Re: LPub 4 Status
Newsgroups: 
lugnet.cad.dev
Date: 
Mon, 21 Apr 2008 02:26:28 GMT
Viewed: 
13712 times
  
In lugnet.cad.dev, Don Heyse wrote:
   Err, I rushed it and sorta botched the build. So a few files got built with no PPC code. I rebuilt it, but didn’t get a chance to borrow an older machine to test it on yet.

Actually, I don’t have a PPC Mac, just the previous OS version. I believe that if you don’t get everything right for the “universal” stuff, it will give you an error at link time. I know that’s what it does to me if any of the libraries aren’t universal and I try to do a universal build.


   Hey, maybe (probably) you know this. What’s involved in supporting a G3, or say OS 10.3? I don’t know my way around the compiler switches well enough yet to turn off altivec or use the older libraries.

No idea. I know how to set up the OS setting in XCode, but I don’t know off-hand even how to do that in a Makefile.

--Travis


Subject: 
Re: LPub 4 Status
Newsgroups: 
lugnet.cad.dev
Date: 
Mon, 21 Apr 2008 14:26:11 GMT
Viewed: 
13670 times
  
In lugnet.cad.dev, Travis Cobbs wrote:
   In lugnet.cad.dev, Don Heyse wrote:
   Err, I rushed it and sorta botched the build. So a few files got built with no PPC code. I rebuilt it, but didn’t get a chance to borrow an older machine to test it on yet.

Actually, I don’t have a PPC Mac, just the previous OS version.

That’s interesting. I built it on a new laptop with the version of XCode that comes with leopard. However I just added the arch targets to the old makefile (but missed one of the libraries). So I guess the default is to target leopard only. I suppose I should try to build from an XCode project and see if it’s easier to target older OS versions and CPUs with that.

   I believe that if you don’t get everything right for the “universal” stuff, it will give you an error at link time. I know that’s what it does to me if any of the libraries aren’t universal and I try to do a universal build.

It let me link in an X86 only lib without an error. Maybe there was a warning, I didn’t pay too much attention. I can imagine reasons why you *might* want a special lib that’s only called from the X86 code.

  
   Hey, maybe (probably) you know this. What’s involved in supporting a G3, or say OS 10.3? I don’t know my way around the compiler switches well enough yet to turn off altivec or use the older libraries.

No idea. I know how to set up the OS setting in XCode, but I don’t know off-hand even how to do that in a Makefile.

I found some documentation, but I printed it and don’t have it on hand right now. It sure looks easier to do from the XCode gui though.

So what’s the oldest, junkiest Mac that’s known to run the LDView executable?

Don


Subject: 
Re: LPub 4 Status
Newsgroups: 
lugnet.cad.dev
Date: 
Mon, 21 Apr 2008 16:30:24 GMT
Viewed: 
13746 times
  
In lugnet.cad.dev, Don Heyse wrote:
   So what’s the oldest, junkiest Mac that’s known to run the LDView executable?

No idea. Whatever it is, it needs Tiger, though, since LDView is built to require Tiger. It presumably needs a G4.

--Travis


Subject: 
Re: LPub 4 Status
Newsgroups: 
lugnet.cad.dev
Date: 
Mon, 21 Apr 2008 19:52:11 GMT
Viewed: 
13825 times
  
In lugnet.cad.dev, Travis Cobbs wrote:
   In lugnet.cad.dev, Don Heyse wrote:
   So what’s the oldest, junkiest Mac that’s known to run the LDView executable?

No idea. Whatever it is, it needs Tiger, though, since LDView is built to require Tiger. It presumably needs a G4.

For what it’s worth, Tiger will run on a 300 MHz G3. While it certainly wasn’t fast, I don’t recall ever encountering any software that simply said “I need a G4”. That’s not to say there’s no reason why such software couldn’t or shouldn’t exist, of course.

Jim


Subject: 
Re: LPub 4 Status
Newsgroups: 
lugnet.cad.dev
Date: 
Wed, 23 Apr 2008 19:20:14 GMT
Viewed: 
14000 times
  
In lugnet.cad.dev, Don Heyse wrote:
   In lugnet.cad.dev, Travis Cobbs wrote:
   In lugnet.cad.dev, Don Heyse wrote:
   Err, I rushed it and sorta botched the build. So a few files got built with no PPC code. I rebuilt it, but didn’t get a chance to borrow an older machine to test it on yet.

Actually, I don’t have a PPC Mac, just the previous OS version.

That’s interesting. I built it on a new laptop with the version of XCode that comes with leopard. However I just added the arch targets to the old makefile (but missed one of the libraries). So I guess the default is to target leopard only. I suppose I should try to build from an XCode project and see if it’s easier to target older OS versions and CPUs with that.

   I believe that if you don’t get everything right for the “universal” stuff, it will give you an error at link time. I know that’s what it does to me if any of the libraries aren’t universal and I try to do a universal build.

It let me link in an X86 only lib without an error. Maybe there was a warning, I didn’t pay too much attention. I can imagine reasons why you *might* want a special lib that’s only called from the X86 code.

  
   Hey, maybe (probably) you know this. What’s involved in supporting a G3, or say OS 10.3? I don’t know my way around the compiler switches well enough yet to turn off altivec or use the older libraries.

No idea. I know how to set up the OS setting in XCode, but I don’t know off-hand even how to do that in a Makefile.

I found some documentation, but I printed it and don’t have it on hand right now. It sure looks easier to do from the XCode gui though.

Since I already lost this once, I’m gonna stash it here just in case. To compile something that runs on Tiger from a makefile on Leopard add this:

CFLAGS+= -mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk

LDFLAGS+= -isysroot /Developer/SDKs/MacOSX10.4u.sdk

That should make it build and run with the older Tiger sdk and libs. Add -arch i386 -arch ppc and I should be able to make a universal binary for 10.4 and up. (I hope)

Don


Subject: 
Re: LPub 4 Status
Newsgroups: 
lugnet.cad.dev
Date: 
Wed, 23 Apr 2008 19:30:48 GMT
Viewed: 
13976 times
  
In lugnet.cad.dev, Don Heyse wrote:
   Since I already lost this once, I’m gonna stash it here just in case. To compile something that runs on Tiger from a makefile on Leopard add this:

Good idea.


   CFLAGS+= -mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk

LDFLAGS+= -isysroot /Developer/SDKs/MacOSX10.4u.sdk

That should make it build and run with the older Tiger sdk and libs. Add -arch i386 -arch ppc and I should be able to make a universal binary for 10.4 and up. (I hope)

I’ll be happy to be your Tiger test subject, but I can only test Intel.

--Travis


Subject: 
Re: LPub 4 Status
Newsgroups: 
lugnet.cad.dev
Date: 
Wed, 23 Apr 2008 23:41:14 GMT
Viewed: 
13960 times
  
In lugnet.cad.dev, Travis Cobbs wrote:
   In lugnet.cad.dev, Don Heyse wrote:
   Since I already lost this once, I’m gonna stash it here just in case. To compile something that runs on Tiger from a makefile on Leopard add this:

Good idea.


   CFLAGS+= -mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk

LDFLAGS+= -isysroot /Developer/SDKs/MacOSX10.4u.sdk

That should make it build and run with the older Tiger sdk and libs. Add -arch i386 -arch ppc and I should be able to make a universal binary for 10.4 and up. (I hope)

I’ll be happy to be your Tiger test subject, but I can only test Intel.

Ok, give this one a try.


Subject: 
Re: LPub 4 Status
Newsgroups: 
lugnet.cad.dev
Date: 
Thu, 24 Apr 2008 02:45:06 GMT
Viewed: 
14157 times
  
In lugnet.cad.dev, Don Heyse wrote:
   Ok, give this one a try.

That one works for LPub. The buffer isn’t getting flushed to the screen right. I have to resize or force a redraw in order. Are you calling CGLFlushDrawable at the end of your drawing code?

--Travis


Subject: 
Re: LPub 4 Status
Newsgroups: 
lugnet.cad.dev
Date: 
Thu, 24 Apr 2008 13:57:56 GMT
Viewed: 
14577 times
  
In lugnet.cad.dev, Travis Cobbs wrote:
In lugnet.cad.dev, Don Heyse wrote:
Ok, give http://ldglite.sf.net/ldgliteosx1_2_1beta2.zip a try.

That one works for LPub.  The buffer isn't getting flushed to the screen
right. I have to resize or force a redraw in order.  Are you calling
CGLFlushDrawable at the end of your drawing code?

No, I use glfinish().  I've had all sorts of problems over the years
with Apple because I often render in the front buffer to emulate
the various ancient ldlite immediate rendering modes.  Does it update
ok when you spin the model with the mouse?  I think that's pure back
buffer rendering (at least until you're done spinning).  What about using
-n4 on the command line?  That's the ldlite command to render the whole
thing before displaying it.  It looks like I forced that mode when the gl
render string contains "RADEON 7000", so I must have had problems with
that one too.  Really, at this point I should probably give up rendering
in the front buffer except perhaps for editing mode and maybe for the
slow software renderers.

What does ldglite print for GL_VENDOR and GL_RENDERER?

Don


Subject: 
Re: LPub 4 Status
Newsgroups: 
lugnet.cad.dev
Date: 
Tue, 29 Apr 2008 13:49:50 GMT
Viewed: 
14428 times
  
In lugnet.cad.dev, Don Heyse wrote:
In lugnet.cad.dev, Travis Cobbs wrote:
In lugnet.cad.dev, Don Heyse wrote:
Ok, give http://ldglite.sf.net/ldgliteosx1_2_1beta2.zip a try.

That one works for LPub.  The buffer isn't getting flushed to the screen
right. I have to resize or force a redraw in order.  Are you calling
CGLFlushDrawable at the end of your drawing code?

No, I use glfinish().  I've had all sorts of problems over the years
with Apple because I often render in the front buffer to emulate
the various ancient ldlite immediate rendering modes.  Does it update
ok when you spin the model with the mouse?  I think that's pure back
buffer rendering (at least until you're done spinning).  What about using
-n4 on the command line?  That's the ldlite command to render the whole
thing before displaying it.  It looks like I forced that mode when the gl
render string contains "RADEON 7000", so I must have had problems with
that one too.  Really, at this point I should probably give up rendering
in the front buffer except perhaps for editing mode and maybe for the
slow software renderers.

What does ldglite print for GL_VENDOR and GL_RENDERER?

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.

Now I just need to fix the display bugs on some systems.  I'm guessing
they use ATI chips, but it'd be nice to know for sure.  It'd also be nice
to know if the -n4 arg makes it better, because if so I'll make that the default
moving forward.

Don


Subject: 
Re: LPub 4 Status
Newsgroups: 
lugnet.cad.dev
Date: 
Tue, 29 Apr 2008 16:59:01 GMT
Viewed: 
14329 times
  
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.

Sorry for not responding, but I didn't remember to look at it while I was at
home.  I'll try to do so tonight.


Now I just need to fix the display bugs on some systems.  I'm guessing
they use ATI chips, but it'd be nice to know for sure.  It'd also be nice
to know if the -n4 arg makes it better, because if so I'll make that the default
moving forward.

Actually, my Intel MacBook (one of the original ones) has Intel motherboard
graphics.  Probably a different model than yours, but Intel nonetheless.

--Travis


Subject: 
Re: LPub 4 Status
Newsgroups: 
lugnet.cad.dev
Date: 
Wed, 30 Apr 2008 02:14:59 GMT
Viewed: 
14422 times
  
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

--Travis


Subject: 
Re: LPub 4 Status
Newsgroups: 
lugnet.cad.dev
Date: 
Wed, 30 Apr 2008 03:22:54 GMT
Viewed: 
14539 times
  
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


Subject: 
Re: LPub 4 Status
Newsgroups: 
lugnet.cad.dev
Date: 
Thu, 1 May 2008 02:15:50 GMT
Viewed: 
15923 times
  
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


Subject: 
Re: LPub 4 Status
Newsgroups: 
lugnet.cad.dev
Date: 
Thu, 1 May 2008 14:41:20 GMT
Viewed: 
16162 times
  
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


Subject: 
Re: LPub 4 Status
Newsgroups: 
lugnet.cad.dev
Date: 
Thu, 1 May 2008 17:36:23 GMT
Viewed: 
16279 times
  
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


Subject: 
Re: LPub 4 Status
Newsgroups: 
lugnet.cad.dev
Date: 
Thu, 1 May 2008 18:12:26 GMT
Viewed: 
16307 times
  
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


Subject: 
Re: LPub 4 Status
Newsgroups: 
lugnet.cad.dev
Date: 
Sat, 3 May 2008 03:02:03 GMT
Viewed: 
16436 times
  
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


Subject: 
Re: LPub 4 Status
Newsgroups: 
lugnet.cad.dev
Date: 
Sat, 3 May 2008 14:52:22 GMT
Viewed: 
16372 times
  
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


Subject: 
Re: LPub 4 Status
Newsgroups: 
lugnet.cad.dev
Date: 
Sat, 3 May 2008 21:13:49 GMT
Viewed: 
16878 times
  
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


©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR