plib-devel

[Plib-devel] KobayashiMaru & plib

[Alexander R. <ale...@us...>]

Hi,


this is an 'Open Letter' to Steve and Oliver Baker and all other people
 behind plib, Tux_aqfh and Tuxkart:

there is a new game in town that uses plib:

   Kobayashi Maru      kobayashimaru.sourceforge.net

a Mailing List kob...@li... has been
created

It's goal is to write a flexible, extensible, multi-platform (blah blah
 blah :-) Space Fight Simulator in 3D

I searched a long time for a scenegraph I could easyly use, because
I didn't knew GL at that time, and the onlu useable I found was plib.

Arg! It took me a whole month experimenting with euler angles,
rotating starfighters, completely failing.
Then I switched to up-right-forward-direction vectors and succeded.

Exacly one day later, I stumbled across 'Euler Angles are Evil' by
Steve, and I knew why I failed a whole month.

Dear Steve, I could kiss you all day long for plib and Tux, but
I'll gonna kick your ass sometime because it would be very very
better if you'd put at least 'Euler Angles are Evil' and
'Matrices can be your Friends' on the _plib_homepage_, so that
even an idiot like me will stumble over it before he looses time.

I also want to have you a look at KobayashiMaru, because I am even
worse in designing spaceships than in maths, and so I took the
models that came with Tux_aqfh for my own project, please allow me
to use them in my game.

Your authorship is of course mentioned.

I am some time now receiving the plib-* mailing lists, but I actually
never had time to read them, so it could be that I am using plib
not in the optimum way to give best performance.
All calls to plibssg have been capsulated in class KobScene and
KobSceneObject, if there is something to impove, let me know.

I am also having the problem of being not able to use a 3D modeler
at all (tried,failed,tried,failed,tried,failed,gave up), couldn't
even make a Tie Fighter, and all free 3D objects I found
in the net where designed for ray-traying and had far too many
polygons and no texture - I'm desperate.

So, if there is anyone out there dreaming like me to see X-Wings and
Tie-Fighers and Klingons and Borgs and the not-yet-created ships
from the Free Stars Foundation (FSF) (their High Priest is a Holy Gnu -
a really weird hairy animal ;-) and the TuxFleet (a horde of inter-
stellar penguins flying giant Iceberg-shaped glistering StarLiberators,
they cooperate in an alliance with the FSF to fight
Imperator Raw-Ass The Utterly Evil - aka me, in this game I wanna be
 the bad guy)

I'll do the coding till my fingers bleed, but please, please, PLEASE

    can't anyone out there design 3D Models for this game?

I need models with few polygons as possible, in low,mid and high detail,
and with _lots_ of texture, since that's what a modern Gfx-Card
(exept GForce) can take.
You can even create more detail levels in between, but I need
anything that runs on a todays computer (and - in low detail - even
on old ones).
I also dream about running Kobayashi Maru on a PDA running linux -
ever there ever is something like a 'fastGLforPDA' available,
you'd need even low low detail ;-)

I also want to have the plib community to look at ssgUtil.cxx (maybe
there is something to go to plibsg/plibssg) and at class puScrollList
I've implemented - puScrollList even doesn't work correct for me,
but you could take up the Idea and implement a cleanly designed/working
puScrollList (or is there an easier way?)

I also have to say that (for my implementation of puScrollList I badly
need something like puObject->setLegendPlace, in Mission/Model Selection
the scroll-list in the top-right corner looks like shit - the legends
should be aligned to the left (inside the widgets).

Now again thoughts about plibssg performance.
I have not much performance on my Athlon500/Tnt2, some is wasted in
my code (I know exactly where), but a large part is lost in ssgCullAndDraw().
If there is something to be improved in KobScene/KobSceneObject, please
do that.
But the capsulation of the Scenegraph the game uses in KobScene will
make it possible to 'switch' between different Scenegraphs (at least
at compile time).
The aim should be that KobayashiMaru should be able to compile for any
Scenegraph and any Soundhandler at any time.
I'd really like to use a glDoom/glQuake/Quakeforge/Aftershock-based
Scenegraph, if you could give me a pointer to where to find good
docu and easy-to-use examples...
Other Scenegraphs I've thought of are SGI Performer, Crystal Space, 
Genesis3D, PVision, and - as a very very optional native implementation -
Direct3D (urks) would also be possible, if someone is mad enough.
I had yet no time to look at those, can't anyone else do that and
mail me a summary?
What a Scenegraph for KobayasiMaru should be able to do can be seen
by reading kob_scene.h/cxx

At the moment I use plibsl for very very basic sound effects, but for
a game like that I need full-stereo-full-pitching-xxx-channels etc,
even 3D sound will be possible with the right underlying Soundhandler,
but, as like for the Scenegraph, KobayashiMaru will compile at any
time optionally for plibsl , with the limitations plibsl has, of course.
But which other portable open source sound system, that features at
least 4 to 8-channel-stereo with modern soundcards, I don't have
experience in that, the only Idea I have is to have a look at
SDL from Loki. Any other Ideas?


Please reply to the KobayashiMaru Mailing List, I hope I hear
from you.



Alex

Notice: this 'Open Letter' will also be (seperately) mailed to
        the KobayashiMaru mailing-list to archive it
        better use the mailing-list for your answer, to keep it
        in the public

RE: [Plib-devel] KobayashiMaru & plib

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

Alexander Rawass writes:

>there is a new game in town that uses plib:
>
>   Kobayashi Maru      kobayashimaru.sourceforge.net

Congratulations to Alexander,  and also to Steve and all the others
helping to keep PLib cross platform.

Except for changing the set_callback code in one derived puObject
to use a staticly defined function instead of a class member

This code compiles and runs on my Win98 box with Cygwin V1.1.3
by only changing the CXXFLAGS, LDFLAGS and LDLIBS
variables in the makefile !!!

Norman

FYI
!!! makefile mods for Cygwin V1.1.3
INCDIRS= -I/usr/local/include
LDFLAGS= -L/usr/local/lib
GLLIBS= -lglut32  -lopengl32 -lglu32
CXXFLAGS= -Wall -DWIN32

!!! puScrollList.h mods
//  void slider_callback(puObject *pob);

!!! puScrollList.cxx mods
!! replace method with smae name with this static
static void slider_callback(puObject *pob){
  //  printf("in slider callback\n");
  puSlider  *psl=(puSlider *) pob;
  //float val= pob->getValue();
}

!!! change this line in constructor
//    slider->setCallback( (void (*)(puObject *))
(&puScrollList::slider_callback) );
    slider->setCallback(slider_callback);

Re: [Plib-devel] KobayashiMaru & plib

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

Alexander Rawass wrote:

> there is a new game in town that uses plib:
> 
>    Kobayashi Maru      kobayashimaru.sourceforge.net

I'll check it out - do you have a small logo that I could put
on the PLIB home page as a link to the game?

> Arg! It took me a whole month experimenting with euler angles,
> rotating starfighters, completely failing.

Ah - perhaps you should ask for help next time!

> Then I switched to up-right-forward-direction vectors and succeded.
> 
> Exacly one day later, I stumbled across 'Euler Angles are Evil' by
> Steve, and I knew why I failed a whole month.
> 
> Dear Steve, I could kiss you all day long for plib and Tux, but
> I'll gonna kick your ass sometime because it would be very very
> better if you'd put at least 'Euler Angles are Evil' and
> 'Matrices can be your Friends' on the _plib_homepage_, so that
> even an idiot like me will stumble over it before he looses time.

Actually - neither being kissed all day long nor having my ass
kicked sound all *that* attractive.  :-)

Mailing me requests written on the back of $100 bills gets my
attention though   ;-)

On the "math_help" page - where you are heaping praise on my
FAQ page and running me into the ground for my web-organizational
skills, you describe me as a "non-professional" - that's not too
accurate.  I write flight sim graphics for a living.

Also, after all you said about the FAQ page, you didn't provide a
link to it!

The "matrices can be your friend" document is an example one of
those documents you either love or hate.  Several mathematicians have
come close to death threats over it.  Offers of 24hr kissings are
also not as uncommon as you might expect.  :-)

I came across that explanation for how a matrix works completely
by accident.  When I was just starting out doing 3D, I was
blinded by the inscrutability of matrices - so I decided to try
to invent a new way to do 3D transforms.  I wanted to think about
what happened to the unit cube - and then use extrapolation to
figure out what happened to the rest of the model.  So, I wrote
down the coordinates that the unit cube would move to - and
then said "well, a point at (10,12,14) will end up ten times
further than where the X axis of the cube went, 12 times where
the Y axis went and 14 times where the Z axis was." 

That trick worked *perfectly* - and so - being very proud of
having discovered this brand new way to do rotation/translation/shear,
I showed my supervisor...who pointed out that the math in my
final result was in fact identical to matrix math!  Sheepishly,
I went back to my desk - realising that I had not stumbled on
some great new mechanism that would revolutionise 3D rendering.

Working back carefully, I realised that by writing down the
final position of the unit cube - I was just writing down the
rows of the damned matrix that I hated so much. At that point,
a bolt of lightning flashed from the heavens - angels sang, etc, etc.

I *grokked* matrices by re-inventing them from the ground up.
"grok" is a good word here.  It means more than "understand" - it
means that you have 'internalized' not just the bare facts - but
all the reasons *why* it works, *how* it works, etc.

Once you have that little unit cube dancing around in your head,
you can never again forget how matrix math implements 3D transformations.

If only math teachers could figure out the importance of teaching
*some* students that way.

Other people on the other hand, prefer the raw math - and proof in
a symbolic manner - they don't need to visualise what's going on...
and they *HATE* my explanation.

> I also want to have you a look at KobayashiMaru, because I am even
> worse in designing spaceships than in maths, and so I took the
> models that came with Tux_aqfh for my own project, please allow me
> to use them in my game.

Sure - that's what OpenSource is all about.  The models that come
with Tux{AQFH,Kart} are licensed under GPL - just like the game itself,
and so long as your game is also released as source code under GPL (or
something compatible) then you are all set to go - and you don't even
need to ask permission. (Although it's nice that you did)
 
> Your authorship is of course mentioned.

Thank-you!
 
> I am some time now receiving the plib-* mailing lists, but I actually
> never had time to read them, so it could be that I am using plib
> not in the optimum way to give best performance.
> All calls to plibssg have been capsulated in class KobScene and
> KobSceneObject, if there is something to impove, let me know.
> 
> I am also having the problem of being not able to use a 3D modeler
> at all (tried,failed,tried,failed,tried,failed,gave up), couldn't
> even make a Tie Fighter, and all free 3D objects I found
> in the net where designed for ray-traying and had far too many
> polygons and no texture - I'm desperate.

Hmmm - the problem of getting appropriate free artwork is a hard one.

Many people have mentioned the reluctance of artists to donate their
work to the OpenSource community...there was a LONG thread about this
on the Linux Games Developers list which resulted in the formation of
a mailing list for artists working in the OpenSource community to get
together and spread the word.

> So, if there is anyone out there dreaming like me to see X-Wings and
> Tie-Fighers and Klingons and Borgs and the not-yet-created ships
> from the Free Stars Foundation (FSF) (their High Priest is a Holy Gnu -
> a really weird hairy animal ;-) and the TuxFleet (a horde of inter-
> stellar penguins flying giant Iceberg-shaped glistering StarLiberators,
> they cooperate in an alliance with the FSF to fight
> Imperator Raw-Ass The Utterly Evil - aka me, in this game I wanna be
>  the bad guy)

:-)

Well, you'd do well to steer clear of X-wings, Tie Fighters, Klingons
and Borg because you'll get your ass sued for sure.

Rip the rotors off the 'tuxcopter' in TuxAQFH and you'd have a
usable 'StarLiberator' shuttlecraft.  :-)

I'll ask Oliver if he'd consider building you some spaceships - he
likes doing stuff like that.  He's away from home until next weekend
though...be patient!

> I'll do the coding till my fingers bleed, but please, please, PLEASE
> 
>     can't anyone out there design 3D Models for this game?
> 
> I need models with few polygons as possible, in low,mid and high detail,
> and with _lots_ of texture, since that's what a modern Gfx-Card
> (exept GForce) can take.
> You can even create more detail levels in between, but I need
> anything that runs on a todays computer (and - in low detail - even
> on old ones).

Fortunately, space ships can be anything from a Borg Cube (Six textured
quadrilaterals) to the ship in "The Last Starfighter" - which at the
time was the most complex object ever modelled inside a computer - at
over 1 million (untextured) triangles.

The artists working on StarTrek must have wanted to go home early on
the day they designed the Borg ship!  :-)

> I also dream about running Kobayashi Maru on a PDA running linux -
> ever there ever is something like a 'fastGLforPDA' available,
> you'd need even low low detail ;-)

They announced 'MiniGL' (which runs on PalmPilot) last week at SigGraph.
It's likely to be *horrificly* slow - and with only 5-grey-shade monochrome
with no Z buffer, I don't think you *really* want to go there yet.

There was also an announcement of a formal standard for an OpenGL subset
that runs on Cell phones and pagers (presumably not *this* generation of
such devices) - but no implementation is available yet.   :-)

> Now again thoughts about plibssg performance.
> I have not much performance on my Athlon500/Tnt2, some is wasted in
> my code (I know exactly where), but a large part is lost in ssgCullAndDraw().
> If there is something to be improved in KobScene/KobSceneObject, please
> do that.

Well, in TNT-2, all your transform and lighting code is in software,
so you should expect ~90% of your CPU time (for a typical game) to
be in ssgCullAndDraw().  Now, if (whilst it's consuming that much
CPU time), you are not getting reasonable polygon throughput rates,
we have a problem.

How many polygons are you drawing - and what kind of frame rate are
you getting - with what percentage of your CPU time going into ssgCullAndDraw?

Looking at your screenshot, I'd guess that a TON of time is being wasted drawing
the text.  It *looks* to me like it's being drawn using GLUT's fonts - which
are REALLY slow on most graphics cards.

You really need to draw text using textured quadrilaterals - for which there
is (of course) a PLIB library 'FNT'.

However, for a fast action game, nobody will have time to read all that tiny
text anyway.  It's generally considered a good idea to use as little text
as possible in a game - preferably none at all.

Also, that spider's web looking thingy - I presume it's a radar display - is
consuming a LOT of throughput if it's being drawn as OpenGL lines - there appear
to be at least 120 lines being drawn.  Most PC graphics hardware does a very poor
job of drawing lines - so you'd be better off painting a really nice radar display
in GIMP (or whatever paint program you prefer) - and drawing that as a single
textured quad.

> But the capsulation of the Scenegraph the game uses in KobScene will
> make it possible to 'switch' between different Scenegraphs (at least
> at compile time).

OK...but all that abstraction and layering costs time - why do you think
you need it?   I know it's nice *in theory* to have a choice of scenegraph
API's but what actual benefit does it bring?   Well, I suppose it lets
you choose non-portable scene-graphs for specific platforms - but I very
much doubt that you could reconcile all the little itty-bitty features
you'll come to need across a wide range of scene graph platforms.

SSG already acts as a portability layer - why go and build a portability
layer ON TOP of a portability layer?

> The aim should be that KobayashiMaru should be able to compile for any
> Scenegraph and any Soundhandler at any time.
> I'd really like to use a glDoom/glQuake/Quakeforge/Aftershock-based
> Scenegraph, if you could give me a pointer to where to find good
> docu and easy-to-use examples...

Those tend to be highly oriented to the kinds of game they come from.

I don't think you could do a good space game using a first-person-perspective
shooter "game engine".

I don't know about glDoom or Aftershock - but Quake/Quakeforge are tuned
for all the fancy flickering torchlight lighting effects and 'portal'
clipping that being in a dark closed space entails.  That's pretty much
the opposite of a space game.

> Other Scenegraphs I've thought of are SGI Performer, Crystal Space,
> Genesis3D, PVision...Direct3D

Yep - all of those are possible.

Performer and Direct3D are of course utterly non-portable. (Well, Performer
runs under IRIX and Linux - but nothing else).

Crystal Space is also heavily slanted towards FPS games (in my opinion).

I don't know enough about PVision or Genesis3D to comment on those.

There are also some others that you missed - OpenSG for example.

> I had yet no time to look at those, can't anyone else do that and
> mail me a summary?
> What a Scenegraph for KobayasiMaru should be able to do can be seen
> by reading kob_scene.h/cxx

Well, SSG is a LOT like Performer - in fact, if you look far enough
back into it's origins, it actually started out as a clone of Performer's
scene graph functions.
 
> At the moment I use plibsl for very very basic sound effects, but for
> a game like that I need full-stereo-full-pitching-xxx-channels etc,
> even 3D sound will be possible with the right underlying Soundhandler,

Then I think you should look into 'OpenAL' - which is big-time into
3D spatialised sound.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [Plib-devel] KobayashiMaru & plib

[Wolfram K. <w_...@rz...>]

Steve wrote:

>The "matrices can be your friend" document is an example one of
>those documents you either love or hate.  Several mathematicians have
>come close to death threats over it.  

Strange. I don't really see why. As far as I see, what you do is
mathematically correct. In mathematical speak, you choose a basis
in one coordinate system, namely the straight-forward basis
(0,0,1), (0,1,0) and (1,0,0) and then look at the transformed
vectors, which will again be a basis of three dimensional space as
long as the matrix is nice enough :-), that is as long as it is
invertible.

When I started with computer graphics, I knew matrices quite well
and had no problem understanding that they can be used to transform
vertices etc. However, I didn't understand at once why it is
advantageous to use them versus rotating, translating and projecting
the vertices "manually". 
The point why 4x4 matrices (or at least 4x3 if you don't have
projection) are effective and why you don't use 3x3 matrices is that
translating - which normally means adding numbers - has been converted
into multiplications. This means instead of transforming the vertex
with operation1, then operation2 etc you can multiply all the matrices
and then transform each vertex only once. For a slight overhead
(multiplying all the matrices) you save something per vertex. For
example, if A and B are matrices and v is a vertex, then you may
calculate either

A*(B*v) 

or 

(A*B)*v

For n vertices, the first costs n*(16+16) multiplications,
the second costs once 16*4 multiplications and then for each vertex
another 16. This means for five or more vertices its faster to merge
all transformations into one large one. This is only possible via
matrices or equivalent stuff.
Steve writes all this in one sentence in his FAQ :-).

>If only math teachers could figure out the importance of teaching
>*some* students that way.

Most things can be taught in a variety of ways. For example I once saw
an article that you can explain the formula pressure=force/area
in five completely different ways. For example you can start with
"if you double the area, the force will double". Or you can 
try it experimentally and say the harder you push the nail into you
flesh, and the smaller its "front area", the higher the pain ;-).

But it is always difficult to teach in several ways, since you don't
have as much time and since this will often cause additional
confusion. Even people who understand the first explanation
can be confused by the second if it doesn't fir their way of thinking.

Bye bye,
Wolfram.

Re: [Plib-devel] KobayashiMaru & plib

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

Alexander Rawass wrote:
> 
> there is a new game in town that uses plib:
> 
>    Kobayashi Maru      kobayashimaru.sourceforge.net
> 
> a Mailing List kob...@li... has been
> created
> 
> It's goal is to write a flexible, extensible, multi-platform (blah blah
>  blah :-) Space Fight Simulator in 3D

Have you had a look at Parsec (http://www.parsec.org)?

I know that they don't publish their source (but IIRC they plan to
release the game itself for free)...

It'll be at least interesting to get some new ideas. They've also got a
few papers online (they are CS students; Parsec is their 'playing
ground' for their ideas) which are very interesting IMHO.

CU,
Christian

Re: [Plib-devel] KobayashiMaru & plib

[Alexander R. <a_r...@in...>]

Hi,

> > It's goal is to write a flexible, extensible, multi-platform (blah blah
> >  blah :-) Space Fight Simulator in 3D
> 
> Have you had a look at Parsec (http://www.parsec.org)?
> 
> I know that they don't publish their source (but IIRC they plan to
> release the game itself for free)...
> 
> It'll be at least interesting to get some new ideas. They've also got a
> few papers online (they are CS students; Parsec is their 'playing
> ground' for their ideas) which are very interesting IMHO.

HaHaHa - Parsec is no danger for my project.

When I first heard of Parsec, I had already written enough code, and
I was relieved to see that there is nothing and that they have
nothing exept some films, some sounds, no code, no source, nothing
you can really do with.

Now they they've got a selfrunning demo in glide. I don't have glide.

I don't know why they are building up a secret cathedral, I
dont't know why (for a 'free' game) they don't go open source,
it's simply a behaviour I cannot understand.

I am writen on KobayashiMaru since the start of the year, with very
long pauses inbetween, and I think I am quicker than them (exept
for models and gfx) and I am quite shure, that my game will be
of course be better than theirs, simply because it is open source
AND it is designed to be completely extensible, and if KobayashiMaru
will get developed further, it may grown so something which is bigger
and better, I want it to make it to a universal action/shooting
gaming engine, while Parsec will rot on disks and begin to
foul on the CDs, because the Heart will get no new blood.

Yes, I am truly an Open Source Freak.

I would gladly have dumped KobayashiMaru if Parsec would have been
the better one, to help extend Parsec to the thing I want, but
this is only possible with open source.


Alex


-- 
                   Alexander Rawass
          Email: ale...@us...
   Project Homepage: http://kobayashimaru.sourceforge.net
...but some day you'll be a STAR in somebody else's SKY...

Re: [Plib-devel] KobayashiMaru & plib

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

Alexander Rawass wrote:

> Yes, I am truly an Open Source Freak.
> 
> I would gladly have dumped KobayashiMaru if Parsec would have been
> the better one, to help extend Parsec to the thing I want, but
> this is only possible with open source.

Have you emailed and asked if your could join their team?

Some developers like to get things working nicely before they
release the source code.

I'm actually like that.  Neither TuxAQFH nor TuxKart were released
as OpenSource until they were actually working.

It's nice not to have outside interference and endless questions
about the code until it's more or less ready to go.

But I understand your point of view too.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net