RE: [Plib-devel] On First Looking Into Baker's SSG (with apologie s to John Keats)
Brought to you by:
sjbaker
Menu
▾
▴
RE: [Plib-devel] On First Looking Into Baker's SSG (with apologie s to John Keats)
|
From: Fay J. F C. AAC/W. <joh...@eg...> - 2004-09-13 14:11:17
|
Wolfram, Hello and welcome back and I certainly understand about the two jobs. And thank you for looking into my questions and comments. I might add that my questions and comments are exactly those--questions and comments. I am just giving SSG a first look, and I am not in a position to be ordering policy to anybody in this regard. My thought was to draw attention to things that don't look right. That said, in answer to your answers to my comments ... (4) No, I am not sure about changing the instructions on lines 42-43 of "ssgconf.h". But here is the section of code: <begin quote> /* For optional use of PNG textures, download the glpng library from http://www.wyatt100.freeserve.co.uk/download.htm and un-comment the following line. */ #undef SSG_LOAD_PNG_SUPPORTED <end quote> It strikes me that if you undefine a macro named "SSG_LOAD_PNG_SUPPORTED", it means that you are not supporting PNG. I also think that if the instruction says to un-comment a line, that line should be commented out in the standard code. So I suggest that we either change "#undef SSG_LOAD_PNG_SUPPORTED" to "#define SSG_LOAD_PNG_SUPPORTED" and actually comment it out, or else we change the instruction to tell the application programmer to "change the #undef to a #define" in order to support PNG. (6) I agree that having writers for all the file formats would be nice but is not at all necessary. And not having a writer certainly does not detract from the utility of a reader. (9) Let me see if I understand the issues. (I haven't gotten to "ssgKidList" yet.) In "ssgList", the function "removeAllEntities" calls "removeEntity" for each entry in the list. Apparently "ssgKidList" inherits from "ssgList" and does other things in its "removeEntity" besides what "ssgList" does. In this case, it would be necessary to call "ssgKidList::removeEntity" when removing all the entities from a "ssgKidList". As such, the "ssgList::removeAllEntities" may as well stay as it is (with the change you put in to remove from the top instead of the bottom). I'll get to your comments on parts two and three separately. John F. Fay joh...@eg... 850-729-6330 -----Original Message----- From: pli...@li... [mailto:pli...@li...] On Behalf Of Wolfram Kuss Sent: Monday, September 13, 2004 6:20 AM To: pli...@li... Subject: Re: [Plib-devel] On First Looking Into Baker's SSG (with apologies to John Keats) First 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? I think that would be a bug. For example ssgKidList uses the normal 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. ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php _______________________________________________ plib-devel mailing list pli...@li... https://lists.sourceforge.net/lists/listinfo/plib-devel |
