plib-users

Re: [Plib-users] PLIB games

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

Steve Wendt wrote:
> 
> On Sun, 22 Jul 2001 19:16:32 -0500, Steve Baker wrote:
> 
> >I actually *had* updated both programs to fix most of the things you mentioned
> >on July 15th.
> 
> Downloading the new versions (and the new PLIB), I noticed the links for
> exposer and ttt3d aren't valid.  You have "_" instead of "-" in the names.

Doh!

I'm too tired to fix it tonight....

----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net     http://tuxaqfh.sf.net  http://tuxkart.sf.net
           http://agtoys.sf.net   http://prettypoly.sf.net
           http://freeglut.sf.net http://toobular.sf.net

Re: [Plib-users] PLIB games

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

Steve Wendt wrote:

> >This is something that someone else complained about - we kicked it around a bit
> >and I don't understand it.  None of my makefiles have
> $(top_srcdir)/../mkinstalldirs ?!?
> 
> It came from Makefile.in (for tux_aqfh).

But it doesn't...I just looked at that file and it says:

tuxaqfh/Makefile.in:

   mkinstalldirs = $(SHELL) $(top_srcdir)/mkinstalldirs

In the tuxaqfh/src/Makefile.in, it actually says the same
thing - but in that case, $(top_srcdir) changes.

What's doubly weird is that this only happens to RedHat 7.x users.

> >> I also had to add -lglut to the makefiles for both games; I guess this is some
> >> error in the configure script?
> >
> >Again, I can't reproduce this.  Whatever I do, that's in the Makefile just as it
> >should be.
> 
> Hmmm... I'll download the latest versions, and check the configure output more
> carefully to see what is happening.
> 
> >I'm betting that your Linux distro has put GLUT somewhere strange.
> 
> Not the distro, I compile my own Mesa.  It goes to /usr/local/lib, but it does make
> links in /usr/lib (including for glut I think, but I'll have to check).

Ah!   Well, I bet you are either missing:

   /usr/include/GL/glut.h

...or

   /usr/lib/libglut.a  (or .so)

...if either of those are missing, the autodetect in the configure script will fail...
producing the effect you are seeing.  The locations I describe above are the "official"
ones according to the Linux OpenGL ABI standard.
 
> >What graphics hardware do you have?
> 
> Voodoo 2.  Some versions of Mesa break it from time to time.  I had to revert
> libGL for some things to work correctly, but GLU and glut seemed OK.
> Apparently, things aren't so good... I'll revert back to 3.4.2 and see if I do better
> with that.

Voodoo-2 is pretty old (and VERY strange) hardware.  It's *definitely* time to upgrade!
 
----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net     http://tuxaqfh.sf.net  http://tuxkart.sf.net
           http://agtoys.sf.net   http://prettypoly.sf.net
           http://freeglut.sf.net http://toobular.sf.net

Re: [Plib-users] PLIB games

[Steve W. <st...@sh...>]

On Sun, 22 Jul 2001 19:16:32 -0500, Steve Baker wrote:

>I actually *had* updated both programs to fix most of the things you mentioned
>on July 15th.

Downloading the new versions (and the new PLIB), I noticed the links for 
exposer and ttt3d aren't valid.  You have "_" instead of "-" in the names.


-----------
"Good people do not need laws to tell them to act responsibly,
while bad people will find a way around the laws."
     - Plato (427-347 B.C.)

Re: [Plib-users] PLIB games

[Steve W. <st...@sh...>]

On Sun, 22 Jul 2001 19:16:32 -0500, Steve Baker wrote:

>When did you download them?
>I actually *had* updated both programs to fix most of the things you mentioned
>on July 15th.

Before that.  Sorry, I hadn't seen an announcment of later versions.  :)

>This is something that someone else complained about - we kicked it around a bit
>and I don't understand it.  None of my makefiles have 
$(top_srcdir)/../mkinstalldirs ?!?

It came from Makefile.in (for tux_aqfh).

>> I also had to add -lglut to the makefiles for both games; I guess this is some 
>> error in the configure script?
>
>Again, I can't reproduce this.  Whatever I do, that's in the Makefile just as it
>should be.

Hmmm... I'll download the latest versions, and check the configure output more 
carefully to see what is happening.

>I'm betting that your Linux distro has put GLUT somewhere strange.

Not the distro, I compile my own Mesa.  It goes to /usr/local/lib, but it does make 
links in /usr/lib (including for glut I think, but I'll have to check).

>What graphics hardware do you have?

Voodoo 2.  Some versions of Mesa break it from time to time.  I had to revert
libGL for some things to work correctly, but GLU and glut seemed OK.  
Apparently, things aren't so good... I'll revert back to 3.4.2 and see if I do better 
with that.


-----------
"Good people do not need laws to tell them to act responsibly,
while bad people will find a way around the laws."
     - Plato (427-347 B.C.)

Re: [Plib-users] PLIB games

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

Steve Wendt wrote:
> 
> Apologies if this is not the proper place for this, but I'm not aware of a better one.
> I finally got around to trying the updated versions of TuxKart and Tux_AQFH.

When did you download them?

I actually *had* updated both programs to fix most of the things you mentioned
on July 15th.

> Tux_AQFH was missing install.sh and mkinstalldirs

...that was fixed in tux_aqfh-1.0.13.tar.gz

> which I copied from TuxKart.
> I had to modify all of the makefiles, to change $(top_srcdir)/../mkinstalldirs to
> $(top_srcdir)/mkinstalldirs (just like it is in TuxKart).

This is something that someone else complained about - we kicked it around a bit
and I don't understand it.  None of my makefiles have $(top_srcdir)/../mkinstalldirs ?!?

Something must have changed subtly in the way that your version of Linux is interpreting
the configure script...but I can't for the life of me figure out what.  Since I can't
reproduce it - it's VERY tough for me to fix.

>  Three files that were in a
> previous version (level14.ac, tree.rgb, and tux.mod) are not in the latest one.  Are
> they no longer used, or was this a mistake?

No longer used.
 
> For TuxKart, I had to add #include <sys/socket.h> to guNet.cxx.

That's fixed in tuxkart-0.0.6.tar.gz - which has been out on the website
since July 15th.

> I also had to add -lglut to the makefiles for both games; I guess this is some error
> in the configure script?

Again, I can't reproduce this.  Whatever I do, that's in the Makefile just as it
should be.

 LIBS = -lplibsl -lplibssg -lplibpu -lplibfnt -lplibsg -lplibul
        -lglut -lGLU -lGL   -L/usr/X11R6/lib  -lSM -lICE -lpthread
        -lX11 -lXi -lXext -lXmu  -lm

(It's all on one line in the Makefile.)

I'm betting that your Linux distro has put GLUT somewhere strange.

Did the configure script complain about GLUT being missing?

> Anyway, I got both games built.  However, I couldn't get either one to work
> correctly.  In TuxKart, when I press the Start button, it just sits there on the same
> screen, until I kill it.  In Tux_AQFH, when I press the Space bar, the menu comes
> up, and then it is similarly hung.  I compiled both of these with Mesa 3.5, perhaps
> that is the problem?  I've been meaning to revert to Mesa 3.4.2, since 3.5 doesn't
> seem quite "polished" yet.

What graphics hardware do you have?

----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net     http://tuxaqfh.sf.net  http://tuxkart.sf.net
           http://agtoys.sf.net   http://prettypoly.sf.net
           http://freeglut.sf.net http://toobular.sf.net

Re: [Plib-users] PLIB games

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

Steve Wendt wrote:
> 
> Apologies if this is not the proper place for this, but I'm not aware of a better one.
> I finally got around to trying the updated versions of TuxKart and Tux_AQFH.
> 
> Tux_AQFH was missing install.sh and mkinstalldirs, which I copied from TuxKart.
> I had to modify all of the makefiles, to change $(top_srcdir)/../mkinstalldirs to
> $(top_srcdir)/mkinstalldirs (just like it is in TuxKart).  Three files that were in a
> previous version (level14.ac, tree.rgb, and tux.mod) are not in the latest one.  Are
> they no longer used, or was this a mistake?

This is a peculiar problem - (and you aren't the first person to comment about it),
when I build these on SuSE Linux, it seems to manage without those files.

I'll make a new TuxAQFH release to fix that.

> For TuxKart, I had to add #include <sys/socket.h> to guNet.cxx.

Yes - that's also been noted...something moved from one header to another - because
again, it builds OK under SuSE Linux.

>  The file
> mfarmer.mod that was in a previous version is no longer included - obsolete, or
> mistakenly omitted?

It shouldn't be needed.  mfarmer.mod was music that I downloaded from a free
music site - but since then Matt Thomas kindly composed music especially for
TuxKart that should be MUCH easier on the ear!
 
> I also had to add -lglut to the makefiles for both games; I guess this is some error
> in the configure script?

That's strange - the configure script finds it on my system.  Do you have GLUT installed
in some unusual place?  (It should be /usr/lib/libglut.a or libglut.so)
 
> Anyway, I got both games built.  However, I couldn't get either one to work
> correctly.  In TuxKart, when I press the Start button, it just sits there on the same
> screen, until I kill it.  In Tux_AQFH, when I press the Space bar, the menu comes
> up, and then it is similarly hung.  I compiled both of these with Mesa 3.5, perhaps
> that is the problem?  I've been meaning to revert to Mesa 3.4.2, since 3.5 doesn't
> seem quite "polished" yet.

Hmmm - maybe.

I guess you are using RedHat 7.x or Mandrake 8.0?  (I presume that because
since I did this new release, I havn't had a single complaint for ANY OTHER
distro owner).

----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net     http://tuxaqfh.sf.net  http://tuxkart.sf.net
           http://agtoys.sf.net   http://prettypoly.sf.net
           http://freeglut.sf.net http://toobular.sf.net

[Plib-users] PLIB games

[Steve W. <st...@sh...>]

Apologies if this is not the proper place for this, but I'm not aware of a better one.
I finally got around to trying the updated versions of TuxKart and Tux_AQFH.

Tux_AQFH was missing install.sh and mkinstalldirs, which I copied from TuxKart.
I had to modify all of the makefiles, to change $(top_srcdir)/../mkinstalldirs to 
$(top_srcdir)/mkinstalldirs (just like it is in TuxKart).  Three files that were in a 
previous version (level14.ac, tree.rgb, and tux.mod) are not in the latest one.  Are 
they no longer used, or was this a mistake?

For TuxKart, I had to add #include <sys/socket.h> to guNet.cxx.  The file 
mfarmer.mod that was in a previous version is no longer included - obsolete, or 
mistakenly omitted?

I also had to add -lglut to the makefiles for both games; I guess this is some error 
in the configure script?

Anyway, I got both games built.  However, I couldn't get either one to work 
correctly.  In TuxKart, when I press the Start button, it just sits there on the same 
screen, until I kill it.  In Tux_AQFH, when I press the Space bar, the menu comes 
up, and then it is similarly hung.  I compiled both of these with Mesa 3.5, perhaps 
that is the problem?  I've been meaning to revert to Mesa 3.4.2, since 3.5 doesn't 
seem quite "polished" yet.


-----------
"Good people do not need laws to tell them to act responsibly,
while bad people will find a way around the laws."
     - Plato (427-347 B.C.)

Re: [Plib-users] Callback

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

Arne Kreutzmann wrote:
> 
> Hi,
> 
> I'm lerning plib right now, and have one question.
> 
> button->setCallback ( widget_cb );
> //     "void widget_cb ( puObject *ob )"
> 
> I would like classes to handel the callback.
> I know I can do that if I use *static*, is there an another way ?

No - there is a real problem with the C++ language - this is not something
you can solve.

The bottom line is that C++ does not allow you to take the
address of a non-static member function...and there are good reasons
for this.

You end up doing this:

  * Write a short 'wrapper' function:

      void my_callback ( puObject *ob )
      {
        MyClass *my_class = (MyClass *)(ob->getUserData()) ;
        my_class -> memberFunction ( ob ) ;
      }

    (This could be a static member function of the class)

  * Put a pointer to the class to which the button belongs
    into the userdata field of the button.

      button -> setUserData ( this ) ;

  * Make the wrapper function be the callback:

      button -> setCallback ( my_callback ) ;

This is a pain - but it's the best you can do in C++.

----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net     http://tuxaqfh.sf.net  http://tuxkart.sf.net
           http://agtoys.sf.net   http://prettypoly.sf.net
           http://freeglut.sf.net http://toobular.sf.net

[Plib-users] Callback

[Arne K. <Arn...@gm...>]

Hi,

I'm lerning plib right now, and have one question.

button->setCallback ( widget_cb );
//     "void widget_cb ( puObject *ob )" 

I would like classes to handel the callback.
I know I can do that if I use *static*, is there an another way ?

Arne

[Plib-users] ANNOUNCING: PLIB 1.5.1, PLIB Demos.

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

ANNOUNCING: PLIB 1.5.1, PLIB Demos.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In order that developers may get some experience with features scheduled
to go into PLIB 1.6.x (eventually), this is the second beta: PLIB 1.5.1

I also created tarballs for ExPoser (which requires PLIB 1.5.1) and
TicTacToe3D (which runs under PLIB 1.4.0 or later).  Check out the
new "Examples and Demos" link from the PLIB homepage.

  * Added ssgTween and ssgTweenController
 
  * Added puFileSelector - henceforth puFilePicker is deprecated.
 
  * Added ulList
 
  * Added VRML loader (this one works!)
 
  * Numerous bug fixes in other loaders.
 
  * Added TopHat support to JS
 
  * Added support for >3 simultaneous sounds in SL.
    (You have to explicitly enable that though - it's not
    the default)
 
  * Fixed bugs in util's directory handling.
 
  * puInput and puListBox now cope better with text that
    is too big for the widget
 
  * puListBox (and hence puFileSelector and puFilePicker)
    works with both large and small font sizes.
 
  * puDial changed to be derived from puSlider - many
    consequences of that change will be visible in the
    application.  (eg output range is 0..1 and not 0..360)
 
  * PUI widgets are now 'sticky' so that if you are
    dragging a slider along a puSlider and your mouse
    slips off the edge of it, it'll still have "focus".
 
  * Added sgLerpAnglesVec3 to linearly interpolate
    angles allowing for the nasty wrap-around-360
    problem.
 
  * Added sgLineSegment3ToLine3, sgDistSquaredToLineVec3
    sgDistSquaredToLineSegmentVec3, sgDistToLineVec3 and
    sgDistToLineSegmentVec3.  Also sgLine3 and sgLineSegment3
    structures.
 
  * Added a 'Gallery' page to the documentation to show
    potential developers the range of applications that use
    PLIB - and also to promote things our developers have done.
    To save download time and CVS space, the actual images
    are not in the PLIB tarball.

----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net     http://tuxaqfh.sf.net  http://tuxkart.sf.net
           http://agtoys.sf.net   http://prettypoly.sf.net
           http://freeglut.sf.net http://toobular.sf.net

Re: [Plib-users] cant compile on MandrakeFreq

[<Seb...@t-...>]

YES !!! it was in mesa-common-devel vielen dank !!!

Re: [Plib-users] cant compile on MandrakeFreq

[Arne K. <Arn...@gm...>]

>I am searching the rpms on my installdisks by viewing them in 
>kpackage-filelist-window, thats really painful ! How would you look for 
>missing files ??? (ok afterwards it seems to be clear that i should have 
>installed XFree86-devel )
>
>sebastian

Hi,

I would do it like this:

move to the place where you install your rpms from eg.
/mnt/cdrom/packages/i386/ ?
there you type the following:

rpm -qilp *.rpm > ~/all_rpm
less ~/all_rpm

now to search for a file just type:

/FILE.NAME

then you find all packages this file is in.
That's it.

Arne

Re: [Plib-users] cant compile on MandrakeFreq

[<Seb...@t-...>]

I found gl.h in XFree86-devel-4.1.0-4mdk.i586.rpm and I found glu.h in the 
X-sources, but now I need glut.h...

can someone tell me what packages i should install now
(i already can run opengl-programs, just the develpackages are missing)

I am searching the rpms on my installdisks by viewing them in 
kpackage-filelist-window, thats really painful ! How would you look for 
missing files ??? (ok afterwards it seems to be clear that i should have 
installed XFree86-devel )

sebastian

[Plib-users] cant compile on MandrakeFreq

[<Seb...@t-...>]

I'm trying to set up plip to install flightgear but make complains there are 
2 files missing: GL/gl.h and GL/glu.h

does someone know to what package they might belong ?

I thought they might be in glut (glut has GL/fgl.h and GL/fglu.h), tried to 
rename them: didnt help ( as you can imagine )

thank you in advance !!!

sebastian

here is what configure and make exactly said, just if it might be useful:

[root@drakeman plib-1.4.0]# ./configure
loading cache ./config.cache
checking for a BSD compatible install... (cached) /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... (cached) yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
includedir changed to ${prefix}/include/plib libdir is ${exec_prefix}/lib
checking for gcc... (cached) gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking how to run the C preprocessor... (cached) gcc -E
checking for c++... (cached) c++
checking whether the C++ compiler (c++  ) works... yes
checking whether the C++ compiler (c++  ) is a cross-compiler... no
checking whether we are using GNU C++... (cached) yes
checking whether c++ accepts -g... (cached) yes
checking how to run the C++ preprocessor... (cached) c++ -E
checking for a BSD compatible install... /usr/bin/install -c
checking for ranlib... (cached) ranlib
checking for windows.h... (cached) no
checking for X... (cached) no
checking for dlclose in -ldl... (cached) yes
checking for glNewList in -lGL... (cached) no
checking for glNewList in -lMesaGL... (cached) no
checking for gluLookAt in -lGLU... (cached) no
checking for gluLookAt in -lMesaGLU... (cached) no
checking for glutGetModifiers in -lfreeglut... (cached) no
checking for glutGetModifiers in -lglut... (cached) no
checking for alOpenPort in -laudio... (cached) no
checking for ANSI C header files... (cached) no
checking for GL/gl.h... (cached) no
checking for GL/glu.h... (cached) no
checking for windows.h... (cached) no
checking for joystick.h... (cached) no
checking for linux/joystick.h... (cached) yes
checking for GL/glut.h... (cached) no
checking for GL/freeglut.h... (cached) no
checking for socklen_t... yes
creating ./config.status
creating Makefile
creating src/Makefile
creating src/js/Makefile
creating src/util/Makefile
creating src/pui/Makefile
creating src/sg/Makefile
creating src/sl/Makefile
creating src/ssg/Makefile
creating src/ssgAux/Makefile
creating src/fnt/Makefile
creating src/net/Makefile
[root@drakeman plib-1.4.0]# make
Making all in src
make[1]: Wechsel in das Verzeichnis Verzeichnis 
»/usr/local/games/source/plib-1.4.0/src«
Making all in util
make[2]: Wechsel in das Verzeichnis Verzeichnis 
»/usr/local/games/source/plib-1.4.0/src/util«
c++ -DPACKAGE=\"plib\" -DVERSION=\"1.4.0\" -DX_DISPLAY_MISSING=1 
-DHAVE_LIBDL=1 -DLINUX_JOYSTICK_IS_PRESENT=1  -I. -I.    -I/usr/local/include 
 -g -O2 -O6 -Wall -c ul.cxx
In file included from ul.cxx:25:
ul.h:81:19: GL/gl.h: Datei oder Verzeichnis nicht gefunden
ul.h:82:20: GL/glu.h: Datei oder Verzeichnis nicht gefunden
make[2]: *** [ul.o] Fehler 1
make[2]: Verlassen des Verzeichnisses Verzeichnis 
»/usr/local/games/source/plib-1.4.0/src/util«
make[1]: *** [all-recursive] Fehler 1
make[1]: Verlassen des Verzeichnisses Verzeichnis 
»/usr/local/games/source/plib-1.4.0/src«
make: *** [all-recursive] Fehler 1
[root@drakeman plib-1.4.0]#

Re: [Plib-users] Shadows

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

Arne Kreutzmann wrote:

> my application will be a 3D realtime strategy game.
> So I guess there I less need of shadows anyway.

Then I would definitely consider the 'fuzzy translucent circle' approach.

----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net     http://tuxaqfh.sf.net  http://tuxkart.sf.net
           http://agtoys.sf.net   http://prettypoly.sf.net
           http://freeglut.sf.net http://toobular.sf.net

Re: [Plib-users] Shadows

[Arne K. <Arn...@gm...>]

>In my games, I generally limit myself to putting a fuzzy translucent
>circle on the ground beneath each moving character - and either
hand-modelling
>shadow for the scenery - or not bothering.
>
>What kind of application do you have in mind?

Hi, 

my application will be a 3D realtime strategy game.
So I guess there I less need of shadows anyway.

Thanks
	Arne

Re: [Plib-users] Shadows

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

Arne Kreutzmann wrote:

> I would like to know if plib supports shadows or not, and if how to set
> them up.

There is no direct support - but some of the techniques people use to
generate shadows in OpenGL should be applicable to PLIB applications.

Shadows are *VERY* hard to do "correctly" and "universally".  For most
rendering algorithms, drawing without shadows takes an amount of time
thats directly proportional to the number of polygons on the screen.

Drawing shadows "correctly" takes an amount of time proportional to
the the number of triangles in the entire scene multiplied by the
number of triangles that are on-screen.

Hence there are a number of cheats that work with varying degrees
of success to produce visual effects that trade quality against
performance.

In my games, I generally limit myself to putting a fuzzy translucent
circle on the ground beneath each moving character - and either hand-modelling
shadow for the scenery - or not bothering.

What kind of application do you have in mind?

----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net     http://tuxaqfh.sf.net  http://tuxkart.sf.net
           http://agtoys.sf.net   http://prettypoly.sf.net
           http://freeglut.sf.net http://toobular.sf.net

[Plib-users] Shadows

[Arne K. <Arn...@gm...>]

Hi,

I would like to know if plib supports shadows or not, and if how to set
them up.

Thanks
	Arne

[Plib-users] Sound demo crash 2

[Arne K. <Arn...@gm...>]

Hi,

I just wanted to post the error message too.
When I put the lines back in an compiled again, everything works ?

Arne

[Plib-users] Sound demo crash

[Arne K. <Arn...@gm...>]

Hi,

I'm new to plib!

I just tried the examples for 1.4.1, and when I try the sound example it
crashs shortly after I started it.

I have a 

	Athlon 1 GHZ
	Geforce 2 Ultra
	Onborad Sound
	I work with Windows 98 SE
	until my Linux (Dabian or Redhat)
	is back up.

If I take out the delay function it works fine.
What shoud I do about it.

Arne

Re: [Plib-users] sl error?

[Chris Willis-F. <cwi...@ws...>]

Okay, i've done a little bit more investigating...
Weird thing #1: tuxkart works fine, even when i'm playing other sound.

Also, I checked both sawfish and gnome (these being what i'm running) and
they both have their sound stuff turned off. Still no go on AQFH...

Weird thing #2: Well, I'll let you figure out meaning of this since I'm
not really sure what it's telling me...
A snippet from "strace tux_aqfh" where things appear to start going wrong,
as near as i can tell (I've fiddled with formatting for readability but
the data's 100% accurate, copy/pasted):

==SNIP==
ioctl(8, SNDCTL_DSP_GETOSPACE, 0x83045ac) = 0
write(8, "\200\200\200\200\200\200\200\200\200\200\200"..., 4096) = 4096

ioctl(8, SNDCTL_DSP_GETOSPACE, 0x83045ac) = 0
write(8, "\200\200\200\200\200\200\200\200\200\200\200"..., 4096) = 4096

ioctl(8, SNDCTL_DSP_GETOSPACE, 0x83045ac) = 0
write(8, "\200\200\200\200\200\200\200\200\200\200\200"..., 4096) = 4096

ioctl(8, SNDCTL_DSP_GETOSPACE, 0x83045ac) = 0
write(8, "\200\200\200\200\200\200\200\200\200\200\200"..., 4096) = 4096

ioctl(8, SNDCTL_DSP_GETOSPACE, 0x83045ac) = 0
write(8, "\200\200\200\200\200\200\200\200\200\200\200"..., 4096) = -1
  EAGAIN (Resource temporarily unavailable)
write(2, "slDSP: write: Resource temporari"..., 47) = 47

ioctl(8, SNDCTL_DSP_GETOSPACE, 0x83045ac) = 0
write(8, "\200\200\200\200\200\200\200\200\200\200\200"..., 4096) = -1
  EAGAIN (Resource temporarily unavailable)
write(2, "slDSP: write: Resource temporari"..., 47) = 47
==SNIP==

Runtime-wise, this happens shortly after the game opens /dev/js0, if that
helps any. This is also the first time in the strace that the program
writes to file handle 8, which is what open("/dev/dsp",...) got.

Right now this is looking really odd to me, but then again I don't have
much experience coding for sound ;)

Thanks for your help,

Chris Willis-Ford


On Mon, 16 Jul 2001, Steve Baker wrote:

> Chris Willis-Ford wrote:
> 
> > slDSP: write: Resource temporarily unavailable
> > ...
> > 
> > the slDSP line keeps going indefinitely, or at least until i press
> > control-C... any ideas? I have a feeling it may be related to my
> > particular sound card (driver)... I'm running an aureal vortex2, using the
> > 1.1.2 drivers found at http://sourceforge.net/projects/aureal
> 
> It could be due to your window manager...I know that some 'enlightenment'
> WM's have audio mixers that open /dev/dsp0 and keep it open.  There is
> generally a way to do that within the WM.
>  
> > oh, and no other sound programs were running when i tried this, just in
> > case you were wondering... esd wasn't running, xmms wasn't running, "fuser
> > /dev/dsp" returned nothing, etc. etc. etc...
> 
> Hmmm - well, the message is coming from the 'write' system call.  I asked
> it to please open /dev/dsp0 (evidently it succeeded) - then I asked to write
> to the device and it says it can't...it's gotta be that something in the
> kernel thinks it's already open and being written to by someone else.
>  
> ----------------------------- Steve Baker -------------------------------
> HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
> HomePage : http://web2.airmail.net/sjbaker1
> Projects : http://plib.sf.net     http://tuxaqfh.sf.net  http://tuxkart.sf.net
>            http://agtoys.sf.net   http://prettypoly.sf.net
>            http://freeglut.sf.net http://toobular.sf.net
> 

 ==================================================================

 "Being able to see The Right Thing, then program it into existence
  out of thin air is still the core wonder of programming for me."

    -- John Carmack, id Software

Re: [Plib-users] sl error?

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

Chris Willis-Ford wrote:

> slDSP: write: Resource temporarily unavailable
> ...
> 
> the slDSP line keeps going indefinitely, or at least until i press
> control-C... any ideas? I have a feeling it may be related to my
> particular sound card (driver)... I'm running an aureal vortex2, using the
> 1.1.2 drivers found at http://sourceforge.net/projects/aureal

It could be due to your window manager...I know that some 'enlightenment'
WM's have audio mixers that open /dev/dsp0 and keep it open.  There is
generally a way to do that within the WM.
 
> oh, and no other sound programs were running when i tried this, just in
> case you were wondering... esd wasn't running, xmms wasn't running, "fuser
> /dev/dsp" returned nothing, etc. etc. etc...

Hmmm - well, the message is coming from the 'write' system call.  I asked
it to please open /dev/dsp0 (evidently it succeeded) - then I asked to write
to the device and it says it can't...it's gotta be that something in the
kernel thinks it's already open and being written to by someone else.
 
----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net     http://tuxaqfh.sf.net  http://tuxkart.sf.net
           http://agtoys.sf.net   http://prettypoly.sf.net
           http://freeglut.sf.net http://toobular.sf.net

[Plib-users] sl error?

[Chris Willis-F. <cwi...@ws...>]

Hi all!

First off, I'd like to ask anybody that replies to this message to reply
to me personally, since I'm not subscribed to this list...

Anyway, i'm having a problem with plib 1.4.1, tested with tux AQFH... it
looks like this:

Data files will be fetched from: '/usr/local/share/games/tux_aqfh'
slDSP: write: Resource temporarily unavailable
slDSP: write: Resource temporarily unavailable
slDSP: write: Resource temporarily unavailable
slDSP: write: Resource temporarily unavailable
...

the slDSP line keeps going indefinitely, or at least until i press
control-C... any ideas? I have a feeling it may be related to my
particular sound card (driver)... I'm running an aureal vortex2, using the
1.1.2 drivers found at http://sourceforge.net/projects/aureal

oh, and no other sound programs were running when i tried this, just in
case you were wondering... esd wasn't running, xmms wasn't running, "fuser
/dev/dsp" returned nothing, etc. etc. etc...

any guesses? any valuable information i left out?

Thanks for reading,

Chris Willis-Ford

 ==================================================================

 "Being able to see The Right Thing, then program it into existence
  out of thin air is still the core wonder of programming for me."

    -- John Carmack, id Software

Re: [Plib-users] Re: Matrix rotation question

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

"McEvoy, Nick" wrote:

> My solution was if my model was pitched + or - 90, then I adjusted it to be
> + or - 89.5 ... this kludge seems to fix the problem (ie. my eye doesn't
> notice the jump).  When I have some more time I'll have to read up on a
> better way to fix it.

Yep!  I've resorted to doing that in order to fix broken code in short
order (Tux - A Quest for Herring has it for when Tux goes swimming) - but
the precision of roll and heading gets rather poor as you get closer and
closer to 90 - so it has to be done with care.

Quaternions will work better in a space game where there is no inherent
"up" direction...they also handily work around the transition problems
you get with going from -180 to +180 or so.

----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net     http://tuxaqfh.sf.net  http://tuxkart.sf.net
           http://agtoys.sf.net   http://prettypoly.sf.net
           http://freeglut.sf.net http://toobular.sf.net

[Plib-users] Re: Matrix rotation question

[McEvoy, N. <nic...@ds...>]

Curtis L. Olson wrote:

>It sounds like you may be experiencing "gimble lock".  If so, you
>should take a look at the definitive document on the subject:
>    http://web2.airmail.net/sjbaker1/eulers_are_evil.html

Thanks !

Actually a few minutes after I posted my question I visited that page. I had
a feeling it was the old "gimble lock" scenario.

My solution was if my model was pitched + or - 90, then I adjusted it to be
+ or - 89.5 ... this kludge seems to fix the problem (ie. my eye doesn't
notice the jump).  When I have some more time I'll have to read up on a
better way to fix it.

Nick.