plib-devel

RE: [Plib-devel] KobayashiMaru & plib

[Dave M. <Dav...@dy...>]

i peeked at puScrollList.  i just added something very similar to plib.
take a look at the latest plib in CVS...

if you select "SAVE" on the menubar in the examples/src/pui/complex.cxx test
program
it brings up a listbox that might work for you

good luck with your app
--Dave

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

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

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

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

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

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

Alexander Rawass wrote:

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

The *trendy* way to do this is to collapse triangles by moving one vertex
of the model to the one next to it - then removing all the zero area polygons
that result.

You decide which vertices to 'collapse' in this way as an offline process - choosing
which vertex of the model is least visually important - so you collapse that first,
then work gradually into the more and more 'important' vertices.

Finally, sort your vertices in a vertex array so that the first one in the array
is the most important, and the last is least significant.  You can do the same
thing with the 'index' array - so that polygons that are deleted first are at
the end of the array.

Choosing 'importance' is a 'black art' - but is do-able automatically - at least
to some degree.

It would be cool to derive a class from ssgVtxArray to do this...although the
automatic vertex-importance selection code would need to be an external program -
which begs the issue of what file format to use... ".SSG" I suppose - that's
extensible so you could extend it to do what you need for your new class.

*NOT* for beginners.

For the first step, figure out how big your model is - and work out at what
range it'll be (say) less than 3 pixels across - and switch it out into a
simple tetrahedron of an appropriate colour (4 triangles - one triangle-strip).
Figure out the range at which it'll be less than one pixel - and throw it away
altogether at that range.

Use an ssgRangeSelector node to do that - and you'll see an immediate improvement
(I suspect).

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

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

S'OK - that's why we are here to help!

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

That'll help - but:

  a) puFnt text can be fuzzy at small scales.
  b) it's still two triangles per character - so 200 characters on-screen
     is 400 poorly-tristripped triangles.

I think you should consider VERY carefully how much text you need to display.
Can you only display ship stats when the thing is clicked on or something?

Can you freeze the action while they read "radio" messages - or scroll them
slowly across a small region of the screen so you can only see a handful of
characters at a time...that can actually look rather cool.

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

You have to be realistic.  THAT'S NOT GOING TO HAPPEN.

THere have been long threads on the LGDG (Linux Games Developer Group) about
the lack of motivated artists who'll work for nothing.  Response from the
artists strongly suggests that what few of them WILL help are not likely to
jump into just any project - they are going to look for projects with experienced
programmers with a proven track-record.

Even if you did find such a person, they are not going to be your 'art slave'. You
won't gain much support if you say things like "Paint me a radar display that's
64x64 pixels, translucent and looks like a spider-web".  If you are *REALLY*
lucky, you may find an artist who will be interested in designing things like 
spaceships or big-breasted aliens women with three heads and forked tongues...but
they are unlikely to be interested in doing these kinds of silly little jobs.

You just need to practice and learn GIMP.  It's not that hard to draw things
like instruments, little icons and such like.
 
> > > 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 ;-)

*NOT* going to happen.  You need a dose of realism.

Let me tell you about Tux-A-Quest-for-Herring.

It was the first *ever* 3D game for Linux.  I was 'slashdotted' *TWICE*
(once when I released initial screenshots and again when the game
was ready for release).  I've had 5-star ratings (the best possible)
on every review site I know of (TwoCows, HappyPenguin, etc)..every major
Linux distribution has it on their CD...so I have to imagine that people
generally like it a lot.

I got:

  150,000 people visiting the web site over the first 12 hours.
   15,000 people downloaded it in the first 12 hours.
    1,500 emails complaining/complimenting/thanking me for TuxAQFH
          within the next week or so.
   ...one year later...
      150 people are subscribed to the Tux mailing lists.
       15 people have *ever* offered to help with artwork/music/models.
      1.5 (OK...2 actually) other people have actually contributed
          *anything* to Tux *ever*. One piece of unusable music - and a
          couple of unusable models.  No significant chunks of code at all.
    *NONE* of those things has ever been useful enough to distribute with
          the game.

Now, *you* won't get slashdotted - they don't report freeware game releases
anymore.  So, how many people do you think will be helping you at the end
of the day?
 
> > > 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.

But do you really believe that as a beginner 3D programmer, you will manage to
write a single game that spans deep space PLUS flight sim PLUS hand-to-hand
combat and integrates all those seamlessly?  Not one single game throughout
the entire history of game making has ever been that ambitious.  Not one.
Remember that *very* likely you'll be doing it single-handedly with no
artistic or music input?

I don't mean to try to put you off - but

a) Be realistic about what you can achieve in reasonable time.

b) Know your limitations.

c) Start with something small - and you *might* get it finished
   to the point where it's playable.

It would be better (IMHO) to concentrate on making a good space
game - and forget (for the moment) about the other things.

Remember - it took 100 people working full-time 5 years to create
Mario'64.  You have about three times that amount of work.  You should
be finished in about 1500 years.
 
You are still learning the basics like matrix algebra and that text
is S-L-O-W.

> Are there any FlightGear developers reading?

Several.

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

The 'terragear' spin-off project is like that - but if you are
planning to have things zoom around at several times the speed
of sound, you'll need a LOT of terrain.  Many, many megabytes.
 
> 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).

OK...maybe.  TuxKart is a VERY simple game...4,000 lines.
 
> 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.

That's *VERY* naive.  Have you thought about collision detection yet?

Scale down your rhetoric until you've done it.  You are a *classic* newbie
who understands just enough to think they can take over the world.  When you
have a couple of *finished* 3D games done, come back and tell me how easy
this *actually* is!

> What you'd think I should do?

Look before you leap!

> Tell sourceforge to stomp it all in, homepage, ftp, mailing list
> and create it all new with new name, two weeks after opening?

Yes - what do you have to lose?  Changing the name everywhere and
deleting the references to X-wings and such won't be more than
a couple of hours work - open a new sourceforge account under the
new name copy everything over - then tell their support guys to
dump the old site because it's been superceded.

> I don't like that idea, I don't like your scenario either :-(

Well - it's your call.

It could be worse.  I dumped an entire game (Harry Potter/Quiddich)
when I got 'cold feet' over the legalities after the book became a
phenomenal success and they announced a feature film!

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

Have you seen the adverts in TuxKart's first level?  Look at them
*carefully* and wonder how I chose them!  My lips are sealed.

> Please be aware that I'm only joking.

I'm not!

-- 
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] Re: KobayashiMaru & plib

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

Steve wrote:

>Finally, sort your vertices in a vertex array so that the first one in the array
>is the most important, and the last is least significant.  

Yes. A friend of mine wrote a program using software-rendering a long
time ago that also sorted the polys according to importance. Each
frame, when the "time slice", for example 1/50 of a second, was up, it
simply stopped rendering. This is not like LOD, since the unimportant
polys were simply missing, there were holes. Still, it looked very
good, even if half of the polys were thrown away.
He did this only when the scene or the camera changed, and rendered
the complete models once everything was static. The program was
similar to PPE and he could draw the 3D-cursor without rendering the
rest (when drawing the 3d-cursor, he saved the pixels underneath).
Anyway, I guess THIS method (not LODs though) is slightly outdated.


>THere have been long threads on the LGDG (Linux Games Developer Group) about
>the lack of motivated artists who'll work for nothing.  

This could lead to a thread about which professionals might work for
nothing :-). I am not sure there are many besides programmers.

>Response from the
>artists strongly suggests that what few of them WILL help are not likely to
>jump into just any project - they are going to look for projects with experienced
>programmers with a proven track-record.

Of course. Artists can choose their project and they want to
participate in successful projects, so they will choose.

>If you are *REALLY*
>lucky, you may find an artist who will be interested in designing things like 
>spaceships or big-breasted aliens women with three heads and forked tongues...but
>they are unlikely to be interested in doing these kinds of silly little jobs.

Yes. Yesterday I was at an ex-artists (we call them technical
draftsman) of ours who now works free-lance (sometimes for us). He is
prepared to work on a free project if he has time. But "only" to learn
new stuff that will advance him and that the industry needs. The
biggest need in the game and film industries seems to be characters
(humans, monsters, animals etc), so if he would do sthg it would be
characters.
BTW, I was there to look at things in 3D Studio that we might use in
PPE, more on the PPE list.


>Let me tell you about Tux-A-Quest-for-Herring.
>
>It was the first *ever* 3D game for Linux.  

Yes - a very interesting thing. I would probably have contributed if I
had heard about it beforehand, but I was not in the linux community.

>I got:
>
>  150,000 people visiting the web site over the first 12 hours.
>   15,000 people downloaded it in the first 12 hours.
>    1,500 emails complaining/complimenting/thanking me for TuxAQFH
>          within the next week or so.
>   ...one year later...
>      150 people are subscribed to the Tux mailing lists.
>       15 people have *ever* offered to help with artwork/music/models.
>      1.5 (OK...2 actually) other people have actually contributed
>          *anything* to Tux *ever*. One piece of unusable music - and a
>          couple of unusable models.  No significant chunks of code at all.
>    *NONE* of those things has ever been useful enough to distribute with
>          the game.

Wow, that's even worse than I thought :-(. It seems many want to start
a new project (see all the modelers on Sourceforge) and few want to
contribute to the project of other people :-(.

>Remember - it took 100 people working full-time 5 years to create
>Mario'64.  You have about three times that amount of work.  You should
>be finished in about 1500 years.

Well, out of the 100 people there are many managers, advertisement
people, manual writers etc. 
But of course it is not possible to compete with the commercial games
writers except MAYBE under the best conditions (many knowledgable
contributors with much time and motivation that work together well)
or of course by programming simple games that work because of the
idea, a la Tetris.


Bye bye,
Wolfram.

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

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

Wolfram Kuss wrote:

> He did this only when the scene or the camera changed, and rendered
> the complete models once everything was static. The program was
> similar to PPE and he could draw the 3D-cursor without rendering the
> rest (when drawing the 3d-cursor, he saved the pixels underneath).
> Anyway, I guess THIS method (not LODs though) is slightly outdated.

It's not even legal in OpenGL.  When you do a 'swapbuffers', the contents
of the back buffer are "undefined" - which means that you can't rely on
the previous image still being there...which indeed it isn't on some
machines.


> >Let me tell you about Tux-A-Quest-for-Herring.
> >
> >It was the first *ever* 3D game for Linux.
> 
> Yes - a very interesting thing. I would probably have contributed if I
> had heard about it beforehand, but I was not in the linux community.

I didn't really publicise it until it was more or less playable.

I have a lot of fun working on these games - and to start with, I
don't *want* help...that just increases the hassle factor and reduces
the fun.

Once the game is basically working, it would be nice to get help - but
I no longer have illusions about that.

Oliver and I had just finished playing Mario'64 (yep - all 120 gold stars)
and were disappointed that there wasn't any more.  We fondly imagined
that if we built a good game 'engine' and a couple of demo levels, we
would have hundreds of OpenSource level designers building new levels.

Hence we'd end up with a game we could play *forever* without ever
getting to the end.

Well, I'm less naive now!
 
> >I got:
> >
> >  150,000 people visiting the web site over the first 12 hours.
> >   15,000 people downloaded it in the first 12 hours.
> >    1,500 emails complaining/complimenting/thanking me for TuxAQFH
> >          within the next week or so.
> >   ...one year later...
> >      150 people are subscribed to the Tux mailing lists.
> >       15 people have *ever* offered to help with artwork/music/models.
> >      1.5 (OK...2 actually) other people have actually contributed
> >          *anything* to Tux *ever*. One piece of unusable music - and a
> >          couple of unusable models.  No significant chunks of code at all.
> >    *NONE* of those things has ever been useful enough to distribute with
> >          the game.
> 
> Wow, that's even worse than I thought :-(.

Yes - it's kinda depressing.

What suprises *me* is that there are LOTS of contributors to PLIB and
LOTS of people working PPE - but *nobody* wants to contribute to the
games.  I expected the reverse.  Games are fun to write - and do great
things for one's ego and popularity - I'd have thought there would be
WAY more contributors than for a boring support utility library.

Well - I guess not!

> It seems many want to start
> a new project (see all the modelers on Sourceforge) and few want to
> contribute to the project of other people :-(.

I guess that's it.  Perhaps people contribute to PLIB so that they can
write their own games.

That's a little unfortunate because it makes it hard to write really
complex games when only one person is involved.

> >Remember - it took 100 people working full-time 5 years to create
> >Mario'64.  You have about three times that amount of work.  You should
> >be finished in about 1500 years.
> 
> Well, out of the 100 people there are many managers, advertisement
> people, manual writers etc.

True - but still, at least a third of that effort must have been
programmers, musicians and artists...so 500 man-years then!

> But of course it is not possible to compete with the commercial games
> writers except MAYBE under the best conditions (many knowledgable
> contributors with much time and motivation that work together well)
> or of course by programming simple games that work because of the
> idea, a la Tetris.

I have a personal hatred of Tetris.  The last time I counted, there
were 23 versions for Linux - of which about 20 were a complete waste
of human effort!

  Blocks CXHextris Columns fscktris Ltris CrystalSpace-Tetris
  GTetris JTetris Jetris Stax Quadra Tetrinet TwinTRIS VGA-Tetris
  XBlockout XJefris XJewel XTrojka Xemeraldia Xinsane Xpuyopuyo
  Xtet42 Xtris

-- 
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] Re: KobayashiMaru & plib

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

Steve wrote:

>It's not even legal in OpenGL.  

Interesting. Anyway, it was using his own software-renderer, not
OpenGL.

>I have a lot of fun working on these games - and to start with, I
>don't *want* help...that just increases the hassle factor and reduces
>the fun.

Ah, I understand.

>We fondly imagined
>that if we built a good game 'engine' and a couple of demo levels, we
>would have hundreds of OpenSource level designers building new levels.

Yes, strange it didnt turn out that way. Maybe there are too many
commercial games where you can create add-ons that draw away people
who like to do this.

>That's a little unfortunate because it makes it hard to write really
>complex games when only one person is involved.

Very true.

>True - but still, at least a third of that effort must have been
>programmers, musicians and artists...so 500 man-years then!

Yes. 

Bye bye,
Wolfram.

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

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

Alexander wrote:

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

I think it wont be faster, probably even slower than other methods. 
The optimizations (portals) don't work. It is known even some Quake
levels that are not well suited for a portal engine are fairly slow.

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

Quake models can be converted and imported into plib (but I haven't
tried it), so people creating Quake models can contribute to your
project even if it doesn't use the Quake engine.

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

Like Steve said already, you should check out what part of your
program costs how much time. Turn off all drawing, then just the text,
then just the lines, then just the rest, then maybe parts of your code
(I don't know how complicated, for example your AI, err KI is).

Bye bye,
Wolfram.

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

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

Wolfram Kuss wrote:

> Quake models can be converted and imported into plib (but I haven't
> tried it), so people creating Quake models can contribute to your
> project even if it doesn't use the Quake engine.

There is a Quake model loader that comes with Performer - and *most*
of the Performer loaders come with source code (although that source
isn't always "free" in the "free speech" meaning of the word).

Since Performer and SSG share a certain family resemblance, you could
probably use the Performer Quake loader as a guide to writing such a
thing for SSG.

-- 
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] Re: KobayashiMaru & plib

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

If someone wants to load Quake models into plib without programming,
he can use 3D exploration on Windo$ (40$) or can send me the files and
I will try to convert them.

Bye bye,
Wolfram.

Re: [Plib-devel] KobayashiMaru & plib

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

Hi,

> i peeked at puScrollList.  i just added something very similar to plib.
> take a look at the latest plib in CVS...
> 
> if you select "SAVE" on the menubar in the examples/src/pui/complex.cxx test
> program
> it brings up a listbox that might work for you

Great! I'll look at it when I have time.

Alex