quesa-develop — Mailing list for Quesa development

Re: Quesa Mach-O static lib

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

On 2005-07-12 16:38, Don Agro said:

>> The quesa=5F1.7=5Fsdk=5Fmac includes Debug and Release variants for most
>> things, except the Mach-O static library.  Is it a debug or release  
>> build=3F
>
>I used the Quesa Framework in Quesa 1.7/Developers/Frameworks/ 
>Frameworks (Mach-O)
>
>Works great in Mach-O builds. Dropped it into my application / 
>Contents/Frameworks/ folder.
>No installer required.

=46rameworks are great I agree, but there are still cases where static
libs are more appropriate, and I'd still like to know if the Quesa
static lib is Debug or Release.

-- 
=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

Setting framework details

[Steven V. <is...@ma...>]

Hi,

Op 13-jul-05 om 5:27 heeft que...@li... 
het volgende geschreven:
>
> That 1.0.0 suggests that you linked against a different copy of Quesa
> than the one you ran with.  See if you have some old copy of Quesa
> floating around, say in /Library/Frameworks or ~/Library/Frameworks.
> -- 
>    James W. Walker, ScriptPerfection Enterprises, Inc.
>    <http://www.write-brain.com/>
>

I have fixed the issue now, but really this is still a fault that lies 
at quesa. The framework needs to have the following changes:

For Target Quesa:
Installation Path	@executable_path/../Frameworks/		Instead of 
$(HOME)/Library/Frameworks // <-- this caused the error
Other Linker Flags	-seg1addr 0x12000000				This is required for 
prebinding. This causes prebinding for me but depending on what you 
link quesa against this might not work.

Also all the quesa headers need to have their roles set to public.

And of course it would be nice if all properties were set; like version 
to 1.7 and identifier to com.Company.Quesa or something.

This would save me an hour every time I download Quesa from CVS.

Steven Verstoep
www.revaro.net

Re: Quesa Mach-O static lib

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

On 12-Jul-05, at 4:20 PM, Sean McBride wrote:

> The quesa_1.7_sdk_mac includes Debug and Release variants for most
> things, except the Mach-O static library.  Is it a debug or release  
> build?

I used the Quesa Framework in Quesa 1.7/Developers/Frameworks/ 
Frameworks (Mach-O)

Works great in Mach-O builds. Dropped it into my application / 
Contents/Frameworks/ folder.
No installer required.

Best Regards,
Don Agro

D o g   P a r k   S o f t w a r e   L t d .

email: da...@do...
   www: http://www.dogparksoftware.com
       iChat AV:do...@ma...

Quesa Mach-O static lib

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

Hi all,

The quesa=5F1.7=5Fsdk=5Fmac includes Debug and Release variants for most
things, except the Mach-O static library.  Is it a debug or release build=3F

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: latest Quesa best ever

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

Steven Verstoep <is...@ma...> wrote:

>There was just one slight problem when i ran my app. At first my 
>application wouldn't launch and gave the following error:
>
>[Session started at 2005-07-12 16:25:55 +0200.]
>dyld: /Users/steven/Development OSX/Adrenalin Racing/build/Adrenalin 
>Racing.app/Contents/MacOS/Adrenalin Racing version mismatch for 
>library: /Users/steven/Development OSX/Adrenalin 
>Racing/build/Adrenalin 
>Racing.app/Contents/MacOS/../Frameworks/Quesa.framework/Versions/A/Quesa 
>(compatibility version of user: 1.6.0 greater than library's 
>version: 1.0.0)
>
>Executable "Adrenalin Racing" has exited due to signal 5 (SIGTRAP).
>
>I then set the version of quesa to 1.7 and rebuild everything. Then 
>it ran fine. Maybe the xcode framework can be updated in CVS with 
>the correct properties?


That 1.0.0 suggests that you linked against a different copy of Quesa 
than the one you ran with.  See if you have some old copy of Quesa 
floating around, say in /Library/Frameworks or ~/Library/Frameworks.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

latest Quesa best ever

[Steven V. <is...@ma...>]

Hi

I subscribed yesterday to this mailing list. I tried the precompiled =20
1.7 SDK. There were still some problems
*__glTessErrorString(int) is called and takes up 15% of cpupower when =20=

rendering a custom texture
* e3group_display_ordered_duplicate crashed
*Background scenery images disappeared

However today I downloaded the latest version from CVS and I am glad to =20=

say that this is the *first* version that renders my game perfect since =20=

OS9. Special thanks to James W for making such a quick fix to the =20
e3group_display_ordered_duplicate code.

There was just one slight problem when i ran my app. At first my =20
application wouldn't launch and gave the following error:

[Session started at 2005-07-12 16:25:55 +0200.]
dyld: /Users/steven/Development OSX/Adrenalin Racing/build/Adrenalin =20
Racing.app/Contents/MacOS/Adrenalin Racing version mismatch for =20
library: /Users/steven/Development OSX/Adrenalin Racing/build/Adrenalin =20=

Racing.app/Contents/MacOS/../Frameworks/Quesa.framework/Versions/A/=20
Quesa (compatibility version of user: 1.6.0 greater than library's =20
version: 1.0.0)

Executable =93Adrenalin Racing=94 has exited due to signal 5 (SIGTRAP).

I then set the version of quesa to 1.7 and rebuild everything. Then it =20=

ran fine. Maybe the xcode framework can be updated in CVS with the =20
correct properties?

Steven Verstoep
www.revaro.net=20=

Re: External Screen on Powerbook?

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

On 11 Jul, 2005, at 21:40, Steven Verstoep wrote:

> Hi Roger
>
> I will experiment tomorrow some more with the suggestions you gave
>
> >Of course if you customer has a machine with more VRAM
> >then they may not have the same size limitation. Are you by any chance
> >running on a Powerbook with an external screen attached?
>
> Yes I am. What do you conclude from this?
>
> I have a powerbook G4 550mhz, 512mb Ram Ati Rage 16mb video, OSX 
> 10.3.9 with an external screen set at 640x480x32bit (Game Resolution 
> Full screen)
>
> Steven Verstoep
> www.revaro.net
>
>

Hi Steven,

I used to have a very similar setup but with a 20 inch monitor. The 
built in screen
and the external screen both use up a chunk of VRAM, leaving OpenGL 
very little
space for the Z-buffer, its other buffers, triangle lists and texture 
memory.

In this configuration I used to get bizarre texture effects when using 
anything but the
smallest 3D windows. You could try disconnecting the external monitor 
and use just
the internal one and see if the problem goes away. Then you could 
change your
system requirements specification to preclude Powerbooks with external 
monitors.
Outside the developer community they are quite a rare configuration I 
believe.

Roger Holmes.

Re: Announcing Cartoon Renderer

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

I wrote:

>I suppose we could do something similar for the parts of glext.h 
>needed for the multitexturing extension.

OK, I have removed the need for glext.h in CartoonRenderer.cpp.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Announcing Cartoon Renderer

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

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

>>   Anyway, OpenGL 1.0 is too old to include extensions.
>
>Do we need extensions? I compile OK with the old version.

I see that there are already some workarounds in Quesa for the lack 
of glext.h:  GLUtils.c defines GL_CLAMP_TO_EDGE and IRLights.c 
defines GL_LIGHT_MODEL_COLOR_CONTROL and such.  I suppose we could do 
something similar for the parts of glext.h needed for the 
multitexturing extension.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Announcing Cartoon Renderer

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

On 11 Jul, 2005, at 19:11, James W. Walker wrote:

>
> How would it know?

How about:

#ifdef GL_VERSION_1_2

>  Anyway, OpenGL 1.0 is too old to include extensions.

Do we need extensions? I compile OK with the old version.

Re: Announcing Cartoon Renderer

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

"Joseph J. Strout" <jo...@st...> wrote:

>Shouldn't it calculate them if it needs them?  Vertex normals are
>not required for a TriMesh to be well-formed, IIRC... in fact, under
>QD3D, refraining from supplying vertex normals was a good way to get
>a "faceted" look (with each polygon given a uniform shade, rather
>than blending).

Yes, I suppose it could fall back to using face normals.  Feel free 
to fix it. :-)
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Is quesa alive?

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

Steven Verstoep <is...@ma...> wrote:

>### Cars no longer have wheels
>	I started debugging this, but now it even crashes when I load
>my wheels. The code that crashes is:
>e3group_display_ordered_duplicate when I duplicate 	a wheel
>trimesh from a list of preloaded wheels to use for the car.


It turns out there was a bug in e3group_display_ordered_duplicate.  I 
just committed a fix to CVS.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Announcing Cartoon Renderer

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

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

>I have checked out a new Quesa.mcp and the path points nowhere useful.

You're supposed to set the OpenGL_SDK source tree to point to your OpenGL SDK.

>If I open an old Quesa.mcp I find it points inside the Metroworks 
>MacOS Support
>files to OpenGL SDK 1.0 . This has always been fine up to now. Can't 
>the header
>file which includes the Cartoon Renderer be conditional on what 
>version of OpenGL
>is being used?

How would it know?  Anyway, OpenGL 1.0 is too old to include extensions.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Announcing Cartoon Renderer

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

I have checked out a new Quesa.mcp and the path points nowhere useful.

If I open an old Quesa.mcp I find it points inside the Metroworks MacOS 
Support
files to OpenGL SDK 1.0 . This has always been fine up to now. Can't 
the header
file which includes the Cartoon Renderer be conditional on what version 
of OpenGL
is being used?

Roger.





On 11 Jul, 2005, at 18:19, James W. Walker wrote:

> Roger Holmes <rog...@mi...> wrote:
>
>> I am compiling the CFM ( Carbon Shared Lib Debug ) project, and yes I
>> have checked out the Quesa.mcp file. I am still running on 10.3.9, 
>> maybe
>> that is the problem?
>
> No, the OS version has little to do with it when building CFM.  What 
> does your OpenGL_SDK access path point to?  Mine points to a folder 
> named "OpenGL SDK 1.2 Core", which I think came with some CarbonLib 
> SDK.  Inside, in the Headers folder, I have glext.h.
> -- 
>   James W. Walker, ScriptPerfection Enterprises, Inc.
>   <http://www.write-brain.com/>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar 
> happening
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in 
> dual
> core and dual graphics technology at this free one hour event hosted 
> by HP,
> AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

Re: Is quesa alive?

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

Hi Steven,

I don't have a solution but I do have some suggestions on how to  
proceed.

IRRenderer_Texture_ConvertSize only gets called if your texture's size  
if not a power of 2 (which you say it is) or it is greater than OpenGL  
can handle. Maybe you could try 128x128 and see if that works. If you  
only use the interactive renderer, and that is reducing your texture to  
a smaller size then there is nothing to be gained from submitting a  
large texture. Of course if you customer has a machine with more VRAM  
then they may not have the same size limitation. Are you by any chance  
running on a Powerbook with an external screen attached?


As far as the missing wheels are concerned, can you save the data you  
are rendering as 3DMF? Could you e-mail the file to me?

How are you drawing the background? If you are drawing with QuickDraw  
and then overwriting with 3D data with the interactive renderer, then  
that was broken a long time ago. Though my apps are not games, most of  
the Quesa people have games applications and they need the full speed  
which OpenGL can provide using the graphics processors on the video  
cards. Unfortunately these take over the window totally and you cannot  
mix QuickDraw or even Quartz graphics with 3D data. I had to recode my  
programs to use a new facility which provides a camera transform for  
either background or foreground (or even somewhere in between). The  
details are in the list archives I'm sure.

Roger Holmes.
Microspot Ltd.




On 11 Jul, 2005, at 17:42, Steven Verstoep wrote:

> Hi all,
>
> I just subscribed to this list, but I am not new to quesa. I have  
> subscribed to more lists and forums, but I was just posting to dead  
> threads for years! (that was about a year ago). Anyway I want to do an  
> update to my game adrenalin racing. I noticed that the site quesa has  
> been updated so that makes me believe that quesa is alive.
>
> I have downloaded quesa 1.7 from sourceforge (I used to have 1.6).  
> Version 1.7 fixed the following issues for me:
>
> - Starting a race displays garbage on screen
> - First 3 frames are flickering with window backgroundcolor => frame  
> <=> backgroundcolor flicker (Quesa actually creates the DrawContext 3  
> times)
> - 2 player ghost/arcade crashes (is the error caused by the level  
> picture overview?)
>
> But it created 3 new Issues. Maybe someone can shed some light on this:
>
> ### Showroom rendering sometimes gets totally white and hogs up  
> cpupower. I did a shark and found the following:
> 	If I render a trimesh which is texturemapped with a texture which  
> displays the capabilities of the car __glTessErrorString(int) is  
> called and takes up 15% 	of cpupower. The texture is created at  
> runtime and is 256x128 in size (and is only created once). The total  
> function call path is:
>
> __glTessErrorString(int)	gluScaleImageCTX	gluScaleImage	 
> IRRenderer_Texture_ConvertSize	IRRenderer_Texture_ConvertImage	 
> ir_texture_load(TQ3CachedTexture*)	 
> ir_texture_cache_add(OpaqueTQ3Object*, TQ3InteractiveData*,  
> OpaqueTQ3Object*,  
> OpaqueTQ3Object*)	IRRenderer_Texture_Set	 
> IRRenderer_Update_Shader_Surface	E3Renderer_Method_UpdateShader	 
> e3view_stack_update(E3View*, unsigned  
> long)	E3View_State_SetShaderSurface	 
> e3shader_surface_submit(OpaqueTQ3Object*, long, OpaqueTQ3Object*, void  
> const*)	e3view_submit_retained_render(E3View*,  
> OpaqueTQ3Object*)	E3View_SubmitRetained	E3Object_Submit	 
> Q3Object_Submit	IRGeometry_Attribute_Handler	IRGeometry_Submit_TriMesh 
> 	E3Renderer_Method_SubmitGeometry	e3geometry_render(OpaqueTQ3Object*,  
> long, OpaqueTQ3Object*, void  
> const*)	e3view_submit_retained_render(E3View*,  
> OpaqueTQ3Object*)	E3View_SubmitRetained	E3Object_Submit	 
> Q3Object_Submit	e3group_submit_contents(OpaqueTQ3Object*, long,  
> E3Group*, void  
> const*)	e3group_display_submit_contents(OpaqueTQ3Object*, long,  
> OpaqueTQ3Object*, void const*)	e3view_submit_retained_render(E3View*,  
> OpaqueTQ3Object*)	E3View_SubmitRetained	E3DisplayGroup_Submit	 
> Q3DisplayGroup_Submit	RenderOverview	MakeShowRoom	ArcadeScreen
>
> ### Cars no longer have wheels
> 	I started debugging this, but now it even crashes when I load my  
> wheels. The code that crashes is: e3group_display_ordered_duplicate  
> when I duplicate 	a wheel trimesh from a list of preloaded wheels to  
> use for the car.
> ### Background scenery images dissappear
> 	I use a texture in the order of 1024x768 as a background scenery for  
> the environment. This is actually a trimesh that is texture 	mapped. I  
> put two of them next to each other to have a seamless scrolling  
> background. Now it happens that the textures start flickering.  
> Sometimes they 	are rendered correctly and sometimes they are  
> completely blue. Also sometimes the left one does render but not the  
> right one or visa versa.
>
> All this used to work on previous versions of quesa and Quickdraw 3D  
> 0S9
>
> Steven Verstoep
> www.revaro.net
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar  
> happening
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in  
> dual
> core and dual graphics technology at this free one hour event hosted  
> by HP,
> AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

Re: Is quesa alive?

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

Steven Verstoep <is...@ma...> wrote:

>But it created 3 new Issues. Maybe someone can shed some light on this:
>
>### Showroom rendering sometimes gets totally white and hogs up
>cpupower. I did a shark and found the following:
>	If I render a trimesh which is texturemapped with a texture
>which displays the capabilities of the car __glTessErrorString(int)
>is called and takes up 15% 	of cpupower. The texture is created
>at runtime and is 256x128 in size (and is only created once). The
>total function call path is:
>
>__glTessErrorString(int)	gluScaleImageCTX	gluScaleImage
>	IRRenderer_Texture_ConvertSize
>	IRRenderer_Texture_ConvertImage
>	ir_texture_load(TQ3CachedTexture*)

This does not make sense.  Looking at the code, the only time 
IRRenderer_Texture_ConvertSize is called is if the texture dimensions 
are not powers of 2, or they exceed the GL_MAX_TEXTURE_SIZE parameter 
of the OpenGL renderer.  Neither should happen for a 256x128 texture.

Does anything show up in the console?

>### Cars no longer have wheels
>	I started debugging this, but now it even crashes when I load
>my wheels. The code that crashes is:
>e3group_display_ordered_duplicate when I duplicate 	a wheel
>trimesh from a list of preloaded wheels to use for the car.

No idea.  I duplicate trimeshes all the time.  Though I don't use 
ordered display groups.  If you have a 3DMF file that, when loaded, 
cannot be duplicated, you can send it to me and I'll take a look.

>### Background scenery images dissappear
>	I use a texture in the order of 1024x768 as a background
>scenery for the environment. This is actually a trimesh that is
>texture 	mapped. I put two of them next to each other to have
>a seamless scrolling background. Now it happens that the textures
>start flickering. Sometimes they 	are rendered correctly and
>sometimes they are completely blue. Also sometimes the left one does
>render but not the right one or visa versa.

1024x768 is pretty big, and of course 768 is not a power of 2, but 
still this should work.  Conceivably it could depend on your video 
hardware.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Announcing Cartoon Renderer

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

Il giorno 11/lug/05, alle 18:55, Roger Holmes ha scritto:

> 		#include <glext.h>                             <------- THIS IS THE 
> ONE WHICH IS FAILING

I'm using the OpenGL SDK 1.2 and it has this file

you can find it also in the OpenGL.framework headers at least since 
1.2.7

where are you picking your OpenGL headers?

Pax et Bonum

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

Re: Announcing Cartoon Renderer

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

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

>I am compiling the CFM ( Carbon Shared Lib Debug ) project, and yes I
>have checked out the Quesa.mcp file. I am still running on 10.3.9, maybe
>that is the problem?

No, the OS version has little to do with it when building CFM.  What 
does your OpenGL_SDK access path point to?  Mine points to a folder 
named "OpenGL SDK 1.2 Core", which I think came with some CarbonLib 
SDK.  Inside, in the Headers folder, I have glext.h.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Announcing Cartoon Renderer

[Joseph J. S. <jo...@st...>]

At 10:10 AM -0700 7/8/05, James W. Walker wrote:

>>I've noted that sometimes the Cartoon renderer misses some polys, 
>>but I cant see a pattern, you can see it loading in Geom Test 
>>"PodRacer.3dmf"
>>this is a bug or a feature?
>>it happens with some of my models too...
>
>In the PodRacer, one of the TriMeshes lacks vertex normals.  The 
>cartoon shading algorithm needs vertex normals.

Shouldn't it calculate them if it needs them?  Vertex normals are not 
required for a TriMesh to be well-formed, IIRC... in fact, under 
QD3D, refraining from supplying vertex normals was a good way to get 
a "faceted" look (with each polygon given a uniform shade, rather 
than blending).

Best,
- Joe

P.S. This cartoon renderer sounds cool -- I can't wait to try it!

-- 
,------------------------------------------------------------------.
|    Joseph J. Strout         Check out the Mac Web Directory:     |
|    jo...@st...           http://www.macwebdir.com/            |
`------------------------------------------------------------------'

Re: Is quesa alive?

[Joseph J. S. <jo...@st...>]

At 6:42 PM +0200 7/11/05, Steven Verstoep wrote:

>I just subscribed to this list, but I am not new to quesa. I have 
>subscribed to more lists and forums, but I was just posting to dead 
>threads for years! (that was about a year ago).

Maybe you subscribed to the old list.  That has indeed been defunct 
ever since we moved over to SourceForge.

Anyway, yes, Quesa is very much alive (yours is the fifth message on 
this list just today!).

I haven't any insight on the specific problems you're seeing, though 
-- hopefully someone else can shed some light.

Best,
- Joe

-- 
,------------------------------------------------------------------.
|    Joseph J. Strout         Check out the Mac Web Directory:     |
|    jo...@st...           http://www.macwebdir.com/            |
`------------------------------------------------------------------'

Re: Announcing Cartoon Renderer

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

I am compiling the CFM ( Carbon Shared Lib Debug ) project, and yes I
have checked out the Quesa.mcp file. I am still running on 10.3.9, maybe
that is the problem?


The code says:

#if QUESA_OS_MACINTOSH
	#if TARGET_RT_MAC_MACHO
		#include <OpenGL/glext.h>
	#else
		#include <glext.h>                             <------- THIS IS THE 
ONE WHICH IS FAILING
	#endif
#elif QUESA_OS_COCOA
	#include <OpenGL/glext.h>
#else
	// NOTE: this include file is not provided with Win32 sdk
	// you can get it at 
<http://oss.sgi.com/projects/ogl-sample/ABI/glext.h>
	// and put it in your GL directory (search for gl.h to find it)
	#include <GL/glext.h>
#endif



Roger.




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

>
> On Jul 11, 2005, at 9:23 AM, Roger Holmes wrote:
>
>> Another problem, now it says can't find glext.h
>
> What platform?  CFM, Mach-O, Windows, or Unix?  If it's Windows, I 
> mentioned earlier in this thread...
>
>> There's one thing I'm uncertain about concerning the Window project.  
>> The cartoon renderer includes <GL/glext.h>.  This file is apparently 
>> not a standard part of the Win32 SDK, but can be downloaded from 
>> <http://oss.sgi.com/projects/ogl-sample/ABI/glext.h>.  So, should 
>> Quesa provide that file, someplace other than the standard GL 
>> directory, or trust people to find it, or what?

Is quesa alive?

[Steven V. <is...@ma...>]

Hi all,

I just subscribed to this list, but I am not new to quesa. I have  
subscribed to more lists and forums, but I was just posting to dead  
threads for years! (that was about a year ago). Anyway I want to do an  
update to my game adrenalin racing. I noticed that the site quesa has  
been updated so that makes me believe that quesa is alive.

I have downloaded quesa 1.7 from sourceforge (I used to have 1.6).  
Version 1.7 fixed the following issues for me:

- Starting a race displays garbage on screen
- First 3 frames are flickering with window backgroundcolor => frame  
<=> backgroundcolor flicker (Quesa actually creates the DrawContext 3  
times)
- 2 player ghost/arcade crashes (is the error caused by the level  
picture overview?)

But it created 3 new Issues. Maybe someone can shed some light on this:

### Showroom rendering sometimes gets totally white and hogs up  
cpupower. I did a shark and found the following:
	If I render a trimesh which is texturemapped with a texture which  
displays the capabilities of the car __glTessErrorString(int) is called  
and takes up 15% 	of cpupower. The texture is created at runtime and is  
256x128 in size (and is only created once). The total function call  
path is:

__glTessErrorString(int)	gluScaleImageCTX	gluScaleImage	 
IRRenderer_Texture_ConvertSize	IRRenderer_Texture_ConvertImage	 
ir_texture_load(TQ3CachedTexture*)	 
ir_texture_cache_add(OpaqueTQ3Object*, TQ3InteractiveData*,  
OpaqueTQ3Object*,  
OpaqueTQ3Object*)	IRRenderer_Texture_Set	 
IRRenderer_Update_Shader_Surface	E3Renderer_Method_UpdateShader	 
e3view_stack_update(E3View*, unsigned  
long)	E3View_State_SetShaderSurface	 
e3shader_surface_submit(OpaqueTQ3Object*, long, OpaqueTQ3Object*, void  
const*)	e3view_submit_retained_render(E3View*,  
OpaqueTQ3Object*)	E3View_SubmitRetained	E3Object_Submit	Q3Object_Submit 
	IRGeometry_Attribute_Handler	IRGeometry_Submit_TriMesh	 
E3Renderer_Method_SubmitGeometry	e3geometry_render(OpaqueTQ3Object*,  
long, OpaqueTQ3Object*, void  
const*)	e3view_submit_retained_render(E3View*,  
OpaqueTQ3Object*)	E3View_SubmitRetained	E3Object_Submit	Q3Object_Submit 
	e3group_submit_contents(OpaqueTQ3Object*, long, E3Group*, void  
const*)	e3group_display_submit_contents(OpaqueTQ3Object*, long,  
OpaqueTQ3Object*, void const*)	e3view_submit_retained_render(E3View*,  
OpaqueTQ3Object*)	E3View_SubmitRetained	E3DisplayGroup_Submit	 
Q3DisplayGroup_Submit	RenderOverview	MakeShowRoom	ArcadeScreen

### Cars no longer have wheels
	I started debugging this, but now it even crashes when I load my  
wheels. The code that crashes is: e3group_display_ordered_duplicate  
when I duplicate 	a wheel trimesh from a list of preloaded wheels to  
use for the car.
### Background scenery images dissappear
	I use a texture in the order of 1024x768 as a background scenery for  
the environment. This is actually a trimesh that is texture 	mapped. I  
put two of them next to each other to have a seamless scrolling  
background. Now it happens that the textures start flickering.  
Sometimes they 	are rendered correctly and sometimes they are  
completely blue. Also sometimes the left one does render but not the  
right one or visa versa.

All this used to work on previous versions of quesa and Quickdraw 3D 0S9

Steven Verstoep
www.revaro.net

Re: Announcing Cartoon Renderer

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

On Jul 11, 2005, at 9:23 AM, Roger Holmes wrote:

> Another problem, now it says can't find glext.h

What platform?  CFM, Mach-O, Windows, or Unix?  If it's Windows, I  
mentioned earlier in this thread...

> There's one thing I'm uncertain about concerning the Window  
> project.  The cartoon renderer includes <GL/glext.h>.  This file is  
> apparently not a standard part of the Win32 SDK, but can be  
> downloaded from <http://oss.sgi.com/projects/ogl-sample/ABI/ 
> glext.h>.  So, should Quesa provide that file, someplace other than  
> the standard GL directory, or trust people to find it, or what?

Re: Announcing Cartoon Renderer

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

Another problem, now it says can't find glext.h

Roger.

On 11 Jul, 2005, at 17:02, James W. Walker wrote:

>
> On Jul 11, 2005, at 7:25 AM, Roger Holmes wrote:
>
>> I have just done an update in Mac CVS Pro, including the .mcp
>> file. I use CodeWarrior 8.3 to compile the Carbon Shared Lib
>> debugging version and it cannot find CartoonRenderer.h or
>> CartoonRenderer.cpp. I have searched my hard disk and
>> cannot find these files. Were they not checked in or am I
>> being stupid?
>>
>
> Try doing a check out instead of an update.  I'm not sure if an update 
> always gives you new files or directories.

Re: Announcing Cartoon Renderer

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

Thanks, that did it.


On 11 Jul, 2005, at 17:02, James W. Walker wrote:

>
> On Jul 11, 2005, at 7:25 AM, Roger Holmes wrote:
>
>> I have just done an update in Mac CVS Pro, including the .mcp
>> file. I use CodeWarrior 8.3 to compile the Carbon Shared Lib
>> debugging version and it cannot find CartoonRenderer.h or
>> CartoonRenderer.cpp. I have searched my hard disk and
>> cannot find these files. Were they not checked in or am I
>> being stupid?
>>
>
> Try doing a check out instead of an update.  I'm not sure if an update 
> always gives you new files or directories.