quesa-develop — Mailing list for Quesa development

Re: C++ changes

[Jose' C. <cru...@ce...>]

Il giorno 06/gen/05, alle 17:15, Roger Holmes ha scritto:

> I have changed the plan slightly as I am using '~' rather than '-'
> to modify the sizeof the new records as some classes have no
> instance data and 0 == -0 whereas 0 != ~0.
>

But why you just doesn't declares a new routine that takes the class 
size instead of the instance size, and add a flag to note what kind of 
class is it?


> 1) Should every E3ClassTree routine be a friend or a method?
> 2) If a method, then should ones with a TQ3Object take it as their 
> 'this' ?

I second the James proposal of a class for tree methods


> 3) If so, should the method names be as in option A, B or C ?

IMHO Always whatever makes sense (in your case option C)


Pax et Bonum

# dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,33603122                0372,460602

Re: C++ changes

[James W. W. <ja...@wr...>]

Roger Holmes <rog...@mi...> wrote:

>1) Should every E3ClassTree routine be a friend or a method?

A third alternative would be to make E3ClassTree a separate class, 
initially containing nothing but static methods.  Then you could just 
make E3ClassTree a friend of OpaqueTQ3Object.  This seems the most 
reasonable to me.

As a later step, it might be reasonable to make E3ClassTree a 
singleton, and move the class tree members of E3Globals into 
E3ClassTree.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

C++ changes

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

I would like a second opinion on what I have done so far.

I have changed the plan slightly as I am using '~' rather than '-'
to modify the sizeof the new records as some classes have no
instance data and 0 == -0 whereas 0 != ~0.

OpaqueTQ3Object is now a class with all its fields private, and it
will be the base class for the entire object hierarchy. Maybe in
the long term it will be a class with no fields and no methods
and a new class probably called ClassTree will inherit from it
and all existing fields will be moved there.

As all the fields are private and as all the existing E3ClassTree
routines make extensive use of these fields I have at the moment
made every E3ClassTree routine a friend of OpaqueTQ3Object.

This is the minimum change necessary, but maybe is not the way
we want to proceed.

Should I leave it as it is now or change all the E3ClassTree routines
into methods of OpaqueTQ3Object? The ones which do not take a
TQ3Object as a parameter would have to be static methods. The rest
could be re-coded as proper methods and all their (principal) TQ3Object
accessed via " this ". Of course " this-> " could be removed where 
fields
or other methods are used. Although this sounds preferable it does
mean a lot more changes will be needed, eventually as the changes
move up through the object hierarchy, almost every routine in every
file will need to be modified. I am not concerned about the volume of
work but by the possibility of introducing bugs. Fortunately Quesa is
a relatively compact source code compared to some of Microspot's
products.

If we do decide to go to methods, there is also the question of names.
Should I retain the existing names or take out the E3ClassTree prefix
so that eventually routines like E3ClassTree_Destroy would become
ClassTree::Destroy rather that ClassTree::E3ClassTree_Destroy.
Maybe the case for non static methods is less clear cut, should a
call to E3ClassTree_GetClassByObject look like this:

theObject -> E3ClassTree_GetClassByObject() ; // option A

or like this:

theObject -> GetClassByObject() ; // option B

or just this:

theObject -> GetClass() ; // option C


To recap, my questions are:

1) Should every E3ClassTree routine be a friend or a method?
2) If a method, then should ones with a TQ3Object take it as their 
'this' ?
3) If so, should the method names be as in option A, B or C ?
4) Any other comments or ideas you have.

I will await input before proceeding further.

[ quesa-Bugs-907879 ] Table of contents not parsed in text 3DMFs

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

Bugs item #907879, was opened at 2004-03-01 13:41
Message generated for change (Comment added) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=907879&group_id=45158

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Dair Grant (grantd)
Assigned to: James W. Walker (jwwalker)
Summary: Table of contents not parsed in text 3DMFs

Initial Comment:
Frank Cox wrote:

Quesa is having problems loading 3DMFs with multiple trimeshes 
that use shader references. Here's a simplified example model: 
http://webhome.idirect.com/~frankco/ test_3dm.sit It's a simple 
cube, with each face saved as a separate trimesh, but all faces 
reference the first texture shader. QD3D handles these files just 
fine.

A second issue that popped up with 1.6d18 involves specular 
highlighting. I'm getting specular highlights on trimeshes that 
shouldn't be receiving them (i.e. meshes using a null shader). This 
only happens when at least one object in the scene has specular 
highlighting enabled, which leads me to suspect that the GL state 
may be left dangling between vertex flushes.

-----

James Walker wrote:

The bug appears to be in reading text 3DMF files.  After I 
converted the test file to binary form with Anatas, a Quesa app 
was able to read all 6 textured TriMeshes.

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

>Comment By: James W. Walker (jwwalker)
Date: 2005-01-05 20:37

Message:
Logged In: YES 
user_id=433183

This is fixed.

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

Comment By: Dair Grant (grantd)
Date: 2004-06-15 16:10

Message:
Logged In: YES 
user_id=439944

Renaming to reflect underlying problem.

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

Comment By: James W. Walker (jwwalker)
Date: 2004-06-05 09:56

Message:
Logged In: YES 
user_id=433183

The underlying problem is that Quesa does not read the table of contents 
in text 3DMF.

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

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

Re: General C++ improvements

[James W. W. <ja...@wr...>]

Roger Holmes <rog...@mi...> wrote:

>When I am writing new routines or modifying new ones I am very tempted
>to adopt the normal C++ style of not declaring variables until they 
>are needed,
>which usually is by setting the variable to an initial value, thereby avoiding
>many cases of uninitialised variables.
>
>Are there any reasons for not doing so now?

One small problem with that approach is that one can easily end up 
with a variable name being declared in multiple scopes within the 
function.  Then if I'm using the CodeWarrior debugger, it's hard to 
tell which version of the variable I should be looking at.  (Maybe 
other debuggers handle this situation better?)
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

General C++ improvements

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

When I am writing new routines or modifying new ones I am very tempted
to adopt the normal C++ style of not declaring variables until they are 
needed,
which usually is by setting the variable to an initial value, thereby 
avoiding
many cases of uninitialised variables.

Are there any reasons for not doing so now?

Roger.

C++ changes

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

This is how I propose to start the changes to the instance data.

I will not be able to do everything in one editing session so to try
to maintain consistency in the CVS code I will have to work up the
class hierarchy one class at a time until all the leaf classes are
complete.

To do this I will change the instanceSize parameter of 
E3ClassTree_RegisterClass
to be TQ3Int32 instead of TQ3Uns32. The internals of the ClassTree 
routines will
then be changed so that they recognise a negative parameter as  being 
minus
the size of the class AND ALL ITS PARENTS including OpaqueTQ3Object.
This code will not need to handle the case of a child being negative 
and the
parent positive, only the other way around or both the same sign.

I can then change each class in turn by modifying the instance data to 
inherit
from its base class and add a minus sign before the sizeof in the 
class's call
to E3ClassTree_RegisterClass.

When all classes have been done we can take out the old code and take 
the
abs of the parameter and take out the minus signs as and when 
convenient.

Unless of course anyone has any objections or any better ideas.

Roger.

Re: C++ wrapper for Quesa object

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

Yes that sounds fine. I would like to informally reserve the name 
C3DObject and similar
C3D prefixes for wrappers which bumps the reference count when they 
they are
constructed and decrease it when their destructor is called.

I am about to start work on the new C++ replacements for the instance 
data for all of
Quesa's shared objects if that is OK with everyone.

Roger.






On Wednesday, December 29, 2004, at 04:56  am, James W.Walker wrote:

> In the course of improving text 3DMF reading, I'm going to introduce a 
> simple C++ wrapper class for a Quesa object.  (One could make such a 
> wrapper using boost::intrusive_pointer, but I didn't think we would 
> want to require Boost.)  Since this class could be useful for users of 
> Quesa as well as in the implementation, I'm wondering whether I should 
> put it in the SDK rather than in the source hierarchy?
>
> Here's the interface.  Comments follow.
>
> class CQ3ObjectRef
> {
> public:
> 							// default constructor
> 							CQ3ObjectRef()
> 									: mObject( NULL ) {}
>
> 							// copy constructor
> 							CQ3ObjectRef( const CQ3ObjectRef& inOther );
> 							
> 							// constructor from a Quesa object
> 							// Note: assumes it is given a new reference
> 	explicit				CQ3ObjectRef( TQ3SharedObject inObject )
> 									: mObject( inObject ) {}
> 	
> 							// destructor
> 							~CQ3ObjectRef();
> 	
> 							// assignment operator
> 	CQ3ObjectRef&		operator=( const CQ3ObjectRef& inOther );
> 	
> 	void					swap( CQ3ObjectRef& ioOther );
> 	
> 	bool					isvalid() const { return mObject != NULL; }
> 	
> 	TQ3SharedObject			get() const { return mObject; }
> 	
> private:
> 	TQ3SharedObject			mObject;
> };
>
> Notes:
> * This object can be used in STL containers.
> * All methods will have inline definitions.
> * No methods throw exceptions.
> * I tried to keep it simple, so I did not provide release() or reset() 
> functions.  In place of myob.reset( newref ) one can write myob = 
> CObjectRef(newRef), and in place of
> TQ3Object x = myob.release();
> one can write
> TQ3Object x = Q3Shared_GetReference( myob.get() );
> --
> <http://www.jwwalker.com/>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

Testing 3, ignore

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

My messages have not been reaching the list.
--
<http://www.jwwalker.com/>

C++ wrapper for Quesa object

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

In the course of improving text 3DMF reading, I'm going to introduce a 
simple C++ wrapper class for a Quesa object.  (One could make such a 
wrapper using boost::intrusive_pointer, but I didn't think we would 
want to require Boost.)  Since this class could be useful for users of 
Quesa as well as in the implementation, I'm wondering whether I should 
put it in the SDK rather than in the source hierarchy?

Here's the interface.  Comments follow.

class CQ3ObjectRef
{
public:
							// default constructor
							CQ3ObjectRef()
									: mObject( NULL ) {}

							// copy constructor
							CQ3ObjectRef( const CQ3ObjectRef& inOther );
							
							// constructor from a Quesa object
							// Note: assumes it is given a new reference
	explicit				CQ3ObjectRef( TQ3SharedObject inObject )
									: mObject( inObject ) {}
	
							// destructor
							~CQ3ObjectRef();
	
							// assignment operator
	CQ3ObjectRef&		operator=( const CQ3ObjectRef& inOther );
	
	void					swap( CQ3ObjectRef& ioOther );
	
	bool					isvalid() const { return mObject != NULL; }
	
	TQ3SharedObject			get() const { return mObject; }
	
private:
	TQ3SharedObject			mObject;
};

Notes:
* This object can be used in STL containers.
* All methods will have inline definitions.
* No methods throw exceptions.
* I tried to keep it simple, so I did not provide release() or reset() 
functions.  In place of myob.reset( newref ) one can write myob = 
CObjectRef(newRef), and in place of
TQ3Object x = myob.release();
one can write
TQ3Object x = Q3Shared_GetReference( myob.get() );
--
<http://www.jwwalker.com/>

Re: Number of mipmaps in a mipmap texture?

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

On 18-Dec-04, at 12:17 PM, James W. Walker wrote:

> On Dec 18, 2004, at 12:41 AM, Jose' Cruanyes wrote:
>
>> but why we have to go down to a 1*1 texture?
>
> That's what OpenGL does. For instance, in the description of 
> gluBuild2DMipmaps, the reference manual says "For example, if width is 
> 64 and height is 16, the following mipmaps are built: 64x16, 32x8, 
> 8x2, 4x1, 2x1, and 1x1".

OpenGL also requires all those levels, and will replace missing mipmaps 
with solid white textures. Apple didn't follow the spec for their CFM 
OpenGL implementation however (it reverts to a linear filter when 
mipmaps are missing), so this might not be obvious unless you're 
working in Win32/*nix or MachO.

Frank.

Re: Number of mipmaps in a mipmap texture?

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

On Dec 18, 2004, at 12:41 AM, Jose' Cruanyes wrote:

> but why we have to go down to a 1*1 texture?

That's what OpenGL does. For instance, in the description of 
gluBuild2DMipmaps, the reference manual says "For example, if width is 
64 and height is 16, the following mipmaps are built: 64x16, 32x8, 8x2, 
4x1, 2x1, and 1x1".  This suggests that the formula is even further off 
than I thought,  It should use the maximum, not the minimum, of the 
width and the height.
--
<http://www.jwwalker.com/>

Re: Number of mipmaps in a mipmap texture?

[Jose' C. <cru...@ce...>]

Il giorno 17/dic/04, alle 23:31, James W. Walker ha scritto:

> In ir_texture_convert_mipmap, we have:
>
> 	// Work out how many images are contained in the mipmap
> 	if (theMipmap.useMipmapping)
> 		{
> 		numImages = 0;
> 		n         = E3Num_Min(theMipmap.mipmaps[0].width, 
> theMipmap.mipmaps[1].height);
> 		while (n > 1)
> 			{
> 			n         /= 2;
> 			numImages += 1;
> 			}
> 		}
> 	else
> 		numImages = 1;
>
> This caught my attention because the subscript [1] for the height 
> seemed out of place.  But even if the width were the limiting factor, 
> the formula seems wrong.  For instance suppose we start with n = 5. 
> The first time through the loop, n becomes 2 and numImages becomes 1. 
> The second pass makes n become 1 and numImages become 2, and then we 
> exit the loop.  But numImages should be 3: sizes 5, 2, and 1.

yes, one of two is wrong
or we init numImages to 1 or test for (n >= 1)

but why we have to go down to a 1*1 texture?

Pax et Bonum

# dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,33603122                0372,460602

Re: Cast as you can (VC++ 6.0)

[Jose' C. <cru...@ce...>]

Il giorno 17/dic/04, alle 20:42, Roger Holmes ha scritto:

even if it's MUCH easier to use

> ((char*&) myStructPtr)) += sizeOfMyStruct;

may be its clearer this one

> myStructPtr =  ( myStruct*) ( (char*) myStructPtr + sizeOfMyStruct ) ;


I'll give them a try Monday (my Windows machines are at office, only 
macs at home)

Pax et Bonum

# dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,33603122                0372,460602

Number of mipmaps in a mipmap texture?

[James W. W. <ja...@wr...>]

In ir_texture_convert_mipmap, we have:

	// Work out how many images are contained in the mipmap
	if (theMipmap.useMipmapping)
		{
		numImages = 0;
		n         = E3Num_Min(theMipmap.mipmaps[0].width, 
theMipmap.mipmaps[1].height);
		while (n > 1)
			{
			n         /= 2;
			numImages += 1;
			}
		}
	else
		numImages = 1;

This caught my attention because the subscript [1] for the height 
seemed out of place.  But even if the width were the limiting factor, 
the formula seems wrong.  For instance suppose we start with n = 5. 
The first time through the loop, n becomes 2 and numImages becomes 1. 
The second pass makes n become 1 and numImages become 2, and then we 
exit the loop.  But numImages should be 3: sizes 5, 2, and 1.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Cast as you can (VC++ 6.0)

[James W. W. <ja...@wr...>]

Roger Holmes <rog...@mi...> wrote:

>One way might be:
>
>myStruct * myStructPtr;
>
>myStructPtr =  ( myStruct*) ( (int) myStructPtr + sizeOfMyStruct ) ;

Better to say

myStructPtr =  ( myStruct*) ( (char*) myStructPtr + sizeOfMyStruct ) ;

There is no guarantee that the int type has the same size as a 
pointer type.  (Indeed, on the old 68K platform with CodeWarrior, int 
was 2 bytes.)
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Cast as you can (VC++ 6.0)

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

On Friday, December 17, 2004, at 07:55  pm, James W. Walker wrote:

>
> ((char*&) myStructPtr)) += sizeOfMyStruct;
>
> That compiles in CodeWarrior, and the reference may make it legal, but 
> it looks tricky.
>

I don't think so, not with two open brackets and three closing ones :-)

Apart from that very neat, as long as it compiles on Jose's compiler.

Re: Cast as you can (VC++ 6.0)

[James W. W. <ja...@wr...>]

Jose' Cruanyes <cru...@ce...> wrote:

>I'm trying to compile Quesa with VC++ 6.0, and an issue has risen
>
>the cast on l-values are not allowed in MS VC++
>
>this expression is illegal in C++ (according to MS)
>
>myStruct * myStructPtr;
>
>((char*) myStructPtr)) += sizeOfMyStruct
>
>error C2106 left operand must be l-value...
>
>there are 44 of them in quesa
>
>several other changes had been made, but this is serious
>do you know a way to avoid it?


It looks as though MS may be right.  The 1998 C++ standard says: "The 
result of the expression (T) cast-expression is of type T. The result 
is an lvalue if T is a reference type, otherwise the result is an 
rvalue."  However, I don't see any way to get CodeWarrior to even 
give me a warning about this.

Would it make sense to say this?

((char*&) myStructPtr)) += sizeOfMyStruct;

That compiles in CodeWarrior, and the reference may make it legal, 
but it looks tricky.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Cast as you can (VC++ 6.0)

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

One way might be:

myStruct * myStructPtr;

myStructPtr =  ( myStruct*) ( (int) myStructPtr + sizeOfMyStruct ) ;


Very similar to what we had to do in Pascal a decade or more ago.

Roger.



On Friday, December 17, 2004, at 06:49  pm, Jose' Cruanyes wrote:

> I'm trying to compile Quesa with VC++ 6.0, and an issue has risen
>
> the cast on l-values are not allowed in MS VC++
>
> this expression is illegal in C++ (according to MS)
>
> myStruct * myStructPtr;
>
> ((char*) myStructPtr)) += sizeOfMyStruct
>
> error C2106 left operand must be l-value...
>
> there are 44 of them in quesa
>
> several other changes had been made, but this is serious
> do you know a way to avoid it?
>
> Pax et Bonum
>
> # dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
> #  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
> #   02,33603122                0372,460602
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

Cast as you can (VC++ 6.0)

[Jose' C. <cru...@ce...>]

I'm trying to compile Quesa with VC++ 6.0, and an issue has risen

the cast on l-values are not allowed in MS VC++

this expression is illegal in C++ (according to MS)

myStruct * myStructPtr;

((char*) myStructPtr)) += sizeOfMyStruct

error C2106 left operand must be l-value...

there are 44 of them in quesa

several other changes had been made, but this is serious
do you know a way to avoid it?

Pax et Bonum

# dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,33603122                0372,460602

[ quesa-Bugs-902924 ] Q3Object_Duplicate doesn't handle storage objects

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

Bugs item #902924, was opened at 2004-02-23 11:42
Message generated for change (Comment added) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=902924&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dair Grant (grantd)
>Assigned to: James W. Walker (jwwalker)
Summary: Q3Object_Duplicate doesn't handle storage objects

Initial Comment:
See comments in E3Main.c - other object types can be 
duplicated correctly.

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

>Comment By: James W. Walker (jwwalker)
Date: 2004-12-16 19:29

Message:
Logged In: YES 
user_id=433183

I have implemented duplication of memory storage objects.  It is
not clear to me what it would mean to duplicate a file storage
object.

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

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

Re: Comments about CW8.3 compile.

[James W. W. <ja...@wr...>]

Peter Michelsen <Pet...@mi...> wrote:

>Where you still able to see the Geom test source code in Shark?
>
>Even this would still be very helpful.

No.  Apparently this is supposed to work, so when I get some time, I 
will give Apple a bug report.  If you do too, all the better.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Comments about CW8.3 compile.

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

Hi James,

Where you still able to see the Geom test source code in Shark?

Even this would still be very helpful.

Peter Michelsen.


On 14 Dec 2004, at 19:40, James W. Walker wrote:

>> I am very interested in how you managed to get Shark working with 
>> Geom Test.
>>
>> I spent today porting over Quesa, Geom Test and some of our
>> applications to CW 9.3. That was fun. To get Quesa to compile I
>> downloaded the OpenGL_CFM_SDK from apple which is using OpenGL 1.3,
>> is this correct?
>
> Yes, that sounds right.
>
>> Next I ran up Shark 4.0.1. Then using the Time Profile setting of
>> Shark on Geom Test but still no source code in the results.
>
> Sorry, it appears that I spoke too hastily.  When I try it today, I 
> see that if I double-click a Quesa function name in the profile, it 
> shows source code, but the WRONG source code.  For instance if I 
> double-click E3Object_Submit, I see the source for 
> E3MeshFacePart_GetFace.
> -- 
>   James W. Walker, ScriptPerfection Enterprises, Inc.
>   <http://www.write-brain.com/>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

Re: Comments about CW8.3 compile.

[James W. W. <ja...@wr...>]

>I am very interested in how you managed to get Shark working with Geom Test.
>
>I spent today porting over Quesa, Geom Test and some of our
>applications to CW 9.3. That was fun. To get Quesa to compile I
>downloaded the OpenGL_CFM_SDK from apple which is using OpenGL 1.3,
>is this correct?

Yes, that sounds right.

>Next I ran up Shark 4.0.1. Then using the Time Profile setting of
>Shark on Geom Test but still no source code in the results.

Sorry, it appears that I spoke too hastily.  When I try it today, I 
see that if I double-click a Quesa function name in the profile, it 
shows source code, but the WRONG source code.  For instance if I 
double-click E3Object_Submit, I see the source for 
E3MeshFacePart_GetFace.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Comments about CW8.3 compile.

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

Hi James,

I am very interested in how you managed to get Shark working with Geom 
Test.

I spent today porting over Quesa, Geom Test and some of our 
applications to CW 9.3. That was fun. To get Quesa to compile I 
downloaded the OpenGL_CFM_SDK from apple which is using OpenGL 1.3, is 
this correct?

Next I ran up Shark 4.0.1. Then using the Time Profile setting of Shark 
on Geom Test but still no source code in the results.

I was wondering if Sharks preferences make a different? What do you set 
for the "Search Paths" part.