plib-devel

RE: [Plib-devel] PLIB developers needed.

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

Roger, wilco.  Tonight.  Maybe.

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.

> Hmm..
> I bet you need SSH.
> 
> Cheers
> 
> Norman

RE: [Plib-devel] PLIB developers needed.

[Norman V. <nh...@ca...>]

Mark K Vallevand writes:
>
>No, I'm a Netscape guy (always have been, always will be).
>But, I didn't login from Netscape.  It wasn't even up.  I was
>doing this all from the command line.  WinNT 4.0 SP6a.  I use
>ksh from MKS Toolkit as my shell.  I didn't use SSH.

Hmm..
I bet you need SSH.

FWIW
I use the Cygwin Toolkit V1.1.4

and SSH from
   - package availability
     - on ftp.franken.de
     - in /pub/win32/develop/gnuwin32/cygwin/porters/Vinschen_Corinna/V1.1.3
     - as openssh-2.1.1p4.tar.gz,
          openssh-2.1.1p4-src.tar.gz

and CVS from
  ftp://sourceware.cygnus.com/pub/cygwin/private/cygwin-extras-392/

and am having no problems from a bash shell in Win98
uploading to sourcegear via SSH.

The latest Cygwin SSH is almost painless :-)

Cheers

Norman

RE: [Plib-devel] PLIB developers needed.

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

No, I'm a Netscape guy (always have been, always will be).
But, I didn't login from Netscape.  It wasn't even up.  I was
doing this all from the command line.  WinNT 4.0 SP6a.  I use
ksh from MKS Toolkit as my shell.  I didn't use SSH.

I'll try logging in from Netscape next time.  I'll try with
and without SSH.

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: Norman Vine [mailto:nh...@ca...]
> Sent: Wednesday, August 09, 2000 12:49 PM
> To: pli...@li...
> Subject: RE: [Plib-devel] PLIB developers needed.
> 
> 
> Mark K Vallevand writes:
> >
> >I'm supposed to have CVS write access to PLIB, but it doesn't
> >work.  I have the ssgVtxArray changes to use shorts in the
> >ssgIndexArray instead of ints.  Its ready to commit.  The
> >commit says I don't have write access.
> >
> >Here is what I did:
> >- anonymous checkout of all of plib;
> >- verify that plib still works for me (it does);
> >- checkout (as markus5, my sourceforge ID) the 3 files that 
> >are changing;
> >- change the files;
> >- commit (as markus5) the 3 files that changed.
> >
> >The commit says I don't have write access.
> >Any ideas?
> 
> Hmm..
> 
> Are you using Internet Explorer ??
> 
> If so login from http://www.sourceforge.net 
> and click the leave SSL mode box
> more Info on login page
> 
> Norman
> 
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
> 

RE: [Plib-devel] PLIB developers needed.

[Norman V. <nh...@ca...>]

Mark K Vallevand writes:
>
>I'm supposed to have CVS write access to PLIB, but it doesn't
>work.  I have the ssgVtxArray changes to use shorts in the
>ssgIndexArray instead of ints.  Its ready to commit.  The
>commit says I don't have write access.
>
>Here is what I did:
>- anonymous checkout of all of plib;
>- verify that plib still works for me (it does);
>- checkout (as markus5, my sourceforge ID) the 3 files that 
>are changing;
>- change the files;
>- commit (as markus5) the 3 files that changed.
>
>The commit says I don't have write access.
>Any ideas?

Hmm..

Are you using Internet Explorer ??

If so login from http://www.sourceforge.net 
and click the leave SSL mode box
more Info on login page

Norman

RE: [Plib-devel] PLIB developers needed.

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

I'm supposed to have CVS write access to PLIB, but it doesn't
work.  I have the ssgVtxArray changes to use shorts in the
ssgIndexArray instead of ints.  Its ready to commit.  The
commit says I don't have write access.

Here is what I did:
- anonymous checkout of all of plib;
- verify that plib still works for me (it does);
- checkout (as markus5, my sourceforge ID) the 3 files that are changing;
- change the files;
- commit (as markus5) the 3 files that changed.

The commit says I don't have write access.
Any ideas?

My PLIB changes are here, if anyone cares:
http://vallevand.homepage.com/plib/ssg.h
http://vallevand.homepage.com/plib/ssg.cxx
http://vallevand.homepage.com/plib/ssgVtxArray.cxx

I'd prefer not to ask Steve to commit the changes, so any ideas about
how I messed up are appreciated.

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.


> There are a couple of hundred people subscribed to the 
> various PLIB mailing
> lists.  Would anyone else like to step forward as an active developer
> (with CVS write access) ?
> 
> -- 
> Steve Baker 

Re: [Plib-devel] KobayashiMaru & plib

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

Hi,

> > It's goal is to write a flexible, extensible, multi-platform (blah blah
> >  blah :-) Space Fight Simulator in 3D
> 
> Have you had a look at Parsec (http://www.parsec.org)?
> 
> I know that they don't publish their source (but IIRC they plan to
> release the game itself for free)...
> 
> It'll be at least interesting to get some new ideas. They've also got a
> few papers online (they are CS students; Parsec is their 'playing
> ground' for their ideas) which are very interesting IMHO.

HaHaHa - Parsec is no danger for my project.

When I first heard of Parsec, I had already written enough code, and
I was relieved to see that there is nothing and that they have
nothing exept some films, some sounds, no code, no source, nothing
you can really do with.

Now they they've got a selfrunning demo in glide. I don't have glide.

I don't know why they are building up a secret cathedral, I
dont't know why (for a 'free' game) they don't go open source,
it's simply a behaviour I cannot understand.

I am writen on KobayashiMaru since the start of the year, with very
long pauses inbetween, and I think I am quicker than them (exept
for models and gfx) and I am quite shure, that my game will be
of course be better than theirs, simply because it is open source
AND it is designed to be completely extensible, and if KobayashiMaru
will get developed further, it may grown so something which is bigger
and better, I want it to make it to a universal action/shooting
gaming engine, while Parsec will rot on disks and begin to
foul on the CDs, because the Heart will get no new blood.

Yes, I am truly an Open Source Freak.

I would gladly have dumped KobayashiMaru if Parsec would have been
the better one, to help extend Parsec to the thing I want, but
this is only possible with open source.


Alex


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

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

Hi,

Steve wrote:

> > > The artists working on StarTrek must have wanted to go home early on
> > > the day they designed the Borg ship!  :-)
> > 
> > _AND_ the idea of the borg is stolen from Perry Rhodan, they call them
> > 'Posbis'
> 
> Really!  I don't remember that.

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

> > > How many polygons are you drawing - and what kind of frame rate are
> > > you getting - with what percentage of your CPU time going into ssgCullAndDraw?
> > 
> > With lots of objects it goes very high (yes,not very precise).
> > But I have yet models with far too much polygons and have no level of
> > detail (due to shortage of models) - I didn't look, is there a routine
> > like countPolygons(scene/entity)?
> 
> No - but you can easily hack one into SSG.
> 
> Look in ssgVtxTable.cxx - find the 'draw_geometry' routine and add up the
> number of vertices and polygons right there - into a global variable somewhere.

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

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

> > I read this on the plib page, but I hat a snippet of code that worked,
> > I will time it and probably change.
> 
> If you ARE using GLUT text, I can tell you for *SURE* that that's the major reason.
> 
> Think about it.  For EVERY letter you draw, you are sending (say) an 8x10 pixel
> rectangle of pixels to the frame buffer.  With full RGBA, that's 8x10x4 = 320 bytes
> per character.  You are drawing a couple of hundred letters - so you are downloading
> maybe 64Kbytes into the graphics card every frame - several megabytes per second
> at reasonable frame rates.
> 
> On the other hand, if you use textures, you have all those letter shapes stored
> in a texture map that's already down on the card.
> 
> More than that, many PC graphics cards have to 'flush' their polygon buffers in
> order to allow the CPU to get access to the frame buffer - that can cause a major
> stall in your CPU when you first start drawing bitmapped characters.
> 
> Anyway - this is a REALLY common problem for people who are doing this for the
> first time.
> 
> Come to think about it - one of my FAQ documents is all about this stuff.

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

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

> > > However, for a fast action game, nobody will have time to read all that tiny
> > > text anyway.  It's generally considered a good idea to use as little text
> > > as possible in a game - preferably none at all.
> > 
> > The text will even get more - the game is far from being 1.0.0 , and most
> > output is more or less debugging ;-)
> 
> Well, I think you should stop and think about that.

I'll use puFnt as soon as I can.

> > > Also, that spider's web looking thingy - I presume it's a radar display - is
> > > consuming a LOT of throughput if it's being drawn as OpenGL lines - there appear
> > > to be at least 120 lines being drawn.  Most PC graphics hardware does a very poor
> > > job of drawing lines - so you'd be better off painting a really nice radar display
> > > in GIMP (or whatever paint program you prefer) - and drawing that as a single
> > > textured quad.
> > 
> > Yes. But I am as bad in drawing images as for modeling.
> 
>   :-)
> 
> Write a program that does a 'glReadPixels' of the graphic you have now - save
> it into a file that you can draw (as a texture) instead of the original.
> 
> You really *will* need to use some minimal painting skills before you are
> done with this game.

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

> > > SSG already acts as a portability layer - why go and build a portability
> > > layer ON TOP of a portability layer?
> > 
> > Some time I ago I tried to download/compile many 2D-linux games, and
> > some of them seemed to me to have exactly this feature, to compile
> > for different bitmap-handling libraries, and I wanted this feature.
> 
> Yes - but for 2D, that's necessary - you have console mode, SVGA, GGI,
> X-windows, etc.
> 
> For 3D, there is exactly ONE low level standard for Linux...and most
> other OS's - OpenGL.  Hence the need to be able to run on multiple
> standards is almost zero.

Good point.

> > Also, I could go and say, hey, here's KobScene, an open source
> > SceneGraphHandler, for whoever might need it.
> > It's also a possiility to benchmark different scenegraphs.
> > Just for interest.
> 
> I guess.  I'd do that at the outset of the project - then pick one
> and run with it.

I'd rather want _them_ to do it for me, since I don't have time ;-)

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

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

> > > There are also some others that you missed - OpenSG for example.
> > 
> > Bah!
> > 
> > I've checked their Homepage for over three months, it didn't change,
> > no bits of code. Nothing exept announcements.
> 
> I spoke to the guy who wrote it at SigGraph (actually - I think he's
> subscribed to this list)...I think it has promise - although perhaps
> not in the area that PLIB is intended for.

Is there anything yet available exept that announcement?

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

> > But maybe it's just so that I think that a game like a Star-
> > Fighter game will have to be faster and more complex than
> > a game like Tux.
> 
> I doubt that you'll need as many polygons as Tux - at least
> in deep space.  I guess if you are skimming along the surfaces

Not if I'm heading for BIG BIG action!

> of planets then you have something more like a flight simulator...
> like FlightGear for example...hmmm - I wonder what that's
> written in?  (Hint: Begins with a 'P')

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

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

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

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

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

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

> > Actually, I've mo idea.
> 
> Well, exactly - and that's why I resent you saying that PLIB
> is
> slow.  People who may be thinking of using PLIB will use a search
> engine to look for other people who use it.  If they find your
> page and it says PLIB is slow then they'll run a mile.
> 
> So - you have to be scrupulously accurate.  Your web page should
> say "My game is slow - I don't know why."....So quit telling the world
> that my library sucks - at least until you manage to show that it
> really does suck - and in a way that we can't easily fix.

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

> > >   These are things that it's easy enough to change - and keeping
> > > it 'clean' of other people's intellectual property is really
> > > important for GPL'ed software.
> > 
> > There may come a time when it's necessary to say things like
> >    sed 's/KobayashiMaru/TuxFleet' `find .`
> > but I have chosen to wait.
> 
> Yep - that *could* work...but it may not be enough once you have
> licensed a gazillion copies to people under GPL.  You could
> be liable for (say) a $10 licensing fee for every copy you
> gave away!  15,000 people downloaded Tux_AQFH.  Think about it!

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

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

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

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

Please be aware that I'm only joking.



Alex

RE: [Plib-devel] PLIB developers needed.

[Fay J. F C. AAC/W. <joh...@eg...>]

What does being a PLIB developer entail?  I'm interested in supporting PUI,
but my day job keeps getting in the way.  How many hours a week are you
talking about?  What sort of things does a formal developer do?

John F. Fay
joh...@eg...


-----Original Message-----
From: Steve Baker [mailto:sjb...@ai...]
Sent: Tuesday, August 08, 2000 21:42
To: PLIB-devel
Subject: [Plib-devel] PLIB developers needed.



I'm feeling severely swamped by the amount of PLIB stuff that's heading
my way recently.  There have been a lot of really good things offered - but
I just don't have time to fit them all in.  Dave is doing great work - but
we really need a couple more people just like him!

There are a couple of hundred people subscribed to the various PLIB mailing
lists.  Would anyone else like to step forward as an active developer
(with CVS write access) ?

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



_______________________________________________
plib-devel mailing list
pli...@li...
http://lists.sourceforge.net/mailman/listinfo/plib-devel

Re: [Plib-devel] PLIB developers needed.

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

What things need to be done?

However, if I would be become a plib-developer, 
prettypoly would stay my main project.

BTW, it *MIGHT* be that I have to rewrite the
*.x loaders/writers in Mdi_edit in some time, then I would 
probably write some for plib at the same time.
*.x is Micro$ofts Direct3D file format, mainly used for games.
Dave (or anybody else), if I want to see how a loader/writer works,
which should I look at? It should be farily easy to understand,
fairly complete and the format should be fairly straight-forward
(list of vertices/list of faces).
Its absolutely not clear I would do this, but if then I will probably
only implement the ASCII-*.x-format, not the binary one.

Bye bye,
Wolfram.

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

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

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

Bye bye,
Wolfram.

Re: [Plib-devel] PLIB developers needed.

[Gil C. <g.c...@ca...>]

I'm registered as gilcarter at Sourceforge.  If Steve adds me to the CVS 
write crowd, there's no more excuses...

Gil

Re: [Plib-devel] PLIB developers needed.

[Gil C. <g.c...@ca...>]

At 09:41 PM 8/8/00 -0500, you wrote:

>I'm feeling severely swamped by the amount of PLIB stuff that's heading
>my way recently.  There have been a lot of really good things offered - but
>I just don't have time to fit them all in.  Dave is doing great work - but
>we really need a couple more people just like him!
>
>There are a couple of hundred people subscribed to the various PLIB mailing
>lists.  Would anyone else like to step forward as an active developer
>(with CVS write access) ?

(Casts eyes down, scrapes toe in dirt, rubs back of neck)

Ahem, yes. I won't try to make excuses for where my commitment has gone, 
other than to point you guys at another "interesting" project called 
matterial, a compositor/non-linear editing system for Linux.  It's early 
days at the moment, but have a look at http://matterial.sourceforge.net/ if 
you're interested.

I did promise great things with VRML import/export which never got 
finished.  I guess I should commit to doing some more work on that, plus 
other things as required.  The McClurg dynamo has part of the VRML work 
done for Blender, but my lex/yacc stuff is probably a more general solution.

There's also a chance that I will be making use of PLIB - more specifically 
SSG - for some new work here at CSIRO, so I might have a "real" reason to 
work on it soon.  Basically, I've been trying to find a commercial scene 
graph toolkit which is fully supported, and works across NT and Linux.

Pretty hard thing to find - a lot harder than I thought it would be:

* Open Inventor doesn't really do what we need, and is Yet Another Dead 
Scene Graph
* OpenGL Optimizer is even deader than Inventor
* Viskit would be great if Paradigm decide to start supporting it again - 
and if it ran on Linux.
* R3 Vis Corporation's RM Scene Graph isn't shipping yet, and Open RM is a 
little unknown
* Iris Performer is great, but no chance of ever running on NT while SGI 
still exists :-)

SSG looks pretty good in comparison to this bunch, so it's really in *my* 
interests to help keep it going.

FWIW, my most likely use for SSG is for a terrain system for flythroughs of 
large scale mining models.  Lots of textures, lots of hi-res meshes, lots 
of problems...  My most likely addition to SSG for my work here is a CLOD 
system, whether it be quadtree, ROAM, VIPM or something else.  My biggest 
concern is that I might not be allowed to contribute my source back because 
of IP restrictions on our research.

So what else is needed at the moment?  Perhaps something which isn't quite 
work-related might be good :-)

Regards,

Gil

[Plib-devel] PLIB developers needed.

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

I'm feeling severely swamped by the amount of PLIB stuff that's heading
my way recently.  There have been a lot of really good things offered - but
I just don't have time to fit them all in.  Dave is doing great work - but
we really need a couple more people just like him!

There are a couple of hundred people subscribed to the various PLIB mailing
lists.  Would anyone else like to step forward as an active developer
(with CVS write access) ?

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

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

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

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

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [Plib-devel] RE: plib, glut and SDL

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

Ben Woodhead wrote:
> 
> Well thanks for your information, no one was able to give me an example of
> were glut would actually crash, I wrote a message to the people that where
> telling me not to use glut and to use sdl instead because glut is not fast
> or stable enough for games but none of them where able to send me any code
> to actually make glut crash.

I don't think people are generally accusing it of crashing.

The (unfounded) complaints I've heard are that it's somehow going to get
very inefficient when a "full up game" is attempted using it.

Anyway - it's an 'urban legend'...don't sweat it...tell your friends!


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

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

Hi,

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

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

Alex

RE: [Plib-devel] hpr?

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

And the angles are measured clockwise, or like a compass.  Not anti-
clockwise like trig textbooks.  That bit me hard.

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.

> It's heading (around z axis), pitch ( around x axis), roll 
> (Around y axis).
> 
> Sam 

Re: [Plib-devel] hpr?

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

----- Original Message ----- 
From: "Philippe C.D. Robert" <ro...@ia...>
To: <pli...@li...>
Sent: Tuesday, May 02, 2000 8:55 AM
Subject: [Plib-devel] hpr?


> Hi,
> 
> I have just a simple question... how exactly are the hpr angles defined
> (what coordinate axis order, which direction)? 

It's heading (around z axis), pitch ( around x axis), roll (Around y axis).

Sam

RE: [Plib-devel] ssgVtxArray fixes.

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

Yes, the MSVC project files seem to be slightly broken.  I've fixed them
up for myself, and will try to check them in real-soon-now.  But, I want
to double check that they are really what they should be.  The latest CVS
works fine, except for the minor project file tweeks.  If you want to fix
them up, go ahead. 

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: Tuesday, August 08, 2000 1:11 PM
> To: pli...@li...
> Subject: Re: [Plib-devel] ssgVtxArray fixes.
> 
> 
> "Vallevand, Mark K" <Mar...@UN...> wrote:
> 
> >I'm going to get the latest CVS tonight, and try it out.
> 
> Good!
> Could you please try to compile plib and the examples "straight out of
> the box"? It seems to work for Dave, but I still think the
> MSVC-project-files are slightly broken. I am prepared to fix it, but
> only if we are sure its broken :-).
> 
> >Regards. 
> >Mark K Vallevand   ma...@rs... 
> 
> Bye bye,
> Wolfram.
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
> 

Re: [Plib-devel] KobayashiMaru & plib

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

Steve wrote:

>The "matrices can be your friend" document is an example one of
>those documents you either love or hate.  Several mathematicians have
>come close to death threats over it.  

Strange. I don't really see why. As far as I see, what you do is
mathematically correct. In mathematical speak, you choose a basis
in one coordinate system, namely the straight-forward basis
(0,0,1), (0,1,0) and (1,0,0) and then look at the transformed
vectors, which will again be a basis of three dimensional space as
long as the matrix is nice enough :-), that is as long as it is
invertible.

When I started with computer graphics, I knew matrices quite well
and had no problem understanding that they can be used to transform
vertices etc. However, I didn't understand at once why it is
advantageous to use them versus rotating, translating and projecting
the vertices "manually". 
The point why 4x4 matrices (or at least 4x3 if you don't have
projection) are effective and why you don't use 3x3 matrices is that
translating - which normally means adding numbers - has been converted
into multiplications. This means instead of transforming the vertex
with operation1, then operation2 etc you can multiply all the matrices
and then transform each vertex only once. For a slight overhead
(multiplying all the matrices) you save something per vertex. For
example, if A and B are matrices and v is a vertex, then you may
calculate either

A*(B*v) 

or 

(A*B)*v

For n vertices, the first costs n*(16+16) multiplications,
the second costs once 16*4 multiplications and then for each vertex
another 16. This means for five or more vertices its faster to merge
all transformations into one large one. This is only possible via
matrices or equivalent stuff.
Steve writes all this in one sentence in his FAQ :-).

>If only math teachers could figure out the importance of teaching
>*some* students that way.

Most things can be taught in a variety of ways. For example I once saw
an article that you can explain the formula pressure=force/area
in five completely different ways. For example you can start with
"if you double the area, the force will double". Or you can 
try it experimentally and say the harder you push the nail into you
flesh, and the smaller its "front area", the higher the pain ;-).

But it is always difficult to teach in several ways, since you don't
have as much time and since this will often cause additional
confusion. Even people who understand the first explanation
can be confused by the second if it doesn't fir their way of thinking.

Bye bye,
Wolfram.

Re: [Plib-devel] ssgVtxArray fixes.

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

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

>I'm going to get the latest CVS tonight, and try it out.

Good!
Could you please try to compile plib and the examples "straight out of
the box"? It seems to work for Dave, but I still think the
MSVC-project-files are slightly broken. I am prepared to fix it, but
only if we are sure its broken :-).

>Regards. 
>Mark K Vallevand   ma...@rs... 

Bye bye,
Wolfram.

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

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

Alexander wrote:

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

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

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

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

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

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

Bye bye,
Wolfram.

[Plib-devel] An example of ssgVtxArray usage

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

I've uploaded a very preliminary version of a useful class for
animation in games.  Its also useful for seeing how ssgVtxArray
can be used and its limitations.

http://vallevand.homepage.com/plib/WavingFlag.h
http://vallevand.homepage.com/plib/WavingFlag.cpp

The class implements a flag waving in the wind.  Its optionally
textured on both sides.  The flag is 1.0 by 1.0 units and is in
the y-plane with lower left coords (0,0,0) and upper right coords
(1,0,1).  The wind blows from -x to +x.  You can translate and
scale it as needed, and rotate it around the z-axis for wind
direction.  But, it should not be rotated about other axis because
you'll loose the effect.  

The class illustrates ssgVtxArray usage to share vertex info
between triangle strips.  It also illustrates one limitation:
if a vertex is used for both faces of an object, the normal for
the vertex will be outward-facing on one side and inward-facing
on the other.  So far, this hasn't caused any problems for me.

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: Steve Baker [mailto:sjb...@ai...]
> Sent: Monday, August 07, 2000 8:16 PM
> To: pli...@li...
> Subject: Re: [Plib-devel] plib, glut and sdl
> 
> 
> Ben Woodhead wrote:
> 
> > A while ago I was talking with serveral people regarding 
> glut 3.7 (game
> > glut). From what they where saying is that the glut 
> libraries can't handle a
> > large amount of load and would not be good to us in games.
> 
> This nonsense is repeated often - but NEVER with specific details of
> WHY and WHERE GLUT is supposedly so slow.  In fact, it's 
> complete B.S which
> has "become true" by virtue only of having been oft repeated.
> 
> You only use GLUT calls to open the windows initially - to 
> read low-speed
> peripherals (like keyboard and mouse) - and to handle window events.
> 
> Games dont *do* enough of those things for GLUT to be a load.
> 
> If in doubt, look at the GLUT code for the main event loop - 
> it scarcely
> executes a dozen lines of C per event.  I would be VERY 
> suprised if GLUT
> consumed more than a hundred lines of code per frame.  On 
> anything post-Z80
> that's negligable!
> 
> The *only* place I've heard remotely believably, specific 
> complaints - is
> that under Windoze, GLUT uses one of the less good API's for 
> reading the
> mouse.  I'm told that red-hot Quake-heads can tell the 
> difference...however,
> who has done the same studies for alternative window-handlers 
> like SDL?
> 
> Honestly, I'd use GLUT - or possibly even 'freeglut' 
> (freeglut.sourceforge.net).
> If you genuinely find the mouse mechanism to be too slow 
> under windoze - then
> switch to the fast mechanism and offer your change as a patch 
> for each of those
> versions of GLUT....I don't think you'll ever find a need to do that.
> 
> > So I was able to hack the tux_example to us SDL instead and 
> it seemed to
> > work fine, but plib was still compiled to use glut. I also 
> read some plib
> > docs and somewere I read that plib can be used with or 
> without glut, is that
> > the case. Would sdl be a better option then glut, would it 
> take a lot of
> > work to change plib to sdl instead.
> 
> Well, the only things PLIB uses GLUT for is:
> 
> a) In PUI: Finding the size of the current window.
> b) Optionally - in PUI: to render fonts when you don't
>    want to use PLIB's own font library.
> 
> However, if your only reason for going to all this trouble is because
> you've heard that GLUT is no good for games - then I'm afraid you have
> been wasting your time.
> 
> Morover (and more seriously IMHO), SDL is not generally installed by
> default with OpenGL implementations - where GLUT is.  Hence you've
> added a significant additional dependancy to your program - which will
> make it much harder for your poor users.
> 
> I've had a heck of a lot of problems with SDL in applications I've
> downloaded.  Because SDL is (like PLIB) made of a bunch of component
> libraries, but (unlike PLIB) releases each component out-of-sync
> with the others, you tend to find that each game needs a different
> set of versions of the sub-packages.  Since some versions of some
> SDL modules are incompatible with other versions of others - I think
> that maintenance of a package that uses SDL is going to be quite
> challenging!
> 
> Also, I don't think SDL is as portable as GLUT...although I could
> be wrong about that.
> 
> SDL is getting quite popular though - so I suppose these things
> will eventually settle down.
> 
> -- 
> 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
> 
> 
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
> 

RE: [Plib-devel] ssgVtxArray fixes.

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

I didn't have time to make any changes last night, however, my
inclination is to support both shorts and ints, unless someone
presents a strong argument for only shorts.

The latest CVS with the ssgVtxArray changes works just fine.  I
was able to get that far...

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.

> Yep - when you called 'glDrawElements' you said:
> 
>    glDrawElements ( gltype, num_vertices, GL_UNSIGNED_INT, ii ) ;
>                                           ^^^^^^^^^^^^^^^
>                                      Change this to
>                                      GL_UNSIGNED_SHORT
> 
> ..you can also pass GL_UNSIGNED_BYTE - but I think that's *too* small.
> 
> This would be a non-reverse-compatible change though - how many people
> are using ssgVtxArray and would be upset by such a change?
> 
> -- 
> Steve Baker   

[Plib-devel] RE: plib, glut and SDL

[Ben W. <be...@bg...>]

Well thanks for your information, no one was able to give me an example of
were glut would actually crash, I wrote a message to the people that where
telling me not to use glut and to use sdl instead because glut is not fast
or stable enough for games but none of them where able to send me any code
to actually make glut crash.
Thanks for the information, sorry if this bothered anybody.
Cheers, Ben