plib-devel

[Plib-devel] ulNet Class

[tjones <tj...@is...>]

Hello=20

I was wondering if theres been any word on if steve is going to commit =
the class to CVS, also I was thinking about creating a new directory for =
the networking code instead of just adding it to utils.=20
I have started working on the tcp code and hope to have something =
shortly.=20

Thanks Ben Woodhead

Re: [Plib-devel] PLIB developers needed.

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

Dave McClurg wrote:
> 
> Christian wrote:
> > But anyway, do SG and SSG brake with that compiler? If the answer is no,
> > that is compiler supporting costs. SG *is* const correct and at least
> > half of SSG (IIRC).
> >
> I went to fix the 'const' methods in ul.h that are *not* portable on IRIX
> when I noticed there were similar 'const' methods already in sg.h like
> Christian says.  The 'const' methods in sg.h have been there for a long time
> and must work on IRIX.

Weird?  That particular program didn't use sg.h - but I'll try it when I
get back to work on Monday.  I havn't tried to recompile PLIB on our ONYX
using the native IRIX compiler (I know it works under GNU G++ under IRIX - but
that's not the point).

>  Perhaps we just need to change
>         'double getRawTime () const ;'
> to
>         'double getRawTime (void) const ;'
> and it would work on IRIX.  Seems to be something strange like that.  Do you
> want to investigate Steve?

Yes - I'll look when I get into work on Monday - I don't have a our $5,000,000
ONYX-2 here at home  :-)

Interestingly, I was using ul.h to measure some benchmarks between GeForce-2
($300+$2000 for the 800MHz PC) and ONYX-2 ($100,000 per graphics 'pipe'+$200,000
for the computer itself) - the GeForce is comfortably beating the ONYX by about
2:1 on polygon throughput and about the same on pixel fill rates!  Even if you
turn on the antialiased rendering (The ONYX's main selling point) - the ONYX is
still only about equal to the GeForce on polygons although it does beats it by
about 2:1 on pixel fill.

**WOW**

-- 
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] PLIB developers needed.

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

Christian Mayer wrote:

> > It didn't even get through the ul.h header.  There was no other code
> > involved apart from standard UNIX headers prior to that point. Also,
> > the program compiles just fine under Linux - so there isn't
> > anything wrong with my code.
> 
> Just that it compiles under one system doesn't say that there's nothing
> wrong with it.

You misunderstand - none of my code has entered the compiler at that point.

The source file says something like:

  #include <stdio.h>
  #include <plib/ul.h>

  ...more stuff...

..and the compiler barfs inside plib/ul.h  when I remove the const from
within the function definitions....


   int getWhatever () const { return whatever ; }
                      ^^^^^
                      here

...it compiles and runs just fine.

> I don't know what causes it (I don't know any of the affected code). So
> it might be your code or it might be the code in the ul.h or perhaps
> even something totally different. I don't know it. So I'm not saying
> who's guilty.

It's not a matter of guilt.  Putting a 'const' right there is OK in
sufficiently modern C++ compilers - it fails in older ones though - so
we can't use that construct and remain 'sufficiently' portable.
 
> > We are looking at a use of 'const' that is in a more recent C++ spec
> > than IRIX supports (this is just like the declaration-inside-a-for-loop
> > issue for MSVC).
> >
> > If we want our code to be portable, we have to forgo some of the
> > fancier features of C++ in order to get through the lowest-common-denominator
> > of all C++ compilers.
> 
> I allways thought that const was one of the most basic C++ features.

It is - but not *there*.

  const float pi = 3.14159 ;                      -- OK
  int func ( const int &x ) ;                     -- OK
  int getWhatever () const { return whatever; }   -- NOT OK

> But anyway, do SG and SSG brake with that compiler?

This program only happened to use UL...but SG and SSG don't (AFAIK)
use const in *that* context.

> If the answer is no,
> that is compiler supporting costs. SG *is* const correct and at least
> half of SSG (IIRC).

Well - not exactly.  The number of places where the keyword 'const' can
be stuck has grown steadily over the life of C++ - and some of the later
ones simply aren't universally supported.
 
> No matter where it compiles. As soon as it doesn't compile on one
> (reasonable) system make it intolerable.

Exactly...unfortunately.
 
> But you can't cry and say 'ban all consts' just because you trip over
> one that doesn't work - w/o really knowing if it's the const that causes
> the problem or if its breaking the compiler just because the real
> problem (probably a forgotten const) stays unnoticed.

I don't really want to ban them all - just that particular usage (and
any others that we might find will break compilation on important
platforms).

One might argue about what platforms are important enough to warrent
dumping language features that are useful.  However, IRIX is defined as
'important' because (selfishly) "PLIB is mine and I use IRIX"

  :-)

If a similar question came up about compiling for (say) AmigaOS - the
answer *might* be different!

Personally, I think a minimal supportable OS set for PLIB is:

   Windoze (all versions NT/95 and later (except possibly, Wince) - using
            at least MSVC++, Borland and Cygwin)
   Linux   (2.0.0 and later)
   BeOS    (?? versions)
   BSD     (Including NetBSD, FreeBSD, etc)
   MacOS   (?? versions)
   IRIX    (6.0 and later)
   Solaris (?? versions)

...I'd consider supporting SCO Unix and HPUX also...but if we had to make
significant language restrictions to make that work, I'd want to think twice
about *that* decision.

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

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

Wolfram Kuss wrote:

> One advice if you want to become a good programmer and see things more
> realistic (which can be frustrating):
> Before you do things, guess how long it will take. Then, after you
> have done it, you can compare. Being able to guess fairly accurately
> how long something will take is an important skill for developers.

It certainly is.

I'm conscious that I always underestimate times for things.  I realised
this after a while - and my managers at work realise it too.  We have
come to know that if you double the amount of time my 'gut feel' tells
me, it'll be reasonably accurate.

Now, when I talk about project schedules and stuff, and I tell them
how long something will take - they say "Is that figure before or
after we've doubled it?"

But Wolfram is dead right - finding the value of your own personal
"effort multiplier" is a vital thing for future programming success.

I'm beginning to realise though that the multiplier I use at work is
not the same as the one I should use for 'homework' activities.

> >> > I have come to the conclusion that all these games are 'the same'.
> 
> Some time ago Steve wrote a great post either here, in plib-users or
> in the ppe-mailing-list about the different needs that different games
> have for cameras. I didn't find it, maybe you will find it in the
> archives.

It might have been on the TuxAQFH or TuxKart lists - I don't remember.
 
> >But show Tux to a person who pays 80DM for a commercial game and
> 
> Huch ;-)
> 
> >is used to graphics like Quake3, he will probably just laugh and
> >say 'yoz gfx sukkz' or so.
> 
> And you really think you can beat many commercial games??

It's almost impossible I think.  Looking at the 7.2 billion dollar turnover
in the games industry and the 7.4 in Hollywood movies, then factoring in
the 10:1 failure rate of movies and the 35:1 failure rate for games, you
may guess that the development cost for a commercial game could be perhaps
a third of a Hollywood movie - that's probably around 3 million dollars?

Competing with that as a single person - not even working full-time and
lacking art and music skills and all the fancy software packages like
Maya and 3D-studio-MAX....I don't think so.

Even if we could compete - the idea of having to write 35 bad games to
get one good one is kinda depressing!

> And Steve didn't say the problem was that terragear is unsuitable. He
> said that to get good frame rates you have to tweak the game design,
> that is, you cant have a universal game engine with todays hardware.

...or ANY hardware EVER.  The problem is that people's expectations
have gone up as the hardware gets better.

Elite was a *great* game in it's time - but now, people wouldn't even
bother to download it - even if it was free.  Monochrome Wireframe
graphics - YUCK!

As fast as CPU's are speeding up, people's expectations are speeding up.

When I started writing TuxAQFH, the Mario-64 style of 3D graphics was
concidered AWESOME - by the time I'd finished writing it, Quake was
considered AWESOME.  You couldn't sell a FPS game without lightmapped
lighting and shadows these days.

Soon, you won't be able to sell one without volumetric fog/smoke, without
skeletal animation, real world physics, VIPM, ROAM, etc, etc.

The best chance we amateur developers have is to try to write something
small enough and lightweight enough so that by the time it's done, it
only looks *one* generation out of date - and people will want it because
despite looking out of date, it's free.

I could manage to write TuxAQFH in 18 months or so (single-handed) because
my hardware is 10x faster than a Nintendo-64 - and I could take horrible
shortcuts. Only build 7 levels instead of 20, only have MOD music, have
no splashes when Tux jumps into the water, etc, etc.

TuxAQFH isn't anywhere near a nice as DonkeyKong (the 'next generation
Mario64' game), but I still have people email me photos of their kids
playing it, send me free stuff (I got two free graphics cards, three
Tux plushies, a book about Penguins, several Tux tee-shirts...), I get
'kudos' (MANY people came to talk to me at SigGraph who would otherwise
have not known who I was). It was fun to write - and (mostly) not a
chore.  It was a nice change from work.

I feel like it was worth that amount of time.

IMHO, the more grandiose your plans, the more pathetic they will look
by the time you ever get them to the point of playability.

* I could write a really simple game with Quake-III quality graphics in
  perhaps a year...and in about a year, the faster graphics on machines
  of that time will mean that although I don't spend as long on optimisation
  as Carmack and crew do, it'll still run fast enough to be playable. The
  game would be only one year out of date - and people would *love* it.
  I could make a contribution - and get some recognition - and have something
  cool to put on my resumee.

* If I tried to make it a complex game - better than Quake III, it would
  take me 5 years to write it and by then people would laugh at it because
  they are all playing QUAKE VIII or so. More to the point, after about 3
  years, I'd realise that what I was writing was crap by the standards people
  measure computer games - and I'd lose interest and abandon the project - 
  having wasted 3 years of my life in the process.

The only way around this depressing scenario is to get a LOT of people
together to write a freeware game.  That would let you work at the
pace of a commercial games company and get the work done.  The problem
is that some of those people need to be artists and others musicians,
level designers, play-testers, etc, etc.  Since ONLY us programmers
are stupid enough to work for nothing, we don't have any vastly
successful large-team games...although we DO have vastly successful
large projects of other kinds (Linux itself, GIMP, G++, Apache, etc).

Tuxkart is ten times (literally) simpler than TuxAQFH, it took less
time to write and is more fun to play.  My next effort will be more
like TuxKart and less like TuxAQFH.  My kid wants Tux-Golf (a 3D
crazy-golf game)...I'm not so sure.

If I can find some good artists (who actually CONTRIBUTE something
rather than just talking about it)...then I may go for something
more sophisticated and try to get a team together to do it...but
I'm guessing that this won't happen.  One approach may be to find
some 3D artists who are already doing free work - and latch onto
that:

   http://major-damage.com

...for example. (This is a group of artists making a non-realtime
3D cartoon in their free time - just for the fun of it). If perhaps
they could be pursuaded to *give* me the artwork - and perhaps make
a few other things we might need for a game - then I would be
interested in getting together a team of maybe 3 or 4 programmers
and trying to make a STATE OF THE ART game of a Mario-64-like
Genre.



> Sigh, I didn't want to invest this much time, but once you start
> writing you don't want to stop midway.

I know what you mean!

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

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

Alexander Rawass wrote:

> > Start simple.  Design one game in one genre.  Just wait and see what
> > actually comes to bite you.  Simple things like collision detection,
> > best use of the Z buffer and where to place the camera are unbelievably
> 
> I don't have any idea about any Z-Buffer - in my opinion, thats your
> part. Tell me how to use it - or just gimme some url doing this.

Well, the problem is that the precision of Z (for hidden surface resolution)
is finite - and (at least on some graphics cards) only just barely usable.

Within one genre of game, you can work on that and find an acceptable range.
But if you tried to do:

* A deep space game - where you need ranges large enough to display
  entire planets but fortunately, you can treat things that come within
  a few klicks specially. ...AND...
* A flight sim - where you need ranges only out to perhaps 100km - but objects
  don't really get closer than perhaps 3 or 4 meters - so you can manage it.
  ...AND...
* A first person shooter where you only need ranges out to perhaps 1km - but
  you need to resolve Z down to a centimeter precision all the way in to maybe
  10cm.

Each one of those is do-able.  Putting all three into one game is impossible
without some MAJOR engineering effort to switch models, switch rendering paradigms,
etc.
 
> The point is: if I'm going to concentrate on this one genre, I might
> write a good game - and get stuck with it.

You can always write another one once you've finished the first one.

> I have LONG LONG thought about howto write this Starfighter game
> (version 1.0.0) in a way that it can easily extended to v2.0.0 in
> some time, but if I would concentrate to this one genre, I had to
> completely re-write code and classes to expand it.

You'd have to do that anyway because (as I'm *still* trying to tell you)
you can't use the same game mechanisms at all those scales and with all
those genres.  You have to employ different dirty tricks at each level.

You could *try* to write all the dirty tricks for all the genres into
all the classes - and then somehow switch between them - and switch the
models - all at the right time to make it seamless - but it's known
that doing that is beyond the abilities of even the largest professional
programming teams - who understand ALL the dirty tricks and how they
interact.

You are probably going to try to tell me that you'll program it all without
any dirty tricks - but I'm telling you that to make convincing 3D images
AT ALL requires a large collection of dirty tricks.
 
> >  or  "How do I allow space ships to
> > fly into holes in asteroids - as well as have people stay stuck to
> 
> When a Starfighter flies into a hole in an asteroid, there will be sort
> of portal and he will get connected to a KobayashiMaru mission
> server playing the inside_asteroid Mission.

In other words you basically throw out one game of one genre - and load
up another.

You need different artwork for the same area of the asteroid - all those
artworks have to look about the same at different scales from orbit
down to low-level "flight" down to walking around in a space-suit.

That's an amazingly tall order.  Also, you'll get cross-over effects
from the various games genres.

The guy walking around on the terrain in his space suit sees a space
ship flying down about to shoot at him.  At his scale of game, he sees
a 10 foot high rock - he runs and manages to hide behind it!  "<Phew>...
I'm safe now!" he thinks.

Meanwhile, the game engine for the space ship level of game is hurtling
him along at mach 3 over the surface - there isn't enough memory or
graphics bandwidth to draw rocks as small as 10 feet high - so the
pilot is suprised to see the lone guy crouched down in the wide open
space of the asteroid!

Meanwhile, at 'deep space' scales, there is a field of asteroids - most
of which are too small to render at the scale of this 'genre' of game.

...you see it's practically impossible to blend all these scales
seamlessly and still make a good game.

> At that moment, calculation gets done by another engine, and the people
> on the ground wont see it again until it comes out of another
> portal.

Won't work - there will be too many 'crossover' events between the
scales.
 
> > the ground - and at the same time allow missiles to collide with
> > 1,000 polygon spacecraft models"....remember my words.
> 
> If the spaceship is so near that is makes sense to let you see
> all 1.000 polygons, it's probaby so near that you wont even have
> to think about drawing something other.

I wasn't talking about what you *draw* I'm talking about what you
*collide* with...VERY DIFFERENT!
 
> > A fancy game engine without good graphics will be *terrible*.  Good
> > graphics consume 95% of every game development team's time, 95% of
> > the time in the CPU, 95% of the disk space the game consumes.  If the
> > graphics suck - you are back to writing games like Tetris that don't
> > *need* fancy graphics.
> 
> How would you rate the graphics of your game?

About 50% of what they could be.
 
> I think that it's one of the cutest little open source games I've ever
> seen, and that the graphics are great, compared to other open source
> games.
> 
> But show Tux to a person who pays 80DM for a commercial game and
> is used to graphics like Quake3, he will probably just laugh and
> say 'yoz gfx sukkz' or so.

But Tux shouldn't be compared with Quake. It should be compared with
games like Mario-64, DonkeyKong, Spiro, etc.

IMHO, Tux's graphics are as good as Mario - not as good as DonkeyKong.

For TuxKart, I deliberately modelled two tracks that are nearly
identical in 'look' to two tracks in MarioKart-64.  I have to say
that "Tux Tollway" looks *MUCH* nicer than "Toads Turnpike" - the
textures in my version are nicer - I have more detail in the track
than Nintendo do, etc.

> No-one of them will play yours or mine.

No - but 7 to 12 year old kids (who enjoy Mario'64) think Tux_AQFH is
pretty good.
 
> > > No one will of course play such a game, exept the Linux-GPL-Freaks,
> >
> > ...not even them.
> 
> I do not know a single person other than me to have a working
> hardware 3D installed, although other could but - why shutdown
> Windows, just to start Quake under Linux - no way for them.

Facts:

* 15,000 people downloaded TuxAQFH in the first day after it's release.

* So far, 50,000 people have downloaded TuxKart - although some of those
  may have been reloads when more recent versions came out.

* 5% of Quake players use Linux.

* In a recent (6 months ago) survey on happypenguin.org (a place where
  only Linux gamers hang out) - 80% of people who voted have a 3D card
  that works under Linux.

* "If you build it they will come." - MANY people boot into Windoze to
  run games - but would prefer to stay in Linux if the games existed.
  Many more die-hard Linux users would buy a 3D card if there were
  more 3D games to use it for.

...there are plenty of potential users out there.

> I will be my best player, that I know for sure.

If you get the game playable - and promote it to places like happypenguin,
I think you'll be amazed at the number of people who play it...but disappointed
at the number who contribute.
 
> An actionbased flightsim doesn't need realism or accuracy
> at that high rates of speed.

(Remember that I design flight simulators for a living - and
get paid six figures to do it - and now I'm telling you...)

          You couldn't be more wrong.
 
> It could of course be that FightGear/Terragear is unsuitable
> for my means, because they are rendering too good and not
> suitable for this type of game, so I'll have to look elsewhere.

Perhaps.

> > But collision (at least at the scale of ground-based simulation) requires
> > knowledge of where every single polygon is.  You can't do that without
> > plibssg.
> 
> Yes.
> At the moment, collision checking is done on 'Shield' level, meaning
> an impact in a sphere around the ship - this can be done without.
> The future will give collision checking on 'Hull' level, when the
> Shields are down - this will be done with plibssg.

Exactly my point.  Collision with simple bounding spheres ("Shield level")
is *fine* for a space game.  But at other levels of play, you need other
tricks.

In TuxKart, I know how far around the track each car is in "track space" -
cars that are not close in track space cannot possibly collide - even if
they are nearby in "world space".  That's a typical dirty trick that a
*racing* game can use to help things along...but a generic engine can't
DO that.  An utterly generic game engine cannot ever implement TuxKart
anything like as well as TuxKart does.
 
> > > The same collision checking will work for cars - only, that the cars are
> > > limited in z axis to the HOT they're on.
> >
> > Not good enough.  How will you detect when the car goes under a bridge?  Or under
> 
> When a CarObject is inside the radius of a StaticGroundObject, further
> collision checking is done with plibssg.

A car is *always* within that range of *some* static ground object.  There are
Armco crash barriers on both sides of the track.
 
> > What happens when your speed is so high that at the start of the frame you
> > are cleanly on one side of a brick wall - and at the end of the frame you are
> > cleanly on the other - you *should* have hit the wall on the way - but does
> > your algorithm solve that?  Efficiently enough?
> 
> Nope. This is _exactly_ a problem I already have.

Exactly.
 
> possible solutions: i) more framerates by
>                        models with lod
>                        changing the fonts
>                        optimising my code a lot
>                     ii) a mathematical algorithms I yet have not the
>                         slightest idea of.
>                     iii) run the KIs that steer in the ship in a
>                          'minimum speed' in a seperate task, when
>                         neccessary leaving frames to display off
>                         to have cputime for the engine.

Well, in TuxKart, I do collision detection for every half meter the car travels
during the frame.  Since the cars are a meter across and can travel only a
few meters per frame - this is do-able.  Translating that to something like
your ships moving at 100meters/sec (pretty slow for a spacecraft), would
probably work - but at many times the speed of sound - it'll cause you to
spend 90% of your CPU time doing collision detection.

Each genre needs a different scheme to do it efficiently enough - but with
only as much precision as that genre needs.

For kart racing, intersecting the sphere around the kart with the terrain
is perfectly acceptable. For Quake, it would *suck* and other tricks are
needed.

> > Think you can solve that?   Now apply that algorithm to a spaceship going at
> > 0.8 times the speed of light towards another spaceship on a collision course.
> 
> Actually, we're not flying that fast, exept for hyperspace.
> A normal starfighter makes 1km in 10secs
 
360kph?  The Cessna's in FlightGear go faster than *that*!

A 1970's F16 fighter can go about 5 times that speed.

The space shuttle (when in orbit) has to orbit the earth ever 72 minutes.

> > Done that?  Now worry about how our heroin can get into a small space if she
> > crawls - but not if she's standing up.  What happens if she crawls into a
> > passageway that GRADUALLY gets smaller until she can't fit anymore?
> > What happens if you are walking along parallel to a wall - carrying a long
> > weapon - and the player pushes the joystick to turn in to face the wall.
> > How do you stop the weapon penetrating the wall?  Did your collision
> > detection even *detect* that situation?
> 
> Nope. All that is done with your lib.

Nope.  I give you the low level primitive tests - you have to decide what
to do with them.
 
> You went public when you were 1.0.0, as you told me.
> 
> I could have chosen to do so, but this would mean to have no
> support on questions for half-a-year / a year.

I'm not blaming you for going public earlier - that's a perfectly
valid thing to do.  That's the way (for example) I'm working with
the PPE project.

I decided to work on Tux and Tuxkart privately because I enjoy
working on games and I don't happen to want to share that
enjoyment early on in the development.
 
> So I'm out with slow Huds and no optimizations at all - but I'm 0.2.9.

There is nothing wrong with that either.

What I have trouble with is the grandiose plans to slurp up every possible
kind of game into what is currently quite a promising space shooter.
 
> How was your code at that time? You didn't give it to the public
> at that time like I did to get contributions and arguments
> and improvents and redesign as soon as possible.

Tux (and TuxKart) didn't progress in quite that way.  I would get all
of one aspect of the game working (with none of the rest) then move on
to the next section and do all of that.  Hence, in TuxKart, I had all
of the driving stuff working with all of the graphics finished before
I even started on collision detection, scoring, powerups, etc.

I don't generally 'rough out a design' and then gradually improve it all...
at least not for those two games.

But that's just me - you may want to work differently...especially since
you are feeling around in the dark for some of this.

Just try to limit the scope of what you are attempting down to something
you can realistically achieve.

Just build a really *good* space shooter *or* a really good low level
futuristic air combat game *or* a ground-based shooter...not all at
once!

-- 
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] PLIB developers needed.

[Dave M. <dp...@ef...>]

Christian wrote:
> But anyway, do SG and SSG brake with that compiler? If the answer is no,
> that is compiler supporting costs. SG *is* const correct and at least
> half of SSG (IIRC).
>
I went to fix the 'const' methods in ul.h that are *not* portable on IRIX
when I noticed there were similar 'const' methods already in sg.h like
Christian says.  The 'const' methods in sg.h have been there for a long time
and must work on IRIX.  Perhaps we just need to change
	'double getRawTime () const ;'
to
	'double getRawTime (void) const ;'
and it would work on IRIX.  Seems to be something strange like that.  Do you
want to investigate Steve?

These 'const' methods have been there for a long time...

sg/sg.cxx: int sgBox::intersects ( const sgVec4 plane ) const
sg/sg.cxx: int sgSphere::intersects ( const sgBox *b ) const
sg/sg.cxx: int sgFrustum::getOutcode ( const sgVec3 pt ) const
sg/sg.cxx: int sgFrustum::contains ( const sgVec3 pt ) const
sg/sg.cxx: int sgFrustum::contains ( const sgSphere *s ) const
sg/sgd.cxx: int sgdBox::intersects ( const sgdVec4 plane ) const
sg/sgd.cxx: int sgdSphere::intersects ( const sgdBox *b ) const
sg/sgd.cxx: int sgdFrustum::getOutcode ( const sgdVec3 pt ) const
sg/sgd.cxx: int sgdFrustum::contains ( const sgdVec3 pt ) const
sg/sgd.cxx: int sgdFrustum::contains ( const sgdSphere *s ) const
sg/sg.h:   const SGfloat *getCenter (void) const { return center ; }
sg/sg.h:   SGfloat getRadius (void) const        { return radius ; }
sg/sg.h:   int isEmpty (void) const { return radius <  SG_ZERO ; }
sg/sg.h:   int intersects ( const sgSphere *s ) const
sg/sg.h:   int intersects ( const sgVec4 plane ) const
sg/sg.h:   int intersects ( const sgBox *b ) const ;
sg/sg.h:   const SGfloat *getMin (void) const { return min ; }
sg/sg.h:   const SGfloat *getMax (void) const { return max ; }
sg/sg.h:   int isEmpty(void) const
sg/sg.h:   int intersects ( const sgSphere *s ) const
sg/sg.h:   int intersects ( const sgBox *b ) const
sg/sg.h:   int intersects ( const sgVec4 plane ) const ;
sg/sg.h:   int getOutcode ( const sgVec4 src ) const ;
sg/sg.h:   SGfloat  getHFOV (void) const { return hfov  ; }
sg/sg.h:   SGfloat  getVFOV (void) const { return vfov  ; }
sg/sg.h:   SGfloat  getNear (void) const { return nnear ; }
sg/sg.h:   SGfloat  getFar  (void) const { return ffar  ; }
sg/sg.h:   SGfloat  getLeft (void) const { return left  ; }
sg/sg.h:   SGfloat  getRight(void) const { return right ; }
sg/sg.h:   SGfloat  getTop  (void) const { return top   ; }
sg/sg.h:   SGfloat  getBot  (void) const { return bot   ; }
sg/sg.h:   void getFOV ( SGfloat *h, SGfloat *v ) const
sg/sg.h:   void getNearFar ( SGfloat *n, SGfloat *f ) const
sg/sg.h:   int  contains ( const sgVec3 p ) const ;
sg/sg.h:   int  contains ( const sgSphere *s ) const ;
sg/sg.h:   const SGDfloat *getCenter (void) const { return center ; }
sg/sg.h:   SGDfloat getRadius (void) const         { return radius ; }
sg/sg.h:   int isEmpty (void) const { return radius <  SGD_ZERO ; }
sg/sg.h:   int intersects ( const sgdSphere *s ) const
sg/sg.h:   int intersects ( const sgdVec4 plane ) const
sg/sg.h:   int intersects ( const sgdBox *b ) const ;
sg/sg.h:   const SGDfloat *getMin (void) const { return min ; }
sg/sg.h:   const SGDfloat *getMax (void) const { return max ; }
sg/sg.h:   int isEmpty(void) const
sg/sg.h:   int intersects ( const sgdSphere *s ) const
sg/sg.h:   int intersects ( const sgdBox *b ) const
sg/sg.h:   int intersects ( const sgdVec4 plane ) const ;
sg/sg.h:   int getOutcode ( const sgdVec4 src ) const ;
sg/sg.h:   SGDfloat  getHFOV (void) const { return hfov  ; }
sg/sg.h:   SGDfloat  getVFOV (void) const { return vfov  ; }
sg/sg.h:   SGDfloat  getNear (void) const { return nnear ; }
sg/sg.h:   SGDfloat  getFar  (void) const { return ffar  ; }
sg/sg.h:   SGDfloat  getLeft (void) const { return left  ; }
sg/sg.h:   SGDfloat  getRight(void) const { return right ; }
sg/sg.h:   SGDfloat  getTop  (void) const { return top   ; }
sg/sg.h:   SGDfloat  getBot  (void) const { return bot   ; }
sg/sg.h:   void getFOV ( SGDfloat *h, SGDfloat *v ) const
sg/sg.h:   void getNearFar ( SGDfloat *n, SGDfloat *f ) const
sg/sg.h:   int  contains ( const sgdVec3 p ) const ;
sg/sg.h:   int  contains ( const sgdSphere *s ) const ;

These are the 'const' methods I recently touched...

util/ulClock.cxx: double ulClock::getRawTime () const
fnt/fnt.h:   virtual int   isFixedPitch () const    = 0 ;
fnt/fnt.h:   virtual float getWidth     () const    = 0 ;
fnt/fnt.h:   virtual float getGap       () const    = 0 ;
fnt/fnt.h:   int   isFixedPitch () const    { return fixed_pitch ; }
fnt/fnt.h:   float getWidth     () const { return width     ; }
fnt/fnt.h:   float getGap       () const { return gap       ; }
fnt/fnt.h:   void getCursor ( float *x, float *y, float *z ) const
fnt/fnt.h:   fntFont *getFont () const { return font ; }
fnt/fnt.h:   float getSlant     () const { return italic    ; }
fnt/fnt.h:   float getPointSize () const { return pointsize ; }
pui/pu.h:   const char *getLegend ( void ) const { return legend ; }
pui/pu.h:   const char *getLabel ( void ) const { return label ; }
pui/pu.h:   int getNumItems() const { return num ; }
pui/pu.h:   int getTopItem() const { return top ; }
ssg/ssg.h:   int getMaxKids (void) const { return max_kids ; }
util/ul.h:   double getRawTime () const ;
util/ul.h:   double getMaxDelta  () const { return max_delta ; }
util/ul.h:   double getAbsTime   () const { return now   ; }
util/ul.h:   double getDeltaTime () const { return delta ; }
util/ul.h:   double getFrameRate () const { return 1.0 / delta ; }

--Dave

Re: [Plib-devel] Quaternions in plib

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

Alexander Rawass wrote:
> 
> I have neither knowledge of net-related problems,
> nor have I designed the net part of my game yet well enough,
> bu I think that this is irrelevant !
> 
> The speed of the game played through the net does not depoend
> on the size of the data transferred at each frame, but
> on the time the packet needs to go from joystick to client engine to
> client net,
> there to the internet to some distant server (TIME! is lost), into the servers engine,
> and then back to the clients.

Wrong! Lag and data size are important. You are saying that e.g. for a
car only the top speed matters but not the power of the engine. I can be
faster than 200 km/h with a car that has only 1 horse power (by driving
out of a plane...). The other way round also doesn't make sense (a tank
is much slower than a motor bike, although it is much stronger).

A normal user doesn't know that the amound of data is important -
because the game designers have alrady taken care of it.

There are actually many things that have to be taken care of when you
are thinking of adding net support:
- the phyiscal connection limits the amount of data which you
  can transport in a certain time
- the protokoll reduces that rate and can cause other problems. 
  Either it guarantees you that you recieve the data - but that 
  can be whenever (TCP does that). Or it transports the data as 
  fast as possible - but might get lost (UDP)
- The network funktions of the OS might give you additional 
  limitations

And there are definitely many more of those.

CU,
Christian

Re: [Plib-devel] PLIB developers needed.

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

Steve Baker wrote:
> 
> Christian Mayer wrote:
> 
> > > ...and then remove them anyway!
> >
> > I doubt that there is a need to remove it. There is a need for the other
> > code to be made const consistent.
> 
> BUT IT DOESN'T COMPILE ON AT LEAST ONE C++ IMPLEMENTATION.

Chill down. Nobody says that you should brake (or mustn't fix) a
compilation, just because it's correct that way.

I just wanted to say that we should cure the source of the problem and
not the symptoms.

When it comes to consts everyone is tempted to do that.

> > It's *very* important for a library to be const correct!
> 
> It's **MUCH** more important that it **COMPILE**!

I was assuming that it compiles. Otherwise it shouldn't be published...
(I know the limitations of that when it comes to protable code, etc.)

> > But as soon as a const correct program wants to use non const correct
> > functions it's very likely that the compilation brakes.
> > The other way round usually works.
> 
> It didn't even get through the ul.h header.  There was no other code
> involved apart from standard UNIX headers prior to that point. Also,
> the program compiles just fine under Linux - so there isn't
> anything wrong with my code.

Just that it compiles under one system doesn't say that there's nothing
wrong with it.

I don't know what causes it (I don't know any of the affected code). So
it might be your code or it might be the code in the ul.h or perhaps
even something totally different. I don't know it. So I'm not saying
who's guilty.

> We are looking at a use of 'const' that is in a more recent C++ spec
> than IRIX supports (this is just like the declaration-inside-a-for-loop
> issue for MSVC).
> 
> If we want our code to be portable, we have to forgo some of the
> fancier features of C++ in order to get through the lowest-common-denominator
> of all C++ compilers.

I allways thought that const was one of the most basic C++ features.

But anyway, do SG and SSG brake with that compiler? If the answer is no,
that is compiler supporting costs. SG *is* const correct and at least
half of SSG (IIRC).

> > PS: const correctness is quite easy to understand once you tried. (Steve
> > it shouldn't take you more than 10 minutes). After you've used it a few
> > times (with paying full attention) it comes automatically.
> 
> OK - I understand - that's not the point.  A program that compiles
> just fine under Linux/g++ doesn't compile under IRIX/C++ - and that's
> utterly intolerable.

No matter where it compiles. As soon as it doesn't compile on one
(reasonable) system make it intolerable.

> Am I supposed to be somehow consoled that although my program is
> completely unusable, it's wonderfully const-correct.  NO!  Const
> is a very small part of making programs that work - I've managed
> to write and debug millions of lines of code without it.

Of course.

But you can't cry and say 'ban all consts' just because you trip over
one that doesn't work - w/o really knowing if it's the const that causes
the problem or if its breaking the compiler just because the real
problem (probably a forgotten const) stays unnoticed.

> Programming is a practical skill - it's all about getting a job done.
> A feature that prevents me from compiling is infinitely worse than
> the teeny-tiny *theoretical* bug it's trying to correct.

It's not only about bugs. It's also about structure, performance and
probably other thing, too.

> Portability is more important to PLIB than const-correctness.

Definitely. But why shouldn't we try to get both?

CU,
Christian

Re: [Plib-devel] PLIB developers needed.

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

Dave wrote:

>i forgot. i found both ascii (txt) and binary (bin) .x
>files in the DirectX 7.0 SDK:

Oh - ok. 
I missunderstood your original post, I hoped
you had found the new super-duper site
with free 3D models :-).

>--Dave

Bye bye,
Wolfram.

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

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

Alex wrote:

>I've today drawn my first image, see my 3D math help page ;-)

Huh, I didn't see it?

>> > it is commercially better to write a gaming engine and make 1,2,3,4 games
>> > out of it and sell them all for a high price, than to write the
>> > universal gaming engine that sells just once.

No. If this could be done and the engine could compete favourable with
specialized engines, then the company doing it would get heaps of
money. Think of the time this would save the developers of the games.


>> Start simple.  Design one game in one genre.  Just wait and see what
>> actually comes to bite you.  Simple things like collision detection,
>> best use of the Z buffer and where to place the camera are unbelievably
>
>I don't have any idea about any Z-Buffer - in my opinion, thats your
>part. Tell me how to use it - or just gimme some url doing this.

Well, you should of course understand the Z-buffer so that, for
example you can set near and far to reasonable values.
But I agree this is fairly simple. As is, if I haven't overlooked
something, everything you did up to now.

Collision detection isn't simple at all if you want some accuracy.
Steve mentioned some, but not all problems in his post.

>The point is: if I'm going to concentrate on this one genre, I might
>write a good game - and get stuck with it.
>I have LONG LONG thought about howto write this Starfighter game
>(version 1.0.0) in a way that it can easily extended to v2.0.0 in
>some time, but if I would concentrate to this one genre, I had to
>completely re-write code and classes to expand it.

I don't understand this, it sounds like a general engine is easier
than a specialized one?

>
>V1.0.0 will be a good starfighter game, with all possibilities
>to extend it.


>It will be better than XwA,XwT or WC, but it will probably not be
>better than SpaceThing or glWars, from which I've heard today.

I have never played XwA,XwT, but I cant imagine that you could just do
them in, say a few man-months so you can then improve. AND you need
some time to learn 3D graphics, game development etc. With plib you
have a HUGE head start over people a few years ago, but it STILL
cost you a long time to do just the rotations.

I think one problem is that you come over as someone who hasn't done
anything hard yet, but is sure that what all other people do is
trivial and if he just tried it, he could of course do much better.

One advice if you want to become a good programmer and see things more
realistic (which can be frustrating):
Before you do things, guess how long it will take. Then, after you
have done it, you can compare. Being able to guess fairly accurately
how long something will take is an important skill for developers.

>> > I have come to the conclusion that all these games are 'the same'.

Some time ago Steve wrote a great post either here, in plib-users or
in the ppe-mailing-list about the different needs that different games
have for cameras. I didn't find it, maybe you will find it in the
archives.

But if you think all the people at your uni have no idea and their
advice is bull, think about John Carmack. Many people think he is one
of the top programmers and from all I know about him I agree.
Still, since Wolfenstein3D (how long ago was that?) he has done
not only the same genre of game - FPS - but I would say even the same
sub-type. For example, AFAIK (I am not into FPS), all his games were
mainly "indoor". You could also have a FPS with people running around
in a hilly landscape without buildings. This would also be a FPS, but
(AFAIK) different to the ones he wrote.
If you now think that this is directed against him, no, just the
opposite: I am a bit of a perfectionist myself and think its great
that he could advance all the time and is now top-of-the-stack in FPS
programmers.
BTW, I am writing two 3D modelers right now, a closed source one 
for several years now and PPE.

If even J.C. can still advance even so he works on such a small field,
do you really think you can write a playable universal game engine?

Sorry, but even if you had unlimited CPU and graphics power - which
you don't - you couldn't do it. To do it really universal, it would
become VERY complex. Just think about collision detection. Some games
might need to calculate a rotation after the collision.
So, you need to exactly know where it collides - face to face, vertex
on face, edge-edge etc. Then you have to see whether something breaks
of and if it does how much the kinetic energy changed etc. If after
the first collision the object rotates and 0.00001 seconds later a
second collision occurs that stops the rotation, will you catch it?


>When a Starfighter flies into a hole in an asteroid, there will be sort
>of portal and he will get connected to a KobayashiMaru mission
>server playing the inside_asteroid Mission.
>At that moment, calculation gets done by another engine, and the people
>on the ground wont see it again until it comes out of another
>portal.

But then your engine isn't universal after all .

>If the spaceship is so near that is makes sense to let you see
>all 1.000 polygons, it's probaby so near that you wont even have
>to think about drawing something other.

You are knocking down other games and argue like this?!?

>> > I've got so many ideas, I don't know where to start next.

Well, that's all we are saying: Start with one thing, for example a
space fighting game a la Elite. Once you have done that, you can plan
the next thing. BTW, I loved Elite.

>> > It will surely a game that will be a lot better than other commercial
>> > games, but I also think that graphics and sound will suck. Relatively.

Do you think (all) game programmers suck?

>But show Tux to a person who pays 80DM for a commercial game and

Huch ;-)

>is used to graphics like Quake3, he will probably just laugh and
>say 'yoz gfx sukkz' or so.

And you really think you can beat many commercial games??

>> OK - so *everyone* is telling you the same thing.  People with 20 times
>
>They don't have the experience, so I igonored it.

Can you tell me one single area where you have experience?
I would guess at the uni you will find people with much experience,
maybe not game development, maybe not even 3D gfx (so that would
surprise me), but with experience in completing stuff, with OO, with
writing large stuff, with generalizing/specializing, with design
decisions etc.

>I'd like to come to your town and explain KobayashiMaru to you, I
>just need a ticket, a big blackboard and some hours of talking
>time.

I fear that wouldn't help. I fear that for each argument pointing out
a difficulty you would say - oh I will simply do it this way. I hope I
am wrong so.
Of course all the problems can be solved. After all, all the problems
were solved in one or the other game. And if one engine for one 
genre has a difficulty with another, then just have n engines working
together looking as one to the games-programmer.
But the problem is how much time you will need (Steves 500 years isn't
unrealistic IMHO), how complex it will get (I would bet it gets so
complex that you couldn't do it ever as a single person even when
working full time on it) and how fast it will run.

>An actionbased flightsim doesn't need realism or accuracy
>at that high rates of speed.

Yes, but action. Steves point was that it will look like you travel 50
mph - and that is very bad if you just bought the newest
HyperTuxoWroom-SpaceShip. The argument is not about realism or
accuracy. 
Sigh. One thing is strange about you:
OToneH, you say that theoretical study of matrices was yuck and 
Steves practical page great. But OTOH you seem to think that you are
able to foresee most of the problems of your project.
I think you will only be able to do so if you have some experience of
your own. 
So, PLEASE stop theoreticising about what great and unbelievable
things you could do in V 2.0. 

>If I'd been you, I'd answered as simple like that:
>
>There is a TerraGear project to do this, and yes, it is in principe
>possible, BUT TerraGear is constructed for a very detailed viewing
>of the landscape at the speed of slow airplanes, so you'd get low
>framerates from this, better look somewhere else.
>
>(I didn't asked if it will run fast, just if it _can_ be possible)

Well, we thought you wanted to make a playable game.
If you want to make something to test theories, that's fine by me, but
say so.
And Steve didn't say the problem was that terragear is unsuitable. He
said that to get good frame rates you have to tweak the game design,
that is, you cant have a universal game engine with todays hardware.

>At the moment, collision checking is done on 'Shield' level, meaning
>an impact in a sphere around the ship - this can be done without.

Ah - That's of course the most primitive solution.
What you code depends on the game-design (and vice-versa).

>When a CarObject is inside the radius of a StaticGroundObject, further
>collision checking is done with plibssg.

So, if you do a racing game, this check is completely super-fluous.
What you code depends on the game-design (and vice-versa).

>possible solutions: i) more framerates by
>                       models with lod
>                       changing the fonts
>                       optimising my code a lot
>                    ii) a mathematical algorithms I yet have not the
>                        slightest idea of.
>                    iii) run the KIs that steer in the ship in a
>                         'minimum speed' in a seperate task, when
>                        neccessary leaving frames to display off
>                        to have cputime for the engine.
>
>When I had realized that problem, I didn't continue to work on that
>but decided to wait until i) has been solved

You do realize that i) isnt a complete solution, don't you?


>It is true that you could say the things shorter, but on the
>other hand I like this discussion, you're the first one
>I have to respect, 

Good, then try not to offend people.

>No, only one.
>I immediatly worked on that part, and I have seen that it was true,
>the other wouldn't probably have been needed.

Good. But it would have been even better if you had said so.
Just "Ok - I am testing it now" would have been enough.

>*PLEASE* remember this:
>
>You went public when you were 1.0.0, as you told me.
>[...]
>Please see the difference between a fully grown & tested game, and
>my early stage.

This is very funny. All we are telling you is that at 0.29 you should
not think about 2.0 or 10.0 and even less brag about 2.0 and 10.0 .

Oh, BTW, nobody looked at your code until yesterday, so nobody 
criticized it. I just tried to compile it under Windo$, I will e-mail
you.

Sigh, I didn't want to invest this much time, but once you start
writing you don't want to stop midway.
BTW, FYI, Steve is just working on some very basic stuff of PPE,
everyone else has to stop coding on it until he is finished. 
I think it is great that Steve puts as much time into answering people
as he does. I have learned quite a lot. But it is absolutely
understandable that he resents wasting time.

>Alex

Bye bye,
Wolfram.

RE: [Plib-devel] PLIB developers needed.

[Paul B. <pbl...@di...>]

Microsoft ships convx.exe with the directx sdk (no source):

C:\DX8SDKW1\bin\dxutil\xfiles>convx

CONVX(1)                                                     CONVX(1)

NAME
        convx - convert X files

SYNOPSIS
        convx [-tso] file

DESCRIPTION
        The convert utility reads an X file and converts it to either
        the binary or text X file format with or without templates.

        The options are as follows:

        -t Generate text format X files

        -s Include template definitions in X files (stand-alone)

        -o "filename" - Name output file


USAGE

        convx file.x        generate binary X file with no templates

        convx -t file.x     generate text X file with no templates

        convx -s file.x     generate binary X file with templates

        convx -t -s file.x  generate text X file with templates

 MICROSOFT              May 28,1996                     1

-----Original Message-----
From: Dave McClurg [mailto:Dav...@dy...]
Sent: Friday, August 11, 2000 7:28 PM
To: 'pli...@li...'
Subject: RE: [Plib-devel] PLIB developers needed.


Wolfram wrote: 
> BTW, IIRC, Micro$oft gives away a converter to convert 
> between ASCII and binary *.x files. 
that would be helpful. then we only need to support ASCII! 
i forgot. i found both ascii (txt) and binary (bin) .x 
files in the DirectX 7.0 SDK: 
samples/Multimedia/VBSamples/D3DRM/media/dropship.x   - bin 
samples/Multimedia/VBSamples/D3DRM/media/egg.x - bin 
samples/Multimedia/VBSamples/D3DRM/media/engine1.x - txt 
samples/Multimedia/VBSamples/D3DRM/media/land4.x - bin 
samples/Multimedia/VBSamples/D3DRM/media/multi.x - bin 
samples/Multimedia/VBSamples/D3DRM/media/prism2.x - txt 
samples/Multimedia/VBSamples/D3DRM/media/skmech.x - txt 
samples/Multimedia/VBSamples/D3DRM/media/sphere1.x - bin 
samples/Multimedia/VBSamples/D3DRM/media/teapot.x - bin 
samples/Multimedia/VBSamples/D3DRM/media/tiger.x - txt 
samples/Multimedia/VBSamples/D3DRM/media/toecone.x - txt 
samples/Multimedia/VBSamples/D3DRM/src/Egg/egg.x - bin 
samples/Multimedia/VBSamples/D3DRM/src/QuickStart/egg.x - bin 
samples/Multimedia/VBSamples/DXMisc/Media/toecone.x - txt 
samples/Multimedia/VBSamples/DXMisc/Media/sphere1.x - bin 
samples/Multimedia/VBSamples/DXMisc/Media/prism2.x - txt 
samples/Multimedia/D3DIM/media/car.x - txt 
samples/Multimedia/D3DIM/media/heli.x - txt 
samples/Multimedia/D3DIM/media/tiger.x - txt 
samples/Multimedia/D3DIM/media/teapot.x - bin 
samples/Multimedia/D3DIM/media/dolphin_group.x - bin 
samples/Multimedia/D3DIM/media/dolphin.x - txt 
samples/Multimedia/D3DIM/media/seafloor.x - txt 
samples/Multimedia/D3DIM/media/envcube.x - txt 
samples/Multimedia/D3DRM/media/cherry.x - bin 
samples/Multimedia/D3DRM/media/camera.x - bin 
samples/Multimedia/D3DRM/media/bigship1.x - bin 
samples/Multimedia/D3DRM/media/pm_cube.x - bin 
samples/Multimedia/D3DRM/media/dropship.x - bin 
samples/Multimedia/D3DRM/media/egg.x - bin 
samples/Multimedia/D3DRM/media/land4.x - bin 
samples/Multimedia/D3DRM/media/mslogo.x - bin 
samples/Multimedia/D3DRM/media/multi.x - bin 
samples/Multimedia/D3DRM/media/ncube.x - bin 
samples/Multimedia/D3DRM/media/pm_bship.x - bin 
samples/Multimedia/D3DRM/media/pm_cam.x - bin 
samples/Multimedia/D3DRM/media/pm_chrry.x - bin 
samples/Multimedia/D3DRM/media/cube.x - bin 
samples/Multimedia/D3DRM/media/pm_torus.x - bin 
samples/Multimedia/D3DRM/media/pm_egg.x - bin 
samples/Multimedia/D3DRM/media/pm_land4.x - bin 
samples/Multimedia/D3DRM/media/pm_mslog.x - bin 
samples/Multimedia/D3DRM/media/pm_multi.x - bin 
samples/Multimedia/D3DRM/media/pm_rmlog.x - bin 
samples/Multimedia/D3DRM/media/pm_sph0.x - bin 
samples/Multimedia/D3DRM/media/pm_sph1.x - bin 
samples/Multimedia/D3DRM/media/pm_sph2.x - bin 
samples/Multimedia/D3DRM/media/pm_sph3.x - bin 
samples/Multimedia/D3DRM/media/pm_sph4.x - bin 
samples/Multimedia/D3DRM/media/pm_dship.x - bin 
samples/Multimedia/D3DRM/media/pm_tpot.x - bin 
samples/Multimedia/D3DRM/media/pm_tpot0.x - bin 
samples/Multimedia/D3DRM/media/pm_tpot1.x - bin 
samples/Multimedia/D3DRM/media/pm_tpot2.x - bin 
samples/Multimedia/D3DRM/media/pm_tpot3.x - bin 
samples/Multimedia/D3DRM/media/pm_tree.x - bin 
samples/Multimedia/D3DRM/media/rmlogo.x - bin 
samples/Multimedia/D3DRM/media/sphere0.x - bin 
samples/Multimedia/D3DRM/media/sphere1.x - bin 
samples/Multimedia/D3DRM/media/sphere2.x - bin 
samples/Multimedia/D3DRM/media/sphere3.x - bin 
samples/Multimedia/D3DRM/media/tpot2.x - bin 
samples/Multimedia/D3DRM/media/teapot.x - bin 
samples/Multimedia/D3DRM/media/tiger.x - txt 
samples/Multimedia/D3DRM/media/torus.x - bin 
samples/Multimedia/D3DRM/media/tpot0.x - bin 
samples/Multimedia/D3DRM/media/tpot1.x - bin 
samples/Multimedia/D3DRM/media/sphere4.x - bin 
samples/Multimedia/D3DRM/media/tree.x - bin 
samples/Multimedia/D3DRM/media/tpot3.x - bin 
include/rmxftmpl.x - txt 
--Dave 

RE: [Plib-devel] PLIB developers needed.

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

Wolfram wrote:
> BTW, IIRC, Micro$oft gives away a converter to convert
> between ASCII and binary *.x files.
that would be helpful. then we only need to support ASCII!

i forgot. i found both ascii (txt) and binary (bin) .x
files in the DirectX 7.0 SDK:

samples/Multimedia/VBSamples/D3DRM/media/dropship.x   - bin
samples/Multimedia/VBSamples/D3DRM/media/egg.x - bin
samples/Multimedia/VBSamples/D3DRM/media/engine1.x - txt
samples/Multimedia/VBSamples/D3DRM/media/land4.x - bin
samples/Multimedia/VBSamples/D3DRM/media/multi.x - bin
samples/Multimedia/VBSamples/D3DRM/media/prism2.x - txt
samples/Multimedia/VBSamples/D3DRM/media/skmech.x - txt
samples/Multimedia/VBSamples/D3DRM/media/sphere1.x - bin
samples/Multimedia/VBSamples/D3DRM/media/teapot.x - bin
samples/Multimedia/VBSamples/D3DRM/media/tiger.x - txt
samples/Multimedia/VBSamples/D3DRM/media/toecone.x - txt
samples/Multimedia/VBSamples/D3DRM/src/Egg/egg.x - bin
samples/Multimedia/VBSamples/D3DRM/src/QuickStart/egg.x - bin
samples/Multimedia/VBSamples/DXMisc/Media/toecone.x - txt
samples/Multimedia/VBSamples/DXMisc/Media/sphere1.x - bin
samples/Multimedia/VBSamples/DXMisc/Media/prism2.x - txt
samples/Multimedia/D3DIM/media/car.x - txt
samples/Multimedia/D3DIM/media/heli.x - txt
samples/Multimedia/D3DIM/media/tiger.x - txt
samples/Multimedia/D3DIM/media/teapot.x - bin
samples/Multimedia/D3DIM/media/dolphin_group.x - bin
samples/Multimedia/D3DIM/media/dolphin.x - txt
samples/Multimedia/D3DIM/media/seafloor.x - txt
samples/Multimedia/D3DIM/media/envcube.x - txt
samples/Multimedia/D3DRM/media/cherry.x - bin
samples/Multimedia/D3DRM/media/camera.x - bin
samples/Multimedia/D3DRM/media/bigship1.x - bin
samples/Multimedia/D3DRM/media/pm_cube.x - bin
samples/Multimedia/D3DRM/media/dropship.x - bin
samples/Multimedia/D3DRM/media/egg.x - bin
samples/Multimedia/D3DRM/media/land4.x - bin
samples/Multimedia/D3DRM/media/mslogo.x - bin
samples/Multimedia/D3DRM/media/multi.x - bin
samples/Multimedia/D3DRM/media/ncube.x - bin
samples/Multimedia/D3DRM/media/pm_bship.x - bin
samples/Multimedia/D3DRM/media/pm_cam.x - bin
samples/Multimedia/D3DRM/media/pm_chrry.x - bin
samples/Multimedia/D3DRM/media/cube.x - bin
samples/Multimedia/D3DRM/media/pm_torus.x - bin
samples/Multimedia/D3DRM/media/pm_egg.x - bin
samples/Multimedia/D3DRM/media/pm_land4.x - bin
samples/Multimedia/D3DRM/media/pm_mslog.x - bin
samples/Multimedia/D3DRM/media/pm_multi.x - bin
samples/Multimedia/D3DRM/media/pm_rmlog.x - bin
samples/Multimedia/D3DRM/media/pm_sph0.x - bin
samples/Multimedia/D3DRM/media/pm_sph1.x - bin
samples/Multimedia/D3DRM/media/pm_sph2.x - bin
samples/Multimedia/D3DRM/media/pm_sph3.x - bin
samples/Multimedia/D3DRM/media/pm_sph4.x - bin
samples/Multimedia/D3DRM/media/pm_dship.x - bin
samples/Multimedia/D3DRM/media/pm_tpot.x - bin
samples/Multimedia/D3DRM/media/pm_tpot0.x - bin
samples/Multimedia/D3DRM/media/pm_tpot1.x - bin
samples/Multimedia/D3DRM/media/pm_tpot2.x - bin
samples/Multimedia/D3DRM/media/pm_tpot3.x - bin
samples/Multimedia/D3DRM/media/pm_tree.x - bin
samples/Multimedia/D3DRM/media/rmlogo.x - bin
samples/Multimedia/D3DRM/media/sphere0.x - bin
samples/Multimedia/D3DRM/media/sphere1.x - bin
samples/Multimedia/D3DRM/media/sphere2.x - bin
samples/Multimedia/D3DRM/media/sphere3.x - bin
samples/Multimedia/D3DRM/media/tpot2.x - bin
samples/Multimedia/D3DRM/media/teapot.x - bin
samples/Multimedia/D3DRM/media/tiger.x - txt
samples/Multimedia/D3DRM/media/torus.x - bin
samples/Multimedia/D3DRM/media/tpot0.x - bin
samples/Multimedia/D3DRM/media/tpot1.x - bin
samples/Multimedia/D3DRM/media/sphere4.x - bin
samples/Multimedia/D3DRM/media/tree.x - bin
samples/Multimedia/D3DRM/media/tpot3.x - bin
include/rmxftmpl.x - txt

--Dave

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

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

Hi,

> Alexander Rawass wrote:
> 
> > > You just need to practice and learn GIMP.  It's not that hard to draw things
> > > like instruments, little icons and such like.
> > 
> > No way. Not for me. Better a good game with bad graphics than to take
> > this big big leap.
> 
> You don't have to do it full-time.  It's not like a maor career change - but

I've today drawn my first image, see my 3D math help page ;-)

> this is something you'll find to be an increasing necessity.  Drawing
> things like your radarscope out of lots of little OpenGL commands just
> doesn't make sense and expecting someone to come along and say "This game
> that runs like a pig and looks terrible could be greatly improved if I
> spend a few hours painting some pictures for him"...well, it's just
> naive.

In my opinion, all Hud-instruments you can see in my game suck.
They are yet slow since they are still using glut.
They are ugly.
They are not stylish/transparent.
They are functional.
They are to be replaced by either myself in the future
or by someone other by accessing the HudObject-API

> > it is commercially better to write a gaming engine and make 1,2,3,4 games
> > out of it and sell them all for a high price, than to write the
> > universal gaming engine that sells just once.
> 
> Well, commercially, the games industry made 7.2 billion dollars last year,
> but only one game in 35 actually turned a profit.  By contrast, the Holliwood
> movie industry made 7.4 billion and one in ten films turned a profit.

I don't wanna make profit.

> Game making is a **HUGE** and extremely risky business.  If you manage to
> make a success out of game #1, you'll certainly be making game #2 with
> pretty much the same themes/engine/etc.

Exactly.

> Utterly universal game engines don't exist because they can't exist.
> There is a galaxy of difference between a first person shooter game
> engine like Quake or Doom and a flight simulation engine like FlightGear.
> The idea that you can just change the model and program some different
> behaviours in is very naive.
>  
> > I am pissed of by ST Armada, I've seen it on a friends computer,
> > the graphics are great but I haven't seen any feature that KobayashiMaru
> > version 2.0.0 is not yet designed to have.
> 
> When you actually *have* all that working, I'll be impressed - but in the
> meantime, it sounds very much like vaporware.  As your first 3D game,
> it's unlikely that you could master one genre - let along three or four
> in a single title.

I'm talking about version 2.0.0, which is far away from 0.2.9

> > You told me in a former mail, that the abstraction layer between the game
> > and plib costs time, put I am big in abstraction this times,
> > and if you write a simple starfighter game, you suddenly lean back for
> > a while, abstracting even more and more, and then you'll have a thing
> > that can handle anything.
> 
> No - you won't.  You'll have an unimplementable design.
> 
> Start simple.  Design one game in one genre.  Just wait and see what
> actually comes to bite you.  Simple things like collision detection,
> best use of the Z buffer and where to place the camera are unbelievably

I don't have any idea about any Z-Buffer - in my opinion, thats your
part. Tell me how to use it - or just gimme some url doing this.

> subtle - and DRASTICALLY different in every genre.  Also, that little thing
> "performance" doesn't just appear from an abstraction layer - it has to
> be tightly engineered at the lowest levels - the way you make a FPS run
> fast is TOTALLY different than a space game or a flight sim.
> 
> > Just wait.
> 
> I don't have to.  I just hope I can pursuade you to make your first project
> something remotely achievable so you don't get discouraged when it won't all
> come together at the end.

The point is: if I'm going to concentrate on this one genre, I might
write a good game - and get stuck with it.
I have LONG LONG thought about howto write this Starfighter game
(version 1.0.0) in a way that it can easily extended to v2.0.0 in
some time, but if I would concentrate to this one genre, I had to
completely re-write code and classes to expand it.

V1.0.0 will be a good starfighter game, with all possibilities
to extend it.
It will be better than XwA,XwT or WC, but it will probably not be
better than SpaceThing or glWars, from which I've heard today.

> > I have come to the conclusion that all these games are 'the same'.
> 
> Really, you couldn't be more wrong. FLightGear, TuxAQFH, TuxKart, TuxRacer
> and others I have worked with couldn't be more different in approach.
> 
> > Lean back and abstract.
> 
> But eventually - just try to implement it all!

Takes time.

> > I am only a 3D beginner, and these problems have either been solved
> > already or will be solved with your help, but I think that I am
> > very well capable in designing that huge game and writing it.
> 
> Well - I'm trying my very best to explain it to you - but you keep coming
> up with grandiose plans - and my best advice as someone who'se been programming
> this kind of thing for 27 YEARS is that you need to come down from this
> ethereal plane and actually implement a couple of more tightly focussed
> designs before you leap off into the void as you are about to do.
> 
> If you think you'll get a lot of help from me when I can clearly see what's
> going to happen here - you have another think coming.  I'll quickly lose
> patience and you'll end up on my mail filter list.

I hope that I'll hear at least a *PLONK* ;-)

> You are asking for advice - and I'm giving it.  Choose to ignore me if
> you like - but don't expect more help if you do!

I need your advise and help for 3D-related matters.

> When you start to ask things like "How the heck to I draw Laura Croft's
> boobs at a range of 10 centimeters - as well as the spiral arm of
> galaxy XYZ-34 in the background?"

Easy: the boobs are SO big, you wont ever see the galaxy.
Besides, who will notice the galaxy, if he has the opportunity
for the other thing?

>  or  "How do I allow space ships to
> fly into holes in asteroids - as well as have people stay stuck to

When a Starfighter flies into a hole in an asteroid, there will be sort
of portal and he will get connected to a KobayashiMaru mission
server playing the inside_asteroid Mission.
At that moment, calculation gets done by another engine, and the people
on the ground wont see it again until it comes out of another
portal.

> the ground - and at the same time allow missiles to collide with
> 1,000 polygon spacecraft models"....remember my words.

If the spaceship is so near that is makes sense to let you see
all 1.000 polygons, it's probaby so near that you wont even have
to think about drawing something other.

These things you mentioned will happen _either_ , but not on the
same display.

> > I've got so many ideas, I don't know where to start next.
> 
> It'll get *MUCH* worse before it gets better.

If you mean 'lower framerate' with worse, you are true at the moment,
since I concentrate on other ideas.

> > > Remember that *very* likely you'll be doing it single-handedly with no
> > > artistic or music input?

> > It will surely a game that will be a lot better than other commercial
> > games, but I also think that graphics and sound will suck. Relatively.
> 
> A fancy game engine without good graphics will be *terrible*.  Good
> graphics consume 95% of every game development team's time, 95% of
> the time in the CPU, 95% of the disk space the game consumes.  If the
> graphics suck - you are back to writing games like Tetris that don't
> *need* fancy graphics.

How would you rate the graphics of your game?

I think that it's one of the cutest little open source games I've ever
seen, and that the graphics are great, compared to other open source
games.

But show Tux to a person who pays 80DM for a commercial game and
is used to graphics like Quake3, he will probably just laugh and
say 'yoz gfx sukkz' or so.

No-one of them will play yours or mine.

> > No one will of course play such a game, exept the Linux-GPL-Freaks,
> 
> ...not even them.

I do not know a single person other than me to have a working 
hardware 3D installed, although other could but - why shutdown
Windows, just to start Quake under Linux - no way for them.

I will be my best player, that I know for sure.

> > My friends told me the same - time will show, on which classes I'll
> > continue working.
> 
> OK - so *everyone* is telling you the same thing.  People with 20 times

They don't have the experience, so I igonored it.

> the experience in this stuff are telling you.

But I won't ignore it from you.

I'd like to come to your town and explain KobayashiMaru to you, I
just need a ticket, a big blackboard and some hours of talking
time.

> > No more than in Flightgear itself. You'll wonder how slow
> > 'several times the speed of sound' can be in an action-type based game.
> 
> No - I won't - unless you have terrain that covers literally millions of
> square miles and doesn't look 'sameish'.
> 
> > Or: the resolution of the terrain has to be decreased.
> 
> ...at which point, the amount of 'optical flow' (tekky flightsim
> term) will fall off - and it'll feel like you are going about 50 mph.
> 
> The Apollo 11 astronauts were flying faster than any man has travelled
> before or since.  However, between the earth and the moon, the
> resolution of the "terrain" is pretty poor - and they felt like they
> were stationary.
> 
> When you get the amount of data up to where it *feels* really fast,
> you'll need so much data that you'll have to page it in from disk in
> realtime (that's what FlightGear has to do - and most of it's planes
> fly at about 200mph!).

When you can't pump this amoun from data from disk, either reduce
it , or wait with that part until cpus are faster, or don't
shove it from disk but create it 'on the fly'

An actionbased flightsim doesn't need realism or accuracy
at that high rates of speed.

It could of course be that FightGear/Terragear is unsuitable
for my means, because they are rendering too good and not
suitable for this type of game, so I'll have to look elsewhere.

> You can help this out by designing the high level game play to
> make it undesirable or impossible to fly in a straight line for
> more distance than the terrain you can hold in RAM - but now
> your high level abstraction has to be bent to fit the ugly
> facts of life.
> 
> You can't "abstract" your way past that in your game design.
> 
> You see there are *so* many things you don't know that FUNDAMENTALLY
> affect the design of the game.  You'd have gotten all the way into
> implementation before you realised that this was your problem - and then
> you are suddenly faced with a MAJOR redesign so you can page stuff in from a
> background task.

If I'd been you, I'd answered as simple like that:

There is a TerraGear project to do this, and yes, it is in principe
possible, BUT TerraGear is constructed for a very detailed viewing
of the landscape at the speed of slow airplanes, so you'd get low
framerates from this, better look somewhere else.

(I didn't asked if it will run fast, just if it _can_ be possible)

> > > That's *VERY* naive.  Have you thought about collision detection yet?
> > 
> > At the moment, collsision checking in KobayashiMaru isn't done in
> > plibssg level but on my intern logical level.
> 
> But collision (at least at the scale of ground-based simulation) requires
> knowledge of where every single polygon is.  You can't do that without
> plibssg.

Yes.
At the moment, collision checking is done on 'Shield' level, meaning
an impact in a sphere around the ship - this can be done without.
The future will give collision checking on 'Hull' level, when the
Shields are down - this will be done with plibssg.

> > The same collision checking will work for cars - only, that the cars are
> > limited in z axis to the HOT they're on.
> 
> Not good enough.  How will you detect when the car goes under a bridge?  Or under

When a CarObject is inside the radius of a StaticGroundObject, further
collision checking is done with plibssg.

> the place where the bridge joins the terrain and there isn't enough room to
> go under the bridge - but the side-walls are just to high to drive *over*.

I dont get which situation you mean here.

> What happens when your speed is so high that at the start of the frame you
> are cleanly on one side of a brick wall - and at the end of the frame you are
> cleanly on the other - you *should* have hit the wall on the way - but does
> your algorithm solve that?  Efficiently enough?

Nope. This is _exactly_ a problem I already have.

possible solutions: i) more framerates by
                       models with lod
                       changing the fonts
                       optimising my code a lot
                    ii) a mathematical algorithms I yet have not the
                        slightest idea of.
                    iii) run the KIs that steer in the ship in a
                         'minimum speed' in a seperate task, when
                        neccessary leaving frames to display off
                        to have cputime for the engine.

When I had realized that problem, I didn't continue to work on that
but decided to wait until i) has been solved

> Think you can solve that?   Now apply that algorithm to a spaceship going at
> 0.8 times the speed of light towards another spaceship on a collision course.

Actually, we're not flying that fast, exept for hyperspace.
A normal starfighter makes 1km in 10secs

> Done that?  Now worry about how our heroin can get into a small space if she
> crawls - but not if she's standing up.  What happens if she crawls into a
> passageway that GRADUALLY gets smaller until she can't fit anymore?
> What happens if you are walking along parallel to a wall - carrying a long
> weapon - and the player pushes the joystick to turn in to face the wall.
> How do you stop the weapon penetrating the wall?  Did your collision
> detection even *detect* that situation?

Nope. All that is done with your lib.

> If the camera accidentally penetrates the wall, you'll see what's on the
> other side of it.  Do you prevent that (very hard) or do you simply
> design the high level game play so it never really matters?

There are situation where this does matter , other not. Now they dont.

> This stuff is *HARD*.  Picking just one genre helps you to get through it.
>  
> > I _can_ do all the game logic - but I have to rely on 3D on people who
> > know better, like you.
> 
> No!  You *can't* do all the game logic because it's horribly intertwined
> with the 3D that you don't know enough about *yet*.

Maybe?

> Look dude - I'm sick of these long posts where I tell you that you are
> a newbie who doesn't understand how hard it is...then you tell me that
> you have it all solved in your head somewhere.  Then I tell you that
> I've been there and done that and it's HARD - and you wave the magic
> "abstraction wand" so you don't have to think about it.

It is true that you could say the things shorter, but on the
other hand I like this discussion, you're the first one
I have to respect, since all others who have yet doubted
can program less than me , it's great to talk with someone
who knows what he's talking about.

> If you don't want to come down to ground level and think rationally

I'd rather fly than be tied to the ground.

> about what you can actually achieve (*especially* with no desire to
> learn art skills) - then I'm not interested in talking to you anymore
> because any attempt at help is just wasted effort.  I mean, it took
> like FOUR posts to convince you that all that font stuff was the cause

No, only one.
I immediatly worked on that part, and I have seen that it was true,
the other wouldn't probably have been needed.

But it took me some days to implement it and CONVICE me.
Would I have reacted faster, I would have BELIEVED you, but now
I am even convinced, and thats a lot better.

> of your slowness and *not* PLIB.  If you ask for advice, take it with
> good grace or get out.

The HudObjects will still use glut, until I think its time to
go for that problem.


*PLEASE* remember this:

You went public when you were 1.0.0, as you told me.

I could have chosen to do so, but this would mean to have no
support on questions for half-a-year / a year.

So I'm out with slow Huds and no optimizations at all - but I'm 0.2.9.

How was your code at that time? You didn't give it to the public
at that time like I did to get contributions and arguments
and improvents and redesign as soon as possible.

You published a neat fine game, while I am publishing sort of junk that
has to evolve about some time until it will be declared 1.0.0

I sometimes feel even ashamed of some of the bad code thats in
some classes, but you wont see that in 1.0.0 anymore,but know,
all could see what a lousy programmer I may be in some cases,
but at least my code is open to the public in a very early stage.

Please see the difference between a fully grown & tested game, and
my early stage.


Alex


PS.: the correct name for the book by Terry Pratchett is
     'Only you can save Mankind', the first Johnny Maxwell story

     'Johnny and the Bomb' is the third in that line, I haven't yet
     read it.


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

Re: [Plib-devel] PLIB developers needed.

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

Steve wrote:

>Sure - and I'm hoping that if I can offload some of the PLIB
>work, my PPE efforts could be larger.

Good.

>Well, I've added you to the developer's list...let me know if you want
>me to take you off again!

Good.

Bye bye,
Wolfram.

Re: [Plib-devel] PLIB developers needed.

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

Dave wrote:

>i couldn't find examples of the ASCII-*-x format, only references in the
>documentation.  Tons of binary .x format examples but that is yucky.

Oh! Do you remember where?
BTW, IIRC, Micro$oft gives away a converter to convert between ASCII
and binary *.x files.

>
>ssgLoadAC.cxx contains the most stable, easy to understand, and complete
>loader in SSG.  [...]

Good, thanks. 

>.  So... you may also want to look at ssgLoadASE.cxx for a more complex
>example.

Ok.


>-- Dave McClurg

Bye bye,
Wolfram.

RE: [Plib-devel] ssgVtxArray fixes.

[Vallevand, M. K <Mar...@UN...>]

Excellent!  I'll pull them down and see if they work for me, too.

BTW,  CVS/SSH commit works for me now!  I needed to checkout
the entire PLIB with my userid instead of anonymous the first
time.  Thanks to everyone!

Regards.
Mark K Vallevand   ma...@rs...
Never try and teach a pig to sing: it's a waste of time, and it annoys
the pig.


> -----Original Message-----
> From: Wolfram Kuss [mailto:w_...@rz...]
> Sent: Friday, August 11, 2000 8:57 AM
> To: pli...@li...
> Subject: Re: [Plib-devel] ssgVtxArray fixes.
> 
> 
> "Vallevand, Mark K" <Mar...@UN...> wrote:
> 
> >Yes, the MSVC project files seem to be slightly broken.  
> 
> Ok, fixed. Everything compiles for me now, the library itself and the
> examples, in release and debug builds.
> 
> Bye bye,
> Wolfram.
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
> 

Re: [Plib-devel] Work outstanding.

[Sam S. <sa...@sp...>]

----- Original Message -----
From: "Wolfram Kuss" <w_...@rz...>
To: <pli...@li...>
Sent: Friday, August 11, 2000 2:55 PM
Subject: Re: [Plib-devel] Work outstanding.


> Steve wrote:
>
> >> >For example, it would be GREAT to know how much
> >> >texture-swapping there is going on, but I doubt this can be done
> >> >portably?
> >>
>
> >However, real hardware can be VERY subtle
>
> Yes, I know. Generally speaking, I loved optimizing till about 10
> years ago. Until then, you could pretty much tell beforehand whether a
> change would speed up the program. But with several caches, pipelines
> that are filled by compilers, branch prediction etc it has become much
> harder and sometimes when I optimized something for speed I ended
> up making it slower :-(.
>
> >Since this question is unanswerable in a portable manner,
>
> That's what I feared.
>
> >So, these are NOT good questions to ask!
>
> Ok, I realize that there is no portable way to measure things, no one
> answer (after all, not all users have the same
> hardware), its not clearly defined etc.
> But I still think a ballpark figure could help enormously. I think
> it can still happen that large parts of the time per frame is spent in
> texture swapping.

Here's an idea.  You could still take a stab at the amount of texture memory _consumed_ even if not the amount _available_.  It's
still not all the simple since you'd need to know which mipmap levels are in use - I'm not sure you can do that.

But what would be useful would be a list of all the textures currently in use by the ssg scenegraph (even if they are culled/never
textured with), and by clicking on them you could replace that texture with the dummy red/white check pattern.

If you notice a sudden increase in frame rate then you know that on this particular hardware, with this scene-graph, looking in that
direction from that viewpoint that texture swapping is happening.. Heh, not get I suspose but it would be a useful UI.
  "Hey, this model is rendering really slowly let's try turning that texture off".

You could write a function that could monitor the frame rate and automatically try replacing texturing to look for swapping but I
think that's about as far as you can go.

Would it be practical to have some kind of playback/record mechanism in ssg or is that too much work, or too much of an impact in
performance?

Anyone know of any opengl texture management articles that cover scaling back the textures in use automatically?

Sam

Re: [Plib-devel] ssgVtxArray fixes.

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

"Vallevand, Mark K" <Mar...@UN...> wrote:

>Yes, the MSVC project files seem to be slightly broken.  

Ok, fixed. Everything compiles for me now, the library itself and the
examples, in release and debug builds.

Bye bye,
Wolfram.

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] Work outstanding.

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

Steve wrote:

>> >For example, it would be GREAT to know how much
>> >texture-swapping there is going on, but I doubt this can be done
>> >portably?
>> 

>However, real hardware can be VERY subtle 

Yes, I know. Generally speaking, I loved optimizing till about 10
years ago. Until then, you could pretty much tell beforehand whether a
change would speed up the program. But with several caches, pipelines
that are filled by compilers, branch prediction etc it has become much
harder and sometimes when I optimized something for speed I ended
up making it slower :-(. 

>Since this question is unanswerable in a portable manner, 

That's what I feared.

>So, these are NOT good questions to ask!

Ok, I realize that there is no portable way to measure things, no one
answer (after all, not all users have the same
hardware), its not clearly defined etc.
But I still think a ballpark figure could help enormously. I think
it can still happen that large parts of the time per frame is spent in
texture swapping.
But in PPE speak NIV10 ;-))), meaning, this wont be the next thing
that is implemented.



>
>> Well, the attraction with perfly is that it really doesn't do anything
>> apart from load and display models.
>
>Neither does PPE right now!   :-(

Lol. But PPE makes a nice 3D object converter once all those
loaders/writers work. BTW; there is a "conv3D" on SourceForge,
but I am not impressed and it seems to be deeply asleep. But maybe
they could help, for example with a *simple* POV reader/writer?


Bye bye,
Wolfram.

Re: [Plib-devel] VRML Loader issues

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

Gil Carter wrote:

> There has also been a call for VRML1 support, as many CAD packages (and
> Blender) export this.  VRML1 is very similar to the Open Inventor file
> format, but it's quite a different language to VRML 97 - IOW, the '97
> parser won't read it.
> 
> Since there would currently be a path to get VRML1 into PLIB via a
> VRML1->VRML2 converter and the VRML97 loader, my initial plan was to get
> the VRML2/VRML97 parser done and then come back to VRML1.  With Blender's
> apparent export of VRML1, this might bump VRML1 support up the priority list.
> 
> So what do people think - VRML1 or VRML97 first?

When Chris sent me the first beta VRML97 loader, I searched high and low
on the web looking for VRML97 models to test it against - the only ones
I *ever* found were on the main VRML organisations's pages!

I conclude that VRML2/97 is a failed standard that hardly anyone actually
uses.

Hence - since there are quite a few VRML-1 models around and LOTS of tools
support it, then we should go with that.  Who knows, we might even get
an OpenInventor loader out of it 'for free' and with packages like COIN
floating around, this could become useful.

-- 
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] Work outstanding.

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

Paul Bleisch wrote:
> 
> Perfly is also "the ultimate judge" on whether a particular feature
> of Performer has been tested.  If it is in Perfly, you can almost
> guarantee the Performer team has looked at it.
> 
> A friend has said that it only took him a few tries to realize that
> you don't start from scratch with Performer, you start with Perfly.

Certainly a lot of people *do* start that way.

Unfortunately, when we started to use Performer, Perfly didn't exist!

-- 
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] Work outstanding.

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

Gil Carter wrote:

> >Probably it would be best to
> >have the performance monitor both in the engine and the modeler.
> >In the engine for the developer, so that he can see the performance
> >where it matters, with sound and ai etc going on.
> >In the modeler, the developer can quickly make changes, for example
> >that car model is too slow - lets try it with opaque windows.
> 
> Ok, but keep in mind that you're not just measuring how long it takes to
> render your car - you're really benchmarking the performance of PPE as
> well.  Even though PPE is underpinned by PLIB, if you're developing models
> for a game, your game engine is really the place to benchmark.

PPE (when not actually being given mouse clicks or key events) simply
calls PLIB's SSG  "ssgCullAndDraw" in a pretty tight loop.

If you set it up with the same clip planes, FOV and resolution as the
game, then it will produce identical timings for those graphics that are
done in SSG...obviously, the game's own menu's and icons won't get
timed.

That's as close as a separate application could possibly be.

So, that's why ssgStatistics needs to be a simple class you can add to
your game *as well* as in PPE.  In PPE it'll give the artist a good 'first
look' at the kind of performance he can expect.  Not perfect - nothing can
be - but since it saves him saving the model, shutting down PPE, starting the
game, playing through to the desired spot and *THEN* turning on the stats,
it's MUCH more likely that he'll actually check performance frequently.

I think that's a valuable tool - even if it's "off" by 10%.

> Maybe PPE could have a "preview" mode which goes fullscreen with no menus,

...the menu's don't redraw unless you click on them or something changes.
They impose no load just be 'being there'...hence no need to get rid of them.

> ...and just renders the current model with trace enabled to give you an idea
> of what type of performance you'll get in a standalone app.

Once 'gotcha' is that the very act of measuring stats costs time (a kind of
Heisenberg uncertainty effect!) - so you NEVER can get perfect statistics!

>  There are
> issues of still having all of the other OpenGL resources consumed to keep
> PPE alive in background, but at least you're not rendering four views of
> the model plus the user interface at each frame :-)

PPE can run happily with a single 3D window.  The four-view mode is optional.

You aren't re-displaying the GUI each frame - only if it changes.


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

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

Alexander Rawass wrote:

> > You just need to practice and learn GIMP.  It's not that hard to draw things
> > like instruments, little icons and such like.
> 
> No way. Not for me. Better a good game with bad graphics than to take
> this big big leap.

You don't have to do it full-time.  It's not like a maor career change - but
this is something you'll find to be an increasing necessity.  Drawing
things like your radarscope out of lots of little OpenGL commands just
doesn't make sense and expecting someone to come along and say "This game
that runs like a pig and looks terrible could be greatly improved if I
spend a few hours painting some pictures for him"...well, it's just
naive.
 

> > 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.
> 
> Why? My answer is:
> 
> it is commercially better to write a gaming engine and make 1,2,3,4 games
> out of it and sell them all for a high price, than to write the
> universal gaming engine that sells just once.

Well, commercially, the games industry made 7.2 billion dollars last year,
but only one game in 35 actually turned a profit.  By contrast, the Holliwood
movie industry made 7.4 billion and one in ten films turned a profit.

Game making is a **HUGE** and extremely risky business.  If you manage to
make a success out of game #1, you'll certainly be making game #2 with
pretty much the same themes/engine/etc.

Utterly universal game engines don't exist because they can't exist.
There is a galaxy of difference between a first person shooter game
engine like Quake or Doom and a flight simulation engine like FlightGear.
The idea that you can just change the model and program some different
behaviours in is very naive.
 
> I was pissed of by the fact that XwingAlliance had no 'strategic mode',
> I had already dumped KobayashiMaru in version 0.1.9 when I was pissed
> of by some friends of mine who claimed Homeworld to be great, but it's
> completely missing an action mode - I expect another will will have that
> and no action.
> 
> I am pissed of by ST Armada, I've seen it on a friends computer,
> the graphics are great but I haven't seen any feature that KobayashiMaru
> version 2.0.0 is not yet designed to have.

When you actually *have* all that working, I'll be impressed - but in the
meantime, it sounds very much like vaporware.  As your first 3D game,
it's unlikely that you could master one genre - let along three or four
in a single title.

> You told me in a former mail, that the abstraction layer between the game
> and plib costs time, put I am big in abstraction this times,
> and if you write a simple starfighter game, you suddenly lean back for
> a while, abstracting even more and more, and then you'll have a thing
> that can handle anything.

No - you won't.  You'll have an unimplementable design.

Start simple.  Design one game in one genre.  Just wait and see what
actually comes to bite you.  Simple things like collision detection,
best use of the Z buffer and where to place the camera are unbelievably
subtle - and DRASTICALLY different in every genre.  Also, that little thing
"performance" doesn't just appear from an abstraction layer - it has to
be tightly engineered at the lowest levels - the way you make a FPS run
fast is TOTALLY different than a space game or a flight sim.

> Just wait.

I don't have to.  I just hope I can pursuade you to make your first project
something remotely achievable so you don't get discouraged when it won't all
come together at the end.
 
> I have come to the conclusion that all these games are 'the same'.

Really, you couldn't be more wrong. FLightGear, TuxAQFH, TuxKart, TuxRacer
and others I have worked with couldn't be more different in approach.

> Lean back and abstract.

But eventually - just try to implement it all!
 
> I am only a 3D beginner, and these problems have either been solved
> already or will be solved with your help, but I think that I am
> very well capable in designing that huge game and writing it.

Well - I'm trying my very best to explain it to you - but you keep coming
up with grandiose plans - and my best advice as someone who'se been programming
this kind of thing for 27 YEARS is that you need to come down from this
ethereal plane and actually implement a couple of more tightly focussed
designs before you leap off into the void as you are about to do.

If you think you'll get a lot of help from me when I can clearly see what's
going to happen here - you have another think coming.  I'll quickly lose
patience and you'll end up on my mail filter list.

You are asking for advice - and I'm giving it.  Choose to ignore me if
you like - but don't expect more help if you do!

When you start to ask things like "How the heck to I draw Laura Croft's
boobs at a range of 10 centimeters - as well as the spiral arm of
galaxy XYZ-34 in the background?"
 or  "How do I allow space ships to
fly into holes in asteroids - as well as have people stay stuck to
the ground - and at the same time allow missiles to collide with
1,000 polygon spacecraft models"....remember my words.

> I've got so many ideas, I don't know where to start next.

It'll get *MUCH* worse before it gets better.
 
> > Remember that *very* likely you'll be doing it single-handedly with no
> > artistic or music input?
> 
> It will surely a game that will be a lot better than other commercial
> games, but I also think that graphics and sound will suck. Relatively.

A fancy game engine without good graphics will be *terrible*.  Good
graphics consume 95% of every game development team's time, 95% of
the time in the CPU, 95% of the disk space the game consumes.  If the
graphics suck - you are back to writing games like Tetris that don't
*need* fancy graphics.
 
> No one will of course play such a game, exept the Linux-GPL-Freaks,

...not even them.

> My friends told me the same - time will show, on which classes I'll
> continue working.

OK - so *everyone* is telling you the same thing.  People with 20 times
the experience in this stuff are telling you.

> > > I'd like also to include your 3D Terrain Rendering Engine in my game,
> > > if it could be easy to access it like
> >
> > 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.
> 
> No more than in Flightgear itself. You'll wonder how slow
> 'several times the speed of sound' can be in an action-type based game.

No - I won't - unless you have terrain that covers literally millions of
square miles and doesn't look 'sameish'.

> Or: the resolution of the terrain has to be decreased.

...at which point, the amount of 'optical flow' (tekky flightsim
term) will fall off - and it'll feel like you are going about 50 mph.

The Apollo 11 astronauts were flying faster than any man has travelled
before or since.  However, between the earth and the moon, the
resolution of the "terrain" is pretty poor - and they felt like they
were stationary.

When you get the amount of data up to where it *feels* really fast,
you'll need so much data that you'll have to page it in from disk in
realtime (that's what FlightGear has to do - and most of it's planes
fly at about 200mph!).

You can help this out by designing the high level game play to
make it undesirable or impossible to fly in a straight line for
more distance than the terrain you can hold in RAM - but now
your high level abstraction has to be bent to fit the ugly
facts of life.

You can't "abstract" your way past that in your game design.

You see there are *so* many things you don't know that FUNDAMENTALLY
affect the design of the game.  You'd have gotten all the way into
implementation before you realised that this was your problem - and then
you are suddenly faced with a MAJOR redesign so you can page stuff in from a
background task.
 
> > That's *VERY* naive.  Have you thought about collision detection yet?
> 
> At the moment, collsision checking in KobayashiMaru isn't done in
> plibssg level but on my intern logical level.

But collision (at least at the scale of ground-based simulation) requires
knowledge of where every single polygon is.  You can't do that without
plibssg.

> The same collision checking will work for cars - only, that the cars are
> limited in z axis to the HOT they're on.

Not good enough.  How will you detect when the car goes under a bridge?  Or under
the place where the bridge joins the terrain and there isn't enough room to
go under the bridge - but the side-walls are just to high to drive *over*.

What happens when your speed is so high that at the start of the frame you
are cleanly on one side of a brick wall - and at the end of the frame you are
cleanly on the other - you *should* have hit the wall on the way - but does
your algorithm solve that?  Efficiently enough?

Think you can solve that?   Now apply that algorithm to a spaceship going at
0.8 times the speed of light towards another spaceship on a collision course.

Done that?  Now worry about how our heroin can get into a small space if she
crawls - but not if she's standing up.  What happens if she crawls into a
passageway that GRADUALLY gets smaller until she can't fit anymore?

What happens if you are walking along parallel to a wall - carrying a long
weapon - and the player pushes the joystick to turn in to face the wall.
How do you stop the weapon penetrating the wall?  Did your collision
detection even *detect* that situation?

If the camera accidentally penetrates the wall, you'll see what's on the
other side of it.  Do you prevent that (very hard) or do you simply
design the high level game play so it never really matters?

This stuff is *HARD*.  Picking just one genre helps you to get through it.
 
> I _can_ do all the game logic - but I have to rely on 3D on people who
> know better, like you.

No!  You *can't* do all the game logic because it's horribly intertwined
with the 3D that you don't know enough about *yet*.

Look dude - I'm sick of these long posts where I tell you that you are
a newbie who doesn't understand how hard it is...then you tell me that
you have it all solved in your head somewhere.  Then I tell you that
I've been there and done that and it's HARD - and you wave the magic
"abstraction wand" so you don't have to think about it.

If you don't want to come down to ground level and think rationally
about what you can actually achieve (*especially* with no desire to
learn art skills) - then I'm not interested in talking to you anymore
because any attempt at help is just wasted effort.  I mean, it took
like FOUR posts to convince you that all that font stuff was the cause
of your slowness and *not* PLIB.  If you ask for advice, take it with
good grace or get out.

-- 
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] Quaternions in plib

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

Sam Stickland wrote:

> Quaternions have the
> advantage that they don't need to be reorthoganised _ever_,

...but they *do* have to be renormalized - and in theory, that's
just as arbitary as orthoganalization.

> ...and from my
> prespective four floats is a damn site better than twelve for network
> transmission (OK, so it's a naive implementation - you could get away with
> transmitting a single unsigned int if you used a lookup table.  Again
> quaternions would be quicker to lookup).

* For 3D rotation only, you only need nine floats to send a matrix - and for
  a quaternion, you only need to send three floats plus a sign bit.  Of
  course, Eulers only need three floats - so in terms of network
  bandwidth, they beat Quaternions by over 1% !   :-)

* Comparing a 4x4 matrix to a quaternion isn't fair.  A matrix can to
  a heck of a lot more than a quaternion - translation, scaling, perspective,
  shearing, projection onto an arbitary plane, *and* rotation.  Quaternions
  can only do the latter.

* Multiplying matrices together is faster than quaternions despite the
  larger number of terms because the math is simpler.

* Transforming vertices using a Quaternion is a *nightmare* compared to
  using a matrix.

* Quaternions score for interpolation, extrapolation and so forth.

Quaternions have their place - so do Matrices *and* Eulers...I have
rather a soft-spot for Quaternions - and what other mathematical
entity every had a bridge erected in honor of it's multiplication rule?

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