quesa-develop — Mailing list for Quesa development

Windows resources

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

About a month ago there was a thread (titled "Windows version info")  
in which it was asked why Quesa did not show a correct version number  
on Windows, and remarked that there was a file Quesa Viewer.res that  
nobody knows how to edit.  In view of the fact that the viewer is  
quite broken on Windows anyway (see bugs 901059, 902978, 907875) I  
have removed Quesa Viewer.res from the CodeWarrior project for  
Windows, and added in its place a Quesa.rc file that will add a  
version number.

[ quesa-Bugs-967773 ] Lighting state isn't respected on transparent objects

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

Bugs item #967773, was opened at 2004-06-06 14:09
Message generated for change (Comment added) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967773&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: Pending
>Resolution: Fixed
Priority: 5
Submitted By: Frank Condello (pox)
Assigned to: James W. Walker (jwwalker)
Summary: Lighting state isn't respected on transparent objects

Initial Comment:
The lighting state isn't restored when rendering transparent 
primitives.

There may already be enough information saved in the 
TQ3TransparentPrim struct to get proper lighting (in the 
"illumination" member)

Fixing this could be as simple as adding the following to 
ir_geom_transparent_render:

	if (thePrim->illumination == kQ3IlluminationTypeNULL)
		{
		glDisable(GL_LIGHTING);
		glDisable(GL_COLOR_MATERIAL);
		}
	else
		{
		glEnable(GL_LIGHTING);
		glEnable(GL_COLOR_MATERIAL);
		}
	}

...but the state should be saved between primitives and only 
changed when needed since they will likely be drawn in large 
groups that are either lit, or unlit.

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

>Comment By: James W. Walker (jwwalker)
Date: 2005-07-18 16:18

Message:
Logged In: YES 
user_id=433183

Fixed in CVS by a change to IRTransparent.c.

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

Comment By: Frank Condello (pox)
Date: 2004-09-29 09:22

Message:
Logged In: YES 
user_id=171509

Note: If using the workaround above, be sure to enable the GL_LIGHTING 
state for the specular pass, and before IRTransBuffer_Draw returns.

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

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

[ quesa-Bugs-1027387 ] Quesa in CVS not compatible with Nanosaur

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

Bugs item #1027387, was opened at 2004-09-13 10:41
Message generated for change (Comment added) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=1027387&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: Pending
Resolution: None
Priority: 5
Submitted By: Lane Roathe (raving)
Assigned to: Nobody/Anonymous (nobody)
Summary: Quesa in CVS not compatible with Nanosaur

Initial Comment:
The version of Quesa for Windows that is in CVS does
not work with Nanosaur for Windows.

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

>Comment By: James W. Walker (jwwalker)
Date: 2005-07-17 23:51

Message:
Logged In: YES 
user_id=433183

I happened to have a Windows laptop at home this weekend.
(A Dell Inspiron running XP Home, to be more precise.)
I tried the same thing: Checked out fresh source, built with CW 8.3,
and tried both the debug and release DLL.  No problem at all.
So there is apparently a little more subtlety to this.

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

Comment By: Lane Roathe (raving)
Date: 2005-07-17 22:21

Message:
Logged In: YES 
user_id=48487

I just checked out the latest version of Quesa from CVS and
built the Windows DLLs from the CW project using CW 8.3
under Mac OS X. (Same setup I develop Nanosaur under).

Downloaded and installed Nanosaur from:

ftp://ftp.ifd.com/pub/win/nanosaur_install.exe

Replaced Quesa.dll therein with my release build from the
project. Ran game. After the serial # dialog (choose play
demo) you get:

"Error: Q3View_StartRendering Failed!"

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

Comment By: James W. Walker (jwwalker)
Date: 2005-07-17 16:55

Message:
Logged In: YES 
user_id=433183

This is too vague.   Does it crash?  Not draw anything?  Draw a particular 
geometry incorrectly?

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

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

[ quesa-Bugs-1027387 ] Quesa in CVS not compatible with Nanosaur

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

Bugs item #1027387, was opened at 2004-09-13 12:41
Message generated for change (Comment added) made by raving
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=1027387&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: Lane Roathe (raving)
Assigned to: Nobody/Anonymous (nobody)
Summary: Quesa in CVS not compatible with Nanosaur

Initial Comment:
The version of Quesa for Windows that is in CVS does
not work with Nanosaur for Windows.

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

>Comment By: Lane Roathe (raving)
Date: 2005-07-18 00:21

Message:
Logged In: YES 
user_id=48487

I just checked out the latest version of Quesa from CVS and
built the Windows DLLs from the CW project using CW 8.3
under Mac OS X. (Same setup I develop Nanosaur under).

Downloaded and installed Nanosaur from:

ftp://ftp.ifd.com/pub/win/nanosaur_install.exe

Replaced Quesa.dll therein with my release build from the
project. Ran game. After the serial # dialog (choose play
demo) you get:

"Error: Q3View_StartRendering Failed!"

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

Comment By: James W. Walker (jwwalker)
Date: 2005-07-17 18:55

Message:
Logged In: YES 
user_id=433183

This is too vague.   Does it crash?  Not draw anything?  Draw a particular 
geometry incorrectly?

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

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

[ quesa-Feature Requests-901437 ] Support alternative texture formats

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

Feature Requests item #901437, was opened at 2004-02-20 14:44
Message generated for change (Settings changed) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442055&aid=901437&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
Priority: 5
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Support alternative texture formats

Initial Comment:
Add support for 4444 and 8-bit grayscale texture map formats.

Would need some new constants and support in Quesa, and support 
in the Interactive renderer.

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

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

[ quesa-Feature Requests-900675 ] Add FSRef based storage object

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

Feature Requests item #900675, was opened at 2004-02-19 13:48
Message generated for change (Settings changed) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442055&aid=900675&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
Priority: 5
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add FSRef based storage object

Initial Comment:
We should add Mac OS TQ3StorageObjects based on FSRefs rather 
than FSSpecs, to support both types of file specifiers.

The API should mirror the Q3FSSpecStorage_xxx calls, and 
Q3MacintoshStorage_GetType should be extended to return a 
kQ3MacintoshStorageTypeFSRef constant.

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

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

[ quesa-Feature Requests-901431 ] Textures should use packed pixel extension

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

Feature Requests item #901431, was opened at 2004-02-20 14:40
Message generated for change (Settings changed) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442055&aid=901431&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
Priority: 5
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Textures should use packed pixel extension

Initial Comment:
We currently convert all incoming textures to 32bpp RGBA for 
passing to OpenGL - most OpenGL implementations will now 
support the packed pixel extension, so we should be able to pass 
on 16 or 24 bit pixel data directly rather than copying it.
        
This could also simplify the texture swapping code in IRUpdate.c, 
which  is quite complex and a bit misleading (e.g., 16bpp texture 
data is not really swapped, it's permuted, and yet the variable is 
called 'swap').


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

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

[ quesa-Feature Requests-901432 ] Textures should use client storage extension

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

Feature Requests item #901432, was opened at 2004-02-20 14:41
Message generated for change (Settings changed) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442055&aid=901432&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
Priority: 5
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Textures should use client storage extension

Initial Comment:
Textures should use the client-storage extension on Mac OS X - 
would allow us to use the QD3D texture data directly rather than 
having to have OpenGL make a second copy.


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

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

[ quesa-Feature Requests-902983 ] Support alternative fog models

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

Feature Requests item #902983, was opened at 2004-02-23 13:06
Message generated for change (Settings changed) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442055&aid=902983&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
Priority: 5
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Support alternative fog models

Initial Comment:
We should support per-vertex and radial fog: fog_coord and 
nv_fog_distance.

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

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

[ quesa-Bugs-1027387 ] Quesa in CVS not compatible with Nanosaur

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

Bugs item #1027387, was opened at 2004-09-13 10:41
Message generated for change (Comment added) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=1027387&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: Pending
Resolution: None
Priority: 5
Submitted By: Lane Roathe (raving)
Assigned to: Nobody/Anonymous (nobody)
Summary: Quesa in CVS not compatible with Nanosaur

Initial Comment:
The version of Quesa for Windows that is in CVS does
not work with Nanosaur for Windows.

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

>Comment By: James W. Walker (jwwalker)
Date: 2005-07-17 16:55

Message:
Logged In: YES 
user_id=433183

This is too vague.   Does it crash?  Not draw anything?  Draw a particular 
geometry incorrectly?

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

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

[ quesa-Bugs-967773 ] Lighting state isn't respected on transparent objects

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

Bugs item #967773, was opened at 2004-06-06 14:09
Message generated for change (Settings changed) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967773&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: Frank Condello (pox)
>Assigned to: James W. Walker (jwwalker)
Summary: Lighting state isn't respected on transparent objects

Initial Comment:
The lighting state isn't restored when rendering transparent 
primitives.

There may already be enough information saved in the 
TQ3TransparentPrim struct to get proper lighting (in the 
"illumination" member)

Fixing this could be as simple as adding the following to 
ir_geom_transparent_render:

	if (thePrim->illumination == kQ3IlluminationTypeNULL)
		{
		glDisable(GL_LIGHTING);
		glDisable(GL_COLOR_MATERIAL);
		}
	else
		{
		glEnable(GL_LIGHTING);
		glEnable(GL_COLOR_MATERIAL);
		}
	}

...but the state should be saved between primitives and only 
changed when needed since they will likely be drawn in large 
groups that are either lit, or unlit.

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

Comment By: Frank Condello (pox)
Date: 2004-09-29 09:22

Message:
Logged In: YES 
user_id=171509

Note: If using the workaround above, be sure to enable the GL_LIGHTING 
state for the specular pass, and before IRTransBuffer_Draw returns.

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

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

Shading and transparency Fixed

[Steven V. <is...@ma...>]

Hi,

I fixed the bug for transparent rendering of non shaded objects inside 
quesa. Really.... It was just 15 minutes of work. The fix is marked 
with a #if(FixTransparentShading), so the new code should be easily to 
spot.

Changes are made in the file:

/quesa/Development/Source/Renderers/Interactive/IRTransparent.c

I will host this file on my website, If you want to have the fix 
immediately.

http://revaro.spymac.com/IRTransparent.c

I also send this file in an email to James W. Walker, so that he can 
fix it in CVS

Steven Verstoep
www.revaro.net
Op 17-jul-05 om 5:33 heeft que...@li... 
het volgende geschreven:

> Message: 8
> From: "James W. Walker" <os...@jw...>
> Subject: Re: Shading and transparency
> Date: Sat, 16 Jul 2005 19:19:39 -0700
> To: que...@li...
> Reply-To: que...@li...
>
>
> --Apple-Mail-1--621824315
> Content-Transfer-Encoding: 7bit
> Content-Type: text/plain;
> 	charset=US-ASCII;
> 	delsp=yes;
> 	format=flowed
>
> It looks like this is already in the bug database, "Lighting state
> isn't respected on transparent objects", <http://sourceforge.net/
> tracker/index.php?func=detail&aid=967773&group_id=45158&atid=442052>.
> --Apple-Mail-1--621824315
> Content-Transfer-Encoding: base64
> Content-Type: application/pkcs7-signature;
> 	name=smime.p7s
> Content-Disposition: attachment;
> 	filename=smime.p7s

Re: Shading and transparency

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

It looks like this is already in the bug database, "Lighting state  
isn't respected on transparent objects", <http://sourceforge.net/ 
tracker/index.php?func=detail&aid=967773&group_id=45158&atid=442052>.

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

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

Bugs item #1227484, was opened at 2005-06-25 12:50
Message generated for change (Comment added) made by jwwalker
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.


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

>Comment By: James W. Walker (jwwalker)
Date: 2005-07-16 19:13

Message:
Logged In: YES 
user_id=433183

Dair Grant's idea was that we should use VBO's instead of
display lists, as a more modern method. (There has been
some recent disagreement on the comp.graphics.api.opengl
newsgroup as to whether VBOs are necessarily faster than
display lists.)  The trouble with both ideas is that Quesa
currently does its own backface culling. This is to support
the 3 backfacing choices in Quesa, which do not quite
correspond to OpenGL's two choices of two-sided rendering
or not.  But this means that if you moved the camera, you
would have to flush the cached display lists or VBOs.

What we might consider is making a new renderer that
would place less emphasis on compatibility with QD3D
documentation and experience, and more emphasis on
speed.  The new cartoon-style renderer can serve as an
example of how to base a new renderer on the existing
one, rather than writing a whole renderer from scratch.

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

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

Re: Shading and transparency

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

On Jul 16, 2005, at 1:56 PM, Steven Verstoep wrote:

> This time I am working on fixing the race-overlay of my game. This  
> was something that used to work once (Either under Quickdraw 3D or  
> under another version of quesa). The problem is that my race- 
> overlay gets shaded with the lights of my scene. I don't want this.  
> I want it to be transparent  and not shaded for which I use  
> Q3NULLIllumination_New. I am really messing my code up so I might  
> actually make things worse. However I suspect this might be a bug  
> in quesa. I render in retained mode and I think what happens is  
> that Quesa does some alpha sorting routine, but then forgets to  
> check if the texture should be rendered with lights on or off.
>
> I can actually make this work, but then all the windows of my cars  
> (which should be transparent) become white.
>

Yes, it looks like a bug.  The TQ3TransparentPrim used for drawing  
transparent stuff does include an illumination field, but it seems to  
be only used to determine whether to draw specular highlights or not.

However, I wonder if fixing this bug would really be the right way  
for you to go.  I see from your web site that your products are for  
OS X only.  An alternative would be to use an overlay window.  That  
way, you could use Quartz APIs to draw the text, which might be  
faster and easier to work with than however you're drawing the text now.

Shading and transparency

[Steven V. <is...@ma...>]

Hi all,

I am so glad that there is now a community which I can turn to if I 
have a problem. This time I am working on fixing the race-overlay of my 
game. This was something that used to work once (Either under Quickdraw 
3D or under another version of quesa). The problem is that my 
race-overlay gets shaded with the lights of my scene. I don't want 
this. I want it to be transparent  and not shaded for which I use 
Q3NULLIllumination_New. I am really messing my code up so I might 
actually make things worse. However I suspect this might be a bug in 
quesa. I render in retained mode and I think what happens is that Quesa 
does some alpha sorting routine, but then forgets to check if the 
texture should be rendered with lights on or off.

I can actually make this work, but then all the windows of my cars 
(which should be transparent) become white.

In the case my race overlay gets shaded with the scene lights I do 
something like:

Q3View_StartRendering(view);
Q3Shader_Submit(MyPhongShader, view);
RenderLevel(view);
RenderRaceOverlay(view);
  Q3View_EndRendering(view);

I can make the race overlay render correctly if I do:

Q3View_StartRendering(view);
Q3Shader_Submit(MyPhongShader, view);
RenderLevel(view);
Q3Shader_Submit(MyNullShader, view);
RenderRaceOverlay(view);
  Q3View_EndRendering(view);

But then All the windows of my cars are white

It will also render correctly if do:

Q3View_StartRendering(view);
Q3Shader_Submit(MyNullShader, view);
RenderLevel(view);
RenderRaceOverlay(view);
  Q3View_EndRendering(view);

But then of course everything gets rendered with the NullShader.

And yes, the RaceOverlay is a OrderedDisplayGroup with a 
NULLIlluminationShader added to it.

The null shader does work, because I already use it for my background. 
But I suspect that alpha sorting messes things up.

A screenshot of the problem can be seen here:

http://revaro.spymac.com/ShadingProblem.png

(That the small numbers are lighter is deliberately know by me, I know 
how to fix it)

Steven Verstoep
www.revaro.net

Re: Announcing VRML Reader plug-in

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

Il giorno 16/lug/05, alle 21:54, James W. Walker ha scritto:

> I have committed my VRML Reader plug-in to CVS, in the SDK/Extras 
> directory.  I plan to release a package of binaries later today.

Great! Thanks

Pax et Bonum

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

Announcing VRML Reader plug-in

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

I have committed my VRML Reader plug-in to CVS, in the SDK/Extras  
directory.  I plan to release a package of binaries later today.

Re: Using Quesa with Cocoa

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

Il giorno 16/lug/05, alle 09:31, Peter Maddox ha scritto:

> Hello,
>
> I am having trouble getting the QuesaCocoa target to work.  The xCode 
> project file doesn't have it as a target and the older Project Builder 
> target comes back with a bunch of errors.  Some of them I can get rid 
> of by  defining QUESA_OS_COCOA in Quesa.h and editing the code to 
> remove extra errors this causes (I tried adding it to E3CocoaPrefix.h, 
> but it didn't seem to do anything).   I know this isn't the right way 
> to do this so could someone please fix this properly in the CVS for 
> me.
>

the problem is that in the current state QuesaCocoa is broken beyond 
repair, it has to go back to the design table

as suggested by me the 8th of july, we should derived quesa cocoa from 
Carbon adding the drawcontext that is the only Cocoa part,

so QuesaCocoa.framework links with Quesa.framework,

remains to solve the initialization process to register the 
CocoaDrawContext in the system and free it at the end



Pax et Bonum

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

Using Quesa with Cocoa

[Peter M. <pm...@bi...>]

Hello,

I am having trouble getting the QuesaCocoa target to work.  The xCode 
project file doesn't have it as a target and the older Project Builder 
target comes back with a bunch of errors.  Some of them I can get rid 
of by  defining QUESA_OS_COCOA in Quesa.h and editing the code to 
remove extra errors this causes (I tried adding it to E3CocoaPrefix.h, 
but it didn't seem to do anything).   I know this isn't the right way 
to do this so could someone please fix this properly in the CVS for me.

Thanks
Peter.

Re: understanding Q3TriMesh_EmptyData

[Joseph J. S. <jo...@st...>]

At 10:19 AM -0700 7/13/05, James W. Walker wrote:

>You're talking about the triMeshAttributeSet field, not face or 
>vertex attributes, right?

Right.

>   I looked at the source code, and it seems to be doing the right 
>thing:  Getting a new reference to the attribute set on 
>Q3TriMesh_GetData, and releasing that reference on 
>Q3TriMesh_EmptyData.

Hmm, that does sound right.  OK, I'll check whether my own code is 
doing a spurious release of the attribute set.

Thanks,
- Joe

-- 
,------------------------------------------------------------------.
|    Joseph J. Strout         Check out the Mac Web Directory:     |
|    jo...@st...           http://www.macwebdir.com/            |
`------------------------------------------------------------------'

Re: Setting framework details

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

Il giorno 13/lug/05, alle 19:24, James W. Walker ha scritto:

> Steven Verstoep <is...@ma...> wrote:
>
>
>> Also all the quesa headers need to have their roles set to public.
>
> I would have no idea how to do that; I'm much more familiar with 
> CodeWarrior.  Perhaps one of the other developers can handle these 
> changes.
>
>> And of course it would be nice if all properties were set; like
>> version to 1.7 and identifier to com.Company.Quesa or something.
>
> The CodeWarrior framework project uses org.Quesa.Quesa as the bundle 
> ID.
>
>> This would save me an hour every time I download Quesa from CVS.
>
>

just send me (or James) the relevant xcode project with the changes 
that we'll upload it

Pax et Bonum

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

Re: Setting framework details

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

Steven Verstoep <is...@ma...> wrote:

>I have fixed the issue now, but really this is still a fault that
>lies at quesa. The framework needs to have the following changes:
>
>For Target Quesa:
>Installation Path	@executable_path/../Frameworks/
>	Instead of $(HOME)/Library/Frameworks // <-- this caused the
>error
>Other Linker Flags	-seg1addr 0x12000000
>	This is required for prebinding. This causes prebinding for
>me but depending on what you link quesa against this might not work.

I've heard that Apple is no longer recommending prebinding.

>Also all the quesa headers need to have their roles set to public.

I would have no idea how to do that; I'm much more familiar with 
CodeWarrior.  Perhaps one of the other developers can handle these 
changes.

>And of course it would be nice if all properties were set; like
>version to 1.7 and identifier to com.Company.Quesa or something.

The CodeWarrior framework project uses org.Quesa.Quesa as the bundle ID.

>This would save me an hour every time I download Quesa from CVS.

What do you mean, every time?  I would expect that after the first 
time, you'd just be updating.  Or do you mean that you are 
downloading Quesa on multiple computers?
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: understanding Q3TriMesh_EmptyData

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

"Joseph J. Strout" <jo...@st...> wrote:

>I'm trying to get some TriMesh data out of a display group, work
>with it for a while in immediate mode, and then release it, and be
>able to get it again.  I get the data with Q3TriMesh_GetData, whose
>docs say that it will allocate memory, which I must free by calling
>Q3TriMesh_EmptyData.  But once I've done that, calling
>Q3TriMesh_GetData again on the original TQ3GeometryObject gives me a
>TriMesh with no attributes; both texture and diffuse color have been
>lost.
>
>Unfortunately, I'm not set up at the moment to test this under QD3D,
>so I'm unsure whether this is a bug in Quesa, or an error on my
>part. It's acting as though Q3TriMesh_GetData is not actually
>cloning the attributes, yet Q3TriMesh_EmptyData is nonetheless
>releasing them.


You're talking about the triMeshAttributeSet field, not face or 
vertex attributes, right?  I looked at the source code, and it seems 
to be doing the right thing:  Getting a new reference to the 
attribute set on Q3TriMesh_GetData, and releasing that reference on 
Q3TriMesh_EmptyData.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

understanding Q3TriMesh_EmptyData

[Joseph J. S. <jo...@st...>]

I'm trying to get some TriMesh data out of a display group, work with 
it for a while in immediate mode, and then release it, and be able to 
get it again.  I get the data with Q3TriMesh_GetData, whose docs say 
that it will allocate memory, which I must free by calling 
Q3TriMesh_EmptyData.  But once I've done that, calling 
Q3TriMesh_GetData again on the original TQ3GeometryObject gives me a 
TriMesh with no attributes; both texture and diffuse color have been 
lost.

Unfortunately, I'm not set up at the moment to test this under QD3D, 
so I'm unsure whether this is a bug in Quesa, or an error on my part. 
It's acting as though Q3TriMesh_GetData is not actually cloning the 
attributes, yet Q3TriMesh_EmptyData is nonetheless releasing them.

Does anyone have any insight to share?

Thanks,
- Joe

-- 

,------------------------------------------------------------------.
|    Joseph J. Strout         Codenautics: quality Mac software    |
|    jo...@st...           http://codenautics.com/              |
`------------------------------------------------------------------'