plib-users

Re: [Plib-users] accessing the camera-/modelview-matrix

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

Volker Poplawski wrote:
> 
> I'm playing around with plib/ssg in combination with Qt. I wonder why there
> is no method to directly set the cameraMatrix in ssgContext.

What's wrong with:

   ssgContext::setCamera ( sgMat4 mat )

...or...

   ssgSetCamera ( sgMat4 mat ) ;

(which operates on the current context for backwards compatibility)

> Is this a missing feature or is there a smarter way to do it?

I think maybe it's not documented.

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net

[Plib-users] accessing the camera-/modelview-matrix

[Volker P. <pop...@in...>]

I'm playing around with plib/ssg in combination with Qt. I wonder why there 
is no method to directly set the cameraMatrix in ssgContext.
I want to apply my own modelview transformation after i've set up the camera 
with setCameraLookAt(). getModelViewMatrix() gets me the current 
cameraMatrix, but how do i set it after i have applied my multiplication to 
it?
Calling glSetMatrixf( myMatrix ) doesn't help cause ssgCullAndDraw( ) will 
set cameraMatrix as model-view-matrix again.

Is this a missing feature or is there a smarter way to do it?

greetings
.......Volker

Re: [Plib-users] Don't Do This!

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

Christian Mayer wrote:
> 
> Steve Baker wrote:
> >
> > ha...@sl... wrote:
> > >
> > > >I wrote up an Omniverous Biped FAQ item about this:
> > > >
> > > >  http://www.sjbaker.org/steve/omniv/index.html
> > > >
> > > >...check out "Keyboards Are Evil".
> > >
> > > Now, not to disagree with what you've figured out, as I'm sure it's
> > > correct, but...  Whats weird is I've seen several older windows games that
> > > did exactly this, with two players.  One in particular was action based,
> > > kinda like a player versus player asteroids game.  I wish I could
> > > remember the name.  You picked a space ship (each had different
> > > speeds/weapons/etc).  You had to thrust, rotate and fire - all sharing
> > > the same keyboard.
> >
> > I didn't say it was impossible - if you pick the right keys, it can work.
> >
> > (eg Q,W,E,R as Turnleft/Thrust/TurnRight/Fire for player 1,
> >     Y,U,I,O as the same for player 2...that works just fine).
> 
> Does the num pad count extra? If that's so than two players should be
> possible.

If you look at my FAQ:

  http://www.sjbaker.org/steve/omniv/index.html

You'll see a table at the bottom of the page showing (for my keyboards
at least) what the decoder's matrix looks like.

It predicts that holding down (for example) 'R' and 'T' will
block 4,5,6,7,8,9 and + on the keypad...<tries it>...and it does!

Really, no keys are immune to the effect.  You just have to *carefully*
pick keys that either all occupy different rows - or all occupy different
columns.

So, looking at that table in the FAQ, you'll see that there are 8 rows
and 18 columns.

Ack! I accidentally typed my table in 'sideways'...and I'm *certainly*
not going to type it in again. Tables are a pain in HTML!.


   Conclusion: You can have at most 18 keys active in the game.


However, it gets worse.  

Some columns of the matrix only have wierd keys like Left-Meta or Right-Meta
that are something of a pain to read in most window libraries...and
which can have unintended consequences.  (You wouldn't want to write
a game that could result in player 1 pressing Ctrl, Player 2 pressing
Alt and Player 3 pressing Del or Backspace in the heat of the action!!)

So, if we eliminate the columns containing only 'dangerous' keys,
we have 14 or maybe 15 keys left (depending on what 'PrintScreen' does).

That's certainly not enough for a four player mode for my game - and
even in 3 player mode, one of the players has to uses SysRequest/PrintScreen
as one of his keys in order to have 5 keys each - and I really wanted
at least six keys per player (North,South,East,West,Jump,Fire) and had
really hoped for something like 10 or 15 per player.

So, I'm left with two player mode as the only possible setup and only
seven keys each.

I can do a *little* better by knowing that you won't often want to press
North and South together - or East and West together...but still, I should
try to ensure that when a player does that by mistake, it doesn't mess up
his competitor.

There would also be *easy* scope for covert cheating!  Just hold down the
right key combination to block the other player's Fire button!  The game
could actually detect that and flash up a "CHEAT!" warning.

Another way to increase the number of commands per player would be to
write the code in a way that would discourage holding some of the keys
down for a long time.  For example, if holding down the 'Jump' button
for more than some small amount of time caused the player to trip and
fall flat on his face, then I could use more than one key in that column,
accepting the small probability of a short-term key lock-out.

There is also the issue of i18n.  There are at least a dozen keyboard
layouts in the world - and some (such as the 'AZERTY' design which has
A and Z where most people would expect Q and W to be) will need different
key assignments...then there are people who remapped their keyboards and
swapped the keycaps around to do a Dvorjak layout or something.

Most worrying of all is that I've only tested this out on the four keyboards
I have at home (Casio laptop, Fujitsu laptop and two different no-name
ergonomic 'split' keyboards).  There is no reason at all why some other
brand might not have a different keyboard decoder with a different key
matrix.  The PC and it's software wouldn't care - but the combinations
of keys that would lock out could be totally different.

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net

Re: [Plib-users] Don't Do This!

[Christian M. <ma...@Ch...>]

Steve Baker wrote:
> 
> ha...@sl... wrote:
> >
> > >I wrote up an Omniverous Biped FAQ item about this:
> > >
> > >  http://www.sjbaker.org/steve/omniv/index.html
> > >
> > >...check out "Keyboards Are Evil".
> >
> > Now, not to disagree with what you've figured out, as I'm sure it's
> > correct, but...  Whats weird is I've seen several older windows games that
> > did exactly this, with two players.  One in particular was action based,
> > kinda like a player versus player asteroids game.  I wish I could
> > remember the name.  You picked a space ship (each had different
> > speeds/weapons/etc).  You had to thrust, rotate and fire - all sharing
> > the same keyboard.
> 
> I didn't say it was impossible - if you pick the right keys, it can work.
> 
> (eg Q,W,E,R as Turnleft/Thrust/TurnRight/Fire for player 1,
>     Y,U,I,O as the same for player 2...that works just fine).

Does the num pad count extra? If that's so than two players should be
possible.

CU,
Christian

--
The idea is to die young as late as possible.        -- Ashley Montague

Whoever that is/was; (c) by Douglas Adams would have been better...

Re: [Plib-users] Don't Do This!

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

ha...@sl... wrote:
> 
> >I wrote up an Omniverous Biped FAQ item about this:
> >
> >  http://www.sjbaker.org/steve/omniv/index.html
> >
> >...check out "Keyboards Are Evil".
> 
> Now, not to disagree with what you've figured out, as I'm sure it's
> correct, but...  Whats weird is I've seen several older windows games that
> did exactly this, with two players.  One in particular was action based,
> kinda like a player versus player asteroids game.  I wish I could
> remember the name.  You picked a space ship (each had different
> speeds/weapons/etc).  You had to thrust, rotate and fire - all sharing
> the same keyboard.

I didn't say it was impossible - if you pick the right keys, it can work.

(eg Q,W,E,R as Turnleft/Thrust/TurnRight/Fire for player 1, 
    Y,U,I,O as the same for player 2...that works just fine).

Also, if you make the game so that a quick tap on the keyboard is all you
need then it's *unlikely* (but not impossible) for something to go wrong.

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net

Re: [Plib-users] Don't Do This!

[<ha...@sl...>]

>I wrote up an Omniverous Biped FAQ item about this:
>
>  http://www.sjbaker.org/steve/omniv/index.html
>
>...check out "Keyboards Are Evil".

Now, not to disagree with what you've figured out, as I'm sure it's
correct, but...  Whats weird is I've seen several older windows games that
did exactly this, with two players.  One in particular was action based,
kinda like a player versus player asteroids game.  I wish I could
remember the name.  You picked a space ship (each had different
speeds/weapons/etc).  You had to thrust, rotate and fire - all sharing
the same keyboard.

--
Brian

Re: [Plib-users] Don't Do This!

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

Cameron Moore wrote:
> 
> * sjb...@ai... (Steve Baker) [2001.12.30 21:32]:
> > The rule is approximately that if you hold down three keys that form
> > the corners of a rectangle on the keyboards 'scan matrix' (E, C and I
> > for example) then depending on the age of your keyboard, you'll either
> > find that the third key you press will be ignored *or* the key at the
> > fourth corner of that rectangle will appear to be pressed even though
> > it isn't!
> 
> Hmm...that is weird.

Yes - exactly.

> You want four people using the same keyboard?  Have you had too much
> egg nog?  :-)

Well, no - but once you've written it for two players, it's only two
more lines of code to allow three or four.

>  Seriously though, I don't think I've ever played a PC
> game where more than two people used the keyboard at the same time...

It emerges that there is a *reason* for that!  :-(

> and it seems impracticle to think people would want to in the first place.

You'd be suprised what kids will do.  We've played glTron that way - it's a blast!

> Anyway, I wasn't aware of the goofy PC keyboard behavior you are brought
> up.  Thanks for bringing it up...

I didn't want anyone else to suffer that amount of pain!

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net

Re: [Plib-users] Don't Do This!

[Cameron M. <li...@to...>]

* sjb...@ai... (Steve Baker) [2001.12.30 21:32]:
> The rule is approximately that if you hold down three keys that form
> the corners of a rectangle on the keyboards 'scan matrix' (E, C and I
> for example) then depending on the age of your keyboard, you'll either
> find that the third key you press will be ignored *or* the key at the
> fourth corner of that rectangle will appear to be pressed even though
> it isn't!

Hmm...that is weird.

> I thought for a while about picking keys that didn't form the corners
> of such squares (eg E, C and G work at the same time) - but rapidly
> realised that I couldn't come up with anything remotely ergonomic
> in that way...not even for two players - let alone three or four!
> 
> So now I have to rethink this in terms of two players using joysticks,
> one using the keyboard and another using the mouse.

You want four people using the same keyboard?  Have you had too much
egg nog?  :-)  Seriously though, I don't think I've ever played a PC
game where more than two people used the keyboard at the same time, and
it seems impracticle to think people would want to in the first place.

Anyway, I wasn't aware of the goofy PC keyboard behavior you are brought
up.  Thanks for bringing it up...
-- 
Cameron Moore

Re: [Plib-users] Don't Do This!

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

Christian Mayer wrote:

> Have you tried a USB keyboard? I could imagine that they aren't using
> the old style method. And if that doesn'T work it's possible to try 2
> USB or 1 USB and 1 PS/2 keyboard, etc.

I don't think they'll be any different from the regular kind.

The problem isn't in how the data is transmitted from the keyboard to the
PC (that's basically just a serial protocol).  The problem is that the
decoder chip in the keyboard has only a limited number of pins (not one
per key) so it has to scan the keyboard using a row-column setup.

When you have two keys held down, two row lines are connected to two
column lines.  When you press down a third key that shared the same row
as one of those keys and the same column as the other, there is no way
for the keyboard controller chip to know which of the two keys were pressed.

Since the controller doesn't know which you pressed, it sends neither of
them (unless it's a really old keyboard controller chip - in which case
it sends *both*...Eeeek!)

I wrote up an Omniverous Biped FAQ item about this:

  http://www.sjbaker.org/steve/omniv/index.html

...check out "Keyboards Are Evil".


----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net

Re: [Plib-users] camera orientation

[Reed H. <re...@ze...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Sunday, December 30, 2001, at 09:23 PM, Steve Baker wrote:

> OTOH, Eulers are Evil...so you probably should read this.
>
>   http://www.sjbaker.org/steve/omniv/eulers_are_evil.html

Oh yeah, I know. I think I actually read that a long time ago! :)

I saw a SetCameraLookat funtion (or something like that). What does that 
do?


rh

- --

Reed Hedges
re...@ze...
http://zerohour.net/~reed

Virtual Object System -- Internet Virtual Reality:
http://www.interreality.org

The owls are not what they seem.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (Darwin)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjwwsq8ACgkQ43zrjhPEi7+1sACghuOaKsYWC3aWDsQHmLSFvnNk
8gYAoK56BKiXKetZFu+X99TD7CyhjS3e
=9WJJ
-----END PGP SIGNATURE-----

[Plib-users] patch for building on OSX

[Reed H. <re...@ze...>]

Attached is a patch for building on OSX, against a CVS checkout from 
yesterday... I hope it still works. Let me know
if it doesn't & i'll remake it for a new co.  (it can be applied from 
the root plib CVS directory with -p1)

I did not work on js, sl or net at all [maybe put a note about that in 
README.mac?], but AFAIK all of sg, ul,
ssg and ssgAux work, and most of fnt and pui -- there is one segfault in 
FilePicker that I need to track down.

configure.in detects a host type  matching *-apple-darwin* and uses a 
new LIBS line for the OpenGL and
GLUT frameworks, like it looks like it does for Win32 (cygwin).  It also 
checks for OpenGL/gl.h and
GLUT/glut.h headers and adds MACOSX_OPENGL and MACOSX_GLUT defines 
respectively.   Various
source files then have "#ifdef" lines to check for those symbols, in the 
libs (except js, sl and net) and some of the
stuff in examples/.   The two glIsValidContext() functions also use 
MACOSX_OPENGL to work around
broken AGL on OSX -- this function will always return true.  There might 
be a way to call the Objective-C
method that ought to work, If i get it working i'll let y'all know.

have a safe and fun New Year's

reed

Re: [Plib-users] Don't Do This!

[Christian M. <ma...@Ch...>]

Steve Baker wrote:
> 
> I puzzled about what might be wrong with my code - but eventually
> (after some questions to the LinuxGameDev mailing list and a bit of
> web surfing) discovered that this is a hardware limitation of the PC
> keyboard!
> 
> Aaaaggghhhh!!!!
> 
> I hadn't noticed it when testing because with just me pushing one
> or two keys, I never hit the combinations that cause problems.
> 
> This suprised me a lot (which is why I'm writing this email - so that
> others don't fall into the same trap).
> 
> The rule is approximately that if you hold down three keys that form
> the corners of a rectangle on the keyboards 'scan matrix' (E, C and I
> for example) then depending on the age of your keyboard, you'll either
> find that the third key you press will be ignored *or* the key at the
> fourth corner of that rectangle will appear to be pressed even though
> it isn't!
> [...]

Have you tried a USB keyboard? I could imagine that they aren't using
the old style method. And if that doesn'T work it's possible to try 2
USB or 1 USB and 1 PS/2 keyboard, etc.

CU,
Christian

--
The idea is to die young as late as possible.        -- Ashley Montague

Whoever that is/was; (c) by Douglas Adams would have been better...

[Plib-users] Don't Do This!

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

I'm not a happy person.  :-(

This is not so much a cry for help - as a warning for others in the future:

I've been playing around with a multiplayer game (perhaps going in the
direction of "Super Smash Bros'" on N64 and Game Cube).

I've got to the point of dividing the screen into two, three or four 
chunks and rendering four cute little penguins - each of which can move
independantly with a camera that follows along.  I had all of it working
with the controls for each player assigned from a config file (eg 

  Player 1: MoveNorth = W, MoveSouth = Z, MoveEast = W, MoveWest = S
            Jump = Q, Fire = E
  Player 2: MoveNorth = I, MoveSouth = M, MoveEast = J, MoveWest = K
            Jump = U, Fire = O

...that kind of thing).

So, if you are player 2, you hold down 'I' to move north, 'I' and 'J'
together to move northwest.

It all worked well in testing - but the first time my son and I tried
to actually play together, we noticed that sometimes our keystrokes
would be ignored.  If player 1 moves NorthEast (holding down W and S)
then the 'I' key (player 2's command to move North) wouldn't work.

I puzzled about what might be wrong with my code - but eventually
(after some questions to the LinuxGameDev mailing list and a bit of
web surfing) discovered that this is a hardware limitation of the PC
keyboard!

Aaaaggghhhh!!!!

I hadn't noticed it when testing because with just me pushing one
or two keys, I never hit the combinations that cause problems.

This suprised me a lot (which is why I'm writing this email - so that
others don't fall into the same trap).

The rule is approximately that if you hold down three keys that form
the corners of a rectangle on the keyboards 'scan matrix' (E, C and I
for example) then depending on the age of your keyboard, you'll either
find that the third key you press will be ignored *or* the key at the
fourth corner of that rectangle will appear to be pressed even though
it isn't!

I thought for a while about picking keys that didn't form the corners
of such squares (eg E, C and G work at the same time) - but rapidly
realised that I couldn't come up with anything remotely ergonomic
in that way...not even for two players - let alone three or four!

So now I have to rethink this in terms of two players using joysticks,
one using the keyboard and another using the mouse.

The trouble with that is that *very* few people have two joysticks
and it's hard to make the controls fair when the players have different
controllers.

Grumble, grumble, grumble....

(If you want to try what I've written so far, you can grab it from:

   http://www.sjbaker.org/steve/tuxfighter.tgz

...the code is mostly from TuxAQFH - much cleaned up. Run it with
"./src/tuxfighter -n 2" for two players, "-n 4" for four players, etc
the control characters are displayed to stdout on startup and can
be changed in data/players.dat - there is no way to use the numeric
or arrow pads or function keys yet - but they have the same problems
as the main keyboard).

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net

Re: [Plib-users] camera orientation

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

Reed Hedges wrote:

> Is there a way to get the camera orientation, or a position/orientation
> matrix?

Yes.  If you are using an ssgContext (the "new" way to do things) then

  ssgContext::getModelviewMatrix

...(that's actually the inverse of the camera matrix).

> Or, if not, what is the best way to turn the camera by some amount
> around some axis?

It's a very bad idea to incrementally update the camera matrix because
roundoff error will accumulate in a way that will result in something
that's no longer a simple rotate/translate matrix.

OTOH, Eulers are Evil...so you probably should read this.

  http://www.sjbaker.org/steve/omniv/eulers_are_evil.html

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net

[Plib-users] camera orientation

[Reed H. <re...@ze...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Is there a way to get the camera orientation, or a position/orientation 
matrix?
Or, if not, what is the best way to turn the camera by some amount 
around some
axis?

PS. found the CVS info, checked out current version.

- --

Reed Hedges
re...@ze...
http://zerohour.net/~reed

Virtual Object System -- Internet Virtual Reality:
http://www.interreality.org

The owls are not what they seem.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (Darwin)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjwvtY8ACgkQ43zrjhPEi7/BvgCeIIkYGWlwYLhxt9ePUHdhJ+Xj
oPUAn0AgfNUvp1Lg3t8s1REuUICmFbA0
=7pi3
-----END PGP SIGNATURE-----

Re: [Plib-users] Building Plib on Mac OSX (Darwin)

[Reed H. <re...@ze...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Jon, have you been working on plib on OSX? How much have you got 
working? I have working for me everything except
fnt, and sl and js (need some bigger porting) and haven't looked at net 
at all.   Basically the tux ssg example,
the simple and complex pui examples (but not widget_list). Segfault 
somewhere in puFilePicker::setSize().
Is any OSX stuff in CVS yet? I was going to put together a patch, but 
would like to know what's there
already.   Would it be possible for me to check out the CVS tree, to 
find a recent tarball somewhere?

On Saturday, December 29, 2001, at 06:03 PM, Beegee wrote:

> I resolved the __objcInit error by linking against libobjc, from 
> /usr/lib. There was some discussion about this on the ProjectBuilder 
> list, but I don't have the thread handy.

yup, that works fine.  I think some of the OpenGL library is in 
Objective-C ("cocoa")

>
> Additionally, there was a bug in 10.1 I believe that caused a crash if 
> you called aglGetCurrentContext() before you created a context. That 
> led me to just have glIsValidContext() always return true on OS X.  
> Sloppy I know...
>

Yeah, most of Carbon AGL is "Unsupported" according to the on-line docs, 
and aglGetCurrentContext() doesn't work,
and needs to be removed.  There are equivalents in the Objective-C 
("Cocoa") OpenGL interfaces, that I will try out.

 > Also, I've made basically the exact same changes that you listed 
except that I kept 'macintosh' and 'MACOSX' as separate
 > targets because of things like <OpenGL/GL.h> vs <GL/GL.h>.

What macros are defined on MacOSX? I know __APPLE__ and __MACH__ are, 
are there any that just mean "you're on
MacOSX" ? ("__MACOSX__" or something?).   I think stuff like:

#if defined(__APPLE__) && defined(__MACH__)	// Mac OSX
#include <OpenGL/gl.h>
#else
#include <GL/gl.h>
#endif

would work pretty fine  (or probably just #ifdef __MACH__). Do you guys 
agree? If so, I'll make up the patch.

I'm still not sure how to get the correct linker flags into the 
Makefiles via autoconf (will look into it sometime)
but this is what's needed in the Makefiles for OSX:

There should be no X11 libraries at all ("-lX11 -lXi -lXext -lXmu").  
This is not a problem in the libraries, because
the X libraries aren't actually linked, but I had to remove those flags 
when building the example programs.

These flags should be added in these makefiles:

ssg/Makefile:	LIBS += -framework OpenGL
pui/Makefile:	LIBS += -framework GLUT
All of the examples I tried: 	LIBS += -lobjc -framework OpenGL  
- -framework GLUT

Let me know about CVS, patching, and if anyone knows about making 
autoconf work.


rh

- --

Reed Hedges
re...@ze...
http://zerohour.net/~reed

Virtual Object System -- Internet Virtual Reality:
http://www.interreality.org

The owls are not what they seem.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (Darwin)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjwvaNEACgkQ43zrjhPEi7/pTQCfRkrZXChfK2ZQjgN6Z7z/vUES
pvsAoLnj+ocrP9jOyWSq5QDA01WufHO6
=0j7b
-----END PGP SIGNATURE-----

RE: [Plib-users] Building Plib on Mac OSX (Darwin)

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

Reed Hedges writes:

>2. remove "-O6" from CXXFLAGS and CFLAGS in the Makefile ??? where did
>this come from ???

To set history straight
The -O6 has been in configure.in 'forever'
.
When PLib was first setup for gnu autotools we didn't have an autotools
expert on board and I borrowed a lot from the PGCC project
http://www.goof.com/pcg/
to include the recommended flags to get the 'most' from their compiler.

I am glad to say we have all learned a lot since then, and the right way is
of course is to not hardwire this into the configure script as is reflected
in
the current CVS.

Note that this allows for configure invocations such as
CXXFLAGS="-OMyWhatAmIDoing" ./configure

YMMV  :-)

Cheers

Norman

Re: [Plib-users] Building Plib on Mac OSX (Darwin)

[Bernie B. <bb...@bi...>]

Steve Baker wrote:
> 
> Reed Hedges wrote:
> 
> >  > The "-O6" stuff was removed recently in CVS.
> >
> >  > Dunno - some attempt to get more speed by increasing the optimisation
> > level
> >  > I guess.
> >
> > Yeah, except gcc 2.95.2 only goes up to -O3, according to the
> > documentation I have...
> > and it fails with -O6 :)
> 
> No it doesn't...
> 
>   /u/steve> gcc -O2 t1.cxx
>   /u/steve> gcc -O6 t1.cxx
>   /u/steve> gcc -O9 t1.cxx
>   /u/steve> gcc --version
>   2.95.2
> 
> Doesn't seem to be a problem.  I don't think you'll get any better optimisation
> after -O3 though.
> 
According to the manual everyything above -O3 is undocumented so YMMV.

Anyways embedding compiler specific options in the autoconf/automake
files is considered bad form.  The approved method is to set CXXFLAGS in
the environment before running configure:

CXX=/usr/intel/ia32/bin/icc CXXFLAGS="-tpp6 -unroll -Kc++eh" ./configure

Cheers,
Bernie

Re: [Plib-users] Building Plib on Mac OSX (Darwin)

[Beegee <be...@ma...>]

I resolved the __objcInit error by linking against libobjc, from 
/usr/lib. There was some discussion about this on the ProjectBuilder 
list, but I don't have the thread handy.

Also, I've made basically the exact same changes that you listed except 
that I kept 'macintosh' and 'MACOSX' as separate targets because of 
things like <OpenGL/GL.h> vs <GL/GL.h>.

Additionally, there was a bug in 10.1 I believe that caused a crash if 
you called aglGetCurrentContext() before you created a context. That led 
me to just have glIsValidContext() always return true on OS X.  Sloppy I 
know...

Jon

On Friday, December 28, 2001, at 12:16 PM, Reed Hedges wrote:

> I'm working on the Tux example program now. Here is the error, which 
> has me stumped. I will try to enlist the help
> of some people who know more about OSX than me...
>
> linked to -framework GLUT and include <GLUT/glut.h> instead of 
> <GL/glut.h>.
>
>
> make:
> c++  -g -O2 -Wall  -o tux_example  tux_example.o -lplibssg -lplibsg 
> -lplibul -lpthread   -lm -framework OpenGL -framework AGL -framework 
> CoreServices -framework GLUT
> /usr/bin/ld: /usr/lib/crt1.o illegal reference to symbol: __objcInit 
> defined in indirectly referenced dynamic library 
> /usr/lib/libobjc.A.dylib
> make: *** [tux_example] Error 1
>

Re: [Plib-users] Building Plib on Mac OSX (Darwin)

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

Reed Hedges wrote:

>  > The "-O6" stuff was removed recently in CVS.
> 
>  > Dunno - some attempt to get more speed by increasing the optimisation
> level
>  > I guess.
> 
> Yeah, except gcc 2.95.2 only goes up to -O3, according to the
> documentation I have...
> and it fails with -O6 :)

No it doesn't...

  /u/steve> gcc -O2 t1.cxx
  /u/steve> gcc -O6 t1.cxx
  /u/steve> gcc -O9 t1.cxx
  /u/steve> gcc --version
  2.95.2

Doesn't seem to be a problem.  I don't think you'll get any better optimisation
after -O3 though.

> yup...  this OpenGL demands GLint...  will this break existing
> applications on Darwin?

Almost no OpenGL programs would compile 'out of the box' if all GL
types were rigerously enforced.  But since Darwin appears to only be
checking that GLint != int...you may 'get away with it' with many
programs.

> If so, c'est la vie, I guess.  It was only those two lines in ssg
> though, none in sg or util.

I find that *very* suprising.

Evidently it doesn't object to you passing a float in place of a GLfloat
and I guess there are relatively few places where we pass integers into
OpenGL.

> Only with some sneaky hacks. All the directories are different, nothing
> like normal unix system.

Ack!  What a pain.
 
> Also:
>         1. is there a really minimal sample program I can use to test?

Most of the programs in the PLIB examples are pretty minimal.  You have
to download those separately from the PLIB web site.

>         2. I ran configure script with --without-x. How important is X
> windows to any part of
>         using plib?

Not at all - PLIB runs under Windoze without X.

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net

Re: [Plib-users] Building Plib on Mac OSX (Darwin)

[Reed H. <re...@ze...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



 > The "-O6" stuff was removed recently in CVS.

 > Dunno - some attempt to get more speed by increasing the optimisation 
level
 > I guess.

Yeah, except gcc 2.95.2 only goes up to -O3, according to the 
documentation I have...
and it fails with -O6 :)


 > We have to find a way to determine whether the machine we are 
compiling on
 > is running Mac OS (X) *without* forcing the user to tell us ...

autoconf will detect this.
I think AC_CANONICAL_SYSTEM will set a variety of variables, including 
"build_alias"
"host_alias", etc??
On darwin this will have the value "powerpc-apple-darwin5.2"

uname will also output "Darwin".

Also, the compiler probably defines some symbol (__DARWIN__ or something)
that can be detected in preprocessing. I will find that out.


 >Yes.  Looking to see if glut.h is in <GLUT/glut.h> might be one way.

 >> 4. changed int vp [ 4 ] ; on line 202 of ssg.cxx to GLint vp [ 4 ] ;
 >> 5. changed int ww; on line 112 of ssgLoadTexture.cxx to GLint ww;

 > Why exactly was this neccessary ?

 > Perhaps they somehow made the GL types *not* be a simple typedef or 
#define
 > of the basic types.  If that's true then writing good code is going to 
be
 > VERY painful.


yup...  this OpenGL demands GLint...  will this break existing 
applications on Darwin?
If so, c'est la vie, I guess.  It was only those two lines in ssg 
though, none in sg or util.
I haven't tried building the other libraries yet.

Is this a big problem do you think?


 > Yes - but surely the old way must work too?

Only with some sneaky hacks. All the directories are different, nothing 
like normal unix system.

Normal systems have /usr/lib/libfoo.so or /usr/lib/group/libfoo.so (in 
which case you use
- - - -L /usr/lib/group) , and /usr/include/foo.h or
/usr/include/group/foo.h (in which case you use #include <group/foo.h>).
Darwin has /System/Library/Frameworks/group.framework/Headers/foo.h and
/System/Library/Frameworks/group.framework/Libraries/libfoo.dylib.


Actually, I first tried symlinks  from /usr/local/lib/GL ->
/System/Library/Frameworks/OpenGL.framework/Libraries and likewise for 
headers,
but ran into all kinds of little problems. It was easier just to link to 
the framework.


Fink <http://fink.sf.net> includes open GL libraries (Mesa?) with the 
XFree port, I *think*,
but I diddn't want to get tangled with those just yet. However, maybe 
that would work better.
I can look at that too.


 > Apple clearly don't seem overly concerned about portability.  Why else 
would
 > they have moved glut.h ?

All the framework stuff is inherited from NeXt, I think.  Politics 
probably :P.
Frameworks *do* facilitate distribution of libraries without install 
scripts
that move copy files around (they can just be dropped into place), which 
is nice.

 > Hmm ... who knows how to properly implement that stuff in our (up to 
now,
 > pretty simple) autoconf-based build system ?

 > I doubt you could use autoconf.  It has things like '-L' and '-I' 
directives
 > hardwired in.

Maybe just do what I did, but in the script-- detect darwin and append 
the framework
directives, checking for OpenGL first, maybe, but it should be in any 
stock system AFAIK.
I'm not sure how to implement this in autoconf though.

There might be a way to get autoconf on Darwin to add in the frameworks 
automatically,
though.  I'll look for docs on it.


 > Perhaps we have to give up and treat it like we do MSVC and Borland 
under
 > Windoze where we just distribute a complete parallel build environment.

This is another solution, It's a bit of grunt work setting up the Apple 
Project
  Builder files, but it's not to bad.  The plib components can be made 
into frameworks,
and contianed in this other concept darwin has of "umbrella" 
frameworks...
I might be able to do this, if there is interest.

Want me to send a patch for autoconf and code if I get it all more or 
less working
correctly?  My motive is working on my apple laptop, rather than my 
linux server/
desktop... which doesnt have a monitor :)  But I can't spend too much 
time on it, I
want to *use* plib :D I can get a monitor...

Also:
	1. is there a really minimal sample program I can use to test?
	2. I ran configure script with --without-x. How important is X 
windows to any part of
	using plib?

thanks

reed

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (Darwin)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjwt528ACgkQ43zrjhPEi7/oUQCg6aYG3SPNoqzwSKpm4ouGcT+A
jmYAoJrUhfw81UDAs1eB+ut2yc2AvEkV
=wQ0O
-----END PGP SIGNATURE-----

Re: [Plib-users] Building Plib on Mac OSX (Darwin)

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

Sebastian Ude wrote:

> > 2. remove "-O6" from CXXFLAGS and CFLAGS in the Makefile ??? where did
> > this come from ???
> 
> The "-O6" stuff was removed recently in CVS.

Dunno - some attempt to get more speed by increasing the optimisation level
I guess.

Does that cause problems to someone?
 
> > 2.  changed some #include statements accordingly:
> >       from <GL/foo.h> to <OpenGL/foo.h>
> >       from <ag.h> to <AGL/agl.h>
> >       from <CodeFragments.h> in util/ul.h to
> > <CoreServices/CoreServices.h>. I also added #include <unistd.h> to
> > util/ul.h after CoreServices (for the sleep() function)
> 
> I think we should add some more #ifdefs to the code so that PLIB
> automatically includes the correct header files on Mac OS X.

Yes - definitely. Now that Mac==UNIX, we need to make better efforts
to support the beast.

> > 3. add -Dmacintosh to DEFS in the Makefile.
> 
> Hmm ... you had to do this manually ?
> 
> We have to find a way to determine whether the machine we are compiling on
> is running Mac OS (X) *without* forcing the user to tell us ...

Yes.  Looking to see if glut.h is in <GLUT/glut.h> might be one way.

I can't imagine any other company making it so difficult to write
portable code!  (OK - actually, can *easily* imagine one other).
 
> > 4. changed int vp [ 4 ] ; on line 202 of ssg.cxx to GLint vp [ 4 ] ;
> > 5. changed int ww; on line 112 of ssgLoadTexture.cxx to GLint ww;
> 
> Why exactly was this neccessary ?

Perhaps they somehow made the GL types *not* be a simple typedef or #define
of the basic types.  If that's true then writing good code is going to be
VERY painful.
 
> PLIB passes normal int / float (whatever) variables or pointers to these
> types to the OpenGL routines expecting a GL* data type all the time (just
> look at PUI), and up to now, this has not caused any trouble as far as I
> can tell.

Indeed.
 
> If it does on Mac OS X, we have to change lots of lines (okay, in this
> case, 'sed' would be our friend ...).

Not really - in many cases the SSG API says that some parameter is an 'int'
or a 'float' when really it's going to be passed into OpenGL.

I doubt that it can be true in all cases - for example, just below where
that 'int vp [ 4 ]' line is, we have:

   glMultMatrixf ( (float *) mat ) ;
                    ^^^^^^
                  Notice that this *isn't*
                  a GLfloat as MultMatrix specifies.

> > Frameworks are Darwin's way of doing libraries, they are versioned
> > bundles (directories, actually) of headers,libraries and resources...
> > to link to a framework SOMEFW, you pass '-framework SOMEFW' to cc, and
> > to include header files out of it you include <SOMEFW/header.h>.
> > Frameworks are a nice idea... but a pain in the ass for porting stuff
> > from other unix platforms...

Yes - but surely the old way must work too?

Apple clearly don't seem overly concerned about portability.  Why else would
they have moved glut.h ?
 
> Hmm ... who knows how to properly implement that stuff in our (up to now,
> pretty simple) autoconf-based build system ?

I doubt you could use autoconf.  It has things like '-L' and '-I' directives
hardwired in.

Perhaps we have to give up and treat it like we do MSVC and Borland under
Windoze where we just distribute a complete parallel build environment.

That will only work if there are reasonable numbers of Mac OSX users on
the mailing list to keep them up to date though.

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net

Re: [Plib-users] Building Plib on Mac OSX (Darwin)

[Sebastian U. <ud...@ha...>]

On Fri, 28 Dec 2001, re...@ze... (Reed Hedges) wrote:
> Date: Fri, 28 Dec 2001 15:16:12 -0500
> To: pli...@li...
> From: re...@ze... (Reed Hedges)
> Subject: Re: [Plib-users] Building Plib on Mac OSX (Darwin)

[...]

> 2. remove "-O6" from CXXFLAGS and CFLAGS in the Makefile ??? where did
> this come from ???

The "-O6" stuff was removed recently in CVS.


> 2.  changed some #include statements accordingly:
>	from <GL/foo.h> to <OpenGL/foo.h>
>	from <ag.h> to <AGL/agl.h>
>	from <CodeFragments.h> in util/ul.h to 
> <CoreServices/CoreServices.h>. I also added #include <unistd.h> to 
> util/ul.h after CoreServices (for the sleep() function)

I think we should add some more #ifdefs to the code so that PLIB
automatically includes the correct header files on Mac OS X.


> 3. add -Dmacintosh to DEFS in the Makefile.

Hmm ... you had to do this manually ?

We have to find a way to determine whether the machine we are compiling on
is running Mac OS (X) *without* forcing the user to tell us ...


> 4. changed int vp [ 4 ] ; on line 202 of ssg.cxx to GLint vp [ 4 ] ;
> 5. changed int ww; on line 112 of ssgLoadTexture.cxx to GLint ww;

Why exactly was this neccessary ?

PLIB passes normal int / float (whatever) variables or pointers to these
types to the OpenGL routines expecting a GL* data type all the time (just
look at PUI), and up to now, this has not caused any trouble as far as I
can tell.

If it does on Mac OS X, we have to change lots of lines (okay, in this
case, 'sed' would be our friend ...).


> Frameworks are Darwin's way of doing libraries, they are versioned 
> bundles (directories, actually) of headers,libraries and resources...
> to link to a framework SOMEFW, you pass '-framework SOMEFW' to cc, and 
> to include header files out of it you include <SOMEFW/header.h>.
> Frameworks are a nice idea... but a pain in the ass for porting stuff
> from other unix platforms...

Hmm ... who knows how to properly implement that stuff in our (up to now,
pretty simple) autoconf-based build system ?


- Sebastian

Re: [Plib-users] Building Plib on Mac OSX (Darwin)

[Reed H. <re...@ze...>]

Hi, thanks for the help.

Since sending that message I found AGL and used that, and Plib builds. 
Here is what
I did to get ssg building, and similiar modifications to sg and util:

1. added "-framework OpenGL -framework AGL -framework CoreServices" to 
LIBS in the Makefile
2.  changed some #include statements accordingly:
	from <GL/foo.h> to <OpenGL/foo.h>
	from <ag.h> to <AGL/agl.h>
	from <CodeFragments.h> in util/ul.h to 
<CoreServices/CoreServices.h>. I also added #include <unistd.h> to 
util/ul.h after CoreServices (for the sleep() function)
2. remove "-O6" from CXXFLAGS and CFLAGS in the Makefile ??? where did 
this come from ???
3. add -Dmacintosh to DEFS in the Makefile.
4. changed int vp [ 4 ] ; on line 202 of ssg.cxx to GLint vp [ 4 ] ;
5. changed int ww; on line 112 of ssgLoadTexture.cxx to GLint ww;

Frameworks are Darwin's way of doing libraries, they are versioned 
bundles (directories, actually) of headers,
libraries and resources...
to link to a framework SOMEFW, you pass '-framework SOMEFW' to cc, and 
to include header files out of it
you include <SOMEFW/header.h>.  Frameworks are a nice idea... but a pain 
in the ass for porting stuff from other
unix platforms...


I'm working on the Tux example program now. Here is the error, which has 
me stumped. I will try to enlist the help
of some people who know more about OSX than me...

linked to -framework GLUT and include <GLUT/glut.h> instead of 
<GL/glut.h>.


make:
c++  -g -O2 -Wall  -o tux_example  tux_example.o -lplibssg -lplibsg 
-lplibul -lpthread   -lm -framework OpenGL -framework AGL -framework 
CoreServices -framework GLUT
/usr/bin/ld: /usr/lib/crt1.o illegal reference to symbol: __objcInit 
defined in indirectly referenced dynamic library /usr/lib/libobjc.A.dylib
make: *** [tux_example] Error 1



--

Reed Hedges
re...@ze...
http://zerohour.net/~reed

Virtual Object System -- Internet Virtual Reality:
http://www.interreality.org

The owls are not what they seem.

Re: [Plib-users] PUI Performance Factors

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

Norman Vine wrote:

> Also note that in Windows an OpenGL program runs significantly
> faster in FullScreen mode vs Windowed mode hence another plus
> for PUI based applications.

That's true under Linux too - for at least *some* 3D hardware and *some*
drivers.

With the latest nVidia drivers, the GeForce 3 card will do a true
buffer swap (just move a pointer) instead of a copy-from-back-buffer-to-front.

Hence, (especially at high resolution and at high frame rates) you get
much better pixel fill rates from full screen rendering.

I presume this is the benefit you are seeing under Windoze too.

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net