quesa-develop — Mailing list for Quesa development

Re: unsigned char vs TQ3Uns8

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

Il giorno 08/giu/06, alle ore 15:46, Daniele Cavallini ha scritto:

> When I compile rayshade in rs_GetStorageData function.The value
> "result"is not possible convert when  I use Q3MemoryStorage_GetBuffer.
> I use O.S. windows. Try to open project and compile.
>

I've updated RS_Rasterize.cpp, RS_Rasterize.h and RS_Texture.cpp
  to allow them to compile on MS VC++ 6.0 without errors

Refresh your copy from CVS

> Can  we change the define  of  TQ3Uns8 in unsigned char in header  
> file?

yes, I'm pretty sure it's harmless.



Pax et Bonum

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

Re: unsigned char vs TQ3Uns8

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

When I compile rayshade in rs_GetStorageData function.The value 
"result"is not possible convert when  I use Q3MemoryStorage_GetBuffer.
I use O.S. windows. Try to open project and compile.
Can  we change the define  of  TQ3Uns8 in unsigned char in header file?


At 15.10 08/06/2006, you wrote:

>Il giorno 08/giu/06, alle ore 12:36, Daniele Cavallini ha scritto:
>
> > Is there a good justify for use in quesa's release 1.8 unsigned char
> > rather than TQ3Uns8?
> > When I compile rayshade there are a lot of error for this.
> > I repleaced unsigned char with TQ3Uns8 for compile it
> > In file RS_Texture.cpp into function rs_TextureConvertMemory there is
> > a type error  "not srcBigEndian"
>
>the change has be done to support native 64bits compilation...
>
>anyway TQ3Uns8 should be defined as unsigned char on every platform...
>
>where are you having problems exactly?
>
>Pax et Bonum
>
># dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
>#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
>#   02,33603122                0372,460602
>
>
>
>
>_______________________________________________
>Quesa-develop mailing list
>Que...@li...
>https://lists.sourceforge.net/lists/listinfo/quesa-develop

Re: unsigned char vs TQ3Uns8

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

Il giorno 08/giu/06, alle ore 12:36, Daniele Cavallini ha scritto:

> Is there a good justify for use in quesa's release 1.8 unsigned char
> rather than TQ3Uns8?
> When I compile rayshade there are a lot of error for this.
> I repleaced unsigned char with TQ3Uns8 for compile it
> In file RS_Texture.cpp into function rs_TextureConvertMemory there is
> a type error  "not srcBigEndian"

the change has be done to support native 64bits compilation...

anyway TQ3Uns8 should be defined as unsigned char on every platform...

where are you having problems exactly?

Pax et Bonum

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

unsigned char vs TQ3Uns8

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

Is there a good justify for use in quesa's release 1.8 unsigned char 
rather than TQ3Uns8?
When I compile rayshade there are a lot of error for this.
I repleaced unsigned char with TQ3Uns8 for compile it
In file RS_Texture.cpp into function rs_TextureConvertMemory there is 
a type error  "not srcBigEndian"

Re: Quesa on Intel woes. Does Quesa support only native byte order?

[Sean M. <se...@ro...>]

On 2006-05-19 11:20, James W. Walker said:

>The background image is not being handled by Quesa, it's just set up 
>with a QuickTime image importer and copied with CopyBits.

So it is.  Thanks James for your explanations.  I now understand how the
test app works and indeed it works as it should.  I believe we have
tracked down our problem also, it appears to be another bug in QuickDraw
on intel, but I'm not entirely certain.

Thanks!

-- 
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Sean McBride, B. Eng                 se...@ro...
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montr=E9al, Qu=E9bec, Canada

Re: Quesa on Intel woes. Does Quesa support only native byte order?

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

I wrote:

>>Exactly what did you change?  Do you mean pass the wrong value for
>>pixmapDrawContextData.pixmap.byteOrder, which would just be a case of
>>false advertising, or do you mean that you removed the
>>kNativeEndianPixMap flag from the NewGWorld calls in QutTexture.c?


"Sean McBride" <se...@ro...> wrote:

>The former.  So the behaviour makes sense given that Quesa always works
>in native endianness.  If I change the latter, then the triangle becomes
>awash in blue (expected) but the background image does not get swapped,
>why is that?

The background image is not being handled by Quesa, it's just set up 
with a QuickTime image importer and copied with CopyBits.  Clearly 
those APIs can handle non-native-order GWorlds.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Quesa on Intel woes. Does Quesa support only native byte order?

[Sean M. <se...@ro...>]

On 2006-05-19 10:54, James W. Walker said:

>>  That is, can I not provide a big
>>endian buffer on a little endian system or vice versa=3F
>
>Currently not.  Why do you want to=3F

I don't.  I'm just trying to understand how changing inputs affects the
output I see.

>>  If I change the
>>"Background Test" in such a way that I pass the wrong byte order I get
>>the assertion but the app still works (no images are byte swapped).
>
>Exactly what did you change=3F  Do you mean pass the wrong value for 
>pixmapDrawContextData.pixmap.byteOrder, which would just be a case of 
>false advertising, or do you mean that you removed the 
>kNativeEndianPixMap flag from the NewGWorld calls in QutTexture.c=3F

The former.  So the behaviour makes sense given that Quesa always works
in native endianness.  If I change the latter, then the triangle becomes
awash in blue (expected) but the background image does not get swapped,
why is that=3F

I'm just trying to understand the Background Test example fully because
with Quesa 1.7 both it and my app had the same problem (offscreen
rendering awash in blue).  Now with 1.8 the example app works, but my
app still has the same problem as in 1.7.

Cheers,

-- 
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Sean McBride, B. Eng                 se...@ro...
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montr=E9al, Qu=E9bec, Canada

Re: Quesa on Intel woes. Does Quesa support only native byte order?

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

"Sean McBride" <se...@ro...> wrote:

>In gldrawcontext_mac_new() in the kQ3DrawContextTypePixmap case there is
>an assertion checking that the byte order passed in is the same as the
>CPU's byte order.  This assertion is new in 1.8.  Why is it there?  Does
>Quesa only support native byte order?

Correct.

>  That is, can I not provide a big
>endian buffer on a little endian system or vice versa?

Currently not.  Why do you want to?

>  If I change the
>"Background Test" in such a way that I pass the wrong byte order I get
>the assertion but the app still works (no images are byte swapped).

Exactly what did you change?  Do you mean pass the wrong value for 
pixmapDrawContextData.pixmap.byteOrder, which would just be a case of 
false advertising, or do you mean that you removed the 
kNativeEndianPixMap flag from the NewGWorld calls in QutTexture.c?
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Quesa on Intel woes. Does Quesa support only native byte order?

[Sean M. <se...@ro...>]

Hi all,

We are still having problems with our app on Intel.  Images are
sometimes awash with blue.  Not sure if its our bug, QD, or Quesa.

I just wanted to ask a hopefully simple question first.

In gldrawcontext=5Fmac=5Fnew() in the kQ3DrawContextTypePixmap case there is
an assertion checking that the byte order passed in is the same as the
CPU's byte order.  This assertion is new in 1.8.  Why is it there=3F  Does
Quesa only support native byte order=3F  That is, can I not provide a big
endian buffer on a little endian system or vice versa=3F  If I change the
"Background Test" in such a way that I pass the wrong byte order I get
the assertion but the app still works (no images are byte swapped).

Thanks,

-- 
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Sean McBride, B. Eng                 se...@ro...
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montr=E9al, Qu=E9bec, Canada

Re: Quesa 1.8 broke my app; assertion in E3Set::Add() adding a kQ3AttributeTypeSurfaceShader

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

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

>Is there a problem with the list? My message (below) was sent at 
>20:40 yesterday
>but was only broadcast at 14:17 today, by which time James had also 
>gone to the
>trouble of replying.

I don't see anything relevant on the SourceForge site status page, 
but the support tracker <https://sourceforge.net/tracker/index.php> 
has a number of mailing list complaints in the last few days.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Quesa 1.8 broke my app; assertion in E3Set::Add() adding a kQ3AttributeTypeSurfaceShader

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

Hi all,

Is there a problem with the list? My message (below) was sent at  
20:40 yesterday
but was only broadcast at 14:17 today, by which time James had also  
gone to the
trouble of replying. Fortunately we said the same things and it  
worked, but
duplication of effort should be avoided is possible, and Sean could  
have had his
answer sooner.

Roger.




On 15 May, 2006, at 20:40, Roger Holmes wrote:

> Hi Sean,
>
> The Null Illumination shader does not inherit from Surface Shader,
> it inherits from Shader. Surface Shader also inherits from Shader
> but that does not help.
>
> I am not sure you can put one in an attribute set. Can you put them
> both in a group and submit that instead?
>
> Roger Holmes.

Re: Quesa 1.8 broke my app; assertion in E3Set::Add() adding a kQ3AttributeTypeSurfaceShader

[Sean M. <se...@ro...>]

On 2006-05-15 12:20, James W. Walker said:

>I don't think you can add an illumination shader as an attribute.  I 
>suggest making a display group, and inserting your illumination 
>shader before the polygon.

That worked, thanks.  Given your explanations, I agree that what we were
doing before was wrong, but it did work in Quesa 1.7 but not 1.8, I
don't understand why, but it doesn't matter much now...

Thanks!

-- 
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Sean McBride, B. Eng                 se...@ro...
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montr=E9al, Qu=E9bec, Canada

Re: Quesa 1.8 broke my app; assertion in E3Set::Add() adding a kQ3AttributeTypeSurfaceShader

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

Hi Sean,

The Null Illumination shader does not inherit from Surface Shader,
it inherits from Shader. Surface Shader also inherits from Shader
but that does not help.

I am not sure you can put one in an attribute set. Can you put them
both in a group and submit that instead?

Roger Holmes.








On 15 May, 2006, at 19:35, Sean McBride wrote:

> Hi all,
>
> Up to recently I've been using Quesa 1.7 from CVS of 2006-03-28.  Now
> I'm trying 1.8 and now my app crashes.  The code is:
>
> 	TQ3ShaderObject	shader =3D Q3NULLIllumination_New();
>
> 	TQ3PolygonData	polygon_data;
> 	polygon_data.numVertices =3D ...;
> 	polygon_data.vertices =3D ...;
> 	polygon_data.polygonAttributeSet =3D Q3AttributeSet_New();
>
> 	Q3AttributeSet_Add( polygon_data.polygonAttributeSet,
>     kQ3AttributeTypeSurfaceShader,
>     &shader );
>
> And then in E3Set::Add() (called by Q3AttributeSet_Add) this =20
> assertion fires:
>
> 	Q3_ASSERT( Q3Object_IsType (
>     setData.attributes.surfaceShader,
> 			 kQ3ShaderTypeSurface ) ) ;
>
> It crashes a few lines later.  I'm not sure if I built 1.7 with
> assertions, but there was no crash then.
>
> Is this not the right way to add a null shader?  Our goal is to add a
> null illumination shader to a polygon object.
>
> Thanks for any advice!
>
> --
> ____________________________________________________________
> Sean McBride, B. Eng                 se...@ro...
> Rogue Research                        www.rogue-research.com
> Mac Software Developer              Montr=E9al, Qu=E9bec, Canada
>
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, =20
> security?
> Get stuff done quickly with pre-integrated technology to make your =20
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache =20
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=120709&bid&3057&dat=121642=

> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop

Re: Quesa 1.8 broke my app; assertion in E3Set::Add() adding a kQ3AttributeTypeSurfaceShader

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

"Sean McBride" <se...@ro...> wrote:

>Up to recently I've been using Quesa 1.7 from CVS of 2006-03-28.  Now
>I'm trying 1.8 and now my app crashes.  The code is:
>
>	TQ3ShaderObject	shader = Q3NULLIllumination_New();
>
>	TQ3PolygonData	polygon_data;
>	polygon_data.numVertices = ...;
>	polygon_data.vertices = ...;
>	polygon_data.polygonAttributeSet = Q3AttributeSet_New();
>
>	Q3AttributeSet_Add( polygon_data.polygonAttributeSet,
>     kQ3AttributeTypeSurfaceShader,
>     &shader );
>
>And then in E3Set::Add() (called by Q3AttributeSet_Add) this assertion fires:
>
>	Q3_ASSERT( Q3Object_IsType (
>     setData.attributes.surfaceShader,
>			 kQ3ShaderTypeSurface ) ) ;
>
>It crashes a few lines later.  I'm not sure if I built 1.7 with
>assertions, but there was no crash then.
>
>Is this not the right way to add a null shader?  Our goal is to add a
>null illumination shader to a polygon object.

The name kQ3AttributeTypeSurfaceShader suggests that the attribute 
should be a surface shader, but an illumination shader is not a 
surface shader.  One way you can see that is by looking at the 
indentation in Quesa.h:

             kQ3ShapeTypeShader                  = Q3_OBJECT_TYPE('s', 
'h', 'd', 'r'),
                 kQ3ShaderTypeSurface            = Q3_OBJECT_TYPE('s', 
'u', 's', 'h'),
                     kQ3SurfaceShaderTypeTexture = Q3_OBJECT_TYPE('t', 
'x', 's', 'u'),
                 kQ3ShaderTypeIllumination       = Q3_OBJECT_TYPE('i', 
'l', 's', 'h'),
                     kQ3IlluminationTypePhong    = Q3_OBJECT_TYPE('p', 
'h', 'i', 'l'),
                     kQ3IlluminationTypeLambert  = Q3_OBJECT_TYPE('l', 
'm', 'i', 'l'),
                     kQ3IlluminationTypeNULL     = Q3_OBJECT_TYPE('n', 
'u', 'i', 'l'),

I don't think you can add an illumination shader as an attribute.  I 
suggest making a display group, and inserting your illumination 
shader before the polygon.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Quesa 1.8 broke my app; assertion in E3Set::Add() adding a kQ3AttributeTypeSurfaceShader

[Sean M. <se...@ro...>]

Hi all,

Up to recently I've been using Quesa 1.7 from CVS of 2006-03-28.  Now
I'm trying 1.8 and now my app crashes.  The code is:

=09TQ3ShaderObject=09shader =3D Q3NULLIllumination=5FNew();

=09TQ3PolygonData=09polygon=5Fdata;
=09polygon=5Fdata.numVertices =3D ...;
=09polygon=5Fdata.vertices =3D ...;
=09polygon=5Fdata.polygonAttributeSet =3D Q3AttributeSet=5FNew();

=09Q3AttributeSet=5FAdd( polygon=5Fdata.polygonAttributeSet,
    kQ3AttributeTypeSurfaceShader,
    &shader );

And then in E3Set::Add() (called by Q3AttributeSet=5FAdd) this assertion =
fires:

=09Q3=5FASSERT( Q3Object=5FIsType (
    setData.attributes.surfaceShader,
=09=09=09 kQ3ShaderTypeSurface ) ) ;

It crashes a few lines later.  I'm not sure if I built 1.7 with
assertions, but there was no crash then.

Is this not the right way to add a null shader=3F  Our goal is to add a
null illumination shader to a polygon object.

Thanks for any advice!

-- 
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Sean McBride, B. Eng                 se...@ro...
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montr=E9al, Qu=E9bec, Canada

Re: Quesa 1.8 release

[Sean M. <se...@ro...>]

On 2006-05-09 09:09, James W. Walker said:

>> 5) are the static lib and framework that are already built and  
>> included
>> in quesa=5F1.8=5Fsdk=5Fmac debug or release builds=3F
>
>Release.  Debug builds just seemed too huge.  Rumor has it that an  
>upcoming version of Xcode may make this less of a problem.

:)  There's a rumour I'd like to see come true!

>> 6) the Xcode project settings have DYLIB=5FCURRENT=5FVERSION =3D 1.7 and
>> DYLIB=5FCOMPATIBILITY=5FVERSION =3D 1.6. I'm guessing the former should  
>> be 1.8=3F
>
>Probably.  I've never actually used those version numbers for  
>anything, have you=3F

No.  Just thought I'd mention it since I spotted it looking over the
project settings...

Thanks,

-- 
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Sean McBride, B. Eng                 se...@ro...
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montr=E9al, Qu=E9bec, Canada

Re: Quesa64

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

Hi Jose,

I would prefer to avoid the underscore character.

I think TQ3Point3D64 would be better as it does not run the 3 and the  
64 together.

I also had to write similar routines, but I replaced my C++ wrapper  
routines with double
versions rather than have to call through to a C routine. That way I  
did not have to worry
about inventing new routine names, just overloaded the standard ones.  
The only problem
was with the compiler sometimes not knowing which routine to call,  
for instance when
passing in an integer it does not know whether I want the float or  
double routine, so I
have to coerce the value directly or rewrite it as 123.0f .

Roger.


On 9 May, 2006, at 17:32, Jose' Cruanyes wrote:

> I'm interested in creating (part of) the math routines with double  
> precision to alleviate a bit the problems I'm having with rounding  
> errors in matrix calculations
>
> it involves the creation of a Quesa64.h and a QuesaMath64.h (and  
> the corresponding .cpp)
>
> the problem is the naming of the data and methods
>
> I'm thinking about
>
> TQ364Point3D or
> TQ3_64Point3D or
> TQ3Point3D64 or ...
>
>
>
>
>
>
>
> Pax et Bonum
>
> # dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
> #  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
> #   02,33603122                0372,460602
>
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop

Quesa64

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

I'm interested in creating (part of) the math routines with double  
precision to alleviate a bit the problems I'm having with rounding  
errors in matrix calculations

it involves the creation of a Quesa64.h and a QuesaMath64.h (and the  
corresponding .cpp)

the problem is the naming of the data and methods

I'm thinking about

TQ364Point3D or
TQ3_64Point3D or
TQ3Point3D64 or ...







Pax et Bonum

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

Re: Quesa 1.8 release

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

On May 9, 2006, at 8:29 AM, Sean McBride wrote:

> 1) <http://www.quesa.org/> still says 1.7 is the latest, with a  
> 2005 date.
> 2) the file "/quesa_1.8_sdk_mac/Quesa Read Me.html" says "Welcome  
> to the
> 1.7 release of Quesa...".
> 3) is the sourceforce cvs server still not working?  It's not for me.

 From the SourceForge site status page:

( 2006-05-05 07:55:54 - Project CVS Service )   As of 2006-05-05 we  
are still waiting on all the hardware for the replacement CVS  
infrastructure. A few of the machines we received from our vendor had  
disk issues shortly after configuration, so we are vetting all the  
systems for issues, and reloading a few of them. The service  
deployment itself is running smoothly and we don't anticipate any  
problems other than the existing hardware issues that we are working  
through with the vendor. We are currently estimating a deployment for  
the end of next week (May 12th).

> 4) looking at the target settings for the 'Static Lib (Univ)'  
> target, I
> see that only the Debug configuration is built universal, and the
> release isn't.  An oversight I assume?

Yes, sorry.

> 5) are the static lib and framework that are already built and  
> included
> in quesa_1.8_sdk_mac debug or release builds?

Release.  Debug builds just seemed too huge.  Rumor has it that an  
upcoming version of Xcode may make this less of a problem.

> 6) the Xcode project settings have DYLIB_CURRENT_VERSION = 1.7 and
> DYLIB_COMPATIBILITY_VERSION = 1.6. I'm guessing the former should  
> be 1.8?

Probably.  I've never actually used those version numbers for  
anything, have you?

Re: Quesa 1.8 release

[Sean M. <se...@ro...>]

On 2006-04-22 16:08, James W. Walker said:

>I have posted Mac and Windows packages for Quesa 1.8.

Thanks James!

A few notes:

1) <http://www.quesa.org/> still says 1.7 is the latest, with a 2005 date.
2) the file "/quesa=5F1.8=5Fsdk=5Fmac/Quesa Read Me.html" says "Welcome to =
the
1.7 release of Quesa...".
3) is the sourceforce cvs server still not working=3F  It's not for me.
4) looking at the target settings for the 'Static Lib (Univ)' target, I
see that only the Debug configuration is built universal, and the
release isn't.  An oversight I assume=3F
5) are the static lib and framework that are already built and included
in quesa=5F1.8=5Fsdk=5Fmac debug or release builds=3F
6) the Xcode project settings have DYLIB=5FCURRENT=5FVERSION =3D 1.7 and
DYLIB=5FCOMPATIBILITY=5FVERSION =3D 1.6. I'm guessing the former should be =
1.8=3F

Well, I built Quesa 1.8 as univ, now to try it out...

Thanks,

-- 
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Sean McBride, B. Eng                 se...@ro...
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montr=E9al, Qu=E9bec, Canada

Re: Quesa 1.8 release

[Roch M. C. <ro...@ro...>]

Me three!

Cheers,

Roch

On 23-Apr-06, at 4:48 AM, Roger Holmes wrote:

> Yes, thanks from me too.
>
> On 23 Apr, 2006, at 01:57, Kevin Matthews wrote:
>
>> Thanks very much, James!
>>
>> - KMM
>>
>> On Sat, 22 Apr 2006 16:08:54 -0700, James W. Walker wrote:
>>> I have posted Mac and Windows packages for Quesa 1.8.
>>> --  
>>>   James W. Walker, Innoventive Software LLC
>>>   <http://www.frameforge3d.com/>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

Re: Quesa 1.8 release

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

Yes, thanks from me too.

On 23 Apr, 2006, at 01:57, Kevin Matthews wrote:

> Thanks very much, James!
>
> - KMM
>
> On Sat, 22 Apr 2006 16:08:54 -0700, James W. Walker wrote:
>> I have posted Mac and Windows packages for Quesa 1.8.
>> -- 
>>   James W. Walker, Innoventive Software LLC
>>   <http://www.frameforge3d.com/>

Re: Quesa 1.8 release

[Kevin M. <mat...@ar...>]

Thanks very much, James!

- KMM

On Sat, 22 Apr 2006 16:08:54 -0700, James W. Walker wrote:
> I have posted Mac and Windows packages for Quesa 1.8.
> -- 
>   James W. Walker, Innoventive Software LLC
>   <http://www.frameforge3d.com/>
> 
> 
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop

Quesa 1.8 release

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

I have posted Mac and Windows packages for Quesa 1.8.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: first draft of release notes for Quesa 1.7.1

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

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

>I propose to call it 1.8 better than 1.7.1

Hearing no other opinions, I can go along with that.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>