Ted's 3.1b2 update

1 files changed, 606 insertions, 739 deletions

diff --git a/docs/README.WIN32 b/docs/README.WIN32
index 6382624f56..43ad8a8b42 100644
--- a/docs/README.WIN32
+++ b/docs/README.WIN32
@@ -1,739 +1,606 @@
-
-    Mesa/Readme.win32
-
-    Last Updated: Sun, Dec 06 1998, 08:49 EST - tjump@spgs.com
-
-    Note: While this build set supports generation of a 3Dfx specific
-          DLL using Mesa, David Bucciarelli's original build files
-          are the "supported" method. -Ted
-
-*** What's New
-
-- Build environment change: The Glide SDK is no longer assumed to be in
-  the global INCLUDE/LIB environment vars, it is required that you set the
-  value 'GLIDE2X' as either an environment variable pointing to your Glide
-  SDK install directory or that you configure that as a build option to
-  nmake.exe when building fxmesagl32.  Examples:
-
-    nmake /f nmake.mak GLIDE2X=g:\sdk\glide2x fxmesagl32
-
-          <or>
-
-    nmake /f nmake.mak GLIDE2X=g:\sdk\glide2x allfx
-
-          <or>
-
-    nmake /f nmake.mak GLIDE2X=g:\sdk\glide2x progs.3dfx.demos
-
-  The DevStudio workspace files for 3Dfx OpenGL require the definition of
-  GLIDE2SDK as an environment variable pointing to where your copy of the
-  Glide SDK has been installed. Adding this to your AUTOEXEC.BAT would do
-  so (change the directories to match):
-
-       SET GLIDE2SDK=G:\SDK\GLIDE2X
-
-- Static build/link of all non-3Dfx targets works now, cool. Required some
-  nontrivial chicanery in the GLUT headers though to allow it to use the
-  mesa 'wgl' functions statically linked instead of always importing the
-  sytem wgl functions from GDI32. Mostly this was an extension of an
-  existing method used in the headers, just taking into account more
-  functions.
-
-- Handled an undocumented change in how Microsoft NMAKE for DevStudio 6
-  defines _NMAKE_VER so that the makefiles should work properly.
-
-- Microsoft Compiler/Win32 specific build tuneups in the header files
-  providing for dramatically faster compilation times of mesa itself and of
-  code using Mesa. Primarily via the removal of any call sequence which
-  would invoke WINDOWS.H (which triggers ~6-10K lines of code inclusion).
-
-  Supporting this, a macro name change was made in the gl.h/glu.h/glut.h
-  header files which should be client-code transparent. The change was to
-  specify function prototypes with the (newly created) macro GLAPI instead
-  of WINGDIAPI to ease conflicts with multiple definitions of WINGDIAPI
-  (needs to be one thing to access Win32 API calls, another to define
-  export funcs when building a Mesa/GLU/GLUT DLL which themselves need to
-  import functions from Win32, etc.).
-
-  Similarly, call sequence definition usage of APIENTRY, CALLBACK, and
-  WINAPI were renamed to prevent collision/need for windows.h.
-
-  Lastly, these changes were incorporated into the GLUT source to
-  facilitate same compile-time performance increases.
-
-  All of these changes should be transparent to code USING
-  mesa/mesaglu/glut, and in most cases did not require changes in their
-  source files within the Mesa/GLUT code base (but there were a few).
-
-- 'wgl' function prototypes and supporting data types declared in gl/gl.h
-  to provide for the usage of these from client Windows code without
-  requiring WINDOWS.H to be included. If you're using non-trivial functions
-  (such as any that pass structures around) you will need to include
-  WINDOWS.H *before* gl/gl.h, however in that case you needed them anyway.
-
-  One benefit of this is that glut-based code on Windows may now use
-  wglGetProcAddress to get the function pointers for all supported OpenGL
-  extensions, preventing the need for directly importing them into
-  code. The 3Dfx/Demos/glbpaltx.c has been modified to use this mechanism
-  by way of example.
-
-  This code has also been copied into gl/glut.h to support glut programs on
-  Windows that do not use Mesa.
-
-- new command line build target: all.debug
-
-  Builds all DLL files and test programs in release, then debug builds,
-  emplacing the requried DLL files in the EXE directories for ready test
-  runs.
-
-- Expanded MESA_WGL_FX options. When setting it to instruct fxMesa to
-  render windowed you may provide it a clue to your system's display, or
-  instruct it to try to detect the pixel format. This information is used
-  in constructing the windowed-rendering hack to try for optimal
-  performance, such as it is. You specify this by adding one of the
-  following tags in the envvar prefixed by a colon.
-
-    noconv    - does not do any pixel format conversion
-                This is synonymous to '16bgr'.
-    16bgr     - uses a 16-bit RGB sequenced dib section and does no pixel
-                format conversion as this is the internal format of the
-                3Dfx hardware when used by fxMesa.
-                This is synonymous to 'noconv'.
-    16rgb     - uses a 16-bit RGB sequenced dib section and does pixel
-                format conversion each frame from the 3Dfx internal format
-                to 5:6:5 RGB.
-    15rgb     - uses a 16-bit RGB sequenced dib section and does pixel
-                format conversion each frame from the 3Dfx internal format
-                to 5:5:5 RGB.
-    15bgr     - uses a 16-bit RGB sequenced dib section and does pixel
-                format conversion each frame from the 3Dfx internal format
-                to 5:5:5 RGB.
-    24rgb     - uses a 24-bit RGB sequenced dib section and does pixel
-                format conversion each frame from the 3Dfx internal format
-                to 8:8:8 RGB. Also suitable for a 32-bpp display.
-    24bgr     - uses a 24-bit BGR sequenced dib section and does pixel
-                format conversion each frame from the 3Dfx internal format
-                to 8:8:8 RGB. Also suitable for a 32-bpp display.
-    query     - Queries Windows for the displays pixel format and attempts
-                to adjust accordingly. This query is done by using
-                DirectDraw to allocate a "Primary" surface and then
-                checking what that surface's pixel format is (as the Win32
-                API for getting the pixel format from a window device or
-                screen device context is useless as far as I have been able
-                to determine).  This does *NOT* mean that fxMesa is now
-                requiring DDraw, however it will use it if found. This
-                prevents system incompatabilities with WinNT 4SP2 and
-                earlier systems.
-
-    Example, put this in your AUTOEXEC.BAT to have fxMesa detect a best
-    case match on context creation:
-
-         set MESA_WGL_FX=windowed:query
-
-    Additionally, if you wish to find out *what* it detected, you may add a
-    ":logged" to this which will cause it to create/append to a file named
-    FXMESAGL32.LOG whenever a context is created, e.g.:
-
-         set MESA_WGL_FX=windowed:query:logged
-
-    *** WARNING: Some display drivers/windows version combinations do not
-        support all of the possible DIB section formats that can be
-        requested, and thanks to Microsoft there is no way of detecting
-        (that I have yet discovered) that the requested DIB section will
-        not work and when it is utilized the application crashes.
-
-  Eventually I hope to incorporate support for DirectDraw Overlay surfaces
-  to facilitate less data crunch overhead when dealing with the in-window
-  hack. For example: if a primary display support overlays of BGR565
-  sequence then the data could be read from the 3Dfx framebuffer into a
-  DDraw "System Memory" or "Non-Local Video Memory" surface - both of which
-  actually reside in on-board DRAM (the latter in AGP space) which could
-  then be blitted/flipped in a much faster fashion than the current DIB
-  section handling.
-
-  The DIB section handling will always be the default, as that's much more
-  compatible since it utilizes GDI features sets that have more longevity
-  to them.
-
-*** Legalese
-
-These build files are provided as-is and are submitted to be included with
-the "Mesa 3-D Graphics Library" package as (currently) maintained by Brian
-Paul. These project build files are free software; you can redistribute it
-and/or modify it under the terms of the GNU Library General Public License
-as published by the Free Software Foundation; either version 2 of the
-License, or (at your option) any later version.
-
-These project files are distributed in the hope that they will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU Library
-General Public License for more details.
-
-You should have received a copy of the GNU Library General Public License
-along with this library; if not, write to the Free Software Foundation,
-Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
-
-*** Maintenance Responsiblity and Technical Support
-
-While these files are now part of the Mesa core distribution please do NOT
-contact Mr. Paul for help with them if you encounter problems as he can't
-help you (currently).  I will, however, attempt my straightforward best in
-assisting anyone with using these files on their system.  I can NOT
-guarantee instant responses owing to other responsiblities, but I do try
-dang hard to answer any mail w/in 24 hours.  I may be contacted at the
-above email address for the forseeable future.
-
--Ted
-mailto://tjump@spgs.com
-http://www.i21.com/~tjump
-
-*** General Information
-
-These build files facilitate convenient building of many variants of Mesa,
-both as static link libraries (including mesaglu) and as dynamic link
-libraries that in some cases may be used as "drop-in" replacements for
-OpenGL32.DLL on both Windows95 and Windows NT.
-
-The construction of the Win32 command-line build files and projects has
-been something of a pet project of mine, and is based upon my own
-"standard" Win32 build environment as supplied by the "nmake.mif" file.
-They have been tested under Windows95 OSR2, Windows NT 4.0SP3, and Windows
-NT 5.0 beta 1.  The libraries that they generated have been tested (via the
-demo programs) in a *limited* fashion on the above three systems, including
-the 3Dfx versions.
-
-The reason I went with command-line build environment instead of the more
-convenient IDE-based project files is for two reasons: 1. These appear to
-have some amount of portability between versions (the nmake syntax hasn't
-changed much since Microsoft C 7.0) while the IDE project files seem to
-change drastically each version. and 2. These are readable with any ascii
-editor and such are better self-documentation of the file relationships for
-more people such that it will facilitate supporting other Win32 compilers.
-
-While these files only deal with building for x86 targeted code it *should*
-be possible to add the necessary logic to them to build for the other MSVC
-supported CPU targets, I simply have no hardware to test them on nor the
-alternative compilers to build with.
-
-*** Prerequisites for use
-
-1. You must have a 32-bit Microsoft compiler installed. I have tested
-this with Visual C 5.0 (SP3) and Visual C 4.2, but with minor
-(possibly no) modification to the nmake.mak and nmake.mif files this
-sequence should work on Visual C 2.0 also. The workspace files
-(mesalib.dsw and mesademos-*.dsw) and their included project files
-(*.dsp) are specific to the DevStudio IDE - I have made no attempt at
-building a VC4 IDE project set as I do not use that any more.  Note
-that the VC workspace files NO LONGER use NORE are dependant upon the
-nmake.mak and nmake.mif files for construction of definition (*.DEF)
-and resource (*.RC) files.
-
-*** Visual C 4.x Users Warning ****
-
-Note that early editions of VC4 do NOT have header files current enough
-for use building this code base. If you are using VC4 you will either need
-to get an update to version 4.2 *or* you may download the Platform SDK
-directly from Microsoft's web site (www.microsoft.com) and update your
-build environment that way.
-
-*** Visual C 4.x Users Warning ****
-
-2. You must have the PATH, INCLUDE, and LIB environment variables set
-properly. With VC5 you can easily get this by executing the VCVARS32.BAT
-file that was created for you upon installation. It is found in the
-DevStudio\VC\BIN directory, wherever you installed DevStudio. VC4 provides
-a similar batch file in it's BIN directory also.
-
-3. (optional) If you're going to build for 3Dfx/Voodoo you will need to
-have previously installed the Glide SDK version 2.3 or later, if I
-recall. This may be retrieved from www.3dfx.com for no money and some
-download time. ;-) These build files assume that you have the Glide SDK
-added to the respective environment variables (LIB and INCLUDE).
-
-4. (optional) If you're going to build for S3/Virge you will need the S3
-Developers Toolkit which may be downloaded from www.s3.com for the price of
-registering on-line and some time. NOTE: I can build the s3mesa.dll file to
-completion, however the compilation of s3mesa.c currently generates a large
-amount of compiler warnings and between that and the fact that I can not at
-all test it I can make no claims to it's ability to execute.  Again, like
-the 3Dfx version before this, these build files assume you have the S3Dtk H
-and LIB files in the path of their respective environment variables.
-Note 2: As of Mesa3.0beta6 I have build files, both command-line and IDE,
-which should be able to build the s3mesa code base if it weren't for updates
-being required in the S3 DD code support (Mesa-3.0/src/s3 directory).
-
-I advise putting any include and lib files for secondary toolkits (Glide,
-S3Tk, whatever) in their respective environment variables *before* the
-Microsoft-assigned default values.
-
-*** FAQ: Frequenty Asked Questions and Other Important Information ***
-
-- When running the 3Dfx demos under Windows NT, they crash on exit, what's
-  up?
-
-  This is apparently a problem in Glide itself. The workaround is to go to
-  your C:\WINNT\SYSTEM32 directory and rename the file FXOEM2X.DLL to
-  FXOEM2X.DL_ to prevent Glide from loading and initializing it upon
-  startup.  This is known to be an issue with cards that do not have "TV
-  out" and is known to cause crashes on Diamond Monster II 8M and 3Dfx
-  Reference boards, all using 3Dfx Reference Drivers version 2.53. Other
-  hardware/driver combinations will also likely exhibit this behavior.
-
-- I'm having a problem building Mesa for static library linking.
-
-  This was caused by some incomplete testing on my part, and a fix is now
-  available in the form of an add-on to the base Mesa 3.0 release.  The
-  file to get is:
-
-       via FTP download from: iris.ssec.wisc.edu
-         you want to go here: /pub/Mesa/patches_to_3.0/
-        you want to get file: Mesa-3.0-w32-static-fixes.tar.gz
-
-  This required a minor addition to INCLUDE/GL for a clean solution, the
-  file "include/gl/mesa_wgl.h" is automatically included by
-  "include/gl/gl.h" when a Win32 non-DLL build is in progress to provide
-  prototypes for the various wgl functions.
-
-  The only remaining hitch in this setup is that the 3Dfx build is not yet
-  running as a static build, because of problems with conflicts in
-  existance of the various GDI functions like ChoosePixelFormat,
-  etc. *sigh*
-
-  Anyway, the "allstatic" target now works as expected and builds all
-  book/sample/demos programs to boot. ;^)
-
-- How do I get fxMesa to render in a window on the desktop instead of only
-  full-screen?
-
-  Use the Microsoft Windows fxMesa-in-a-window hack!
-
-  Seriously, if you want fxMesaGL to render using the 3Dfx Voodoo1 or
-  Voodoo2 hardware into a window on the desktop then all you need to do is
-  set the MESA_WGL_FX environment variable to anything other than
-  "fullscreen" and it will render into a window.  If you wish to go
-  fullscreen then you only need to NOT have the environment variable, or
-  have it set to "fullscreen".  You may also switch at runtime between
-  fullscreen-mode and windowed by pressing ALT-ENTER on the keyboard
-  (unless the application using Mesa does something with those keystrokes,
-  of course).
-
-  As of 8/13/98 this should be running a LOT better for more people as a
-  low-compatability item was cleaned up which prevented it from working on
-  many (most?) display drivers under Windows 9x.
-
-- I have my 3Dfx card hooked to it's own monitor and I want the output to
-  stay on even if I switch to another program, is this possible?
-
-  If the Glide environment variable SST_DUALHEAD is set to '1' then fxMesa
-  will never disable the Voodoo output on a Voodoo1 or Voodoo2 display
-  regardless of whether the fxMesa application is "current" or not. This
-  works regardless of whether it's rendering using the window hack
-  mentioned above or not.
-
-- I want to run the Mesa demos on my Intel740 card using it's own OpenGL
-  acceleration, how do I do this?
-
-  Build GLUT standalone for use with system OpenGL and GLU drivers!
-
-  The Command-line project supports building all test/demo programs against
-  these drivers also! This allows you full use of GLUT on Windows using
-  hardware accelerated OpenGL. Wheee! This includes the "3dfx/demos"
-  directory of which only two programs will not run on "standard"
-  opengl. Note that there are a few of the sample programs which will NOT
-  work without Mesa as they directly call into Mesa instead of using the
-  extension mechanism.
-
-*** Included programs that exhibit unfortunate or bad behavior
-
-- demos/bounce - doesn't run on high-colors screens?  It's requesting an
-  INDEX display from GLUT and that fails on my true-color desktop. Changing
-  this to _RGB let's the program work, but it doesn't display
-  properly. This is probably just an idiosyncracy of my machine though, as
-  if I test the program using GLUT for System OpenGL on my Intel740 OpenGL
-  accelerated machine it's just hunky-dory.
-
-- demos/glutfx - runs, but crashes on exit (but not on my Intel740 machine)
-
-- demos/texobj - runs, but crashes on exit if ESC is pressed. Exits cleanly
-  if the Close box on the window frame is pressed with the mouse. Go figure.
-
-- book/aaindex - doesn't run, can't get pixel format, because it wants an
-  INDEX display maybe (but is okay on my Intel740 machine)?
-
-- most of the book/* demos don't respond to ESC being pressed.
-
-- 3dfx/demos/* - all demos run, however they all crash on exit. I've traced
-  this so far as to determine the call it's happening with. The crash comes
-  from within Glide during the processing of the grGlideShutdown() call, as
-  in invalid memory reference exception. I'm wondering if this is because
-  of some state or processing not being completed before the call. Dunno,
-  but putting grSstIdle() in just before grGlideShutdown() does NOT fix the
-  problem.
-
-- 3dfx/demos/tunnel2 - does not run on my system even with SLI mode
-  disabled. Hmmmm, maybe I need to disconnect my Voodoo2 cards?
-
-*** Important Notes and Changing Default values
-
-- The optimizer settings have been manually reworked in both command line
-  and DevStudio IDE files to hopefully prevent possible irrational code on
-  the part of the code generator.  Formerly, it was configured for "/Ox",
-  now it is configured for safer handling at a slight potential performance
-  cost. This may not be required for Visual Studio 6 but I can't test that
-  (yet).
-
-- These files build with the code targeted for Pentium processors and
-  8-byte structure padding.
-
-- The IDE-built programs seem to be "happier" in that the command line
-  build of the 3Dfx demo "fire" will grenade on exit (?). Otherwise pretty
-  much everything may be built with either interface.
-
-- The currently configured Mesa version is 3.1, and MesaDemos version is
-  the same. To change this permanently you will need to edit NMAKE.MAK and
-  change the lines that look like this (they start o/a line 116):
-
-    # Currently, Mesa is at rev 3.1 ...
-    #
-    !IF "$(MESAVER)" == ""
-    MESAVER=3.1
-    !ENDIF
-
-    # used in building all of the resource files for the Mesa DLLs
-    #
-    !IF "$(MESAFILEVER)" == ""
-    MESAFILEVER=3,1,0,0
-    !ENDIF
-
-- Currently the build files are configured to be used from a Win32
-  directory that is included inside the main Mesa-3.1 heirarchy.
-
-- The build files are smart enough to find the files for the core lib, glu,
-  glut, and the various demo programs if they are unpacked in the current
-  Mesa-3.1 heirarchy, like this:
-
-    \Mesa-3.1
-    \Mesa-3.1\src
-    \Mesa-3.1\src-glu
-    \Mesa-3.1\src-glut
-    \Mesa-3.1\Win32
-    \Mesa-3.1\samples
-    \Mesa-3.1\demos
-    \Mesa-3.1\book
-    \Mesa-3.1\3Dfx\demos
-
-    ... should work.  This arose because my initial build tests for the
-    demo files were done before MesaDemos 2.6 had been released.
-
-- To enable use of MMX instructions by the VC5 compiler you may add the
-  "USE_MMX=1" option to the NMAKE command line, or edit the default in the
-  NMAKE.MAK file.  This does appear to have some affect on the performance
-  on the library and does not seem to harm it in any way *but* I have done
-  *no* verification of this. I have an MMX processor so I figured what the
-  heck. This option is only available with VC5 when building from the
-  command line.
-
-  This is probably required if you are going to modify the code to include
-  inline MMX instructions though.
-
-- With the exception of the static link libraries generated by this file
-  set (mesagl.lib, mesaglu.lib, mesaglut.lib) all DLLs and executables are
-  built against the "Multithreaded DLL" runtime - this means that they
-  require MSVCRT.DLL or MSVCRTD.DLL in the path to execute.
-
-  ** CHANGED 8/11/98 ***
-
-  Note also that the demos are all built aginst the "OpenGL32, GLU32, and
-  GLUT32" and as such they are fairly agnostic wrt: building against Mesa
-  for CPU-rendering, Mesa-for-3Dfx, Mesa-for-S3, or System OpenGL.
-
-  If you want to build them for use on your system and your display card
-  provides full OpenGL acceleration (Permedia, Intel740, Intergraph,
-  whatever) then you only need to build GLUT prior to building any of the
-  demo programs. For convenience, the GLUT project is included in each of
-  the demo projects Workspace files for the DevStudio IDE builds BUT it is
-  not automatically built - you still need to build it first manually.
-
-  Note that if you have GLUT already installed on your system (gl/glut.h in
-  yoru INCLUDE path, glut32.lib/glut32d.lib in your LIB path, and the DLL
-  in your PATH) then you do NOT need to build GLUT prior to the test
-  programs.
-
-- The 3Dfx build of Mesa has primarily been tested with Quake 2 and it runs
-  (mostly) fine on my PC (take that for what you want it)...
-
-  ** CHANGED  8/11/98 ***
-
-  There is still something going on that causes Glide to crash on shutdown,
-  when I run fxMesa under Windows NT, however it does not appear to occur
-  under Windows 9x on either Voodoo1 or Voodoo2 cards. *sigh*
-
-- I can not test the S3 build as I have no machines available with Virge
-  based display cards.
-
-- The multithreaded test code is *not* built as it requires pthreads and I
-  have as of yet spent not time trying to get that running. The latest word
-  that I saw WRT threading support on win32 was that they are intending to
-  support it natively within Win32 - so I'm waiting it out until they get
-  it done.
-
-- Similarly, the 'xdemos' are not currently built because I haven't gotten
-  around to building the client libs for native win32 and getting it all
-  setup for use.
-
-*** Output Files
-
-All final output files (DLL/LIB) are placed in the Mesa-3.1/lib directory,
-with the exception of the fxMesaGL32 build which is placed in
-Mesa-3./lib/FX and the executable images which are placed in their source
-directories.
-
-To be able to execute the various test programs, you will need to copy the
-requisite DLL files into the same directory as the EXE files. Note that
-most of the 3Dfx/demos/* programs WILL run with the non-FX build of Mesa -
-just very slowly. The two programs which are hard-linked with the FX build
-and will not run without it are "glbpaltx" which uses "gl3DfxSetPaletteEXT"
-directly instead of via the extensions mechanism and "tunnel2" which uses
-"fxMesaSelectCurrentBoard" API for selecting between multiple 3Dfx cards
-installed in one system. Likewise, "paltex" directly uses the
-"glColorTableEXT" extension and thus may not run on anything except
-Mesa. If these applications used the proper extension mechanism they could
-then be used on more than "just" fxMesa to good effect (for example, the
-rest of the "3Dfx/demos" run just peachy on the Intel740 card in my test
-machine) under WinNT.
-
-Because I'm anal about my computer and it's organization, and I like to
-prevent collision between builds, each of the subprojects has their own
-intermediate file directory inside .\win32\release (for example, when
-building mesagl.lib all of it's intermediate files will be found in
-.\win32\release\lib.mesagl).  This makes it very easy to cleanup as you
-only need to remove .\win32\release.
-
-*** Okay, Enough, how do I build with this stuff already Ted!
-
-Okay, no major calamity here. The basic way to use the project file is to
-call it via NMAKE from the command line. The format is:
-
-    nmake[.exe] /f nmake.mak [options] [target]
-
-The most likely [options] values you will use may be any combination of the
-following:
-
-    DEBUG=1 or DEBUG=0
-    USE_MMX=1 or USE_MMX=0
-    USE_CRTDLL=1 or USE_CRTDLL=0
-
-    Note that all three of these options are OFF by default.
-
-The [target] includes but is not limited to the following (for full details
-please peruse the NMAKE.MAK and NMAKE.MIF files - but be warned that
-NMAKE.MIF is rather large and sometimes hard to follow):
-
-    --- convenience targets ---
-
-    all                 - builds everything
-    libfiles            - builds all linking library files
-    progs               - builds all executable images
-
-    --- library files, static and dynamic ---
-
-    mesagl              - static lib build of Mesa core.
-    mesaglu             - static lib build of MesaGLU core.
-    mesaglut            - static lib build of Mesa GLUT core.
-
-    mesagl32            - dynamic lib build of Mesa core.
-
-    mesaglu32           - dynamic lib build of GLU core, generates
-                          GLU32.DLL and/or GLU32d.DLL.
-
-    mesaglut32          - dynamic lib build of GLUT core, generates
-                          GLUT32.DLL and/or GLUT32d.dll.
-
-    --- hardware accelerated mesa builds ---
-
-    fxmesagl32          - builds Mesa for use on top of the 3Dfx
-                          Glide runtime libs
-
-    s3mesagl32          - builds mesa for use on top of the S3
-                          'S3Tk' runtime libs.
-
-    --- executable images ---
-
-    progs.book          - builds all programs in \book directory
-    progs.demos         - builds all programs in \demos directory
-    progs.samples       - builds all programs in \samples directory
-
-        These targets generate all of the programs in their respective
-        directories and link the executables against OpenGL32.DLL,
-        GLU32.DLL, and GLUT32.DLL (or their debug equivalents).
-
-    progs.3dfx.demos    - builds all programs in \3dfx\demos directory
-
-        This target generates the 3Dfx/Demo executables, linking them
-        against GLUT32.DLL, GLU32.DLL, OPENGL32.DLL and are thus NOT
-        hard-bound to using Mesa per-se as you can simply NOT build the
-        Mesa core and GLU libraries.
-
-   --- Microsoft/SGI OpenGL-based GLUT and Demo program builds ----
-
-   *** IMPORTANT SAFETY TIP: If you're going to build these variants of
-       GLUT then DO NOT build any other target libraries in this package
-       first, OR from the command line run the "nmake /f nmake.mak clean"
-       command first!  This is because generation of the GLUT for SGI
-       OpenGL target libraries conflicts in naming with the static build
-       libraries of Mesa and it's supporting GLUT build.
-
-   Currently, you may build GLUT as either GLUT32.DLL or GLUT.DLL for
-   use running against either Microsoft or SGI OpenGL for Window,
-   respectively.  This allows for the general use of GLUT 3.7 on Windows
-   systems with fully compliant OpenGL.
-
-   You can build the GLUT DLL files either with the command line by
-   issuing either of these commands:
-
-        nmake /f nmake.mak glut.sysgl
-
-        <or>
-
-        nmake /f nmake.mak glut.sgigl
-
-   OR by using the DevStudio MesaLib Worksapce build the GLUT_SGIGL or
-   GLUT_SYSGL projects within the DevStudio IDE.
-
-   Unfortunately, the only way to build the test programs against this
-   build of GLUT is via the command line, and I will NOT be making
-   duplicate demo program projects for the IDE as it's just not worth it,
-   sorry.
-
-   To build the test programs against either MS or SGI OpenGL, you do so
-   via either of these two commands:
-
-        nmake /f nmake.mak progs.sysgl
-
-        <or>
-
-        nmake /f nmake.mak progs.sgigl
-
-   To use the GLUT-for-system-OpenGL in your own programs, you need to do
-   three things by way of preparation, after building GLUT of course:
-
-         1. Copy include\gl\glut.h to somewhere in your %INCLUDE% path, one
-            likely candidate location would be in your
-            "DevStudio\VC\INCLUDE\GL" directory.
-
-         2. Copy the linking libraries to somewhere in your %LIB% path, one
-            likely candidate location would be in your "DevStudio\VC\LIB"
-            directory. The linking libraries you need to copy are as
-            follows:
-
-                .\Release\GLUT32.LIB
-                .\Release\GLUT.LIB
-                .\Debug\GLUT32.LIB
-                .\Debug\GLUT.LIB
-
-        3. Copy the runtime libraries to somewhere in your %PATH%, one
-           likely candidate location would be in WINDOWS\SYSTEM. the files
-           that you should copy are as follows:
-
-                .\Release\GLUT32.DLL
-                .\Release\GLUT32.PDB
-                .\Release\GLUT.DLL
-                .\Release\GLUT.PDB
-                .\Debug\GLUT32d.DLL
-                .\Debug\GLUT32d.PDB
-                .\Debug\GLUTd.DLL
-                .\Debug\GLUTd.PDB
-
-Some examples are in order ...
-
-    ... build all dynamic-link libs using MSVCRT.DLL for C runtime:
-
-        nmake /f nmake.mak USE_CRTDLL=1 alldynamic
-
-    ... To build all library variants and all test and demonstration
-        programs with the default settings you do this:
-
-        nmake /f nmake.mak all
-
-    ... to build all static link libs and nothing else you do this:
-
-        nmake /f nmake.mak allstatic
-
-    ... to build all non-accelerated dynamic link libs you do this:
-
-        nmake /f nmake.mak alldynamic
-
-    ... to build all 3Dfx targeted dynamic link libs you do this:
-
-        nmake /f nmake.mak allaccel
-
-    ... to build all S3 Virge targetd dynamic link libs you do this:
-
-        nmake /f nmake.mak alls3
-
-    ... to build all libraries, static and dynamic, in all versions
-        you do this:
-
-        nmake /f nmake.mak libfiles
-
-    ... to subsequently build all demo and test programs you do this:
-
-        nmake /f nmake.mak progs
-
-    ... to cleanup all intermediate files you do this:
-
-        nmake /f clean
-
-You get the picture. (I hope) ;^)  You may also specify specify
-single targets in a convenient fashion. The rule is simple, any of the
-above named lib files, static or dynamic, may be built by providing it's
-name on the command line as the target. Examples:
-
-    ... to build only Mesa as OpenGL32.DLL ...
-
-        nmake /f nmake.mak opengl32
-
-    ... to build only Mesa on top of the 3Dfx Glide API ...
-
-        nmake /f nmake.mak fxMesaGL32
-              <or>
-        nmake /f nmake.mak fxMesaGL
-
-    ... to build only Mesa on top of the S3 Toolkit ...
-
-        nmake /f nmake.mak s3MesaGL32
-              <or>
-        nmake /f nmake.mak s3mesaGL
-
-*** Revision history for ./win32 project files
-
-1/18/98 - initial cut submitted and included with core mesa
-2/5/98  - fixed internal dependency within nmake.mif upon there being
-          a $(DEVDIR) variable to make some temporary batch files
-          dependant upon (thanks to Keven T. McDonnell for finding
-          that there was this particular bug). I also updated the
-          build files for 2.6beta6.
-2/8/98  - added DevStudio workspace and project files for all lib
-          files and some test programs. Updated readme.win32.
-6/25/98 - initial revision for Mesa 3.0, does not include IDE files,
-          not everything is running. *sigh*
-7/20/98 - Mesa 3.0beta6 rev of all build files, all libs built and
-          minimally tested, all demo programs built and minimally
-          tested to within limits of my PC. ;^) Eveything looks
-          MUCH better now ...
-7/30/98 - Minor updates/edits based upon feedback from
-          Eero Pajarre <epajarre@koti.tpo.fi>. These updates include a fix
-          to the Mesa-on-3Dfx build such that Quake-II now runs almost
-          properly on my system. It runs, just *very* slowly and with *no*
-          textures. Hmmm. Doesn't make any difference whether Quake is set
-          to use 8-bit textures or not.
-8/13/98 - Lots of build cleanups, minor bug fixes in fxwgl.c, and
-          compatability fix in fxapi.c for in-window rendering using 3Dfx
-          hardware.
-8/26/98 - Final revisions for Mesa 3 release checked
-9/22/98 - Fixed static builds for all but fxMesaGL32 and s3MesaGL32 targets
-9/29/98 - Reorganized FAQ information and added Added faq entry about Glide
-          bug under NT (crash on exit) and a workaround.
-11/21/98 - Updated files for Mesa 3.1 beta 1
-           Updated fxMesa window-hack code
-           Updated fxMesa resolution support to handle 1600x1200 & 1280x1024
+

+    Mesa/Readme.win32

+

+    Last Updated: Friday, July 9th, 1999 - tjump@tertius.com

+

+*** What's New

+

+- Updated for Mesa 3.1beta2/CVS.

+

+- DevStudio projects suspended for compatability reasons: projects modified

+  by DevStudio 6 are not compatible with DevStudio 5.

+

+- Build environment change: The Glide SDK is no longer assumed to be in

+  the global INCLUDE/LIB environment vars, it is required that you set the

+  value 'GLIDE2X' as either an environment variable pointing to your Glide

+  SDK install directory or that you configure that as a build option to

+  nmake.exe when building fxmesagl32.  Examples:

+

+    nmake /f nmake.mak GLIDE2X=g:\sdk\glide2x fxmesagl32

+

+          <or>

+

+    nmake /f nmake.mak GLIDE2X=g:\sdk\glide2x allfx

+

+          <or>

+

+    nmake /f nmake.mak GLIDE2X=g:\sdk\glide2x progs.3dfx.demos

+

+  The DevStudio workspace files for 3Dfx OpenGL require the definition of

+  GLIDE2SDK as an environment variable pointing to where your copy of the

+  Glide SDK has been installed. Adding this to your AUTOEXEC.BAT would do

+  so (change the directories to match):

+

+       SET GLIDE2SDK=G:\SDK\GLIDE2X

+

+*** Legalese

+

+These build files are provided as-is and are submitted to be included with

+the "Mesa 3-D Graphics Library" package as (currently) maintained by Brian

+Paul. These project build files are free software; you can redistribute it

+and/or modify it under the terms of the GNU Library General Public License

+as published by the Free Software Foundation; either version 2 of the

+License, or (at your option) any later version.

+

+These project files are distributed in the hope that they will be useful,

+but WITHOUT ANY WARRANTY; without even the implied warranty of

+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU Library

+General Public License for more details.

+

+You should have received a copy of the GNU Library General Public License

+along with this library; if not, write to the Free Software Foundation,

+Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

+

+*** Maintenance Responsiblity and Technical Support

+

+While these files are now part of the Mesa core distribution please do NOT

+contact Mr. Paul for help with them if you encounter problems as he can't

+help you (currently).  I will, however, attempt my straightforward best in

+assisting anyone with using these files on their system.  I can NOT

+guarantee instant responses owing to other responsiblities, but I do try

+dang hard to answer any mail w/in 24 hours.  I may be contacted at the

+above email address for the forseeable future.

+

+-Ted

+mailto://tjump@tertius.com

+http://www.tertius.com/tjump

+

+*** General Information

+

+These build files facilitate convenient building of many variants of Mesa,

+both as static link libraries (including mesaglu) and as dynamic link

+libraries that in some cases may be used as "drop-in" replacements for

+OpenGL32.DLL on both Windows95 and Windows NT.

+

+The construction of the Win32 command-line build files and projects has

+been something of a pet project of mine, and is based upon my own

+"standard" Win32 build environment as supplied by the "nmake.mif" file.

+They have been tested under Windows95 OSR2, Windows NT 4.0SP3, and Windows

+NT 5.0 beta 1.  The libraries that they generated have been tested (via the

+demo programs) in a *limited* fashion on the above three systems, including

+the 3Dfx versions.

+

+The reason I went with command-line build environment instead of the more

+convenient IDE-based project files is for two reasons: 1. These appear to

+have some amount of portability between versions (the nmake syntax hasn't

+changed much since Microsoft C 7.0) while the IDE project files seem to

+change drastically each version. and 2. These are readable with any ascii

+editor and such are better self-documentation of the file relationships for

+more people such that it will facilitate supporting other Win32 compilers.

+

+While these files only deal with building for x86 targeted code it *should*

+be possible to add the necessary logic to them to build for the other MSVC

+supported CPU targets, I simply have no hardware to test them on nor the

+alternative compilers to build with.

+

+*** Prerequisites for use

+

+1. You must have a 32-bit Microsoft compiler installed. I have tested

+this with Visual C 5.0 (SP3) and Visual C 4.2, but with minor

+(possibly no) modification to the nmake.mak and nmake.mif files this

+sequence should work on Visual C 2.0 also. The workspace files

+(mesalib.dsw and mesademos-*.dsw) and their included project files

+(*.dsp) are specific to the DevStudio IDE - I have made no attempt at

+building a VC4 IDE project set as I do not use that any more.  Note

+that the VC workspace files NO LONGER use NORE are dependant upon the

+nmake.mak and nmake.mif files for construction of definition (*.DEF)

+and resource (*.RC) files.

+

+*** Visual C 4.x Users Warning ****

+

+Note that early editions of VC4 do NOT have header files current enough

+for use building this code base. If you are using VC4 you will either need

+to get an update to version 4.2 *or* you may download the Platform SDK

+directly from Microsoft's web site (www.microsoft.com) and update your

+build environment that way.

+

+*** Visual C 4.x Users Warning ****

+

+2. You must have the PATH, INCLUDE, and LIB environment variables set

+properly. With VC5 you can easily get this by executing the VCVARS32.BAT

+file that was created for you upon installation. It is found in the

+DevStudio\VC\BIN directory, wherever you installed DevStudio. VC4 provides

+a similar batch file in it's BIN directory also.

+

+3. (optional) If you're going to build for 3Dfx/Voodoo you will need to

+have previously installed the Glide SDK version 2.3 or later, if I

+recall. This may be retrieved from www.3dfx.com for no money and some

+download time. ;-) These build files assume that you have the Glide SDK

+added to the respective environment variables (LIB and INCLUDE).

+

+4. (optional) If you're going to build for S3/Virge you will need the S3

+Developers Toolkit which may be downloaded from www.s3.com for the price of

+registering on-line and some time. NOTE: I can build the s3mesa.dll file to

+completion, however the compilation of s3mesa.c currently generates a large

+amount of compiler warnings and between that and the fact that I can not at

+all test it I can make no claims to it's ability to execute.  Again, like

+the 3Dfx version before this, these build files assume you have the S3Dtk H

+and LIB files in the path of their respective environment variables.

+Note 2: As of Mesa3.0beta6 I have build files, both command-line and IDE,

+which should be able to build the s3mesa code base if it weren't for updates

+being required in the S3 DD code support (Mesa-3.0/src/s3 directory).

+

+I advise putting any include and lib files for secondary toolkits (Glide,

+S3Tk, whatever) in their respective environment variables *before* the

+Microsoft-assigned default values.

+

+*** FAQ: Frequenty Asked Questions and Other Important Information ***

+

+- When running the 3Dfx demos under Windows NT, they crash on exit, what's

+  up?

+

+  This is apparently a problem in Glide itself. The workaround is to go to

+  your C:\WINNT\SYSTEM32 directory and rename the file FXOEM2X.DLL to

+  FXOEM2X.DL_ to prevent Glide from loading and initializing it upon

+  startup.  This is known to be an issue with cards that do not have "TV

+  out" and is known to cause crashes on Diamond Monster II 8M and 3Dfx

+  Reference boards, all using 3Dfx Reference Drivers version 2.53. Other

+  hardware/driver combinations will also likely exhibit this behavior.

+

+- I'm having a problem building Mesa for static library linking.

+

+  This was caused by some incomplete testing on my part, and a fix is now

+  available in the form of an add-on to the base Mesa 3.0 release.  The

+  file to get is:

+

+       via FTP download from: iris.ssec.wisc.edu

+         you want to go here: /pub/Mesa/patches_to_3.0/

+        you want to get file: Mesa-3.0-w32-static-fixes.tar.gz

+

+  This required a minor addition to INCLUDE/GL for a clean solution, the

+  file "include/gl/mesa_wgl.h" is automatically included by

+  "include/gl/gl.h" when a Win32 non-DLL build is in progress to provide

+  prototypes for the various wgl functions.

+

+  The only remaining hitch in this setup is that the 3Dfx build is not yet

+  running as a static build, because of problems with conflicts in

+  existance of the various GDI functions like ChoosePixelFormat,

+  etc. *sigh*

+

+  Anyway, the "allstatic" target now works as expected and builds all

+  book/sample/demos programs to boot. ;^)

+

+- How do I get fxMesa to render in a window on the desktop instead of only

+  full-screen?

+

+  Use the Microsoft Windows fxMesa-in-a-window hack!

+

+  Seriously, if you want fxMesaGL to render using the 3Dfx Voodoo1 or

+  Voodoo2 hardware into a window on the desktop then all you need to do is

+  set the MESA_WGL_FX environment variable to anything other than

+  "fullscreen" and it will render into a window.  If you wish to go

+  fullscreen then you only need to NOT have the environment variable, or

+  have it set to "fullscreen".  You may also switch at runtime between

+  fullscreen-mode and windowed by pressing ALT-ENTER on the keyboard

+  (unless the application using Mesa does something with those keystrokes,

+  of course).

+

+  As of 8/13/98 this should be running a LOT better for more people as a

+  low-compatability item was cleaned up which prevented it from working on

+  many (most?) display drivers under Windows 9x.

+

+- I have my 3Dfx card hooked to it's own monitor and I want the output to

+  stay on even if I switch to another program, is this possible?

+

+  If the Glide environment variable SST_DUALHEAD is set to '1' then fxMesa

+  will never disable the Voodoo output on a Voodoo1 or Voodoo2 display

+  regardless of whether the fxMesa application is "current" or not. This

+  works regardless of whether it's rendering using the window hack

+  mentioned above or not.

+

+- I want to run the Mesa demos on my Intel740 card using it's own OpenGL

+  acceleration, how do I do this?

+

+  Build GLUT standalone for use with system OpenGL and GLU drivers!

+

+  The Command-line project supports building all test/demo programs against

+  these drivers also! This allows you full use of GLUT on Windows using

+  hardware accelerated OpenGL. Wheee! This includes the "3dfx/demos"

+  directory of which only two programs will not run on "standard"

+  opengl. Note that there are a few of the sample programs which will NOT

+  work without Mesa as they directly call into Mesa instead of using the

+  extension mechanism.

+

+*** Included programs that exhibit unfortunate or bad behavior

+

+- demos/bounce - doesn't run on high-colors screens?  It's requesting an

+  INDEX display from GLUT and that fails on my true-color desktop. Changing

+  this to _RGB let's the program work, but it doesn't display

+  properly. This is probably just an idiosyncracy of my machine though, as

+  if I test the program using GLUT for System OpenGL on my Intel740 OpenGL

+  accelerated machine it's just hunky-dory.

+

+- demos/glutfx - runs, but crashes on exit (but not on my Intel740 machine)

+

+- demos/texobj - runs, but crashes on exit if ESC is pressed. Exits cleanly

+  if the Close box on the window frame is pressed with the mouse. Go figure.

+

+- book/aaindex - doesn't run, can't get pixel format, because it wants an

+  INDEX display maybe (but is okay on my Intel740 machine)?

+

+- most of the book/* demos don't respond to ESC being pressed.

+

+- 3dfx/demos/* - all demos run, however they all crash on exit. I've traced

+  this so far as to determine the call it's happening with. The crash comes

+  from within Glide during the processing of the grGlideShutdown() call, as

+  in invalid memory reference exception. I'm wondering if this is because

+  of some state or processing not being completed before the call. Dunno,

+  but putting grSstIdle() in just before grGlideShutdown() does NOT fix the

+  problem.

+

+- 3dfx/demos/tunnel2 - does not run on my system even with SLI mode

+  disabled. Hmmmm, maybe I need to disconnect my Voodoo2 cards?

+

+*** Important Notes and Changing Default values

+

+- The optimizer settings have been manually reworked in both command line

+  and DevStudio IDE files to hopefully prevent possible irrational code on

+  the part of the code generator.  Formerly, it was configured for "/Ox",

+  now it is configured for safer handling at a slight potential performance

+  cost. This may not be required for Visual Studio 6 but I can't test that

+  (yet).

+

+- These files build with the code targeted for Pentium processors and

+  8-byte structure padding.

+

+- The IDE-built programs seem to be "happier" in that the command line

+  build of the 3Dfx demo "fire" will grenade on exit (?). Otherwise pretty

+  much everything may be built with either interface.

+

+- The currently configured Mesa version is 3.1, and MesaDemos version is

+  the same. To change this permanently you will need to edit NMAKE.MAK and

+  change the lines that look like this (they start o/a line 116):

+

+    # Currently, Mesa is at rev 3.1 ...

+    #

+    !IF "$(MESAVER)" == ""

+    MESAVER=3.1

+    !ENDIF

+

+    # used in building all of the resource files for the Mesa DLLs

+    #

+    !IF "$(MESAFILEVER)" == ""

+    MESAFILEVER=3,1,0,0

+    !ENDIF

+

+- Currently the build files are configured to be used from a Win32

+  directory that is included inside the main Mesa-3.1 heirarchy.

+

+- The build files are smart enough to find the files for the core lib, glu,

+  glut, and the various demo programs if they are unpacked in the current

+  Mesa-3.1 heirarchy, like this:

+

+    \Mesa-3.1

+    \Mesa-3.1\src

+    \Mesa-3.1\src-glu

+    \Mesa-3.1\src-glut

+    \Mesa-3.1\Win32

+    \Mesa-3.1\samples

+    \Mesa-3.1\demos

+    \Mesa-3.1\book

+    \Mesa-3.1\3Dfx\demos

+

+    ... should work.  This arose because my initial build tests for the

+    demo files were done before MesaDemos 2.6 had been released.

+

+- With the exception of the static link libraries generated by this file

+  set (mesagl.lib, mesaglu.lib, mesaglut.lib) all DLLs and executables are

+  built against the "Multithreaded DLL" runtime - this means that they

+  require MSVCRT.DLL or MSVCRTD.DLL in the path to execute.

+

+  ** CHANGED 8/11/98 ***

+

+  Note also that the demos are all built aginst the "OpenGL32, GLU32, and

+  GLUT32" and as such they are fairly agnostic wrt: building against Mesa

+  for CPU-rendering, Mesa-for-3Dfx, Mesa-for-S3, or System OpenGL.

+

+  If you want to build them for use on your system and your display card

+  provides full OpenGL acceleration (Permedia, Intel740, Intergraph,

+  whatever) then you only need to build GLUT prior to building any of the

+  demo programs. For convenience, the GLUT project is included in each of

+  the demo projects Workspace files for the DevStudio IDE builds BUT it is

+  not automatically built - you still need to build it first manually.

+

+  Note that if you have GLUT already installed on your system (gl/glut.h in

+  yoru INCLUDE path, glut32.lib/glut32d.lib in your LIB path, and the DLL

+  in your PATH) then you do NOT need to build GLUT prior to the test

+  programs.

+

+- The 3Dfx build of Mesa has primarily been tested with Quake 2 and it runs

+  (mostly) fine on my PC (take that for what you want it)...

+

+  ** CHANGED  8/11/98 ***

+

+  There is still something going on that causes Glide to crash on shutdown,

+  when I run fxMesa under Windows NT, however it does not appear to occur

+  under Windows 9x on either Voodoo1 or Voodoo2 cards. *sigh*

+

+- I can not test the S3 build as I have no machines available with Virge

+  based display cards.

+

+- The multithreaded test code is *not* built as it requires pthreads and I

+  have as of yet spent not time trying to get that running. The latest word

+  that I saw WRT threading support on win32 was that they are intending to

+  support it natively within Win32 - so I'm waiting it out until they get

+  it done.

+

+- Similarly, the 'xdemos' are not currently built because I haven't gotten

+  around to building the client libs for native win32 and getting it all

+  setup for use.

+

+*** Output Files

+

+All final output files (DLL/LIB) are placed in the Mesa-3.1/lib directory,

+with the exception of the fxMesaGL32 build which is placed in

+Mesa-3./lib/FX and the executable images which are placed in their source

+directories.

+

+To be able to execute the various test programs, you will need to copy the

+requisite DLL files into the same directory as the EXE files. Note that

+most of the 3Dfx/demos/* programs WILL run with the non-FX build of Mesa -

+just very slowly. The two programs which are hard-linked with the FX build

+and will not run without it are "glbpaltx" which uses "gl3DfxSetPaletteEXT"

+directly instead of via the extensions mechanism and "tunnel2" which uses

+"fxMesaSelectCurrentBoard" API for selecting between multiple 3Dfx cards

+installed in one system. Likewise, "paltex" directly uses the

+"glColorTableEXT" extension and thus may not run on anything except

+Mesa. If these applications used the proper extension mechanism they could

+then be used on more than "just" fxMesa to good effect (for example, the

+rest of the "3Dfx/demos" run just peachy on the Intel740 card in my test

+machine) under WinNT.

+

+Because I'm anal about my computer and it's organization, and I like to

+prevent collision between builds, each of the subprojects has their own

+intermediate file directory inside .\win32\release (for example, when

+building mesagl.lib all of it's intermediate files will be found in

+.\win32\release\lib.mesagl).  This makes it very easy to cleanup as you

+only need to remove .\win32\release.

+

+*** Okay, Enough, how do I build with this stuff already Ted!

+

+Okay, no major calamity here. The basic way to use the project file is to

+call it via NMAKE from the command line. The format is:

+

+    nmake[.exe] /f nmake.mak [options] [target]

+

+The most likely [options] values you will use may be any combination of the

+following:

+

+    DEBUG=1 or DEBUG=0

+    USE_CRTDLL=1 or USE_CRTDLL=0

+

+    Note that all three of these options are OFF by default.

+

+The [target] includes but is not limited to the following (for full details

+please peruse the NMAKE.MAK and NMAKE.MIF files - but be warned that

+NMAKE.MIF is rather large and sometimes hard to follow):

+

+    --- convenience targets ---

+

+    all                 - builds everything

+    libfiles            - builds all linking library files

+    progs               - builds all executable images

+

+    --- library files, static and dynamic ---

+

+    mesagl              - static lib build of Mesa core.

+    mesaglu             - static lib build of MesaGLU core.

+    mesaglut            - static lib build of Mesa GLUT core.

+

+    mesagl32            - dynamic lib build of Mesa core.

+

+    mesaglu32           - dynamic lib build of GLU core, generates

+                          GLU32.DLL and/or GLU32d.DLL.

+

+    mesaglut32          - dynamic lib build of GLUT core, generates

+                          GLUT32.DLL and/or GLUT32d.dll.

+

+    --- hardware accelerated mesa builds ---

+

+    fxmesagl32          - builds Mesa for use on top of the 3Dfx

+                          Glide runtime libs

+

+    s3mesagl32          - builds mesa for use on top of the S3

+                          'S3Tk' runtime libs.

+

+    --- executable images ---

+

+    progs.book          - builds all programs in \book directory

+    progs.demos         - builds all programs in \demos directory

+    progs.samples       - builds all programs in \samples directory

+

+        These targets generate all of the programs in their respective

+        directories and link the executables against OpenGL32.DLL,

+        GLU32.DLL, and GLUT32.DLL (or their debug equivalents).

+

+    progs.3dfx.demos    - builds all programs in \3dfx\demos directory

+

+        This target generates the 3Dfx/Demo executables, linking them

+        against GLUT32.DLL, GLU32.DLL, OPENGL32.DLL and are thus NOT

+        hard-bound to using Mesa per-se as you can simply NOT build the

+        Mesa core and GLU libraries.

+

+   --- Microsoft/SGI OpenGL-based GLUT and Demo program builds ----

+

+   *** IMPORTANT SAFETY TIP: If you're going to build these variants of

+       GLUT then DO NOT build any other target libraries in this package

+       first, OR from the command line run the "nmake /f nmake.mak clean"

+       command first!  This is because generation of the GLUT for SGI

+       OpenGL target libraries conflicts in naming with the static build

+       libraries of Mesa and it's supporting GLUT build.

+

+   Currently, you may build GLUT as either GLUT32.DLL or GLUT.DLL for

+   use running against either Microsoft or SGI OpenGL for Window,

+   respectively.  This allows for the general use of GLUT 3.7 on Windows

+   systems with fully compliant OpenGL.

+

+   You can build the GLUT DLL files either with the command line by

+   issuing either of these commands:

+

+        nmake /f nmake.mak glut.sysgl

+

+        <or>

+

+        nmake /f nmake.mak glut.sgigl

+

+   OR by using the DevStudio MesaLib Worksapce build the GLUT_SGIGL or

+   GLUT_SYSGL projects within the DevStudio IDE.

+

+   Unfortunately, the only way to build the test programs against this

+   build of GLUT is via the command line, and I will NOT be making

+   duplicate demo program projects for the IDE as it's just not worth it,

+   sorry.

+

+   To build the test programs against either MS or SGI OpenGL, you do so

+   via either of these two commands:

+

+        nmake /f nmake.mak progs.sysgl

+

+        <or>

+

+        nmake /f nmake.mak progs.sgigl

+

+   To use the GLUT-for-system-OpenGL in your own programs, you need to do

+   three things by way of preparation, after building GLUT of course:

+

+         1. Copy include\gl\glut.h to somewhere in your %INCLUDE% path, one

+            likely candidate location would be in your

+            "DevStudio\VC\INCLUDE\GL" directory.

+

+         2. Copy the linking libraries to somewhere in your %LIB% path, one

+            likely candidate location would be in your "DevStudio\VC\LIB"

+            directory. The linking libraries you need to copy are as

+            follows:

+

+                .\Release\GLUT32.LIB

+                .\Release\GLUT.LIB

+                .\Debug\GLUT32.LIB

+                .\Debug\GLUT.LIB

+

+        3. Copy the runtime libraries to somewhere in your %PATH%, one

+           likely candidate location would be in WINDOWS\SYSTEM. the files

+           that you should copy are as follows:

+

+                .\Release\GLUT32.DLL

+                .\Release\GLUT32.PDB

+                .\Release\GLUT.DLL

+                .\Release\GLUT.PDB

+                .\Debug\GLUT32d.DLL

+                .\Debug\GLUT32d.PDB

+                .\Debug\GLUTd.DLL

+                .\Debug\GLUTd.PDB

+

+Some examples are in order ...

+

+    ... build all dynamic-link libs using MSVCRT.DLL for C runtime:

+

+        nmake /f nmake.mak USE_CRTDLL=1 alldynamic

+

+    ... To build all library variants and all test and demonstration

+        programs with the default settings you do this:

+

+        nmake /f nmake.mak all

+

+    ... to build all static link libs and nothing else you do this:

+

+        nmake /f nmake.mak allstatic

+

+    ... to build all non-accelerated dynamic link libs you do this:

+

+        nmake /f nmake.mak alldynamic

+

+    ... to build all 3Dfx targeted dynamic link libs you do this:

+

+        nmake /f nmake.mak allaccel

+

+    ... to build all S3 Virge targetd dynamic link libs you do this:

+

+        nmake /f nmake.mak alls3

+

+    ... to build all libraries, static and dynamic, in all versions

+        you do this:

+

+        nmake /f nmake.mak libfiles

+

+    ... to subsequently build all demo and test programs you do this:

+

+        nmake /f nmake.mak progs

+

+    ... to cleanup all intermediate files you do this:

+

+        nmake /f clean

+

+You get the picture. (I hope) ;^)  You may also specify specify

+single targets in a convenient fashion. The rule is simple, any of the

+above named lib files, static or dynamic, may be built by providing it's

+name on the command line as the target. Examples:

+

+    ... to build only Mesa as OpenGL32.DLL ...

+

+        nmake /f nmake.mak opengl32

+

+    ... to build only Mesa on top of the 3Dfx Glide API ...

+

+        nmake /f nmake.mak fxMesaGL32

+              <or>

+        nmake /f nmake.mak fxMesaGL

+

+    ... to build only Mesa on top of the S3 Toolkit ...

+

+        nmake /f nmake.mak s3MesaGL32

+              <or>

+        nmake /f nmake.mak s3mesaGL

+

+*** Revision history for ./win32 project files

+

+1/18/98 - initial cut submitted and included with core mesa

+2/5/98  - fixed internal dependency within nmake.mif upon there being

+          a $(DEVDIR) variable to make some temporary batch files

+          dependant upon (thanks to Keven T. McDonnell for finding

+          that there was this particular bug). I also updated the

+          build files for 2.6beta6.

+2/8/98  - added DevStudio workspace and project files for all lib

+          files and some test programs. Updated readme.win32.

+6/25/98 - initial revision for Mesa 3.0, does not include IDE files,

+          not everything is running. *sigh*

+7/20/98 - Mesa 3.0beta6 rev of all build files, all libs built and

+          minimally tested, all demo programs built and minimally

+          tested to within limits of my PC. ;^) Eveything looks

+          MUCH better now ...

+7/30/98 - Minor updates/edits based upon feedback from

+          Eero Pajarre <epajarre@koti.tpo.fi>. These updates include a fix

+          to the Mesa-on-3Dfx build such that Quake-II now runs almost

+          properly on my system. It runs, just *very* slowly and with *no*

+          textures. Hmmm. Doesn't make any difference whether Quake is set

+          to use 8-bit textures or not.

+8/13/98 - Lots of build cleanups, minor bug fixes in fxwgl.c, and

+          compatability fix in fxapi.c for in-window rendering using 3Dfx

+          hardware.

+8/26/98 - Final revisions for Mesa 3 release checked

+9/22/98 - Fixed static builds for all but fxMesaGL32 and s3MesaGL32 targets

+9/29/98 - Reorganized FAQ information and added Added faq entry about Glide

+          bug under NT (crash on exit) and a workaround.

+11/21/98 - Updated files for Mesa 3.1 beta 1

+           Updated fxMesa window-hack code

+           Updated fxMesa resolution support to handle 1600x1200 & 1280x1024

+7/9/99  - Rev'd for Mesa 3.1 beta 2
\ No newline at end of file