plib-users

RE: [Plib-users] Compiling for windows

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

Eric Espie writes:
>
>I found that PLIB fonts looked blurry with my voodoo 2 and 
>gltt bitmap fonts
>too slow, so for TORCS I use glf fonts.
>It is (IMHO) the same principle than PLIB fonts, so don't 
>expect any speed
>benefits from PLIB fonts (with all the respect due to PLIB).
>The other advantage of glf over PLIB is that the 'texture' is 
>done with a true type font an not an X11 one.

You can use true type fonts with PLib
You just have to make the textures yourself.
You can also make the texture text font size
to exactly match yhe desired output size and
this will take care of any 'blurring'.  :-)

Also FWIW there is some 'ugly' code in the FlightGear 
Source cockpit / hud.hxx 
that I used to speed up PLib text when I 'KNEW'
that I was rendering a lot of text with no intervening 
glstate changes.   

class fgText 
class fgTextList

This code could probably be cleaned up a little bit
but it served its purpose for me as is :-)

Cheers

Norman

Re: [Plib-users] Library Initialization

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

Sam Stickland wrote:

> > You might want to downgrade your gcc to something that works.  RedHat
> > are coming in for a lot of flak over their decision to ship a relatively
> > poorly tested beta version.
> 
> No need.  Type recompiling everything with kgcc instead of gcc. kgcc is the
> Linus blessed version for compiling kernals.

I havn't heard of that.  It's not installed on SuSE Linux.
 
> alias gcc kgcc
> 
> might do the trick

...and g++ ==> kg++ ?

I don't think an 'alias' will work BTW, the Makefile system probably uses
bash or something.

You'd probably have to rename the original gcc/g++ to something else and
symlink to them to kgcc or whatever.

-- 
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-users] Compiling for windows

[Eric E. <Eri...@fr...>]

Don Lafontaine wrote:
> 
> Cool,  I'll try to whip a few up.
> 
> I'm thinking of replacing "glf" fonts with plib fonts.  I hope to get a
> little more speed out of my project.  It uses text pretty heavily compared
> to the average OpenGL program.

I found that PLIB fonts looked blurry with my voodoo 2 and gltt bitmap fonts
too slow, so for TORCS I use glf fonts.
It is (IMHO) the same principle than PLIB fonts, so don't expect any speed
benefits from PLIB fonts (with all the respect due to PLIB).
The other advantage of glf over PLIB is that the 'texture' is done with a true type
font an not an X11 one.
One problem is that the glf 'texture' generator is not freeware and it runs only under
Win32 (but the lib is freeware).

> 
> http://www.avsim.com/hangar/utils/freefd
> 
> Don.
> ----- Original Message -----
> From: "Steve Baker" <sjb...@ai...>
> To: <pli...@li...>
> Sent: Wednesday, October 11, 2000 12:22 AM
> Subject: Re: [Plib-users] Compiling for windows
> 
> > > Don Lafontaine wrote:
> > >
> > > Hi,  has anyone managed to compile with MSVC6.0?
> >
> > Yes - quite a few people use it routinely under MSVC 6.
> >
> > > I tried to load the projects,  but they are invalid.
> >
> > They tend to get out of date because when Linux people
> > work on PLIB they have no way to keep the MSVC project
> > files up to date.
> >
> > > Does anyone have project files that work?
> >
> > I'm sure they do...if not, it shouldn't be hard
> > to remake them.  Each directory in 'src' is an independent
> > library - just compile everything in that directory
> > and link it all together.
> >
> > --
> > 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-users mailing list
> > pli...@li...
> > http://lists.sourceforge.net/mailman/listinfo/plib-users
> >
> 
> _______________________________________________
> plib-users mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-users

-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

                       TORCS
            The Open Racing Car Simulator
                 http://torcs.org

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

Re: [Plib-users] Library Initialization

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

----- Original Message -----
From: "Steve Baker" <sjb...@ai...>
To: <pli...@li...>
Sent: Tuesday, October 10, 2000 5:10 PM
Subject: Re: [Plib-users] Library Initialization


> Elad Lahav wrote:
> >
> > OK, I have tried to exclude as many reasons as possible for this
failure,
> > and this is what I got:
> > 1. Reinstalled RH 7,
>
> *BZZT*BZZT* WARNING! WARNING!
>
> You might want to downgrade your gcc to something that works.  RedHat
> are coming in for a lot of flak over their decision to ship a relatively
> poorly tested beta version.

No need.  Type recompiling everything with kgcc instead of gcc. kgcc is the
Linus blessed version for compiling kernals.

alias gcc kgcc

might do the trick

Sam

Re: [Plib-users] Compiling for windows

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

Don wrote:

>Hi,  has anyone managed to compile with MSVC6.0?

Yes, many.  One of the main developers develops in MSVC and there are
several people who regularly compile the newest CVS stuff, most often
without any problems.

>I tried to load the projects,  but they are invalid.  

Which? All? What do you mean by invalid? Dont they load into MSVC or
dont they compile?

>Does anyone have project files that work?

I just did an update from cvs (but I didnt do a checkout from
scratch). Then I batch build everything, both in debug and release
builds. Not one error. I use MSVC 6 service pack 3.

Our projects at work are in Micro$oft Visual Source Safe.
When I get a new plib, MSVC asks whether I want to connect
plib with the version control system. Just say "no".

OT, just say no to VSS alltogether, it sometimes corrupts your
repository :-((. It happened once to us and we were just lucky we lost
nothing. On Slashdot lots of people complained about this. What worse
thing can a Source "Safe" do than eat your code?


>Thanks
>
>Don.

I am of to work now,
Wolfram.

Re: [Plib-users] Compiling for windows

[Don L. <laf...@cn...>]

Cool,  I'll try to whip a few up.

I'm thinking of replacing "glf" fonts with plib fonts.  I hope to get a
little more speed out of my project.  It uses text pretty heavily compared
to the average OpenGL program.

http://www.avsim.com/hangar/utils/freefd

Don.
----- Original Message -----
From: "Steve Baker" <sjb...@ai...>
To: <pli...@li...>
Sent: Wednesday, October 11, 2000 12:22 AM
Subject: Re: [Plib-users] Compiling for windows


> > Don Lafontaine wrote:
> >
> > Hi,  has anyone managed to compile with MSVC6.0?
>
> Yes - quite a few people use it routinely under MSVC 6.
>
> > I tried to load the projects,  but they are invalid.
>
> They tend to get out of date because when Linux people
> work on PLIB they have no way to keep the MSVC project
> files up to date.
>
> > Does anyone have project files that work?
>
> I'm sure they do...if not, it shouldn't be hard
> to remake them.  Each directory in 'src' is an independent
> library - just compile everything in that directory
> and link it all together.
>
> --
> 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-users mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-users
>

Re: [Plib-users] Compiling for windows

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

> Don Lafontaine wrote:
> 
> Hi,  has anyone managed to compile with MSVC6.0?

Yes - quite a few people use it routinely under MSVC 6.

> I tried to load the projects,  but they are invalid.

They tend to get out of date because when Linux people
work on PLIB they have no way to keep the MSVC project
files up to date.
 
> Does anyone have project files that work?

I'm sure they do...if not, it shouldn't be hard
to remake them.  Each directory in 'src' is an independent
library - just compile everything in that directory
and link it all together.

-- 
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-users] Menubars overlapped by other widgets

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

"Vaughn C. Clayton" wrote:
> 
> I am developing a data visualization program that uses PUI for a menubar
> and widgets to change options and things. I have multiple sets of widgets
> that I create and destroy depending on what options the user is working
> with. The problem is that the menus dropped down from the menubar are
> displayed behind the currently displayed widgets.
>  Is there any way to explicitly set the draw order, or the layer, or
> whatever you want to call it? Or are there any other ideas that could get
> these menus on top where they belong?
> 
> BTW - I mentioned that I create and destroy sets of widgets because I
> think the problem is that the menubar is created once, before all these
> other widgets, and is therefore drawn first, then overlapped.

Yes - that's exactly it.  Widgets are drawn in the order they are
declared.  I suppose you should delete and recreate the menu bar
after each time you delete and recreate one of the other widgets.
It's probably not that inefficient compared to regenerating those
other widgets.

I guess this is kindof unfortunate...and rather nasty to fix too.

Ick!

-- 
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-users] Library Initialization

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

Elad Lahav wrote:
> 
> OK, I have tried to exclude as many reasons as possible for this failure,
> and this is what I got:
> 1. Reinstalled RH 7,

*BZZT*BZZT* WARNING! WARNING!

You might want to downgrade your gcc to something that works.  RedHat
are coming in for a lot of flak over their decision to ship a relatively
poorly tested beta version.

> with the original kernel and libraries, and still got
> the same GL context issue...

Well - I'm rather unconvinced - I don't think this is a PLIB problem.

> 2. Compiled other, non-plib, GL-dependant programmes. They seemed to work
> fine.

Well, that's interesting - but I *still* don't think it's a PLIB problem.

The deal is that you really havn't run much PLIB code by this stage:

The rule is that the first SSG function to be called MUST be ssgInit - and
ssgInit must not be called until there is a valid OpenGL rendering context.

The very first line of that function is a call to glIsValidContext whose
very first line is to ask X if there is a valid rendering context.
Immediately upon return, you are getting that error message saying
that there isn't a valid context.

So, if FGFS has a valid rendering context in the line immediately before
the very first ever call to a PLIB function (well, a PUI, FNT or SSG function
at least) - then you could insert a glXGetCurrentContext in the line just
before ssgInit is called and it would return some non-NULL value.

Then you are telling me that sometime in the next three lines, PLIB somehow
corrupts that context and then - testing it a second time - get's NULL back?

I don't believe that.

Ergo FGFS did not have a valid context before calling ssgInit - so it's
FGFS's fault.  I can't see a flaw in that reasoning.

You may not previously have seen this message with earlier versions
of PLIB because we were not doing the check - now we are, we may have
uncovered a FGFS error of some kind....I don't know.

> 3. When trying FlightGear, I have compiled all libraries and programmes
> (plib, SimGear and FlightGear), on the same machine, with the same compiler,
> at the same time (so you can't even blame it on weather changes...;-)
> Anything else?

Well, I think you should hack into plib/src/ssg/ssg.cxx, see where it says 'glXGetCurrentContext'
in 'glIsValidContext' - print out the value that glXGetCurrentContext returns.  Also stick
a printf inside 'ssgInit' so we know that it is truly what called glIsValidContext.

Now, put a check for glXGetCurrentContext into FGFS in the line before you call
ssgInit - and you'll know for sure.

Incidentally, a similar test for a valid OpenGL context is made in PUI's puInit
(which FGFS is presumably also calling)...and also in the FNT font loader. 
*PRESUMABLY* those are being called after ssgInit - so we don't see them complain.

I *suspect* the RedHat C++ compiler - it's been implicated in several problems in
other projects this week.  If I'd bought a copy of RH 7, I'd be demanding my money
back.  They did a VERY irresponsible thing and use poor package maintainers are
suffering the consequences.  That gets me somewhat upset.  I can only imagine
what the GCC maintainers are going through.


-- 
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-users] Compiling for windows

[Don L. <laf...@cn...>]

Hi,  has anyone managed to compile with MSVC6.0?

I tried to load the projects,  but they are invalid. =20

Does anyone have project files that work?

Thanks

Don.

[Plib-users] Menubars overlapped by other widgets

[Vaughn C. C. <cl...@et...>]

I am developing a data visualization program that uses PUI for a menubar
and widgets to change options and things. I have multiple sets of widgets
that I create and destroy depending on what options the user is working
with. The problem is that the menus dropped down from the menubar are
displayed behind the currently displayed widgets.
 Is there any way to explicitly set the draw order, or the layer, or
whatever you want to call it? Or are there any other ideas that could get
these menus on top where they belong?


BTW - I mentioned that I create and destroy sets of widgets because I
think the problem is that the menubar is created once, before all these
other widgets, and is therefore drawn first, then overlapped.


-------------------------------
Vaughn C. Clayton
Brigham Young University
Center for Earth Remote Sensing
cl...@et...

Re: [Plib-users] Library Initialization

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

Try getting plib from cvs, and get the examples as well. Let me know if the
examples are not working either. Also do you have glut installed. Also if
you want you can mail me directly and I can try to help you off this list.

Later Ben
----- Original Message -----
From: Elad Lahav <el...@el...>
To: <pli...@li...>
Sent: Tuesday, October 10, 2000 2:58 AM
Subject: RE: [Plib-users] Library Initialization


> OK, I have tried to exclude as many reasons as possible for this failure,
> and this is what I got:
> 1. Reinstalled RH 7, with the original kernel and libraries, and still got
> the same GL context issue
> 2. Compiled other, non-plib, GL-dependant programmes. They seemed to work
> fine.
> 3. When trying FlightGear, I have compiled all libraries and programmes
> (plib, SimGear and FlightGear), on the same machine, with the same
compiler,
> at the same time (so you can't even blame it on weather changes...;-)
> Anything else?
>
> Elad
>
> By the way, thanks for the quick responds...
>
>
> _______________________________________________
> plib-users mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-users
>
>

RE: [Plib-users] Library Initialization

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

Elad Lahav writes:
>
>OK, I have tried to exclude as many reasons as possible for 
>this failure,
>and this is what I got:
>1. Reinstalled RH 7, with the original kernel and libraries, 
>and still got the same GL context issue
>2. Compiled other, non-plib, GL-dependant programmes. They 
>seemed to work fine.
>3. When trying FlightGear, I have compiled all libraries and programmes
>(plib, SimGear and FlightGear), on the same machine, with the 
>same compiler,
>at the same time (so you can't even blame it on weather changes...;-)
>Anything else?

Hmm...

What versions of the libraries are you using ??

Did RedHat include these or did you download them ?

     Is there a 
/ usr / local / include / plib 
       that is hiding  
/ usr / include / plib

What does running this produce

#include <stdio.h>
#include <plib/ssg.h>
iny main(int argc char **argv) {
  printf("Plib Version %s\n", ssgGetVersion());
}

Cheers

Norman

RE: [Plib-users] Library Initialization

[Elad L. <el...@el...>]

OK, I have tried to exclude as many reasons as possible for this failure,
and this is what I got:
1. Reinstalled RH 7, with the original kernel and libraries, and still got
the same GL context issue
2. Compiled other, non-plib, GL-dependant programmes. They seemed to work
fine.
3. When trying FlightGear, I have compiled all libraries and programmes
(plib, SimGear and FlightGear), on the same machine, with the same compiler,
at the same time (so you can't even blame it on weather changes...;-)
Anything else?

				Elad

By the way, thanks for the quick responds...

Re: [Plib-users] Library Initialization

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

Norman Vine wrote:

> >I am using RedHat 7.0, kernel 2.4.0-test7, XFree86 4.0.1 with
> >a 3dfx Voodoo3 3000.
> 
> Sounds like this might be a compiler issue.
> RedHat 7.0 is shipping with a gcc that produces
> non-compatable c++ object files.
> see
> http://gcc.gnu.org/ml/gcc-announce/2000/msg00003.html
> 
> FWIW
> My guess is that if you make sure all files including linked libs
> are compiled on your machine things should work.

Oooh!  Yes - I'd forgotten about *that*.

This is a *very* good excuse!  We can blame all RH7 problems
on this one!  SuSE Linux Roolz! (etc)

The most ironic thing about this horrible fiasco is that most gcc
development is done by Cygnus people who are owned by RedHat!!

I'm really upset that RedHat would do such an incredibly STOOPID
thing.  I think the gcc people are being most restrained about
the whole thing.

(If you didn't hear, RedHat took an unreleased CVS copy of gcc
and released it on RH7's CD collection.  It's quite the most
irresponsible thing they've done for a LONG time!)

-- 
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-users] Including string.h in library headers.

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

David Williams wrote:
> 
> Is there any reason why ssg.h and js.h don't include string.h themselves,
> since(at least under recent Linux Distributions) it is needed to define
> memcpy?

Nope - it's a simple oversight.

I'll fix it.

> Pretty much the library expects you to define some functions that it uses
> internally(and which you shouldn't need to worry about as a user), prior
> to even including the library headers.

Since most main programs use <string.h> somewhere - and therefore include
it themselves, I doubt that anyone noticed this drop-off before.

Good catch!  Thanks.
 
> Does anyone know if that would break out of the box compiles of the
> library on any systems?

No - it shouldn't.
 
-- 
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-users] Library Initialization

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

Elad Lahav wrote:
> 
> I have tried a couple of programmes based on plib, and encountered the same
> result. The plib libraries will not initialize, claiming a GL context was
> not created.

Well, it PLIB calls 'glXGetCurrentContext()' to test for a valid GL context.
If that test fails then (somehow) you are not getting a valid context.

> I have checked the source of these applications (FlightGear and
> some Tux game), and seen that glutInit is called, so it should have worked.

Well, only if glutInit managed to find a valid OpenGL context.

Are you sure your OpenGL is correctly installed?

Do (for example) the GLUT demo programs work?

> I am using RedHat 7.0, kernel 2.4.0-test7, XFree86 4.0.1 with a 3dfx Voodoo3
> 3000.

Well, I know that FlightGear and both Tux games that use PLIB (TuxKart,
TuxAQFH do, TuxRacer doesn't) all work just fine with RedHat/Xfree4.0.1/Voodoo-3...
that's a very well tested configuration....although the 2.4.0-test7 kernel is pretty
suspicious.

I think you should back up a little and try the GLUT/Mesa test programs.

If those work, pick one of them and add a call to glXGetCurrentContext just after
glutInit and check that it returns a non-NULL result.

If all that works as expected then it's a PLIB problem - so come back to this
list and we'll see what's going on.

If those tests fail - then it's not a problem with either of the games or PLIB
and
you'll need to take it up with the Mesa team.  (www.mesa3d.org)

So, either it's the Kernel (I doubt it) or your Mesa installation (with all that
DRI stuff, it can get tricky).

-- 
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-users] Library Initialization

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

Elad Lahav writes:
>
>I have tried a couple of programmes based on plib, and encountered the same
>result. The plib libraries will not initialize, claiming a GL context was
>not created. I have checked the source of these applications (FlightGear
and
>some Tux game), and seen that glutInit is called, so it should have worked.
>Any suggestions?
>I am using RedHat 7.0, kernel 2.4.0-test7, XFree86 4.0.1 with
>a 3dfx Voodoo3 3000.

Sounds like this might be a compiler issue.
RedHat 7.0 is shipping with a gcc that produces
non-compatable c++ object files.
see
http://gcc.gnu.org/ml/gcc-announce/2000/msg00003.html

FWIW
My guess is that if you make sure all files including linked libs
are compiled on your machine things should work.

ie no rpm's unless compiled specifically for RedHat 7.0

< disclaimer >
I have never even booted Linux, but I do have LOTS of experience
with incompatable object file formats ( Thanks M$oft )  :-(
</>

Good Luck

Norman

[Plib-users] Including string.h in library headers.

[David W. <dj...@ef...>]

Is there any reason why ssg.h and js.h don't include string.h themselves,
since(at least under recent Linux Distributions) it is needed to define
memcpy?

Pretty much the library expects you to define some functions that it uses
internally(and which you shouldn't need to worry about as a user), prior
to even including the library headers. 

Does anyone know if that would break out of the box compiles of the
library on any systems?

[Plib-users] Library Initialization

[Elad L. <el...@el...>]

I have tried a couple of programmes based on plib, and encountered the same
result. The plib libraries will not initialize, claiming a GL context was
not created. I have checked the source of these applications (FlightGear and
some Tux game), and seen that glutInit is called, so it should have worked.
Any suggestions?
I am using RedHat 7.0, kernel 2.4.0-test7, XFree86 4.0.1 with a 3dfx Voodoo3
3000.

						Elad

[Plib-users] SSG format files and a change to ssgEntity/ssgBase

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

Are any of you users/developers of PLIB's SSG library actively saving files
in '.ssg' file format?

I'd like to make a small (non-backwards-compatible) change to the file
format to allow objects lower in the file heirarchy to have 'name' strings.
(eg ssgState objects).

But if I do that, it'll prevent existing SSG files from being read by
applications linked to PLIB v.1.3.1 or later.

I *could* go to great and complex lengths to work around this problem - but
if (as I suspect) - people are only using '.ssg' format as a temporary format,
then there won't be any point in me writing all that stuff.

If I don't hear from anyone within a week or so, I'll assume that nobody cares.

-- 
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-users] Re: [Plib-devel] *** Fix for TuxKart ***

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

Hi,

Sam Stickland wrote:
> 
> Remember people - don't delete your objects in callbacks!

Thank you for that one - this *could* be a possible answer 
for the weird behavior of TuxFleet's GUI, I'm doing deletes
all way long in callbacks (bang my head...)  :-(


Alex


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

Re: [Plib-users] Plib, OpenGL and particle engines

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

Risto S Varanka wrote:
> 
> > Hmmm - maybe I should dump plumber3d into the PLIB examples directory sometime.
> 
> Well, if it's added there it has to be maintained too :^)
> 
> Having some code to look at would be rather helpful, since I
> don't really know how to make things with these objects. Could you
> please send the code to me?

Actually, having thought about it carefully, I don't think it makes
an appropriate PLIB example program...so yesterday I created a new
project at Sourceforge "toobular" and I'll place the code there...when
I have a spare millisecond or two.

Whether I'll ever have time to turn it into a playable game, I doubt.
But at least if it's there, it's out there for someone else to play
with...and heck - I can stop doing backups of it from my hard drive!

   :-) 

> I saw there is some code with ssgVTable in the Majik demo too, but
> it would probably take some time to figure out, since I don't know
> what is done with it.

The ssgVTable is really rather obsolete - we are encouraging people
to use ssgVtxArray these days - it's the fastest mechanism for
drawing polygons in SSG right now.

The best places to get examples is in the SSG file loaders.  But
most programs just call a loader to grab stuff off disk rather
than generating ssgLeaf nodes by themselves.

-- 
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-users] Plib, OpenGL and particle engines

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

you might want to look at Mark's wavingFlag demo in examples/src/ssg/tux. i
found it very useful to create a particle system.

--Dave

> > Hmmm - maybe I should dump plumber3d into the PLIB examples 
> directory sometime.
> 
> Well, if it's added there it has to be maintained too :^) 
> 
> Having some code to look at would be rather helpful, since I
> don't really know how to make things with these objects. Could you
> please send the code to me? 
> 
> I saw there is some code with ssgVTable in the Majik demo too, but
> it would probably take some time to figure out, since I don't know
> what is done with it. 
> 
> -- 
> Risto Varanka

Re: [Plib-users] Plib, OpenGL and particle engines

[Risto S V. <rva...@cc...>]

> Hmmm - maybe I should dump plumber3d into the PLIB examples directory sometime.

Well, if it's added there it has to be maintained too :^) 

Having some code to look at would be rather helpful, since I
don't really know how to make things with these objects. Could you
please send the code to me? 

I saw there is some code with ssgVTable in the Majik demo too, but
it would probably take some time to figure out, since I don't know
what is done with it. 

-- 
Risto Varanka | http://www.helsinki.fi/~rvaranka/		
ris...@he...