Thread: [Plib-devel] On First Looking Into Baker's SSG (with apologies to John Keats)
Brought to you by:
sjbaker
From: Fay J. F C. AAC/W. <joh...@eg...> - 2004-08-09 19:59:46
|
MUCH have I travell'd in the realms of gold, And many goodly states and kingdoms seen; Round many western islands have I been Which bards in fealty to Apollo hold. Oft of one wide expanse had I been told That deep-brow'd Homer ruled as his demesne; Yet did I never breathe its pure serene Till I heard Chapman speak out loud and bold: Then felt I like some watcher of the skies When a new planet swims into his ken; Or like stout Cortez when with eagle eyes He star'd at the Pacific-and all his men Look'd at each other with a wild surmise- Silent, upon a peak in Darien. -------------------------------------------------- Frankly, I feel that anything I try to write after quoting the above is an anticlimax. But here goes. I printed out the SSG files (except for all the loaders and writers) and started digging through them over the weekend. I have a few notes and questions so far, some trivial and some not trivial. In the realm of the trivial: (1) There are several places where tabs are used for indentation instead of spaces. (ssg.cxx:404,405; ssg.h:357-358, 450) (2) The variable "sgebug" (ssg.h:43) seems not to be used anywhere. (3) In "ssgconf.h" on line 35, the word "and" should be "an" ("to an #undef"). (4) Also in "ssgconf.h" on lines 42-43, I think the instruction to "un-comment the following line" should be changed to something like "change the 'undef' on the following like to a 'define'." (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. In the realm of the not-so-trivial: (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? (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. Do we want to initialize the variable to 0 (on line 27) and increment it (on line 68) with a prefix "++"? (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. (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". (10) Do we want to implement PUI-type RTTI in the SSG functions? 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? (12) How do we handle multiple windows in SSG? I surmise that we would have a separate scene-graph tree for each window. I believe Steve would have done something like that for PUI except that I put in the multiple-window support first and didn't ask him. This time I am asking first. I daresay there will be many more issues as I continue to dig. John F. Fay joh...@eg... |
From: Bert D. <dri...@pl...> - 2004-08-10 00:21:00
|
On Mon, 9 Aug 2004, Fay John F Contr AAC/WMG wrote: > (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. Do we want to initialize the variable to > 0 (on line 27) and increment it (on line 68) with a prefix "++"? I always learned that trying to save a single CPU tick is incompatible with writing in C++ :-) For what it's worth, any compiler worth its salt will know if the original value will eventually be discarded and not bother so save it in that case. I'd be tremendously surprised if either MSVC for i386 or GCC for i386 got this wrong. I have actually seen code breaking over such optimizations. A far better argument for making the change is to establish a common idiom for a project. Cheers, -- Bert -- Bert Driehuis -- dri...@pl... -- +31-20-3116119 If the only tool you've got is an axe, every problem looks like fun! |
From: Steve B. <sjb...@ai...> - 2004-08-10 00:22:58
|
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----- |
From: Wolfram K. <w_...@rz...> - 2004-09-13 11:18:42
|
=46irst of all, a big "excuse me" for my absence from this list and my slack in helping! Sorry! I am super busy right now with two jobs :-/. >In the realm of the trivial: >(3) In "ssgconf.h" on line 35, the word "and" should be "an" ("to an >#undef"). Done. >(4) Also in "ssgconf.h" on lines 42-43, I think the instruction to >"un-comment the following line" should be changed to something like = "change >the 'undef' on the following like to a 'define'." Are you sure? >In the realm of the not-so-trivial: >(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? It would of course be nice to have leaders and writers for all formats, but it is not realistic. Also, not having a writer for a format does not make the loader any less useful and for example the asc loader was worth it's weight in gold as it is and actually is a small part of why I got my second job. >(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? =20 I think that would be a bug. For example ssgKidList uses the normal=20 removeAllEntities but a specific removeEntity. If this would no longer be called, things would break. >At the >very least, we can speed up the "memmove" calls by invoking = "removeEntity" >with an argument of "total-1" instead of "0". I agree on this and have implemented the change. >John F. Fay >joh...@eg... Bye bye, Wolfram. |