Re: [Plib-devel] Re: KobayashiMaru & plib

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

Alexander Rawass wrote:

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

Yes - I understand - I'm really just trying to help!

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

Really!  I don't remember that.

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

Yes - it might just manage that at reasonable speed.  Wireframe would work well
and you wouldn't have to worry so much about Z-buffering.
 
> > 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)?

No - but you can easily hack one into SSG.

Look in ssgVtxTable.cxx - find the 'draw_geometry' routine and add up the
number of vertices and polygons right there - into a global variable somewhere.
 
> > 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.

If you ARE using GLUT text, I can tell you for *SURE* that that's the major reason.

Think about it.  For EVERY letter you draw, you are sending (say) an 8x10 pixel
rectangle of pixels to the frame buffer.  With full RGBA, that's 8x10x4 = 320 bytes
per character.  You are drawing a couple of hundred letters - so you are downloading
maybe 64Kbytes into the graphics card every frame - several megabytes per second
at reasonable frame rates.

On the other hand, if you use textures, you have all those letter shapes stored
in a texture map that's already down on the card.

More than that, many PC graphics cards have to 'flush' their polygon buffers in
order to allow the CPU to get access to the frame buffer - that can cause a major
stall in your CPU when you first start drawing bitmapped characters.

Anyway - this is a REALLY common problem for people who are doing this for the
first time.

Come to think about it - one of my FAQ documents is all about this stuff.

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

Well, I think you should stop and think about that.
 
> > 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.

  :-)

Write a program that does a 'glReadPixels' of the graphic you have now - save
it into a file that you can draw (as a texture) instead of the original.

You really *will* need to use some minimal painting skills before you are
done with this game.
 
> > 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.

Yes - but for 2D, that's necessary - you have console mode, SVGA, GGI,
X-windows, etc.

For 3D, there is exactly ONE low level standard for Linux...and most
other OS's - OpenGL.  Hence the need to be able to run on multiple
standards is almost zero.

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

I guess.  I'd do that at the outset of the project - then pick one
and run with it.

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

Well, in the end you are shoving polygons into OpenGL as fast as you
can.  Testing to see if there are other portals to clip against can
really only slow you down.
 
> 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...

Well - I doubt it.
 
> > 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.

I spoke to the guy who wrote it at SigGraph (actually - I think he's
subscribed to this list)...I think it has promise - although perhaps
not in the area that PLIB is intended for.
 

> >  * I think it may be unfair to characterise PLIB as the source
> >    of your slowness.

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

Well, probably:

     0. Bitmapped fonts - and LOTS of text.
 
> 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.

I doubt that you'll need as many polygons as Tux - at least
in deep space.  I guess if you are skimming along the surfaces
of planets then you have something more like a flight simulator...
like FlightGear for example...hmmm - I wonder what that's
written in?  (Hint: Begins with a 'P')

> Actually, I've mo idea.

Well, exactly - and that's why I resent you saying that PLIB
is
slow.  People who may be thinking of using PLIB will use a search
engine to look for other people who use it.  If they find your
page and it says PLIB is slow then they'll run a mile.

So - you have to be scrupulously accurate.  Your web page should
say "My game is slow - I don't know why."....So quit telling the world
that my library sucks - at least until you manage to show that it
really does suck - and in a way that we can't easily fix.

> >  Personally, I accuse
> > all that text you are drawing.
> 
> I will time that. And bite my ass if it's true.

Well - be careful how you time.  It's tricky to measure the time
to draw the text because you'll be unable to time the all-important
pipeline delays in the graphics hardware.

The best thing is just to comment it ALL out and see how much faster you
run without it.

It's possible that your other problems outweigh this one - but from
my experience, it's a MAJOR hit.

That's why I went to all the trouble to write the 'FNT' library. FlightGear
was getting *horrible* frame rates - due to just a couple of lines of text
in the HUD display - but you have DOZENS of lines of text.
> I am a novice in 3D maths as well as GL as well as games programming.

We were all there once.

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

That's a GOOD approach.

Don't optimise something unless it's going to give you a significant
speedup....and if you are doing it for free - do what YOU find interesting.
 
> Okay. Ashes on my head. Lot's of ashes. I hope you're non-smoker.

Yep.  There is no need to apologise - just fix the problems.

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

I don't have time to read your code - heck - I don't even have time
to read my *own* code!  Sorry.
 
> >   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.

Yep - that *could* work...but it may not be enough once you have
licensed a gazillion copies to people under GPL.  You could
be liable for (say) a $10 licensing fee for every copy you
gave away!  15,000 people downloaded Tux_AQFH.  Think about it!

We live in a litigous society...and the owners of the Star{Trek,Wars}
rights are amongst the nastiest of people to upset.  Just don't put
Mickey mouse ears and a Coke 'swirl' on your spaceships!

Good luck!

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