Re: [Gnu3dkit-dev] New core API

[Brent Gulanowski]

General response to this is that I think it makes more sense to 
consider general tasks that need to be performed before trying to 
assign them to classes or functions.

On Thursday, December 26, 2002, at 06:46  AM, Philippe C.D. Robert 
wrote:

> Hi,
>
> spending more time on all that some more simplifications might be 
> possible:
>
> On Monday, December 23, 2002, at 07:18  Uhr, Philippe C.D. Robert 
> wrote:
> > o G3DContextManager
> >   Manages rendering contexts
>
> Maybe this can be internal only, or even be integrated into the 
> context class itself?!

The only reason to have a distinct "context" from "manager" is if a 
manager could handle multiple contexts at the same time.
> > o G3DFrustum
> >   The frustum used by a camera object.
>
> Maybe this is too much of OO - should we integrate this functionality 
> into the camera itself? In the old 3DKit this design approach resulted 
> in some annoying implementation hacks w/o providing additional value 
> in terms of usability.

A frustum is really a small thing, with hardly any behaviour other than 
accessor methods. Moreover the data inside is not particularly 
vulnerable. I think you should just fold the frustum into the camera.
> > o G3DApplication
> >   The application singleton used to setup a GNU 3DKit application, 
> > ie. to
> >   specify the threading model and renderer backend
>
> I now think that we should not provide this class in the core API. 
> Instead we should make sure that the various actions can be performed 
> using multiple threads. Otherwise the API becomes IMHO too heavy.

I don't see why the core application object should have to correspond 
to any particular protocol (I don't mean Obj-C protocol necessarily). 
The application should do little more than act as the setup and 
teardown and the root of the object hierarchy. If you need a way to 
ensure that an application has certain properties, make a convenience 
class which can have them (possibly delegate class), and otherwise 
provide specifications so that developers can design their own 
application which satisfies the requirements of 3DKit.
> > o G3DShader
> >   Shaders describe the appearance of a shape. The use of a standard 
> > shading
> >   languages would be very interesting here.
>
> We might use the RSL here, or at least a similar approach.
>
> Moreover I'd like to hear from you whether you prefer having 
> everything packed into an ObjC class or not - think of bounding boxes, 
> bounding spheres, transformations and so on... Personally I would go 
> for C constructs here, but maybe this is way too "old school"...:-)

If some construct has a lot of behaviour, make a class out of it. Also 
if the data is fragile, make a class out of it. I would like to use 
Obj-C semantics whenever possible, but wrapper classes which don't do 
anything except put up walls and gates around disposable data are 
pointless. But Obj-C messages make for much clearer code, in my 
opinion, than function calls which require explicit specification of 
the pointer.

I would like as much of the exposed API to be Obj-C, and internal use 
C-style wherever convenient, but draw some meaningful borders between 
code modules and ensure safety when crossing them. Tiny objects are 
overkill, but huge nested structures are dangerous. Let's find a middle 
ground.

Brent Gulanowski
--
Mac game development news and discussion
http://www.idevgames.com