Re: Depth buffer option

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

At 9:36 PM +0100 6/1/04, Dair Grant wrote:

>This means you won't be able to take a QD3D app and use it as-is, but is
>that still going to be a problem? After N years of saying we must be
>backwards compatible, I realise this must sound a bit shocking. :-)

It would be a problem for me.  REALbasic still runs happily under 
both Quesa and QD3D, and I see no near-term change in the need to do 
that.

>The question is, how much upgrading of client code is acceptible in
>order to let the API grow? If it was done in such a way that existing
>code continued to work, but new features mean using a new API, would
>that be OK?

Yes, that's OK -- we already have several new APIs of that sort. 
Code that wants to stay QD3D compatible simply ignores them.  But any 
changes that would require us to fork our code would be quite onerous 
-- especially considering that a classic app may be running against 
either QD3D or Quesa, and can't know at compile time which it will be.

>Don't know - just thinking out loud. One of the problems with the
>original API is there's no way to extend these structures in the future
>without breaking older code.
>
>If each structure started with a size or version field then this problem
>would be avoided, so perhaps this would be a good point to think about
>gradually upgrading the API to be future-proof?

Yes, when we're touching things anyway, we certainly should keep that in mind.

Here's one mildly hackish way to do something similar without 
breaking backwards compatibility: add an API for declaring what 
version of the Quesa structures you are compiling with.  (There will 
be some constant in the Quesa headers which you can pass right in for 
this purpose.)  This has global effects on what layout we expect for 
the structures.

In a true shared-library environment, where several clients can be 
sharing the  same Quesa memory, we'll have to take care to store this 
in a data area associated with a particular client.  But I think 
that's doable.

When we present code snippets that require a certain version of 
Quesa, we can indicate that using the same constant, e.g.

   #if kQ3HeadersVersion < 0x0170
	#warning This neat trick requires Quesa headers 1.7 or later
   #else
	...

>I guess an ideal-looking API for me would be:
>
>- Version/size-tagged struct to create objects and do batch data get/set
>
>- A common Q3Object_GetValue/SetValue API to assign tagged values to an
>object

Yes, this would be very cool.

Best,
- Joe

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