plib-users

Re: [Plib-users] PLib compilation fails on OpenBSD

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

Heikki Korpela wrote:
> 
> I'm using OpenBSD 2.8, stable. Both 1.2.0 and 1.3.1 versions of PLib
> fail to compile:
> 
> c++ -DPACKAGE=\"plib\" -DVERSION=\"1.2.0\" -DHAVE_LIBGL=1 -DHAVE_LIBGLU=1 -DHAVE_LIBGLUT=1 -DSTDC_HEADERS=1 -DHAVE_GL_GL_H=1 -DHAVE_GL_GLU_H=1 -DGLUT_IS_PRESENT=1  -I. -I.    -I/usr/local/include -L/usr/local/lib  -I/usr/local/include -L/usr/local/lib -O6 -Wall -c slDSP.cxx
> In file included from slDSP.cxx:2:
> sl.h:96: macro `ioctl' used with only 2 args
> 
> README.openbsd for SL suggests to use 'make openbsd', while target
> openbsd is not defined for any targets as far as I can see.

I guess the OpenBSD community hasn't been using PLIB recently so the
code has 'rotted'...if you have a fix, please contribute it - but there
are not (AFAIK) any other OpenBSD users here who could hope to solve
your problem.  Maybe some NetBSD or FreeBSD people here can help?

Under Linux, the 'ioctl' call has an optional third argument:

      #include <sys/ioctl.h>
 
      int ioctl(int d, int request, ...)
 
I think (from the sound of the error), that OpenBSD has somehow defined 'ioctl'
as a macro - that's **WRONG** because in C++ you should be able to overload
the names of system functions (as we have done here) - but if the host OS
defines them as macro's, that won't work.

I guess you should demand that OpenBSD fix this - but since that's unlikely
to have the immediate effect you need, I guess the best fix is to replace
all of *our* overloaded ioctl functions with something like XXXioctl - so
they don't trigger the macro substitution.

Can you confirm that this *truly* is the cause - and if it is, one of us
will fix it for you.

Yuk, Yuk, Yuk!

-- 
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
                         http://freeglut.sourceforge.net

[Plib-users] PLib compilation fails on OpenBSD

[Heikki K. <he...@sa...>]

I'm using OpenBSD 2.8, stable. Both 1.2.0 and 1.3.1 versions of PLib
fail to compile:

c++ -DPACKAGE=\"plib\" -DVERSION=\"1.2.0\" -DHAVE_LIBGL=1 -DHAVE_LIBGLU=1 -DHAVE_LIBGLUT=1 -DSTDC_HEADERS=1 -DHAVE_GL_GL_H=1 -DHAVE_GL_GLU_H=1 -DGLUT_IS_PRESENT=1  -I. -I.    -I/usr/local/include -L/usr/local/lib  -I/usr/local/include -L/usr/local/lib -O6 -Wall -c slDSP.cxx
In file included from slDSP.cxx:2:
sl.h:96: macro `ioctl' used with only 2 args

README.openbsd for SL suggests to use 'make openbsd', while target
openbsd is not defined for any targets as far as I can see.

<!-- ---------------------- 72 characters -------------------------- -->
                   Heikki Korpela -- he...@sa...

[Plib-users] =?iso-8859-1?Q?=CE=F2=E2=E5=F2:_=5BPlib-users=5D_Compiling_PLIB_under?= =?iso-8859-1?Q?_Windows_using_Borland_C++_Builder_5.02?=

[Shchetinin <Mal...@ma...>]

Hi
I managed to compile PLIB under BCB 3 (1998 "oldie"). Just create a "LIB"
project and insert all the files into the project, maybe some project-wide
defines will be needed to get rid of errors.
Maluke.

[Plib-users] Compiling PLIB under Windows using Borland C++ Builder 5.02

[Thomas G. <pin...@we...>]

I tried to compile PLIB under Window$ 2000 using Borland C++ Builder 5.02,
but it didn't work. Can anybody help me or send me a project file?

-- 

cheers,
Thomas Gahr
(da....@we...)

Re: [Plib-users] Bug report

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

Fredrik Sandström wrote:
> 
> On Sun, 1 Apr 2001, Per Liedman wrote:
> 
> > I don't think it should be deleted. It's just a pointer to a node, and that
> > node is a part of the model that is loaded, and thus should not be deleted.
> > But I could be missing some fine details of my own code. Feel free to comment
> > further if you have any examples of when current_branch causes leaks.

I've just read the code - and I agree - 'current_branch' is just a temporary variable
used to hold a pointer between it being created and it's child objects finally being
bolted into the tree.

I don't see what it's holding that won't be deallocated when the tree is
ultimately 'delete'd.

> After doing...
> 
>  ssgEntity *loadThis = ssgLoad(tmp);
>  delete loadThis;
>  loadThis = NULL;
> 
> ...the debugger reports that memory allocated to current_branch hasn't
> been deallocated, so the leak is somewhere in the loader at least.

I don't know what the debugger is thinking here...I don't see how something
can be passed into current_branch without being connected into the tree - and
'ref' counting should take care of the cleanup after that.

-- 
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
                         http://freeglut.sourceforge.net

Re: [Plib-users] Bug report

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

Fredrik Sandström wrote:
> 
> On Sun, 1 Apr 2001, Steve Baker wrote:
> 
> > Per Liedman wrote:
> >
> > > Interesting and annoying. Should we just refuse to load too large models?
> >
> > More than 65535 vertices in a single ssgLeaf is "A Bad Thing" anyway because
> >
> It crashes at the 10922:th (int / 6) vertex....

Ick!  I'd forgotten about that.

> ...which still qualifies to the
> "Bad Thing" category but is quite common for 3ds meshes. I've got a big
> neanderthal human skin which contains just above this number of vertices.
 
Well, perhaps - but it's still a bad idea to store that many vertices in a
single ssgLeaf.  Think about the situation where your Neanderthal is half
on screen and half off.  You have to weigh the cost of stuffing half of
those 10922 vertices down the graphics pipe - versus the cost of a handful
of bounding sphere tests.

When the whole mesh is entirely on-screen, the bounding sphere tests are
wasted (but even a dozen of them will be negligable compared to the cost
of redundantly fetching and stuffing all those vertices.  But when the end
of the Neanderthal's nose is the only thing on screen, those few extra
tests will make the model run a thousand times faster.

So, I think you should aim to keep your triangle meshes under a thousand
vertices - with modern T&L hardware.  With older pre-T&L hardware, you
should keep leaf nodes down at a few dozen vertices since a bounding
sphere test is *FAR* cheaper than drawing even one triangle more than you
need.

> Well, it's more the incompatibility of the int return type of the possible
> number of vertices and the actual short counter limit that I feel is the
> bug.

I disagree on that point...the number of vertices is an integer value (in the
mathematical sense) - if I choose to return a number with a larger potential
range than the actual range, that's my business.  If you were measuring objects
in inches that could only be a foot long - you wouldn't demand that I define a
4 bit variable to hold the number.  The original C manuals said that 'int' is
the most *efficient* type on whatever machine you are running on - so you should
only use a 'short' where storage space is at a premium.  I think that's a *good*
rule and I try to stick by it.

-- 
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
                         http://freeglut.sourceforge.net

Re: [Plib-users] Bug report

[Per L. <li...@ho...>]

On Monday 02 April 2001 12:23, Fredrik Sandstr=F6m wrote:
> On Sun, 1 Apr 2001, Per Liedman wrote:
> > I don't think it should be deleted. It's just a pointer to a node, an=
d
> > that node is a part of the model that is loaded, and thus should not =
be
> > deleted. But I could be missing some fine details of my own code. Fee=
l
> > free to comment further if you have any examples of when current_bran=
ch
> > causes leaks.
>
> After doing...
>
>  ssgEntity *loadThis =3D ssgLoad(tmp);
>  delete loadThis;
>  loadThis =3D NULL;
>
> ....the debugger reports that memory allocated to current_branch hasn't
> been deallocated, so the leak is somewhere in the loader at least.
>
> This is the part of the debug loggin that contains the block that seems=
 to
> be causing the leak.
> <snip>
>         Found chunk 4000 of length 54 (known)
>         Object block "default#1"
>             Found chunk 4700 of length 38 (unknown)
>     Found chunk B000 of length 1313 (known)
> <snip>
>
> It's the last Object block (of two) which might explain why the
> current_branch pointer seems to be responsible for the leak.
>
> Maybe it has something to do with there being a dummy object in the mod=
el?
>
> I can send you my model if you like, it's just ~50kb in size.

Yes, please do. I'll try to take a look at it.

--=20
   / Per Liedman
  / li...@ho...
 / www.mdstud.chalmers.se/~md6pl
/ 031-825659 / 0705-520455

Re: [Plib-users] Bug report

[<dva...@cs...>]

On Sun, 1 Apr 2001, Per Liedman wrote:

> I don't think it should be deleted. It's just a pointer to a node, and that 
> node is a part of the model that is loaded, and thus should not be deleted. 
> But I could be missing some fine details of my own code. Feel free to comment 
> further if you have any examples of when current_branch causes leaks.
>

After doing...

 ssgEntity *loadThis = ssgLoad(tmp);
 delete loadThis;
 loadThis = NULL;

...the debugger reports that memory allocated to current_branch hasn't
been deallocated, so the leak is somewhere in the loader at least.

This is the part of the debug loggin that contains the block that seems to
be causing the leak. 
<snip>
        Found chunk 4000 of length 54 (known)
        Object block "default#1"
            Found chunk 4700 of length 38 (unknown)
    Found chunk B000 of length 1313 (known)
<snip>

It's the last Object block (of two) which might explain why the
current_branch pointer seems to be responsible for the leak. 

Maybe it has something to do with there being a dummy object in the model?

I can send you my model if you like, it's just ~50kb in size.

/Fredde

Magic is Life - Technology is Death

Re: [Plib-users] Bug report

[<dva...@cs...>]

On Sun, 1 Apr 2001, Steve Baker wrote:

> Per Liedman wrote:
> 
> > Interesting and annoying. Should we just refuse to load too large models?
> 
> More than 65535 vertices in a single ssgLeaf is "A Bad Thing" anyway because
>
It crashes at the 10922:th (int / 6) vertex, which still qualifies to the
"Bad Thing" category but is quite common for 3ds meshes. I've got a big
neanderthal human skin which contains just above this number of vertices.
 
Well, it's more the incompatibility of the int return type of the possible
number of vertices and the actual short counter limit that I feel is the
bug.

/Fredde

Magic is Life - Technology is Death

Re: [Plib-users] Bug report

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

Per Liedman wrote:

> > * The 3ds-loader also have problems with large models. It can load them
> > ok, but when ypu try to manipulate them PLib will crash. This is because
> > the loader creates VtxTables with too many vertices in them. The getVertex
> > function can only handle shorts but the number of vertices variable is an
> > int, making it possible to load more vertices than some of PLib's other
> > functions can handle.
> 
> Interesting and annoying. Should we just refuse to load too large models?

More than 65535 vertices in a single ssgLeaf is "A Bad Thing" anyway because
the entire leaf either is or isn't passed on to OpenGL...there is no field
of view culling *within* an ssgLeaf.

If your model has nodes as large as that, it's not going to render efficiently
anyway.

We *could* automatically split large leaf nodes into a branch and multiple
leaves - but that's a *LOT* of hassle and since rather few models would
ever make use of it...and those models are already doomed to fairly poor
performance...I think we should just flag a nice error message and abort.

If someone passionately wants to write all the needed code to split objects
into multiple leaf nodes then we should certainly accept it...but I wouldn't
be very excited about writing it myself.

-- 
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
                         http://freeglut.sourceforge.net

Re: [Plib-users] Bug report

[Per L. <li...@ho...>]

On Friday 30 March 2001 11:48, Fredrik Sandstr=F6m wrote:
> Here comes a bunch of bugs that I've found when using PLib on Win9x
> platform. I use a PLib version from the cvs approx. a month ago, so if
> some of them already has been fixed I appologize.

Hi Fredrik!
Nice to see more and more swedes using plib! (I think there's at least th=
ree=20
of us here now.)

> * The 3ds-loader (and maybe other loaders as well?) crashes if the mode=
l
> file isn't found since it tries to do a fseek on an invalid file handle.

I think I fixed this a while ago...looks like it should work, and a quick=
=20
test shows it appears to work too.

> * The 3ds-loader also have problems with large models. It can load them
> ok, but when ypu try to manipulate them PLib will crash. This is becaus=
e
> the loader creates VtxTables with too many vertices in them. The getVer=
tex
> function can only handle shorts but the number of vertices variable is =
an
> int, making it possible to load more vertices than some of PLib's other
> functions can handle.

Interesting and annoying. Should we just refuse to load too large models?

> * In ssgLoad3ds the current_branch is never deleted after the parsing o=
f
> the file is finished.

I don't think it should be deleted. It's just a pointer to a node, and th=
at=20
node is a part of the model that is loaded, and thus should not be delete=
d.=20
But I could be missing some fine details of my own code. Feel free to com=
ment=20
further if you have any examples of when current_branch causes leaks.

Regards,
Per

--=20
   / Per Liedman
  / li...@ho...
 / www.mdstud.chalmers.se/~md6pl
/ 031-825659 / 0705-520455

[Plib-users] Bug report

[<dva...@cs...>]

Here comes a bunch of bugs that I've found when using PLib on Win9x
platform. I use a PLib version from the cvs approx. a month ago, so if
some of them already has been fixed I appologize.

* ssgaShape. Crashes after regeneration if kidStates has been set. The
removeAllKids deletes all references to the ssgState but the pointer is
still used after that. Works as long as the state is ref:ed before used in
the Shape but I don't believe that's the way it's supposed to work.

* ssgLOS doesn't work. It uses some code that are specific to the HOT case
(i.e. assume that the ray always points along the Z axis).

* sgQuat is broken. The conversion between other rotational types are NOT
done correctly. Conversions like quat -> matrix -> quat etc results in
axes switching and radians/degrees conversion errors.

* The 3ds-loader (and maybe other loaders as well?) crashes if the model
file isn't found since it tries to do a fseek on an invalid file handle.

* The 3ds-loader also have problems with large models. It can load them
ok, but when ypu try to manipulate them PLib will crash. This is because
the loader creates VtxTables with too many vertices in them. The getVertex
function can only handle shorts but the number of vertices variable is an
int, making it possible to load more vertices than some of PLib's other
functions can handle.

I've also found some mem leaks that shouldn't be a problem on a platform
with good memory handling, but since I'm stuck with Windows... Some of
these leaks are things that could (should?) be handled by a ssgExit
function.

* _ssgModelPath/_ssgTexturePath are never deallocated.

* _ssgCurrentContext is never deallocated.

* In ssgLoad3ds the current_branch is never deleted after the parsing of
the file is finished.

CU.

/Fredde

Magic is Life - Technology is Death

Re: [Plib-users] Build fails because glu.h is missing

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

> James Gallagher wrote:
>> I'm trying to build plib (1.2 or 1.3.1) and the build fails when it
>> needs glu.h. I have libGL and its headers (in /usr/X11R6/include/GL but
>> there's no glu.h in there. LibGL is version 1.2. Any help would be
>> appreciated.

Guy BARBIER wrote:
> I had the same problem two weeks ago! I installed the most recent
> version 1.4? and it worked fine.

(there is no PLIB version 1.4...yet)

Well, you should have GLU installed in the correct place whether
PLIB uses it or not.  Nearly all OpenGL and/or PLIB applications
need it - so you'll need to have it in the right place sooner or
later.

-- 
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
                         http://freeglut.sourceforge.net

Re: [Plib-users] Build fails because glu.h is missing

[Guy B. <gba...@ct...>]

Hi,
I had the same problem two weeks ago! I installed the most recent 
version 1.4? and it worked fine.
Good luck
Guy BArbier

James Gallagher wrote:

> Hi,
> 
> I'm trying to build plib (1.2 or 1.3.1) and the build fails when it
> needs glu.h. I have libGL and its headers (in /usr/X11R6/include/GL but
> there's no glu.h in there. LibGL is version 1.2. Any help would be
> appreciated.
> 
> Thanks
> James Gallagher
> 
> _______________________________________________
> plib-users mailing list
> pli...@li...
> http://lists.sourceforge.net/lists/listinfo/plib-users
> 
> 
> 

Re: [Plib-users] Open/Save AS Dialog

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

> I'm currently starting a project with OpenGL and I'm looking for a UI
> system.  The one crucial component that I need is an 'open as /save as'
> dialog.  From what I've read, PUI only does simple dialogs, like yes/no
> dialogs.  Is this the case?

PUI http://plib.sourceforge.net/pui/index.html is the interface system in
PLIB.  if you look at plib's viewer example in examples/src/ssg/viewer,
you'll see it has an open dialog.  i think you could build a save_as dialog
using PUI without too much trouble.  PUI is very simple but fits in well
with the GLUT callbacks.

> And if it doesn't, can anybody point me to a package that does provide
this
> widget?
>
> Or is there an existing solution already with GLUT?

GLUT includes MUI but you shouldn't use that.
http://web2.airmail.net/sjbaker1/mui_pui_glui.html  Instead, if you need
something more powerful than PUI, use GLUI
http://www.cs.unc.edu/~rademach/glui/.

There are other OpenGL based interface toolkits, but PUI and GLUI are good
bets.  PPE uses FLTK http://www.fltk.org/ and GLOW
http://glow.sourceforge.net/ looks interesting but I don't know much about
it.

Good luck,
--Dave McClurg

[Plib-users] Open/Save AS Dialog

[David G. <bea...@ho...>]

Hi,

I'm currently starting a project with OpenGL and I'm looking for a UI 
system.  The one crucial component that I need is an 'open as /save as' 
dialog.  From what I've read, PUI only does simple dialogs, like yes/no 
dialogs.  Is this the case?

And if it doesn't, can anybody point me to a package that does provide this 
widget?

Or is there an existing solution already with GLUT?

Thanks
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: [Plib-users] Build fails because glu.h is missing

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

James Gallagher wrote:
> 
> Hi,
> 
> I'm trying to build plib (1.2 or 1.3.1) and the build fails when it
> needs glu.h. I have libGL and its headers (in /usr/X11R6/include/GL but
> there's no glu.h in there. LibGL is version 1.2. Any help would be
> appreciated.

libGL is supposed to be in /usr/lib and gl.h and glu.h are supposed to
be in /usr/include/GL

If you got your OpenGL from nVidia, they don't ship a copy of GLU - if
you are using Mesa then you should have gotten a copy from them.

Fortunately, the Mesa GLU works fine with the nVidia drivers - so you
can go to www.mesa3d.org and snag a copy of Mesa to extract the libGLU
and glu.h files.

Mesa used to build libMesaGLU and GL/glu.h

-- 
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
                         http://freeglut.sourceforge.net

[Plib-users] Build fails because glu.h is missing

[James G. <ji...@dc...>]

Hi,

I'm trying to build plib (1.2 or 1.3.1) and the build fails when it
needs glu.h. I have libGL and its headers (in /usr/X11R6/include/GL but
there's no glu.h in there. LibGL is version 1.2. Any help would be
appreciated.

Thanks
James Gallagher

RE: [Plib-users] fullscreen mode?

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

Mark Blythe writes:

> Does PLIB have fullscreen OpenGL support?  
>Are there any example programs that use it?

Hmm FlightGear runs in fullscreen mode just fine :-)

all you have to do is request fullscreen mode from GLUT

This should get you a fullscreen window that matches the
current display settings on Win32

int FullScreenGlutInitWin32( int *argc, char **argv ) 
{
    glutInitDisplayMode( GLUT_RGB | GLUT_DEPTH | GLUT_DOUBLE );

#ifndef ENUM_CURRENT_SETTINGS
#define ENUM_CURRENT_SETTINGS       ((DWORD)-1)
#define ENUM_REGISTRY_SETTINGS      ((DWORD)-2)
#endif

    DEVMODE dm;
    dm.dmSize = sizeof(DEVMODE);
    EnumDisplaySettings(NULL, ENUM_CURRENT_SETTINGS, &dm);

    sprintf( game_mode_str, "%dx%d:%d@%d",
		 dm.dmPelsWidth,
		 dm.dmPelsHeight,
		 dm.dmBitsPerPel,
		 dm.dmDisplayFrequency );
	
    glutGameModeString( game_mode_str );
    glutEnterGameMode();
}

Re: [Plib-users] fullscreen mode?

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

Mark Blythe wrote:
> 
> Hi,
> 
> I've just started investigating PLIB, and I like what I've seen so
> far.  However, I have not yet seen a program using PLIB that will run in
> fullscreen mode, as opposed to in a window.  The Tux Herring game had an
> option to switch to fullscreen mode, but it didn't do anything on any of
> my machines.
> 
> Can it be done?  Does PLIB have fullscreen OpenGL support?  Are there any
> example programs that use it?

Fullscreen/not-Fullscreen isn't a function of either OpenGL or PLIB - it
only depends on the library you use for opening windows (which in the case
of TuxAQFH is 'GLUT').  So, if the library you use for creating and managing
windows has a 'full screen' command then use it and PLIB will be happy.

The only reason there was a special command in TuxAQFH is because it was
written back when the only hardware accellerated OpenGL for Linux used
the god-awful Voodoo-1/2 cards which could only do full-screen.

If you are using GLUT, there is an explicit full-screen command you can use.


-- 
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
                         http://freeglut.sourceforge.net

[Plib-users] fullscreen mode?

[Mark B. <ma...@cv...>]

Hi,

I've just started investigating PLIB, and I like what I've seen so
far.  However, I have not yet seen a program using PLIB that will run in
fullscreen mode, as opposed to in a window.  The Tux Herring game had an
option to switch to fullscreen mode, but it didn't do anything on any of
my machines.

Can it be done?  Does PLIB have fullscreen OpenGL support?  Are there any
example programs that use it?

Thanks,

Mark Blythe
ma...@cv...

Re: [Plib-users] A bit off-topic: Mem. utilization

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

Hi,

Wolfram Kuss wrote:
> 
> <ha...@sl...> wrote:
> 
> >I'm sure this is a frequently asked question, but the glutCreateWindow()
> >function takes my process memory utilization from 1.2mb to 162mb.
> 
> Its funny you bring this up now; The day before yesterday we started a
> discussion about this on PPE devel, please look into the archives.
> Unfortunately, all of us are fairly confused.

On my machine (128MB RAM, tnt2pro/32MB, Xfree4.0.1,Nvidia
GL-drivers0.95) I have the effect, that the X-server process takes up
about 256MB of RAM, and applications that use GL are shown up with about
200MB of RAM (as shown with qps)

I think it's the GL-driver, maybe it let's see the applications all
possible AGP-memory or whatever?

I've looked more closely with qps at the memory maps of the GL process.
/dev/nvidia0 is listed three times with 64MB memory usage and once with
1MB memory usage....?

The X-server takes up 3x64MB (on /dev/nvidia0) and 32MB on /dev/mem

All other apps (and X-apps) that don't use GL have a 'normal' memory
size.


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

[Plib-users] Texturing a triangle

[D L. <ea...@no...>]

Hi all,

I'm having trouble applying a texture to a triangle.  All I get is an
overall colour that looks like it might be the averaged texture
colour.  I'm sure I'm doing something very simple wrong but I just
can't see it.

The code snippet is here - I just added it to the tux example code.

ssgTexture *texture = new ssgTexture("wood.rgb");
ssgSimpleState *state = new ssgSimpleState;
state->setTexture(texture);

    state->enable( GL_TEXTURE_2D );

      // Allocate ssg structure
    ssgVertexArray   *vl = new ssgVertexArray( 3 );
    ssgNormalArray   *nl = new ssgNormalArray( 3 );
    ssgTexCoordArray *tl = new ssgTexCoordArray( 3 );
    ssgColourArray   *cl = new ssgColourArray( 3 );

    sgVec4 color;
    sgSetVec4( color, 1.0, 0.0, 0.0, 1.0 );
    cl->add( color );
    cl->add( color );
    cl->add( color );


    sgVec3 tmpvec;
    sgSetVec3( tmpvec, -50.0, -10.0, 0.0 );
    vl->add( tmpvec );
    sgSetVec3( tmpvec, 50.0, -10.0, 0.0 );
    vl->add( tmpvec );
    sgSetVec3( tmpvec, 0.0, 50.0, 0.0 );
    vl->add( tmpvec );

    // Add normals
    sgSetVec3( tmpvec, 0.0, 0.0, 1.0 );
    nl->add(tmpvec);
    nl->add(tmpvec);
    nl->add(tmpvec);

   // Add texture coordinates
    sgVec2 texvec;
    sgSetVec2(texvec,0.0,0.0);
    sgSetVec2(texvec,1.0,0.0);
    sgSetVec2(texvec,0.5,1.0);
    tl->add(texvec);
    tl->add(texvec);
    tl->add(texvec);

  ssgLeaf *leaf = new ssgVtxTable ( GL_TRIANGLES, vl, nl, tl, NULL );
  leaf->setState(state);

  penguin  -> addKid ( tux_obj  ) ;
  pedestal -> addKid ( leaf  ) ;


I just can't see what I'm missing / doing wrong :-(

Cheers - Dave

--
David Luff
Engines Research Group
University of Nottingham
0115-9513814
dav...@no...

Re: [Plib-users] Compiling with glib-2.2.2 and gcc 2.95.2

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

Norman wrote:

>  Can't we just automatically include <float.h>  I believe it is ANSII

I agree. It is listed in Bjarne Stroustrup. Someone (David Findlay?)
on the fgfs list had the same problem.

>  Norman

Bye bye,
Wolfram.

RE: [Plib-users] Compiling with glib-2.2.2 and gcc 2.95.2

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

Ben Woodhead  writes: 

I have been having no luck since I installed slackware current. 

  ../../src/sg/sg.h:847: `FLT_MAX' undeclared (first use this function)
  ../../src/sg/sg.h:847: (Each undeclared identifier is reported only once
  ../../src/sg/sg.h:847: for each function it appears in.)
  ../../src/sg/sg.h: In method `void sgdBox::empty()':
  ../../src/sg/sg.h:2023: `DBL_MAX' undeclared (first use this function) 

  Hmm what happens if you  
  #include  <float.h>

  This is special caased in src/util/ul.h for a bunch of systems
  but not slackware

  Can't we just automatically include <float.h>  I believe it is ANSII

  Norman