quesa-develop — Mailing list for Quesa development

Using OS X framework

[Jeff Q. <jq...@mi...>]

I'm entirely new to Xcode and to frameworks, but I'd like to give the  
latest Quesa's OpenGL renderer a run as I use it in conjunction with  
REALbasic.

I've been able to compile a universal binary framework, but I'm not  
sure how to proceed. I've linked my app to a Quesa.framework folder  
before, but what I get back is a Quesa.build folder. What are my next  
steps?

==
Jeff Quan
jq...@mi...
http://www.jcquan.com/JQportfolio

[ quesa-Bugs-902950 ] Improve view state stack performance

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

Bugs item #902950, was opened at 2004-02-23 12:10
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=902950&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 view state stack performance

Initial Comment:
A  performance bottleneck at present is that pushing/popping the 
view state stack is quite expensive.

This could be improved by doing some kind of lazy-updating of the 
stack, where values would only be pushed if they were changed 
since the view state was 'pushed'.


------- Additional Comments From Dair Grant 2002-04-17 09:58 
-------

Additional comments from Erik Olson:

> Profiling under Quesa did reveal that about one third of cpu 
> time was spent copying and destructing attribute sets on 
> stack pops. An optimization would be to have lazy 
> construction of the stack frame's attribute set. 
> 
> I rely on the stack to unwind hierarchical matrix transforms 
> and infrequent color highlights, so most of the time the 
> attribute set is constant.


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

>Comment By: SourceForge Robot (sf-robot)
Date: 2007-03-14 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-02-27 21:14

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

We're no longer duplicating or destroying attribute sets when the view
state stack is pushed or popped.  The statement of the bug is a bit too
ill-defined to state definitively that it has been "fixed", but I'm not
sure we need the bug around any more.  In the future, performance bugs
should contain specific instructions on how to duplicate a particularly
slow case.

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

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

Re: Lights (was Re: 64 bit version of Quesa)

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

On 13 Mar, 2007, at 17:00, James Walker wrote:

> Roger Holmes wrote:
>
>> No. My mental model is that of the plug-in (shadow) renderer we ship
>> for Quesa, which I wrote. To speed up rendering, I do not do the slow
>> calculations for the texturing, shading, lighting (and shadowing) of
>> a z buffer pixel until I know it is front most. Game programmers have
>> control of their data and can cull lots of stuff which is behind
>> other items, but for fully user defined data this is not easy,
>> probably impossible without using more time than it saves. So for
>> each front most pixel there are dozens behind, and with user defined
>> ordering of the data that means I can save doing the calculations for
>> many of them.
>
> Oh, interesting.  Does your renderer use the GPU or is it all on  
> the CPU?

No it only uses the CPU. Version 3.6 used only one CPU but 4.0 will  
use them all. It is not an interactive renderer but it supports  
shadows and the quality is configurable to balance the complexity of  
the drawing, the available processing power, the time the user is  
willing to wait and the quality required. Turn off the bells and  
whistles and it could be used as an interactive renderer. A user  
visited us on Friday and showed us her 860,000 triangle model, and  
even the interactive renderer was struggling with it, and she was  
willing to wait several minutes for a fully rendered image, and she  
was using 3.6 under Rosetta!


>
> By the way, I notice that Quesa's contributors page has broken  
> links for
> MicroSpot.  Do you have replacements for them?
>


Could it please be changes to reference our home page  
www.microspot.co.uk

Robin Landsbert no longer works for Microspot. I am quite happy to  
credit him, but his e-mail address is no longer valid. Maybe my name  
should be first anyway as I was always more senior than Robin and in  
view of my big speed up exercise a while back.

Although we have an internal development build called 3D World, the  
issued version still is for OS9 on PowerPC (which uses real QuickDraw  
3D). Our shipping OS-X products which use Quesa are called Microspot  
Interiors and Microspot Modeller. We are about to ship a 4.0 version  
of Microspot Interiors for Intel and PowerPC and then we will do the  
extra plugins to make a 4.0 version of Modeller too. The program  
icons will be changing too.

Re: Lights (was Re: 64 bit version of Quesa)

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

Roger Holmes wrote:

> No. My mental model is that of the plug-in (shadow) renderer we ship  
> for Quesa, which I wrote. To speed up rendering, I do not do the slow  
> calculations for the texturing, shading, lighting (and shadowing) of  
> a z buffer pixel until I know it is front most. Game programmers have  
> control of their data and can cull lots of stuff which is behind  
> other items, but for fully user defined data this is not easy,  
> probably impossible without using more time than it saves. So for  
> each front most pixel there are dozens behind, and with user defined  
> ordering of the data that means I can save doing the calculations for  
> many of them.

Oh, interesting.  Does your renderer use the GPU or is it all on the CPU?

By the way, I notice that Quesa's contributors page has broken links for 
MicroSpot.  Do you have replacements for them?
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Lights (was Re: 64 bit version of Quesa)

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

On 13 Mar, 2007, at 01:04, James Walker wrote:

> Roger Holmes wrote:
>
>>> In answer to the question "why do they have to be known before
>>> StartRender time", my answer is: because any OpenGL-based renderer
>>> needs
>>> to have the lights set up before you render anything that should be
>>> lit
>>> by said lights.
>>
>> Well if that is a restriction of OpenGL then fair enough. I just
>> think that no processing of lights can be done until a (non shadow)
>> renderer has the Z buffer set up with depths and references to the
>> triangles, and whilst the renderer builds the list of triangles (and
>> culls some) it could have set up the list of lights whilst it parsed
>> the group structures.
>
> Either I'm misunderstanding you, or you have a mental model of  
> rendering
> that doesn't correspond to the way any of our built-in renderers work.
> There isn't any separate phase of setting up the Z buffer with depths
> and references to triangles.  There's a continuous process of breaking
> triangles into fragments, updating the Z and color buffers with new
> fragment data, and so on.  Once a particular triangle has passed  
> through
> the pipeline, there is no opportunity to change the way it has been  
> lit.

No. My mental model is that of the plug-in (shadow) renderer we ship  
for Quesa, which I wrote. To speed up rendering, I do not do the slow  
calculations for the texturing, shading, lighting (and shadowing) of  
a z buffer pixel until I know it is front most. Game programmers have  
control of their data and can cull lots of stuff which is behind  
other items, but for fully user defined data this is not easy,  
probably impossible without using more time than it saves. So for  
each front most pixel there are dozens behind, and with user defined  
ordering of the data that means I can save doing the calculations for  
many of them.

Roger.

Re: Lights (was Re: 64 bit version of Quesa)

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

Roger Holmes wrote:

>> In answer to the question "why do they have to be known before
>> StartRender time", my answer is: because any OpenGL-based renderer  
>> needs
>> to have the lights set up before you render anything that should be  
>> lit
>> by said lights.
> 
> Well if that is a restriction of OpenGL then fair enough. I just  
> think that no processing of lights can be done until a (non shadow)  
> renderer has the Z buffer set up with depths and references to the  
> triangles, and whilst the renderer builds the list of triangles (and  
> culls some) it could have set up the list of lights whilst it parsed  
> the group structures.

Either I'm misunderstanding you, or you have a mental model of rendering 
that doesn't correspond to the way any of our built-in renderers work. 
There isn't any separate phase of setting up the Z buffer with depths 
and references to triangles.  There's a continuous process of breaking 
triangles into fragments, updating the Z and color buffers with new 
fragment data, and so on.  Once a particular triangle has passed through 
the pipeline, there is no opportunity to change the way it has been lit.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Lights (was Re: 64 bit version of Quesa)

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

On 12 Mar, 2007, at 19:54, James Walker wrote:

> Roger Holmes wrote (on 2/17/07):
>
>> I would like to go back to being able to store lights in display  
>> groups,
>> preferably so that when their group gets submitted, they get added
>> to the light group so that I would no longer have to do a pre-pass
>> to read all the lights and add them to the light group myself with
>> their correct transforms and then afterward remove them from the
>> light group. Lights are real things in the real world, we do not need
>> to do anything with them until EndRender time, so why do they
>> have to be known before StartRender time?
>
> While I agree that it would be nice to be able to have lights anywhere
> in the scene, I don't know how to do it without two passes.
>
> I don't know what you mean by "go back to being able to store  
> lights in
> display groups".  When was this possible?  The QD3D manual says: "A
> display group is a group of objects that are drawable. Drawable  
> objects
> include geometric objects, styles, transforms, attributes and  
> attribute
> sets, and other display groups."  No mention of lights.

I think the manual was published after version 1.0 shipped. We had a  
series of much more detailed specs up to that time (I wish I still  
had them - some tidy person threw them away because 'we have the  
proper manual now'). I think it was about version 1.2 that Apple made  
display groups reject the adding of a light. Not that they ever had  
any effect, I always had to do a rendering pre-pass. Now I have to do  
pre-passes before rendering, before saving (to convert lights to  
custom attributes and custom light groups to display groups) and do a  
post pass after reading to convert them back again. I also do special  
processing during  the finding of bounding boxes and bounding balls  
so that they include the lights, and have to have light widgets so  
that picking works.

>
> In answer to the question "why do they have to be known before
> StartRender time", my answer is: because any OpenGL-based renderer  
> needs
> to have the lights set up before you render anything that should be  
> lit
> by said lights.

Well if that is a restriction of OpenGL then fair enough. I just  
think that no processing of lights can be done until a (non shadow)  
renderer has the Z buffer set up with depths and references to the  
triangles, and whilst the renderer builds the list of triangles (and  
culls some) it could have set up the list of lights whilst it parsed  
the group structures.

Lights (was Re: 64 bit version of Quesa)

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

Roger Holmes wrote (on 2/17/07):

> I would like to go back to being able to store lights in display groups,
> preferably so that when their group gets submitted, they get added
> to the light group so that I would no longer have to do a pre-pass
> to read all the lights and add them to the light group myself with
> their correct transforms and then afterward remove them from the
> light group. Lights are real things in the real world, we do not need
> to do anything with them until EndRender time, so why do they
> have to be known before StartRender time?

While I agree that it would be nice to be able to have lights anywhere 
in the scene, I don't know how to do it without two passes.

I don't know what you mean by "go back to being able to store lights in 
display groups".  When was this possible?  The QD3D manual says: "A 
display group is a group of objects that are drawable. Drawable objects
include geometric objects, styles, transforms, attributes and attribute 
sets, and other display groups."  No mention of lights.

In answer to the question "why do they have to be known before 
StartRender time", my answer is: because any OpenGL-based renderer needs 
to have the lights set up before you render anything that should be lit 
by said lights.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

New RayShade renderer for XCode

[Sauro A. <int...@in...>]

We ported  RayShade renderer to XCode.

Project, binaries and modified source files are downloadable from the 
following address:

http://www.interstudio.net/quesa/RayShade/Rayshade.zip

RayShade is a Quesa plugin renderer with raytracing, casted shadows 
and antialiasing.

To use the shader, it must be placed in one of the following folders:

- Plugin folder inside the application package
- Library/CFMSupport
- User/Library/CFMSupport

I posted a Geom-test application with inside the shader:

http://www.interstudio.net/quesa/RayShade/Geom_Test_MachO_D.zip


Sauro
-- 
-----------------------------------------------------------------------------
  _ ___
|_| __|  Interstudio S.r.l.      Tel + 39 0573 99291   Fax   + 39 0573 992930
| |__ |  Piazza Monteoliveto 6a                    http://www.interstudio.net
|_____|  I-51100 Pistoia Italy             mailto:int...@in...
-----------------------------------------------------------------------------

Re: Cartoon Renderer Bug

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

Stefan Huber wrote:
> It seems that the cartoon renderer does not fully initialize the 
> OpenGL renderer.
> 
> Rendering a Polyhedron (will be decomposed) fails; rendering a 
> Trimesh works correctly.
> In "CCartoonRendererQuesa::Cartoon_Geometry_Submit_TriMesh"
> "GetParentRendererMethod( kQ3GeometryTypeTriMesh )" crashes.
> 
> The crash does not happen If the Polyhedron will be rendered with the 
> OpenGL renderer first and then with the cartoon renderer.

You're right, thanks for the bug report.  I have committed a fix.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Cartoon Renderer Bug

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

It seems that the cartoon renderer does not fully initialize the 
OpenGL renderer.

Rendering a Polyhedron (will be decomposed) fails; rendering a 
Trimesh works correctly.
In "CCartoonRendererQuesa::Cartoon_Geometry_Submit_TriMesh"
"GetParentRendererMethod( kQ3GeometryTypeTriMesh )" crashes.

The crash does not happen If the Polyhedron will be rendered with the 
OpenGL renderer first and then with the cartoon renderer.

Stefan
__________
www.topoi.ch

Re: VC++ 6.0

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

Il giorno 03/mar/07, alle ore 07:49, Jose' Cruanyes ha scritto:

>>
>> When I tried a more standard definition of E3Num_Max and E3Num_Min, I
>> was surprised to find that we weren't using them directly with mixed
>> types, the only problem was with E3Num_Clamp.  So, I wrote a template
>> version of E3Num_Clamp that casts its second and third parameters to
>> match the type of the first parameter.
>
>
> the fact is that there are mix of types detected by Visual_C...
> I'll investigate, and eventually add a cast in code...
>

The fact is that I have to wake up before post....

Quesa on Visual Studio 2005 compiles beautifully now, Thanks

Pax et Bonum

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

Re: VC++ 6.0

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

Il giorno 03/mar/07, alle ore 00:25, James Walker ha scritto:

> Jose' Cruanyes wrote:
>> Il giorno 01/mar/07, alle ore 18:33, James W. Walker ha scritto:
>>
>>> or we could change E3Num_Max to be a function template defined
>>> exactly like std::max.
>>>
>>
>> taked... I'm leaving now (CET here) if tomorrow is still to do, I'll
>> do it.
>
> So, where did you get that template implementation?

my own... my wrong own...

>
> When I tried a more standard definition of E3Num_Max and E3Num_Min, I
> was surprised to find that we weren't using them directly with mixed
> types, the only problem was with E3Num_Clamp.  So, I wrote a template
> version of E3Num_Clamp that casts its second and third parameters to
> match the type of the first parameter.


the fact is that there are mix of types detected by Visual_C...
I'll investigate, and eventually add a cast in code...


>
> I've committed an update to E3Utils.h with the new template  
> definitions.




> -- 
>    James W. Walker, Innoventive Software LLC
>    <http://www.frameforge3d.com/>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

Pax et Bonum

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

Re: VC++ 6.0

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

Jose' Cruanyes wrote:
> Il giorno 01/mar/07, alle ore 18:33, James W. Walker ha scritto:
> 
>> or we could change E3Num_Max to be a function template defined
>> exactly like std::max.
>>
> 
> taked... I'm leaving now (CET here) if tomorrow is still to do, I'll  
> do it.

So, where did you get that template implementation?  It's not the one 
used in Xcode or in CodeWarrior.  Those reference casts looked 
suspicious, so I tried it out...

	float	res1 = E3Num_Max( 23, 1.0f );
	float	res2 = E3Num_Max( 23, 100.0f );
	float	res3 = E3Num_Max( 1.0f, 23 );
	float	res4 = E3Num_Max( 100.0f, 23 );

The results I saw were 1e+9, 1e+9, 1.0, and 100.0 respectively.  Not good.

The answer to my original question "what is the advantage of using 
E3Num_Max rather than std::max?" seems to be: std::max does not allow 
operands of mixed type.  Not only can you not mix int and float, you 
can't mix int and unsigned long.  See 
<http://www.aristeia.com/Papers/C++ReportColumns/jan95.pdf> for a 
discussion of these issues.

When I tried a more standard definition of E3Num_Max and E3Num_Min, I 
was surprised to find that we weren't using them directly with mixed 
types, the only problem was with E3Num_Clamp.  So, I wrote a template 
version of E3Num_Clamp that casts its second and third parameters to 
match the type of the first parameter.

I've committed an update to E3Utils.h with the new template definitions.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Codewarrior 9

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

Il giorno 02/mar/07, alle ore 21:18, James Walker ha scritto:

> Too bad you didn't get CodeWarrior 10 when they were selling that for
> $99.  I'll add some XML project files.

I'm using it almost only to build win32 binaries...

Pax et Bonum

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

Re: Codewarrior 9

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

Jose' Cruanyes wrote:
> I'm still using (?) the old Codewarrior 8, and have no access to CW9,  
> so the new projects are unusable to me
> 
> To solve this problem we can put on CVS the XML export instead of the  
> binary project, but obviously I can't do it

Too bad you didn't get CodeWarrior 10 when they were selling that for 
$99.  I'll add some XML project files.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Codewarrior 9

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

I'm still using (?) the old Codewarrior 8, and have no access to CW9,  
so the new projects are unusable to me

To solve this problem we can put on CVS the XML export instead of the  
binary project, but obviously I can't do 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: VC++ 6.0

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

Il giorno 01/mar/07, alle ore 18:33, James W. Walker ha scritto:

> or we could change E3Num_Max to be a function template defined
> exactly like std::max.
>

taked... I'm leaving now (CET here) if tomorrow is still to do, I'll  
do 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: VC++ 6.0

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

On Mar 1, 2007, at 9:23 AM, Jose' Cruanyes wrote:

>>  Now that we
>> compile as C++, what is the advantage of using E3Num_Max rather than
>> std::max?  There is a disadvantage, that the operands are evaluated
>> twice.
>
> max is #defined in VC, leading to compilation errors,
>
> if we find a way to detect availability of std::max, we can define
> E3Num_Max, in terms of std::max, or just define it based in  
> platform...

The CodeWarrior version of <algorithm> says

#ifdef max
#undef max
#endif

before defining std::max, we could do that...

or we could change E3Num_Max to be a function template defined  
exactly like std::max.

Re: VC++ 6.0

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

Il giorno 01/mar/07, alle ore 18:11, James W. Walker ha scritto:

> Sounds like a good idea to me!

Stomp!!! (dropped :-)

>  Now that we
> compile as C++, what is the advantage of using E3Num_Max rather than
> std::max?  There is a disadvantage, that the operands are evaluated
> twice.

max is #defined in VC, leading to compilation errors,

if we find a way to detect availability of std::max, we can define  
E3Num_Max, in terms of std::max, or just define it based in platform...


Pax et Bonum

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

Re: VC++ 6.0

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

On Mar 1, 2007, at 6:03 AM, Jose' Cruanyes wrote:

> I'm asking permission to drop support for VC++ 6.0 to build Quesa
>
> It does'n support a bunch of common C++ constructs, and I should
> modify too many James' sources
> Once we have no choice but support it, but now with the Visual Studio
> 2005  freely downloadable, it's not a problem anymore

Sounds like a good idea to me!

> in the meanwhile I'm updating the VS 2005 projects to include the
> OpenGL renderer

One question about the changes you checked in today:  Now that we  
compile as C++, what is the advantage of using E3Num_Max rather than  
std::max?  There is a disadvantage, that the operands are evaluated  
twice.

Re: VC++ 6.0

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

Il giorno 01/mar/07, alle ore 16:59, Daniele Cavallini ha scritto:

> Are you sure the Visual Studio2005  is  freely downloadable?
>

Well not Visual Studio, but Visual C++ 2005 Express
all you need to compile Quesa

http://www.microsoft.com/italy/msdn/prodotti/vs2005/editions/download/ 
vc.mspx


Pax et Bonum

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

Re: VC++ 6.0

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

Are you sure the Visual Studio2005  is  freely downloadable?

Jose' Cruanyes ha scritto:
> I'm asking permission to drop support for VC++ 6.0 to build Quesa
>
> It does'n support a bunch of common C++ constructs, and I should  
> modify too many James' sources
> Once we have no choice but support it, but now with the Visual Studio  
> 2005  freely downloadable, it's not a problem anymore
>
> in the meanwhile I'm updating the VS 2005 projects to include the  
> OpenGL renderer
>
> Pax et Bonum
>
> # dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
> #  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
> #   02,33603122                0372,460602
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>
>   

VC++ 2005 Project updated

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

I've updated the VC++2005 project to compile the latest modifications  
in rendering.



Pax et Bonum

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

VC++ 6.0

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

I'm asking permission to drop support for VC++ 6.0 to build Quesa

It does'n support a bunch of common C++ constructs, and I should  
modify too many James' sources
Once we have no choice but support it, but now with the Visual Studio  
2005  freely downloadable, it's not a problem anymore

in the meanwhile I'm updating the VS 2005 projects to include the  
OpenGL renderer

Pax et Bonum

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