quesa-develop — Mailing list for Quesa development

Re: Comments about CW8.3 compile.

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

>Yes I did see the changes, and thank-you. I still get three error
>messages from the E3Set.c file.

Oh, I see, I forgot to check that one in.  It's up to date now.

>I also ran up the Xcode version of Quesa and Geom Test, both are
>working. Plus I was able to get shark working. ( I ask the Apple
>speaker about CFM and shark, got the standard answer it should work
>but not sure how....)

I just tried running Shark 4.0.1 on the CFM Geom Test, and it 
worked... even showed source code in Quesa, much to my surprise. 
However I guess my Quesa was built with CW 9.3, perhaps that could 
make a difference.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Comments about CW8.3 compile.

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

Sorry, I did write a reply earlier but there was a problem with the 
email.

Yes I did see the changes, and thank-you. I still get three error 
messages from the E3Set.c file.

I also ran up the Xcode version of Quesa and Geom Test, both are 
working. Plus I was able to get shark working. ( I ask the Apple 
speaker about CFM and shark, got the standard answer it should work but 
not sure how....)

Now the good news, I ran the timer function over the latest version of 
Quesa and it is already 10 percent faster in all the cases tested so 
far. Plus the wireframe issue now seems to be resolved, brilliant.

Peter Michelsen.


On 13 Dec 2004, at 17:22, James W. Walker wrote:

> On Dec 13, 2004, at 1:46 AM, Peter Michelsen wrote:
>
>> I used the cvs download from Sourceforge on Friday 10/12/2004.
>>
>> Yes, I think you are right about the MSL_All_Carbon_D.Lib.
>
> In case you're not subscribed to the CVS mailing list, this weekend I 
> went ahead and updated the CodeWarrior projects for Mac and Windows, 
> and the XCode project.
> --
> <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
>

Re: Comments about CW8.3 compile.

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

On Dec 13, 2004, at 1:46 AM, Peter Michelsen wrote:

> I used the cvs download from Sourceforge on Friday 10/12/2004.
>
> Yes, I think you are right about the MSL_All_Carbon_D.Lib.

In case you're not subscribed to the CVS mailing list, this weekend I 
went ahead and updated the CodeWarrior projects for Mac and Windows, 
and the XCode project.
--
<http://www.jwwalker.com/>

Re: Comments about CW8.3 compile.

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

I used the cvs download from Sourceforge on Friday 10/12/2004.

Yes, I think you are right about the MSL_All_Carbon_D.Lib.

Thanks,
Peter Michelsen


On 10 Dec 2004, at 20:30, James W. Walker wrote:

> Peter Michelsen <Pet...@mi...> wrote:
>
>>  The second change was three type casting need adding.
>
> Are you sure your sources were up to date?  I just compiled the 
> project as C++ in CW 8.3 and did not get any compile errors.
>
>> The third change and the one I am not sure about which MSL Carbon
>> library should we use? At Microspot we use MSL_All_Carbon.D.Shld for
>> debugging and MSL_All_Carbon.Shld for release versions. This would
>> then replace the library MSL_C_Carbon.Lib currently in Quesa. If
>> this is correct, shall I check-in the changes?
>
> I think it would be more consistent to use the static library 
> versions, like MSL_All_Carbon_D.Lib.
> -- 
>   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
>

[ 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 (Settings changed) 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: Open
>Resolution: Accepted
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: 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: Comments about CW8.3 compile.

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

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

>  The second change was three type casting need adding.

Are you sure your sources were up to date?  I just compiled the 
project as C++ in CW 8.3 and did not get any compile errors.

>The third change and the one I am not sure about which MSL Carbon
>library should we use? At Microspot we use MSL_All_Carbon.D.Shld for
>debugging and MSL_All_Carbon.Shld for release versions. This would
>then replace the library MSL_C_Carbon.Lib currently in Quesa. If
>this is correct, shall I check-in the changes?

I think it would be more consistent to use the static library 
versions, like MSL_All_Carbon_D.Lib.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Comments about CW8.3 compile.

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

Dear Quesa list,

I have a comments about the latest CVS version of Quesa.

I noticed that James W. Walker has been working on GLTextureManager.c 
and now this file must be compile as a C++ file ( plus all the other 
work to allow C++ compiling, fantastic ). The problem, as I see it , is 
that the CW 8.3 project information has not been updated as well.

The first change is to the "Carbon Shlib Settings" is now ticked for 
Force C++ compilation, Enable C++ Exceptions and Enable bool Support.

The second change was three type casting need adding.

The third change and the one I am not sure about which MSL Carbon 
library should we use? At Microspot we use MSL_All_Carbon.D.Shld for 
debugging and MSL_All_Carbon.Shld for release versions. This would then 
replace the library MSL_C_Carbon.Lib currently in Quesa. If this is 
correct, shall I check-in the changes?

As for the Xcode project I do not know where to start but it does not 
compile at the moment....

Peter Michelsen.

Re: Quesa contributors page

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

On Monday, December 6, 2004, at 05:28  pm, James W. Walker wrote:

> You now have the same privileges on SourceForge as I do.  Could the 
> someone be you?

Having the privileges and having the knowledge are different things.
I could get a colleague who composes our company web pages to
do it if is OK with everyone for him to use my privileges for a while.

Re: Quesa contributors page

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

On Dec 6, 2004, at 7:42 AM, Roger Holmes wrote:

> Could somebody please change the link(s) on the contributors page to
> either point to our home page www.microspot.co.uk or to point to
> the two products which use Quesa.

You now have the same privileges on SourceForge as I do.  Could the 
someone be you?
--
<http://www.jwwalker.com/>

Re: C++ and file name extensions

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

On Dec 6, 2004, at 5:20 AM, Roger Holmes wrote:

> If the other platforms allow C++ compiling of .c files then I agree we 
> should go with
> that which lets us to keep the history in a more direct way than 
> replacing all the
> .c files with .cp files.

Hmm, I don't really know about other platforms.  Since Xcode can do it, 
I expect that it's a gcc feature, which covers Unix.  Anyone know 
whether, say, Visual C++ can force C++ compilation of .c files?
--
<http://www.jwwalker.com/>

Quesa contributors page

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

On Friday, December 3, 2004, at 06:31  pm, SourceForge.net wrote:

>  By the
> way, the Quesa contributors page mentions "3D World" but the link is
> dead.
>

Could somebody please change the link(s) on the contributors page to
either point to our home page www.microspot.co.uk or to point to
the two products which use Quesa. For Microspot Interiors:

  http://www.microspot.co.uk/products/interiors.htm

and for Micrsopot Modeller:

http://www.microspot.co.uk/products/modeler.htm


There is still a page for 3D World, but it currently ships as an OS9
version only using QuickDraw 3D. One of our long term goals is
to Carbonise and Aquify almost the whole of it but it is a big job and
we are doing it in stages with Interiors and Modeller being stops
along the way. If you would like to refer to classic 3DWorld it is on:

http://www.microspot.co.uk/products/classic/3Dworld.htm


Also, though I am very happy for you to credit Robin Landsbert 
independently,
he stopped working for Microspot some years ago. As Peter Michelsen
is working on View Hint objects you might like to add his name to the
Microspot entry.

Roger.

Re: C++ and file name extensions

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

On Sunday, December 5, 2004, at 03:04  am, James W. Walker wrote:

> When we change a file to use C++, do we change the file extension to 
> .cpp or some such, messing up the CVS history, or do we leave it at 
> .c, and require that one force C++ compilation of all files?  I'd lean 
> toward the latter.  With CodeWarrior, if you want to use a precompiled 
> header, you pretty much have to make an all or nothing choice anyway.
>

If the other platforms allow C++ compiling of .c files then I agree we 
should go with
that which lets us to keep the history in a more direct way than 
replacing all the
.c files with .cp files.

Thanks for the preparatory work, I had not expected quite so many 
changes just to
get it to compile with C++.

C++ and file name extensions

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

When we change a file to use C++, do we change the file extension to 
.cpp or some such, messing up the CVS history, or do we leave it at .c, 
and require that one force C++ compilation of all files?  I'd lean 
toward the latter.  With CodeWarrior, if you want to use a precompiled 
header, you pretty much have to make an all or nothing choice anyway.
--
<http://www.jwwalker.com/>

preparation for C++

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

Today I am going to be checking in a slew of changes for compatibility 
with C++ compilation.   The majority are added typecasts to make type 
conversions explicit.
--
<http://www.jwwalker.com/>

[ quesa-Bugs-907873 ] Polygon objects not drawn in edge fill style

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

Bugs item #907873, was opened at 2004-03-01 13:33
Message generated for change (Comment added) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=907873&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: Polygon objects not drawn in edge fill style

Initial Comment:
Quesa's interactive renderer does not draw Polygon objects 
correctly in edge mode. QD3D draws the lines making up the 
boundary. The default cube objects in 3D World are composed of 
six polygons. They totally disappear when using Quesa.

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

>Comment By: James W. Walker (jwwalker)
Date: 2004-12-03 10:31

Message:
Logged In: YES 
user_id=433183

I have fixed this by a change to E3GeometryPolygon.c.  I also
changed the bug title to reflect the fact that this was not a
problem with the wireframe renderer.

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

Comment By: James W. Walker (jwwalker)
Date: 2004-12-01 23:01

Message:
Logged In: YES 
user_id=433183

The polygon in Geom Test looks fine in wireframe mode.  If this bug still 
exists, more information on how to reproduce it would be good.  By the 
way, the Quesa contributors page mentions "3D World" but the link is 
dead.

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

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

Re: [ quesa-Bugs-907873 ] Wire frame renderer does not draw Polygon objects

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

The bug has to do with lines that are in the exactly the same place.  
When one is removed they are both disappear.

To see this bug, run Microspot Modeler. Draw a cube. Now open the  
renderer option palette, and set the renderer to wireframe or with the  
interactive renderer set the Styles pop-menu to Edges. Notice that when  
the axis lines disappear the cube lines also disappear.

This did not happen under QuickDraw3D. I did traced the bug in code  
with the debugger but got lost in Quesa code. It all looked fine until  
I got into Quesa.

Hope this helps.

Peter Michelsen. (via Roger)

On Thursday, December 2, 2004, at 07:01  am, SourceForge.net wrote:

> Bugs item #907873, was opened at 2004-03-01 13:33
> Message generated for change (Comment added) made by jwwalker
> You can respond by visiting:
> https://sourceforge.net/tracker/ 
> ?func=detail&atid=442052&aid=907873&group_id=45158
>
> Category: None
> Group: None
>> Status: Pending
>> Resolution: Works For Me
> Priority: 5
> Submitted By: Dair Grant (grantd)
> Assigned to: Nobody/Anonymous (nobody)
> Summary: Wire frame renderer does not draw Polygon objects
>
> Initial Comment:
> Quesa's interactive renderer does not draw Polygon objects
> correctly in edge mode. QD3D draws the lines making up the
> boundary. The default cube objects in 3D World are composed of
> six polygons. They totally disappear when using Quesa.
>
> ----------------------------------------------------------------------
>
>> Comment By: James W. Walker (jwwalker)
> Date: 2004-12-01 23:01
>
> Message:
> Logged In: YES
> user_id=433183
>
> The polygon in Geom Test looks fine in wireframe mode.  If this bug  
> still
> exists, more information on how to reproduce it would be good.  By the
> way, the Quesa contributors page mentions "3D World" but the link is
> dead.
>
> ----------------------------------------------------------------------
>
> You can respond by visiting:
> https://sourceforge.net/tracker/ 
> ?func=detail&atid=442052&aid=907873&group_id=45158
>
>
> -------------------------------------------------------
> 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
>

[ quesa-Bugs-907873 ] Wire frame renderer does not draw Polygon objects

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

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

Category: None
Group: None
>Status: Pending
>Resolution: Works For Me
Priority: 5
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wire frame renderer does not draw Polygon objects

Initial Comment:
Quesa's interactive renderer does not draw Polygon objects 
correctly in edge mode. QD3D draws the lines making up the 
boundary. The default cube objects in 3D World are composed of 
six polygons. They totally disappear when using Quesa.

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

>Comment By: James W. Walker (jwwalker)
Date: 2004-12-01 23:01

Message:
Logged In: YES 
user_id=433183

The polygon in Geom Test looks fine in wireframe mode.  If this bug still 
exists, more information on how to reproduce it would be good.  By the 
way, the Quesa contributors page mentions "3D World" but the link is 
dead.

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

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

[ quesa-Bugs-967633 ] Fog does not work correctly

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

Bugs item #967633, was opened at 2004-06-06 08:11
Message generated for change (Settings changed) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967633&group_id=45158

Category: None
Group: None
>Status: Pending
>Resolution: Fixed
Priority: 5
Submitted By: Lane Roathe (raving)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fog does not work correctly

Initial Comment:
The current version of Quesa (cvs as of 6/1/4) does not
render fog correctly in Nanosaur Extreme under Windows.
The verison of Quesa from Bugdom renders fog correctly.
(But I can't use it due to lighting and floor tiling
issues). You can swap in the Bugdom Quesa.dll to see
how for should work, and the source for the Bugdom
Quesa is at:

<ftp://ftp.ifd.com/pub/Quesa_Bugdom.zip>

Note that this is not a new issue, all versions of
Quesa from cvs that I have used have had this issue
with Nanosaur.


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

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

Message:
Logged In: YES 
user_id=439944

Should now be fixed - please reopen and attach a screenshot if not 
(Nanosaur used RAVE fog on the Mac, so it may be that your Windows 
Nanosaur is using its own fog implementation rather than calling Quesa).

We were trying to avoid submitting a fog style if it didn't change the 
current state, but a typo meant that changes to the fogEnd/density/color 
fields would be ignored in the comparison (and so a fog change could be 
incorrectly ignored).

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

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

www.quesa.org still wrong... hello, anyone from Artifice?

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

SourceForge docs say that quesa.org should point to 66.35.250.210, 
and www.quesa.org should be a CNAME to vhost.sourceforge.net. 
Instead, quesa.org points to 66.35.250.209 and www.quesa.org is a 
CNAME to quesa.org.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Ideas on the future of Quesa.

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

Il giorno 01/dic/04, alle 15:57, Roger Holmes ha scritto:

> As nobody has objected I guess we can drop BeOS.
>

Plonk!!!

Pax et Bonum

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

Re: Ideas on the future of Quesa.

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

On Monday, November 29, 2004, at 06:42  pm, James W. Walker wrote:

>
> Do we still want to claim to support BeOS?  We never really did, 
> right?  At least, the Be functions in GLDrawContext.c are just stubs.
>


As nobody has objected I guess we can drop BeOS.

Roger.

Re: Ideas on the future of Quesa.

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

I think there is consensus on the idea of moving the instance data from 
the E3xxx.c
files to the E3xxx.h files, changing the structs to classes so that the 
fields are
private, and using inheritance to append a child class's data to the 
parent class's
data.

There will be corresponding changes in the routines to allocate, 
deallocate and use
the instance data.

This is a necessary first step so I can get started on this unless 
anyone objects.

Roger.
  

Re: Ideas on the future of Quesa.

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

On Tuesday, November 30, 2004, at 06:32  pm, James W. Walker wrote:

> Roger Holmes <rog...@mi...> wrote:
>
>> Ok so I was trying to gather your comments on virtual functions and 
>> you
>> seem to be dead set against them, but so was I at first. If you are
>> still
>> against them after reading this I will drop the idea. 0xDEADD0D0.
>>
>> But first inheritance. The instance data of a Quesa sub class is 
>> ideally
>> held in memory just after the base class's data. That way we can
>> allocate
>> just one block of data for all the instance data of a leaf class and
>> all its
>> base classes in one go, and we do not have to follow a chain of 
>> pointers
>> to find a particular sub class's instance data. This has shown a great
>> performance boost for processing and rendering of complex documents.
>> Of course we could do this with structs, by defining a first data 
>> member
>> to be the base class's instance data, but we do want to keep the data
>> private to a class and not have it messed about with by derived 
>> classes,
>> so to have a struct/class inherit all the data members from its base
>> class
>> privately is the only way to do this properly. Of course this also
>> inherits
>> the methods but if we don't want this then we just don't define any
>> methods.
>
> If you can speed up access to instance data without compromising 
> extensibility, that would be great.

Traditional extensions would get their instance data allocated after 
the data of the class they
inherit from by just adding the requested number of bytes to the sizeof 
the base class instance.


>
>> Virtual methods. The other big speed up I made in Quesa was by
>> implementing in C the closest thing I could to a C++ VTable. I could
>> bring this code forward into cvs Quesa but the thought of allowing the
>> C++ compiler to do it for me is appealing as it is simper, less prone 
>> to
>> error and more readable. Where there is now a hash table look up for
>> a method we would instead use a virtual method. This would not of
>> course affect the API, just as the API does not expose the existing
>> functionality. There is of course the problem of extensibility. It 
>> might
>> be possible to have an extension class which would get called for
>> extension classes and would then vector off in the existing way.
>> However, apart from renderers, how many of us have actually
>> extended Quesa, I have but I would be very happy to modify my
>> extension into clean C++ classes linked into Quesa instead of the
>> horrid mess of meta handlers and multiple functions which
>> were necessary with the closed source library QD3D.
>>
>> So have I talked you around?
>
> I'm still concerned about extensibility.  I've written lots of custom 
> elements and have plans for custom renderers.  With the current setup, 
> it is theoretically possible for a plugin renderer to derive from the 
> built-in IR, using Q3XObjectClass_GetMethod to get an IR function 
> pointer.  If the IR methods were C++ methods, they would have a 
> different function signature.
>

I have written a plug in renderer, custom elements and custom groups. I 
would not break any of these otherwise
the Microspot products derived from 3D World would stop working. I 
don't think Apple ever got around to opening
up the API for custom geometries or anything other than the three I 
have used.

We could have an old style wrapper for the new style virtual methods 
but that makes the whole
thing pretty pointless.

Re: Ideas on the future of Quesa.

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

On Tuesday, November 30, 2004, at 06:38  pm, James W. Walker wrote:

> "Lane Roathe" <la...@if...> wrote:
>
>> Why? Any operation that you would want to overload should be able to
>> become an inlined function call just as easily. The actual operation 
>> code
>> remains nearly identical. (at least in my experience.)
>>
>>> From someone who's still trying to get the latest builds to work in 
>>> my
>> products, I'd rather see easily read/understood/maintainable code. The
>> more programmers who can read the code and _really_ understand what's
>> happening the more contributions to that code base you will get.
>
> Using overloaded operators for vector addition and scalar-times-vector 
> multiplication results in code that is closer to mathematical 
> notation, which to me makes it easier to read. Multiplication of 
> vectors is more doubtful, since math has dot and cross products while 
> C++ has only one * operator.
>

Yes, I have functions called DotProduct which returns a float and 
CrossProduct which return a vector.
Operator * works on a vector and a float, a point and a float,a vector 
and a matrix or two matrices, in
both 2D and 3D. Operators + and - work of a pair of vectors, a point 
and a vector (returning a point)
or for + only a vector and a point as vector - point does not really 
make sense. For operator - there
is also one which takes two points and returns a vector. The unary - 
operator works on vectors and
point though I would be happy to ditch the point one as it is a bit 
dodgy mathematically, and you can
do the same thing by multiplying by -1 anyway.

Re: Ideas on the future of Quesa.

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

"Lane Roathe" <la...@if...> wrote:

>Why? Any operation that you would want to overload should be able to
>become an inlined function call just as easily. The actual operation code
>remains nearly identical. (at least in my experience.)
>
>>From someone who's still trying to get the latest builds to work in my
>products, I'd rather see easily read/understood/maintainable code. The
>more programmers who can read the code and _really_ understand what's
>happening the more contributions to that code base you will get.

Using overloaded operators for vector addition and 
scalar-times-vector multiplication results in code that is closer to 
mathematical notation, which to me makes it easier to read. 
Multiplication of vectors is more doubtful, since math has dot and 
cross products while C++ has only one * operator.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>