RE: [Plib-devel] A Third Look Into SSG

[Fay J. F C. AAC/W. <joh...@eg...>]

Notes on part three:

(10) As Will Rogers (an American humorist from early in the 20th century),
all I know is what I read in the papers.  Line 736 of "ssg.h" says that the
function "ssgTexture::setHandle ()"--presumably the function "setHandle (
GLuint handle )" defined on line 740--is deprecated because it leaks texture
handles.  I propose putting a date of deprecation in the comment so that two
years after the date (more or less) we can remove the function.  To be
perfectly honest, I know nothing of texture handles or how an "ssgTexture"
object should set its handle (if it should at all).

I do find that the function "setTexture" on line 923 of the same file is
also deprecated--apparently also because it leaks texture handles.  I
propose that it also get a date of deprecation.  There is another
"setTexture" function a few lines earlier, which presumably would be used
instead.  PPE should probably be changed posthaste.

(11) With the question of an array of pointers to longs being "static_cast"
to shorts, I surmise that there is a history here of which I know nothing.
At some point when there's time I would probably be interested in hearing
the history, but in the meantime I will defer to your statement that we
should just leave it as it is.

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 7:08 AM
To: pli...@li...
Subject: Re: [Plib-devel] A Third Look Into SSG

>	Part three.
>
<snip>

>Not so trivial:
>(10) On line 736 of "ssg.h" we see that a "setHandle()" function is
>deprecated.  Should we remove it, or at least give a date of deprecation so
>that people will know how quickly they should move away from it?

It seems to me we have to remove setTexture as well then?
PPE uses this.

>(11) In the file "ssgVtxArray.h", on line 207 (site of the memory leak
>mentioned earlier), the variable "oldIndex2NewIndex" is defined to be a
>pointer to an array of longs.  Then on line 228 the value is "static_cast"
>to short.  

Yes. Let's just leave it like that :-).


>John F. Fay
>joh...@eg...
>850-729-6330 

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