[Mesa-dev] demo wierdness?
I just updated my mesa cvs (after like a month of using an old one :) and im having a bunch of wierd errors. Ive built and configured with prefix=/usr/local . I installed and things seemed well. I then did a make check and it spat out the usual demos. This is where it gets wierd. When i try and run the demos as non root, i get: rarloa-4 [thebard] bash\>./drawpix /usr/bin/ld: cannot open output file /usr/local/cvs-gnome/Mesa/demos/.libs/12930-lt-drawpix: Permission denied collect2: ld returned 1 exit status Ok. so i look in /usr/local/cvs-gnome/Mesa/demos/.libs . There are a bunch of wierd executables that look like the demo executeables in there, but they are all diferent sizes than the demo executables in /demo. What are they? Also, if i run say ./drawpix as root, then try and run it as a normal user, it runs fine.. doesn't error. Another thing. I next installed cvs glx and everything went fine. quake3test runs using it. However, the demos do not. Obviously they are not using the new glx libGL. Do i need to recompile them all by hand or is there an automated way to do this? Also, this new cvs doesnt seem to configure shared libs in by default for me. I'm on a rh6 box, smp pent II's. I have to manually tell configure to build shared libs. Is that normal? Wayde [EMAIL PROTECTED] ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GL_EXT_multitexture
hes2 wrote: > > I am developing Mesa drivers for my own 3D accelerator based of an FPGA > board. Specifically I want to show Quake II as a demo for the hardware. > > I've written the multi-texturing hardware, and wish to interface to the > GL_EXT_multitexture extension. In my setup_DD_pointers what condition > should I test for ( stored in the GLcontext somewhere ? ) to see whether > multi-pass texturing is currently active, so I can reconfigure for a > multi-pass rasterizer. Multitexturing is fairly complex - there is a lot of state to examine to get it all right. Have you got the single-texture case working correctly yet? What version of Mesa are you building against? Probably the best advice is to look at the FX driver, and the tests in triangle.c of whatever version you are developing against. There you will find two fairly different approaches to multitexture. In summary, the ctx->Texture.ReallyEnabled variable is a good place to start, but you need to track a lot more than this to get everything looking right. Keith ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
[Mesa-dev] book/tess demo
Hooray! I got a nice, smoothly shaded star at around midnight last night with this demo. Just had to clean up my memory allocation (actually, do some deallocation...) and we now have support for self-intersecting polygons. The other demos require me to fix the island-inside-an-island case, which I know how to do, and will code up tonight. I'll spend some time making sure I'm deallocating all of my dynamic data, but a "final" commit should happen this week. -- Gareth == Gareth Hughesmailto:[EMAIL PROTECTED] DEFINITY® Site Administration Project Lucent Technologies, Bell Labs Australia ph: +61 2 9352 8608 ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] autoconf stuff
On 21-Sep-99 [EMAIL PROTECTED] wrote: >> I don't know the reasoning of the original libtool author. >> Maybe he wanted to keep the directory "clean". >> .libs contains libtool-specific data that must not be modified. > And it contains the resulting library also and THAT's what I don't > understand. (All the object files and symlinks are in the src > directory... sot it's not that "clean") The filename(s) of the library is system-dependent (e.g. libGL.so.3.1.3, libGL.sl.3 ...) but the object files (.o and .lo) are not. The src directory contains only the files that are known to the make rules (.o, .lo, .la). There's no doubt that libtool-specific must be stored in a subdirectory but the question is why it should be hidden. I'll ask the original libtool maintainer. Thomas Tanner - email: tanner@(ffii.org|gnu.org|gmx.de) web: http://home.pages.de/~tanner GGI/Picasso: http://picasso.ffii.org ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
[Mesa-dev] GL_EXT_multitexture
I am developing Mesa drivers for my own 3D accelerator based of an FPGA board. Specifically I want to show Quake II as a demo for the hardware. I've written the multi-texturing hardware, and wish to interface to the GL_EXT_multitexture extension. In my setup_DD_pointers what condition should I test for ( stored in the GLcontext somewhere ? ) to see whether multi-pass texturing is currently active, so I can reconfigure for a multi-pass rasterizer. ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa Perspective Texture mapping
>Jeff: What is the exact heritage of the TNT and G400 drivers you are using - are >they recent cvs, or an older snapshot from somewhere? My G400 is a CVS snapshot from about 8/27/1999 (from http://glx.on.openprojects.net/) the TNT is binaries from the NVidia site, and they are from around the middle of August. I will get the latest of both and test them. The G400 is suffering from more texture issues than just the perspective problem. It appears to be not going into some states that I set (understood since it is still in it's infancy). For instance, it seems like my lightmaps are not blending with the textures beneath but instead are just rendering over them. If anyone needs anymore from me, such as a Descent 3 Linux client beta I can get that to you. Thanks for all the help, -Jeff ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa Perspective Texture mapping
Stephen J Baker wrote: > > Someone has to look into the inner workings of glTexCoord4f and find > the bug. Stephen, My guess is it's basically a driver issue as the test program which works ok for the X and FX drivers failed for him under G400 and TNT. The g200 code is a work in progress and currently silently ignores the 4th texcoord. This is easy to fix for the single texture (g200) case, but I don't think matrox has given us enough info to correctly do multi-projective-textures. Currently the G400 is only used as a single-texture engine, anyway, so this isn't critical yet. Jeff: What is the exact heritage of the TNT and G400 drivers you are using - are they recent cvs, or an older snapshot from somewhere? I'll probably get around to fixing the G200/G400 single-projective-texture case by this weekend. If you're interested in poking around in the driver itself send me a mail & I'll direct you to the bit that needs surgery... Keith ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa Perspective Texture mapping
On Mon, 20 Sep 1999, Jeff Slutter wrote: > Thanks for the sample program, I compiled it in both my Linux and > Windows to compare them. In Linux (but not Windows) I get the same problem > as what is in Descent 3 with the perspective texture mapping once I hit the > '4' key to switch to use glTexCoord4f(). glTexCoord2f() works fine, > however. > > The Descent 3 code uses neither glTexCoord2f() or glTexCoord4f(), it > uses glTexCoordPointer(), so I suspect these drivers are having some problem > with that also. In the code snipped below, it's using glTexCoordPointer to send four-component texture coordinates - so it's in the 4-component texture coord code. > glEnableClientState (GL_VERTEX_ARRAY); > glEnableClientState (GL_COLOR_ARRAY); > glEnableClientState (GL_TEXTURE_COORD_ARRAY); > > glVertexPointer (3,GL_FLOAT,0,GL_verts); > glColorPointer (4,GL_FLOAT,0,GL_colors); > glTexCoordPointer (4,GL_FLOAT,0,GL_tex_coords); > > So do you think (I'm sorry, but I'm quite new to OpenGL, as I have > inherited all of D3's rendering systems since our graphics programmer left > Outrage) if I convert to use glTexCoord2f() I might get some good results? Well, I presume the real code is using four-component texture coordinates because it's doing its own perspective divide. Under those circumstances, you *can't* use a two component texture. Someone has to look into the inner workings of glTexCoord4f and find the bug. Steve Baker(817)619-2657 (Vox/Vox-Mail) Raytheon Systems Inc. (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.hti.com Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1 ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa Perspective Texture mapping
Jeff Slutter wrote: > > > If I understood correctly, you are using OpenGL as a "2D painting > > engine" feeding it polygons which you have already translated to > > screen coordinates. > > That is correct. > > > In this case you have to use the more complex TexCoord4 interface. > > (Or possibly use Vertex4 interface for w information) > > I realized this shortly after my previous email. Is it possible to get away > without using the TexCoord4 interface and use the Vertex4 interface? > I have never tried this myself, but look at: http://www.berkelium.com/OpenGL/examples/ (especially rasonly2.c) Eero ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
