Re: RayShade with XCode

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

On 18 Jul, 2006, at 21:06, James W. Walker wrote:

> Roger Holmes <rog...@mi...> wrote:
>
>> For our renderer we had a problem getting the initialisation called
>> when the Macho module gets loaded by Quesa and have patched
>> our version of Quesa so it now works. I am not sure whether
>> checking this in would be a good idea or not, I don't want to break
>> anything, but if it would be of benefit I am happy to do so.
>
> I'd like to hear more about this.  I'm using the VRML reader plugin,
> and as far as I know it's working correctly.

Ah, the problem was there but not quite as I remembered. It was getting
a reference to the plug-in's bundle. If you are writing an  
application then
this is very easy, but there does not seem to be an easy way for a  
plug-in.
Because the renderer could not find its resources it was refusing to
initialise, which is why at the start I thought the initialisation  
code had not
been called.


I defined an external routine in my plugin called  
__BeGivenMyOwnBundleRef__
(double underscores both ends of name), this has one parameter of type
CFBundleRef and returns a void.

Then I have changed e3macho_load_plugin to read thus:

static void e3macho_load_plugin( CFBundleRef theBundle )
{
	E3MacSystem_PluginSlotPtr newSlot = NULL;
	short oldResFile = CurResFile();
	
	// Load the plugin, which causes the function marked as CALL_ON_LOAD
	// to be called.
	if (CFBundleLoadExecutable( theBundle ))
	{
		newSlot = (E3MacSystem_PluginSlotPtr)Q3Memory_Allocate(sizeof 
(E3MacSystem_PluginSlot));
		
		if (newSlot != NULL)
		{
			newSlot->pluginBundle = theBundle;
			CFRetain( theBundle );
			newSlot->nextSlot = e3macsystem_pluginSlotHead;
			e3macsystem_pluginSlotHead = newSlot;
		}
		
	typedef void (*PlugInProcPtr) ( CFBundleRef theBundle ) ;

	PlugInProcPtr plugInProcPtr = (PlugInProcPtr)  
CFBundleGetFunctionPointerForName ( theBundle , CFSTR  
( "__BeGivenMyOwnBundleRef__" ) ) ;
	if ( plugInProcPtr )
		plugInProcPtr ( theBundle ) ;

	}
	
	// In case the plug-in's initialization routine changed the resource  
file
	UseResFile( oldResFile );
}


If I ever check this in we should perhaps come up with a more 'Quesa- 
ish' name than __BeGivenMyOwnBundleRef__.


>
>> Any other ideas? Either about Quesa and
>> Intel or ideas about Quesa in general. Do we have a wish
>> list? Or is that the 'to do' list, and is that up to date?
>
> Of course we have the bug and feature-request lists at SourceForge,
> but not really a simple prioritized list.
>
> A couple of wishes I've had more than once:
>
> 1. Hardware-accelerated offscreen rendering would be helpful e.g. for
> high-resolution printing.  This could be done by tiling and pbuffer
> rendering.

I always assumed it was accelerated, there is not much of a delay anyway
considering the huge number of pixels being generated. Hi-res  
printing is
not really that fast from Quartz either, but I agree a speed gain  
would be useful.

>
> 2. A new OpenGL-based renderer that would pay less attention to
> compatibility with QD3D behavior and more attention to maximizing
> performance.  For instance if we let OpenGL handle backface culling,
> it would be more practical to use vertex buffer objects.

Now your talking. The old behaviour would still have to be available of
course. There seems to be lots of new stuff in OpenGL at each WWDC,
none of which is currently much use to us. It would be great to make it
available. After all, even QuickDraw3D was designed to be extendable.

Roger Holmes,
Microspot Ltd