plib-users

[Plib-users] RE: ssgIsect question ... whack ... answered ???

[McEvoy, N. <nic...@ds...>]

Sorry I just had another head slapping moment !!!  :-)

I think I have solved my ssgIsect problem (but I have been known to be
wrong).

If I comment out the part where I set the inverse matrix (invmat) to my
player position and change the sphere to be my player position then the
returned ssgHit plane (h->plane) equation is correct !!!!  And my ODE
physics engine works fantastic ... my sphere tumbles down the mountain side,
coming to a rest at the bottom (before it bounced off the screen).

sgMat4 invmat;
sgMakeIdentMat4(invmat);
sgSphere sphere;

//invmat[3][0] = -player_pos[SG_X];
//invmat[3][1] = -player_pos[SG_Y];
//invmat[3][2] = -player_pos[SG_Z];
//sphere.setCenter(0.0, 0.0, 0.0);
sphere.setCenter(player_pos[SG_X], player_pos[SG_Y], player_pos[SG_Z]);
sphere.setRadius(10.0);

ssgHit *results ;
int num_hits = ssgIsect(&mWorld, &sphere, invmat, &results);

for (int i = 0; i < num_hits; i++)
{
	ssgHit *h = &results[i];
	printf("pos <%.1f:%.1f:%.1f> plane <%.1f:%.1f:%.1f:%.1f>\n",
		player_pos[0], player_pos[1], player_pos[2],
		h->plane[0], h->plane[1], h->plane[2], h->plane[3]);
}

Is the PLIB documentation misleading on the use of ssgIsect where it states:
"In each case, the search for a collision starts at 'root', and the database
is transformed by the matrix 'm' before the test is evaluated - hence, 'm'
is usually the inverse of the matrix describing the test object's location."

In my case 'm' was not "the inverse matrix describing the test object's
location", 'm' was the identity matrix and the sphere described the test
object's location.

Any comments ?

Nick
http://members.ozemail.com.au/~ndmcevoy/

[Plib-users] ssgIsect question

[McEvoy, N. <nic...@ds...>]

What's up with ssgIsect (ie. how does it work) ???  YES, I have read the
PLIB documentation.

I want to find the distance between my player's center and the plane I hit.
I use a sphere radius 10 at 0,0,0 as per the code below.

When my player is at (0,0,9.68326) and the ground (or plane) is on the X-Y
plane with normal (0,0,1) I use ssgIsect to return info about the ground
below me that I wish to 'rest' on, ssgHit has plane
(0.00,0.00,1.00,9.68326).

Why is plane[3] = 9.68326 ?  According to the equation of a plane D would be
zero in my case cause my plane is X-Y (ie. all point on plane have z=0)
(ref: http://astronomy.swin.edu.au/pbourke/geometry/planeeq/)

Ax = By + Cz + D = 0

A = y1 (z2 - z3) + y2 (z3 - z1) + y3 (z1 - z2) 
B = z1 (x2 - x3) + z2 (x3 - x1) + z3 (x1 - x2) 
C = x1 (y2 - y3) + x2 (y3 - y1) + x3 (y1 - y2) 
- D = x1 (y2 z3 - y3 z2) + x2 (y3 z1 - y1 z3) + x3 (y1 z2 - y2 z1)

Say O is my player (& sphere with radius 10 for isect test).

+Z   +Y
 |  /
 | /
 O/
 .------+X

Now I hope I don't confuse the issue (by bringing ODE into the equation) ...
but ...

The problem is that when I pass the plane to a physics engine (ODE) it works
out the depth of penetration by:
#define dDOT(a,b)   ((a)[0]*(b)[0] + (a)[1]*(b)[1] + (a)[2]*(b)[2])
dReal k = dDOT(pos,plane);
dReal depth = -plane[3] - k + sphere->radius;

ie. depth = -9.68326 -9.68326 + 10 = -9.36652

The incorrect depth result causes my sphere to 'bounce' due to the large
depth in penetration.

Note I get same depth calculation result with PLIB:
float dist = sgDistToPlaneVec3(h->plane, player_pos);
float depth = sphere.getRadius() - dist;

Is it something to do with the invmat[3][2] or setting the sphere at 0,0,0
???

Do I need to raise the sphere or invmat[3][2] ?  I'm quite not sure how PLIB
works backwards to get the ssgHit.  Believe me I have traced the code !!!

Any ideas ???

--------------------------------------------------
sgMat4 invmat;
sgMakeIdentMat4(invmat);
sgSphere sphere;

invmat[3][0] = -player_pos[SG_X];
invmat[3][1] = -player_pos[SG_Y];
invmat[3][2] = -player_pos[SG_Z];
{
...
	sphere.setCenter(0.0, 0.0, 0.0);
	sphere.setRadius(10.0);

	ssgHit *results ;
	int num_hits = ssgIsect(&mWorld, &sphere, invmat, &results);

	for (int i = 0; i < num_hits; i++)
	{
		ssgHit *h = &results[i];
		printf("pos <%.1f:%.1f:%.1f> plane <%.1f:%.1f:%.1f:%.1f>\n",
			player_pos[0], player_pos[1], player_pos[2],
			h->plane[0], h->plane[1], h->plane[2], h->plane[3]);
	}
...
}

--------------------------------------------------
pos <0.00:0.00:9.68326> plane <0.00:0.00:1.00:9.68326>
...etc
--------------------------------------------------
Nick
http://members.ozemail.com.au/~ndmcevoy/

Re: [Plib-users] Floating Group with Frame

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

On Sat, 19 Jan 2002, da...@mi... (dave) wrote:
> Date: Sat, 19 Jan 2002 18:05:58 -0600
> To: plib-users <pli...@li...>
> From: da...@mi... (dave)
> Subject: [Plib-users] Floating Group with Frame
>
> Q1.
> I was able to make a nice translucent group by creating a class that 
> inherits from puGroup. I set the floating flag, and was able to drag the 
> group around. In order to be able to see the group's abox I added a 
> Frame as the first widget and made it the same size as the group. This 
> is great, now I don't have to hunt and peck to find the group to do a 
> click. But, alas, with the new frame now I am unable to grab the group 
> to drag it.

I had a discussion on this issue with John recently.

The "floating" stuff has not been used for years and definately does not
work correctly in some situations.

However, since nobody seems to need it at the moment, nobody has fixed it
:).


> I suspect the Frame gets the hit before the group does, ie, the group is 
> behind the Frame.  What do I do to get the hit passed on to the Group?

No. Let's assume that group you created is not stacked in another group
created by you, that's what happens:

- Hit goes to the PUI live interface group
- PUI live interface group passes the hit to your group
- Your group passes the hit to the widget(s)

Is your problem that the frame gets in front of the other widgets when you
click upon the group ?

If yes, than that's because of that puMoveToLast () stuff. We had long
discussions about this issue, too. In the end, we realized that we need to
do it for certain reasons, even if it can be nerve-killing in some
situations.


> Q2.  Maybe I am going about this wrong. Maybe it would be better to give 
> the group itself a simple outside border without using a Frame but leave 
> the middle transparent?   Hmmm. But isnt a Frame the way to do this 
> anyway? Then the same problem would occur.

The group's abox is not drawn - but nobody prevents you from drawing it.

Derive your own "draw" routine and have it look like this:

void myGroup::draw ( int dx, dy )
{
  abox.draw ( dx, dy, style, colour, FALSE, border_thickness ) ;

  puGroup::draw ( dx, dy ) ;
}

This way the frame will always be behind tehe widgets.


> Q3. What I really want to do is have the Group or Frame look like a 
> clear sheet of glass. Mostly only the edge of the sheet would be 
> visible. Maybe a striated reflection would delineate the surface of the 
> sheet much like a real glass sheet is detectable. I assume all this is 
> possible? If you see the movie Mission To Mars all the computer 
> terminals in the ship are essentially sheets of glass - thats the idea 
> here. Any tips on how to do this?

As Steve said, that's impossible to do with PUI's styles.

Derive your own draw routine and place some OpenGL code there.


- Sebastian

Re: [Plib-users] Floating Group with Frame

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

dave wrote:
> 
> Q1.
> I was able to make a nice translucent group by creating a class that
> inherits from puGroup. I set the floating flag, and was able to drag the
> group around. In order to be able to see the group's abox I added a
> Frame as the first widget and made it the same size as the group. This
> is great, now I don't have to hunt and peck to find the group to do a
> click. But, alas, with the new frame now I am unable to grab the group
> to drag it.
> 
> I suspect the Frame gets the hit before the group does, ie, the group is
> behind the Frame.  What do I do to get the hit passed on to the Group?

I don't think you should make new widgets by *combining* others in layers.

There is a lot more to a PUI widget than just it's graphic.

> Q2.  Maybe I am going about this wrong. Maybe it would be better to give
> the group itself a simple outside border without using a Frame but leave
> the middle transparent?   Hmmm. But isnt a Frame the way to do this
> anyway? Then the same problem would occur.

Just make you midget render the way you want it to.  If you are deriving
a class from a standard widget anyway - why not just write your own draw()
method and have it look however you like?

> Q3. What I really want to do is have the Group or Frame look like a
> clear sheet of glass. Mostly only the edge of the sheet would be
> visible. Maybe a striated reflection would delineate the surface of the
> sheet much like a real glass sheet is detectable. I assume all this is
> possible?

Certainly.

> If you see the movie Mission To Mars all the computer
> terminals in the ship are essentially sheets of glass - thats the idea
> here. Any tips on how to do this?

Well, I don't think any of the built-in 'draw' methods are adapted to this
rendering style...so writing your own makes a lot of sense.

----------------------------- 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] Floating Group with Frame

[dave <da...@mi...>]

Q1.
I was able to make a nice translucent group by creating a class that 
inherits from puGroup. I set the floating flag, and was able to drag the 
group around. In order to be able to see the group's abox I added a 
Frame as the first widget and made it the same size as the group. This 
is great, now I don't have to hunt and peck to find the group to do a 
click. But, alas, with the new frame now I am unable to grab the group 
to drag it.

I suspect the Frame gets the hit before the group does, ie, the group is 
behind the Frame.  What do I do to get the hit passed on to the Group?

Q2.  Maybe I am going about this wrong. Maybe it would be better to give 
the group itself a simple outside border without using a Frame but leave 
the middle transparent?   Hmmm. But isnt a Frame the way to do this 
anyway? Then the same problem would occur.

Q3. What I really want to do is have the Group or Frame look like a 
clear sheet of glass. Mostly only the edge of the sheet would be 
visible. Maybe a striated reflection would delineate the surface of the 
sheet much like a real glass sheet is detectable. I assume all this is 
possible? If you see the movie Mission To Mars all the computer 
terminals in the ship are essentially sheets of glass - thats the idea 
here. Any tips on how to do this?

Thanks ahead of time,
da...@mi...

Re: [Plib-users] ssgHOT question ... solved

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

"McEvoy, Nick" wrote:

> ...now HOT calculation (which starts *inside* the player object) hits my
> player ssgEntity object ... giving me my height above my players feet
> (actually its a space-craft so it doesn't have feet ... but I do digress)
> !!!

Yep - that's another one of those "I wish I had a dollar for every time
I've done that" things.

What sometimes happens is that the object gently rises up into the air
as each frame it stands on top of it's own roof.
 

----------------------------- 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] ssgHOT question ... solved

[McEvoy, N. <nic...@ds...>]

Duh ... stupid me ...

When I'm in 1st person view my player ssgEntity is not in the scene

...HOT calculation works fine

When I switch to external view I add my player ssgEntity to the scene

...now HOT calculation (which starts *inside* the player object) hits my
player ssgEntity object ... giving me my height above my players feet
(actually its a space-craft so it doesn't have feet ... but I do digress)
!!!

My solution is obviously to clear the traversal mask bits when I load my
player !!!

	pPlayerObject->clrTraversalMaskBits(SSGTRAV_ISECT|SSGTRAV_HOT);

Now I get the correct Height of Terrain ... in both views !!!

So that weird problem was just me after all ... now I'll just slink away and
hide :-)

Nick
http://members.ozemail.com.au/~ndmcevoy/

RE: [Plib-users] ssgHOT question

[McEvoy, N. <nic...@ds...>]

"Steve Baker" wrote:
>That's very weird - but I don't see anything like that in either TuxAQFH,
>TuxKart, EvilOverlord or any of the 'quick hack' programs I have that use
>it.

mmmm, yes I know ... they work fine ... I'll have to do some more
investigation.  I must be doing something wrong elsewhere then !?


>OTOH, your code is nearly identical to the TuxAQFH code (Your program had
>better be under GPL or the Baker Enterprises crack legal team will be on
>your tail)...so I don't see why you could be having a problem and not me.

Where do you think my best 3D code ideas come from ... not out of my brain
:-)

I learn from the best by example (... and rest assured all my code is under
GPL ... tell those crack legal guys to holster their pens and put the safety
catch on ... I'm now putting my keyboard down and stepping away ... very
slowly ... my PLIB game development is just a hobby ... and is out there for
all to see)  :-)

mmmm ... back to the code ... very weird ...

Nick
http://members.ozemail.com.au/~ndmcevoy/

Re: [Plib-users] ssgHOT question

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

"McEvoy, Nick" wrote:
> 
> Can anyone tell me why ssgHOT() returns different results depending on my
> camera position (ie. 1st person view and external view) ?  In 1st person
> view I get the correct HOT, when I change to an external view the HOT is
> incorrect.  I get 2 hits when in 1st view (looking out over my terrain) and
> 4 hits when in external view (looking at my player which is sitting just
> above the terrain).

That's very weird - but I don't see anything like that in either TuxAQFH,
TuxKart, EvilOverlord or any of the 'quick hack' programs I have that use
it.

OTOH, your code is nearly identical to the TuxAQFH code (Your program had
better be under GPL or the Baker Enterprises crack legal team will be on
your tail)...so I don't see why you could be having a problem and not me.

Weird.

----------------------------- 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] Translucent Widgets

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

dave wrote:

> I'd like to have various groups of widgets that have differing states of
> translucence. It isnt obvious to me how to do this. I don't know much
> about openGL/Glut, after all, the motivation to use higher level
> libraries is partly so I dont have to learn as much low-level details.
> 
> It seems to me that setting up a blend function just before calling
> puDisplay is the wrong approach. Setting the defaultColour would apply
> to the entire PUI display list would it not?  Also, it seems like one
> would always want to save/restore the previous defaultColour as well,
> and this would be going on a lot.

There are really only two mechanisms - set the default colour - or set
the colour of each widget individually.

> I suspect it is better to derive new translucent PUI classes and put the
> blending within each widget. One could then get a group box where the
> box's background is in one state of translucence, and the widgets on top
> of it can be slightly less translucent, ie, more solid, depending on how
> one programs the widgets as one builds the group.

That tends to happen that way anyway because if you (say) set the default
alpha to 0.5 then the group box obscures 50% of the light coming from
behind it and adds in 50% of it's own colour.  Then when you render
a button or something on top of that, you get 50% of the light from
behind it and 50% of the button colour.  In total, you get 25% of the
ultimate background and 25% of the group box plus 50% of the button.

Presuming you choose reasonably harmonious colours for group box and
button, the button will *look* more opaque than the rest of the box
simply because less of the background is showing through.
 
> It seems to me that each object should have a setColour() and load
> color, ie, that these functions should be within the puObject class
> instead of being global to PUI.

They are within the puObject class.
 
Every widget is derived from puObject - and puObject has member functions:

  setColour ( which, r, g, b, a ) ;

...where 'which' can be:

 PUCOL_FOREGROUND
 PUCOL_BACKGROUND
 PUCOL_HIGHLIGHT
 PUCOL_LABEL
 PUCOL_LEGEND
 PUCOL_MISC

This gives you minute control over every single stoopid little part of
every single silly little widget...if you have the patience to choose
them all!

...or you can use:

  setColourScheme ( r, g, b, a ) ;

...where you pick the overall colour and the package 'tastefully' chooses
foregrounds and backgrounds that look good. (Usually!)

----------------------------- 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] ssgHOT question

[McEvoy, N. <nic...@ds...>]

Can anyone tell me why ssgHOT() returns different results depending on my
camera position (ie. 1st person view and external view) ?  In 1st person
view I get the correct HOT, when I change to an external view the HOT is
incorrect.  I get 2 hits when in 1st view (looking out over my terrain) and
4 hits when in external view (looking at my player which is sitting just
above the terrain).

In the method below getHeightAndNormal() my_position is always the player
pos (I'm not passing in the camera by mistake !)

Note: the same problem happens with ssgIsect().

What am I missing here ???

Is it something to do with the scene matrix ... causing some difference
within the ssgHOT() call ???

float
getHeightAndNormal(ssgRoot* scene, sgVec3 my_position, sgVec3 normal)
{
	/* Look for the nearest polygon *beneath* my_position */

	ssgHit *results;
	int num_hits;

	float hot;        /* H.O.T == Height Of Terrain */
	sgVec3 HOTvec;

	sgMat4 invmat;
	sgMakeIdentMat4(invmat);
	invmat[3][0] = - my_position [0];
	invmat[3][1] = - my_position [1];
	invmat[3][2] = 0.0;

	sgSetVec3(HOTvec, 0.0f, 0.0f, HIGHEST_HEAVEN);

	num_hits = ssgHOT(scene, HOTvec, invmat, &results);

	hot = DEEPEST_HELL ;

	for (int i = 0; i < num_hits; i++)
	{
		ssgHit *h = &results[i];

		float hgt = - h->plane[3] / h->plane[2];

		if (hgt >= hot)
		{
			hot = hgt;

			if (normal != NULL)
				sgCopyVec3(normal, h->plane);
		}
	}

	return hot;
}

Nick
http://members.ozemail.com.au/~ndmcevoy/

Re: [Plib-users] Translucent Widgets

[dave <da...@mi...>]

Sebastian,

Well that answers that one.
Yes,while you were answering I figured out that I had confused
puSetDefaultColourScheme with puObject::setColourScheme.


I am still pondering the subject of whats going on inside widgets with 
"styles" though as far as blending goes. Hopefully a blend just affects 
them all equally once a puObject::setColour is done,  and all is well.
I don't know whether one would ever want the pieces implied by a style 
(foreground,background,mid.lo,hi,etc) to be affected uniquely though, or 
if it would even be possible.

Thanks for the feedback.
-Dave




Sebastian Ude wrote:

> 
> On Thu, 17 Jan 2002, da...@mi... (dave) wrote:
> 
>>Date: Thu, 17 Jan 2002 16:05:55 -0600
>>To: ud...@ha...
>>From: da...@mi... (dave)
>>Subject: Re: [Plib-users] Translucent Widgets
>>
>>It calls:
>>	static void load_colour_scheme()  within puObject.cxx.
>>
>>Maybe my C++ is a bit weak. There isn't a scope resolver. Isn't it true 
>>that just because  it's in the puObject.cxx file doesn't necessarily 
>>mean its part of the class?  Maybe I'm wrong. but my thought was to be 
>>part of the class it would need to be:
>>
>>         static void puObject::load_colour_scheme()
>>
>>wouldnt it?
>>
>>C++ has evolved a bit since I last used it. Could it be that the scope 
>>resolver is implicit to the entire cxx file?
>>
> 
> Yes. It was all the time.
> 
> The
> 
> void load_colour_scheme ( float col[][4], float r, float g, float b, float
> a ) ;
> 
> routine does nothing but filling the colour table specified with the
> calculated values.
> 
> 
> Hence, it can be and is used by both
> 
> puSetDefaultColourScheme
> 
> which modifies PUI's _global_ colour table specifying the default colours
> that are used when a widget is created and
> 
> puObject::setColourScheme
> 
> which modifies the widget's _local_ (!) colour table.
> 
> 
> - Sebastian
> 
> _______________________________________________
> plib-users mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-users
> 
> 
> 
> 

Re: [Plib-users] Translucent Widgets

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

On Thu, 17 Jan 2002, da...@mi... (dave) wrote:
> Date: Thu, 17 Jan 2002 16:05:55 -0600
> To: ud...@ha...
> From: da...@mi... (dave)
> Subject: Re: [Plib-users] Translucent Widgets
> 
> It calls:
> 	static void load_colour_scheme()  within puObject.cxx.
> 
> Maybe my C++ is a bit weak. There isn't a scope resolver. Isn't it true 
> that just because  it's in the puObject.cxx file doesn't necessarily 
> mean its part of the class?  Maybe I'm wrong. but my thought was to be 
> part of the class it would need to be:
> 
>          static void puObject::load_colour_scheme()
> 
> wouldnt it?
> 
> C++ has evolved a bit since I last used it. Could it be that the scope 
> resolver is implicit to the entire cxx file?

Yes. It was all the time.

The

void load_colour_scheme ( float col[][4], float r, float g, float b, float
a ) ;

routine does nothing but filling the colour table specified with the
calculated values.


Hence, it can be and is used by both

puSetDefaultColourScheme

which modifies PUI's _global_ colour table specifying the default colours
that are used when a widget is created and

puObject::setColourScheme

which modifies the widget's _local_ (!) colour table.


- Sebastian

Re: [Plib-users] Translucent Widgets

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

On Thu, 17 Jan 2002, da...@mi... (dave) wrote:
> Date: Thu, 17 Jan 2002 15:28:37 -0600
> To: pli...@li...
> From: da...@mi... (dave)
> Subject: Re: [Plib-users] Translucent Widgets

[...]

> It seems to me that each object should have a setColour() and load 
> color, ie, that these functions should be within the puObject class 
> instead of being global to PUI.

What about:

void puObject::setColourScheme ( float r, float g, float b, float a = 1.0f
) ;
void puObject::setColour ( int which, float r, float g, float b, float a =
1.0f ) ;

?


- Sebastian

Re: [Plib-users] Translucent Widgets

[dave <da...@mi...>]

I'd like to have various groups of widgets that have differing states of 
translucence. It isnt obvious to me how to do this. I don't know much 
about openGL/Glut, after all, the motivation to use higher level 
libraries is partly so I dont have to learn as much low-level details.

It seems to me that setting up a blend function just before calling 
puDisplay is the wrong approach. Setting the defaultColour would apply 
to the entire PUI display list would it not?  Also, it seems like one 
would always want to save/restore the previous defaultColour as well, 
and this would be going on a lot.


I suspect it is better to derive new translucent PUI classes and put the 
blending within each widget. One could then get a group box where the 
box's background is in one state of translucence, and the widgets on top 
of it can be slightly less translucent, ie, more solid, depending on how 
one programs the widgets as one builds the group.

It seems to me that each object should have a setColour() and load 
color, ie, that these functions should be within the puObject class 
instead of being global to PUI.

This seems like excessive work so I must be wrong, I just dont know 
quite how. Any suggestions?

Re: [Plib-users] error in doc/ssg/non_class.html ?

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

>Should it read
>ssgEntity *ssgLoad(char *fname, ssgLoaderOptions* opt =3D NULL);

=46ixed.

Bye bye,
Wolfram.

Re: [Plib-users] how???

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

Actually, there are several Windo$ people here. Simply open the
*.dsw/*.dsp files if you use MSVC.

Bye bye,
Wolfram.

Re: [Plib-users] how???

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

br...@tb... wrote:

>> how do i compile plib in windows?  I know most plib users aren't windows
>> people, but I'd like to try using this even though I don't know anything
>> about linux.  Can someone please help me out?

> Do you have Microsoft DevStudio? That's what I use and it works great. If
> you're having problems with that then maybe we can compare notes, but
> hopefully somebody else can help if you're using Cygwin or something.

AFAIK, the standard './configure ; make ; make install' mechanism
works OK for Cygwin under Windoze.

----------------------------- 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] how???

[<br...@tb...>]

On Wed, 16 Jan 2002, Andrew Masters wrote:

> how do i compile plib in windows?  I know most plib users aren't windows
> people, but I'd like to try using this even though I don't know anything
> about linux.  Can someone please help me out?
> -Andrew

Hi Andrew,

Do you have Microsoft DevStudio? That's what I use and it works great. If
you're having problems with that then maybe we can compare notes, but
hopefully somebody else can help if you're using Cygwin or something.

Have fun,
Dave

[Plib-users] how???

[Andrew M. <ama...@pt...>]

how do i compile plib in windows?  I know most plib users aren't windows
people, but I'd like to try using this even though I don't know anything
about linux.  Can someone please help me out?
-Andrew

Re: [Plib-users] Compiled, but can't execute...

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

On Tue, 15 Jan 2002, re...@ze... (Reed Hedges) wrote:
> Date: Tue, 15 Jan 2002 11:14:07 -0500
> To: pli...@li...
> From: re...@ze... (Reed Hedges)
> Subject: Re: [Plib-users] Compiled, but can't execute...
>
> Is this that same RedHat error/race that was discussed earlier (where 
> the window is slow to get created, or something?)

Yes. Excactly that one.


- Sebastian

Re: [Plib-users] Compiled, but can't execute...

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

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


Is this that same RedHat error/race that was discussed earlier (where 
the window is slow to
get created, or something?)



- --

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

iEYEARECAAYFAjxEVVEACgkQ43zrjhPEi79FTACfTX//JUb7j3gZYS7m6pmgkplE
MoAAn0t1ULesK/TAFHrpsEvXYUSwjPYo
=/G5r
-----END PGP SIGNATURE-----

Re: [Plib-users] Compiled, but can't execute...

[Lo'oRiS il K. <_l...@li...>]

> evening (we seem to be in the same time zone).

sure, simply look at the domain of the address...

> I do not know whether it is neccessary to update the devel package as w=
ell,
> but it's a good idea. It does not hurt.

it didn't :)

> > > *Always* use your distributions packages wherever possbile unless y=
ou a
> > > re *absolutely* sure what you are doing.
> >=20
> > i'll probably change distribution soon...
>=20
> Okay, but this is a genral rule for every distribution that has some ki=
nd
> of package managent.

right...

PS: if everything correct u should already have received the mail where i=
 say now everything works...

--=20

"Bleeeeeeeehhhhhhh!!! bleeeeeeeehhhhhhhhh!!! Goblin! Goblin!"
                                        a goblin

_.-:/=B0^^=B0\:-._.-:/=B0^^=B0\:-._          __.         ____
 - Lo'oRiS il Kabukimono -          / /|       /^___ \
Real Name: Lorenzo Petrone         / / /      / /L_/ /
e-mail: _l...@li...          / / /      /  ___-=B0/
irc.azzurra.org #lano            / /_/__    /  /|__-=B0
digilander.iol.it/lano666       /______/|  /__/ /
^=B0\:-.__.-:/=B0^=B0\:-.__.-:/=B0^     |______|/  |__L/

Re: [Plib-users] Compiled, but can't execute...

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

On Tue, 15 Jan 2002, _l...@li... (Lo'oRiS il Kabukimono) wrote:
> Date: Tue, 15 Jan 2002 15:42:24 +0100
> To: Sebastian Ude <ud...@ha...>
> From: _l...@li... (Lo'oRiS il Kabukimono)
> CC: pli...@li...
> Subject: Re: [Plib-users] Compiled, but can't execute...
>
> > Aaaargh ... seems like my ISP had some technical problems yesterday so
> > that a mail I sent to the list was rejected.
>
> no, i received it 10 minutes ago... :)

Yes, that's because I have re-sent it. I initially sent it yesterday
evening (we seem to be in the same time zone).


> now i'm downloading that package and hoping it will work... but... should
> 't i'd also need the devel package?

I do not know whether it is neccessary to update the devel package as well,
but it's a good idea. It does not hurt.


> > *Always* use your distributions packages wherever possbile unless you a
> > re *absolutely* sure what you are doing.
> 
> i'll probably change distribution soon...

Okay, but this is a genral rule for every distribution that has some kind
of package managent.


- Sebastian

Re: [Plib-users] Compiled, but can't execute...

[Roy W. <ro...@ce...>]

>> and reinstalled my RedHat Mesa RPMs and all was well again.  For some 
>> reason, Mesa seems to default to software rendering.
>
>and how can i enable direct rendering?

I never did figure that out.  As mentioned in a followup email, I got my 
RPMs from Brian Hayward here:

http://www.slothmud.org/~hayward/mesafix


These fixed things perfectly for me.  Your mileage may vary.


-Roy