Re: [Plib-devel] On First Looking Into Baker's SSG (with apologies to John Keats)

[Steve B. <sjb...@ai...>]

Fay John F Contr AAC/WMG wrote:

> (1) There are several places where tabs are used for indentation instead 
> of spaces. (ssg.cxx:404,405; ssg.h:357-358, 450)

Should be spaces - tabs are not portable.

> (5) In "ssg.h" starting around line 133 there is a rather complex series 
> of functions that set type data.  The PUI version is considerably more 
> efficient, but I think I remember there being a discussion about doing 
> SSG this way so as to avoid a hard limitation on 32 bits.  I would like 
> to suggest adding a comment to this effect.

The problem is that lots of SSG programs use the present system and it's
hard to fix without breaking them.  Nobody was using the PUI flags when it
was changed.

> (6) From what I gather from "ssg.cxx", we do not have writers for the 
> "dof", "md2", "strip", "mdl", or "xpl" file formats and we do not have 
> loaders for the "asc" or "pov" file formats (the latter is commented out 
> entirely).  Do we need them? Do we want them?

We want as many loaders and writers as we can get.  Few people are interested
in creating writers though because most SSG applications read data files - but
don't write them.

> (7) The file "ssgBase.cxx" has a variable "next_unique_id" that starts 
> at 1 and is incremented every time a new "ssgBase" object is created.  
> The operation used for this is a postfix "++".  I am told that a prefix 
> "++" is ever-so-slightly faster because you don't have to save the 
> return value before incrementing the variable.

I didn't know that.  Oh well, object creation is not exactly a high bandwidth
operation and compared to the memory allocation cost, it's likely to be a
VERY tiny percentage of the overall time.

>  Do we want to initialize 
> the variable to 0 (on line 27) and increment it (on line 68) with a 
> prefix "++"?

Feel free!

> (8) In the "ssgBase::print" function, do we want to print out the unique 
> ID as well?  Just asking ... and not pretending to have any knowledge in 
> the area.

That function is really just for debug...I've never felt a need to know
the unique ID.

> (9) In the "ssgList::removeAllEntities" function (ssgList.cxx:94), the 
> function removes entity 0 repeatedly until the list is empty.  This is a 
> lot like unpiling a stack of bricks by removing the bottom one each 
> time; the "removeEntity" involves a "memmove" call each time.  Why 
> doesn't the "removeAllEntities" function simply set "total" and "next" 
> to zero?  At the very least, we can speed up the "memmove" calls by 
> invoking "removeEntity" with an argument of "total-1" instead of "0".

Yes.

> (10) Do we want to implement PUI-type RTTI in the SSG functions?

We talked about it - but see my answer to (5) above.

> Under the heading of real issues:
> (11) How would we implement the "puValue" functionality in SSG?  Should 
> we just add it to "ssgBase" or should it remain separate?  If the 
> latter, should we use multiple inheritance in the SSG widgets?

I dislike multiple inheritance - it causes no end of problems in complex
inheritance trees - so let's not do *that*.

Do we need puValue functionality in every node?   Seems to me that it's
really only needed in leaf nodes - so I'd probably think in terms of
creating a derived class of ssgLeaf.

> (12) How do we handle multiple windows in SSG?  I surmise that we would 
> have a separate scene-graph tree for each window.

Yes - I think so.  SSG works well with multiple windows - so that should
be OK.

> I daresay there will be many more issues as I continue to dig.

Keep 'em coming!

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----