quesa-develop — Mailing list for Quesa development

Re: Mach-O static library

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

On Jun 14, 2005, at 5:25 AM, Don Agro wrote:

> Is anyone using the Mach-O library in a CW 8.3 Mach-O Project ?
>
> When I try to link the Quesa v1.7 libQuesa.a into a CW 8.3 Mach-O  
> project I get link errors starting with...

This does not surprise me.  It's generally a bad idea to use a static  
library containing C++ code unless you built that static library.   
There is a mismatch between the STL used to build the library and the  
STL that you use in your app.

> If I try to use Quesa.framwork it compiles and links OK but crashes  
> in dylib when run.

Now this ought to work (though I personally would not try to do Mach- 
o in CW 8).  Can you show us the relevant portion of the crash log?  
(And by the way, please join the mailing list so that your posts will  
not require moderator approval.)

Mach-O static library

[Don A. <da...@do...>]

Is anyone using the Mach-O library in a CW 8.3 Mach-O Project ?

When I try to link the Quesa v1.7 libQuesa.a into a CW 8.3 Mach-O  
project I get link errors starting with...

Link Error   : undefined: 'std::string::resize(unsigned long)' (code)
Referenced from 'e3fformat_3dmf_text_skipcomments(E3Text3DMFReader*)'  
in libQuesa.a

Link Error   : undefined: 'std::string::operator[](unsigned  
long)' (code)
Referenced from 'e3fformat_3dmf_text_skipcomments(E3Text3DMFReader*)'  
in libQuesa.a

Link Error   : undefined: 'std::string::empty()const ' (code)
Referenced from 'e3fformat_3dmf_text_skipcomments(E3Text3DMFReader*)'  
in libQuesa.a

Link Error   : undefined: 'std::allocator<char>::~allocator()' (code)
Referenced from 'e3fformat_3dmf_text_skipcomments(E3Text3DMFReader*)'  
in libQuesa.a

If I try to use Quesa.framwork it compiles and links OK but crashes  
in dylib when run.

Any ideas ?

Don Agro
www: http://www.dogparksoftware.com

Re: v1.7 Changed Something with Types?

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

Seth Willits <bm...@pa...> wrote:

>Add the two lines:
>
>     printf("Error: %i \n", error);
>     printf("kQ3ErrorNone: %i \n", kQ3ErrorNone);
>
>You should get the two warnings:
>     warning: int format, different type arg (arg 2)


OK, now I have the code

	TQ3Error error = Q3Error_Get(nil);

	if (error != kQ3ErrorNone)
	{
		printf("Error: %i \n", error);
		printf("kQ3ErrorNone: %i \n", kQ3ErrorNone);
	}

and I get no warnings.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: v1.7 Changed Something with Types?

[Seth W. <bm...@pa...>]

On May 18, 2005, at 9:29 AM, James W. Walker wrote:

> I don't usually use XCode, but I made a new project and added the  
> debug Quesa framework from 1.7.  In main.c, I added
>
> #define QUESA_OS_MACINTOSH    1
> #include <Quesa/Quesa.h>
> #include <Quesa/QuesaErrors.h>
>
> and in the main function,
>
>     if (Q3Error_Get(nil) != kQ3ErrorNone)
>     {
>
>     }
>
> It compiles with no warnings or errors.


Of course it just occured to me.... this won't give you any warnings  
or errors.


Add the two lines:

     printf("Error: %i \n", error);
     printf("kQ3ErrorNone: %i \n", kQ3ErrorNone);

You should get the two warnings:
     warning: int format, different type arg (arg 2)



I disabled the error checking entirely and the whole app still works  
fine. Except for some issues with translucent geometry. I'm not sure  
what's about.



-- Seth

Re: v1.7 Changed Something with Types?

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

Seth Willits <bm...@pa...> wrote

>>  It compiles with no warnings or errors.  Are you defining
>>QUESA_OS_MACINTOSH or QUESA_OS_COCOA?  When using CodeWarrior,
>>Quesa.h will automatically turn on QUESA_OS_MACINTOSH, but it looks
>>like XCode users must do it themselves.
>
>Yup. It's in my prefix header. It must have something to do with a
>change between the two versions. Could the change to C++ have
>changed this?

I don't see how.  That's an internal change that should not affect 
the public headers, and the public headers are all that you're using.

Without being able to reproduce the problem, I can't help.  Can you 
make a sample project that has this problem, and post it somewhere?
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: v1.7 Changed Something with Types?

[Seth W. <bm...@pa...>]

On May 18, 2005, at 9:29 AM, James W. Walker wrote:

> I don't usually use XCode, but I made a new project and added the  
> debug Quesa framework from 1.7.  In main.c, I added
>
> #define QUESA_OS_MACINTOSH    1
> #include <Quesa/Quesa.h>
> #include <Quesa/QuesaErrors.h>
>
> and in the main function,
>
>     if (Q3Error_Get(nil) != kQ3ErrorNone)
>     {
>
>     }
>
> It compiles with no warnings or errors.  Are you defining  
> QUESA_OS_MACINTOSH or QUESA_OS_COCOA?  When using CodeWarrior,  
> Quesa.h will automatically turn on QUESA_OS_MACINTOSH, but it looks  
> like XCode users must do it themselves.

Yup. It's in my prefix header. It must have something to do with a  
change between the two versions. Could the change to C++ have changed  
this?



-- Seth

Re: v1.7 Changed Something with Types?

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

On May 18, 2005, at 12:19 AM, Seth Willits wrote:

> On May 17, 2005, at 11:29 PM, James W. Walker wrote:
>
>
>> For a start, how about telling us which compiler you're using?   
>> XCode 1.5, XCode 2.0, CodeWarrior 8.3, CodeWarrior 9.5?
>>
>
> gcc 4 and 3.3. The result with both is exactly the same.
>
>
>
>> Since TQ3Error is a typedef for an enumerated type, and  
>> kQ3ErrorNone is a member of that enumeration, I don't see how  
>> there could be a mismatch.
>>
>
>
> I have a simple chunk of code which looks like:
>
>     if (Q3Error_Get(nil) != kQ3ErrorNone) {
>         ...
>         return kQ3Failure;
>     }

I don't usually use XCode, but I made a new project and added the  
debug Quesa framework from 1.7.  In main.c, I added

#define QUESA_OS_MACINTOSH    1
#include <Quesa/Quesa.h>
#include <Quesa/QuesaErrors.h>

and in the main function,

     if (Q3Error_Get(nil) != kQ3ErrorNone)
     {

     }

It compiles with no warnings or errors.  Are you defining  
QUESA_OS_MACINTOSH or QUESA_OS_COCOA?  When using CodeWarrior,  
Quesa.h will automatically turn on QUESA_OS_MACINTOSH, but it looks  
like XCode users must do it themselves.

Re: v1.7 Changed Something with Types?

[Seth W. <bm...@pa...>]

On May 17, 2005, at 11:29 PM, James W. Walker wrote:

> For a start, how about telling us which compiler you're using?   
> XCode 1.5, XCode 2.0, CodeWarrior 8.3, CodeWarrior 9.5?

gcc 4 and 3.3. The result with both is exactly the same.


> Since TQ3Error is a typedef for an enumerated type, and  
> kQ3ErrorNone is a member of that enumeration, I don't see how there  
> could be a mismatch.


I have a simple chunk of code which looks like:

     if (Q3Error_Get(nil) != kQ3ErrorNone) {
         ...
         return kQ3Failure;
     }


With d18 there's no error and all is well. With 1.7 however, this  
returns true (this is while reading a 3DMF file). I was pretty  
skeptical about there being anything actually wrong, so I did some  
investigating. I first tried:

     TQ3Error error = Q3Error_Get(nil);
     printf("%s", Q3Error_ToString(kQ3LanguageEnglishUS, error));
     if (error != kQ3ErrorNone) {
        ...
        return kQ3Failure;
     }


The result: "No error", yet when the != comparison is done, there  
*is* an error. So I dug a bit further:

     printf("Error: %i \n", error);


With gcc 4.0 I get:
     warning: format '%i' expects type 'int', but argument 2 has type  
'long long int'

My initial thought was that this was some gcc 4.0 incompatibility so  
I reverted to 3.3 and got:
     warning: int format, different type arg (arg 2)


However, with either version of gcc, if I use the framework I built  
for 1.6d18 it works just fine.



-- Seth

Re: v1.7 Changed Something with Types?

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

On May 17, 2005, at 9:14 PM, Seth Willits wrote:

> Something changed between d18 and 1.7. The old framework works  
> wonderfully but when trying the new one, I'm getting some kind of  
> screwy type conflict for TQ3Error. The compiler thinks it's a long  
> long int, and I did a big dance with flags to shrink it and force  
> to in int and such but nothing is working. The failure is that the  
> comparison between the result of Q3Error_Get(nil) and the  
> kQ3ErrorNone constant is resulting in that they are different when  
> they should be the same.
>
> So this same project that works with the d18 doesn't work now. Any  
> ideas what I should do? I didn't see anything in the release notes  
> that seemed to apply. (I could be blind - it's been known to happen.)

For a start, how about telling us which compiler you're using?  XCode  
1.5, XCode 2.0, CodeWarrior 8.3, CodeWarrior 9.5?

Since TQ3Error is a typedef for an enumerated type, and kQ3ErrorNone  
is a member of that enumeration, I don't see how there could be a  
mismatch.

v1.7 Changed Something with Types?

[Seth W. <bm...@pa...>]

Something changed between d18 and 1.7. The old framework works  
wonderfully but when trying the new one, I'm getting some kind of  
screwy type conflict for TQ3Error. The compiler thinks it's a long  
long int, and I did a big dance with flags to shrink it and force to  
in int and such but nothing is working. The failure is that the  
comparison between the result of Q3Error_Get(nil) and the  
kQ3ErrorNone constant is resulting in that they are different when  
they should be the same.

So this same project that works with the d18 doesn't work now. Any  
ideas what I should do? I didn't see anything in the release notes  
that seemed to apply. (I could be blind - it's been known to happen.)

Thanks

-- 
Seth Willits

Re: Quesa 1.7 released

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

On May 8, 2005, at 1:27 PM, Edward K.Chew wrote:

> The CFM libraries have taken on an unusual appearance:

Apparently some application on your machine "claims" the 'shlb' file  
type as its own and provides an icon for them.  Nothing to worry about.

Re: Quesa 1.7 released

[Edward K.C. <ek...@lg...>]

On May 8, 2005, at 3:03 PM, James W. Walker wrote:

>
> On May 8, 2005, at 11:44 AM, James W. Walker wrote:
>
>> I'll post again when I'm sure all the files I posted are correct.
>
> I have successfully downloaded and opened all 4 files now, though I 
> don't know how long it takes for file to reach all the mirrors.

Oh good, I was able to download it from the Phoenix mirror without any 
incidents.  Well, actually, there was one little thing that rather 
caught me by surprise!  The CFM libraries have taken on an unusual 
appearance:

Re: Quesa 1.7 released

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

Il giorno 08/mag/05, alle 21:03, James W. Walker ha scritto:

>
> On May 8, 2005, at 11:44 AM, James W. Walker wrote:
>
>> I'll post again when I'm sure all the files I posted are correct.
>>
>
> I have successfully downloaded and opened all 4 files now, though I 
> don't know how long it takes for file to reach all the mirrors.

In the meantime I've uploaded the Unix versions


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.7 released

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

On May 8, 2005, at 11:44 AM, James W. Walker wrote:

> I'll post again when I'm sure all the files I posted are correct.
>

I have successfully downloaded and opened all 4 files now, though I  
don't know how long it takes for file to reach all the mirrors.

Re: Quesa 1.7 released

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

On May 8, 2005, at 8:04 AM, Edward K.Chew wrote:

> Hmm...I just tried downloading quesa_1.7_sdk_mac.dmg from two  
> different SourceForge mirrors, and each time, I got a "no mountable  
> file systems" error from the disk image.

Sorry, my fault.  Apparently I misunderstood something about the  
SourceForge file release system.  I added files to the release as  
soon as SourceForge saw them, but I was supposed to wait until the  
uploads were complete.  I am fixing the situation now.  I'll post  
again when I'm sure all the files I posted are correct.

> By the way, I haven't been following developments in the Quesa  
> world very closely.  Is 1.7 a major departure from 1.6 in terms of  
> APIs and such, or is it more of a performance/compatibility/bug-fix  
> type release?

You can see the release notes by clicking the "1.7" on the  
SourceForge download page.  I'd say that the only major changes are  
internal, not in the APIs.

Re: Quesa 1.7 released

[Edward K.C. <ek...@lg...>]

Hmm...I just tried downloading quesa_1.7_sdk_mac.dmg from two different 
SourceForge mirrors, and each time, I got a "no mountable file systems" 
error from the disk image.

By the way, I haven't been following developments in the Quesa world 
very closely.  Is 1.7 a major departure from 1.6 in terms of APIs and 
such, or is it more of a performance/compatibility/bug-fix type 
release?

-Ted

Re: Quesa 1.7 released

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

On May 8, 2005, at 3:55 AM, Jose' Cruanyes wrote:

> What about a bulldozer breaking a fiber? ( happened friday morning,  
> perhaps solved for tomorrow) back to ISDN but no IP

That would certainly explain it!

> I can send it to you or upload them directly on sf

Go ahead and upload directly to SourceForge.  Have you updated them  
since your previous post?  I included changes through 5/5/05.

Re: Quesa 1.7 released

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

Il giorno 08/mag/05, alle 06:51, James W. Walker ha scritto:

> I went ahead and posted the 1.7 release.  I was going to update and=20
> post the Unix packages made by Jos=E9, but I could not reach his =
server.

What about a bulldozer breaking a fiber? ( happened friday morning,=20
perhaps solved for tomorrow) back to ISDN but no IP

I can send it to you or upload them directly on sf

Pax et Bonum

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

Quesa 1.7 released

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

I went ahead and posted the 1.7 release.  I was going to update and =20
post the Unix packages made by Jos=E9, but I could not reach his server.=

Re: Release 1.7

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

On May 4, 2005, at 10:32 PM, James W. Walker wrote:

> Going back to gcc 3 did not help.

I was wrong about that.  Being insufficiently familiar with XCode, I  
had apparently failed to switch the gcc version.  It does, in fact,  
compile with gcc 3.3.

Re: More problems with RasterizeCameraTransform

[Frank C. <dev...@ch...>]

On 7-May-05, at 2:54 PM, James W. Walker wrote:

> On May 7, 2005, at 11:39 AM, Frank Condello wrote:
>
>> Got a few problems with RasterizeCameraTransforms:
>
> If I recall correctly, that feature was added by Dair Grant, who is no 
> longer working on the project.  I don't know if anyone else really 
> understands it.  Personally, if I find time to work on Quesa, I'm more 
> likely to work on things useful to me, for instance I was thinking 
> about trying to write an importer plug-in for VRML files.  So I would 
> suggest that if rasterize transforms are important to you, you might 
> consider trying to fix them yourself.  Sorry I can't be more helpful.

Well that sums up the problem with Quesa - there are major bugs in the 
published APIs but the project admins have their own agendas. I don't 
blame anyone for this (it's voluntary after all), but Quesa has turned 
out to be a disappointment time and time again. I've submitted several 
fixes in the past but I think I'm finally done with Quesa - I need a 
scenegraph that works, so I can spend time writing my apps rather than 
fixing broken code...

Please don't take this personally, I can appreciate the work everyone 
has put into Quesa thus far, but perhaps removing the "d" from the 
version number isn't such a good idea at this point.

Thanks,
Frank.

Re: More problems with RasterizeCameraTransform

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

On May 7, 2005, at 11:39 AM, Frank Condello wrote:

> Got a few problems with RasterizeCameraTransforms:

If I recall correctly, that feature was added by Dair Grant, who is  
no longer working on the project.  I don't know if anyone else really  
understands it.  Personally, if I find time to work on Quesa, I'm  
more likely to work on things useful to me, for instance I was  
thinking about trying to write an importer plug-in for VRML files.   
So I would suggest that if rasterize transforms are important to you,  
you might consider trying to fix them yourself.  Sorry I can't be  
more helpful.

More problems with RasterizeCameraTransform

[Frank C. <dev...@ch...>]

Got a few problems with RasterizeCameraTransforms:

1). The docs say "Any geometry type or rendering state may be submitted  
while this transform is active" but meshes with Z depth don't render  
(you just get a very thin cross-section). I think this is normal since  
the depth is limited, but the documentation is a little misleading.  
e.g. You can't submit a sphere and expect useful results...

2). Objects are displayed upside down and backwards. Billboards can be  
easily fixed with some UV twiddling but I'm not sure this is the  
intended behaviour. To get the top/left coordinate system it's  
necessary to flip the view, so I'm not sure if much can be done about  
this.

3). Picking doesn't work - looks like picks occur in world space, as if  
the rasterize transform wasn't there.

I'm pretty sure #3 is a genuine bug, but are #1 and #2 expected  
behaviour? If they are, the documentation should probably be more clear  
on how these transforms work.

I'll post bug reports over the weekend if warranted, but if someone can  
clarify whether or not these are real problems I'd appreciate it. I  
reported another rasterize bug earlier as well:  
<http://sourceforge.net/tracker/index.php? 
func=detail&aid=1194603&group_id=45158&atid=442052>

Thanks,
Frank.

Re: Release 1.7

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

I have re-posted the 4 archives:

<ftp://ftp.jwwalker.com/misc/quesa_1.7_sdk_mac.dmg>
<ftp://ftp.jwwalker.com/misc/quesa_1.7_sdk_win32.zip>
<ftp://ftp.jwwalker.com/misc/quesa_1.7_source_mac.dmg>
<ftp://ftp.jwwalker.com/misc/quesa_1.7_source_win32.zip>

These include the several source changes submitted in the last few  
days, and the Mac SDK includes the Mach-O static library (built under  
Panther). If there are no objections, I'd like to do the release this  
weekend.

[ quesa-Bugs-1196267 ] Texture matrix not properly set for transparent primitives

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

Bugs item #1196267, was opened at 2005-05-05 19:21
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=1196267&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank Condello (pox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Texture matrix not properly set for transparent primitives

Initial Comment:
The interactive renderer's transparency pass doesn't handle texture 
shader matrix transforms. It also doesn't doesn't reset the GL 
texture matrix, so any translations on the last solid texture affect all 
transparent primitives.

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

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