| |
In lugnet.cad.dev, Allen Smith wrote:
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
| |
In PLI’s, LPub displays the parts color name (from LDConfig), the part
number (yes, even on the Mac version Allan!), and the part title. Currently
I get these titles from PARTS.LST, but that is not sufficient, and it is a
short sighted implementation.
|
Is PARTS.LST the file that gets generated by some DOS utility in the original
LDraw distribution? You can’t rely on that being present. Not being able to
rely on a DOS utility, Bricksmith reads the part library and generates its
own XML parts list; I assume other programs do something similar.
|
As will LPub before it is made available to the public. Thus the comment about
short sighted. Now that I have an example on what to do, I’ll implement that
instead. There is one class that will have to be changed, and no one else needs
to know the difference.
| |
| |
I got a Mac mini yesterday, so I’m at the bottom of the learning curve on
getting LPub going there. I know it is unix (which I know very well), but I
did not find make or the gcc tools (which I also know very well) using find.
I’m antsy to get going there. Any ideas on where to get started?
|
Congratulations! This is wonderful news for Mac LDraw users. I have fielded
numerous requests asking for an instruction-generation tool in Bricksmith,
and I’ve always been ashamed to respond that there isn’t one, never will be,
and the process of doing it manually is probably too hard for them to figure
out. I eagerly anticipate being able to direct people to a real solution.
Thanks for making the capital investment to support us!
|
It turns out that I get an employee discount through work, even though I don’t
work for Apple. Who could resist?
Now, if someone would make a platform independent editor, we’d be in fantastic
shape!
| |
As others have noted, in order to get the developer tools on your Mac, you
need to install the Xcode Tools package. It is found somewhere on your Mac OS
installer DVD. That installs the gcc toolchain, Apple’s graphical IDE, and
lots of other stuff.
Allen
|
I’m grateful for all the help.
I’ve gotten LPub to build successfully, and am working on interfacing to
renderers. On vidoze I used ldglite originally on LPub 4, and all was well.
Don Heyse had added some features to ldglite to make it easier for LPub to work
with, by adding some of the L3P camera lens and positioning options, and getting
it to render offscreen. Today, the Mac version of ldglite does not have these
features.
LPub 2 supports LDView, which I hadn’t gotten around to doing with LPub 4 until
last night. Travis was nice enough to make the L3P camera command line option
changes to LDView a few years back. I’ve not got LDView and LPub 4 working well
on the Mac yet, but that will be just a matter of debug time.
I’m very excited.
Kevin
|
|
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
| |
I’ve gotten LPub to build successfully, and am working on interfacing to
renderers. On vidoze I used ldglite originally on LPub 4, and all was well.
Don Heyse had added some features to ldglite to make it easier for LPub to
work with, by adding some of the L3P camera lens and positioning options, and
getting it to render offscreen. Today, the Mac version of ldglite does not
have these features.
|
Yeah, gotta work on that... But hey, the kids just got a macbook! And, as
of yesterday, it has a sneaky ssh login just for me so I can soak up some of the
idle cycles from across the living room.
But...my notes on libpng for OS-X are about 5 years old. Is
this the current recommended way to
get it? If so, what does the code patch do? Is the patch still needed? I ran
the script without patching and was able to build an executable with the
resulting libpng, but I didn’t actually try the png functions yet, because...
I haven’t fetched the LDRAW parts library yet. So what’s the best way to
get the parts for the Mac -- With bricksmith? In ldview? Straight from
ldraw.org? -- and where do you folks put the LDRAWDIR on the MAC these days?
Have fun,
Don
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
| |
But...my notes on libpng for OS-X are about 5 years old. Is
this the current recommended way
to get it? If so, what does the code patch do? Is the patch still needed?
I ran the script without patching and was able to build an executable with
the resulting libpng, but I didn’t actually try the png functions yet,
because...
|
How about I send you a universal binary of a static libpng? (If I remember
correctly, it was a real pain to make.)
| |
I haven’t fetched the LDRAW parts library yet. So what’s the best way to
get the parts for the Mac -- With bricksmith? In ldview? Straight from
ldraw.org? -- and where do you folks put the LDRAWDIR on the MAC these days?
|
I think I got mine via BrickSmith, which is kind of sad, really, but I just
checked, and LDView will happily download the official library on the Mac if you
just run it and open its sample file.
--Travis
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
| |
I haven’t fetched the LDRAW parts library yet. So what’s the best way to
get the parts for the Mac -- With bricksmith? In ldview?
|
One of those.
No. They don’t distribute the full library; you would have to merge together all
the updates with the original LDraw DOS package. Not fun.
| |
and where do you folks put the LDRAWDIR on the MAC these days?
|
Wherever you want it. If Bricksmith is installed, you can find out where the
LDraw folder is by issuing the following terminal command:
defaults read com.AllenSmith.Bricksmith “LDraw Path”
On Bricksmith’s first launch, it automatically searches in /Applications,
/Library, ~/Library, and directories relative to Bricksmith.app itself
(which is where it usually finds it).
Allen
|
|
| |
In lugnet.cad.dev, Travis Cobbs wrote:
| |
How about I send you a universal binary of a static libpng? (If I remember
correctly, it was a real pain to make.)
| |
I haven’t fetched the LDRAW parts library yet. So what’s the best way to
get the parts for the Mac -- With bricksmith? In ldview? Straight from
ldraw.org? -- and where do you folks put the LDRAWDIR on the MAC these days?
|
I think I got mine via BrickSmith, which is kind of sad, really, but I just
checked, and LDView will happily download the official library on the Mac if
you just run it and open its sample file.
|
Thanks guys for all the help. I grabbed BrickSmith and moved the ldraw
folder that came with it to /Library. I wanted both anyhow so it seemed
to be the way to go. Then I built a new (universal?) ldglite with your
static libpng and some patches to render offscreen via the carbon fns. It
didn’t work from an ssh login (carbon is forbidden), but when I logged
locally I got a png file without opening a graphics window. Cool!
Kevin, if you want to test it I put a beta of just the executable
here.
Enjoy,
Don
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
| |
In lugnet.cad.dev, Travis Cobbs wrote:
| |
How about I send you a universal binary of a static libpng? (If I remember
correctly, it was a real pain to make.)
| |
I haven’t fetched the LDRAW parts library yet. So what’s the best way to
get the parts for the Mac -- With bricksmith? In ldview? Straight from
ldraw.org? -- and where do you folks put the LDRAWDIR on the MAC these
days?
|
I think I got mine via BrickSmith, which is kind of sad, really, but I just
checked, and LDView will happily download the official library on the Mac if
you just run it and open its sample file.
|
Thanks guys for all the help. I grabbed BrickSmith and moved the ldraw
folder that came with it to /Library. I wanted both anyhow so it seemed
to be the way to go. Then I built a new (universal?) ldglite with your
static libpng and some patches to render offscreen via the carbon fns. It
didn’t work from an ssh login (carbon is forbidden), but when I logged
locally I got a png file without opening a graphics window. Cool!
Kevin, if you want to test it I put a beta of just the executable
here.
Enjoy,
Don
|
Hi Don,
It worked!
Now I just have to figure out how to get my main menu and popup menus to work
on the Mac from Qt!
Thanks!
Kevin
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
| |
to be the way to go. Then I built a new (universal?) ldglite with your
static libpng and some patches to render offscreen via the carbon fns. It
didn’t work from an ssh login (carbon is forbidden), but when I logged
locally I got a png file without opening a graphics window. Cool!
|
If you used my code as an example for Core GL setup, then the error was due to a
bug in my code. If not, put the following in your CGLPixelFormatAttribute
array, and it should work even via ssh:
CGLPixelFormatAttribute attrs[] =
{
kCGLPFADepthSize, (CGLPixelFormatAttribute)24,
kCGLPFAColorSize, (CGLPixelFormatAttribute)24,
kCGLPFAAlphaSize, (CGLPixelFormatAttribute)8,
kCGLPFAStencilSize, (CGLPixelFormatAttribute)8,
kCGLPFAAccelerated,
kCGLPFAPBuffer,
kCGLPFARemotePBuffer,
(CGLPixelFormatAttribute)0
};
The last setting (kCGLPFARemotePBuffer) is the important one for remote
rendering. Note, thought, that you don’t want that setting set when saving a
file from the UI. I suspect that you can skip the kCGLPFAAccelerated entry.
I updated LDView, and it now works fine remotely via ssh from an account
different than the logged in user (and probably when nobody is logged in; I
can’t test that right now).
--Travis
|
|
| |
In lugnet.cad.dev, Travis Cobbs wrote:
> In lugnet.cad.dev, Don Heyse wrote:
> > to be the way to go. Then I built a new (universal?) ldglite with your
> > static libpng and some patches to render offscreen via the carbon fns. It
> > didn't work from an ssh login (carbon is forbidden), but when I logged
> > locally I got a png file without opening a graphics window. Cool!
>
> If you used my code as an example for Core GL setup, then the error was due
> to a bug in my code. If not, put the following in your
> CGLPixelFormatAttribute array, and it should work even via ssh:
>
> | CGLPixelFormatAttribute attrs[] =
> | {
> | kCGLPFADepthSize, (CGLPixelFormatAttribute)24,
> | kCGLPFAColorSize, (CGLPixelFormatAttribute)24,
> | kCGLPFAAlphaSize, (CGLPixelFormatAttribute)8,
> | kCGLPFAStencilSize, (CGLPixelFormatAttribute)8,
> | kCGLPFAAccelerated,
> | kCGLPFAPBuffer,
> | kCGLPFARemotePBuffer,
> | (CGLPixelFormatAttribute)0
> | };
>
> The last setting (kCGLPFARemotePBuffer) is the important one for remote
> rendering. Note, thought, that you don't want that setting set when
> saving a file from the UI. I suspect that you can skip the
> kCGLPFAAccelerated entry.
>
> I updated LDView, and it now works fine remotely via ssh from an account
> different than the logged in user (and probably when nobody is logged in; I
> can't test that right now).
Actually it turned out that despite the warning message my settings
did work from a remote ssh login as a different user. The old AGL code,
while it worked locally (that was a surprise), did not work remotely and
produced the same warning message:
_RegisterApplication(), FAILED TO establish the default connection to the
WindowServer, _CGSDefaultConnection() is NULL.
When I searched for that I found some dev notes for daemon developnemt
that said carbon and opengl calls were not allowed for this sort of thing.
Since it warned me but still worked I wonder if this was more of a
problem with older versions of OS-X.
I took a peek at your code, but pbuffers make me nervous. I sorta
remember a Dev Connection table that showed them as unsupported on
some of the older Macs. (Like before 10.3)
So I skipped the pbuffer and went straight to ordinary offscreen
memory for the absolute lowest performance. ;-) I only use the stencil
buffer for editing mode, and I forgot to ask for alpha, but got it
anyhow with this setup:
CGLPixelFormatAttribute attribs[] = {
kCGLPFAOffScreen,
kCGLPFAColorSize, 32,
kCGLPFADepthSize, 32,
0};
Have fun,
Don
|
|
| |
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?
--Travis
|
|
| |
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
|
|
| |
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
|
|
| |
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
|
|
| |
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
|
|
| |
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
|
|
| |
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
|
|
| |
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
|
|
| |
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.
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
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
|
|
| |
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
|
|
| |
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
|
|
| |
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
|
|
| |
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
|
|
| |
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
|
|
|
