quesa-develop — Mailing list for Quesa development

Problem with shadow render opengl

[Daniele C. <dca...@in...>]

For obtain an image with a good resolution I use TQ3PixmapDrawContextData.
It is work fine but if I use Quesa shared render opengl I don't see shadow.
The function is this:
/
TQ3DrawContextObject MyNewDrawContext(long larg,long alt)
{
    TQ3PixmapDrawContextData myDrawContextData;
    CRect                    srcRect ;
    TQ3ColorARGB                coloreSfondo;

    coloreSfondo.r=(float) (GetRValue(gPOG.coloreSfondo3D)/255.);//copia 
RGBColor in TQ3ColorRGB É
    coloreSfondo.g=(float) (GetGValue(gPOG.coloreSfondo3D)/255.);//É 
convertendo dal range 0..65535 É
    coloreSfondo.b=(float) (GetBValue(gPOG.coloreSfondo3D)/255.);//É al 
range 0,0..1,0
    coloreSfondo.a=1;// alfa channel = 1 (solid)
   

    myDrawContextData.drawContextData.clearImageMethod = 
kQ3ClearMethodWithColor;
    myDrawContextData.drawContextData.clearImageColor  = coloreSfondo;
    myDrawContextData.drawContextData.paneState = kQ3False;
    myDrawContextData.drawContextData.maskState = kQ3False;
    myDrawContextData.drawContextData.doubleBufferState = kQ3False;
    srcRect.SetRect(0,0,larg,alt);
    myDrawContextData.pixmap.width = srcRect.right  - srcRect.left;
    myDrawContextData.pixmap.height= srcRect.bottom - srcRect.top;

    myDrawContextData.pixmap.pixelSize=32;
    myDrawContextData.pixmap.rowBytes = 
Pixmap_GetRowBytes(myDrawContextData.pixmap.width,myDrawContextData.pixmap.pixelSize);

    myDrawContextData.pixmap.pixelType = kQ3PixelTypeRGB32;
    myDrawContextData.drawContextData.paneState=kQ3True;
    myDrawContextData.drawContextData.pane.min.x=(float)srcRect.left;
    myDrawContextData.drawContextData.pane.min.y=(float)srcRect.top;
    myDrawContextData.drawContextData.pane.max.x=(float)srcRect.right;
    myDrawContextData.drawContextData.pane.max.y=(float)srcRect.bottom;

    myDrawContextData.pixmap.bitOrder  = kQ3EndianLittle;
    myDrawContextData.pixmap.byteOrder = kQ3EndianLittle;


    pBits = (BYTE*) 
malloc(myDrawContextData.pixmap.rowBytes*myDrawContextData.pixmap.height);
    
::ZeroMemory(pBits,myDrawContextData.pixmap.rowBytes*myDrawContextData.pixmap.height);

    myDrawContextData.pixmap.image = pBits ;


    return Q3PixmapDrawContext_New(&myDrawContextData);
}
/

It Maybe the problem is not here.
Have you some advice?
Thanks

[ quesa-Bugs-902964 ] Polyline should cache transparent state

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

Bugs item #902964, was opened at 2004-02-23 12:29
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=902964&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: Closed
Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Polyline should cache transparent state

Initial Comment:
The polyline geometry should cache if it contains transparent 
attributes or not, and invalidate its cache when its edit index 
changes.

Would save interactive renderer from calculating this state each 
time.

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

>Comment By: SourceForge Robot (sf-robot)
Date: 2007-07-25 19:20

Message:
Logged In: YES 
user_id=1312539
Originator: NO

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

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

Comment By: James W. Walker (jwwalker)
Date: 2007-07-11 15:21

Message:
Logged In: YES 
user_id=433183
Originator: NO

I think we should generally not introduce performance optimizations
without first seeing a case where the particular operation shows up as a
significant percentage on a performance profile.

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

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

[ quesa-Feature Requests-1256902 ] Custom Renders for Reflections and Shadows

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

Feature Requests item #1256902, was opened at 2005-08-11 10:19
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442055&aid=1256902&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: Closed
Priority: 5
Private: No
Submitted By: MacFan (granit)
Assigned to: Nobody/Anonymous (nobody)
Summary: Custom Renders for Reflections and Shadows

Initial Comment:
As I was reading the Quick Draw 3D files at apple.com I Found that 
it supports Custom renders so I could create my own or use another. 
This means I could use raytracing to create Reflection and I knew a 
lot of people want quesa to have reflects.  Even Alias's Maya, which 
uses opengl as well, needs to use raytracing to do reflections.

This is the same with shadows, because these days it's done by the 
hardware, not software.  So we could use the video card to make 
shadows

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

>Comment By: SourceForge Robot (sf-robot)
Date: 2007-07-24 19:20

Message:
Logged In: YES 
user_id=1312539
Originator: NO

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

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

Comment By: James W. Walker (jwwalker)
Date: 2007-07-10 14:32

Message:
Logged In: YES 
user_id=433183
Originator: NO

We have the RayShade raytracing renderer, and the OpenGL renderer can now
do shadows (but not reflections).

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

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

[ quesa-Bugs-901440 ] Wireframe renderer does not support hilighting

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

Bugs item #901440, was opened at 2004-02-20 14:46
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=901440&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: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wireframe renderer does not support hilighting

Initial Comment:
The Wireframe OpenGL renderer does not currently support the 
hilight style.

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

>Comment By: SourceForge Robot (sf-robot)
Date: 2007-07-24 19:20

Message:
Logged In: YES 
user_id=1312539
Originator: NO

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

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

Comment By: James W. Walker (jwwalker)
Date: 2007-07-10 17:38

Message:
Logged In: YES 
user_id=433183
Originator: NO

Now that the wireframe renderer derives from the OpenGL renderer, this bug
seems to have gone away.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=901440&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 (Comment added) made by sf-robot
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: Closed
Priority: 5
Private: No
Submitted By: Dair Grant (grantd)
Assigned to: James W. Walker (jwwalker)
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.

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

>Comment By: SourceForge Robot (sf-robot)
Date: 2007-07-24 19:20

Message:
Logged In: YES 
user_id=1312539
Originator: NO

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

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

Comment By: James W. Walker (jwwalker)
Date: 2007-07-10 13:40

Message:
Logged In: YES 
user_id=433183
Originator: NO

I have implemented the FSRef storage APIs, however FSRef storage objects
are actually the same class of object as FSSpec storage objects.

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

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

Re: Quesa (not) on Mac OS X 10.2.x

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

Stefan Huber wrote:
> I've found the issue:
> 
> E3MacDrawContext.c, revision 1.40 of June 7
> E3MacDrawContext_RegisterClass/E3MacDrawContext_UnregisterClass
> 
> console log message:
> Quesa undefined reference to 
> _CGDisplayRegisterReconfigurationCallback expected to be defined in 
> Carbon
> Quesa undefined reference to _CGDisplayRemoveReconfigurationCallback 
> expected to be defined in Carbon
> 
> This happens under Mac OS X 10.2.0 till 10.2.8. Mac OS X 10.3.9 and 
> higher is ok (10.3.0 not tested).

I see.  My fault.  I have checked in a change that should fix it for you.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Quesa (not) on Mac OS X 10.2.x

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

I've found the issue:

E3MacDrawContext.c, revision 1.40 of June 7
E3MacDrawContext_RegisterClass/E3MacDrawContext_UnregisterClass

console log message:
Quesa undefined reference to 
_CGDisplayRegisterReconfigurationCallback expected to be defined in 
Carbon
Quesa undefined reference to _CGDisplayRemoveReconfigurationCallback 
expected to be defined in Carbon

This happens under Mac OS X 10.2.0 till 10.2.8. Mac OS X 10.3.9 and 
higher is ok (10.3.0 not tested).

   Stefan
   http://www.topoi.ch

Re: Quesa (not) on Mac OS X 10.2.x

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

Stefan Huber wrote:
> Both the application and the Quesa framework are built with CW (Mach-O).

Are you building using the 10.2.8 SDK?

> The crash log says after calling Q3GetReleaseVersion (the first Quesa 
> related call)
> 
>   #0   0x8fe01280 in halt
>   #1   0x8fe106b4 in link_in_need_modules
>   #2   0x8fe102d0 in bind_lazy_symbol_reference
>   #3   0x8fe00ec0 in stub_binding_helper_interface

Surely there is more to the log than those 4 lines.

Does any message appear in the console log when the crash happens?

Are there any Quesa plug-ins involved?  Did you use any of the 
draw-region APIs, which have been removed?
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Quesa (not) on Mac OS X 10.2.x

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

Both the application and the Quesa framework are built with CW (Mach-O).

The crash log says after calling Q3GetReleaseVersion (the first Quesa 
related call)

  #0   0x8fe01280 in halt
  #1   0x8fe106b4 in link_in_need_modules
  #2   0x8fe102d0 in bind_lazy_symbol_reference
  #3   0x8fe00ec0 in stub_binding_helper_interface

   Stefan
   http://www.topoi.ch

>On Jul 22, 2007, at 3:17 PM, Stefan Huber wrote:
>
>  > With the latest Quesa build my CW Mach-O application does not work 
>>  on Mac OS X 10.2.x anymore.
>
>Are you building Quesa with CW?  Or do you mean an app built with CW 
>but using Quesa built with Xcode?
>
>>  The Quesa framework cannot be linked (lazy symbol refs). The Quesa
>  > build of March 2007 works.
>
>What exactly is the link error?

Re: Quesa (not) on Mac OS X 10.2.x

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

On Jul 22, 2007, at 3:17 PM, Stefan Huber wrote:

> With the latest Quesa build my CW Mach-O application does not work  
> on Mac OS X 10.2.x anymore.

Are you building Quesa with CW?  Or do you mean an app built with CW  
but using Quesa built with Xcode?

> The Quesa framework cannot be linked (lazy symbol refs). The Quesa  
> build of March 2007 works.

What exactly is the link error?

Quesa (not) on Mac OS X 10.2.x

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

With the latest Quesa build my CW Mach-O application does not work on 
Mac OS X 10.2.x anymore. The Quesa framework cannot be linked (lazy 
symbol refs). The Quesa build of March 2007 works.

   Stefan
   http://www.topoi.ch

Re: quesa/Development/Source/Renderers/Common GLDrawContext.c, 1.63, 1.64

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

Jose' Cruanyes wrote:
> Il giorno 24/mag/07, alle ore 00:51, James W. Walker ha scritto:
> 
>> Update of /cvsroot/quesa/quesa/Development/Source/Renderers/Common
>> In directory sc8-pr-cvs16.sourceforge.net:/tmp/cvs-serv18759/quesa/ 
>> Development/Source/Renderers/Common
>>
>> Modified Files:
>> 	GLDrawContext.c
>> Log Message:
>> In gldrawcontext_win_new, try to fail more gracefully when  
>> SetPixelFormat fails to change the pixel format.
>>
>> Index: GLDrawContext.c
>> ===================================================================
>> RCS file: /cvsroot/quesa/quesa/Development/Source/Renderers/Common/ 
>> GLDrawContext.c,v
>> retrieving revision 1.63
>> retrieving revision 1.64
>> diff -C2 -d -r1.63 -r1.64
>> *** GLDrawContext.c	18 May 2007 23:47:36 -0000	1.63
>> --- GLDrawContext.c	23 May 2007 22:51:11 -0000	1.64
>> ***************
>> *** 1615,1618 ****
>> --- 1615,1620 ----
>>   		goto fail;
>>
>> + 	int	prevPixelFormat = GetPixelFormat( theContext->theDC );
>> + 	
>>       if (!SetPixelFormat(theContext->theDC, pixelFormat,  
>> &pixelFormatDesc))
>>   	{
>> ***************
>> *** 1623,1628 ****
>>   		E3Assert( __FILE__, __LINE__, theString );
>>   	#endif
>> ! 		Q3Error_PlatformPost(error);
>> !     	goto fail;
>>   	}
>>
>> --- 1625,1640 ----
>>   		E3Assert( __FILE__, __LINE__, theString );
>>   	#endif
>> ! 		
>> ! 		// The docs on SetPixelFormat say that "Once a window's pixel  
>> format is
>> ! 		// set, it cannot be changed".  In that case, try falling back  
>> to the
>> ! 		// previous format.
>> ! 		
>> ! 		pixelFormat = prevPixelFormat;
>> ! 		
>> ! 		if ( (pixelFormat == 0) || !SetPixelFormat(theContext->theDC,  
>> pixelFormat, &pixelFormatDesc) )
>> ! 		{
>> ! 			Q3Error_PlatformPost(error);
>> ! 	    	goto fail;
>> ! 		}
>>   	}
> 
> 
> We've found that this change (or another triggered by this) cause  
> crashes on certain machines, when rebuilding the drawContext...
> 
> if we open a window, print it (creating a pixmap DC), when rebuilding  
> the window, quesa crashes when trying to swap buffers at the end of  
> the first, render loop
> 
> the machine has an onboard SIS video adaptor, so I think it's using  
> the software renderer
> 
> throwing an error if SetPixelFormat fails, solves the problem (my  
> program tries to rebuild the Drawcontext in the next update event and  
> then it works)
> 
> any ideas?

I don't know why this change would cause a problem, but if you want to 
revert it, I won't be upset.

As I recall, I noticed a problem with SetPixelFormat when switching to 
shadow rendering in Geom Test.  That requires a stencil buffer, where 
none had been requested before, hence a change in pixel format.  Of 
course my change did not actually solve that problem.  One really needs 
to request a stencil buffer at the beginning if there is any chance that 
a stencil buffer will be needed later.

If you do revert the change, please leave a comment that a window's 
pixel format cannot be set more than once, so that the next time 
SetPixelFormat fails, I won't have to figure it out again.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Cocoa/Carbon unification

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

I've made the Quesa framework able to handle both Cocoa and Carbon  
draw contexts.  I don't use Cocoa day to day, but I modified the  
Cocoa example to use Quesa.framework, and it seems to work.   Let me  
know if any problems show up.

[ quesa-Bugs-902964 ] Polyline should cache transparent state

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

Bugs item #902964, was opened at 2004-02-23 12:29
Message generated for change (Comment added) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=902964&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: Wont Fix
Priority: 5
Private: No
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Polyline should cache transparent state

Initial Comment:
The polyline geometry should cache if it contains transparent 
attributes or not, and invalidate its cache when its edit index 
changes.

Would save interactive renderer from calculating this state each 
time.

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

>Comment By: James W. Walker (jwwalker)
Date: 2007-07-11 15:21

Message:
Logged In: YES 
user_id=433183
Originator: NO

I think we should generally not introduce performance optimizations
without first seeing a case where the particular operation shows up as a
significant percentage on a performance profile.

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

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

[ quesa-Bugs-901422 ] Improve kQ3ShaderUVBoundaryClamp handling

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

Bugs item #901422, was opened at 2004-02-20 14:35
Message generated for change (Comment added) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=901422&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: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Improve kQ3ShaderUVBoundaryClamp handling

Initial Comment:
If GL_CLAMP_TO_EDGE is available, the Interactive Renderer 
should implement kQ3ShaderUVBoundaryClamp with this 
extension in preference to GL_EDGE.

This helps avoid seams between otherwise adjacent textures.

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

>Comment By: James W. Walker (jwwalker)
Date: 2007-07-10 17:49

Message:
Logged In: YES 
user_id=433183
Originator: NO

This was fixed in Oct. 2004, we just forgot to close the bug.

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

Comment By: Dair Grant (grantd)
Date: 2004-07-15 09:48

Message:
Logged In: YES 
user_id=439944

Yes, sorry - GL_CLAMP and GL_REPEAT are the built-ins (that we 
currently use) while GL_CLAMP_TO_EDGE was the final name for the 
extension (which we should use if it's available).

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

Comment By: James W. Walker (jwwalker)
Date: 2004-07-15 09:29

Message:
Logged In: YES 
user_id=433183

You mean GL_CLAMP, there is no such thing as GL_EDGE.

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

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

[ quesa-Bugs-901439 ] Hilight state does not match QD3D results

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

Bugs item #901439, was opened at 2004-02-20 14:45
Message generated for change (Comment added) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=901439&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: Closed
>Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Hilight state does not match QD3D results

Initial Comment:
Fred Mandrea has an example demonstrating the way in which 
Quesa renders an object with a hilight style different to Quesa.
        
Note that this happens with either the QD3D or the Quesa 
renderer, so the bug must be in the Quesa library rather than in 
the OpenGL code.
        
Fred's example was at http://homepage.mac.com/genfred/
quesa3.html (no longer online).

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

>Comment By: James W. Walker (jwwalker)
Date: 2007-07-10 17:40

Message:
Logged In: YES 
user_id=433183
Originator: NO

With no access to an example, there is no way to know if there is still a
bug here.

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

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

[ quesa-Bugs-901440 ] Wireframe renderer does not support hilighting

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

Bugs item #901440, was opened at 2004-02-20 14:46
Message generated for change (Comment added) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=901440&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
Private: No
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wireframe renderer does not support hilighting

Initial Comment:
The Wireframe OpenGL renderer does not currently support the 
hilight style.

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

>Comment By: James W. Walker (jwwalker)
Date: 2007-07-10 17:38

Message:
Logged In: YES 
user_id=433183
Originator: NO

Now that the wireframe renderer derives from the OpenGL renderer, this bug
seems to have gone away.

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

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

[ quesa-Bugs-967639 ] Nanosaur Overview Map not transparent

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

Bugs item #967639, was opened at 2004-06-06 08:19
Message generated for change (Comment added) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967639&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: Closed
>Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Lane Roathe (raving)
Assigned to: Nobody/Anonymous (nobody)
Summary: Nanosaur Overview Map not transparent

Initial Comment:
With the latest version of Quesa from cvs (6/1/4) the
overview map in Nanosaur (for Windows) is not
transparent. Using the cvs version from 2/1/3 the map
is correctly transparent.

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

>Comment By: James W. Walker (jwwalker)
Date: 2007-07-10 16:24

Message:
Logged In: YES 
user_id=433183
Originator: NO

Too old, no response to question.

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

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

Message:
Logged In: YES 
user_id=439944

Can you try rolling back IRTransparent to before 1.16? (you may need 
other bits as well, so try a version from CVS at 2004/01/01).

That was the point where transparent prims were submitted in frustum 
coordinates rather than world coordinates, and the QD3D->GL camera 
code changed to using pushing matrices through.

One of those two are probably the culprit.

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

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

[ quesa-Bugs-967641 ] Flickering objects (shading?)

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

Bugs item #967641, was opened at 2004-06-06 08:21
Message generated for change (Comment added) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967641&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: Closed
>Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Lane Roathe (raving)
Assigned to: Nobody/Anonymous (nobody)
Summary: Flickering objects (shading?)

Initial Comment:
Using the 6/1/4 cvs version of Quesa, there are
flickering (triangles?) objects in Nanosaur for
Windows; these look like they might be "shadows" or
other shading objects being drawn incorrectly.

The version of Quesa I am using from 2/1/3 does not
have these artifacts.


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

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

Message:
Logged In: YES 
user_id=433183
Originator: NO

Too old, too vague, no response to the question.

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

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

Message:
Logged In: YES 
user_id=439944

This is probably the depth buffer - we ask for a deeper buffer now than 
we used to and although GL should fall back automatically perhaps it's 
not on this machine.

Can you try tweaking the depthBits value used in gldrawcontext_win_new 
in GLDrawContext.c, and see how using 16/24/32 affects it?

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

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

[ quesa-Feature Requests-1256902 ] Custom Renders for Reflections and Shadows

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

Feature Requests item #1256902, was opened at 2005-08-11 10:19
Message generated for change (Comment added) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442055&aid=1256902&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
Priority: 5
Private: No
Submitted By: MacFan (granit)
Assigned to: Nobody/Anonymous (nobody)
Summary: Custom Renders for Reflections and Shadows

Initial Comment:
As I was reading the Quick Draw 3D files at apple.com I Found that 
it supports Custom renders so I could create my own or use another. 
This means I could use raytracing to create Reflection and I knew a 
lot of people want quesa to have reflects.  Even Alias's Maya, which 
uses opengl as well, needs to use raytracing to do reflections.

This is the same with shadows, because these days it's done by the 
hardware, not software.  So we could use the video card to make 
shadows

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

>Comment By: James W. Walker (jwwalker)
Date: 2007-07-10 14:32

Message:
Logged In: YES 
user_id=433183
Originator: NO

We have the RayShade raytracing renderer, and the OpenGL renderer can now
do shadows (but not reflections).

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442055&aid=1256902&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 (Comment added) 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: Pending
Priority: 5
Private: No
Submitted By: Dair Grant (grantd)
>Assigned to: James W. Walker (jwwalker)
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.

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

>Comment By: James W. Walker (jwwalker)
Date: 2007-07-10 13:40

Message:
Logged In: YES 
user_id=433183
Originator: NO

I have implemented the FSRef storage APIs, however FSRef storage objects
are actually the same class of object as FSSpec storage objects.

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

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

Re: Time for Classic Mac to go?

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

>Now that I'm thinking about removing deprecated and otherwise dusty 
>code, do we still need to support Classic?  I'm not talking about
>assuming OS X yet, we could still run under OS 9 with Carbon.

Fine to me too. I'm using Carbon on OS X only.

Stefan

Re: Time for Classic Mac to go?

[<jo...@st...>]

On Jul 10, 2007, at 17:07 UTC, Jim Witte wrote:

> > Does anyone use it in a non Mac environment?
> 
> Game developers that might use Quesa might like the portability.  But
> then, does *anyone* (aside from PangeaSoft) use Quesa/QD3D for  
> games?

Yes!  I feel like I'm repeating myself a lot here, but just to be clear:

The built-in 3D capabilities of REALbasic are built on Quesa/QD3D. 
REALbasic is a very popular development environment on Mac, Windows,
and Linux.  And yes, people use REALbasic to write games.  Here are
some of mine:    http://www.codenautics.com/

BrickBall, Armageddon, and Zombies are all using Quesa/QD3D (and the
latter two have been quite popular, too, generating a lot of positive
comments; Armageddon even won a Mac game programming contest).

So yes, there are a lot of Quesa developers out there, both for games
and for non-games -- but most of them are using it via REALbasic.

Best,
- Joe

--
Joe Strout -- jo...@st... | Fusion power may be practical today.  See:
Strout Custom Solutions, LLC | http://www.strout.net/info/science/polywell

Re: Time for Classic Mac to go?

[Jim W. <js...@bl...>]

> Does anyone use it in a non Mac environment?

Game developers that might use Quesa might like the portability.  But  
then, does *anyone* (aside from PangeaSoft) use Quesa/QD3D for  
games?  I had a feeling everyone just either used a more powerful  
engine that included game-specific stuff (motion control, effects  
built-in, etc), or - does anyone just write their own game engine  
anymore?

Jim ("extreme lurker")

Re: Time for Classic Mac to go?

[<jo...@st...>]

On Jul 10, 2007, at 12:19 UTC, Roger Holmes wrote:

> 
> On 9 Jul, 2007, at 17:27, James W. Walker wrote:
> 
> > OK, I have updated E3MacSystem.c and E3MacStorage.c.  Now the only
> > deprecation warnings I get are from the viewer.  I'm not sure if I
> > want to rewrite that.
> 
> Currently, we don't use it. Does anyone?

Yes, Meshwork uses it.

> Is so votes for Cocoa vs Carbon please.

Carbon.

> Does anyone use it in a non Mac environment?

I don't.  I do think it's a pretty nifty feature, though.

Best,
- Joe

--
Joe Strout -- jo...@st... | Fusion power may be practical today.  See:
Strout Custom Solutions, LLC | http://www.strout.net/info/science/polywell