+++ /dev/null
-
- 3Dfx Glide device driver
-
-
-
-Requirements:
--------------
-
-A Voodoo-based videocard/accelerator
-DOS (with DJGPP), Windows9x/2k (with MinGW), Linux
-Glide3x library for your OS
-
-http://sourceforge.net/projects/glide/
-
-
-
-How to compile:
----------------
-
-DJGPP:
- Place the Glide3 SDK in the top Mesa directory:
- $(MESA)/glide3/include/
- 3dfx.h, g3ext.h, glide.h, glidesys.h, glideutl.h, sst1vid.h
- $(MESA)/glide3/lib/
- libgld3x.a, libgld3i.a, glide3x.dxe
- Type:
- make -f Makefile.DJ X86=1 FX=1
- Look into the makefile for further information.
-
-MinGW:
- Place the Glide3 SDK in the top Mesa directory:
- $(MESA)/glide3/include/
- 3dfx.h, g3ext.h, glide.h, glidesys.h, glideutl.h, sst1vid.h
- $(MESA)/glide3/lib/
- libglide3x.a, glide3x.dll
- Type:
- make -f Makefile.mgw X86=1 FX=1
- Look into the makefile for further information.
-
-Linux:
- Place the Glide3 SDK in /usr/local/glide
- /usr/local/glide/include/
- 3dfx.h, g3ext.h, glide.h, glidesys.h, glideutl.h, sst1vid.h
- /usr/local/glide/lib/
- libglide3x.a, libglide3x.so
- Type:
- make linux-glide
- or
- make linux-x86-glide
-
-
-
-Compilation defines:
---------------------
-
-FX_DEBUG
- enable driver debug code
-FX_TRAP_GLIDE
- enable Glide trace code
-FX_PACKEDCOLOR
- use packed color in vertex structure
-FX_TC_NAPALM
- map GL_COMPRESSED_RGB[A] to FXT1. Works with VSA100-based cards only.
-FX_COMPRESS_S3TC_AS_FXT1_HACK
- map S3TC to FXT1
-FX_RESCALE_BIG_TEXURES_HACK
- fake textures larger than HW can support
- (see MESA_FX_MAXLOD environment variable)
-
-
-
-Environment variables:
-----------------------
-
-The following environment variables affect MesaFX. Those that affect Glide
-only, are beyond the scope of this section. Entries that don't have a "Value"
-field, can have any value whatsoever
- ex: set MESA_FX_IGNORE_CMBEXT=y
-
-"Note" (*) means that the environment variable affects Glide, too; also, if
-the var is not found in the environment, it is searched in windoze registry.
-"Note" (!) means that the environment variable is not working as expected;
-may have undefined effects, might have effects only at Glide level or might
-not have any effect whatsoever. Caveat emptor! Those are to be revised soon.
-
-It is recommended to leave the envvars alone, so that Mesa/Glide will run with
-default values. Use them only when you experience crashes or strange behavior.
-
-FX_GLIDE_NUM_TMU
- OS: all
- HW: dual-TMU cards (Voodoo2, Avenger, Napalm)
- Desc: force single-TMU
- Note: (*)
- Value: "1"
-FX_GLIDE_SWAPPENDINGCOUNT
- OS: all
- HW: all
- Desc: max # of buffers allowed to build up
- Note: (*) (!)
- Value: "0", "1", "2", "3", "4", "5" or "6"
-FX_GLIDE_SWAPINTERVAL
- OS: all
- HW: all
- Desc: number of vertical retraces to wait before swapping
- Note: (*) (!) works only at Glide-level?
-SSTH3_SLI_AA_CONFIGURATION
- OS: all
- HW: VSA100-based cards
- Desc: SLI/AA setup
- Note: (*) (!) works only at Glide-level?
- Value:
- 1, 2, 4 chip cards
- "0" - SLI & AA disable
- "1" - SLI disabled, 2 sample AA enabled
- 2, 4 chip cards
- "2" - 2-way SLI enabled, AA disabled
- "3" - 2-way SLI enabled, 2 sample AA enabled
- "4" - SLI disabled, 4 sample AA enabled
- 4 chip cards
- "5" - 4-way SLI enabled, AA disabled
- "6" - 4-way SLI enabled, 2 sample AA enabled
- "7" - 2-way SLI enabled, 4 sample AA enabled
- "8" - SLI disabled, 8 sample AA enabled
-SST_DUALHEAD
- OS: win32
- HW: ?
- Desc: ?
- Note: (!) disabled?
-MESA_FX_NO_SIGNALS
- OS: linux
- HW: all
- Desc: avoid installing signals
- Note: (!) untested!
-MESA_FX_INFO
- OS: all
- HW: all
- Desc: verbose to stderr
- Value: any; special value "r" to redirect stderr to MESA.LOG
-MESA_FX_NOSNAP
- OS: all
- HW: Voodoo1, Rush, Banshee
- Desc: do not snap vertices inside Mesa
- Note: to be used with Glide3x that snaps vertices internally
-MESA_FX_POINTCAST
- OS: all
- HW: dual-TMU cards (some Voodoo1, Voodoo2, Avenger, Napalm)
- Desc: try to use pointcast palette
- Note: may give adverse effects on UMA cards (Avenger, Napalm)
-MESA_FX_IGNORE_PALEXT
- OS: all
- HW: all
- Desc: disable 6666 palette
-MESA_FX_IGNORE_PIXEXT
- OS: all
- HW: Napalm
- Desc: force 565 16bpp mode (traditional Voodoo, no 32/15bpp)
-MESA_FX_IGNORE_TEXFMT
- OS: all
- HW: Napalm
- Desc: disable 32bit textures
-MESA_FX_IGNORE_CMBEXT
- OS: all
- HW: Napalm
- Desc: disable Napalm combiners (color/alpha/texture)
- Note: this option allows dual-TMU cards perform single-pass
- trilinear, but some advanced (multi)texturing modes
- won't work (GL_EXT_texture_env_combine)
-MESA_FX_IGNORE_MIREXT
- OS: all
- HW: all
- Desc: disable mirror extension
-MESA_FX_IGNORE_TEXUMA
- OS: all
- HW: all
- Desc: disable UMA
-MESA_FX_IGNORE_TEXUS2
- OS: all
- HW: all
- Desc: disable Texus2
-MESA_FX_MAXLOD
- OS: all
- HW: non VSA-100 cards
- Desc: enable large texture support using SW rescaling
- Value:
- "9" - 512x512 textures
- "10" - 1024x1024 textures
- "11" - 2048x2048 textures
-MESA_FX_ALLOW_VP
- OS: all
- HW: all
- Desc: allow vertex program extensions
-MESA_GLX_FX
- OS: linux
- HW: Voodoo1, Rush, Voodoo2
- Desc: display mode
- Note: (!) experimental
- Value:
- "w" - windowed mode
- "f" - fullscreen mode
- "d" - disable glide driver
- OS: win32
- HW: Rush, Banshee, Avenger, Napalm
- Desc: display mode
- Note: (!) experimental
- Value:
- "w" - windowed mode
-
-
-
-Contact:
---------
-
-Daniel Borca <dborca 'at' users 'dot' sourceforge 'dot' net>
-Hiroshi Morii <koolsmoky 'at' users 'dot' sourceforge 'dot' net>
-
-
-
-WARNING! The info below this line is outdated (yet some of it useful). WARNING!
-*******************************************************************************
-
-
-
-Info for Mesa 4.1
------------------
-
-The 3dfx Glide driver in Mesa is disabled by default. Not too many people
-use this driver anymore and at some point down the road it will be dropped.
-
-To use/enable the Glide driver either do this:
-
-'./configure --with-glide=DIR' Where DIR is the location of Glide, like
- /usr/ or /usr/local
-
-OR
-
-'make linux-x86-glide' If using the old-style Makefile system.
-
-The rest of this file hasn't changed since Mesa 3.3. Some of it's out of
-date, but some is still valid.
-
-
-
-What do you need ?
-------------------
-
- - A PC with a 3Dfx Voodoo1/2 Graphics or Voodoo Rush based board
- (Pure3D, Monster 3D, R3D, Obsidian, Stingray 128/3D, etc.).
- The Quantum3D Obsidian3D-2 X-24 requires some special env. setting
- under Linux (more information in the "Useful Glide Environment
- Variables");
-
- - The 3Dfx Glide library 2.3 or later for your OS (the 2.4 works fine).
- The Voodoo2 requires the Glide library 2.51. The Glide 3.1 is not
- compatible with the Glide 2.x so it doesn't work with the current
- version of the driver;
-
- - A compiler supported by the Glide library (Micro$oft VC++ (tested),
- Watcom (tested), GCC for Linux (tested), etc.);
-
- - It's nice to have two monitors - one for your normal graphics
- card and one for your 3Dfx card. If something goes wrong with
- an application using the 3Dfx hardware you can still see your
- normal screen in order to recover.
-
-
-
-Tested on:
-----------
- Windows 95 - David Bucciarelli
- Windows NT - Henri Fousse
- MS-DOS
- Linux - Daryll Strauss, Brian Paul, David Bucciarelli
- FreeBSD
- BeOS - Duncan Wilcox
- MacOS - Fazekas Miklos
-
-
-What is able to do ?
---------------------
-
- - It is able accelerate points, lines and polygon with flat
- shading, gouraud shading, Z-buffer, texture mapping, blending, fog and
- antialiasing (when possible). There is also the support for rendering
- in a window with a slow trick for the Voodoo Graphics (available only
- for Linux) and at full speed with the Voodoo Rush chipset.
- Under Linux is also possible to switch on-the-fly between the fullscreen
- and in-window rendering hack.
- There is also the support for using more than one Voodoo Graphics in the
- some application/PC (you can create one context for each board and use
- multiple video outputs for driving monitors, videoprojectors or HMDs).
- The driver is able to fallback to pure software rendering when afeature
- isn't supported by the Voodoo hardware (however software rendering is
- very slow compared to hardware supported rendering)
-
-
-
-How to compile:
----------------
-
-Linux:
-------
- Here are the basic steps for using the 3Dfx hardware with Mesa
- on Linux:
-
- - You'll need the Glide library and headers. Mesa expects:
- /usr/local/glide/include/*.h // all the Glide headers
- /usr/local/glide/lib/libglide2x.so
-
- If your Glide libraries and headers are in a different directory
- you'll have to modify the Mesa-config and mklib.glide files.
-
- - Unpack the MesaLib-3.1.tar.gz and MesaDemos-3.1.tar.gz archives;
-
- - If you're going to use a newer Mesa/Glide driver than v0.27 then
- unpack the new driver archive over the Mesa directory.
-
- - In the Mesa-3.1 directory type "make linux-glide"
-
- - Compilation _should_ finish without errors;
-
- - Set your LD_LIBRARY_PATH environment variable so that the
- libglide2x.so and Mesa library files can be found. For example:
- setenv LD_LIBRARY_PATH "/usr/local/glide/lib:/SOMEDIR/Mesa-3.1/lib"
-
- - You'll have to run Glide-based programs as root or set the suid
- bit on executables;
-
- - Try a demo:
- cd gdemos
- su
- setenv MESA_GLX_FX f
- ./gears (hit ESC to exit)
-
- - You can find the demos especially designed for the Voodoo driver in
- in the Mesa-3.1/3Dfx/demos directory (type "make" in order to compile
- everything).
-
-MacOS:
-------
- Check the WEB page at http://valerie.inf.elte.hu/~boga/Mesa.html
-
-MS Windows:
------------
-
- For the MSVC++:
- - The glide2x.lib have to be in the default MSVC++ lib directory;
-
- - The Glide headers have to be in the default MSVC++ include directory;
-
- - You must have the vcvars32.bat script in your PATH;
-
- - Go to the directory Mesa-3.1 and run the mesafx.bat;
-
- - The script will compile everything (Mesa-3.1/lib/OpenGL32.{lib,dll},
- Mesa-3.1/lib/GLU32.{lib,dll}, Mesa-3.1/lib/GLUT32.{lib,dll} and
- Voodoo demos);
-
- - At the end, you will be in the Mesa-3.1/3Dfx/demos directory;
-
- - Try some demo (fire.exe, teapot.exe, etc.) in order to check if
- everything is OK (you can use Alt-Tab or Ctrl-F9 to switch between
- the Voodoo screen and the windows desktop);
-
- - Remember to copy the Mesa OpenGL32.dll, GLU32.dll and GLUT32.dll in the
- some directory were you run your Mesa based applications.
-
- - I think that you can easy change the Makefile.fx files in order
- to work with other kind of compilers;
-
- - To discover how open the 3Dfx screen, read the sources under
- the Mesa-3.1/3Dfx/demos directory. You can use the GLUT library or
- the Diego Picciani's wgl emulator.
-
- NOTE: the MSVC++ 5.0 optimizer is really buggy. Also if you install the
- SP3, you could have some problem (you can disable optimization in order
- solve these kind of problems).
-
-
-Doing more with Mesa & Linux Glide:
------------------------------------
-
- The MESA_GLX_FX environment variable can be used to coax most
- GLX-based programs into using Glide (and the __GLUT library
- is GLX-based__).
-
- Full-screen 3Dfx rendering:
- ---------------------------
-
- 1. Set the MESA_GLX_FX variable to "fullscreen":
-
- ksh:
- export MESA_GLX_FX = "fullscreen"
- csh:
- setenv MESA_GLX_FX fullscreen
-
- 2. As root, run a GLX-based program (any GLUT demo on Linux).
-
- 3. Be careful: once the 3Dfx screen appears you won't be able
- to see the GLUT windows on your X display. This can make using
- the mouse tricky! One solution is to hook up your 3Dfx card to
- a second monitor. If you can do this then set these env vars
- first:
-
- setenv SST_VGA_PASS 1
- setenv SST_NOSHUTDOWN
-
- or for the Voodoo2:
-
- setenv SSTV2_VGA_PASS 1
- setenv SSTV2_NOSHUTDOWN
-
- Rendering into an X window with the help of the Voodoo hardware:
- ----------------------------------------------------------------
-
- 1. Start your X server in 16 bpp mode (XFree86: startx -- -bpp 16)
- in order to have the best performance and the best visual
- quality. However you can use any visual depth supported by X.
-
- 2. Set the following environment variables:
- export MESA_GLX_FX="window" # to enable window rendering
- export SST_VGA_PASS=1 # to stop video signal switching
- export SST_NOSHUTDOWN=1 # to stop video signal switching
- OR
- setenv MESA_GLX_FX window
- setenv SST_VGA_PASS 1
- setenv SST_NOSHUTDOWN 1
-
- (the Voodoo2 requires to use "SSTV2_" instead "SST_").
-
- 3. As root, try running a GLX-based program
-
- How does it work? We use the 3Dfx hardware to do rendering then
- copy the image from the 3Dfx frame buffer into an X window when
- the SwapBuffers() function is called. The problem with this
- idea is it's slow. The image must be copied from the 3Dfx frame
- buffer to main memory then copied into the X window (and when the X
- visual depth doesn't match the Voodoo framebufffer bit per pixel, it
- is required also a pixel format translation).
-
- NOTE: the in-window rendering feature only works with double-buffering.
-
-
- On the fly switching between in window rendering and full screen rendering
- --------------------------------------------------------------------------
-
- The Mesa 2.6 has introduced the capability of switching
- on-the-fly between the fullscreen/fullspeed rendering and the in-window
- hack and vice versa. The on-the-fly switching requires a direct support
- by the application but it is really easy to add. You have to start
- your X server in 16 bpp mode and to add the following lines to your
- application:
-
- #if defined(FX) && define(XMESA)
- #include <GL/xmesa.h>
-
- static int fullscreen=1;
- #endif
-
- ...
-
- /* In the GLUT keyboard event callback */
-
- #if defined(FX) && !define(WIN32)
- case ' ':
- fullscreen=(!fullscreen);
- XMesaSetFXmode(fullscreen ? XMESA_FX_FULLSCREEN : XMESA_FX_WINDOW);
- break;
- #endif
- ...
-
- See the 3Dfx/demos/tunnel.c program
- for an example. You have to set the -DXMESA flag in the Makefile's COPTS
- to enable it.
-
- Rendering into an X window with the X11 software driver:
- --------------------------------------------------------
-
- Set the MESA_GLX_FX variable to "disable" your GLX-based program will use
- the X11 software driver (the 3Dfx hardware isn't used at all).
-
-
-
-Useful Glide Environment Variables:
------------------------------------
-
- - To disable the 3Dfx logo, set the FX_GLIDE_NO_SPLASH variable.
-
- - To disable video signal switching:
- setenv SST_VGA_PASS 1
- setenv SST_NOSHUTDOWN
- or for the Voodoo2:
- setenv SSTV2_VGA_PASS 1
- setenv SSTV2_NOSHUTDOWN
-
- - To set the default screen refresh rate:
- setenv SST_SCREENREFRESH=75
-
- the supported values are 60, 70, 72, 75, 80, 85, 90, 100, 120.
-
- - To force the Mesa library to swap buffers as fast as possible,
- without any vertical blanking synchronization (useful for benchmarks):
- setenv FX_GLIDE_SWAPINTERVAL 0
- setenv SST_SWAP_EN_WAIT_ON_VIDSYNC 0
-
- - You can slight improve the performances of your Voodoo1 board with
- the following env. var.:
- setenv SST_FASTMEM 1
- setenv SST_PCIRD 1
- setenv SST_GRXCLK 57
-
- (don't use this setting with the Quantum3D 100SB or with any other
- SLI configuration: it will hang everything !).
- The following setting can be used with the Voodoo2:
- setenv SSTV2_FASTMEM_RAS_READS=1
- setenv SSTV2_FASTPCIRD=1
- setenv SSTV2_GRXCLK=95
-
- - The Quantum3D Obsidian3D-2 X-24 requires some special env. setting
- in order to work under Linux:
-
- export SSTV2_FT_CLKDEL=5
- export SSTV2_TF0_CLKDEL=7
- export SSTV2_TF1_CLKDEL=7
- export SSTV2_TF2_CLKDEL=7
- export SSTV2_SLIM_VIN_CLKDEL=3
- export SSTV2_SLIM_VOUT_CLKDEL=2
- export SSTV2_SLIS_VIN_CLKDEL=3
- export SSTV2_SLIS_VOUT_CLKDEL=2
-
- (Thanks to Phil Ross for this trick).
-
-
-
-
-The Mesa/Voodoo Environment Variables:
---------------------------------------
-
- - Only for Windows/Voodoo Rush users, if you define the
- env. var. MESA_WGL_FX:
- export MESA_WGL_FX=fullscreen
- you will get fullscreen rendering;
-
- - Only for Windows/Voodoo Rush users, if you define the
- env. var. MESA_WGL_FX:
- export MESA_WGL_FX=window
- you will get window rendering (default value);
-
- - Only for Linux users, you can find more informations about
- the env. var. MESA_GLX_FX in the "Doing more with Mesa & Linux Glide"
- section;
-
- - If you define the env. var. MESA_FX_SWAP_PENDING:
- export MESA_FX_SWAP_PENDING=4
- you will able to set the maximum number of swapbuffers
- commands in the Voodoo FIFO after a swapbuffer (default value: 2);
-
- - If you define the env. var. MESA_FX_INFO:
- export MESA_FX_INFO=1
- you will get some useful statistic.
-
- - If you define the env. var. MESA_FX_NO_SIGNALS:
- export MESA_FX_NO_SIGNALS=1
- Mesa/FX will not install atexit() or signal() handlers.
-
-
-
-Know BUGS and Problems:
------------------------
-
- - fog doesn't work in the right way when using the glDepthRange() function;
-
- - Maximum texture size: 256x256 (this is an hardware limit);
-
- - Texture border aren't yet supported;
-
- - A GL_BLEND in a glTexEnv() is not supported (it is an hardware limit);
-
- - Use the glBindTexture extension (standard in OpenGL 1.1) for texture
- mapping (the old way: glTexImage inside a display list, download
- the texture map each time that you call the display list !!!);
-
- - Stencil buffer and Accumulation buffer are emulated in software (they are not
- directly supported by the Hardware);
-
- - Color index mode not implemented (this is an hardware limit);
-
- - Thre is an know bug in the Linux Glide library so the in-window-rendering hack
- and any other operations that requires to read the Voodoo frame buffer
- (like the accumulation buffer support) doesn't work on Voodoo SLI cards.
-
- - The driver switch to pure software (_slow_) rendering when:
-
- - Stencil enabled;
- - Using the Accumulation buffer;
- - Blend enabled and blend equation != GL_FUNC_ADD_EXT;
- - Color logic operation enabled and color logic operation != GL_COPY;
- - Using GL_SEPARATE_SPECULAR_COLOR;
- - The four values of glColorMask() aren't the some;
- - Texture 1D or 3D enabled;
- - Texture function is GL_BLEND;
- - Using the Multitexture extension with Voodoo cards with only one TMU;
- - Using the Multitexture extension with Voodoo cards with more than
- one TMU, and texture function isn't GL_MODULATE;
- - Point size is != 1.0 or point params vector != (1.0,0.0,0.0);
- - Line width != 1.0 or using stipple lines.
- - Using polygon offset or stipple polygons;
-
- NOTE: this is list is not yet complete.
-
-
-Hints and Special Features:
----------------------------
-
- - Under Linux and with a Voodoo Graphics board, you can use
- XMesaSetFXmode(XMESA_FX_FULLSCREEN or XMESA_FX_WINDOW) in order to
- switch on the fly between fullscreen rendering and the in-window-rendering
- hack.
-
- - The driver is able to use all the texture memory available: 2/4MB on
- Voodoo1 boards and 8MB (!) on high-end Voodoo1 and Voodoo2 boards.
-
- - Trilinear filtering is fully supported on Voodoo boards with two TMUs
- (high-end Voodoo1 boards and Voodoo2 boards). When only one TMU is
- available the driver fallback to bilinear filter also if you ask
- for trilinear filtering.
-
- - The Voodoo driver support multiple Voodoo Graphics boards in the
- some PC. Using this feature, you can write applications that use
- multiple monitors, videoprojectors or HMDs for the output. See
- Mesa-3.1/3Dfx/demos/tunnel2.c for an example of how setup one
- context for each board.
-
- - The v0.19 introduces a new powerful texture memory manager: the
- texture memory is used as a cache of the set of all defined texture
- maps. You can now define several MBs of texture maps also with a 2MB
- of texture memory (the texture memory manager will do automatically
- all the swap out/swap in
- texture memory work). The new texture memory manager has also
- solved a lot of other bugs/no specs compliance/problems
- related to the texture memory usage.
-
- - Use triangles and quads strip: they are a LOT faster than sparse
- triangles and quads.
-
- - The Voodoo driver supports the GL_EXT_paletted_texture. it works
- only with GL_COLOR_INDEX8_EXT, GL_RGBA palettes and the alpha value
- is ignored because this is a limitation of the current Glide
- version and of the Voodoo hardware. See Mesa-3.1/3Dfx/demos/paltex.c for
- a demo of this extension.
-
- - The Voodoo driver directly supports 3Dfx Global Palette extension.
- It was written for GLQuake and I think that it isn't a good idea
- to use this extension for any other purpose (it is a trick). See
- Mesa-3.1/3Dfx/demos/glbpaltex.c for a demo of this extension.
-
- - The Voodoo driver chooses the screen resolution according to the
- requested window size. If you open a 640x480 window, you will get
- a 640x480 screen resolution, if you open a 800x600 window, you
- will get a 800x600 screen resolution, etc.
- Most GLUT demos support the '-geometry' option, so you can choose
- the screen resolution: 'tunnel -geometry 800x600'.
- Clearly, you Voodoo board must have enough framebuffer RAM (otherwise
- the window creation will fail).
-
- - The glGetString(GL_RENDERER) returns more information
- about the hardware configuration: "Mesa Glide <version>
- <Voodoo_Graphics|Voodoo_Rush|UNKNOWN> <num> CARD/<num> FB/
- <num> TM/<num> TMU/<NOSLI|SLI>"
- where: <num> CARD is the card used for the current context,
- <num> FB is the number of MB for the framebuffer,
- <num> TM is the number of MB for the texture memory,
- <num> TMU is the number of TMU. You can try to run
- Mesa/demos/glinfo in order to have an example of the output.
-
-Did you find a lot BUGs and problems ? Good, send me an email.
-
-
-
-FAQ:
-----
-
-For a complete FAQ check the Bernd Kreimeier's Linux 3Dfx HOWTO
-available at http://www.gamers.org/dEngine/xf3D (it includes also
-a lot of informations not strictly related to Linux, so it can be
-useful also if you don't use Linux)
-
-1. What is 3Dfx?
-
-3Dfx Interactive, Inc. is the company which builds the VooDoo 3-D graphics
-chipset (and others) used in popular PC cards such as the Diamond Monster 3D
-and the Orchid Righteous 3D (more informations at http://www.3dfx.com).
-
-
-2. What is Glide?
-
-Glide is a "thin" programming interface for the 3Dfx hardware. It was
-originally written for Windows/Intel but has been ported to Linux/Intel
-by Daryll Strauss.
-
-3Dfx, Inc. should be applauded for allowing the Linux version of Glide
-to be written.
-
-You can directly program with the Glide library if you wish. You can
-obtain Glide from the "Developer" section of the 3Dfx website: www.3dfx.com
-There's a Linux/Glide newsgroup at news://news.3dfx.com/3dfx.glide.linux
-
-
-3. What is fxmesa?
-
-"fxmesa" is the name of the Mesa device driver for the 3Dfx Glide library.
-It was written by David Bucciarelli and others. It works on both Linux
-and Windows. Basically, it allows you to write and run OpenGL-style programs
-on the 3Dfx hardware.
-
-
-4. What is GLQuake?
-
-Quake is a very popular game from id software, Inc. See www.idsoftware.com
-GLQuake is a version of Quake written for OpenGL. There is now a Linux
-version of GLQuake with works with the Mesa/3Dfx/Glide combo.
-
-Here's what you need to run GLQuake on Linux:
- PC with 100MHz Pentium or better
- a 3Dfx-based card
- Mesa 3.1 libraries: libMesaGL.so libMesaGLU.so
- Glide 2.4 libraries: libglide2x.so libtexus.so
- GLQuake for Linux.
-
-Also, the windows version of GLQuake works fine with the Mesa OpenGL32.dll,
-you have only to copy the Mesa-3.1/lib/OpenGL32.dll in the GLQuake directory
-in order to test 'MesaQuake'.
-
-
-5. What is GLUT?
-
-GLUT is Mark Kilgard's OpenGL Utility Toolkit. It provides an API for
-writing portable OpenGL programs with support for multiple windows, pop-
-up menus, event handling, etc.
-
-Check the Mark's home page for more informations (http://reality.sgi.com/mjk_asd).
-
-Every OpenGL programmer should check out GLUT.
-
-GLUT on Linux uses GLX.
-
-
-6. What is GLX?
-
-GLX is the OpenGL extension to the X Window System. I defines both a
-programming API (glX*() functions) and a network protocol. Mesa implements
-an emulation of GLX on Linux. A real GLX implementation would requires
-hooks into the X server. The 3Dfx hardware can be used with GLX-based
-programs via the MESA_GLX_FX environment variable.
-
-
-7. Is the Voodoo driver able to use the 4Mb texture memory of
-the Pure3D boards ?
-
-Yes, the Voodoo driver v0.20 includes the support for Voodoo
-Graphics boards with more than 2Mb of texture memory.
-
-
-8. Do the Voodoo driver support the Voodoo Rush under Windows ?
-
-Yes, Diego Picciani has developed the support for the Voodoo
-Rush but David Bucciarelli has a Pure3D and a Monster3D and Brian Paul
-has a Monster3D, so the new versions of the Mesa/Voodoo sometime are
-not tested with the Voodoo Rush.
-
-
-9. Do the Voodoo driver support the Voodoo Rush under Linux ?
-
-No because the Linux Glide doesn't (yet) support the Voodoo Rush.
-
-
-10. Can I sell my Mesa/Voodoo based software and include
-a binary copy of the Mesa in order to make the software
-working out of the box ?
-
-Yes.
-
-
-11. Which is the best make target for compiling the Mesa for
-Linux GLQuake ('make linux-glide', 'make linux-386-glide', etc.) ?
-
-'make linux-386-opt-glide' for Voodoo1 and 'make linux-386-opt-V2-glide'
-for Voodoo2 boards because it doesn't include the '-fPIC'
-option (4-5% faster).
-
-
-12. Can I use a Mesa compiled with a 'make linux-386-opt-V2-glide'
-for my applications/programs/demos ?
-
-Yes, there is only one constrain: you can't run two Mesa applications
-at the some time. This isn't a big issue with the today Voodoo Graphics.
-
-
-Thanks to:
-----------
-
-Henri Fousse (he has written several parts of the v0.15 and the old GLUT
- emulator for Win);
-
-Diego Picciani (he has developed all the Voodoo Rush support and the wgl
- emulator);
-
-Daryll Strauss (for the Linux Glide and the first Linux support);
-
-Brian Paul (of course);
-
-Dave 'Zoid' Kirsch (for the Linux GLQuake and Linux Quake2test/Q2 ports)
-
-Bernd Kreimeier (for the Linux 3Dfx HOWTO and for pushing companies to offer
- a better Linux support)
-
-3Dfx and Quantum3D (for actively supporting Linux)
-
-The most update places where find Mesa VooDoo driver related informations are
-the Mesa mailing list and my driver WEB page
-(http://www-hmw.caribel.pisa.it/fxmesa/index.shtml)
-
-
-David Bucciarelli (davibu@tin.it)
-
-Humanware s.r.l.
-Via XXIV Maggio 62
-Pisa, Italy
-Tel./Fax +39-50-554108
-email: info.hmw@plus.it
-www: www-hmw.caribel.pisa.it
+++ /dev/null
-AMIGA AMIWIN PORT of MESA: THE OPENGL SOFTWARE EMULATION
-========================================================
-Port by Victor Ng-Thow-Hing (victorng@dgp.toronto.edu)
-Original Author (Brian Paul (brianp@ssec.wisc.edu)
-
-Dec.1 , 1995: Port of release Mesa 1.2.5
- - Modifications made to minimize changes to Mesa distribution.
-
-Nov.25, 1995: Port of release Mesa 1.2.4
-
-
-HISTORY
-=======
-As a 3D graphics progammer, I was increasingly frustrated to see OpenGL
-appearing on so many platforms EXCEPT the Amiga. Up to now, the task
-of porting OpenGL directly from native Amiga drawing routines seemed like
-a daunting task. However, two important events made this port possible.
-
-First of all, Brian Paul wrote Mesa, the OpenGL software emulator that
-can be found on many platforms - except the Amiga and Atari (who cares
-about the latter!). This was pretty ironic considering that Mesa was
-originally prototyped on an Amiga! The second great event was when
-Holger Kruse developed AmiWin, the X11R6 server for the Amiga (definitely
-register for this great piece of software) and released a development kit
-so one could compile X programs with SAS/C.
-
-Since Mesa had X routines as its primitive drawing operations, this made
-a marriage of Mesa and Amiwin feasible. I copied over the sources from
-an ftp site, played with the code, wrote some Smakefiles, and voila,
-I had OpenGL programs displaying on my Amiga.
-
-Although the speed is nothing to be impressed about, this port can be
-potentially useful to those who want to quickly test their code in
-wireframe or perhaps learn more about programming with the OpenGL API.
-
-I hope Amiga developers will continue to write excellent software for
-their machine, especially more X clients for Amiwin. If you have any
-solutions so some of my problems in the porting notes, please send me
-some email!
-
-See you around,
-Vic.
-
-HOW TO CREATE THE LIBRARIES AND SAMPLE CODE
-===========================================
-
-Just run the shell script mklib.amiwin in the mesa directory. This will
-make all the libraries and copy them into the mesa/lib directory. If you
-don't want to compile everything, just go to the desired directory and
-type smake in that directory.
-
-Change any of the variables in the smakefiles as necessary. You will REQUIRE
-the Amiwin development kit to compile these libraries since you need X11.LIB
-and the shareable X libraries. Some examples require the AmiTCP4.0
-net.lib static link library and related header files for unix related
-header files and functions like sleep().
-
-HOW TO USE THE MESA LIBRARIES
-=============================
-
-Study the Smakefiles in the demos, samples and book directories for the
-proper SAS/C options and linkable libraries to use. Basically aux calls
-require Mesaaux.LIB, gl calls require MesaGL.LIB, glu calls MesaGLU.LIB,
-tk calls Mesatk.LIB. There is a preliminary port of MesaGLUT.LIB toolkit
-available in the lib directory with the other Mesa libraries. However,
-it seems to cause crashes on some of the sample code. Someone else may want
-to attempt a more stable port.
-
-PORTING NOTES TO AMIWIN
-=======================
-
-My strategy of porting was to leave as much of the code untouched as
-possible. I surrounded any amiga specific changes with
-#ifdef AMIWIN ... #endif or #ifndef AMIWIN ... #endif preprocessor
-symbols. The code was ported on an Amiga 2000, with Fusion 40 accelerator
-and a Picasso II graphics card. The SAS/C 6.56 compiler was used, with
-the AmiWin 2.16 X development kit.
-
-All compilations were done for a 68040 CPU with 68882 math coprocessor for
-maximum speed. Please edit the smakefile for other compilers.
-I wrote smakefiles for the directories I ported. I omitted the Windows
-and Widgets directories. The former is for MS Windows and the latter
-requires Motif, which is not easily available for the Amiga.
-
-Here are the changes I did per directory:
-
-* mesa
-Nov. 25, 1995 v 1.2.4
- - added a mklib.amiwin shell script that will make all the libraries and
- sample code for Mesa
- - created this readme file: readme.AMIGA
-
-* mesa/include
-Dec. 1, 1995 v 1.2.5
- - added the following to GL/xmesa.h
- #ifdef AMIWIN
- #include <pragmas/xlib_pragmas.h>
- extern struct Library *XLibBase;
- #endif
-NET CHANGE: xmesa.h
-
-* mesa/src
-Nov. 25, 1995 v 1.2.4
- - added the necessary pragma calls for X functions to the following:
- xmesa1.c, xmesa2.c, xmesa3.c, xfonts.c, glx.c
- This prevents undefined symbols errors during the linking phase for
- X library calls
- - created smakefile
-Dec. 1, 1995 v 1.2.5
- - removed AMIWIN includes from xmesa1.c, xmesa2.c, xmesa3.c, xfonts.c,
- glx.c since they are now defined in include/GL/xmesa.h
-NET CHANGE: smakefile
-
-* mesa/src-tk
-Nov. 25, 1995 v 1.2.4
- - added the necessary pragma calls for X functions to the following:
- private.h
- - created smakefile
-Dec. 1, 1995 v 1.2.5
- - removed AMIWIN includes from private.h since it is now defined in
- include/GL/xmesa.h
-NET CHANGE: smakefile
-
-* mesa/src-glu
-Nov. 25, 1995 v 1.2.4
- - created smakefile
-NET CHANGE: smakefile
-
-* mesa/src-aux
-Nov. 25, 1995 v 1.2.4
- - added the necessary pragma calls for X functions to the following:
- glaux.c
- - created smakefile
-NET CHANGE: glaux.c, smakefile
-
-* mesa/demos
-Nov. 25, 1995 v 1.2.4
- - added the necessary pragma calls for X functions to the following:
- xdemo.c, glxdemo.c, offset.c
- - created smakefile
- - put #ifndef AMIWIN ... #endif around sleep() calls in xdemo.c since
- they are not part of AmigaDOS.
-Dec. 1, 1995 v 1.2.5
- - removed AMIWIN defines from xdemo.c, glxdemo.c, offset.c since
- already defined in include/GL/xmesa.h
- - modified Smakefile to include header and includes from the AmiTCP4.0
- net.lib linkable library to provide unix-compatible sys/time.h and
- the sleep() function
- - removed AMIWIN defines in xdemo.c since sleep() now defined
-NET CHANGE: smakefile
-
-* mesa/samples
-Nov. 25, 1995 v 1.2.4
- - added the necessary pragma calls for X functions to the following:
- oglinfo.c
- - created smakefile
- - put #ifndef AMIWIN ... #endif around sleep() in blendxor.c
- - removed olympic from smakefile targets since <sys/time.h> not defined
-Dec. 1, 1995 v 1.2.5
- - removed AMIWIN defines from oglinfo.c, since already defined in
- include/GL/xmesa.h
- - modified Smakefile to include header and includes from the AmiTCP4.0
- net.lib linkable library to provide unix-compatible sys/time.h and
- the sleep() function
- - removed AMIWIN defines in blendxor.c for sleep()
- - added AMIWIN defines around _MACHTEN_ in olympic.c since xrandom()
- functions are not defined in any libraries
- - added olympic back into the Smakefile targets
-NET CHANGE: smakefile, olympic.c
-
-* mesa/book
-Nov. 25, 1995 v 1.2.4
-- created smakefile
-- removed accpersp and dof from smakefile targets since the SAS/C compile seems to
- confuse the near,far variables with near/far memory models.
-NET CHANGE: smakefile
-
-* mesa/windows
-Dec. 1, 1995 v 1.2.5
-- Removed directory to save space since this is only needed for Windows based
- machines.
+++ /dev/null
- Mesa 6.5 DOS/DJGPP Port v1.8
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-
-
-Description:
-~~~~~~~~~~~~
-
-Well, guess what... this is the DOS port of Mesa 6.5, for DJGPP fans... Whoa!
-The driver uses OSMesa to draw off screen, and then blits the buffer. This is
-not terribly efficient, and has some drawbacks, but saves maintenance costs.
-
-
-
-Legal:
-~~~~~~
-
-Mesa copyright applies.
-
-
-
-Installation:
-~~~~~~~~~~~~~
-
-Unzip and type:
-
- make -f Makefile.DJ [OPTIONS...]
-
-Available options:
-
- Environment variables:
- CPU optimize for the given processor.
- default = pentium
- GLIDE path to Glide3 SDK; used with FX.
- default = $(TOP)/glide3
- FX=1 build for 3dfx Glide3. Note that this disables
- compilation of most DMesa code and requires fxMesa.
- As a consequence, you'll need the DJGPP Glide3
- library to build any application.
- default = no
- X86=1 optimize for x86 (if possible, use MMX, SSE, 3DNow).
- default = no
-
- Targets:
- all: build everything
- libgl: build GL
- libglu: build GLU
- libglut: build GLUT
- clean: remove object files
- realclean: remove all generated files
-
-
-
-Tested on:
- Video card: Radeon 9500
- DJGPP: djdev 2.04 + gcc v4.1.0 + make v3.80
- OS: DOS, Win98SE, WinXP (using Videoport driver)
-
-
-
-FAQ:
-~~~~
-
-1. Compilation
-
- Q) `make' barfs and exits because it cannot find some stupid file.
- A) You need LFN support.
- A) When compiling for Glide (FX=1), pay attention to Glide path.
-
- Q) Libraries built OK, but linker complains about `vsnprintf' every time I
- compile some demo.
- A) Upgrade to DJGPP 2.04.
- A) Add `vsnprintf.c' to the CORE_SOURCES in `src/Makefile.DJ' (untested!).
- A) Patch `src/mesa/main/imports.c' with the following line:
- #define vsnprintf(buf, max, fmt, arg) vsprintf(buf, fmt, arg)
- This hack should be safe in 90% of the cases, but if anything goes wrong,
- don't come back to me crying.
-
- Q) `make' complains about DXE3 or something, yet it builds the libraries.
- A) DXE3 refers to the DJGPP dynamic modules. You'll need either the latest
- DJGPP distro, or download the separate package from my web page. Read the
- DXE3 documentation on how to use them.
- A) When compiling for Glide (FX=1), make sure `glide3x.dxe' can be found in
- LD_LIBRARY_PATH (or top `lib' directory).
-
-2. Using Mesa for DJGPP
-
- Q) Every test I tried crashes badly.
- A) If you have compiled with SSE and you're running under plain DOS, you
- have to disable SSE at run-time. See environment variables below.
-
- Q) DMesa is so SLOOOW! The Win32 OpenGL performs so much better...
- A) Is that a question? If you have a 3dfx Voodoo (any model), you're
- lucky (check http://sourceforge.net/projects/glide for the DJGPP port).
- If you haven't, sorry; everything is done in software.
-
- Q) I tried to set refresh rate w/ DMesa, but without success.
- A) Refresh rate control works only for VESA 3.0 and the 3dfx driver (in
- which case FX_GLIDE_REFRESH will be overwritten if it is defined and
- is not 0).
-
- Q) I made a simple application and it does nothing. It exits right away. Not
- even a blank screen.
- A) Software drivers (VESA/VGA/NUL) must to be constructed as single-buffered
- visuals. However, DMesaSwapBuffers must be called to get any output.
- A) Another weird "feature" is that buffer width must be multiple of 8 (I'm a
- lazy programmer and I found that the easiest way to keep buffer handling
- at peak performance ;-).
-
- Q) I'm getting a "bad font!" fatal error.
- A) Always use GLUT_STROKE_* and GLUT_BITMAP_* constants when dealing with
- GLUT fonts. If you're using `glut.dxe', then make sure GLUT_STROKE_* and
- GLUT_BITMAP_* are mapped to integer constants, not to the actual font
- address (same mechanism used for Win32 _DLL).
-
- Q) What is NUL driver good for, if I don't get any output at all?
- A) For debugging. The NUL driver is very much like OSMesa. Everything is
- done just the same as VESA/VGA drivers, only it doesn't touch your video
- hardware. You can query the actual buffer by issuing:
- DMesaGetIntegerv(DMESA_GET_BUFFER_ADDR, &buffer);
- and dump it to a file.
-
- Q) How do I query for a list of available video modes to choose as a visual?
- A) This is an ugly hack, for which I'm sure I'll burn in hell.
- First, query for a list of modes:
- n = DMesaGetIntegerv(DMESA_GET_VIDEO_MODES, NULL);
- If `n' is strictly positive, you allocate an array of pointers to a given
- struct (which is guaranteed to be extended only - not changed in future):
- struct {
- int xres, yres;
- int bpp;
- } **l = malloc(n * sizeof(void *));
- Now pass the newly allocated buffer to fill in:
- DMesaGetIntegerv(DMESA_GET_VIDEO_MODES, (GLint *)l);
- And collect the info:
- for (i = 0; i < n; i++) {
- printf("%dx%d:%d\n", l[i]->xres, l[i]->yres, l[i]->bpp);
- }
-
- Q) The GLUT is incomplete.
- A) See below.
-
-
-
-libGLUT (the toolkit):
-~~~~~~~~~~~~~~~~~~~~~~
-
-Well, this "skeletal" GLUT implementation was taken from AllegGL project and
-heavily changed. Thanks should go to Bernhard Tschirren, Mark Kilgard, Brian
-Paul and probably others (or probably not ;-). GLUT functionality will be
-extended only on an "as needed" basis.
-
-GLUT talks to hardware via PC_HW package which was put together from various
-pieces I wrote long time ago. It consists from the keyboard, mouse and timer
-drivers.
-
-My keyboard driver used only scancodes; as GLUT requires ASCII values for keys,
-I borrowed the translation tables (and maybe more) from Allegro -- many thanks
-to Shawn Hargreaves et co. Ctrl-Alt-Del (plus Ctrl-Alt-End, for Windows users)
-will shut down the GLUT engine unconditionally: it will raise SIGINT, which in
-turn will (hopefully) call the destructors, thus cleaning up your/my mess ;-)
-NB: since the DJGPP guys ensured signal handlers won't go beyond program's
-space (and since dynamic modules shall) the SIGINT can't be hooked (well, it
-can, but it is useless), therefore you must live with the 'Exiting due to
-signal SIGINT' message...
-
-The mouse driver is far from complete (lack of drawing, etc), but is enough to
-make almost all the demos work. Supports the CuteMouse WheelAPI.
-
-The timer is pretty versatile for it supports multiple timers with different
-frequencies. While not being the most accurate timer in the known universe, I
-think it's OK. Take this example: you have timer A with a very high rate, and
-then you have timer B with very low rate compared to A; now, A ticks OK, but
-timer B will probably loose precision!
-
-As an addition, stdout and stderr are redirected and dumped upon exit. This
-means that `printf' can be safely called during graphics. A bit of a hack, I
-know, because all messages come in bulk, but I think it's better than nothing.
-"Borrowed" from LIBRHUTI (Robert Hoehne).
-
-Window creating defaults: (0, 0, 300, 300), 16bpp. However, the video mode is
-chosen in such a way that first window will fit. If you need high resolution
-with small windows, set initial position far to the right (or way down); then
-you can move them back to any position right before the main loop.
-
-
-
-Environment variables:
-~~~~~~~~~~~~~~~~~~~~~~
- DMESA_NULDRV - (any value) force NUL driver
- GLUT_FPS - print frames/second statistics to stderr
- MESA_NO_SSE - (any value) safe option under pure DOS
- DMESA_GLUT_REFRESH - set vertical screen refresh rate (VESA3)
- DMESA_GLUT_BPP - set default bits per pixel (VGA needs 8)
- DMESA_GLUT_ALPHA - set default alpha bits (8)
- DMESA_GLUT_DEPTH - set default depth bits (16)
- DMESA_GLUT_STENCIL - set default stencil bits (8)
- DMESA_GLUT_ACCUM - set default accum bits (16)
-
-
-
-History:
-~~~~~~~~
-
-v1.0 (mar-2002)
- initial release
-
-v1.1 (sep-2002)
- + added 3dfx Glide3 support
- + added refresh rate control
- + added fonts in GLUT
- * lots of minor changes
-
-v1.2 (nov-2002)
- * synced w/ Mesa-4.1
- - removed dmesadxe.h
-
-v1.3 (mar-2003)
- + enabled OpenGL 1.4 support
- + added MMX clear/blit routines
- + enabled SGI's GLU compilation
- + added samples makefile
- + added new GLUT functions
- + added color-index modes
- + added Matrox Millennium MGA2064W driver
- + added 8bit FakeColor (thanks to Neil Funk)
- + added VGA support (to keep Ben Decker happy)
- ! fixed some compilation errors (reported by Chan Kar Heng)
- * optimized driver for faster callback access... yeah, right :)
- * overhauled virtual buffer and internal video drivers
- * better fxMesa integration
- * revamped GLUT
- * switched to DXE3
-
-v1.4 (dec-2003)
- + enabled GLUT fonts with DXE
- + truly added multi-window support in GLUT (for Adrian Woodward)
- * accomodated makefiles with the new sourcetree
- * fixed some ALPHA issues
- * minor changes to PC_HW/timer interface
- x hacked and slashed the 3dfx driver (w/ help from Hiroshi Morii)
-
-v1.5 (jan-2004)
- + added interface to query available "visuals" (GLFW - Marcus Geelnard)
- + added GLUT timer callback
- - removed Matrox Millennium MGA2064W driver
- x more changes to the 3dfx driver
-
-v1.6 (aug-2004)
- + implemented NUL driver
- + added DMesaGetProcAddress and glutGetProcAddress
- * reorganized fxMesa wrapper to handle multiple contexts
- ! fixed a horrible bug in VGA initialization routine
- ! fixed partial clears
-
-v1.7 (???-2005)
- + enabled OpenGL 2.0 support
- + added support for sw texture compression
- + added FreeGLUT specific functions
- * no more GLX sources in DOS GLUT
- * made GLUT timer callbacks less accurate but safer
-
-v1.8 (apr-2006)
- * killed lots of code, the driver is now a front-end to OSMesa
- * fixed problem with WinNT (http://www.volny.cz/martin.sulak/)
- - removed 3dfx Glide3 support (temporarily?)
-
-
-
-Contact:
-~~~~~~~~
-
-Name: Daniel Borca
-E-mail: dborca@users.sourceforge.net
-WWW: http://www.geocities.com/dborca/
+++ /dev/null
-GGIMesa for LibGGI 2.x
-
-Requirements:
--------------
-LibGGI 2.0 or greater
-
-Installation:
--------------
-To install GGIMesa, follow the instructions in INSTALL.GNU. If you
-wish to install GGIGLUT as well, first install GGIMesa and then run
-
-make
-make install (must be root)
-
-in ggi/ggiglut.
-
-Notes:
-------
-
-* Set the environment variables GGIMESA_DEBUG and/or GGIGLUT_DEBUG
-to 255 to see lots of debugging output.
-
-* GGIGLUT contains support for all of the GLUT 3.6 API except for the
-high-level primitive drawing functions, but many of the functions (in
-particular the menu drawing functions) are just stubs.
-
+++ /dev/null
-
-Mesa 3.0 for LynxOS builds in the following way:
-
-make lynxos
-
-This will build all the libraries and demo applications. You should have
-around 400 megabytes free for everything since everything is done with
-static
-libraries.
-
-Before using this make file however, you should perform the following
-actions:
-0) cd to the Mesa-3.0 directory
-1) Copy the GL directory under the include directory to /usr/include.
-2) Copy the files in the lib directory to /lib.
-3) Make links so that the Mesa libraries look like ordinary OpenGL
-libraries
-in /lib. This is important for compatibility with other OpenGL apps. This
-is done as follows:
-
-cd /lib
-ln -s libMesaGL.a libGL.a
-ln -s libMesaGLU.a libGLU.a
-
-Mesa 3.0 includes the GLUT (GL Utility Toolkit) by default.
-The demo applications are done using this toolkit.
-
-Mesa makefiles for building their apps could be used as well, but the
-following one is much more concise. Note that the order of the X libraries
-is important to the linker so that all symbols get resolved correctly.
-Changing the order may result in having to list a library twice to make
-sure all linkages are made correctly.
-
-----cut here for Makefile -----
-
-FILES = your_app.x
-
-SPECIAL_INCLUDES = -I/usr/include/GL
-
-SPECIAL_CFLAGS = -g -ansi -pedantic -funroll-loops -ffast-math -DSHM
-
-SPECIAL_LIBS = -lglut -lGLU -lGL -lm -L/usr/X11/lib -lXext -lXmu -lXi \
--lX11 -lbsd -g
-
-STANDARD_OFILES = $(FILES:.x=.o)
-
-%.o: %.c
- gcc -c $(SPECIAL_CFLAGS) $(SPECIAL_INCLUDES) $< -o $@
-
-all: $(STANDARD_OFILES)
- gcc -o your_app $(STANDARD_OFILES) $(SPECIAL_LIBS)
-
-
-----cut here for Makefile-----
-
-I have tested Mesa under LynxOS 3.0 and 3.01. It should build fine under
-other
-versions as well. Note, however, that LynxOS versions prior to 3.0 are not
-binary compatible, so you will have to rebuild from source.
-
-
-Vik Sohal
-vik@lynx.com
-January 13, 1999
+++ /dev/null
-The NeXT support has now been incorporated into the OpenStep support.
-You can build NeXT libraries simply by typing "make next", though before
-linking they will need to be ranlib'd by hand. For more information see
-the README.OpenStep file, together with the README files in OpenStep/Old_Demos.
-
--Pete French. (pete@ohm.york.ac.uk) 28/5/1998
+++ /dev/null
- README for port of Mesa 3.x to XFree86 on OS/2 (X/2)
- (as of 19990514)
-
-
- Contents:
-
- 1) Binary release
- 2) Building from sources
- 3) History
- 4) Todo
- 5) Mesa Home Page
-
-
-1) Binary release
-
- Though the Mesa sources should build in a quite reasonable time even on
- a 585 class machine a binary relase is available (check topic 4) for an URL)
- This package includes:
-
- - lib/MesaGL.dll, MesaGL.a
- - lib/MesaGLU.dll, MesaGLU.a
- - lib/glut.dll, glut.a
- - include/GL/*.h
-
- Installing this in your XFree86 tree will enable you to build and
- run all applications compatible with Mesa (and the current DLL
- interface, of course ;-)
- As usual the OMF-style libraries can be created using emxomf.
- (e.g. "emxomf foo.a" creates the foo.lib omf-style library).
- The static libraries are rarely used and you have to rebuild
- Mesa to get them. They're a supported target, so you get
- them in a straightforward way (see below).
-
- The testing of these libraries was limited to the supplied
- demos/examples and a quite small number of third-party apps.
- No warranty ... as usual ... ;-)
-
-
-2) Instructions to build Mesa 3.x for XFree86/OS2 from sources:
-
- Except the official Mesa source distribution you need:
- - a recent version of XFree86 (3.3.x or above) including
- the programming libraries
- - EMX 0.9c (0.9d might work, never checked)
- - GNU make
- - REXX (!)
-
- The creation of the DLLs as well as of the static libraries
- (if you want to have them) is handled in "mklib-emx.cmd",
- a small REXX script. Perhaps not the best idea, but this
- way it fits best in the scheme used to build libraries
- on all platforms in Mesa 3.x.
-
- To actually build the libraries and demos, check mklib-emx.cmd
- and modify it as desired. Then type
- make os2-x11
- and wait for completion ;-)
-
-
-3) History
-
- Initially Darren Abbott (abbott@hiwaay.net) ported Mesa versions 2.x
- to XFree86 OS/2. This port might still be available from
- http://fly.HiWAAY.net/~abbott/xfree86-os2/xfree86.html
-
- The current port picked up things during the beta test for 3.0.
- No major changes in the source were done. The build mechanism under OS/2
- has been made very similar to other platforms (if you treat mklib-emx.cmd
- as a "black box").
- Advantage is that X/2 is now a valid target and all files are
- integrated in the official source distribution.
- Disadvantage is that this port (i.e. the DLLs' interface itself) is
- definitly NOT COMPATIBLE to those of version 2.x.
- It's uncertain whether this would be at all possible but since there
- a _very_ few those apps it's not worth to find out anyway.
- Also some libs (MesaTK, MesaAUX) are withdrawn from the Mesa distribution,
- and accordingly from the OS/2 port.
-
-4) Todo
-
- By now binary compatiblity is ensured by using the function names
- as entry points instead of ordinals. This might cost performance and
- is subject to change in future. In addition the supplied X86 assembler
- source is not used yet.
-
-5) Mesa Home Page
-
- You can get the source code and more information about Mesa from
- http://www.mesa3d.org/
-
- The OS/2 ports should be available from
- http://r350.ee.ntu.edu.tw/~hcchu/os2/ports
-
---
-Alexander Mai
-st002279@hrzpub.tu-darmstadt.de
+++ /dev/null
-This is a port of the GL and GLU libraries to NeXT/Apple object
-orientated systems. As these systems have their own window handling
-systems we simply use the offscreen rendering capability of Mesa
-to generate bitmaps which may then be displayed by the application
-with a View as required. Example pieces of code may be found in the
-OpenStep directory.
-
-Sadly there are now a proliferation of different system that we need to
-support compilation for: The original NextStep system, The OpenStep
-system, the Rhapsody/Mac OS X system and also the windows implementations
-of the latter two systems. This version of the code has been compiled and
-tested under the following architectures:
-
- NextStep 3.3
- OpenStep 4.2
- Rhapsody DR2
- WebObjects for NT 3.5
- WebObjects for NT 4.0
-
-All tests were done with Intel processors. Feedback on other systems would,
-however, be appreciated !
-
-On UNIX systems simply type "make openstep". Under Windows systems
-with WebObjects run the "win32-openstep.sh" script from within the Bourne
-shell provided with the development environment. In both cases this will
-build the libraries and place them into the "lib" directory. Some examples
-may be found in the OpenStep directory showing how to use the code in an
-actual application (MesaView) as well as some command line demos.
-
-The CC variable may be specified on the command line for doing such things
-as building FFAT libraries or using alternative compilers to the standard 'cc'
-e.g. make CC='cc -arch m68k -arch i386' openstep" will build the libraries
-with both intel and motorola architectures.
-
--Pete French. (pete@ohm.york.ac.uk) 7/6/1999
+++ /dev/null
-
- WindML Driver for Mesa 4.0
-
-
-Requirements
-------------
-
-Tornado 2 + WindML, Cumulative Patchs are recommended.
-
-I suppose you have a valid WindML installation. Double buffer hardware
-gives better performance than double buffer software so if you can
-compile your WindML driver with this option, just do it. I/O
-redirection is adviced in target server.
-
-
-Tested on
----------
-
-During the development, my main target was a CoolMonster:
-- Video card: CT69000
-- CPU: PENTIUM 266MHz
-
-and my host a Windows NT + Tornado 2.
-
-
-Installation
-------------
-
-1. Mesa sources must be in root directory (C:\)
-
-2. Add the following line to your torVars.bat:
-set MESA_BASE=C:\Mesa
-
-OR copy the new torVars.bat in your bin path:
-c:/Mesa/src/ugl/tornado/torVars.sample ->
-/mnt/nt/Tornado/host/x86-win32/bin/torVars (for example)
-
-3. In a command prompt:
-$ torVars
-$ cd c:\Mesa
-$ make -f Makefile.ugl CPU=PENTIUM
-
-Take a long while...
-
-5. Include all the files from ugldemos folder to build some downloadable
- application modules
-
-4. Download UGL/Mesa object files on target
-
-For example via the WindShell:
-ld < c:\Tornado\target\lib\objMesaGL.o
-ld < c:\Tornado\target\lib\objMesaUGL.o
-ld < c:\Tornado\target\lib\objMesaGLU.o
-ld < c:\Tornado\target\lib\objGLUTshapes.o
-ld < c:\Tornado\target\lib\objMesaOS.o
-
-You can put the previous lines in a file and use:
-< filename
-
-6. Download the application modules.
-
-7. In WindShell, run:
--> uglalldemos
-
-During the show some messages will appear, it provides some useful
-information on key management.
-
-
-Coding
-------
-
-Sample Usage:
-
-In addition to the usual ugl calls to initialize UGL, (may be find an
-input driver), you must do the following to use the UGL/Mesa interface:
-
-1. Call uglMesaCreateContext() to create a UGL/Mesa rendering context,
- given the display format.
-
-2. Call uglMesaMakeCurrent() to bind the UGL/Mesa buffers to an
- UGL/Mesa Context and to make the context the current one.
-
-3. Make gl* calls to render your graphics.
-
-4. Use uglMesaSwapBuffers() when double buffering to swap front/back buffers.
-
-5. Before the UGL is destroyed, call MesaDestroyContext().
-
-6. Before exiting, call if required uglEventQDestroy and then
- uglDeinitialize();
-
-Limitations
------------
-
-I found the following limitations in my driver :
- - Color Indexed management is only in 8 bits
- - It's possible to mix UGL/OpenGL application with a software
- double buffer
-
-Modifications
-------------
-
-New files in Mesa:
-- Makefile.ugl
-- rules.windmlmesa
-- docs/README.UGL
-- include/GL/uglmesa.h
-- si-glu/Makefile.ugl
-- src/Makefile.ugl
-- src/ugl/torGLUTShapesInit.c
-- src/ugl/torMesaUGLInit.c
-- src/ugl/ugl_api.c
-- src/ugl/ugl_dd.c
-- src/ugl/ugl_glutshapes.c
-- src/ugl/ugl_line.c
-- src/ugl/ugl_span.c
-- src/ugl/ugl_tri.c
-- src/ugl/uglmesaP.h
-- ugldemos/*
-
-Modified files in Tornado 2.0:
-- c:\Tornado\host\x86-win32\bin\torVars.bat
-rem Command line build environments
-set WIND_HOST_TYPE=x86-win32
-set WIND_BASE=C:\Tornado
-set MESA_BASE=C:\Mesa
-set PATH=%WIND_BASE%\host\%WIND_HOST_TYPE%\bin;%PATH%
-- c:\Tornado\target\config\comps\VxWorks\01uglmesa.cdf
-- c:\Tornado\target\h\GL\*
-
-Todo
-----
-- GCC 2.96, ASM compilation
-
-Thanks to:
-----------
-
-Precision Insight team for their great job around Mesa, XFree, and DRI.
-Wind River Systems to take me as an intern.
-
-
-Stephane Raimbault
-<stephane.raimbault@windriver.com>
-<stephane.raimbault@deesse.univ-lemans.fr>
-
-July 24, 2001
<LI>DEC VMS <A HREF="README.VMS">(README.VMS)</A>
</UL>
-
-<h2>Deprecated Systems</h2>
-
-<p>
-These drivers have not been maintained and are being deprecated.
-They can be saved if someone steps up to help.
-</p>
-
-<UL>
-<LI>3dfx/Glide <A HREF="README.3DFX">(README.3DFX)</A>
-<LI>GGI <A HREF="README.GGI">(README.GGI)</A>
-<LI>Amiga Amiwin <A HREF="README.AMIWIN">(README.AMIWIN)</A>
-<LI>Direct3D driver <A HREF="README.D3D">(README.D3D)</A>
-<LI>DJGPP <A HREF="README.DJ">(README.DJ)</A>
-<LI>LynxOS <A HREF="README.LYNXOS">(README.LYNXOS)</A>
-<LI>Mingw32 <A HREF="README.MINGW32">(README.MINGW32)</A>
-<LI>NeXT <A HREF="README.NeXT">(README.NeXT)</A>
-<LI>OpenStep <A HREF="README.OpenStep">(README.OpenStep)</A>
-<LI>OS/2 <A HREF="README.OS2">(README.OS2)</A>
-<LI>WindML <A HREF="README.WINDML">(README.WINDML)</A>
-</UL>
-
-And for historical reference:
-<UL>
-<LI><a href="http://utah-glx.sourceforge.net/" target="_parent">Utah GLX drivers</a>
-</UL>
-
</body>
</html>
projects / mesa.git / commitdiff