plib-devel

RE: [Plib-devel] Another New Demo Program for PW

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

Steve,

	I have a couple of notes on your changes.  The first is that the
"%lf" is good for the "printf" statements but we need to be careful with the
"sscanf" statements.  I've put in a "float_value" variable which actually
gets read from the strings.

	The second is a PW issue which I think I raised earlier.  The fifth
argument of "pwInit" is "int multisample" which in the "pw_demo" program is
set to "false".  I think an "int" should be "TRUE" and "FALSE" rather than
the strict boolean values of "true" and "false".  I propose that we either
change the "pwInit" function to take a "bool" or else we change "pw.h" to
include definitions of "TRUE" and "FALSE" and change the sample programs to
pass those.  My personal preference is for the latter.

John F. Fay
joh...@eg...



-----Original Message-----
From: pli...@li...
[mailto:pli...@li...]On Behalf Of Steve Baker
Sent: Sunday, April 25, 2004 4:24 PM
To: pli...@li...
Subject: Re: [Plib-devel] Another New Demo Program for PW


Fay John F Contr AAC/WMG wrote:
> Since I can never leave well enough alone ... here's a Lorenz strange
> attractor demo program.

I eventually managed to compile this under Linux - there were a few
problems:

1) '%lf' is not allowed in printf's - the 'l' modifier can only be applied
    to integers - not doubles.  Just a plain '%f' is sufficient.

2) FALSE is undeclared in line 332.

3) The variable pargc isn't used.

---------------------------- 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-----


-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] Another New Demo Program for PW

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

Fay John F Contr AAC/WMG wrote:
> Since I can never leave well enough alone ... here's a Lorenz strange
> attractor demo program.

I eventually managed to compile this under Linux - there were a few problems:

1) '%lf' is not allowed in printf's - the 'l' modifier can only be applied
    to integers - not doubles.  Just a plain '%f' is sufficient.

2) FALSE is undeclared in line 332.

3) The variable pargc isn't used.

---------------------------- 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-----

Re: [Plib-devel] Another New Demo Program for PW

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

Fay John F Contr AAC/WMG wrote:
> Since I can never leave well enough alone ... here's a Lorenz strange
> attractor demo program.

Cool!

> It originally had some text in it but since PW doesn't support fonts I
> commented the line out.

That's what the 'FNT/PUI' libraries are for.  It would be redundant to have
fonts in PW as well.  PW is designed to operate as a part of PLIB - not as
a GLUT replacement!

> Do I figure correctly that PW does not support single buffering?

Yes.  PLIB is really only intended to support interactive applications
and those are invariably double-buffered on modern hardware.

---------------------------- 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-----

Re: [Plib-devel] New Demo Program for PW

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

Fay John F Contr AAC/WMG wrote:

> I wrote both of them,
> and so naturally there will be stylistic similarities, but I don't think
> there will be any problems with licensing.

No - if you wrote them, you own the copyright - so you can choose to relicense
new versions them in any way you like.

 > (The "freeglut" library operates
> under the XFree86 license while PLIB is LGPL'ed.  I don't know what the
> prevailing license is for the PLIB demos; I'm sure it is not GPL.)

How sure?  :-)

Those under the directory called 'examples' are all GPL'ed because it was
too much of a hassle to put a 'COPYING' file in every directory.

Those under the 'demos' directory are large/complex enough to warrant
having their own build mechanism and COPYING file - so I guess those
could be differently licensed if you really insisted.

> 	Are we interested in such a demo?

Yes!  Definitely.

---------------------------- 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-----

[Plib-devel] New Demo Program for PW

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

Gentlemen,

	I recently wrote a short demonstration program for PW called
"fractals".  Those of you who are familiar with "freeglut" may notice some
similarities between this and the "freeglut" demo program of the same name,
but I assure you that they are different programs.  I wrote both of them,
and so naturally there will be stylistic similarities, but I don't think
there will be any problems with licensing.  (The "freeglut" library operates
under the XFree86 license while PLIB is LGPL'ed.  I don't know what the
prevailing license is for the PLIB demos; I'm sure it is not GPL.)

	Are we interested in such a demo?

John F. Fay
joh...@eg...

[Plib-devel] PW example question

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

Gentlemen,

	The fifth and seventh arguments of the function "pwInit" are of type
int (see "pw.h" lines 40-42) while the parameters supplied in the sample
program "pw_demo.cxx" (line 90) are "false" and "true", which are bool.
Should the latter be changed?

John F. Fay
joh...@eg...

Re: [Plib-devel] psl copy constructor.

[Jonathan W. <jtw...@in...>]

On Tue, 2004-04-20 at 21:29, Steve Baker wrote:
> We need to be careful around the bytecode stuff because it would be
> very easy to introduce something that would clobber performance.
> Reading the bytecode array happens at the innermost levels of the
> runtime interpreter - so tread VERY carefully!

OK, I've got a patch that implements ref counting for the pslCompiler
class and i've set it to delete the code array when it's destructor is
called - This does feel like a hack though, cleaning up an array created
by a seperate class.  Could the array creation be moved into the
pslCompiler constructor?

I've written a program that compiles a simple psl script, runs it, makes
a copy, deletes the first one and then repeats the process.  All three
scripts seem to run without a hitch, so I guess the patch does work. 
Once again I'd appreciate any feedback.

Jonathan.


Index: pslCompiler.h
===================================================================
RCS file: /cvsroot/plib/plib/src/psl/pslCompiler.h,v
retrieving revision 1.33
diff -u -r1.33 pslCompiler.h
--- pslCompiler.h	6 Jan 2003 05:10:13 -0000	1.33
+++ pslCompiler.h	20 Apr 2004 12:37:52 -0000
@@ -51,6 +51,8 @@
 
 class pslCompiler
 {
+  int ref_count; // reference count.  Clean up when this reaches zero 
+  
   /* File I/O and preprocessor */
 
   int  getChar               () ;
@@ -313,6 +315,7 @@
                 const pslExtension *_extn,
                 const char   *_progName )
   {
+    ref_count = 1;
     program  = prog ;
     progName = ulStrDup ( _progName ) ;
 
@@ -341,6 +344,21 @@
       delete [] symtab      [ i ] . symbol ; symtab      [ i ] . symbol
= NULL ;
       delete [] code_symtab [ i ] . symbol ; code_symtab [ i ] . symbol
= NULL ;
       delete [] forward_ref [ i ] . symbol ; forward_ref [ i ] . symbol
= NULL ;
+    }
+  }
+
+  void ref()
+  {
+    ref_count++;
+  }
+
+  void deref()
+  {
+    ref_count--;
+    if(ref_count < 1)
+    {
+      delete [] code;
+      delete this;
     }
   }
 
Index: pslProgram.cxx
===================================================================
RCS file: /cvsroot/plib/plib/src/psl/pslProgram.cxx,v
retrieving revision 1.17
diff -u -r1.17 pslProgram.cxx
--- pslProgram.cxx	6 Jan 2003 05:10:14 -0000	1.17
+++ pslProgram.cxx	20 Apr 2004 12:37:52 -0000
@@ -29,7 +29,7 @@
   if ( ! _pslInitialised )
     ulSetError ( UL_FATAL,
           "PSL: You didn't call pslInit() before using PSL functions."
) ;
-
+ 
   code = new pslOpcode [ MAX_CODE ] ;
 
   extensions = ext ;
@@ -64,17 +64,17 @@
   progName = NULL ;
 
   if ( _prgnm == NULL ) _prgnm = src -> getProgName () ;
-
+  
   setProgName ( _prgnm ) ;
 
   /* This will fail if this pslProgram is ever deleted */
   /* We need ref-counting on code/compiler */
-
+ 
   code       = src -> getCode       () ;
   compiler   = src -> getCompiler   () ;
   extensions = src -> getExtensions () ;
   userData   = src -> getUserData   () ;
-
+  compiler -> ref();
   context = new pslContext ( this ) ;
   context -> reset () ;
 }
@@ -86,9 +86,9 @@
   /* We need ref-counting on code/compiler */
   /* DEBUG-ME! */
   delete [] progName ;
-  delete    compiler ;
   delete    context  ;
-  delete [] code     ;
+  compiler -> deref();
+  
 }

Re: [Plib-devel] psl copy constructor.

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

Jonathan Wheare wrote:

> I thought about doing a reference count and could implement it for the
> pslCompiler class fairly easily, but there is also a static array of
> type pslOpcode containing the bytecode, I've thought about wrapping it
> in a class or making it a part of pslCompiler, but that would require
> changing all the references in the pslProgram class to be indirect.

We need to be careful around the bytecode stuff because it would be
very easy to introduce something that would clobber performance.
Reading the bytecode array happens at the innermost levels of the
runtime interpreter - so tread VERY carefully!

---------------------------- 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-----

RE: [Plib-devel] psl copy constructor.

[Jonathan W. <jtw...@in...>]

On Tue, 2004-04-20 at 00:34, Fay John F Contr AAC/WMG wrote:
> Jonathan,
> 
>         I put your changes into my copy of PSL and it compiles
> nicely.  The existing code around the changes mentions a need for
> reference counting and so it appears that what you have done is
> probably half the solution.  Half is better than none, though, and I
> thank you for your contribution.

> John F. Fay
> joh...@eg...

Thanks for the feedback.  
I thought about doing a reference count and could implement it for the
pslCompiler class fairly easily, but there is also a static array of
type pslOpcode containing the bytecode, I've thought about wrapping it
in a class or making it a part of pslCompiler, but that would require
changing all the references in the pslProgram class to be indirect.
I'm willing to have a go at it if no-one has a better idea though. 

Jonathan

RE: [Plib-devel] psl copy constructor.

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

Jonathan,

	I put your changes into my copy of PSL and it compiles nicely.  The
existing code around the changes mentions a need for reference counting and
so it appears that what you have done is probably half the solution.  Half
is better than none, though, and I thank you for your contribution.

	The combination of your "is_copy" and the mentions of reference
counting have gotten me thinking.  Would it improve matters to declare
"is_copy" to be a static integer (and probably rename it to something like
"number_of_objects"), increment it in every constructor, decrement it in the
destructor, and delete the compiler and code when its value is zero?  I know
nothing of PSL and really can't test this out at all.

John F. Fay
joh...@eg...



-----Original Message-----
From: pli...@li...
[mailto:pli...@li...]On Behalf Of Jonathan
Wheare
Sent: Sunday, April 18, 2004 6:26 AM
To: pli...@li...
Subject: [Plib-devel] psl copy constructor.


I've been tinkering with psl scripting and written myself a small
manager class that will automatically create script instances using the
copy constructor if there is already a compiled psl script in
existance.  this seems to work quite well until it is time to free the
script instances.  the first one works OK, but subsequent ones have
problems.  Looking through the code I found that there is no
differentiation between instances and the scripts theey are created from
when freeing the compiler and code structures.
I've written a little bit of code that changes the pslProgram destructor
so that it only frees the pslCode and pslCompiler objects on the master
copy of a script.  it will still cause problems if someone deletes the
master copy of a script and continues to use instances created from it,
but I can now create and delete ten instances of a script created using
the copy constructor without problems.
I have attatched a copy of my script at the end of this E-Mail.  I would
appreciate any feedback that people have.

Thanks,
Jonathan.

<snip>

[Plib-devel] psl copy constructor.

[Jonathan W. <jtw...@in...>]

I've been tinkering with psl scripting and written myself a small
manager class that will automatically create script instances using the
copy constructor if there is already a compiled psl script in
existance.  this seems to work quite well until it is time to free the
script instances.  the first one works OK, but subsequent ones have
problems.  Looking through the code I found that there is no
differentiation between instances and the scripts theey are created from
when freeing the compiler and code structures.
I've written a little bit of code that changes the pslProgram destructor
so that it only frees the pslCode and pslCompiler objects on the master
copy of a script.  it will still cause problems if someone deletes the
master copy of a script and continues to use instances created from it,
but I can now create and delete ten instances of a script created using
the copy constructor without problems.
I have attatched a copy of my script at the end of this E-Mail.  I would
appreciate any feedback that people have.

Thanks,
Jonathan.


Index: psl.h
===================================================================
RCS file: /cvsroot/plib/plib/src/psl/psl.h,v
retrieving revision 1.27
diff -u -r1.27 psl.h
--- psl.h	6 Apr 2004 12:53:15 -0000	1.27
+++ psl.h	18 Apr 2004 10:16:48 -0000
@@ -301,7 +301,7 @@
 
   int force_trace ;
   int force_stacktrace ;
-
+  int is_copy;
 public:
 
    pslProgram ( const pslExtension *ext, const char *_progName = NULL )
;
Index: pslProgram.cxx
===================================================================
RCS file: /cvsroot/plib/plib/src/psl/pslProgram.cxx,v
retrieving revision 1.17
diff -u -r1.17 pslProgram.cxx
--- pslProgram.cxx	6 Jan 2003 05:10:14 -0000	1.17
+++ pslProgram.cxx	18 Apr 2004 10:16:48 -0000
@@ -29,7 +29,7 @@
   if ( ! _pslInitialised )
     ulSetError ( UL_FATAL,
           "PSL: You didn't call pslInit() before using PSL functions."
) ;
-
+  is_copy = FALSE;
   code = new pslOpcode [ MAX_CODE ] ;
 
   extensions = ext ;
@@ -64,12 +64,12 @@
   progName = NULL ;
 
   if ( _prgnm == NULL ) _prgnm = src -> getProgName () ;
-
+  
   setProgName ( _prgnm ) ;
 
   /* This will fail if this pslProgram is ever deleted */
   /* We need ref-counting on code/compiler */
-
+  is_copy = TRUE;
   code       = src -> getCode       () ;
   compiler   = src -> getCompiler   () ;
   extensions = src -> getExtensions () ;
@@ -86,9 +86,13 @@
   /* We need ref-counting on code/compiler */
   /* DEBUG-ME! */
   delete [] progName ;
-  delete    compiler ;
   delete    context  ;
-  delete [] code     ;
+  if(!is_copy)
+  {
+    delete [] code   ;
+    delete  compiler ;
+  }
+  
 }
 

RE: [Plib-devel] Some "PW" notes

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

Frankly, I haven't the foggiest about the OpenGL installation.  I'll get
some local help here.

John F. Fay
joh...@eg...



-----Original Message-----
From: pli...@li...
[mailto:pli...@li...]On Behalf Of Steve Baker
Sent: Friday, April 16, 2004 4:50 PM
To: pli...@li...
Subject: Re: [Plib-devel] Some "PW" notes

<snip>

You should fix whatever is wrong with your computer.  You should find that
OpenGL is LOTS faster when you do.

 > I am getting
> frame rates of less than one per second but it's a slow computer.  Also,
how
> do I create a direct rendering context?

I'm hazy on the details of what you might have done wrong when you installed
OpenGL.   What card/drivers are you using?

---------------------------- 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-----


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] Some "PW" notes

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

Fay John F Contr AAC/WMG wrote:
> Gentlemen,
> 
> 	I have started going over the new "PW" code.  Frankly, I am amazed
> at the accomplishment; "freeglut" is almost 20,000 lines of code while PW is
> under 2,500 lines.  (Of course, the joystick support is missing; there
> aren't any fonts; backwards compatibility was not an issue; etc.

No menu's, only one window, no sphere's, cylinders, teapots, no overlay
planes, no support for single-buffered windows...

I really trimmed it to the bare bones.

> (1) The X11 and MacOSX versions of "pwSwapBuffers" and "pwCleanup" check
> whether PW has been initialized and prints an error message (and in the case
> of "pwSwapBuffers" under X11 exits) if it has not.  The Windows version does
> not.  Do we want it to?

Yes.  As with all PLIB libraries, the rule is that you call the 'init' function
before ANY other calls.  This should be (IMHO) a fatal error.

> Incidentally, the X11 version uses "fprintf" and "exit" while the MacOSX
> version uses "ulSetError".  I presume the latter is preferable.

Ooops!

> Also, do we want to exit if a PW application calls "pwSwapBuffers" without
> initializing?

Yes.  Who knows what some FUTURE implementation might need to have implemented
in the pwInit() call.   This isn't likely to be an error that happens to some
poor user after an hour of working with the program - it's something that'll be
evident to the application programmer on the very first time he tries to run
his newly written program.  At that point, exiting is an appropriate way to
draw his attention to a very serious error.

> (2) Some error messages in the X11 version need carriage returns at the end
> of the message.  They also use "fprintf" instead of "ulSetError".  The
> messages that I noticed are on lines 219, 229, 314, and 315 of "pwX11.cxx".

Sorry!  I'm on the case!

> (3) When starting up the Trireme simulation on Linux, I get the warning
> messages that "This is an INDIRECT rendering context" and "That may be bad
> for performance."  This may be more a question for the Triereis project, but
> I will ask it here anyway.  How bad for performance is it?

Pretty bad.  It implies that your OpenGL implementation isn't installed correctly -
or that you are trying to play on one computer whilst viewing the graphics in
a window on another computer.  The result will be VERY SLOW rendering.

In the early days of TuxAQFH/TuxKart, people would have this problem all the
time and would complain that their software was running very slowly - for no
adequately explained reason.   We'd know that they had a good 3D card - and
that OpenGL was obviously rendering - but we'd be unable to explain why it
was so slow.

You should fix whatever is wrong with your computer.  You should find that
OpenGL is LOTS faster when you do.

 > I am getting
> frame rates of less than one per second but it's a slow computer.  Also, how
> do I create a direct rendering context?

I'm hazy on the details of what you might have done wrong when you installed
OpenGL.   What card/drivers are you using?

---------------------------- 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-----

[Plib-devel] Some "PW" notes

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

Gentlemen,

	I have started going over the new "PW" code.  Frankly, I am amazed
at the accomplishment; "freeglut" is almost 20,000 lines of code while PW is
under 2,500 lines.  (Of course, the joystick support is missing; there
aren't any fonts; backwards compatibility was not an issue; etc.)  As with
all new software, there are some rough edges that may need some smoothing.
In an effort to apply some polishing, I have a few questions and
suggestions.

(1) The X11 and MacOSX versions of "pwSwapBuffers" and "pwCleanup" check
whether PW has been initialized and prints an error message (and in the case
of "pwSwapBuffers" under X11 exits) if it has not.  The Windows version does
not.  Do we want it to?

Incidentally, the X11 version uses "fprintf" and "exit" while the MacOSX
version uses "ulSetError".  I presume the latter is preferable.

Also, do we want to exit if a PW application calls "pwSwapBuffers" without
initializing?

(2) Some error messages in the X11 version need carriage returns at the end
of the message.  They also use "fprintf" instead of "ulSetError".  The
messages that I noticed are on lines 219, 229, 314, and 315 of "pwX11.cxx".

(3) When starting up the Trireme simulation on Linux, I get the warning
messages that "This is an INDIRECT rendering context" and "That may be bad
for performance."  This may be more a question for the Triereis project, but
I will ask it here anyway.  How bad for performance is it?  I am getting
frame rates of less than one per second but it's a slow computer.  Also, how
do I create a direct rendering context?

John F. Fay
joh...@eg...

RE: [Plib-devel] Re: pwMacOSX.cxx

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

I'd like to repeat that I took Olivier's files, made some slight
modifications, and have them in zipped form.  I can send them to anybody who
is interested.  I tried sending them to Olivier directly but the e-mail has
bounced.

John F. Fay
joh...@eg...



-----Original Message-----
From: pli...@li...
[mailto:pli...@li...]On Behalf Of Olivier A
Sent: Saturday, April 10, 2004 10:10 AM
To: pli...@li...
Subject: [Plib-devel] Re: pwMacOSX.cxx


>
>>   Oops, I am sorry. I modified my own version and forgot to add the
>> conditional compilation... (these conditional compilations are not in
>> the jsXXX.cxx files either...)
>
> Yes they are!

   Yes, but not in the modified files I provide at the following url:
     <http://perso.wanadoo.fr/oliver77-htm/plib/liste.htm>

   I added the conditional compilations in these files, and do some 
fixes according to the remarks of John Fay, and to the discussions 
about the jsBSD.cxx file, some weeks ago.

Olivier A.



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

[Plib-devel] Re: pwMacOSX.cxx

[Olivier A <oli...@wa...>]

>
>>   Oops, I am sorry. I modified my own version and forgot to add the
>> conditional compilation... (these conditional compilations are not in
>> the jsXXX.cxx files either...)
>
> Yes they are!

   Yes, but not in the modified files I provide at the following url:
     <http://perso.wanadoo.fr/oliver77-htm/plib/liste.htm>

   I added the conditional compilations in these files, and do some 
fixes according to the remarks of John Fay, and to the discussions 
about the jsBSD.cxx file, some weeks ago.

Olivier A.

Re: [Plib-devel] pwSetAutoRepeatKey...and pwMacOSX.

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

Fay John F Contr AAC/WMG wrote:
> Well, one obvious solution is just not to use the shift key for anything in
> the game.  It doesn't generate a callback call, anyway.  ("Doc, it hurts
> when I do *this*."  "So don't to that.")

People like it because "Keyboards are Evil" (see my FAQ:
http://www.sjbaker.org/steve/omniv/keyboards_are_evil.html) and whilst
other keys are 'iffy', they know that you can always press CTRL, ALT and
SHIFT in any combination without risk of the things I explain in my FAQ.

It's a continuing source of amazement to me that keyboards are such a
difficult input device...after all, electronic/digital keyboards have
been around LONG before the invention of the computer.  You'd really
hope we'd have got them right by now!

---------------------------- 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-----

RE: [Plib-devel] puDialogBox error

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

You're right; I'm operating from memory from over a year ago.  The change
went in on February 7, 2003; Norman Vine put it in for me, so don't hold him
responsible for it.  The associated comments are "Allow PUI to shut down
gracefully," so it definitely had something to do with deleting widgets all
over the place.

Either way, if you have something that is crashing now, please send me a
demo and I'll see if I can fix the problem.

John F. Fay
joh...@eg...



-----Original Message-----
From: pli...@li...
[mailto:pli...@li...]On Behalf Of Eero Pajarre
Sent: Friday, April 09, 2004 3:12 PM
To: pli...@li...
Subject: Re: [Plib-devel] puDialogBox error


Fay John F Contr AAC/WMG wrote:
> Unfortunately we need to keep the "puCleanUpJunk" in the "puInterface" 
> destructor in case the user is destroying the entire interface at once.  
> If there are widgets within widgets within widgets, we can't wait for 
> another iteration to destroy the sub-sub-widgets because there may not 
> be another iteration.
> 

But puCleanUpJunk does iterate until all "junk" has
been cleaned, so wouldn't that be sufficient if
puCleanUpJunk is used to delete puInterface?

		Eero


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

RE: [Plib-devel] pwSetAutoRepeatKey...and pwMacOSX.

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

Well, one obvious solution is just not to use the shift key for anything in
the game.  It doesn't generate a callback call, anyway.  ("Doc, it hurts
when I do *this*."  "So don't to that.")

John F. Fay
joh...@eg...



-----Original Message-----
From: pli...@li...
[mailto:pli...@li...]On Behalf Of Steve Baker
Sent: Friday, April 09, 2004 3:04 PM
To: pli...@li...
Subject: Re: [Plib-devel] pwSetAutoRepeatKey...and pwMacOSX.


Fay John F Contr AAC/WMG wrote:
> Heh, heh, heh, "freeglut" has the bug just as badly as PW does, if not
> worse.  I think I got a callback from releasing the shift key.  I haven't
> checked GLUT.
> 
> You are right, I do get the same sequence of calls with the "?" and "/"
> combination and with the "+" and "=" combination.  So games like that will
> have to deal with it unless we can figure out a way around it.  And I
> daresay you don't want PW to start auto-detecting keyboards and
configuring
> itself around them.

Well, that sounds like a really difficult thing to do - and almost
impossible
to test...so I suppose this isn't a business we should be in.

I guess if GLUT and freeglut are broken, we can just call this a bug in the
keyboard handlers in Windows and X11.

It's going to be a big hassle to work around though.

---------------------------- 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-----


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] puDialogBox error

[Eero P. <epa...@ko...>]

Fay John F Contr AAC/WMG wrote:
> Unfortunately we need to keep the "puCleanUpJunk" in the "puInterface" 
> destructor in case the user is destroying the entire interface at once.  
> If there are widgets within widgets within widgets, we can't wait for 
> another iteration to destroy the sub-sub-widgets because there may not 
> be another iteration.
> 

But puCleanUpJunk does iterate until all "junk" has
been cleaned, so wouldn't that be sufficient if
puCleanUpJunk is used to delete puInterface?

		Eero

Re: [Plib-devel] pwSetAutoRepeatKey...and pwMacOSX.

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

Fay John F Contr AAC/WMG wrote:
> Heh, heh, heh, "freeglut" has the bug just as badly as PW does, if not
> worse.  I think I got a callback from releasing the shift key.  I haven't
> checked GLUT.
> 
> You are right, I do get the same sequence of calls with the "?" and "/"
> combination and with the "+" and "=" combination.  So games like that will
> have to deal with it unless we can figure out a way around it.  And I
> daresay you don't want PW to start auto-detecting keyboards and configuring
> itself around them.

Well, that sounds like a really difficult thing to do - and almost impossible
to test...so I suppose this isn't a business we should be in.

I guess if GLUT and freeglut are broken, we can just call this a bug in the
keyboard handlers in Windows and X11.

It's going to be a big hassle to work around though.

---------------------------- 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-----

RE: [Plib-devel] Is a point inside a triangle in 3-d

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

So:  are we interested in a fast "point-in-triangle" algorithm for SG?  As I
see it, we have three alternatives:

(1) Keep what we have.
(2) Keep what we have and add new functions "sgFastPointInTriangle*" for
applications where it is not crucial that a point fall inside one, and only
one, triangle in a lattice.
(3) Replace what we have with the new algorithm.

Since I haven't done all my homework on the present algorithm and the new
algorithm, I advocate (1).  On the other hand, if I find (in my copious free
time) that the present algorithm will miss points in a lattice of triangles,
you will be hearing about it from me.  For one thing, the present algorithm
goes to "NaN" with degenerate triangles.

John F. Fay
joh...@eg...

RE: [Plib-devel] pwSetAutoRepeatKey...and pwMacOSX.

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

Heh, heh, heh, "freeglut" has the bug just as badly as PW does, if not
worse.  I think I got a callback from releasing the shift key.  I haven't
checked GLUT.

You are right, I do get the same sequence of calls with the "?" and "/"
combination and with the "+" and "=" combination.  So games like that will
have to deal with it unless we can figure out a way around it.  And I
daresay you don't want PW to start auto-detecting keyboards and configuring
itself around them.

John F. Fay
joh...@eg...



-----Original Message-----
From: pli...@li...
[mailto:pli...@li...]On Behalf Of Steve Baker
Sent: Friday, April 09, 2004 1:37 PM
To: pli...@li...
Subject: Re: [Plib-devel] pwSetAutoRepeatKey...and pwMacOSX.


Fay John F Contr AAC/WMG wrote:
> Since a tenet of windowing systems (at least of the GLUT type) is platform
> independence, I guess we will want to change the Windows code to match the
> Linux behavior.

Either that or modify the Linux code to match Windows.

I think on balance, I like the Linux way because anything that's
relying on a key UP event wouldn't see any key repeat if it's done
the Windows way.

> Regarding the bug in the X11 version (about how if you press shift-W,
> release the shift, then release the w, you don't get an up-callback for
the
> "W"):  Windows behaves in exactly the same manner if the keys are pressed
> long enough for the autorepeat to come on (whether PW passes them through
or
> not).  If everything is done quickly, then we get a key press event for
the
> capital letter and a key release event for the lowercase letter.

Yeah - I think Linux is the same.

I wonder what GLUT and freeglut do?  Maybe there is a clever fix of some
kind.

> By moving
> the test for CTRL/SHIFT/CapsLock to above the assignment for "key =
wParam"
> I can remove the second key press callback invocation (with the lowercase
> "w") but we still have the phenomenon of the key press callback being
called
> with one key and the key release with another key.  It may need just to be
> documented as a "feature."

Well, it's very inconvenient for games.  You tend to want to track which
keys
are down and which are up - and there really isn't an easy way to do that
with
the present code.  (Especially when you consider non-US keyboards.  Then,
the
relationship between a punctuation character and the character you get with
the
same key but with SHIFT depressed may be different from one keyboard type to
another.

My code might be smart enough to know that when it sees a '/'
character DOWN followed by a '?' character UP that in fact it was really the
'/' that went up because '?' is just SHIFT+'/'....but is that true on all
keyboards. (HINT: No, it's not!)

Without going back to looking at the original scan-codes, it's going to be
rather hard to figure out what's going on!

This sort of thing might seem unlikely - but there are plenty of games out
there that use (say) 'Z' and 'X' for steering and 'SHIFT' for shooting -
which
could very well result in a sequence like:

PLAYER STARTS TO TURN LEFT:    Presses the 'z' key.   We see 'z'+DOWN.
PLAYER SHOOTS:  Presses the SHIFT key.
PLAYER STOPS TURNING:  Releases the 'z' key - but we see 'Z'+UP.

Now the software doesn't know whether you're still steering or not.

Yuk!

I'm gonna see whether GLUT or freeglut has a clever trick for avoiding
this problem.

---------------------------- 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-----


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] pwSetAutoRepeatKey...and pwMacOSX.

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

Fay John F Contr AAC/WMG wrote:
> Since a tenet of windowing systems (at least of the GLUT type) is platform
> independence, I guess we will want to change the Windows code to match the
> Linux behavior.

Either that or modify the Linux code to match Windows.

I think on balance, I like the Linux way because anything that's
relying on a key UP event wouldn't see any key repeat if it's done
the Windows way.

> Regarding the bug in the X11 version (about how if you press shift-W,
> release the shift, then release the w, you don't get an up-callback for the
> "W"):  Windows behaves in exactly the same manner if the keys are pressed
> long enough for the autorepeat to come on (whether PW passes them through or
> not).  If everything is done quickly, then we get a key press event for the
> capital letter and a key release event for the lowercase letter.

Yeah - I think Linux is the same.

I wonder what GLUT and freeglut do?  Maybe there is a clever fix of some kind.

> By moving
> the test for CTRL/SHIFT/CapsLock to above the assignment for "key = wParam"
> I can remove the second key press callback invocation (with the lowercase
> "w") but we still have the phenomenon of the key press callback being called
> with one key and the key release with another key.  It may need just to be
> documented as a "feature."

Well, it's very inconvenient for games.  You tend to want to track which keys
are down and which are up - and there really isn't an easy way to do that with
the present code.  (Especially when you consider non-US keyboards.  Then, the
relationship between a punctuation character and the character you get with the
same key but with SHIFT depressed may be different from one keyboard type to
another.

My code might be smart enough to know that when it sees a '/'
character DOWN followed by a '?' character UP that in fact it was really the
'/' that went up because '?' is just SHIFT+'/'....but is that true on all
keyboards. (HINT: No, it's not!)

Without going back to looking at the original scan-codes, it's going to be
rather hard to figure out what's going on!

This sort of thing might seem unlikely - but there are plenty of games out
there that use (say) 'Z' and 'X' for steering and 'SHIFT' for shooting - which
could very well result in a sequence like:

PLAYER STARTS TO TURN LEFT:    Presses the 'z' key.   We see 'z'+DOWN.
PLAYER SHOOTS:  Presses the SHIFT key.
PLAYER STOPS TURNING:  Releases the 'z' key - but we see 'Z'+UP.

Now the software doesn't know whether you're still steering or not.

Yuk!

I'm gonna see whether GLUT or freeglut has a clever trick for avoiding
this problem.

---------------------------- 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-----

RE: [Plib-devel] puDialogBox error

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

Unfortunately we need to keep the "puCleanUpJunk" in the "puInterface"
destructor in case the user is destroying the entire interface at once.  If
there are widgets within widgets within widgets, we can't wait for another
iteration to destroy the sub-sub-widgets because there may not be another
iteration.

John F. Fay
joh...@eg...



-----Original Message-----
From: pli...@li...
[mailto:pli...@li...]On Behalf Of Eero Pajarre
Sent: Friday, April 09, 2004 1:19 PM
To: pli...@li...
Subject: Re: [Plib-devel] puDialogBox error


Fay John F Contr AAC/WMG wrote:

> You are absolutely right, deleting the widget with "puDeleteObject" 
> makes all the difference.  We need to fix the web page there.  In fact, 
> this problem was exactly the reason for writing "puDeleteObject".
> 

I wonder if the real fix would require making the problematic destructor
private and puDeleteObject a friend function ... No actually that
would be too ugly...

It might be sufficient to remove puCleanUpJunk() from puInterface
destructor.

(Keep in mind I have still not properly demonstrated this with
the latest sources)


		Eero




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel