mesa3d-users

[Mesa3d-users] frame rate

[Arnfried G. <arn...@gm...>]

Hi,

I've written a simple routine to get the frame rate of the monitor. The
program is very simple, it uses a loop for calculating the time of 100
glXSwapBuffers(). On my SGI with OpenGL it works fine, but with MesaGL
it failed, because the swapping of the two buffers is not syncronized
with the vertical monitor sync.

My question is if anyone knows why glXSwapBuffers() doesn't wait for a
vertical sync or if this behavior is correct.

Arnfried

[Mesa3d-users] glBitmap + GL_ALPHA_TEST

[Dave M. <mo...@ni...>]

Should the enabledieness of GL_BLEND somehow mess with the drawing of
bitmaps through glBitmap?  If I have it on while bitmapping I only see the
bottom 60-80% of my bitmaps.

[Mesa3d-users] Makefile newbie problems

[delia <gis...@po...>]

I had the same problems too. To get it to work, I played with the makefile
in the Book directory, the code there are for the examples in the RedBook
and use GLUT. If you do not understand, slowly remove stuff from the file
little by little, don't forget to save, you will reach a point when you get
to understand the makefile

Aaron

Re: [Mesa3d-users] (no subject)

[Stephen J B. <sj...@ht...>]

On Mon, 8 May 2000, david besnard wrote:

> glide must use to have hardware acceleration with a voodoo 3?

Yes - Mesa uses GLIDE as a low level driver for all of the 3Dfx cards.

> if yes where i can download glide

http://www.3dfxgamers.com/drivers/voodoo3/voodoo3_linux.stm

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@ht...            http://www.hti.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

[Mesa3d-users] (no subject)

[david b. <sup...@ho...>]

glide must use to have hardware acceleration with a voodoo 3?
if yes where i can download glide
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

Fwd: [Mesa3d-users] Makefile newbie problems

[Brad B. <bra...@ho...>]

(sorry if this is posted twice :)

>From: "Brad Beveridge" <bra...@ho...>
>To: mes...@li...
>Subject: [Mesa3d-users] Makefile newbie problems
>Date: Mon, 08 May 2000 12:58:38 NZST
>
>Hi guys - I'm very new to Mesa programming, I've installed the latest Mesa
>release & the examples build & execute properly.  However I can't get my
>files to make properly (basically I just copied a sample file & played with
>the makefile a bit)  I run a Mandrake Linux system & here is the make file 
>I
>have
>
>test.o:
>	gcc -DSYSV -Dlinux -c test.c
>test: test.o test.c
>	gcc -o test test.c -lGL -lGLU -L/home/bbe13/libs/Mesa-3.2/src-glut -lglut
>-lm -L/usr/X11R6/lib -lXmu -lXext -lXi -lX11
>
>this compiles fine but when I run the executable nothing happens - I'm
>stumped.  Please someone, for the love of god help.
>
>Also - how can I tell it my TNT2 card is being utilized by Mesa?
>
>Cheers
>Brad
>_____________________________________________________________________
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

[Mesa3d-users] Makefile newbie problems

[Brad B. <bra...@ho...>]

Hi guys - I'm very new to Mesa programming, I've installed the latest Mesa 
release & the examples build & execute properly.  However I can't get my 
files to make properly (basically I just copied a sample file & played with 
the makefile a bit)  I run a Mandrake Linux system & here is the make file I 
have

test.o:
	gcc -DSYSV -Dlinux -c test.c
test: test.o test.c
	gcc -o test test.c -lGL -lGLU -L/home/bbe13/libs/Mesa-3.2/src-glut -lglut 
-lm -L/usr/X11R6/lib -lXmu -lXext -lXi -lX11

this compiles fine but when I run the executable nothing happens - I'm 
stumped.  Please someone, for the love of god help.

Also - how can I tell it my TNT2 card is being utilized by Mesa?

Cheers
Brad
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

Re: [Mesa3d-users] problem writing a mesa/X11 game

[Brian P. <br...@pr...>]

Dave Morse wrote:
> 
> Dave Morse writes:
>  > I'm experiencing some bad behavior in a game I'm writing.
>  >
>  > My problem is that if Mesa draws my scene faster than 30 Hertz then I
>  > never get any x events.  So as far as my client can tell, the mouse never
>  > moves again.
>  >
>  > All other applications recieve X events normally.
>  >
>  > If I comment out the Mesa drawing code, then I get X events normally.
>  >
>  > During the locked times, top reports that X is consuming 90% cpu time.
>  >
>  > My machines are K6/450 and PII/333 running software mesa 3.3 beta.
>  >
>  > Can someone explain why X is so studiously ignoring the event sending half
>  > of its job, in favor of the rendering half?
>  >
>  > Any ideas for a solution?
> 
> I should also mention that this is a second pass at implementing the
> game.  The first pass was single-player, no network code, its main loop
> looked like:
> 
> while (1) {
>   check_x_events();
>   update_game_state();
>   draw_window();
> }
> 
> The new version has a client and a server communicating through udp
> packets, and the client loop looks like:
> 
> while (1) {
>   select( ...X_Windows, UDP... ) /* block for any input */
>   if (FD_ISSET( X_Windows ))
>     {
>       check_x_events();
>       send_mouse_position_to_server();
>     }
>   if (FD_ISSET( UDP ));
>     {
>       read_game_state();
>       draw_window();
>     }
> }
> 
> The simpler prototype loop had no problems getting X events.


I have no idea what check_x_events() is doing, but I think that
should probably consume all pending events, not just one at a time.

-Brian

Re: [Mesa3d-users] using GLU with nvidia driver (Xfree 4.0)

[Bjorn L. <me...@le...>]

Today I finally figured out what doesn't work :

The problem is not the GLU libraries but the glut libraries (3.7).
Whever I use
double buffering I get a "segmentation fault" - even the red book demos
don't
work.
A part from this everything works fine (GLU included)

Unfortunaltely, the program doesn't leave a core on exit so I don't know
exactly
what happends.

If I replace the new NVidia driver (libGL.so) with the old Mesa3D libs,
glut
works fine.

Has anyone else had the same problem ?

Björn

[Mesa3d-users] RE: NVidia Drivers, XF86-40,

[Michael I G. <go...@nv...>]

Don't forget to enable blending.

    glEnable(GL_BLEND);
    glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

The roundness is in the alpha channel.  I'm guessing the smooth points you
see on other implementations are round-ish but still suffer from the
jaggies.  Enabling blending will fix that as well.  Its a quirk of our
implementation that we don't cull the zero-coverage fragments from the
bounding rect of the smooth point, but when blending is enabled it looks
correct.

 -- Michael

> -----Original Message-----
> From: Robert M. Wheat, Jr. [mailto:rm...@wo...]
> Sent: Friday, May 05, 2000 1:45 PM
> To: mes...@li...
> Cc: lin...@nv...
> Subject: NVidia Drivers, XF86-40, 
> 
> 
> Hello,
> 
> I have just recently installed the latest NVida drivers for 
> XFree86-4.0 (as
> well as WinNT4).
> I've noticed a small problem which may or may not be 'operator error'.
> When rendering a point with smoothing (anti-aliasing) 
> enabled, and the new
> NVidia libraries
> and drivers enabled, the only effect seen is a larger 
> (square) point. (See
> the following sample code.)
> 
>       glEnable(GL_POINT_SMOOTH);
>       glHint(GL_POINT_SMOOTH_HINT, GL_NICEST);
>       glPointSize(11.125);
>       glBegin(GL_POINTS);
>       glVertex3f(x, y, 0.0);
>       glEnd();
>       glDisable(GL_POINT_SMOOTH);
> 
> If I disable the new NVidia stuff by changing symbolic links 
> to point at
> the Mesa3D libs, the
> smooth point rendering works as expected (a round point).  
> I'm asking for a
> display config
> with RGBA (RGB), double bufferring, depth bufferring, and stencil
> bufferring (for other things).
> 
> Am I missing the boat on this?  What else would I need in my 
> display config?
> 
> By the way, I notice this problem under NT4.0 as well, but if 
> I replace the
> Opengl32.dll with
> the M$ version, all is well.
> 
> Thanx,
> 
> Robert M. Wheat, Jr.
> E-Mail: rm...@wo...
> 

[Mesa3d-users] problem writing a mesa/X11 game

[Dave M. <mo...@ni...>]

Dave Morse writes:
 > I'm experiencing some bad behavior in a game I'm writing.  
 > 
 > My problem is that if Mesa draws my scene faster than 30 Hertz then I
 > never get any x events.  So as far as my client can tell, the mouse never
 > moves again.
 > 
 > All other applications recieve X events normally.
 > 
 > If I comment out the Mesa drawing code, then I get X events normally.
 > 
 > During the locked times, top reports that X is consuming 90% cpu time.
 > 
 > My machines are K6/450 and PII/333 running software mesa 3.3 beta.
 > 
 > Can someone explain why X is so studiously ignoring the event sending half
 > of its job, in favor of the rendering half?
 > 
 > Any ideas for a solution?

I should also mention that this is a second pass at implementing the
game.  The first pass was single-player, no network code, its main loop
looked like:

while (1) {
  check_x_events();
  update_game_state();
  draw_window();
}

The new version has a client and a server communicating through udp
packets, and the client loop looks like:

while (1) {
  select( ...X_Windows, UDP... ) /* block for any input */
  if (FD_ISSET( X_Windows ))
    {
      check_x_events();
      send_mouse_position_to_server();
    }
  if (FD_ISSET( UDP ));
    {
      read_game_state();
      draw_window();
    }
}

The simpler prototype loop had no problems getting X events.  

Re: [Mesa3d-users] problem writing a mesa/X11 game

[Brian P. <br...@pr...>]

Dave Morse wrote:
> 
> I'm experiencing some bad behavior in a game I'm writing.
> 
> My problem is that if Mesa draws my scene faster than 30 Hertz then I
> never get any x events.  So as far as my client can tell, the mouse never
> moves again.
> 
> All other applications recieve X events normally.
> 
> If I comment out the Mesa drawing code, then I get X events normally.
> 
> During the locked times, top reports that X is consuming 90% cpu time.
> 
> My machines are K6/450 and PII/333 running software mesa 3.3 beta.
> 
> Can someone explain why X is so studiously ignoring the event sending half
> of its job, in favor of the rendering half?
> 
> Any ideas for a solution?

Sounds like a design bug in your event loop.  Can you post the code
for the event loop?  It can be tricky to get right.

-Brian

[Mesa3d-users] problem writing a mesa/X11 game

[Dave M. <mo...@ni...>]

I'm experiencing some bad behavior in a game I'm writing.  

My problem is that if Mesa draws my scene faster than 30 Hertz then I
never get any x events.  So as far as my client can tell, the mouse never
moves again.

All other applications recieve X events normally.

If I comment out the Mesa drawing code, then I get X events normally.

During the locked times, top reports that X is consuming 90% cpu time.

My machines are K6/450 and PII/333 running software mesa 3.3 beta.

Can someone explain why X is so studiously ignoring the event sending half
of its job, in favor of the rendering half?

Any ideas for a solution?

[Mesa3d-users] NVidia Drivers, XF86-40,

[Robert M. W. Jr. <rm...@wo...>]

Hello,

I have just recently installed the latest NVida drivers for XFree86-4.0 (as
well as WinNT4).
I've noticed a small problem which may or may not be 'operator error'.
When rendering a point with smoothing (anti-aliasing) enabled, and the new
NVidia libraries
and drivers enabled, the only effect seen is a larger (square) point. (See
the following sample code.)

      glEnable(GL_POINT_SMOOTH);
      glHint(GL_POINT_SMOOTH_HINT, GL_NICEST);
      glPointSize(11.125);
      glBegin(GL_POINTS);
      glVertex3f(x, y, 0.0);
      glEnd();
      glDisable(GL_POINT_SMOOTH);

If I disable the new NVidia stuff by changing symbolic links to point at
the Mesa3D libs, the
smooth point rendering works as expected (a round point).  I'm asking for a
display config
with RGBA (RGB), double bufferring, depth bufferring, and stencil
bufferring (for other things).

Am I missing the boat on this?  What else would I need in my display config?

By the way, I notice this problem under NT4.0 as well, but if I replace the
Opengl32.dll with
the M$ version, all is well.

Thanx,

Robert M. Wheat, Jr.
E-Mail: rm...@wo...

[Mesa3d-users] Mesa and OpenGL perl module

[Icebreaker <de...@lo...>]

Hello,

I'm currently having problems installing the OpenGL perl
module.  It uses the MesaGL set, of which I have as well
as MesaGLUT.

Everything was installed via rpm, and it had no complaints
when installing.  However, when I try to install the OpenGL
perl module, the makefile complains that it can't find the
libraries.  It is pointing to the correct dir /usr/X11R6/lib
I don't know why it isn't working.  I have searched for the
help info on the OpenGL perl mod, but all of the links are
too old, and there is no redirection to where ever the new
sites may be, if there are any.

Any ideas?

Icebreaker
-- 
If ignorance is bliss, then why 
aren't there more happy people?

Join the Rebellion:  Switch to Linux

Re: [Mesa3d-users] 256x256 texture size limitation

[Stephen J B. <sj...@ht...>]

On Thu, 4 May 2000, Robert [ISO-8859-1] Bäuml wrote:

> we're also using Mesa in our project Doom Legacy and recently came over a
> well known problem with 3dfx hardware: There is no support for textures
> above 256x256.

It's a hardware limitation of the 3Dfx card family.

> I know, OpenGL does not guarantee large texture sizes, but
> wouldn't it be a nice feature if there were a SW workaround for this HW limitation
> built into Mesa? 3dfx Voodoo cards are currently widespread and programmers
> wouldn't need to make special hacks for those cards to make it display
> properly.
 
Well, you have to ask what you'd have the software hack *do*.
I can only imagine three options:

1) Automatically drop the resolution when maps larger than 256x256
   are presented.  This is something that the application can
   (and should) do.  Use a proxy texture to discover if your map
   will fit - if it doesn't, throw away that MIPmap level and
   try again with the next one down.

2) Revert to software rendering for large maps (I don't think
   you'd like that - and it would certainly break existing
   programs that use mechanism (1) above).

3) Chop large textures up into 256x256 chunks and do an on-the-fly
   polygon split - applying different textures to different parts.
   I believe that this has been tried before on some Windoze 'mini-GL'
   driver from a company that OEM's the 3Dfx chipset. I forget who
   that was.

   This is probably the fix you are thinking of - but think for
   a moment about the implications:

    * When you split up a polygon, you'll sometimes create 'T' edges
      that'll cause cracking in the database. That sucks.

    * Sometimes, I might have a texture repeat across the polygon
      ten times in each direction.  If that's a 512x512 map, the
      splitting process will generate 800 triangles from that single
      input polygon!!

    * There is no way to avoid seams in your polygons where two
      sub-textures meet along a newly created edge.  You can't
      fix that problem.

    * Switching texture maps is a costly process (compared to
      drawing polygons at least) - whenever you split a polygon
      into four so that you can render it using four sub-maps,
      you get four additional texture map switches.

    * The cost to compute the split up polygons is non-trivial.

    * Bad things happen if you render in glPolygonModes other
      than FILL.

    * Colour shading across the split polygon (which is not
      perspective-correct in the 3Dfx hardware) will result
      in colour and lighting mis-matches along the border
      of polygons that have different texture resolutions.

    * In some multipass algorithms, the two passes may have
      different resolutions of texture map (eg Quake - which
      has really low-res lightmaps).  The change in roundoff
      error that would result from the splitting up of the
      higher resolution map but not the lower resolution
      version would certainly cause Z-fighting.

Note that the older 3Dfx cards have TINY amounts of texture
memory anyway - if you split large maps into tiny ones, you'll
be texture paging all the time.

So, I think that *by far* you are better off living with
the fuzzy maps and going with method (1) - have your
application automatically drop the higher resolution
maps on hardware that can't hack it.

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@ht...            http://www.hti.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

Re: [Mesa3d-users] 256x256 texture size limitation

[Brian P. <br...@pr...>]

Robert Bäuml wrote:
> 
> Hi,
> 
> we're also using Mesa in our project Doom Legacy and recently came over a
> well known problem with 3dfx hardware: There is no support for textures
> above 256x256. I know, OpenGL does not guarantee large texture sizes, but
> wouldn't it be a nice feature if there were a SW workaround for this HW limitation
> built into Mesa?

It would be slow and probably not worth the effort, IMHO.

-Brian

Re: [Mesa3d-users] using GLU with nvidia driver (Xfree 4.0)

[Stephen J B. <sj...@ht...>]

On Wed, 3 May 2000, Brian Paul wrote:

> Bjorn Leffler wrote:

> > Can anyone explain to me how to install the GLU library.
> > I just installed the nvidia drivers for Xfree 4.0 (libGL.so)
> > 
> > The libGL.so driver works great.

Yep - it certainly does. V.impressive.

> > My problem is that I can't use the GLU library anymore.
> > 
> > I think it's a linking problem :
> > 
> > OpenGL programs compile without errors,    (using "-lGL -lGLU  -lglut")
> > but I get a "Segmentation Fault" at execution
 
Well, it would be more usual to link them in the order:

    -lglut -lGLU -lGL -L/usr/X11R6/lib -lX11 -lXi -lXext -lXmu

...since glut uses both GLU and GL functions, GLU uses only GL functions, and
GL doesn't use either of the others.

But I'd have thought that if it got through the linker OK, you'd be
alright.  The linking process is getting so damned complicated these
days that I'd believe anything - so try relinking your program with
the libraries in that order.

> Can you pinpoint it with a debugger?
 
Or just run 'gdb' on the core file and type 'where' to get a stack
backtrace.
 
> > Can anyone tell me how to recompile GLU to match the provided libGL.so
> > file
> 
> That shouldn't be necessary.
 
It certainly wasn't necessary for me.  I installed the nVidia drivers
over the top of Mesa - and Mesa's GLU "just worked".

I didn't recompile it or anything...and I've not had any crashes at
all.  Having said that, I'm not a *heavy* user of GLU - so I may well
not be exercising the part that's giving you problems.

If you are desperate, you could try the GLU that comes with the
SGI reference implementation of OpenGL - but I don't think that
should be necessary - and it would be nice to track this one
down first.

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@ht...            http://www.hti.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

[Mesa3d-users] 256x256 texture size limitation

[Robert <Rob...@gm...>]

Hi,

we're also using Mesa in our project Doom Legacy and recently came over a
well known problem with 3dfx hardware: There is no support for textures
above 256x256. I know, OpenGL does not guarantee large texture sizes, but
wouldn't it be a nice feature if there were a SW workaround for this HW limitation
built into Mesa? 3dfx Voodoo cards are currently widespread and programmers
wouldn't need to make special hacks for those cards to make it display
properly.

Bye,

Rob

-- 
Sent through GMX FreeMail - http://www.gmx.net

Re: [Mesa3d-users] using GLU with nvidia driver (Xfree 4.0)

[Brian P. <br...@pr...>]

Bjorn Leffler wrote:
> 
> Hi,
> 
> Can anyone explain to me how to install the GLU library.
> I just installed the nvidia drivers for Xfree 4.0 (libGL.so)
> 
> The libGL.so driver works great.
> My problem is that I can't use the GLU library anymore.
> 
> I think it's a linking problem :
> 
> OpenGL programs compile without errors,    (using "-lGL -lGLU  -lglut")
> but I get a "Segmentation Fault" at execution

Can you pinpoint it with a debugger?


> Can anyone tell me how to recompile GLU to match the provided libGL.so
> file

That shouldn't be necessary.

-Brian

[Mesa3d-users] using GLU with nvidia driver (Xfree 4.0)

[Bjorn L. <me...@le...>]

Hi,

Can anyone explain to me how to install the GLU library.
I just installed the nvidia drivers for Xfree 4.0 (libGL.so)

The libGL.so driver works great.
My problem is that I can't use the GLU library anymore.

I think it's a linking problem :

OpenGL programs compile without errors,    (using "-lGL -lGLU  -lglut")
but I get a "Segmentation Fault" at execution

Can anyone tell me how to recompile GLU to match the provided libGL.so
file

Thanks a lot,

Bjorn Leffler

Re: [Mesa3d-users] [Newbie] can't get SVGA driver to work

[Brian P. <br...@pr...>]

Russ Mercer wrote:
> 
> Hello,
> 
> I am interested in developing a MesaGL application that works without the X Window System, so I am trying to get started with the SVGA drivers. I have compiled some of the applications in Mesa-3.2/xdemos that are supposed to work in SVGA mode, including vgears and vtest. However, when I run these programs on my system, the screen locks up with a checkerboard-like pattern that stays there until I restart the system remotely.
> 
> Obviously, the display is being permanently put into some kind of unusable mode by the MesaGL applications. Is there someplace I can configure the SVGA driver so that it works correctly on my system? In general, I don't understand how MesaGL handles different drivers. So far I have read the FAQ and the top-level documentation on www.mesa3d.org, but I have not seen any discussion of this topic. Is there anywhere else I can look to get information specifically about the SVGA drivers?
> 
> Thanks for any info or pointers,
> 

Slawomir Szczyrba <st...@ho...> contributed the updates to the SVGA
driver in Mesa 3.2.  He might be able to help you.

-Brian

[Mesa3d-users] "undefined reference" to all GL & glut funcs?

[M. N. <mnail@u.washington.edu>]

I just installed Mesa and GLUT on my RedHat Linux 6.0 box, and tried to
compile a program, but got an "undefined reference" error for each
function from the mesa and glut libraries I tried to call.  Any
advice? 

-- mnail@u.washington.edu --------------------- 
---- http://students.washington.edu/~mnail -----------

[Mesa3d-users] Mesa3.2 and DEBUG ..

[v0id <v0...@us...>]

Sorry for asking this, but i have a problem with turning OFF the
DEBUGING of Mesa3.2. 
when i use ./configure --disable-debug Mesa still compiles with "-g
-DDEBUG" ...grrrrrr
anyone knows what i do wrong ?

v0id
-- 
-------------------------------------------------
 "Life is too short to waste it with Windows..."
          http://www.business-linux.at 
 	       http://v0id.n3.net
-------------------------------------------------

Re: [Mesa3d-users] silly question :-)

[physic <ph...@te...>]

Thats a graphics toolkit think.  Its different depending on how you
are dislaying mesa.  Are you using SDL, X11, GL4Java, SVGALib, etc etc.
There it also depends on the video card.  Mesa used to have some hooks
to switch for fullscreen for the 3dfx cards.  Anyway, you'll have to
be more specific about what you want.

On Thu, 27 Apr 2000, Wolfram Wiesemann wrote:

> sorry to dizz you with this - for you maybe - silly question, but I need to know how to use Mesa in fullscreen mode. I haven't seen any example program dealing with this problem so I would be pleased if somebody could tell.
> thank you.
> _______________________________________________________________________
> 1.000.000 DM gewinnen - kostenlos tippen - http://millionenklick.web.de
> Ih...@we..., 8MB Speicher, Verschluesselung - http://freemail.web.de
> 
> 
> _______________________________________________
> Mesa3d-users mailing list
> Mes...@li...
> http://lists.sourceforge.net/mailman/listinfo/mesa3d-users
> 

--physic
ph...@te...