[Plib-devel] Re: KobayashiMaru & plib

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

Hi,

Steve wrote:

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

Not yet. Maybe soon.

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

I will correct that :-)
That's the thing about the web:
you see someone's page, you don't read careful enough, you make
certain assumptions, and in the end the reality is completely
different from what I had expected. I don't know why.
Maybe I should sit down in a corner and be quiet ;-)

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

My Homepage is just building up - first public version.

> 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 know what you mean.

> 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 went through the same process of non-understanding as you, lots
of mathematical formula in lectures and no practial connection.

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

I already have the fear of men in suits lining up before my front door.

Haven't you read the slogan of Kobayashi Maru?

"a free Space Fight Simulator for a free Universe"

This is also a joke connected to the name.
Let's see, which Universe is free...
... but I think that honorable Captain Picard would be quite shocked
to realise that he is private property :-)

In some day in the future, the men in suits will appear even in your
dreams and sue you for having used characters of popular series in
your thoughts :-(

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

Would be great!

> > 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!  :-)

_AND_ the idea of the borg is stolen from Perry Rhodan, they call them
'Posbis'

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

Sitting in the railway, playing a game _exactly_ like Elite?
No Problem!

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

With lots of objects it goes very high (yes,not very precise).
But I have yet models with far too much polygons and have no level of
detail (due to shortage of models) - I didn't look, is there a routine
like countPolygons(scene/entity)?

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

I read this on the plib page, but I hat a snippet of code that worked,
I will time it and probably change.

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

The text will even get more - the game is far from being 1.0.0 , and most
output is more or less debugging ;-)

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

Yes. But I am as bad in drawing images as for modeling.

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

I hope not much, compared to rendering time.

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

Some time I ago I tried to download/compile many 2D-linux games, and
some of them seemed to me to have exactly this feature, to compile
for different bitmap-handling libraries, and I wanted this feature.

Also, I could go and say, hey, here's KobScene, an open source
SceneGraphHandler, for whoever might need it.
It's also a possiility to benchmark different scenegraphs.
Just for interest.

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

Those objections have been already told to me bu a friend, but if you
imagine space as one giant room with no portals, how fast is the
part that renders this? Interesting question for me.

And: Quake, Quake, Quake, all people in my real life play Quake.
There are a lot of players, editors, engines - I just hope by 
saying - "hey, my game uses free quake" to attract those people,
especially the ones that design models to my game...

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

Bah!

I've checked their Homepage for over three months, it didn't change,
no bits of code. Nothing exept announcements.

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

Thanks... will check it.

You also wrote:

> Some corrections:
> 
>  * On 'requirements.html', you say that PLIB is "yet in developer
>    stage".  That's not true.  PLIB is in mainstream use now.
>    Every library gets developed after it's in mainstream use -
>    but you make it sound as though PLIB is still in 'beta' -
>    which it's not.  PLIB 1.2.0 is a 'stable' release.

This was written at the time when plib went in CVS and the loadXXX
functions were written, the appearance of 3ds models changed a
lot on my system. I was referring more to the loading of 3ds
models, I think. I'll correct it.

>  * I think it may be unfair to characterise PLIB as the source

No, it's the _third_ source:
   1. too many polygons due to bad (3ds-converted) models
   2. my own code (I know where I loose time)
   3. plib
   4. but there's no fourth ;-)

>    of your slowness.  You have no proof of that - and to the
>    contrary, there are MANY other games that use PLIB and
>    achieve high frame rates.  So, before you start telling

The problem is that I probably have _imagined_ a higher frame-
rate, and maybe I dream of having better models with a higher
framerate and can't understand why ... sniff.

>    people that my library is SLOW and that you are looking

But maybe it's just so that I think that a game like a Star-
Fighter game will have to be faster and more complex than
a game like Tux.
Actually, I've mo idea.

>    for a faster one - let's see why.  Personally, I accuse
>    all that text you are drawing.  Either way, I resent the

I will time that. And bite my ass if it's true.

>    implication from an utter novice.

I am a novice in 3D maths as well as GL as well as games programming.

If you look at the code, you'll find many really nasty things that
shouldn't clearly be like that, but I have to admit I am a lazy
programmer and tend to write first quick&dirty, and then improve it.
AND there are places in the code were I simply stopped , because
I had problems and wanted to write on another piece of code.

>  * On the math help page you say I'm an amateur - that's not
>    the case - I've been working as a professional 3D programmer
>    for 20 years.  I've designed PC graphics cards - I've written
>    commercial games software - SSG is my third or fourth
>    scene graph API...I forget.

Okay. Ashes on my head. Lot's of ashes. I hope you're non-smoker.

I am just starting to hope that you won't point out too many bad
codelines, please forgive a youngster.

> Some advice:
> 
>   The owners of the StarTrek copyrights are known for vigerously
> chasing people who infringe on their concepts.  Since there is
> a StarTrek book out with the title "#47 The Kobayashi Maru" by
> Julia Ecklar - you might want to think about whether you should
> change the name of your project.
> 
>   Sprinking names like "Borg" around will tend to enhance their
> interest in suing you - even though your game may have nothing
> to do with the StarTrek universe.

See above.

>   These are things that it's easy enough to change - and keeping
> it 'clean' of other people's intellectual property is really
> important for GPL'ed software.

There may come a time when it's necessary to say things like
   sed 's/KobayashiMaru/TuxFleet' `find .`
but I have chosen to wait.