plib-devel Mailing List for PLIB (Page 42)
Brought to you by:
sjbaker
Menu
▾
▴
plib-devel
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
(80) |
Mar
(128) |
Apr
(111) |
May
(157) |
Jun
(70) |
Jul
(116) |
Aug
(465) |
Sep
(574) |
Oct
(325) |
Nov
(163) |
Dec
(182) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(167) |
Feb
(191) |
Mar
(319) |
Apr
(118) |
May
(252) |
Jun
(427) |
Jul
(187) |
Aug
(96) |
Sep
(219) |
Oct
(161) |
Nov
(109) |
Dec
(210) |
| 2002 |
Jan
(97) |
Feb
(80) |
Mar
(143) |
Apr
(234) |
May
(72) |
Jun
(246) |
Jul
(155) |
Aug
(280) |
Sep
(418) |
Oct
(81) |
Nov
(72) |
Dec
(88) |
| 2003 |
Jan
(59) |
Feb
(63) |
Mar
(33) |
Apr
(27) |
May
(87) |
Jun
(50) |
Jul
(97) |
Aug
(45) |
Sep
(35) |
Oct
(67) |
Nov
(78) |
Dec
(13) |
| 2004 |
Jan
(167) |
Feb
(144) |
Mar
(172) |
Apr
(93) |
May
(43) |
Jun
(7) |
Jul
(27) |
Aug
(36) |
Sep
(48) |
Oct
(54) |
Nov
(5) |
Dec
(44) |
| 2005 |
Jan
(53) |
Feb
(36) |
Mar
(13) |
Apr
(3) |
May
(19) |
Jun
|
Jul
(49) |
Aug
(39) |
Sep
(8) |
Oct
(8) |
Nov
(51) |
Dec
(23) |
| 2006 |
Jan
(26) |
Feb
(5) |
Mar
(26) |
Apr
(26) |
May
(52) |
Jun
(36) |
Jul
(8) |
Aug
(12) |
Sep
(6) |
Oct
(75) |
Nov
(34) |
Dec
(25) |
| 2007 |
Jan
(46) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(7) |
Jul
(2) |
Aug
|
Sep
(40) |
Oct
(9) |
Nov
(3) |
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
(26) |
Apr
|
May
|
Jun
(2) |
Jul
(4) |
Aug
(6) |
Sep
|
Oct
|
Nov
(5) |
Dec
(2) |
| 2009 |
Jan
(63) |
Feb
(4) |
Mar
(12) |
Apr
|
May
(5) |
Jun
(1) |
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
(14) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
(2) |
Feb
(1) |
Mar
(2) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(5) |
| 2012 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Fay J. F C. AAC/W. <joh...@eg...> - 2004-09-24 13:12:25
|
Thanks, but it doesn't really float my boat. I would prefer something a little more artistic and less cartoonish. But thank you for your offer. John F. Fay joh...@eg... 850-729-6330 -----Original Message----- From: pli...@li... [mailto:pli...@li...] On Behalf Of Bram Stolk Sent: Friday, September 24, 2004 6:34 AM To: pli...@li... Subject: [Plib-devel] plib logo Hello, The 2002 plib logo competition was a big fiasco: http://sourceforge.net/mailarchive/forum.php?thread_id=904174&forum_id=4480 However, why not try again? My entry is at: http://stolk.org/plib.png Bram ------------------------------------------------------- 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. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ plib-devel mailing list pli...@li... https://lists.sourceforge.net/lists/listinfo/plib-devel |
|
From: Bram S. <br...@sa...> - 2004-09-24 11:32:16
|
Hello, The 2002 plib logo competition was a big fiasco: http://sourceforge.net/mailarchive/forum.php?thread_id=904174&forum_id=4480 However, why not try again? My entry is at: http://stolk.org/plib.png Bram |
|
From: Fay J. F C. AAC/W. <joh...@eg...> - 2004-09-23 18:14:03
|
Thank you. There are a total of 139 files containing tab characters in the "plib/src" directory. At some point when I am brain-dead and am capable of nothing more, I shall go through and remove the tabs from them. Do we have a style guide giving the number of spaces to indent code inside a curly-brace? I see two spaces in some places (this is my preference) and four spaces in other places. John F. Fay joh...@eg... 850-729-6330 -----Original Message----- From: pli...@li... [mailto:pli...@li...] On Behalf Of Wolfram Kuss Sent: Wednesday, September 22, 2004 5:46 PM To: pli...@li... Subject: Re: [Plib-devel] Tabs vs. Blanks > I just copied your "ssgLoadPCX.cxx" file and find a bunch of tab >characters in it. Just FYI. Fixed in CVS. I have set my editor to prefer spaces now, so I will at least not add new tabs in future. > >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. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ plib-devel mailing list pli...@li... https://lists.sourceforge.net/lists/listinfo/plib-devel |
|
From: Bram S. <br...@sa...> - 2004-09-23 17:33:59
|
Hello plibbers,
I implemented ssgSaveIV()
The results are quite satisfactory.
I tested it on tuxedo.ac and dog.ac, and the output
looks fine in ivview.
The code is already quite robust, and it correctly
handles:
- scene hierarchy
- transformations
- states
- texture coords
- textures
- normals
not yet implemented: lights, lines, points, shademodel, camera.
Additionally, the code is quite clean, and introduces no
new dependencies, as I managed to stay away from stl and
libinventor. It's a single .cxx file, and some entries
in ssg.cxx, sgg.dsp, Makefile.am, ssg.h
I prefer to be granted cvs write access, so I can commit my
changes. If cvs-write access for me is deemed undesirable, I
could mail someone the output of a cvs diff run on my tree,
otherwise, my sourceforge id is bram
regards,
Bram
|
|
From: Wolfram K. <w_...@rz...> - 2004-09-22 22:45:17
|
> I just copied your "ssgLoadPCX.cxx" file and find a bunch of tab >characters in it. Just FYI. =46ixed in CVS. I have set my editor to prefer spaces now, so I will at least not add new tabs in future. > >John F. Fay >joh...@eg... >850-729-6330=20 Bye bye, Wolfram. |
|
From: LAVIGNE,ERIC <la...@uf...> - 2004-09-22 18:49:05
|
Welcome back John. My computer is set up again, so send those files to me. Eric Lavigne. On Wed Sep 22 11:40:21 EDT 2004, Fay John F Contr AAC/WMG <joh...@eg...> wrote: > Gentlemen, > > In going over the last week and a half of changes to PLIB I > notice > that a bug fix of mine to "puAux" didn't make it in. There are > two specific > things: > > - The "puaComboBox" has its own "resize" function to adjust > the positions and sizes of its subwidgets > - The "puaChooser" destructor is virtual > > I'm not sure whether the second one is absolutely necessary but > it's there > in my personal copy. If someone can put the changes into CVS for > me I will > send him a zip file with them. > > John F. Fay > joh...@eg... > 850-729-6330 |
|
From: Fay J. F C. AAC/W. <joh...@eg...> - 2004-09-22 17:39:31
|
Wolfram, I just copied your "ssgLoadPCX.cxx" file and find a bunch of tab characters in it. Just FYI. John F. Fay joh...@eg... 850-729-6330 |
|
From: Fay J. F C. AAC/W. <joh...@eg...> - 2004-09-22 16:06:13
|
Gentlemen, In going over the last week and a half of changes to PLIB I notice that a bug fix of mine to "puAux" didn't make it in. There are two specific things: - The "puaComboBox" has its own "resize" function to adjust the positions and sizes of its subwidgets - The "puaChooser" destructor is virtual I'm not sure whether the second one is absolutely necessary but it's there in my personal copy. If someone can put the changes into CVS for me I will send him a zip file with them. John F. Fay joh...@eg... 850-729-6330 |
|
From: Fay J. F C. AAC/W. <joh...@eg...> - 2004-09-22 14:53:58
|
Wolfram, Whoops, my mistake. I had thought that "plane" (the result of the call to "sgMakePlane") was used only inside the "_ssgIsHotTest" if-block, but it isn't. Ignore the suggestion. John F. Fay joh...@eg... 850-729-6330 -----Original Message----- From: pli...@li... [mailto:pli...@li...] On Behalf Of Wolfram Kuss Sent: Tuesday, September 14, 2004 7:54 AM To: pli...@li... Subject: Re: [Plib-devel] A Second Look Into SSG <snip> >I also propose checking the "_ssgIsHotTest" variable (see line 674) earlier. And doing what depending on the result? It seems the work done depending on _ssgIsHotTest needs also the result of sgMakePlane, does it not? The rest of your new order should indeed improve speed. 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 |
|
From: Steve B. <sjb...@ai...> - 2004-09-22 13:24:52
|
Fay John F Contr AAC/WMG wrote: > Gentlemen, > > After about a week away from work, I am now back on-line and > working. At the moment I'm digging through 100 e-mails that piled up > (only that few! I am amazed). Maybe all the spammers live in Pensacola! ---------------------------- 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: Fay J. F C. AAC/W. <joh...@eg...> - 2004-09-22 13:14:18
|
Gentlemen, After about a week away from work, I am now back on-line and working. At the moment I'm digging through 100 e-mails that piled up (only that few! I am amazed). <off-topic> Fort Walton Beach is beginning to return to some form of normalcy, although I did drive over one downed power line on my way in this morning. (I presume that it had been deactivated and simply had not been picked up yet.) West of here, though, is devastated. I was in Navarre on Monday handing out supplies and the place looks like ... well, like a hurricane hit it. I was aghast. Pictures can show you what it looks like, but they cannot at all convey the full sense of what has happened. I can only speculate about what it is like in Pensacola. </off-topic> John F. Fay joh...@eg... 850-729-6330 |
|
From: Steve B. <sjb...@ai...> - 2004-09-19 22:50:38
|
-------- Original Message -------- Subject: I'm OK Date: Sun, 19 Sep 2004 13:12:30 -0500 From: Fay Family <joh...@cy...> Reply-To: joh...@cy... <joh...@cy...> To: 'sjb...@ai...' <sjb...@ai...>, 'sf...@ol...' <sf...@ol...> Gentlemen, I can't get to the mailing lists directly but please forward to the PLIB, "freeglut," and OpenGLUT lists that my family and I are OK. Hurricane Ivan swept through here Wednesday night and Thursday morning but by the grace of God our house suffered no major damages. We have both electricity and telephone at home and we got the notice this morning that we don't have to boil the tap water any more. Work is closed "until further notice" and there's a good bit of relief work going on here so I won't be paying much attention to any open-source libraries for a few weeks. - John Fay -- ---------------------------- 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-14 12:53:07
|
> Since we can do the "inside the triangle" test with six multiplies, >I propose moving it earlier in the list of tests. =20 Makes sense. >I also propose checking the "_ssgIsHotTest" variable (see line 674) = earlier. =20 And doing what depending on the result? It seems the work done depending on _ssgIsHotTest needs also the result of sgMakePlane, does it not? The rest of your new order should indeed improve speed. Bye bye, Wolfram. |
|
From: Wolfram K. <w_...@rz...> - 2004-09-14 12:46:26
|
Hi! >(9) In the file "ssgBase.cxx" on line 41 in the function >"ssgBase::copy_from", there is a test: "if ( this =3D=3D src ) return = ;" with a >comment "Avoid corrupting userdata when copying to self." In the file >"ssgSimpleList.cxx" starting on line 27 we find another "copy_from" = function >which (among other things) deletes a variable "list" and allocates a new >one. Do we want the code to do this even if "this =3D=3D src" or do we = want to >return without doing anything in this case? I see. Adding a=20 if ( this =3D=3D src ) return; does sound good. >(15) In "ssgVtxTable.cxx" on line 704ff, we are in the function >"hot_triangles". [....] Sounds good to me. However, I can not say how robust it is to numerical accuracy. I suggest to only change this if someone from a programm that uses it extensively - say FlightGear - will test the change. BTW, I suggest in a case like this to add the derivation to the code as a comment or at least, with a comment, list to the email with the derivation. Bye bye, Wolfram. |
|
From: Wolfram K. <w_...@rz...> - 2004-09-14 12:22:34
|
Hi > 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. =20 I think this is a good idea, since you do the work to look at ssg anyway, so pointing out those things to someone with write access (or someone to double check your ideas) makes sense. And I agree that trivial things should be fixed as well, if they are trivial to fix. >(4) No, I am not sure about changing the instructions on lines 42-43 of >"ssgconf.h". =20 =46ixed. Somehow, yesterday I was obviously able to confuse myself over this issue completely. Thanks for the clarification. >(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). Yes, correct. >John F. Fay >joh...@eg... Bye bye, Wolfram. |
|
From: Fay J. F C. AAC/W. <joh...@eg...> - 2004-09-13 15:03:55
|
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 |
|
From: Fay J. F C. AAC/W. <joh...@eg...> - 2004-09-13 14:54:52
|
Gentlemen, I'd like to add another comment about "ssgVtxTable.cxx" in the function "hot_triangles". This, I think, is important enough to stand on its own and not get put at the tail end of another e-mail. Since we can do the "inside the triangle" test with six multiplies, I propose moving it earlier in the list of tests. I also propose checking the "_ssgIsHotTest" variable (see line 674) earlier. The "sgMakePlane" function is rather slow (involving several multiplies and a square root) and should be moved down. I propose the following ordering: (a) Check whether the "_ssgIsHotTest" variable is enabled. This is a boolean test. (Presently on line 674) (b) Check whether the point's x- and y-coordinates are within the triangle's bounding box and whether the point's z-coordinate is below the triangle entirely. This is presently the first test and involves 15 comparisons and 14 boolean operations. (Presently on lines 665-669) (c) Check whether the point's x-and y-coordinates are within the triangle. This is the six-multiply test that I just put into a previous e-mail. (Presently on lines 7094-716) (d) Create the plane of the triangle by calling "sgMakePlane". (Presently on line 672) (e) Test whether the plane is vertical or upside-down. (Presently on line 678) (f) Find the height of the point on the plane of the triangle beneath the specified point and make sure it is less than the height of the specified point itself. (Presently on lines 684 and 688) With the calculation in (c) having already been done, there is no need to perform the test on lines 693-694 as to whether the z-coordinate in the plane of the triangle is outside the triangle's bounding box. Thoughts, anyone? 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:53 AM To: pli...@li... Subject: Re: [Plib-devel] A Second Look Into SSG <snip> >(15) In "ssgVtxTable.cxx" on line 704ff, I can do this test with six >multiplies. Is there enough of a demand for it that somebody is willing to >put it into CVS for me? I would guess the FGFS people would appreciate it! >I have some more comments to "ssgVtxTable.cxx" and the geometry functions, >specifically in terms of making them more efficient; does anybody want to >hear them? Certainly, I can not promise any time though. Thank you for your work! 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 |
|
From: Fay J. F C. AAC/W. <joh...@eg...> - 2004-09-13 14:40:52
|
Wolfram,
Here are my answers to your answers to my comments, part two. I
notice that CVS hasn't gotten your changes (from two hours ago, I'm not
complaining) yet, so I'm not looking at them (obviously).
(6) The author of the "spherebotch" code in "ssgEntity.cxx" on lines 80ff is
Steve Baker, in version 1.1 of the file. Steve, what do you want the code
to do here? My guess is that the spheres are supposed to shimmer as the
numbers of polygons changes back and forth. But this is only a guess.
(9) In the file "ssgBase.cxx" on line 41 in the function
"ssgBase::copy_from", there is a test: "if ( this == src ) return ;" with a
comment "Avoid corrupting userdata when copying to self." In the file
"ssgSimpleList.cxx" starting on line 27 we find another "copy_from" function
which (among other things) deletes a variable "list" and allocates a new
one. Do we want the code to do this even if "this == src" or do we want to
return without doing anything in this case?
(15) In "ssgVtxTable.cxx" on line 704ff, we are in the function
"hot_triangles". The problem at hand is to determine whether the x- and
y-coordinates of a specified point "P" are within the two-dimensional
triangle given by three other pairs of x- and y-coordinates. Let me call
the coordinates of the specified point (x,y) and the coordinates of the
three corners of the triangle (x1,y1), (x2,y2), and (x3,y3). The three
corners themselves I will call "P1", "P2", and "P3". The derivation begins
by expressing the coordinates of the point as parametric coordinates in
terms of the three corners:
P = P1 + A ( P2 - P1 ) + B ( P3 - P1 )
where A and B are my parametric coordinates. In terms of the coordinates, I
can express this as a matrix operation (you will need a constant-spaced font
to view this properly)
[ x-x1 ] = [ (x2-x1) (x3-x1) ] [ A ]
[ y-y1 ] = [ (y2-y1) (y3-y1) ] [ B ]
The determinant of the matrix is given by
D = ( x2 - x1 ) ( y3 - y1 ) - ( x3 - x1 ) ( y2 - y1 )
Calculating the determinant takes two multiplies.
Inverting the matrix gives
[ A ] = [ (y3-y1) -(x3-x1) ] [ x-x1 ]
[ B ] = [ -(y2-y1) (x2-x1) ] [ y-y1 ] / D
To save operations and to avoid the possibility of dividing by zero, we
multiply both sides of the equation by the determinant:
[ D A ] = [ (y3-y1) -(x3-x1) ] [ x-x1 ]
[ D B ] = [ -(y2-y1) (x2-x1) ] [ y-y1 ]
Multiplying this out takes four more multiplications and gives us the
products "DA" and "DB" as a result. The point is in the triangle if A >= 0,
B >= 0, and (A+B) <= 1. Since we don't want to divide by D, we have the
following (admittedly complicated) test:
if ( D >= 0.0 )
{
if ( ( DA < 0.0 ) || ( DB < 0.0 ) || ( DA + DB > D ) )
continue ; /* Outside the triangle */
}
else /* Negative determinant, change the direction of the inequalities */
{
if ( ( DA > 0.0 ) || ( DB > 0.0 ) || ( DA + DB < D ) )
continue ; /* Outside the triangle */
}
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:53 AM
To: pli...@li...
Subject: Re: [Plib-devel] A Second Look Into SSG
>Trivial:
>
>(1) More tabs that should be blank spaces in ssgSimpleState.cxx:545;
>ssgStateSelector.cxx:44-46, 83; ssgVtxTable.cxx:31-56, 66-126, 319-322,
>363-383, 418, 447-452, 796-798, 810-819
I untabified ssgStateSelector.cxx. I have local changes in the other
files, so it would be too much hassle to get the "Clean version",
untabify and commit.
>(2) In "ssgEntity.cxx" on lines 117 and 131, the words "gimbles,"
>"seperate," and "seperated" should be "gimbals," "separate," and
>"separated."
Fixed
>(3) In "ssgLeaf.cxx" we may want to check the indentation of lines 36, 51,
>and 53 (two spaces instead of the usual four).
Hopefully fixed, please check it.
>(4) In "ssgVtxTable.cxx" on lines 46-47 the same test is repeated.
Fixed.
>(5) In "ssgVtxTable.cxx" on line 314, should we account for the GL_POINTS,
>GL_LINES, GL_LINE_LOOP, and GL_LINE_STRIP cases inside the "switch"
>statement?
Well, if you find that more elegant, ok. Changed.
>Less Trivial:
>
>(6) In "ssgEntity.cxx" on lines 80ff, the local variable "spherebotch" is
>set to a pseudorandom (but repeatable) value from zero to nine and
>incremented through a "switch" statement. This is strange; each entity
will
>get its own value from zero to nine, but the same entity will always get
the
>same value. Further, "spherebotch" is incremented on line 82 and reset to
>zero on line 92. It will be reinitialized each time through the function.
>It should be added to the private variables of the "ssgEntity" class.
That sounds good and the current implementation is obviously not what
the author wanted. Still, before a change we might want to hear what
the author wanted to achieve.
>(7) In "ssgEntity.cxx" on line 432, we set the variable
"bsphere_is_invalid"
>to true. Do we want to call "dirtyBSphere" instead, so that we set the
>parent entities' b-spheres dirty as well?
Yes. Fixed.
>(8) In "ssgList.cxx" on line 102 I think there is a bug. The "if ( next >=
>n )" should be "if ( next > n )". In the extreme case, if both "next" and
>"n" are zero, we will wind up pointing to "next" equal to -1. In general,
>if "next" is equal to "n", we wind up pointing at the element we just
>processed.
Sounds good to me. I have not changed it yet though.
>(9) In "ssgSimpleList.cxx" on line 29, do we want to test for "if ( this ==
>src ) return ;"? The test is in "ssgBase.cxx" on line 41, also in the
>"copy_from" function.
Could you check filename/line number please?
>(15) In "ssgVtxTable.cxx" on line 704ff, I can do this test with six
>multiplies. Is there enough of a demand for it that somebody is willing to
>put it into CVS for me?
I would guess the FGFS people would appreciate it!
>I have some more comments to "ssgVtxTable.cxx" and the geometry functions,
>specifically in terms of making them more efficient; does anybody want to
>hear them?
Certainly, I can not promise any time though.
Thank you for your work!
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
|
|
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 |
|
From: Wolfram K. <w_...@rz...> - 2004-09-13 12:23:46
|
When a model contains selectors, the ASE and ASC writers now write out all children. This is ther behaviour that other loaders had beforehand already. I reworked my loader of PCX textures. I would appreciate it if someone tests the loader. Bye bye, Wolfram. |
|
From: Wolfram K. <w_...@rz...> - 2004-09-13 12:07:36
|
> Part three. > >Serious Business: >(1) In "ssgVtxArray.cxx" on line 207 an array of "long" is allocated and= its >address stored in a local variable. I do not see where it is ever = deleted >or its address stored somewhere permanent. This is a memory leak. =46ixed. > >Trivial: >(2) More tabs that should be blank spaces in "ssg.h" on lines 643, = 676-679, >689, 704, 713, 727 (maybe), 1021, 1422, 1432-1439, 1485, 1577, and 1593;= in >"ssgVtxArray.cxx" on line 76 (after the "indices"?) =46ixed the ssgVtxArray one. >(7) In the file "ssgTween.cxx" on lines 150, 184, 192, 200, and 208, the >variable "bsphere_is_invalid" is set to true immediately after a call to >"dirtyBSphere". The call includes that assignment and so the repeated >assignment is not necessary. =46ixed. >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. =20 Yes. Let's just leave it like that :-). >John F. Fay >joh...@eg... >850-729-6330=20 Bye bye, Wolfram. |
|
From: Wolfram K. <w_...@rz...> - 2004-09-13 11:52:29
|
>Trivial: > >(1) More tabs that should be blank spaces in ssgSimpleState.cxx:545; >ssgStateSelector.cxx:44-46, 83; ssgVtxTable.cxx:31-56, 66-126, 319-322, >363-383, 418, 447-452, 796-798, 810-819 I untabified ssgStateSelector.cxx. I have local changes in the other files, so it would be too much hassle to get the "Clean version", untabify and commit.=20 >(2) In "ssgEntity.cxx" on lines 117 and 131, the words "gimbles," >"seperate," and "seperated" should be "gimbals," "separate," and >"separated." =46ixed >(3) In "ssgLeaf.cxx" we may want to check the indentation of lines 36, = 51, >and 53 (two spaces instead of the usual four). Hopefully fixed, please check it. >(4) In "ssgVtxTable.cxx" on lines 46-47 the same test is repeated. =46ixed. >(5) In "ssgVtxTable.cxx" on line 314, should we account for the = GL_POINTS, >GL_LINES, GL_LINE_LOOP, and GL_LINE_STRIP cases inside the "switch" >statement? Well, if you find that more elegant, ok. Changed. >Less Trivial: > >(6) In "ssgEntity.cxx" on lines 80ff, the local variable "spherebotch" = is >set to a pseudorandom (but repeatable) value from zero to nine and >incremented through a "switch" statement. This is strange; each entity = will >get its own value from zero to nine, but the same entity will always get= the >same value. Further, "spherebotch" is incremented on line 82 and reset = to >zero on line 92. It will be reinitialized each time through the = function. >It should be added to the private variables of the "ssgEntity" class. That sounds good and the current implementation is obviously not what the author wanted. Still, before a change we might want to hear what the author wanted to achieve. >(7) In "ssgEntity.cxx" on line 432, we set the variable = "bsphere_is_invalid" >to true. Do we want to call "dirtyBSphere" instead, so that we set the >parent entities' b-spheres dirty as well? Yes. Fixed. >(8) In "ssgList.cxx" on line 102 I think there is a bug. The "if ( next= >=3D >n )" should be "if ( next > n )". In the extreme case, if both "next" = and >"n" are zero, we will wind up pointing to "next" equal to -1. In = general, >if "next" is equal to "n", we wind up pointing at the element we just >processed. Sounds good to me. I have not changed it yet though. >(9) In "ssgSimpleList.cxx" on line 29, do we want to test for "if ( this= =3D=3D >src ) return ;"? The test is in "ssgBase.cxx" on line 41, also in the >"copy_from" function. Could you check filename/line number please? >(15) In "ssgVtxTable.cxx" on line 704ff, I can do this test with six >multiplies. Is there enough of a demand for it that somebody is willing= to >put it into CVS for me? I would guess the FGFS people would appreciate it! >I have some more comments to "ssgVtxTable.cxx" and the geometry = functions, >specifically in terms of making them more efficient; does anybody want = to >hear them? Certainly, I can not promise any time though. Thank you for your work! Bye bye, Wolfram. |
|
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.
|
|
From: Fay J. F C. AAC/W. <joh...@eg...> - 2004-09-11 03:07:03
|
Gentlemen, Part three. Serious Business: (1) In "ssgVtxArray.cxx" on line 207 an array of "long" is allocated and its address stored in a local variable. I do not see where it is ever deleted or its address stored somewhere permanent. This is a memory leak. Trivial: (2) More tabs that should be blank spaces in "ssg.h" on lines 643, 676-679, 689, 704, 713, 727 (maybe), 1021, 1422, 1432-1439, 1485, 1577, and 1593; in "ssgVtxArray.cxx" on line 76 (after the "indices"?) (3) In "ssg.h", in the definition of "ssg<fill-in>Array", there are a lot of functions that are defined (with the curly braces, I mean, not just declared) and are then followed by semicolons. The semicolons are not hurting anything, but they are extraneous. You may find them on lines 487, 488. 490. 492, 509, 510, 512, 514, 531, 532, 534, 536, 553, 554, 556, 558, 576, 577, and 594. (4) Why is the "type" assignment commented out on lines 607 and 629 of "ssg.h"? (5) Lines 684-689 of "ssg.h" appear to be indented improperly. (6) In the file "ssgTween.cxx", the construction "banked_vertices -> getNumEntities ()" is used on lines 128, 168, 246, and 450. On line 221 the function "getNumBanks ()" is used; I consider the latter to be clearer for the purpose and a little investigation shows it to be identical to the former. I suggest that the former be changed to the latter. (7) In the file "ssgTween.cxx" on lines 150, 184, 192, 200, and 208, the variable "bsphere_is_invalid" is set to true immediately after a call to "dirtyBSphere". The call includes that assignment and so the repeated assignment is not necessary. (8) In the file "ssgVtxArray.cxx" on lines 354, 370, and 392 we have "assert(false)" statements to kill execution. May I suggest a call to "ulError ( UL_FATAL, <error_message> )" instead? Not so trivial: (9) Do we want to define a template class for the "ssg<fill-in>Array" classes? (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? (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. Why not just declare the array to be of type short in the first place? John F. Fay joh...@eg... 850-729-6330 |
|
From: Steve B. <sjb...@ai...> - 2004-09-10 23:33:19
|
Fay John F Contr AAC/WMG wrote: > I read on the "www.opengl.org" web site today that OpenGL 2.0 > was released last Tuesday. I've not been following this. Does it have > any relevance to us? Or do we need to wait until somebody releases an > implementation of it? Or has that already been done? Well, it's certainly been expected for a long time. The main significance is that the specificiation of the OpenGL shader language (GLSL) is now firm. I believe that the latest drivers from nVidia and ATI both support GLSL under Linux. Getting good shader support into (at least) SSG is starting to be very important. We should spend some time discussing how to do that. ---------------------------- 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----- |
34 messages has been excluded from this view by a project administrator.
