plib-devel

Re: [Plib-devel] SVN Conversion

[Frederic B. <fre...@fr...>]

Selon Frederic Bouvier :

> Bert,
>
> Selon Bert Driehuis :
>
> > On Tue, 25 Jul 2006, Frederic Bouvier wrote:
> >
> > > I am afraid you must be a project admin to do that. I am ready to h=
elp
> > > to convert a cvs tarball into a svn dumpfile suitable for the
> > > migration process, if someone wants to give me such a fresh tarball=
.
> >
> > You can easily make one yourself:
> >
> > % mkdir /work/cvs/plib-sf
> > % cd /work/cvs/plib-sf
> > % rsync -av rsync://plib.cvs.sourceforge.net/cvsroot/plib/\* .
> > receiving file list ... done
> >     [...]
> > % ls
> > CVSROOT/        plib/
> >
> > I'll be happy to .tar.gz it and send it to you.
>
> I forgot this new method of creating cvs backup. I just hope I can do i=
t
> without
> being a plib developer. I will try tonight and report.
>
> Nobody will do cvs commit in the meantime, right ?

By the time this message took to be delivered, I made the 2 svndumps for =
plib
and freeglut. They are here :

http://frbouvi.free.fr/plibsvndump.bz2
http://frbouvi.free.fr/freeglutsvndump.bz2

They were made last wednesday 26. They can be used to create the svn
repositories. A message has already been sent to Steve.

Instructions to use the dumps are here : https://sourceforge.net/docs/E09=
#import

-Fred

--
Fr=E9d=E9ric Bouvier
http://frfoto.free.fr         Photo gallery - album photo
http://www.fotolia.fr/p/2278  Other photo gallery
http://fgsd.sourceforge.net/  FlightGear Scenery Designer

Re: [Plib-devel] SVN Conversion

[Frederic B. <fre...@fr...>]

Bert,

Selon Bert Driehuis :

> On Tue, 25 Jul 2006, Frederic Bouvier wrote:
>
> > I am afraid you must be a project admin to do that. I am ready to hel=
p
> > to convert a cvs tarball into a svn dumpfile suitable for the
> > migration process, if someone wants to give me such a fresh tarball.
>
> You can easily make one yourself:
>
> % mkdir /work/cvs/plib-sf
> % cd /work/cvs/plib-sf
> % rsync -av rsync://plib.cvs.sourceforge.net/cvsroot/plib/\* .
> receiving file list ... done
>     [...]
> % ls
> CVSROOT/        plib/
>
> I'll be happy to .tar.gz it and send it to you.

I forgot this new method of creating cvs backup. I just hope I can do it =
without
being a plib developer. I will try tonight and report.

Nobody will do cvs commit in the meantime, right ?

Thanks,

-Fred

--
Fr=E9d=E9ric Bouvier
http://frfoto.free.fr         Photo gallery - album photo
http://www.fotolia.fr/p/2278  Other photo gallery
http://fgsd.sourceforge.net/  FlightGear Scenery Designer

Re: [Plib-devel] SVN Conversion

[Fay J. F Dr C. U. AFSEO/SK <joh...@eg...>]

Bert,

	I would greatly appreciate it if you could make a .tar.gz file of
PLIB for me.  Not for SVN conversion, but for my own use.  The firewall
seems to have gotten thicker so that I can't get CVS files any more using
CVSgrab like I used to.

John F. Fay
Technical Fellow, Jacobs/Sverdrup TEAS Group
850-883-1294
joh...@eg...
 
-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Bert Driehuis
Sent: Tuesday, July 25, 2006 6:37 PM
To: PLIB Developers
Subject: Re: [Plib-devel] SVN Conversion

On Tue, 25 Jul 2006, Frederic Bouvier wrote:

> I am afraid you must be a project admin to do that. I am ready to help 
> to convert a cvs tarball into a svn dumpfile suitable for the 
> migration process, if someone wants to give me such a fresh tarball.

You can easily make one yourself:

% mkdir /work/cvs/plib-sf
% cd /work/cvs/plib-sf
% rsync -av rsync://plib.cvs.sourceforge.net/cvsroot/plib/\* .
receiving file list ... done
    [...]
% ls
CVSROOT/        plib/

I'll be happy to .tar.gz it and send it to you.

Cheers,

 					-- Bert

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's
Techsay panel and you'll get the chance to share your opinions on IT &
business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] SVN Conversion

[steve <sjb...@ai...>]

Fay John F Dr CTR USAF AFSEO/SK wrote:
> Gentlemen,
> 
>         Has anybody tried lately to convert the CVS repository to SVN?

I tried about 10 days ago - and it's still broken.

* The fully automatic feature is simply greyed out - you can't select
   it.
* The semi-automatic feature where you download a CVS repository as a
   tarball is enabled - but always comes back with "FAILED" and zero
   explanation as to why it failed.

What needs to happen (I think) is for someone to set up their own
SVN repository on their own machine - to transfer the CVS tarball
into it - then to upload the resulting SVN repository to Sourceforge.

At the very least, this will enable us to find out why doing that
on Sourceforge is resulting in a "FAILED" message.

Sadly, I just don't have the free time to do that right now.

The other approach (which I dislike - but which would work easily)
would be to create an empty SVN repository and just check in the
current sources as if it were a new project.   This would be easy
to do - but would result in us losing all of our edit history and
old versions going back 7 years or so.

Well, we wouldn't exactly *lose* them because they'd still be in
CVS - but it wouldn't be possible to access them using SVN.

But I think we can (and should) do better.  I just don't have the
time to fritz around with it right now.

Re: [Plib-devel] SVN Conversion

[Bert D. <dri...@pl...>]

On Tue, 25 Jul 2006, Frederic Bouvier wrote:

> I am afraid you must be a project admin to do that. I am ready to help 
> to convert a cvs tarball into a svn dumpfile suitable for the 
> migration process, if someone wants to give me such a fresh tarball.

You can easily make one yourself:

% mkdir /work/cvs/plib-sf
% cd /work/cvs/plib-sf
% rsync -av rsync://plib.cvs.sourceforge.net/cvsroot/plib/\* .
receiving file list ... done
    [...]
% ls
CVSROOT/        plib/

I'll be happy to .tar.gz it and send it to you.

Cheers,

 					-- Bert

Re: [Plib-devel] SVN Conversion

[Frederic B. <fre...@fr...>]

Quoting Fay John F Dr CTR USAF AFSEO/SK :

> Gentlemen,
>
> 	Has anybody tried lately to convert the CVS repository to SVN?

I am afraid you must be a project admin to do that.
I am ready to help to convert a cvs tarball into a svn dumpfile suitable =
for the
migration process, if someone wants to give me such a fresh tarball.

-Fred

--
Fr=E9d=E9ric Bouvier
http://frfoto.free.fr         Photo gallery - album photo
http://www.fotolia.fr/p/2278  Other photo gallery
http://fgsd.sourceforge.net/  FlightGear Scenery Designer

[Plib-devel] SVN Conversion

[Fay J. F Dr C. U. AFSEO/SK <joh...@eg...>]

Gentlemen,

	Has anybody tried lately to convert the CVS repository to SVN?

John F. Fay
Technical Fellow, Jacobs/Sverdrup TEAS Group
850-883-1294
joh...@eg...
 

Re: [Plib-devel] OT: new linux game

[Bram S. <br...@sa...>]

steve wrote:

> I'm not sure what you should do about it - maybe there is a key you can
> hit that causes a giant crane to swing over, pick you up and put you
> back at the last reset point.  It would be FUNCTIONALLY the same as a
> 'suicide/restart' thing - but without taking you out of the 'game
> world'.  It's a subtle distinction - but one that your players will
> appreciate.

Sound good.
 
> If you had the giant crane (or something) then the user could ASK for
> assistance when he needs it - because he knows better than your software
> does when he considers himself 'stuck'.

I think I'll make a rescue helicoptor instead :-)
 
> 
> It looked like maybe it was the size of my screen - but it was centered
> at (0,0) - so I could only see the bottom-left quarter or so of the
> screen.  I've never seen that happen before.
> 
> Which 'GLUT' are you using?  GLUT?  freeglut?  OpenGLUT?

Well.... that really depends on what you have installed on your
build machine.

On mine, I have freeglut.

> I've always hoped for that in my games too - but never, ever got a
> single usable level!

That's a pity, yes.

Well.... even game-ideas would be a valuable contribution.
I tried to think of other obstacles that would be similar to
the ones I have.
  
> Right - but there are lots of interesting things you could model
> like ramps and jumps and curving track sections - loops maybe.  But
> yeah - we'd need to get to the dynamic stuff too.

You're right... the static stuff can be interesting as well.


> Ah - so you have to hard-code the dynamics stuff?  That's not so nice!
> 
> Could it be abstracted in some way that could be read from a file?
> My recollection is that ODE uses a heirarchy not entirely unlike
> a scene graph - but with masses, moments of inertia, etc.

I guess something like that could be possible, although you
still have to account for joints and such. These are likely to
be hardcoded anyway.
 
> Do you have a mailing list for the game where we can take this
> discussion?

I guess that the bulletin board at this place could accomodate this:

http://freshmeat.net/projects/sturmbahnfahrer/

  Bram

Re: [Plib-devel] OT: new linux game

[steve <sjb...@ai...>]

Bram Stolk wrote:

>> 1) The RPM didn't work for me because it demanded a version of glibc
> 
> RPM support is pretty minimal.
> I simply create a deb archive, and convert with alien.
> I've uploaded the rpm without testing.

Yeah - I found it hard to support enough different RPM's to keep
everyone happy - in the end I just gave up and gave people the source
and concentrated on getting good enough './configure ; make install'
support.

>>     Makefile it demands /usr/lib/libode.a - but the default installation
>>     of ODE if you just download it and do a 'make install' is
>>     /usr/local/lib/libode.a - why don't you just link like this:
> 
> I'll change the default prefix in the Makefile from /usr to /usr/local
> 
> I intentionally use libode.a instead of -lode, because I want to 
> avoid building against shared objects, for all the good reasons you
> so eloquently put on this mailing list.

Ah - good point.

The problem with changing it from /usr/lib  to /usr/local/lib is that
on Linux distro's that ship with ODE installed by default (evidently
this doesn't include SuSE 9.3), you'll probably find ODE in /usr/lib.

So whichever path you look for it on, you won't find it 100% of the
time.  (This is why PLIB installs in /usr/lib no matter what!)

>> 2) The level you have working now is way too hard for a first level
>>     (even assuming you do the training level).
> 
> Yeah... last time I checked, out of 50 downloads, only 5 people or
> so made it onto the leaderboard (meaning a complete run below 100 secs).

I didn't even realise we were doing it against the clock!  *OUCH!*

>> 3) The problem with this level is that it has three hard problems
>>     and if you fail the second or third one, you have to 'die' and
>>     then go all the way back to the beginning.   That makes it a lot
>>     harder - but not in a good way - it's just really frustrating.
>>
>>     One thing that would help would be if there was a 'floor' under the
>>     basic level that allowed you to drive back around to the start so
>>     you didn't feel like you were 'dying and restarting' - it's a
>>     psychological thing in a game like that.
> 
> Interesting idea, however, it would really mess up your time without
> the restart, so after 10 attempts or so, your time is already so large,
> you don't make a chance on the leaderboard when you do make the complete
> run. Maybe a start-gate to accompany the finish-gate would fix that.

I hadn't appreciated that speed was a factor.  If you can do it at all,
you can probably do it pretty fast.

When there are multiple levels, maybe you should have two play modes -
one in which getting through a level (no matter how slowly) unlocks
the next level - and another mode that's against the clock.

While you are still working out how to do a level, the ability to go
round and round retrying it would be very useful - once you can do
it reasonably well, doing it faster and faster means that if you
fail even once then your time will be crap - so the restart issue
is less important.

>>     By dividing the 'floor' up with big vertical walls, you could arrange
>>     it so that passing the first problem level would get you past the
>>     first wall - thereby giving you access to a ramp that would let you
>>     retry the second problem without repeatedly having to retry the first
>>     one.   (This is hard to explain in words!)
> 
> I understand it. You want to preserve the progress you already made.

Yeah - somehow.  On longer stages maybe you can do automatic restart
points so once you've gotten through a couple of obstacles, you pass a
gate - when you fall off the track, you get restarted at the last gate
you passed through.

> Then again.... doing a complete run of all the stages on a string, is
> kinda rewarding when you do get there in the end.

Doubtless - but for a lot of people, they'll try that level five or ten
times - then give up in disgust.  There is no better way to put people
off a game by making them go back and redo the same thing over and over.

> But for a new and a much bigger level, your idea makes a lot of sense 
> to me.

I was assuming more/bigger levels would be coming in the future.

>> 4) It's annoying that you can get fatally 'stuck' and that the only way
>>     to proceed is to commit suicide.  That's a HUGE 'no-no' in game
>>     design.  There must ALWAYS be a way to finish the game if you are
>>     still alive.   In a game with real physics, this is a bit of a
>>     challenge since there are ways for the player to get stuck that the
>>     game designer couldn't possibly anticipate.
> 
> Yes.. I agree... I've been thinking about it as well.
> The 'upside down car' is pretty easy to detect, and is already handled
> by the game.

Yeah - but with a physics engine in control, there can be some amazingly
'creative' ways to get stuck.

I'm not sure what you should do about it - maybe there is a key you can
hit that causes a giant crane to swing over, pick you up and put you
back at the last reset point.  It would be FUNCTIONALLY the same as a
'suicide/restart' thing - but without taking you out of the 'game
world'.  It's a subtle distinction - but one that your players will
appreciate.

Like I say - having to 'commit suicide' in order to restart is a
real 'no-no' in game design because it's not something that would
EVER happen in the real world - in game design parlance, it's
"MetaGaming" - and metagaming is to be avoided at all costs.

> Getting your wheels off-ground, without being turned over causes the
> main problem. A possible approach is to detect fast-moving wheels,
> without any motion of the car-body itself, but then again... you could
> be doing a burn-out instead :-)

Yeah - but if you were just gradually making progress (like once I 
managed to use the steering to nudge me just far enough back onto the
track to get going again) - it would be REALLY annoying for the system
to kill you off.

If you had the giant crane (or something) then the user could ASK for
assistance when he needs it - because he knows better than your software
does when he considers himself 'stuck'.

>> 5) On startup, the game opened a large window that was mostly off the
>>     top-left corner of the screen?!?  I had to drag the window so that
>>     more of it was on-screen - then resize it and drag is some more
>>     before I could see all of it.  I've never seen another program with
>>     this problem?!?
> 
> I don't understand this.
> With 'a large window' you mean the main (and only window) of the game,
> right? The one that plays the revving engine animation, the menu, and
> the game itself?

Yes.

> I put glut in fullscreen mode, so it should exactly fit your screen.

It looked like maybe it was the size of my screen - but it was centered
at (0,0) - so I could only see the bottom-left quarter or so of the
screen.  I've never seen that happen before.

Which 'GLUT' are you using?  GLUT?  freeglut?  OpenGLUT?

>> 6) Use 'pw' instead of GLUT - it'll make life easier on your end-users
>>     because that's one less dependancy to worry about.
> 
> I'll take a look at pw, to see if it fits my needs.

It should - all you seem to be doing is opening a window and fetching
key up/down events.

>> My son says he's interested in making some more levels for you if
>> you are interested.  He has to finish an animation he's trying to get
>> into the 'blender' SigGraph show reel - and then he owes me some
>> work on my current game project (The Lemur of Lima) - but if you'd
>> like some help, he would be able to help out in a couple of weeks.
> 
> Yeah... that would be great. I was hoping on level design
> from the community.

I've always hoped for that in my games too - but never, ever got a
single usable level!

However, my kid is pretty amazingly good at 3D modelling work...and
he's on school vacations right now.

>> Is there any level design information out there?
> 
> Tricky stuff....

Yeah - I can understand that.

> modeling is very hard to do properly, using the Wings3d tool helps
> a lot, because the method of construction pretty much avoids
> problems with backfaces, wrong polygon orientation, non matching
> normals/orientation, z-fighting, etc. In fact, with wings, you can
> only create solid models, not e.g. a single triangle.
> With blender models, I've seen all the problems I mentioned above.

Well, not if the person who is doing the modelling knows what they
are doing.  For the game I'm working on, I designed a version of the
PLIB scene graph that was expressed in XML - with an XML writer in
blender and an XML reader for PLIB (although it's not a part of
PLIB for reasons too complicated to explain).

> The other complicating factor is that you need to be aware of
> OpenDE limitations to design levels for sturmbahnfahrer.
> 
> For the static scenery (e.g. the spikes) which is stuff that
> does not move, has no mass, and no velocity, etc, you can pretty
> much do every thing you want.

Right - but there are lots of interesting things you could model
like ramps and jumps and curving track sections - loops maybe.  But
yeah - we'd need to get to the dynamic stuff too.

> For the dynamic parts in the world (ferris wheel cart, magic carpet,
> jump board) you need to approximate these with very simple geometry
> (boxes). The car is approximated by a single box and 4 cylinders.

So would you want to see two versions of the geometry?  One for
rendering and one for ODE's benefit?

Seems reasonable enough.

> An object in the game has three properties:
> -OpenDE body (dynamic properties)
> -OpenDE geometry (used for collision testing only)
> -Plib geometry (used for OpenGL rendering)
> 
> Unfortunately, the opende geom and plib geom are very loosely coupled:
> The first is specified in C++ code, and the latter simply modeled.
> It is the responsibility of the C++ coder to make those two match
> by hand.

Ah - so you have to hard-code the dynamics stuff?  That's not so nice!

Could it be abstracted in some way that could be read from a file?
My recollection is that ODE uses a heirarchy not entirely unlike
a scene graph - but with masses, moments of inertia, etc.

> Due to all this required hand-work, level design is best approached
> by brainstorming on possible obstacles for the course, and then
> consult the opende mailinglist on how to model such an obstacle in
> OpenDE terms. After that, it is simply a matter of modeling a matching
> faceset to go with it, but basically, it starts with the dynamical
> model, and derive a visible model from that.

Right.

Do you have a mailing list for the game where we can take this
discussion?

Re: [Plib-devel] OT: new linux game

[Bram S. <br...@sa...>]

steve wrote:

> Wow!  That's a really neat idea...fun to play too.

Thanks, Steve.... a good review coming from you means a lot.
=20
> I presume other game levels are planned - may I suggest a couple of
> things:
>=20
> 1) The RPM didn't work for me because it demanded a version of glibc

RPM support is pretty minimal.
I simply create a deb archive, and convert with alien.
I've uploaded the rpm without testing.

>     Makefile it demands /usr/lib/libode.a - but the default =
installation
>     of ODE if you just download it and do a 'make install' is
>     /usr/local/lib/libode.a - why don't you just link like this:

I'll change the default prefix in the Makefile from /usr to /usr/local

I intentionally use libode.a instead of -lode, because I want to=20
avoid building against shared objects, for all the good reasons you
so eloquently put on this mailing list.
=20
> 2) The level you have working now is way too hard for a first level
>     (even assuming you do the training level).

Yeah... last time I checked, out of 50 downloads, only 5 people or
so made it onto the leaderboard (meaning a complete run below 100 secs).

> 3) The problem with this level is that it has three hard problems
>     and if you fail the second or third one, you have to 'die' and
>     then go all the way back to the beginning.   That makes it a lot
>     harder - but not in a good way - it's just really frustrating.
>=20
>     One thing that would help would be if there was a 'floor' under =
the
>     basic level that allowed you to drive back around to the start so
>     you didn't feel like you were 'dying and restarting' - it's a
>     psychological thing in a game like that.

Interesting idea, however, it would really mess up your time without
the restart, so after 10 attempts or so, your time is already so large,
you don't make a chance on the leaderboard when you do make the complete
run. Maybe a start-gate to accompany the finish-gate would fix that.

>     By dividing the 'floor' up with big vertical walls, you could =
arrange
>     it so that passing the first problem level would get you past the
>     first wall - thereby giving you access to a ramp that would let =
you
>     retry the second problem without repeatedly having to retry the =
first
>     one.   (This is hard to explain in words!)

I understand it. You want to preserve the progress you already made.

Then again.... doing a complete run of all the stages on a string, is
kinda rewarding when you do get there in the end.

But for a new and a much bigger level, your idea makes a lot of sense=20
to me.

> 4) It's annoying that you can get fatally 'stuck' and that the only =
way
>     to proceed is to commit suicide.  That's a HUGE 'no-no' in game
>     design.  There must ALWAYS be a way to finish the game if you are
>     still alive.   In a game with real physics, this is a bit of a
>     challenge since there are ways for the player to get stuck that =
the
>     game designer couldn't possibly anticipate.

Yes.. I agree... I've been thinking about it as well.
The 'upside down car' is pretty easy to detect, and is already handled
by the game.

Getting your wheels off-ground, without being turned over causes the
main problem. A possible approach is to detect fast-moving wheels,
without any motion of the car-body itself, but then again... you could
be doing a burn-out instead :-)

>=20
> 5) On startup, the game opened a large window that was mostly off the
>     top-left corner of the screen?!?  I had to drag the window so that
>     more of it was on-screen - then resize it and drag is some more
>     before I could see all of it.  I've never seen another program =
with
>     this problem?!?

I don't understand this.
With 'a large window' you mean the main (and only window) of the game,
right? The one that plays the revving engine animation, the menu, and
the game itself?

I put glut in fullscreen mode, so it should exactly fit your screen.

It even worked on a twin-view setup with 2 monitors for me.

> 6) Use 'pw' instead of GLUT - it'll make life easier on your end-users
>     because that's one less dependancy to worry about.

I'll take a look at pw, to see if it fits my needs.

> My son says he's interested in making some more levels for you if
> you are interested.  He has to finish an animation he's trying to get
> into the 'blender' SigGraph show reel - and then he owes me some
> work on my current game project (The Lemur of Lima) - but if you'd
> like some help, he would be able to help out in a couple of weeks.

Yeah... that would be great. I was hoping on level design
from the community.

> Is there any level design information out there?

Tricky stuff....
modeling is very hard to do properly, using the Wings3d tool helps
a lot, because the method of construction pretty much avoids
problems with backfaces, wrong polygon orientation, non matching
normals/orientation, z-fighting, etc. In fact, with wings, you can
only create solid models, not e.g. a single triangle.
With blender models, I've seen all the problems I mentioned above.

The other complicating factor is that you need to be aware of
OpenDE limitations to design levels for sturmbahnfahrer.

For the static scenery (e.g. the spikes) which is stuff that
does not move, has no mass, and no velocity, etc, you can pretty
much do every thing you want.

For the dynamic parts in the world (ferris wheel cart, magic carpet,
jump board) you need to approximate these with very simple geometry
(boxes). The car is approximated by a single box and 4 cylinders.

An object in the game has three properties:
-OpenDE body (dynamic properties)
-OpenDE geometry (used for collision testing only)
-Plib geometry (used for OpenGL rendering)

Unfortunately, the opende geom and plib geom are very loosely coupled:
The first is specified in C++ code, and the latter simply modeled.
It is the responsibility of the C++ coder to make those two match
by hand.

Due to all this required hand-work, level design is best approached
by brainstorming on possible obstacles for the course, and then
consult the opende mailinglist on how to model such an obstacle in
OpenDE terms. After that, it is simply a matter of modeling a matching
faceset to go with it, but basically, it starts with the dynamical
model, and derive a visible model from that.

  Bram

Re: [Plib-devel] OT: new linux game

[steve <sjb...@ai...>]

Bram Stolk wrote:
> Not entirely on-topic, but:
> I want to announce the first release of my linux game,
> 
> "Sturmbahnfahrer - A simulated obstacle course for automobiles"
> 
> It's based on ODE and PLIB, and is available under GPL from
> http://www.sturmbahnfahrer.com

Wow!  That's a really neat idea...fun to play too.

I presume other game levels are planned - may I suggest a couple of
things:

1) The RPM didn't work for me because it demanded a version of glibc
    that's not in SuSE 9.3 - so I built from source code.  In the
    Makefile it demands /usr/lib/libode.a - but the default installation
    of ODE if you just download it and do a 'make install' is
    /usr/local/lib/libode.a - why don't you just link like this:

    ...  -L /usr/local/lib  -lode  ....

    Then it would find ODE automatically no matter whether it's in
    /usr/lib, /lib or /usr/local/lib without me having to edit the
    Makefile.  Ideally, you should use the autotools to auto-detect
    which libraries are present.  It would be nice if the website
    told you where to get ODE from.

2) The level you have working now is way too hard for a first level
    (even assuming you do the training level).

3) The problem with this level is that it has three hard problems
    and if you fail the second or third one, you have to 'die' and
    then go all the way back to the beginning.   That makes it a lot
    harder - but not in a good way - it's just really frustrating.

    One thing that would help would be if there was a 'floor' under the
    basic level that allowed you to drive back around to the start so
    you didn't feel like you were 'dying and restarting' - it's a
    psychological thing in a game like that.

    By dividing the 'floor' up with big vertical walls, you could arrange
    it so that passing the first problem level would get you past the
    first wall - thereby giving you access to a ramp that would let you
    retry the second problem without repeatedly having to retry the first
    one.   (This is hard to explain in words!)

4) It's annoying that you can get fatally 'stuck' and that the only way
    to proceed is to commit suicide.  That's a HUGE 'no-no' in game
    design.  There must ALWAYS be a way to finish the game if you are
    still alive.   In a game with real physics, this is a bit of a
    challenge since there are ways for the player to get stuck that the
    game designer couldn't possibly anticipate.

5) On startup, the game opened a large window that was mostly off the
    top-left corner of the screen?!?  I had to drag the window so that
    more of it was on-screen - then resize it and drag is some more
    before I could see all of it.  I've never seen another program with
    this problem?!?

6) Use 'pw' instead of GLUT - it'll make life easier on your end-users
    because that's one less dependancy to worry about.

My son says he's interested in making some more levels for you if
you are interested.  He has to finish an animation he's trying to get
into the 'blender' SigGraph show reel - and then he owes me some
work on my current game project (The Lemur of Lima) - but if you'd
like some help, he would be able to help out in a couple of weeks.

Is there any level design information out there?

[Plib-devel] OT: new linux game

[Bram S. <br...@sa...>]

Not entirely on-topic, but:
I want to announce the first release of my linux game,

"Sturmbahnfahrer - A simulated obstacle course for automobiles"

It's based on ODE and PLIB, and is available under GPL from
http://www.sturmbahnfahrer.com

   Bram

Re: [Plib-devel] Still no joy from SVN migration.

[Frederic B. <fre...@fr...>]

steve wrote :
> I tried again today to migrate PLIB and freeglut from CVS to Subversion
> (SVN).
>
> The Sourceforge migration tool still shows three possible routes:
>
> 1) From an existing subversion repository (not much help to us)
>  =20

No, it is in fact the only viable solution. What you have to do is :

1. get a fresh cvs repository tarball from sourceforge,
2. download cvs2svn from http://cvs2svn.tigris.org/
3. untar the tarball
4. apply cvs2svn to your repository copy
5. upload the generated svn dump at the root of the sourceforge web
space - there are restrictions on the naming, I don't remember what they =
are
6. migrate

> 2) From a CVS tarball.   When I try to use this method, I just get
>     a "Failure" message back with no clue as to why.
>
> 3) From a SourceForge.net CVS Repository.  Whilst this would be
>     by far the simplest route, this option says "currently not
>     available".
>
> ...so sadly, there is still no way for me to transfer these projects
> across.  :-(
>
> Anyway - I wanted you all to know that I havn't stopped looking.
>
>  =20

HTH

-Fred

--=20
Fr=E9d=E9ric Bouvier
http://frfoto.free.fr         Photo gallery - album photo
http://www.fotolia.fr/p/2278  Other photo gallery
http://fgsd.sourceforge.net/  FlightGear Scenery Designer

[Plib-devel] Still no joy from SVN migration.

[steve <sjb...@ai...>]

I tried again today to migrate PLIB and freeglut from CVS to Subversion
(SVN).

The Sourceforge migration tool still shows three possible routes:

1) From an existing subversion repository (not much help to us)

2) From a CVS tarball.   When I try to use this method, I just get
    a "Failure" message back with no clue as to why.

3) From a SourceForge.net CVS Repository.  Whilst this would be
    by far the simplest route, this option says "currently not
    available".

...so sadly, there is still no way for me to transfer these projects
across.  :-(

Anyway - I wanted you all to know that I havn't stopped looking.

[Plib-devel] SVN migration.

[steve <sjb...@ai...>]

I've been looking into the CVS==>SVN migration for both freeglut and 
PLIB again.

The good news is that the CVS repository for both projects are back
up (although the URL has changed AGAIN -  PROJECT.cvs.sourceforge.net).

The bad news is that the automated SVN migration mechanism hasn't
caught up with the change yet.

I think I can do the migration manually using an 'rsync' dump of
the CVS repository - I'll try that for 'freeglut' this evening
and if it works, I'll do PLIB next.

Re: [Plib-devel] Creating shared libs or plib under Linux

[Fay J. F Dr C. U. AFSEO/SK <joh...@eg...>]

Yes ... It's been a thorn in my side for most of a decade.

John F. Fay
Technical Fellow, Jacobs/Sverdrup TEAS Group
850-883-1294
joh...@eg...
 
-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Hans de Goede
Sent: Monday, June 05, 2006 1:13 PM
To: PLIB Developers
Subject: Re: [Plib-devel] Creating shared libs or plib under Linux



Fay John F Dr CTR USAF AFSEO/SK wrote:
> Hans,
> 
> 	The primary reason I haven't stepped up is that I'm behind an Air 
> Force firewall.  This prevents me from putting things into CVS--which 
> is why I am so eager for the transition to SVN.  This has actually 
> been a problem for me since PLIB moved to SourceForge.
> 

Does this firewall disallow outgoing ssh access to the regular port 22?
Because thats what you need for sf CVS (as a developer, the regular cvs
access is only anonymous).

Regards,

Hans


_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] Creating shared libs or plib under Linux

[Fay J. F Dr C. U. AFSEO/SK <joh...@eg...>]

Well, as soon as we get things out of CVS and into SVN, I will be in a much
better position to "pull the kart."

John F. Fay
Technical Fellow, Jacobs/Sverdrup TEAS Group
850-883-1294
joh...@eg...
 
-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Hans de Goede
Sent: Saturday, June 03, 2006 1:10 PM
To: Mar...@mg...; PLIB Developers
Subject: Re: [Plib-devel] Creating shared libs or plib under Linux



Martin Spott wrote:
> 
> I suggest to put this idea of adding such a 'shared-library-mode' to 
> the 'official' PLIB source tree on hold as long as there's no 
> maintainer who'll try to take care of backwards compatilbility with 
> previously issued binaries.
> 

I agree indeed the most important thing for plib now is to someone actually
stand up and say this looks like a cool project for me and then starts
pulling the kart, he doesn't need to be alone, but someone has to take the
lead. Preferably this someone would be approved by Steve.

Notice that I'm not that someone, I'm interested in plib, willing to create
patches etc, but I'm not going to pull the kart.

Regards,

Hans


_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] Creating shared libs or plib under Linux

[Hans de G. <j.w...@hh...>]

Fay John F Dr CTR USAF AFSEO/SK wrote:
> Hans,
> 
> 	The primary reason I haven't stepped up is that I'm behind an Air
> Force firewall.  This prevents me from putting things into CVS--which is why
> I am so eager for the transition to SVN.  This has actually been a problem
> for me since PLIB moved to SourceForge.
> 

Does this firewall disallow outgoing ssh access to the regular port 22?
Because thats what you need for sf CVS (as a developer, the regular cvs
access is only anonymous).

Regards,

Hans

Re: [Plib-devel] Creating shared libs or plib under Linux

[Hans de G. <j.w...@hh...>]

steve wrote:
> Hans de Goede wrote:
> 
>> The
>> exact same breakage will happen with plain C when you exchange the
>> position of 2 variables in a structure.
> 
> Yes - but very, very few C API's use structures.  In the whole of
> the C standard library there are maybe two.  Things like the
> internals of a FILE are typically hidden.
> 

There are many C API's which use structures I'll gladly admit I know
little about C++ but I can dream in C-code and this simply is not true.

> You just can't do that in C++ and yet still get the benefits of
> a class interface.
> 

<snip>

> No - this is how a C++ library has to be maintained.
> 
> There aren't a whole lot of heavily C++ libraries out there with the
> class objects exposed.   Those that do suffer this problem.
> 
Thats untrue, see QT/KDE for example or the STL or many others which all
work fine with shared-objects and C++.

But as I already said:
>> lets end this with agreeing on the fact that we disagree.

I think thats all there is to it. You are not willing to guarantee a
stable ABI, then downstream (Fedora or whatever) should not depend on a
stable ABI and thus I won't. As said before I've used the full plib
version/release as soname, so if a newer plib gets build it will have a
different soname, guaranteeing proper working (or a linker error giving
a clear message about the problem).

All I'm asking now (and all thats keeping this discussion going) is that
you do not defend your stance with clearly false statements like the
ones above.

<snip>

> If someone comes to us with mysterious errors our reaction will be:
> 
>    "Oh dear - your copy of PLIB has been installed incorrectly
>     by Fedora (or whoever) - I suggest you uninstall it and put
>     it back correctly.  If you still have a problem - come back
>     to us."
> 
> ...we've seen these kinds of fiasco's many times before from the
> RedHat guys - both C++ and Mesa have been grabbed from CVS repositories
> in an unfinished or unreleased state and stuffed into their distro.
> I'd hoped that PLIB wouldn't suffer the same fate...but there isn't
> a good defense of that for an OpenSource library team.

1) I'm not RedHat but a volunteer contributer
2) The C++ compiler and Mesa things are off topic
3) Debian (which is known for its stability) has been doing this for
ages so solely targeting Fedora for this isn't helping this discussion,
instead you should be glad that I'm trying to work this out with you
instead of shipping modified packages without ever letting you know
which Debian appearantly is doing.

Regards,

Hans

Re: [Plib-devel] Creating shared libs or plib under Linux

[Fay J. F Dr C. U. AFSEO/SK <joh...@eg...>]

Hans,

	The primary reason I haven't stepped up is that I'm behind an Air
Force firewall.  This prevents me from putting things into CVS--which is why
I am so eager for the transition to SVN.  This has actually been a problem
for me since PLIB moved to SourceForge.

John F. Fay
Technical Fellow, Jacobs/Sverdrup TEAS Group
850-883-1284
joh...@eg...
 
-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Hans de Goede
Sent: Monday, June 05, 2006 2:45 AM
To: PLIB Developers
Subject: Re: [Plib-devel] Creating shared libs or plib under Linux




I assume with "you" you mean the plib developer community, not me :) Yes it
would be great if someone could step up and to those things. Come one
everyone any takers?

Re: [Plib-devel] Creating shared libs or plib under Linux

[steve <sjb...@ai...>]

Hans de Goede wrote:

>>* I don't run this like Linus runs the kernel - I'm not the sole
>>   'gatekeeper' of the golden sources.
> 
> Good, but the others still seem to want you to act as Linus when a
> decision has to be taken they all seem to say I have no opinion lets ask
> Steve. (Which is actually a bit different from how Linus does it, there
> the others first voice there opinion loudly and then Linus makes the
> decision if a consensus can't be reached :).

Well, 'life or death' decisions (such as going '.so' or staying '.a')
are things I'd like to have a say in - but I'd hope that one or more of
those 23 other registered developers would be able to help commit a
simple patch.

If you'd like to become a registered developer yourself, please send me
a request with your sourceforge username and I'll be happy to add you
to the list.

>>* The only tasks you really need me to help out with are those that
>>   require admin privilage:
>>
>>   + Mailing list settings.
>>   + Making releases.
>>   + Creating new developers.
>>   + Doing stuff like transitioning CVS to SVN.
> 
> I assume with "you" you mean the plib developer community, not me :)

Yes.

Re: [Plib-devel] Creating shared libs or plib under Linux

[steve <sjb...@ai...>]

Hans de Goede wrote:

> Definitely a bug in the newer plib if you ask me, the answer to the
> whole above scenario is simple: don't exchange the 2 variables.

...or add a virtual function - or change the type of an internal
class member - or almost anything actually.

I sense you havn't tried to maintain a large C++ class library
with dozens of contributors.   You can't stop this kind of change -
you just can't be that alert.

> The
> exact same breakage will happen with plain C when you exchange the
> position of 2 variables in a structure.

Yes - but very, very few C API's use structures.  In the whole of
the C standard library there are maybe two.  Things like the
internals of a FILE are typically hidden.

You just can't do that in C++ and yet still get the benefits of
a class interface.

> So the whole this is C++ shared
> libs can't be done with C++ scenario doesn't fly here.

I'm sorry - but you are wrong.  I've been writing C++ libraries
since the very first C++ translator came out from AT&T - and I'm
quite certain of that.

> Actually it
> doesn't fly at all. Because in essence the problem is the same in both
> worlds though shall not change the layout of in memory structures.

Yes - but in C, you design your API without exposed data because C
is a PROCEDURAL language.  C++ is HEAVILY data-driven with the
inner workings of your classes necessarily exposed in the '.h' files.

It's the style of programming - not the precise details of the language.

> There are even tricks in the book to allow you to extend in memory
> layouts as long as you don't change them.

Not in a portable and efficient manner.

> This has been done for ages,
> when you program native Xlib for example you must always ask the library
> to alloc the WMHints struct for you because the _real_ size is unknown
> to applications the struct may contain additional members after those
> declared in the header file.

Now mentally extend that to the SSG scene graph structure and see what
an unholy mess you'd end up with.

> This is where the way plib is maintained apparently differs hugely from
> other libraries (again this is language independent).

No - this is how a C++ library has to be maintained.

There aren't a whole lot of heavily C++ libraries out there with the
class objects exposed.   Those that do suffer this problem.

> Now plib doesn't give this ABI stability guarantee and I understand that
> you aren't willing to give this guarantee in the future either. (From
> what I've heard plib doesn't even offer API stability guarantees).

We are actually REMARKABLY stable over the years for programs that are
recompiled when they want a new version of PLIB.

> So lets end this with agreeing on the fact that we disagree. Fedora is
> shipping plib .so files as of yesterday with the full release (1.8.4)
> as soname, when a bug comes by that needs fixing I'll be sure not to
> break the ABI when a new plib is released (say 1.8.5) I'll change the
> soname (to 1.8.5) and provide a compatibility package (for 1.8.4 linked
> apps) untill all apps are succesfully rebuild and linked against 1.8.5 .

I have no control over what the distro guys do with this package -
that's what OpenSource is all about - however, they should not expect
binary compatibility between releases because we can't assure that.

Please don't expect us to field queries from users of these distro's
because we simply can't do that if the package was installed incorrectly
by the distro vendors.

If someone comes to us with mysterious errors our reaction will be:

   "Oh dear - your copy of PLIB has been installed incorrectly
    by Fedora (or whoever) - I suggest you uninstall it and put
    it back correctly.  If you still have a problem - come back
    to us."

...we've seen these kinds of fiasco's many times before from the
RedHat guys - both C++ and Mesa have been grabbed from CVS repositories
in an unfinished or unreleased state and stuffed into their distro.
I'd hoped that PLIB wouldn't suffer the same fate...but there isn't
a good defense of that for an OpenSource library team.

Re: [Plib-devel] Creating shared libs or plib under Linux

[Hans de G. <j.w...@hh...>]

steve wrote:
> Hans de Goede wrote:
> 
>> It seems to me that plib development is a bit stuck at everyone waiting
>> one Steve and Steve not having time todo any work on plib, why don't you
>> (the community) take over / why doesn't Steve hand over leadership to
>> someone else?
> 
> I've certainly been too busy with paying work to give PLIB the time it
> deserves.
> 
> However:
> 
> * I don't run this like Linus runs the kernel - I'm not the sole
>    'gatekeeper' of the golden sources.
> 

Good, but the others still seem to want you to act as Linus when a
decision has to be taken they all seem to say I have no opinion lets ask
Steve. (Which is actually a bit different from how Linus does it, there
the others first voice there opinion loudly and then Linus makes the
decision if a consensus can't be reached :).

Now with the shared lib story I can understand that people want to hear
your opinion (besides their own) But why noone sofar has reacted to my
pw fullscreen patch is a mistery. Yes I know its Xlib only, I would hope
a windows developer to step up and implement the windows version that
shouldn't be to hard I think.

> * I don't believe I've ever turned down anyone who requested developer
>    status.  If you plan to regularly commit patches and you aren't a
>    developer - let me know and I'll give you CVS access.
> 

Erm, I'll just lurk around on the list for now to get a hang of things
are done in plib and I'll wait and see how many patches for plib I
produce. If I get and hit no plib related bugs in my Fedora work I
probably won't be doing much plib work and then CVS access won't be
necessary. But if I ever feel the need for it I'll ask, thanks!

> * The only tasks you really need me to help out with are those that
>    require admin privilage:
> 
>    + Mailing list settings.
>    + Making releases.
>    + Creating new developers.
>    + Doing stuff like transitioning CVS to SVN.
> 

I assume with "you" you mean the plib developer community, not me :) Yes
it would be great if someone could step up and to those things. Come one
everyone any takers?

Regards,

Hans

Re: [Plib-devel] Creating shared libs or plib under Linux

[Hans de G. <j.w...@hh...>]

steve wrote:
> Hans de Goede wrote:
>> Bram Stolk wrote:
>> <snip>
>>
>>> But first: what is the exact reason for you wanting to have shared libs?
>>> Do you want to package multiple plib games for a distro and need to spare
>>> the redudancy?
>>>
>>
>> We already ship multiple plib games and plan to package more in the
>> future. It isn't about sparing the redundancy in terms of diskspace, let
>> alone the very theoretically lower memory usage when running multiple
>> plib using games at once (who would want to run multiple games at once).
>>
>> There is only one reason for wanting shared libs and thats a very good
>> reason: with shared libs if a bug is found in plib (and no piece of code
>> is bugfree) we only need to release an updated plib package which the
>> fixed shared libs and all plib using programs / games will magicly pick
>> up the bugfix.
> 
> That's another urban legend.
> 
> I've been supporting these kinds of applications since before Tux the
> Penguin - A Quest for Herring was released in 1998.  Here is the
> truth:
> 
> All it takes is something like:
> 
>    class ssgThing
>    {
>      char *second ;
>      int first ;
>    public:
> 
>      void setFirst ( int x ) { first = x ; }
>      void setSecond ( char *y ) ;
>    }
> 
> 
> ...then in the '.cxx' file:
> 
>    void ssgThing::setSecond { char *y ) { second = y ; }
> 
> ...then, a year later, some enthusiastic contributer looks at
> 'class ssgThing' and thinks it would look nicer if the
> fields 'first' and 'second' were in the right order...
> 
>    class ssgThing
>    {
>      int   first ;
>      char *second ;
>    public:
> 
>      void setFirst ( int x ) { first = x ; }
>      void setSecond ( char *y ) ;
>    }
> 
> (or he adds a variable - or changes it's type or adds a virtual
> function or changes a defaulting parameter or...almost anything
> acutally)
> 
> ...now we recompile the library and rerelease it - and KABLOOIE - every
> single dynamically linked binary crashes because 'setFirst' in the
> application scribbles over 'second' in the library and you get the
> weirdest crashes in formerly working applications.
> 
> To be clear here - there was no bug in the older PLIB, no bug in the
> newer PLIB and no bug in the application...yet still it crashes.
> 

Definitely a bug in the newer plib if you ask me, the answer to the
whole above scenario is simple: don't exchange the 2 variables. The
exact same breakage will happen with plain C when you exchange the
position of 2 variables in a structure. So the whole this is C++ shared
libs can't be done with C++ scenario doesn't fly here. Actually it
doesn't fly at all. Because in essence the problem is the same in both
worlds though shall not change the layout of in memory structures. The
only thing making c++ slightly harder is the fact that the virtual
function table is an in memory structure too.

There are even tricks in the book to allow you to extend in memory
layouts as long as you don't change them. This has been done for ages,
when you program native Xlib for example you must always ask the library
to alloc the WMHints struct for you because the _real_ size is unknown
to applications the struct may contain additional members after those
declared in the header file.

> 
> So whilst there are times when upgrading PLIB might fix bugs in older
> applications - there are just as many times when it CAUSES bugs in
> perfectly working programs.
> 

Only if you break the ABI and a _bugfix_ release to a library should
never break the ABI.

This is where the way plib is maintained apparently differs hugely from
other libraries (again this is language independent).

Other libraries have a scheme where 1.8.x would all be ABI compatible,
maybe a .x release could introduce new functionality, but done in such a
way that it doesn't break the ABI. Then when you _really_ need to change
the ABI you release 2.0.x (or 1.9.x) and then you're free to exchange
the position of the variables as described above and todo whatever you
want, and you change the soname so that the linker _will_ complain when
an older apps is ran and only this version is installed (with a
different soname both versions can be installed besides eachother).

Now plib doesn't give this ABI stability guarantee and I understand that
you aren't willing to give this guarantee in the future either. (From
what I've heard plib doesn't even offer API stability guarantees).

So lets end this with agreeing on the fact that we disagree. Fedora is
shipping plib .so files as of yesterday with the full release (1.8.4)
as soname, when a bug comes by that needs fixing I'll be sure not to
break the ABI when a new plib is released (say 1.8.5) I'll change the
soname (to 1.8.5) and provide a compatibility package (for 1.8.4 linked
apps) untill all apps are succesfully rebuild and linked against 1.8.5 .

Regards,

Hans

Re: [Plib-devel] Creating shared libs or plib under Linux

[Norman V. <nh...@ca...>]

steve writes:
>
> Sooner or later my workload will reduce and I'll get active again - =
it'sjust not practical right now - sorry.

Cool, bunch of us are waiting for that

after all PrettyPoly should be using shaders  :-)

Ciao

nhv


=20