quesa-develop — Mailing list for Quesa development

[ quesa-Bugs-1227484 ] Add support for OpenGL display lists

[SourceForge.net <no...@so...>]

Bugs item #1227484, was opened at 2005-06-25 14:50
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=1227484&group_id=45158

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Sullivan (imikey)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add support for OpenGL display lists

Initial Comment:
Was discussed on the list with the following thoughts:

*****

James W. Walker wrote:

 > Yes, but if someone is updating a trimesh every frame (which 
isn"t  
 > an unreasonable expectation) you"ll be compiling a new display 
list  
 > every frame, which will certainly be slower than using the 
current  
 > vertex array path.
 
 I suppose some might do that, but it would not be a concern in 
my use  
 of Quesa.
 
 > To use display lists to their potential you need a geometry type  
 > that"s guaranteed never to change, or some sort of flag for  
 > existing geometries that allows you to declare them as "static"  
 > once their data is set.
 
 It would be easy enough to use an object property as a flag.

*****

Mikey wrote:

 >  To use display lists to their potential you need a
 >  geometry type that"s guaranteed never to change, or some 
sort of flag
 >  for existing geometries that allows you to declare them as 
"static"
 >  once their data is set.
 
 I would think that scenery such as ground terrain, trees, etc. 
would  
 be ideal for using this "static" flag and thus become eligible for  
 storage in display lists.  Furthermore, if all such objects had  
 normals computed for them, then perhaps OpenGL"s built-in 
backface  
 culling could be used when drawing them.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=1227484&group_id=45158

Re: Lights I/O

[Stefan H. <st...@to...>]

I've written two simple binary files with my app: one using QD3D and 
the other using Quesa (using your patch). Then I compared the 
viewhints (byte for byte).

In my case QD3D has written

Container
   ViewHints
   Container (view angle aspect camera...)
   Container (renderer...)
   Container (ambient light...)
   Container (direct light...)
   Container (attribute set...)
   ImageClearColor
   ImageDimensions

and Quesa:

Container
   ViewHints
   Container (view angle aspect camera...)
   Container (ambient light...)
   Container (direct light...)


Quesa currently seems to ignore certain parts. But the other parts 
are absolutely binary compatible with the QD3D output. The size of 
the main container has been correctly calculated.

But QD3D has not accepted the file. Then I copied the viewhints of 
the QD3D file into the Quesa file (Quesa geometry with QD3D 
viewhints): QD3D can read this.

It doesn't seem to be a container problem. Maybe QD3D wants the whole stuff...

Stefan



>I have modified my version of Quesa as Stephan requested but it 
>seems no better.
>If you would like to try it, in E3FFW_3DMFBin_Writer.c, line 542 reads:
>
>					qd3dStatus = 
>Q3Uns32_Write(instanceData->stack[i].objectType,theFile);
>
>If you change this (yes I know its a horrible way to do it) to:
>
>					{
>					if ( 
>instanceData->stack[i].objectType == kQ3LightData )
>						qd3dStatus = 
>Q3Uns32_Write ( kQ3ShapeTypeLight, theFile ) ; // To allow light 
>data objects to be read by QD3D
>					else
>						qd3dStatus = 
>Q3Uns32_Write(instanceData->stack[i].objectType,theFile);
>					}
>
>  Then this produces the requested data in the output file.
>
>I think the other problem may be that the light is in a 'container' 
>which QD3D does
>not expect, but I have no idea how to get rid of the container, it 
>seems everything
>in Quesa has to be in a container whether you want it or not.

Re: Lights I/O

[Roger H. <rog...@mi...>]

I have modified my version of Quesa as Stephan requested but it seems 
no better.
If you would like to try it, in E3FFW_3DMFBin_Writer.c, line 542 reads:

					qd3dStatus = 
Q3Uns32_Write(instanceData->stack[i].objectType,theFile);

If you change this (yes I know its a horrible way to do it) to:

					{
					if ( instanceData->stack[i].objectType == kQ3LightData )
						qd3dStatus = Q3Uns32_Write ( kQ3ShapeTypeLight, theFile ) ; // To 
allow light data objects to be read by QD3D
					else
						qd3dStatus = 
Q3Uns32_Write(instanceData->stack[i].objectType,theFile);
					}

  Then this produces the requested data in the output file.

I think the other problem may be that the light is in a 'container' 
which QD3D does
not expect, but I have no idea how to get rid of the container, it 
seems everything
in Quesa has to be in a container whether you want it or not.

Roger.



On 22 Jun, 2005, at 00:12, Stefan Huber wrote:

> I've found another compability problem: QD3D writes kQ3LightData as 
> 'lhgt' (it's ugly because kQ3ShapeTypeLight has the same value). Quesa 
> uses 'lida' internally to fix the QD3D issue. But then Quesa writes 
> 'lida' instead of 'lhgt'. So QD3D cannot read lights.
>
> Stefan
>
>> Thanks for the fault report and diagnosis.
>>
>> I have changed the writing code to write the lights rather than
>> have them in a light group. I have changed the reading code
>> so it can accept either format.
>>
>> I can now read old QD3D files which 1.28 could not read.
>>
>> Maybe we are not finished yet, but a step in the right direction.
>>
>> Roger.
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

Re: Lights I/O

[Stefan H. <st...@to...>]

I've found another compability problem: QD3D writes kQ3LightData as 
'lhgt' (it's ugly because kQ3ShapeTypeLight has the same value). 
Quesa uses 'lida' internally to fix the QD3D issue. But then Quesa 
writes 'lida' instead of 'lhgt'. So QD3D cannot read lights.

Stefan

>Thanks for the fault report and diagnosis.
>
>I have changed the writing code to write the lights rather than
>have them in a light group. I have changed the reading code
>so it can accept either format.
>
>I can now read old QD3D files which 1.28 could not read.
>
>Maybe we are not finished yet, but a step in the right direction.
>
>Roger.

Re: Windows version info

[Roger H. <rog...@mi...>]

I don't know much about "Windows" (though I know a lot about
walls, doors and windows) but looking at Quesa Viewer.res I
find at offset hex 2376 some weirdly formatted text saying
"ProductVersion 1, 5, 4, 9" . Alternate bytes are null but I guess
it would be easy to patch as long as you maintain the same
number of bytes and assuming there is not a sumcheck on
the entire file.

Roger.



On 21 Jun, 2005, at 19:01, Lane Roathe wrote:

> on Tue, Jun 21, 2005 Lars Jensen may have said:
>
>>>> The Quesa.dll file that comes with the version 1.7 download has
>>>> "1,5,4,9" in its Product Version and File Version strings on 
>>>> Windows.
>>>
>>> ...lately, I've been doing the Windows builds (using CodeWarrior) 
>>> and I
>>> don't know how to set those numbers.
>>
>> Alas, nor do I.
>
> These are set in the .rc file...although I do not see any such file in
> the CVS archive, only a .res file which is an unknown file format.
>
> What is the .res file? And why isn't there a .rc file?
>
> Lane Roathe
> President          Ideas From the Deep        <http://www.ifd.com>
> ___________________________________________________________________
> I am Pentium of Borg. Precision is futile. You will be approximated.
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

Re: Windows version info

[Lane R. <la...@if...>]

on Tue, Jun 21, 2005 Lars Jensen may have said:

>>> The Quesa.dll file that comes with the version 1.7 download has
>>> "1,5,4,9" in its Product Version and File Version strings on Windows.
>> 
>> ...lately, I've been doing the Windows builds (using CodeWarrior) and I
>> don't know how to set those numbers.
>
>Alas, nor do I.

These are set in the .rc file...although I do not see any such file in
the CVS archive, only a .res file which is an unknown file format.

What is the .res file? And why isn't there a .rc file?

Lane Roathe
President          Ideas From the Deep        <http://www.ifd.com>
___________________________________________________________________
I am Pentium of Borg. Precision is futile. You will be approximated.

Re: Windows version info

[Lars J. <lar...@rc...>]

>> The Quesa.dll file that comes with the version 1.7 download has
>> "1,5,4,9" in its Product Version and File Version strings on Windows.
> 
> ...lately, I've been doing the Windows builds (using CodeWarrior) and I
> don't know how to set those numbers.

Alas, nor do I.

lj

Re: Lights I/O

[Roger H. <rog...@mi...>]

Thanks for the fault report and diagnosis.

I have changed the writing code to write the lights rather than
have them in a light group. I have changed the reading code
so it can accept either format.

I can now read old QD3D files which 1.28 could not read.

Maybe we are not finished yet, but a step in the right direction.

Roger.

On 19 Jun, 2005, at 00:54, Stefan Huber wrote:

> I've found the light bug. viewhints should read/write the lights, not 
> the light group.
>
> In file E3IOData.c, e3viewhints_read we have to go back to version 
> 1.27 where the lights are collected in a light group first.
>
> The viewhints writer currently writes a light group, not lights.
>
> Stefan
>
>
>> Reading lights worked a few weeks ago. Now, when reading a QD3D 
>> generated file Q3ViewHints_GetLightGroup always returns NULL.
>>
>> When reading a Quesa generated file Q3ViewHints_GetAttributeSet 
>> returns NULL. The light group seems to be ok (I have to look in 
>> deeper).
>>
>> QD3D cannot read Quesa generated lights. My app simply crashes.
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

Re: Lights I/O

[Peter M. <pet...@mi...>]

Sorry, we just finished the writer code. If you can give more  
feedback on the issue, I can discuss it with Roger.

I have done a bit of testing with viewhints and they had seem to be  
working very well.

Cheers Peter.

P.S. does sourceforge cvs take 24 hours to update after a check-in?


On 19 Jun 2005, at 00:54, Stefan Huber wrote:

> I've found the light bug. viewhints should read/write the lights,  
> not the light group.
>
> In file E3IOData.c, e3viewhints_read we have to go back to version  
> 1.27 where the lights are collected in a light group first.
>
> The viewhints writer currently writes a light group, not lights.
>
> Stefan
>
>
>
>> Reading lights worked a few weeks ago. Now, when reading a QD3D  
>> generated file Q3ViewHints_GetLightGroup always returns NULL.
>>
>> When reading a Quesa generated file Q3ViewHints_GetAttributeSet  
>> returns NULL. The light group seems to be ok (I have to look in  
>> deeper).
>>
>> QD3D cannot read Quesa generated lights. My app simply crashes.
>>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

Re: Why no display lists in Quesa?

[James W. W. <os...@jw...>]

On Jun 19, 2005, at 12:16 AM, Frank Condello wrote:

> Yes, but if someone is updating a trimesh every frame (which isn't  
> an unreasonable expectation) you'll be compiling a new display list  
> every frame, which will certainly be slower than using the current  
> vertex array path.

I suppose some might do that, but it would not be a concern in my use  
of Quesa.

> To use display lists to their potential you need a geometry type  
> that's guaranteed never to change, or some sort of flag for  
> existing geometries that allows you to declare them as "static"  
> once their data is set.

It would be easy enough to use an object property as a flag.

Re: Why no display lists in Quesa?

[Mikey <im...@be...>]

On 2005-06-19 02:16, Frank Condello wrote:

>  To use display lists to their potential you need a
>  geometry type that"s guaranteed never to change, or some sort of flag
>  for existing geometries that allows you to declare them as "static"
>  once their data is set.

I would think that scenery such as ground terrain, trees, etc. would  
be ideal for using this "static" flag and thus become eligible for  
storage in display lists.  Furthermore, if all such objects had  
normals computed for them, then perhaps OpenGL's built-in backface  
culling could be used when drawing them.

- Mikey

Re: Why no display lists in Quesa?

[Frank C. <dev...@ch...>]

On 19-Jun-05, at 2:09 AM, James W. Walker wrote:

> On Jun 18, 2005, at 9:41 PM, Frank Condello wrote:
>
>> Another problem is that retained or not, no mesh is guaranteed to  
>> be static. Even if you track data locks/replacements there's no  
>> "safe" time to build and use a display list (even without software  
>> backface culling).
>
> When you say "mesh" here, are you speaking specifically of the Mesh  
> geometry, or do you use the word mesh in a more general sense?

Trimesh is what I meant (not sure its worth optimizing other types).

>   I usually use TriMesh geometries.  I would think that one could  
> invalidate a cached display list on Q3TriMesh_UnlockData and  
> Q3TriMest_SetData, and rebuild it just in time.

Yes, but if someone is updating a trimesh every frame (which isn't an  
unreasonable expectation) you'll be compiling a new display list  
every frame, which will certainly be slower than using the current  
vertex array path. To use display lists to their potential you need a  
geometry type that's guaranteed never to change, or some sort of flag  
for existing geometries that allows you to declare them as "static"  
once their data is set.

Frank.

Re: Why no display lists in Quesa?

[James W. W. <os...@jw...>]

On Jun 18, 2005, at 9:41 PM, Frank Condello wrote:

> Another problem is that retained or not, no mesh is guaranteed to  
> be static. Even if you track data locks/replacements there's no  
> "safe" time to build and use a display list (even without software  
> backface culling).

When you say "mesh" here, are you speaking specifically of the Mesh  
geometry, or do you use the word mesh in a more general sense?  I  
usually use TriMesh geometries.  I would think that one could  
invalidate a cached display list on Q3TriMesh_UnlockData and  
Q3TriMest_SetData, and rebuild it just in time.

Re: Why no display lists in Quesa?

[Frank C. <dev...@ch...>]

On 18-Jun-05, at 6:55 PM, James W. Walker wrote:

> On Jun 18, 2005, at 11:45 AM, Mikey wrote:
>
>> I've just been going thru the Quesa source code and I don't see  
>> any use of OpenGL display lists.  I'm surprised by this since that  
>> seems like it should be a relatively straight-forward optimization  
>> when using retained mode.
>
> That's a good question.  I can think of one design decision that  
> wouldn't be very compatible with display lists: Quesa does its own  
> backface culling.  You wouldn't want a display list that you'd have  
> to rebuild whenever you move the camera.
>
> The founder of the Quesa project, Dair Grant, is no longer  
> participating.  Anyone else know the history of this?

Another problem is that retained or not, no mesh is guaranteed to be  
static. Even if you track data locks/replacements there's no "safe"  
time to build and use a display list (even without software backface  
culling). The best you can do is use something like VAR or VBOs,  
cause you certainly don't want to go compiling a new display list  
every time something changes.

The pre-processing is a bigger bottleneck than the rendering though -  
There's gotta be a way to avoid stuff like software backface culling  
when using an interactive renderer...

Frank.

Re: Lights I/O

[Stefan H. <st...@to...>]

I've found the light bug. viewhints should read/write the lights, not 
the light group.

In file E3IOData.c, e3viewhints_read we have to go back to version 
1.27 where the lights are collected in a light group first.

The viewhints writer currently writes a light group, not lights.

Stefan


>Reading lights worked a few weeks ago. Now, when reading a QD3D 
>generated file Q3ViewHints_GetLightGroup always returns NULL.
>
>When reading a Quesa generated file Q3ViewHints_GetAttributeSet 
>returns NULL. The light group seems to be ok (I have to look in 
>deeper).
>
>QD3D cannot read Quesa generated lights. My app simply crashes.

Re: Why no display lists in Quesa?

[James W. W. <os...@jw...>]

On Jun 18, 2005, at 11:45 AM, Mikey wrote:

> I've just been going thru the Quesa source code and I don't see any  
> use of OpenGL display lists.  I'm surprised by this since that  
> seems like it should be a relatively straight-forward optimization  
> when using retained mode.

That's a good question.  I can think of one design decision that  
wouldn't be very compatible with display lists: Quesa does its own  
backface culling.  You wouldn't want a display list that you'd have  
to rebuild whenever you move the camera.

The founder of the Quesa project, Dair Grant, is no longer  
participating.  Anyone else know the history of this?

Why no display lists in Quesa?

[Mikey <im...@be...>]

I've just been going thru the Quesa source code and I don't see any  
use of OpenGL display lists.  I'm surprised by this since that seems  
like it should be a relatively straight-forward optimization when  
using retained mode.

Am I missing something?

- Mikey

Re: Windows version info

[James W. W. <os...@jw...>]

On Jun 17, 2005, at 9:16 PM, Lars Jensen wrote:

> The Quesa.dll file that comes with the version 1.7 download has  
> "1,5,4,9" in
> its Product Version and File Version strings on Windows. Is that  
> supposed to
> mean anything?

No.  Well, I'm sure that at some time it meant something.  But  
lately, I've been doing the Windows builds (using CodeWarrior) and I  
don't know how to set those numbers.

Windows version info

[Lars J. <lar...@rc...>]

The Quesa.dll file that comes with the version 1.7 download has "1,5,4,9" in
its Product Version and File Version strings on Windows. Is that supposed to
mean anything?

lj

Lights I/O

[Stefan H. <st...@to...>]

Reading lights worked a few weeks ago. Now, when reading a QD3D 
generated file Q3ViewHints_GetLightGroup always returns NULL.

When reading a Quesa generated file Q3ViewHints_GetAttributeSet 
returns NULL. The light group seems to be ok (I have to look in 
deeper).

QD3D cannot read Quesa generated lights. My app simply crashes.

Camera I/O works perfectly well.


Stefan

Re: Mach-O static library

[Don A. <da...@do...>]

Hi James,

On 15-Jun-05, at 9:45 AM, James W. Walker wrote:

> On Jun 15, 2005, at 6:13 AM, Don Agro wrote:
>> One last question ... What is the preferred method of distributing  
>> Quesa as a framework with ones application ?
> Well, I put it in the Frameworks folder of my application package.   
> That way there's no doubt about having the right version, and no  
> extra installation step.

Works for me.

Thanks for your help.

My last few messages to the list have bounced - the CC's to you must  
have gotten through.

> This Message was undeliverable due to the following reason:
>
> Each of the following recipients was rejected by a remote mail server.
> The reasons given by the server are included to help you determine why
> each recipient was rejected.
>
>     Recipient: <que...@li...>
>     Reason:    Postmaster verification failed while checking  
> <da...@do...>               Called:    
> 209.68.1.154               Sent:     RCPT  
> TO:<pos...@do...>               Response: 553  
> This server does not accept mail for that address  
> (#5.7.1)               Several RFCs state that you are required to  
> have a postmaster               mailbox for each mail domain. This  
> host does not accept mail               from domains whose servers  
> reject the postmaster address.               Sender verify failed
>
> Reporting-MTA: dns; tomts20.bellnexxia.net
> Arrival-Date: Wed, 15 Jun 2005 09:13:20 -0400
> Received-From-MTA: dns; [67.68.32.4]
>
> Final-Recipient: RFC822; <que...@li...>
> Action: failed
> Status: 5.1.1
> Remote-MTA: dns; mail.sourceforge.net (66.35.250.206)
> Diagnostic-Code: smtp; 550-Postmaster verification failed while  
> checking <da...@do...>
>  550-Called:   209.68.1.154
>  550-Sent:     RCPT TO:<pos...@do...>
>  550-Response: 553 This server does not accept mail for that  
> address (#5.7.1)
>  550-Several RFCs state that you are required to have a postmaster
>  550-mailbox for each mail domain. This host does not accept mail
>  550-from domains whose servers reject the postmaster address.
>  550 Sender verify failed


I am not getting any email from the list - just you - not sure why. I  
have been checking the posts on the web.

Best Regards,
Don Agro

D o g   P a r k   S o f t w a r e   L t d .

email: da...@do...
   www: http://www.dogparksoftware.com
       iChat AV:do...@ma...

Re: Mach-O static library

[James W. W. <os...@jw...>]

On Jun 15, 2005, at 6:13 AM, Don Agro wrote:

> One last question ... What is the preferred method of distributing  
> Quesa as a framework with ones application ?

Well, I put it in the Frameworks folder of my application package.   
That way there's no doubt about having the right version, and no  
extra installation step.

Re: Mach-O static library

[James W. W. <os...@jw...>]

On Jun 15, 2005, at 5:01 AM, Don Agro wrote:

> It may be sooner than that :(   It's my understanding that only  
> Mach-O Carbon will run under Rosetta.

No, I've heard some pretty definite statements that CFM Carbon does  
run under Rosetta.  It's Classic that doesn't run.

>> Is the Quesa framework in the Frameworks folder of your  
>> application package?
>>
>
> No there is no frameworks folder in my application package, I just  
> added the framework from the Quesa v1.7 SDK.

Added it where?  In ~/Library/Frameworks?  And you've checked that  
there isn't another version, say, in /Library/Frameworks?

> As far as I can tell I can only add one version of the Quesa v1.7  
> framework.

Re: Mach-O static library

[James W. W. <os...@jw...>]

On Jun 14, 2005, at 8:12 PM, Don Agro wrote:

>>>  Now this ought to work (though I personally would not try to do  
>>> Mach-
>>>  o in CW 8).
>>>
>
> I personally don't have a choice - my application was developed in  
> CW and one of the intermediate steps to get it into XCode is to  
> convert it from Carbon CFM to Carbon Mach-O.

I didn't mean to imply that you should be using XCode (though we all  
may be forced to do that within a couple of years) but rather that CW  
9 is better for Mach-O than CW 8.

> Link (dyld) error:
>
> Library not loaded: @executable_path/../Frameworks/Quesa.framework/ 
> Versions/A/Quesa
>   Referenced from: /Users/donagro/Documents/DogTools/MacLoggerDX  
> Mach-O/Output/MacLoggerDX.app/Contents/MacOS/MacLoggerDX
>   Reason: Incompatible library version: MacLoggerDX requires  
> version 1.6.0 or later, but Quesa provides version 1.0.0
>

Is the Quesa framework in the Frameworks folder of your application  
package?  If so, are you sure that you are linking against the same  
version of Quesa.framework as the one in the package?  It seems to be  
saying that there is a version mismatch.

Re: Mach-O static library

[Don A. <da...@do...>]

Hi James,

On Jun 14, 2005, at 9:34 PM, James W. Walker wrote:
> On Jun 14, 2005, at 5:25 AM, Don Agro wrote:
>>>  Is anyone using the Mach-O library in a CW 8.3 Mach-O Project ?
>>>  When I try to link the Quesa v1.7 libQuesa.a into a CW 8.3 Mach-O
>>>  project I get link errors starting with...
>>  This does not surprise me.  It"s generally a bad idea to use a  
>> static
>>  library containing C++ code unless you built that static library.
>>  There is a mismatch between the STL used to build the library and  
>> the
>>  STL that you use in your app.
>>>  If I try to use Quesa.framwork it compiles and links OK but crashes
>>>  in dylib when run.
>>  Now this ought to work (though I personally would not try to do  
>> Mach-
>>  o in CW 8).

I personally don't have a choice - my application was developed in CW  
and one of the intermediate steps to get it into XCode is to convert  
it from Carbon CFM to Carbon Mach-O.

Apple seems to think it is a worthwhile exercise since so many  
Macintosh applications have been written with CW...
<http://developer.apple.com/tools/switchtoxcode.html>


The entire thing compiles, links and runs - with the exception of Quesa.

> Can you show us the relevant portion of the crash log?

Sure...

Including the OpenGL and AGL frameworks - no problem but as soon as I  
include the Quesa framework - it tanks.

Date/Time:      2005-06-14 08:40:19.617 -0400
OS Version:     10.4.1 (Build 8B15)
Report Version: 3

Command: MacLoggerDX
Path:    /Users/donagro/Documents/DogTools/MacLoggerDX Mach-O/Output/ 
MacLoggerDX.app/Contents/MacOS/MacLoggerDX
Parent:  WindowServer [95]

Version: ??? (???)

PID:    11186
Thread: Unknown

Link (dyld) error:

Library not loaded: @executable_path/../Frameworks/Quesa.framework/ 
Versions/A/Quesa
   Referenced from: /Users/donagro/Documents/DogTools/MacLoggerDX  
Mach-O/Output/MacLoggerDX.app/Contents/MacOS/MacLoggerDX
   Reason: Incompatible library version: MacLoggerDX requires version  
1.6.0 or later, but Quesa provides version 1.0.0

> (And by the way, please join the mailing list so that your posts will
> not require moderator approval.)

I did - before I posted but the confirmation email I sent didn't take  
- had to send it again - and send my post again.


Don Agro
www: http://www.dogparksoftware.com