-The reason I went with command-line build environment instead of the more\r
-convenient IDE-based project files is for two reasons: 1. These appear to\r
-have some amount of portability between versions (the nmake syntax hasn't\r
-changed much since Microsoft C 7.0) while the IDE project files seem to\r
-change drastically each version. and 2. These are readable with any ascii\r
-editor and such are better self-documentation of the file relationships for\r
-more people such that it will facilitate supporting other Win32 compilers.\r
-\r
-While these files only deal with building for x86 targeted code it *should*\r
-be possible to add the necessary logic to them to build for the other MSVC\r
-supported CPU targets, I simply have no hardware to test them on nor the\r
-alternative compilers to build with.\r
-\r
-*** Prerequisites for use\r
-\r
-1. You must have a 32-bit Microsoft compiler installed. I have tested\r
-this with Visual C 5.0 (SP3) and Visual C 4.2, but with minor\r
-(possibly no) modification to the nmake.mak and nmake.mif files this\r
-sequence should work on Visual C 2.0 also. The workspace files\r
-(mesalib.dsw and mesademos-*.dsw) and their included project files\r
-(*.dsp) are specific to the DevStudio IDE - I have made no attempt at\r
-building a VC4 IDE project set as I do not use that any more. Note\r
-that the VC workspace files NO LONGER use NORE are dependant upon the\r
-nmake.mak and nmake.mif files for construction of definition (*.DEF)\r
-and resource (*.RC) files.\r
-\r
-*** Visual C 4.x Users Warning ****\r
-\r
-Note that early editions of VC4 do NOT have header files current enough\r
-for use building this code base. If you are using VC4 you will either need\r
-to get an update to version 4.2 *or* you may download the Platform SDK\r
-directly from Microsoft's web site (www.microsoft.com) and update your\r
-build environment that way.\r
-\r
-*** Visual C 4.x Users Warning ****\r
-\r
-2. You must have the PATH, INCLUDE, and LIB environment variables set\r
-properly. With VC5 you can easily get this by executing the VCVARS32.BAT\r
-file that was created for you upon installation. It is found in the\r
-DevStudio\VC\BIN directory, wherever you installed DevStudio. VC4 provides\r
-a similar batch file in it's BIN directory also.\r
-\r
-3. (optional) If you're going to build for 3Dfx/Voodoo you will need to\r
-have previously installed the Glide SDK version 2.3 or later, if I\r
-recall. This may be retrieved from www.3dfx.com for no money and some\r
-download time. ;-) These build files assume that you have the Glide SDK\r
-added to the respective environment variables (LIB and INCLUDE).\r
-\r
-4. (optional) If you're going to build for S3/Virge you will need the S3\r
-Developers Toolkit which may be downloaded from www.s3.com for the price of\r
-registering on-line and some time. NOTE: I can build the s3mesa.dll file to\r
-completion, however the compilation of s3mesa.c currently generates a large\r
-amount of compiler warnings and between that and the fact that I can not at\r
-all test it I can make no claims to it's ability to execute. Again, like\r
-the 3Dfx version before this, these build files assume you have the S3Dtk H\r
-and LIB files in the path of their respective environment variables.\r
-Note 2: As of Mesa3.0beta6 I have build files, both command-line and IDE,\r
-which should be able to build the s3mesa code base if it weren't for updates\r
-being required in the S3 DD code support (Mesa-3.0/src/s3 directory).\r
-\r
-I advise putting any include and lib files for secondary toolkits (Glide,\r
-S3Tk, whatever) in their respective environment variables *before* the\r
-Microsoft-assigned default values.\r
-\r
-*** FAQ: Frequenty Asked Questions and Other Important Information ***\r
-\r
-- When running the 3Dfx demos under Windows NT, they crash on exit, what's\r
- up?\r
-\r
- This is apparently a problem in Glide itself. The workaround is to go to\r
- your C:\WINNT\SYSTEM32 directory and rename the file FXOEM2X.DLL to\r
- FXOEM2X.DL_ to prevent Glide from loading and initializing it upon\r
- startup. This is known to be an issue with cards that do not have "TV\r
- out" and is known to cause crashes on Diamond Monster II 8M and 3Dfx\r
- Reference boards, all using 3Dfx Reference Drivers version 2.53. Other\r
- hardware/driver combinations will also likely exhibit this behavior.\r
-\r
-- I'm having a problem building Mesa for static library linking.\r
-\r
- This was caused by some incomplete testing on my part, and a fix is now\r
- available in the form of an add-on to the base Mesa 3.0 release. The\r
- file to get is:\r
-\r
- via FTP download from: iris.ssec.wisc.edu\r
- you want to go here: /pub/Mesa/patches_to_3.0/\r
- you want to get file: Mesa-3.0-w32-static-fixes.tar.gz\r
-\r
- This required a minor addition to INCLUDE/GL for a clean solution, the\r
- file "include/gl/mesa_wgl.h" is automatically included by\r
- "include/gl/gl.h" when a Win32 non-DLL build is in progress to provide\r
- prototypes for the various wgl functions.\r
-\r
- The only remaining hitch in this setup is that the 3Dfx build is not yet\r
- running as a static build, because of problems with conflicts in\r
- existance of the various GDI functions like ChoosePixelFormat,\r
- etc. *sigh*\r
-\r
- Anyway, the "allstatic" target now works as expected and builds all\r
- book/sample/demos programs to boot. ;^)\r
-\r
-- How do I get fxMesa to render in a window on the desktop instead of only\r
- full-screen?\r
-\r
- Use the Microsoft Windows fxMesa-in-a-window hack!\r
-\r
- Seriously, if you want fxMesaGL to render using the 3Dfx Voodoo1 or\r
- Voodoo2 hardware into a window on the desktop then all you need to do is\r
- set the MESA_WGL_FX environment variable to anything other than\r
- "fullscreen" and it will render into a window. If you wish to go\r
- fullscreen then you only need to NOT have the environment variable, or\r
- have it set to "fullscreen". You may also switch at runtime between\r
- fullscreen-mode and windowed by pressing ALT-ENTER on the keyboard\r
- (unless the application using Mesa does something with those keystrokes,\r
- of course).\r
-\r
- As of 8/13/98 this should be running a LOT better for more people as a\r
- low-compatability item was cleaned up which prevented it from working on\r
- many (most?) display drivers under Windows 9x.\r
-\r
-- I have my 3Dfx card hooked to it's own monitor and I want the output to\r
- stay on even if I switch to another program, is this possible?\r
-\r
- If the Glide environment variable SST_DUALHEAD is set to '1' then fxMesa\r
- will never disable the Voodoo output on a Voodoo1 or Voodoo2 display\r
- regardless of whether the fxMesa application is "current" or not. This\r
- works regardless of whether it's rendering using the window hack\r
- mentioned above or not.\r
-\r
-- I want to run the Mesa demos on my Intel740 card using it's own OpenGL\r
- acceleration, how do I do this?\r
-\r
- Build GLUT standalone for use with system OpenGL and GLU drivers!\r
-\r
- The Command-line project supports building all test/demo programs against\r
- these drivers also! This allows you full use of GLUT on Windows using\r
- hardware accelerated OpenGL. Wheee! This includes the "3dfx/demos"\r
- directory of which only two programs will not run on "standard"\r
- opengl. Note that there are a few of the sample programs which will NOT\r
- work without Mesa as they directly call into Mesa instead of using the\r
- extension mechanism.\r
-\r
-*** Included programs that exhibit unfortunate or bad behavior\r
-\r
-- demos/bounce - doesn't run on high-colors screens? It's requesting an\r
- INDEX display from GLUT and that fails on my true-color desktop. Changing\r
- this to _RGB let's the program work, but it doesn't display\r
- properly. This is probably just an idiosyncracy of my machine though, as\r
- if I test the program using GLUT for System OpenGL on my Intel740 OpenGL\r
- accelerated machine it's just hunky-dory.\r
-\r
-- demos/glutfx - runs, but crashes on exit (but not on my Intel740 machine)\r
-\r
-- demos/texobj - runs, but crashes on exit if ESC is pressed. Exits cleanly\r
- if the Close box on the window frame is pressed with the mouse. Go figure.\r
-\r
-- book/aaindex - doesn't run, can't get pixel format, because it wants an\r
- INDEX display maybe (but is okay on my Intel740 machine)?\r
-\r
-- most of the book/* demos don't respond to ESC being pressed.\r
-\r
-- 3dfx/demos/* - all demos run, however they all crash on exit. I've traced\r
- this so far as to determine the call it's happening with. The crash comes\r
- from within Glide during the processing of the grGlideShutdown() call, as\r
- in invalid memory reference exception. I'm wondering if this is because\r
- of some state or processing not being completed before the call. Dunno,\r
- but putting grSstIdle() in just before grGlideShutdown() does NOT fix the\r
- problem.\r
-\r
-- 3dfx/demos/tunnel2 - does not run on my system even with SLI mode\r
- disabled. Hmmmm, maybe I need to disconnect my Voodoo2 cards?\r
-\r
-*** Important Notes and Changing Default values\r
-\r
-- The optimizer settings have been manually reworked in both command line\r
- and DevStudio IDE files to hopefully prevent possible irrational code on\r
- the part of the code generator. Formerly, it was configured for "/Ox",\r
- now it is configured for safer handling at a slight potential performance\r
- cost. This may not be required for Visual Studio 6 but I can't test that\r
- (yet).\r
-\r
-- These files build with the code targeted for Pentium processors and\r
- 8-byte structure padding.\r
-\r
-- The IDE-built programs seem to be "happier" in that the command line\r
- build of the 3Dfx demo "fire" will grenade on exit (?). Otherwise pretty\r
- much everything may be built with either interface.\r
-\r
-- The currently configured Mesa version is 3.1, and MesaDemos version is\r
- the same. To change this permanently you will need to edit NMAKE.MAK and\r
- change the lines that look like this (they start o/a line 116):\r
-\r
- # Currently, Mesa is at rev 3.1 ...\r
- #\r
- !IF "$(MESAVER)" == ""\r
- MESAVER=3.1\r
- !ENDIF\r
-\r
- # used in building all of the resource files for the Mesa DLLs\r
- #\r
- !IF "$(MESAFILEVER)" == ""\r
- MESAFILEVER=3,1,0,0\r
- !ENDIF\r
-\r
-- Currently the build files are configured to be used from a Win32\r
- directory that is included inside the main Mesa-3.1 heirarchy.\r
-\r
-- The build files are smart enough to find the files for the core lib, glu,\r
- glut, and the various demo programs if they are unpacked in the current\r
- Mesa-3.1 heirarchy, like this:\r
-\r
- \Mesa-3.1\r
- \Mesa-3.1\src\r
- \Mesa-3.1\src-glu\r
- \Mesa-3.1\src-glut\r
- \Mesa-3.1\Win32\r
- \Mesa-3.1\samples\r
- \Mesa-3.1\demos\r
- \Mesa-3.1\book\r
- \Mesa-3.1\3Dfx\demos\r
-\r
- ... should work. This arose because my initial build tests for the\r
- demo files were done before MesaDemos 2.6 had been released.\r
-\r
-- With the exception of the static link libraries generated by this file\r
- set (mesagl.lib, mesaglu.lib, mesaglut.lib) all DLLs and executables are\r
- built against the "Multithreaded DLL" runtime - this means that they\r
- require MSVCRT.DLL or MSVCRTD.DLL in the path to execute.\r
-\r
- ** CHANGED 8/11/98 ***\r
-\r
- Note also that the demos are all built aginst the "OpenGL32, GLU32, and\r
- GLUT32" and as such they are fairly agnostic wrt: building against Mesa\r
- for CPU-rendering, Mesa-for-3Dfx, Mesa-for-S3, or System OpenGL.\r
-\r
- If you want to build them for use on your system and your display card\r
- provides full OpenGL acceleration (Permedia, Intel740, Intergraph,\r
- whatever) then you only need to build GLUT prior to building any of the\r
- demo programs. For convenience, the GLUT project is included in each of\r
- the demo projects Workspace files for the DevStudio IDE builds BUT it is\r
- not automatically built - you still need to build it first manually.\r