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

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

Hi,

Steve wrote:

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

The Posbis are positronical-biological robots, that means robots with
a bit of bioplasma as brain, whereas Borg are bio with machine implants,
but it is just 'the other way round', but in the end, it's all the same.

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

Maybe I'd need also something like
  ssg_entity=createLevelOfDetailFromEntity(int nr_of_polygons, orig_entity)

meaning a routine that takes and entity and tries to reduce somehow the
number of triangles in that entities, till there are (more or less) only
nr_of_polygons left or so.
There are some Modelers which have this feature, of course the results
look like shit, but as part of plibssg I could break down high-detail
models to low-detail, as long as I've got a shortage on models.

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

Now I'm timing the Huds, now I see, and I have even a new Hud (Radio_Display)
that displays lots of message, and the more messages, the slower.

As a novice, I wouldn't have thought of that - or at least, that it will
draw so much. Sorry.

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

I'll use puFnt as soon as I can.

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

No, I simply need a lot of people with great painting skills to help me
there  :-)

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

Good point.

> > 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'd rather want _them_ to do it for me, since I don't have time ;-)

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

But what happens, if the brave Starfighter Pilot lands on some weird
planet and has to rescue some mamsel by simply going afoot, it'd
be a chance to use all those quake-stuff for this subtype of
KobayashiMaru.

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

Is there anything yet available exept that announcement?

I'm tired of people building up a cathedral.
See OpenSG, see Parsec.

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

Not if I'm heading for BIG BIG action!

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

FlightGear will be the more realistic part of flying, while with
KobayashiMaru you can load a level from Tux and fly above/inside it,
now only with a starfighter, soon with a helicopter, then with
a non-realistic plane (action game type)

Are there any FlightGear developers reading?
I'd like also to include your 3D Terrain Rendering Engine in my game,
if it could be easy to access it like

   terrain.init(terrain_data_filename)
   terrain.draw(sgMat4 camera_position)

please show me a way to easy access the code, or write me a class
that does this thing for me.

Dear Steve, you should also be aware that at some time in the
future, your game Tuxkart will be playable from within KobayashiMaru
(but maybe with other focus).

This will be done by loading the tracks and buildings as 'world' object
into KobayashiMaru, extending SpaceObject to KartObject (routines MoveShip/PitchShip) that behaves like a Kart, write a KI KI_KartDriver that drives this
thing and - pop - KobTuxkart.
Exept that the drivers would have to care about the X-Wings diving down
on them ;-)

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

When you read this, I should have my homepage revised.

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

What you'd think I should do?
Tell sourceforge to stomp it all in, homepage, ftp, mailing list
and create it all new with new name, two weeks after opening?
I don't like that idea, I don't like your scenario either :-(

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

Moment - thank you very much for showing me how to make money with
my game :-)

IF I probably contact Coke and Disney and tell them - "Would you
like to sponsor me?", they'd probably give me money to do exacly like
that, and you'd wonder how much advertisement you'll see in space ;-)

Please be aware that I'm only joking.



Alex