quesa-develop — Mailing list for Quesa development

Re: At last! I have finished the Quesa changes.

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

On Friday, February 11, 2005, at 07:51 AM, James W.Walker wrote:

>
> I don't think we should keep using "d" version numbers.  That may have 
> a stigma of "not ready for prime time" in some people's minds.  Just 
> because Quesa is in continuous development doesn't mean it shouldn't 
> be used in production.

So 1.7b1 maybe?

>
> I also don't see the point of a final 1.6.  Anyone who would use that 
> instead of 1.7 (or whatever we call it) should have his or her head 
> examined, in my humble opinion.


Thanks.

Roger.

Re: At last! I have finished the Quesa changes.

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

On Feb 10, 2005, at 11:11 PM, Lane Roathe wrote:

> I vote for v1.7d1 ... but there should be a plan in place to release a
> final 1.7 not too far off (and, for that matter, a final 1.6 based on 
> the
> 1.6d20 base after testing).

I don't think we should keep using "d" version numbers.  That may have 
a stigma of "not ready for prime time" in some people's minds.  Just 
because Quesa is in continuous development doesn't mean it shouldn't be 
used in production.

I also don't see the point of a final 1.6.  Anyone who would use that 
instead of 1.7 (or whatever we call it) should have his or her head 
examined, in my humble opinion.
--
<http://www.jwwalker.com/>

Re: At last! I have finished the Quesa changes.

[Lane R. <la...@if...>]

on Fri, Feb 11, 2005 Jose' Cruanyes may have said:

>Il giorno 11/feb/05, alle 04:05, James W. Walker ha scritto:
>
>>> I have now finished all the changes I set out to make to Quesa, and a 
>>> few more.
>>>
>>> I hope you all like what I've done but as they say, your can't please 
>>> all the people
>>> all the time.
>>
>> Thanks for doing this!  In the Multibox test in Geom Test, I am seeing 
>> a 41% increase in frame rate compared to the 1.6d20 release.
>>
>
>Thanks also from me
>
>It's time for a new release,
>How should we call it?...
>1.6d21 ?
>1.7 ?

I vote for v1.7d1 ... but there should be a plan in place to release a
final 1.7 not too far off (and, for that matter, a final 1.6 based on the
1.6d20 base after testing).

Of course, easy for me to say :)

Lane Roathe
President          Ideas From the Deep        <http://www.ifd.com>
___________________________________________________________________
Data, data everywhere . . . and not a thought to to be had.

Re: At last! I have finished the Quesa changes.

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

Il giorno 11/feb/05, alle 04:05, James W. Walker ha scritto:

>> I have now finished all the changes I set out to make to Quesa, and a 
>> few more.
>>
>> I hope you all like what I've done but as they say, your can't please 
>> all the people
>> all the time.
>
> Thanks for doing this!  In the Multibox test in Geom Test, I am seeing 
> a 41% increase in frame rate compared to the 1.6d20 release.
>

Thanks also from me

It's time for a new release,
How should we call it?...
1.6d21 ?
1.7 ?
2.0 ?
02.2005 ?
Valentine ?

Pax et Bonum

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

Re: At last! I have finished the Quesa changes.

[Lane R. <la...@if...>]

on Thu, Feb 10, 2005 James W. Walker may have said:

>>I have now finished all the changes I set out to make to Quesa, and 
>>a few more.
>>
>>I hope you all like what I've done but as they say, your can't 
>>please all the people
>>all the time.
>
>Thanks for doing this!  In the Multibox test in Geom Test, I am 
>seeing a 41% increase in frame rate compared to the 1.6d20 release.

Wow...that's a big increase on code which over the last two years has
already seen a lot of improvements.

Good work Roger!

Lane Roathe
President          Ideas From the Deep        <http://www.ifd.com>
___________________________________________________________________
Q. "If you knew it wasn't true, why did you report it?"
A. "If nobody watches my show, we will all starve."

Actual response from Denver TV news anchor in response to questions in
an A&E Investigative Reports airing. And people believe what they watch!

Re: At last! I have finished the Quesa changes.

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

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

>I have now finished all the changes I set out to make to Quesa, and 
>a few more.
>
>I hope you all like what I've done but as they say, your can't 
>please all the people
>all the time.

Thanks for doing this!  In the Multibox test in Geom Test, I am 
seeing a 41% increase in frame rate compared to the 1.6d20 release.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

At last! I have finished the Quesa changes.

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

I have now finished all the changes I set out to make to Quesa, and a 
few more.

I hope you all like what I've done but as they say, your can't please 
all the people
all the time.

Though I have worked in a way to minimize any possibility of 
introducing bugs there
is always a risk, so please let me know if you think there is a fault 
in my code which
was not in the original.

There might be the odd file I decide to tidy up a bit but this will be 
one or two files at
a time, I will not be committing 25 files at a time again without 
discussion with the group.

Due to the non standard way E3Renderer and the Input / Output classes 
add their
methods (directly not through via their Meta Handler) I have been 
unable to convert
these to have their addresses in their class info, so they continue to 
work via the
hash table. For I/O this is not too much of a problem as it is slow 
anyway as it takes
time to transfer the data to/from disk. E3Renderer is more of a 
problem, and if
someone who understands it can either convert it to Meta Handler 
working (so I can
convert it) or convert it themselves (allowing for plug in renderers of 
course, which
do use Meta Handler working) then that would be great.

I am going to be working on other projects from Monday.

Roger.

Re: Further Quesa changes

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

Il giorno 08/feb/05, alle 14:29, Roger Holmes ha scritto:

>
> May I go ahead?
>

GO...


Pax et Bonum

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

Further Quesa changes

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

As most of you are aware, I have been changing Quesa so that
what are is essence virtual methods are not found by the old
mechanism of look up of the method name in a hash table,
but rather by holding the address of the method in an
extension of the class info for the class.

Whilst writing this I have retained the test on whether the method
is NULL before calling it, but I now think that many of these tests
could be done at class registration rather than on the call of a method.

For instance, the root class provides a kQ3XMethodTypeObjectDispose
method, and every class in the hierarchy has the option of overriding 
it,
but if it should return NULL, then Quesa calls the meta handler of the
parent classes up to as far as root if necessary. So it is impossible 
for
the method pointer for this method ever to be NULL, so there is really
absolutely no need to test for NULL.

There are cases where a method pointer can be NULL, for instance
the class Group has many NULL pointers, and this is very similar to
the C++ language having a class with methods assigned ' = 0 '. In
that cases objects of the class cannot be made. In our cases I do
not think that there is any point in making an object of type Group
as you can do practically nothing with it. Classes derived from Group
are of course useful, as they fill in the missing methods.

There are also legitimate cases where a method can be NULL, for
instance if a class adds only instance data without pointers, then
there is no reason to provide an instance data destructor method.

It seems that these legitimate NULL methods are those which do
not inherit from their parent classes.

What I propose is that we have a new boolean in the class info
called 'abstract', meaning it has one or more inheriting methods
which are NULL (i.e. pure virtual in C++ parlance). If any attempt
is made to create an instance of a class for which 'abstact' is
true, then a failure would be returned (and in the debugging
version an assertion error produced).

As this would mean that no objects could be created which refer
to a class where an inheriting method is NULL, then all the tests
for NULL could be taken out, saving more runtime overhead.
There would of course be similar tests at class registration but
these would only be done during initialisation. The only new
head would be a single test at the creation of each instance, but
as we are allocation (and clearing) the data, a single test is
swamped by the processing needed, and in 99% of cases it
is also swamped by the savings I have already made .

May I go ahead?

Roger.

Re: linking small test programm

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

Il giorno 08/feb/05, alle 13:41, Bernhard Breinbauer ha scritto:

> Hi!
>
> Am Dienstag 08 Februar 2005 10:53 schrieb Jose' Cruanyes:
>> Get quesaexamples-1.6d20.tar.gz, and give it a try
> done that. When I was running make i got the following error
>
Seems that the configure script is not properly tuned... my fault...

can please e-mail me privately the Makefile and config.log from both 
quesa and quesa examples generated on your machine?



Pax et Bonum

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

Re: linking small test programm

[Bernhard B. <inf...@gm...>]

Hi!

Am Dienstag 08 Februar 2005 10:53 schrieb Jose' Cruanyes:
> Get quesaexamples-1.6d20.tar.gz, and give it a try
done that. When I was running make i got the following error
make
gcc -DPACKAGE_NAME=3D\"QuesaExamples\" -DPACKAGE_TARNAME=3D\"quesaexamples\=
"=20
=2DDPACKAGE_VERSION=3D\"1.6d20\" -DPACKAGE_STRING=3D\"QuesaExamples\ 1.6d20=
\"=20
=2DDPACKAGE_BUGREPORT=3D\"que...@de...\"=20
=2DDPACKAGE=3D\"quesaexamples\" -DVERSION=3D\"1.6d20\" -DSTDC_HEADERS=3D1=20
=2DDHAVE_SYS_TYPES_H=3D1 -DHAVE_SYS_STAT_H=3D1 -DHAVE_STDLIB_H=3D1 -DHAVE_S=
TRING_H=3D1=20
=2DDHAVE_MEMORY_H=3D1 -DHAVE_STRINGS_H=3D1 -DHAVE_INTTYPES_H=3D1 -DHAVE_STD=
INT_H=3D1=20
=2DDHAVE_UNISTD_H=3D1 -DHAVE_DLFCN_H=3D1  -I. -I.   -I/usr/X11R6/include =20
=2DDQUESA_OS_UNIX=3D1 -Wall -Wpointer-arith -Wno-cast-qual -Waggregate-retu=
rn=20
=2DWstrict-prototypes -Wmissing-prototypes -Wmissing-declarations=20
=2DWredundant-decls -Wno-multichar -Wno-conversion -Wno-unknown-pragmas=20
=2DWno-unused -I/usr/local/include/quesa -I./Qut -I/usr/include/gtk-1.2=20
=2DI/usr/include/glib-1.2 -I//usr/lib/glib/include=20
=2DI/usr/X11R6/include-DQUESA_HOST_IS_BIG_ENDIAN=3D0 -g -O2 -c -o=20
libquesaqut_a-Qut.o `test -f 'Qut/Qut.c' || echo './'`Qut/Qut.c
In file included from Qut/Qut.c:46:
Qut/Qut.h:50:20: Quesa.h: No such file or directory
Qut/Qut.h:51:26: QuesaCamera.h: No such file or directory
Qut/Qut.h:52:30: QuesaController.h: No such file or directory
Qut/Qut.h:53:34: QuesaCustomElements.h: No such file or directory

=2E... and so on, it couldn't find any of the quesa headers.
These files are under /usr/include/quesa/, I copied them to /usr/include/ t=
hen=20
make completed successfully. (Not a nice way, but I'm a little frustated=20
about this things atm.)
I can start the example apps without a problem, very nice btw.

> BTW Qut is 'Quesa utilities' used AFAIK only by the quesa examples

thanks!

> > I've got my little testprogramm to link when i use following command:
> > g++ /usr/local/lib/libquesa.so -o test-quesa test-quesa.o
> > But I have no idea why i have to provide the quesa library that way.
> > And i
> > think it shouldn't be done that way.
>
> probably /usr/local/lib/ is not in your LIBRARY_PATH
>
> try gcc -print-search-dirs

gcc -print-search-dirs
install: /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/
programs:=20
=3D/usr/libexec/gcc/x86_64-pc-linux-gnu/3.4.3/:/usr/libexec/gcc/x86_64-pc-l=
inux-gnu/3.4.3/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-p=
c-linux-gnu/3.4.3/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/libexec/gcc/x86_6=
4-pc-linux-gnu/3.4.3/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x8=
6_64-pc-linux-gnu/3.4.3/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86=
_64-pc-linux-gnu/3.4.3/../../../../x86_64-pc-linux-gnu/bin/x86_64-pc-linux-=
gnu/3.4.3/:/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/../../../../x86_64-pc-lin=
ux-gnu/bin/
libraries:=20
=3D/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/:/usr/lib/gcc/x86_64-pc-linux-gnu=
/3.4.3/:/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/../../../../x86_64-pc-linux-=
gnu/lib/x86_64-pc-linux-gnu/3.4.3/:/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/.=
=2E/../../../x86_64-pc-linux-gnu/lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.=
3/../../../x86_64-pc-linux-gnu/3.4.3/:/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.=
3/../../../:/lib/x86_64-pc-linux-gnu/3.4.3/:/lib/:/usr/lib/x86_64-pc-linux-=
gnu/3.4.3/:/usr/lib/

Yes, you were right. GCC is not searching in /usr/local/lib. And after=20
recognizing that LIBRARY_PATH is not set at all in my environment (Gentoo=20
Linux), I installed quesa with --prefix=3D"/usr".=20
But linking my small app is still only possible when I provide the quesa=20
library explicitly:
g++ /usr/lib/libquesa.so -o test-quesa test-quesa.o

While I was compiling the quesa examples, I recognized that the examples al=
so=20
provide the quesa library explicitly, so maybe this is not that wrong as i=
=20
thought?
e.g:
gcc -DQUESA_HOST_IS_BIG_ENDIAN=3D0 -g -O2 -o dumpgroup dumpgroup-DumpGroup.=
o=20
=2Drdynamic  /usr/lib/libglut.so -L/usr/lib64 -lX11 -lXext -L/usr/local/lib=
=20
=2DL/home/derber/bernhard/9.semester/programmierpraktikum/quesa/quesaexampl=
es-1.6d20=20
=2Dlquesaqut /usr//lib/libquesa /usr/lib/opengl/nvidia/lib/libGL.so /usr/li=
b/libGLU.so
=2DL//usr/lib=20
=2DL/usr/X11R6/lib64 /usr/lib/libgtk.so /usr/lib/libgdk.so //usr/lib/libgmo=
dule.so //usr/lib/libglib.so=20
=2DlXext -lX11 -lXext -lX11 -lX11 -lMesaGLU -lMesaGL -lX11 -lc -lX11=20
=2DL/usr/X11R6/lib -lX11 -L/usr/lib -lXext -lX11 -lX11 -lXext -lSM -lICE -l=
Xmu=20
=2DlXt -lXext -lX11 -lpthread -lXext -lX11 -lXi -lXext -lX11 -lm -ldl=20
=2DWl,--rpath -Wl,/usr//lib -Wl,--rpath -Wl,//usr/lib-Wl,--rpath -Wl,/usr//=
lib=20
=2DWl,--rpath -Wl,//usr/lib

greetings to milano,
Bernhard

Re: linking small test programm

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

Il giorno 08/feb/05, alle 10:10, Bernhard Breinbauer ha scritto:

>
>> are geomtest working on this machine?
>
> Do you mean the Geom Test in the Example directory? Then, no. Didn't 
> get it to
> compile by hand, and there is no autoconf stuff in the directory. And 
> it uses
> this Qut (have no idea what it is), which is also in the Examples 
> directory
> and is not installed (same problem, no autoconf stuff).

Get quesaexamples-1.6d20.tar.gz, and give it a try

BTW Qut is 'Quesa utilities' used AFAIK only by the quesa examples

>
>> How have you get and compiled quesa?
>
>
> I've got my little testprogramm to link when i use following command:
> g++ /usr/local/lib/libquesa.so -o test-quesa test-quesa.o
> But I have no idea why i have to provide the quesa library that way. 
> And i
> think it shouldn't be done that way.
>

probably /usr/local/lib/ is not in your LIBRARY_PATH

try gcc -print-search-dirs


Pax et Bonum

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

Re: linking small test programm

[Bernhard B. <inf...@gm...>]

Am Dienstag 08 Februar 2005 09:06 schrieb Jose' Cruanyes:

> Hi Bernhard:
> couple of questions:
>
> Have you isntalled quesa? ('make install' as root)

Yes, did that

> are geomtest working on this machine?

Do you mean the Geom Test in the Example directory? Then, no. Didn't get it=
 to=20
compile by hand, and there is no autoconf stuff in the directory. And it us=
es=20
this Qut (have no idea what it is), which is also in the Examples directory=
=20
and is not installed (same problem, no autoconf stuff).

> How have you get and compiled quesa?

I've downloaded quesa-1.6d20.tar.gz from sf.net, and made the usual=20
steps: ./configure, make, make install (as root). all went well.
then I wasn't able to link my test app and I started playing around with th=
e=20
linker, with no success. I discovered that ldconfig didn't recognize=20
libquesa, after making a symbolic link libquesa.so to libquesa.0.0.0,=20
libquesa was in the linker cache but linking was still not possible.

I've got my little testprogramm to link when i use following command:
g++ /usr/local/lib/libquesa.so -o test-quesa test-quesa.o
But I have no idea why i have to provide the quesa library that way. And i=
=20
think it shouldn't be done that way.

so I'm still confused...

bye
Bernhard

Re: linking small test programm

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

Il giorno 07/feb/05, alle 19:07, Bernhard Breinbauer ha scritto:

> Hi everyone!
>
> I'm searching for a 3D library for a university project.
> ATM I'm testing quesa, but get an error when I try linking.
> my prog:
> #define QUESA_OS_UNIX
>
> #include <Quesa.h>
> #include <stdio.h>
>
> int main (void) {
>  Q3Initialize();
>  if (Q3IsInitialized())
>  {
>   printf("YES\n");
>   return 1;
>   }
>  else {
>   printf("NO\n");
>   return 0;
>   }
> }
>
> compilation is ok with following command:
> g++ -ansi -pedantic -Wall -g -c -I/usr/local/include/quesa  
> test-quesa.cc
>
> but linking fails with following error:
> g++ -o test-quesa test-quesa.o
> test-quesa.o(.text+0x9): In function `main':
> /home/derber/bernhard/9.semester/programmierpraktikum/test-quesa.cc:10:
> undefined reference to `Q3Initialize'
> test-quesa.o(.text+0xe):/home/derber/bernhard/9.semester/ 
> programmierpraktikum/test-quesa.cc:11:
> undefined reference to `Q3IsInitialized'
> collect2: ld returned 1 exit status
>
> when i try linking with defining libquesa explicitly, i get this error:
> g++ -l /usr/local/lib/libquesa.so -o test-quesa test-quesa.o
> /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/../../../../x86_64-pc-linux- 
> gnu/bin/ld:
> cannot find -l/usr/local/lib/libquesa.so
> collect2: ld returned 1 exit status
>
> i have no idea if this is quesa related or a general linking problem,  
> but
> hopefully someone can help me.
>
> Bernhard
>


Hi Bernhard:
couple of questions:

Have you isntalled quesa? ('make install' as root)

are geomtest working on this machine?

How have you get and compiled quesa?

Pax et Bonum

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

linking small test programm

[Bernhard B. <inf...@gm...>]

Hi everyone!

I'm searching for a 3D library for a university project.
ATM I'm testing quesa, but get an error when I try linking.
my prog:
#define QUESA_OS_UNIX

#include <Quesa.h>
#include <stdio.h>

int main (void) {
 Q3Initialize();
 if (Q3IsInitialized())
 {
  printf("YES\n");
  return 1;
  }
 else {
  printf("NO\n");
  return 0;
  }
}

compilation is ok with following command:
g++ -ansi -pedantic -Wall -g -c -I/usr/local/include/quesa test-quesa.cc

but linking fails with following error:
g++ -o test-quesa test-quesa.o
test-quesa.o(.text+0x9): In function `main':
/home/derber/bernhard/9.semester/programmierpraktikum/test-quesa.cc:10:=20
undefined reference to `Q3Initialize'
test-quesa.o(.text+0xe):/home/derber/bernhard/9.semester/programmierpraktik=
um/test-quesa.cc:11:=20
undefined reference to `Q3IsInitialized'
collect2: ld returned 1 exit status

when i try linking with defining libquesa explicitly, i get this error:
g++ -l /usr/local/lib/libquesa.so -o test-quesa test-quesa.o
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/../../../../x86_64-pc-linux-gnu/bin/=
ld:=20
cannot find -l/usr/local/lib/libquesa.so
collect2: ld returned 1 exit status

i have no idea if this is quesa related or a general linking problem, but=20
hopefully someone can help me.

Bernhard

[ quesa-Bugs-907857 ] RayShade misapplies textures

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

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

Category: None
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: RayShade misapplies textures

Initial Comment:
The RayShade renderer seems to be applying the whole texture to 
every triangle of a TriMesh model.  Actually, with a model that 
contains several TriMeshes, the texture from one gets applied even 
to the other (untextured) models.  Jose' comments:

"the problem could be at:
- the renderer doesn't honor the u,v parameters for the triangles
- the decomposition routine doesn't set properly the u,v in the 
resulting triangles

to test which one is you could comment out the entry in the IR 
renderer metahandler for trimeshes, and see if the problem is 
replicated in the IR"


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

>Comment By: James W. Walker (jwwalker)
Date: 2005-02-03 11:28

Message:
Logged In: YES 
user_id=433183

The example renders correctly for me with the current
version of RayShade, so it must have gotten fixed at
some point.

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

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

Reading meshes

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

What is the state of the code which reads meshes?

Whilst Microspot's programs do not generate any meshes, we
are trying to read a 3DMF file from Poser, and Quesa is looping
infinitely in e3ptrListSequence_FindPtr whilst testing if a mesh
corner has a face.

Roger.

Re: 1.6d20 release

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

On Feb 1, 2005, at 10:45 PM, Keith Wiley wrote:

> Where is there an itemized list of the differences between d18 and d20?

There are release notes inside several of the file packages, and if you 
click on the 1.6d20 line of the file release, you get the release 
notes... anyway, here they are:

** Changes from version 1.6d19 to 1.6d20:

* Improved rendering of transparent geometries.
* Quesa requests a 32-bit depth buffer from OpenGL, as opposed to the 
previous 16.
* On Mac and Windows, the OpenGL context is not destroyed and recreated 
when the window is resized.
* On Mac and Windows, texture memory can be shared between draw 
contexts.
* Added a CodeWarrior project to build Quesa as a Mach-O framework.
* Various bug fixes and optimizations.


** Changes from version 1.6d18 to 1.6d19:

* Changed from LGPL to BSD license.
* Improved window point picking of a Line geometry.
* Implemented reading/writing of NURB patches.
* Added Q3Bitmap_GetBit/Q3Bitmap_SetBit APIs.
* Added functions Q3Object_GetProperty, Q3Object_RemoveProperty, 
Q3Object_SetProperty.
* Fixed automatic mipmapping.
* Texture filters reworked to take advantage of mipmaps (QD3D parity 
and increased quality)
* Vertex colors modulated on textured geometry when using null shaders 
(QD3D parity)
* Various bug fixes and optimizations.
* Added cross-platform TGA texture reading to the Qut sample code.
* Added an XCode project.
--
<http://www.jwwalker.com/>

Re: 1.6d20 release

[Keith W. <kw...@cs...>]

Where is there an itemized list of the differences between d18 and d20?


________________________________________________________________________
Keith Wiley         kw...@cs...         http://www.unm.edu/~keithw

"Yet mark his perfect self-contentment, and hence learn his lesson,
that to be self-contented is to be vile and ignorant, and that to
aspire is better than to be blindly and impotently happy."
                                           --  Edwin A. Abbott, Flatland
________________________________________________________________________

Re: 1.6d20 release

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

I fixed the Windows SDK, and the release is now complete.
--
<http://www.jwwalker.com/>

Re: 1.6d20 release

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

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

>I've been trying to test the Windows release, but I believe the .zip is
>corrupt:
>
><ftp://ftp.frameforge3d.com/misc/quesa_1.6d20_sdk_win32.zip>
>
>I can not download it and open it on any of my machines (mac or windows).


Arrgh, you're right.  Well, I can download it, but I can't open it. 
Unfortunately the original package is on my home computer, so I won't 
be able to replace it for a few hours.  Meanwhile, I removed that 
file from the release.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: 1.6d20 release

[Lane R. <la...@if...>]

on Tue, Feb 1, 2005 James W. Walker may have said:

>Jose' Cruanyes <cru...@ce...> wrote:
>
>>well, if nobody objects, monday morning (CET time)  I'll upload the 
>>packages on sourceforge,
>
>I don't know what happened to that plan, but I will do the release. 
>The SourceForge release pages say that you must release source, so 
>I'm making a 1.6d20 source file too.

I've been trying to test the Windows release, but I believe the .zip is
corrupt:

<ftp://ftp.frameforge3d.com/misc/quesa_1.6d20_sdk_win32.zip>

I can not download it and open it on any of my machines (mac or windows).

Lane Roathe
President          Ideas From the Deep        <http://www.ifd.com>
___________________________________________________________________
When we drive on parkways, park in driveways, and never obey the speed
limit, is it any wonder our children have trouble with right and wrong?

Re: 1.6d20 release

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

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

>well, if nobody objects, monday morning (CET time)  I'll upload the 
>packages on sourceforge,

I don't know what happened to that plan, but I will do the release. 
The SourceForge release pages say that you must release source, so 
I'm making a 1.6d20 source file too.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: exceptions (was Re: First stage of Quesa changes now complete)

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

On Feb 1, 2005, at 6:01 AM, Roger Holmes wrote:

> Compiling the current CVS source using an admittedly old version of 
> Quesa.mcp, target Carbon ShLib Release with CW8.3 on 10.2.8
> I get a much smaller result. The size of the 'Quesa' file is 796k with 
> exceptions off and 832k with exceptions on. Still about 4%
> difference but over 200k smaller, about 20%  in both cases. I have 
> recently trimmed 40k off the size but I cannot account for the
> other 160k.

The project I was using had traceback tables turned on even in the 
release build.  That may account for the larger size.
--
<http://www.jwwalker.com/>

Re: exceptions (was Re: First stage of Quesa changes now complete)

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

On Tuesday, February 1, 2005, at 12:17  am, James W. Walker wrote:

> Fair enough... and since I recently told Roger "test, don't hope", I 
> did a quick test, kludging GLTextureManager.c and E3FFR_3DMF_Text.c so 
> that they could be compiled with exceptions off.  I built the Carbon 
> release CFM version of Quesa with and without exceptions.
>
> Size: with exceptions, 1046K.  Without, 1003K.  About a 4% difference.
>



Really?

Compiling the current CVS source using an admittedly old version of 
Quesa.mcp, target Carbon ShLib Release with CW8.3 on 10.2.8
I get a much smaller result. The size of the 'Quesa' file is 796k with 
exceptions off and 832k with exceptions on. Still about 4%
difference but over 200k smaller, about 20%  in both cases. I have 
recently trimmed 40k off the size but I cannot account for the
other 160k.

Roger.