From ecc88c1e1cad4a5ac933fd085237f54cff62d2d4 Mon Sep 17 00:00:00 2001 From: Brian Paul Date: Tue, 23 Feb 1999 03:41:13 +0000 Subject: initial rev --- docs/README.AMIWIN | 181 +++++++++++++ docs/README.GGI | 172 ++++++++++++ docs/README.MINGW32 | 123 +++++++++ docs/README.MITS | 102 +++++++ docs/README.NeXT | 6 + docs/README.OS2 | 27 ++ docs/README.OpenStep | 28 ++ docs/README.VMS | 15 ++ docs/README.WIN32 | 739 +++++++++++++++++++++++++++++++++++++++++++++++++++ 9 files changed, 1393 insertions(+) create mode 100644 docs/README.AMIWIN create mode 100644 docs/README.GGI create mode 100644 docs/README.MINGW32 create mode 100644 docs/README.MITS create mode 100644 docs/README.NeXT create mode 100644 docs/README.OS2 create mode 100644 docs/README.OpenStep create mode 100644 docs/README.VMS create mode 100644 docs/README.WIN32 diff --git a/docs/README.AMIWIN b/docs/README.AMIWIN new file mode 100644 index 0000000000..47cf696cc1 --- /dev/null +++ b/docs/README.AMIWIN @@ -0,0 +1,181 @@ +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 + 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 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. diff --git a/docs/README.GGI b/docs/README.GGI new file mode 100644 index 0000000000..e28d047732 --- /dev/null +++ b/docs/README.GGI @@ -0,0 +1,172 @@ + LibGGI driver for Mesa-3.0 + by Uwe Maurer (uwe_maurer@t-online.de) + + +Introduction +============ +[from libggi.txt by Steve Cheng and Hartmut Niemann] + + "LibGGI, the dynamic GGI (General Graphics Interface) library is a + flexible drawing library. + + It provides an opaque interface to the display's acceleration + functions. It was originally intended to allow user programs to + interface with KGI, the kernel side of the GGI code, but other display + types can be easily used by loading the appropriate "display target" + (e.g. X, memory). + + LibGGI consists of a main library (libggi.so) and a multitude of + dynamic drivers. The library then loads the necessary "drivers" for + the requested mode, taking hints from the graphics device if + necessary. LibGGI can also load extension libraries, e.g. to provide + enhanced 2D and 3D functions. + + It has been designed after having a look at several existing + libraries, and so far we have found porting to be quite simple from + and to most of them." + +---------------------------------------------------------------------------- + + More information about the GGI project and LibGGI can be + obtained from the GGI website: + + www.ggi-project.org + +---------------------------------------------------------------------------- + +Installation +============ + + - Install LibGGI + + - Unpack the Mesa archives + + - In the Mesa directory type: + + make linux-ggi + su + make linux-ggi-install + exit + + - Now you can try some demos. + If they don't work, you can set the GGIMESA_DEBUG + variable to 255 and you will see some information from the + LibGGI-driver. + + export GGIMESA_DEBUG=255 + + +GLUT +==== + + You can change these default values in ggi/ggiglut.c: + #define WIDTH 640 + #define HEIGHT 400 + #define GRAPHTYPE_RGB GT_16BIT + #define GRAPHTYPE_INDEX GT_8BIT + + Options: + -bpp x Set graphic mode with x bits per pixel + -size x y Screen (or window) is x*y pixels + + Example: + demos/gears -size 320 200 -bpp 24 + +Updates +======= + + You can find the latest LibGGI-driver and ggiglut on my + homepage: + + http://home.t-online.de/home/uwe_maurer/ggimesa.htm + + + +Uwe Maurer - uwe_maurer@t-online.de + + LibGGI driver for Mesa-3.0 + by Uwe Maurer (uwe_maurer@t-online.de) + + +Introduction +============ +[from libggi.txt by Steve Cheng and Hartmut Niemann] + + "LibGGI, the dynamic GGI (General Graphics Interface) library is a + flexible drawing library. + + It provides an opaque interface to the display's acceleration + functions. It was originally intended to allow user programs to + interface with KGI, the kernel side of the GGI code, but other display + types can be easily used by loading the appropriate "display target" + (e.g. X, memory). + + LibGGI consists of a main library (libggi.so) and a multitude of + dynamic drivers. The library then loads the necessary "drivers" for + the requested mode, taking hints from the graphics device if + necessary. LibGGI can also load extension libraries, e.g. to provide + enhanced 2D and 3D functions. + + It has been designed after having a look at several existing + libraries, and so far we have found porting to be quite simple from + and to most of them." + +---------------------------------------------------------------------------- + + More information about the GGI project and LibGGI can be + obtained from the GGI website: + + www.ggi-project.org + +---------------------------------------------------------------------------- + +Installation +============ + + - Install LibGGI + + - Unpack the Mesa archives + + - In the Mesa directory type: + + make linux-ggi + su + make linux-ggi-install + exit + + - Now you can try some demos. + If they don't work, you can set the GGIMESA_DEBUG + variable to 255 and you will see some information from the + LibGGI-driver. + + export GGIMESA_DEBUG=255 + + +GLUT +==== + + You can change these default values in ggi/ggiglut.c: + #define WIDTH 640 + #define HEIGHT 400 + #define GRAPHTYPE_RGB GT_16BIT + #define GRAPHTYPE_INDEX GT_8BIT + + Options: + -bpp x Set graphic mode with x bits per pixel + -size x y Screen (or window) is x*y pixels + + Example: + demos/gears -size 320 200 -bpp 24 + +Updates +======= + + You can find the latest LibGGI-driver and ggiglut on my + homepage: + + http://home.t-online.de/home/uwe_maurer/ggimesa.htm + + + +Uwe Maurer - uwe_maurer@t-online.de + diff --git a/docs/README.MINGW32 b/docs/README.MINGW32 new file mode 100644 index 0000000000..75709ed43d --- /dev/null +++ b/docs/README.MINGW32 @@ -0,0 +1,123 @@ +August 30, 1998 -- Paul Garceau (pgarceau@teleport.com) + +DISCLAIMER: I make this extension to the Mesa 3-D Graphics Library as a service +to the general public. I can, in no way support or make any guarantee that the +EGCS-Mingw32 build or any Gnu-Win32 build will work for your system. The +associated packages and batch files I have included as part of the EGCS-Mingw32 +extension are provided "As-is" with out any guarantee of support or functionality +from the author of this EGCS-Mingw32 native windows port of the Mesa 3-D Graphics +Library. + + Feel free to modify or change things as you see fit, just remember that +I can't support any modifications you might want to make to the files which I +have included OR the lgpl protected Mesa 3-D Graphics Library. + + + EGCS-Mingw32 Beta 3.08 Archive Manifest: + mingw32.bat + src/makefile.nt4 + src/wmesa.c + src-glu/makefile.nt4 + +############### + +Greetings, + + In order to build the Mingw32 set of Mesa 3-D Graphics Library for Beta3.08 +it will be necessary for you to use the Dos or Command Prompt that is available +on most of the i86 based MS Windows machines. Also, I believe that this build +will run on Win95, Win98, WinNT4 and WinNT5. + + I haven't tested Win95/98 or WinNT5. This build was generated under +WinNT4 with SP3 installed. + + This has not been tested under any systems outside of +a WinNT4 Workstation with EGCS-Mingw32 toolchain, v.1.0.2 installed. + + EGCS-Mingw32 uses a variation of gcc to handle its build. The Mesa 3-D +Graphics Library build that I have generated is based, in small part, on the +Cygwin32 build and associated makefiles that Stephane Rehel (rehel@worldnet.fr) +defined back in 1997. The EGCS-Mingw32 toolchain is capable of generating +native windows code and, as of the date of this readme, can be obtained from: + + http://www.xraylith.wisc.edu/~khan/software/gnu-win32/egcs-mingw32-102.html + + Much thanks to the combined efforts of Mumit Khan, Jan-Jaap Vanderhagen +and Colin Peters for making it possible for the EGCS-Mingw32 toolchain to exist. + +Installing EGCS-Mingw32 Build Revisions: + + To install the makefile and source revisions incorporated with this build +of the Mesa 3-D Graphics Library, you'll have to use a version of winzip. I am +in the process of finding a suitable Win32 compatible tar executable so that if +you don't have winzip, you can still decompress the files into their respective +folders/directories. + + a) Move the mingw32.zip file to the top level of the hard drive on your +system. + + b) Copy all of the Beta 3.08 src/windows files to the src/ directory. + + b) Open the Winzip file + + c) Verify that the files will be properly extracted. + + d) Extract the files with the Winzip "Overwrite" and "Use Folder Names" + options enabled. + + The zip file directory structure extraction defaults to the top level of +the hard drive where the mingw32.zip file exists unless otherwise instructed by +you. + + The version of wmesa.c included with the mingw32 archive needs to replace +the current version of the Beta 3.08 wmesa.c file in order for the egcs-mingw32 +build to work. This is because the original Win32 stuff assumes that the glut +utilities are to be installed. The Glut utilities are not part of the +egcs-mingw32 build for Beta 3.08. + + +Build Considerations: + + In order to get the build to work, I needed to create a special makefile +for each library which the Mesa 3-D Graphics Library requires since there is no +comparable make-config/config on a native windows platform. + + Since I was only creating a few of the possible libraries for +Mesa (gl, glu), I only created the new make files in their respective libraries +src, src-glu). For libMesaaux.a. you will find a makefile for it in the +src-aux directory. libMesatk.a and libglut.a were not ported. + + The build itself is a .bat based build and uses Gnu Make,Version 3.76.1 to +process the makefiles noted above. The build must be run from the directory +where the mingw32.bat file is. You can get the binary version of Make 3.76.1 +from Jan-Jaap van der Heijden's site in Germany: + + http://agnes.dida.physik.uni-essen.de/~janjaap/mingw32/download.html + + It was necessary to modify some source code, specifically the source code +in the src-glu directory. I needed to modify nurbs.c, quadric.c and tess.c in +order to get them to work using the EGCS-Mingw32 toolchain. + + The original EGCS-Mingw32 Toolchain, is available from: + + http://www.xraylith.wisc.edu/~khan/software/gnu-win32/egcs-mingw32-102.html + +Running the Build: + + Ok, now that we've got the basics out of the way, follows is all you need +to do in order to build the EGCS-Mingw32 version of libMesaGL.a and libMesaGLU.a: + + Open your Command Prompt/Dos prompt. + Go to your Mesa-3.0 beta 'root' directory. + This is the same directory that the Mesa mingw32.zip file was + originally stored in if you've installed the Mesa-3.0 beta 3-D + Graphics Library source as outlined in the "readme" file included + with the Mesa-3.0 beta distribution. + At the command line type: mingw32 + mingw32 is the .bat file that actually does the build. + + Enjoy! + + Peace, + + Paul G. (pgarceau@teleport.com) \ No newline at end of file diff --git a/docs/README.MITS b/docs/README.MITS new file mode 100644 index 0000000000..a89176a62e --- /dev/null +++ b/docs/README.MITS @@ -0,0 +1,102 @@ + + Mesa 3.0 MITS Information + + +This software is distributed under the terms of the GNU Library +General Public License, see the LICENSE file for details. + + +This document is a preliminary introduction to help you get +started. For more detaile information consult the web page. + +http://10-dencies.zkm.de/~mesa/ + + + +Version 0.1 (Yes it's very alpha code so be warned!) +Contributors: + Emil Briggs (briggs@bucky.physics.ncsu.edu) + David Bucciarelli (tech.hmw@plus.it) + Andreas Schiffler (schiffler@zkm.de) + + + +1. Requirements: + Mesa 3.0. + An SMP capable machine running Linux 2.x + libpthread installed on your machine. + + +2. What does MITS stand for? + MITS stands for Mesa Internal Threading System. By adding + internal threading to Mesa it should be possible to improve + performance of OpenGL applications on SMP machines. + + +3. Do applications have to be recoded to take advantage of MITS? + No. The threading is internal to Mesa and transparent to + applications. + + +4. Will all applications benefit from the current implementation of MITS? + No. This implementation splits the processing of the vertex buffer + over two threads. There is a certain amount of overhead involved + with the thread synchronization and if there is not enough work + to be done the extra overhead outweighs any speedup from using + dual processors. You will not for example see any speedup when + running Quake because it uses GL_POLYGON and there is only one + polygon for each vertex buffer processed. Test results on a + dual 200 Mhz. Pentium Pro system show that one needs around + 100-200 vertices in the vertex buffer before any there is any + appreciable benefit from the threading. + + +5. Are there any parameters that I can tune to try to improve performance. + Yes. You can try to vary the size of the vertex buffer which is + define in VB_MAX located in the file src/vb.h from your top level + Mesa distribution. The number needs to be a multiple of 12 and + the optimum value will probably depend on the capabilities of + your machine and the particular application you are running. + + +6. Are there any ways I can modify the application to improve its + performance with the MITS? + Yes. Try to use as many vertices between each Begin/End pair + as possbile. This will reduce the thread synchronization + overhead. + + +7. What sort of speedups can I expect? + On some benchmarks performance gains of up to 30% have been + observerd. Others may see no gain at all and in a few rare + cases even some degradation. + + +8. What still needs to be done? + Lots of testing and benchmarking. + A portable implementation that works within the Mesa thread API. + Threading of additional areas of Mesa to improve performance + even more. + + + +Installation: + + 1. This assumes that you already have a working Mesa 3.0 installation + from source. + 2. Place the tarball MITS.tar.gz in your top level Mesa directory. + 3. Unzip it and untar it. It will replace the following files in + your Mesa source tree so back them up if you want to save them. + + + README.MITS + Make-config + Makefile + mklib.glide + src/vbxform.c + src/vb.h + + 4. Rebuild Mesa using the command + + make linux-386-glide-mits + diff --git a/docs/README.NeXT b/docs/README.NeXT new file mode 100644 index 0000000000..52a62a3265 --- /dev/null +++ b/docs/README.NeXT @@ -0,0 +1,6 @@ +The NeXT support has now been incorproated 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/98 diff --git a/docs/README.OS2 b/docs/README.OS2 new file mode 100644 index 0000000000..35b3e7a329 --- /dev/null +++ b/docs/README.OS2 @@ -0,0 +1,27 @@ + README for port of Mesa to XFree86 on OS/2 + (as of 19980802) + + +Instructions to build Mesa for XFree86/OS2: + +You need a recent version of XFree86 (3.3x or above) installed including +the supplied programming libraries and tools as well as EMX 0.9c (and above). + +Beginning after beta 7 there's again support for creating DLLs. +The details are handled in "mklib-emx.cmd" a small REXX script. +By now it does ensure compatiblity by using the function names as +entry points instead of ordinals. This will cost performance and +might be fixed in a future patch. + +We switched to the usual build method +(based on Makefile and make-config) beginning with Mesa 3.0 beta 5. +To use most of the standard files (including shell scripts) you should +have a un*x shell (sh) in path. + +To actually build the (static) libraries and demos type + make os2 + + +Alexander Mai +am@os-2.de +st002279@hrzpub.tu-darmstadt.de diff --git a/docs/README.OpenStep b/docs/README.OpenStep new file mode 100644 index 0000000000..c4f504c22a --- /dev/null +++ b/docs/README.OpenStep @@ -0,0 +1,28 @@ +This is a port of Mesa-3.0 to OpenStep and Rhapsody/YellowBox. Only +the GL and GLU libraries have been ported. As OpenStep has it's own +window handling code we simply use the offscreen rendering capability +of Mesa to generate a bitmap which can then be drawn into a View. An +example application using Mesa can be found in OpenStep/MesaView. +Currently only static libraries are built. The code has been tested on the +Intel hardware version of the following systems: + + OpenStep for Mach 4.2 + Rhapsody (DR1) + YellowBox for NT4 (DR1) + +It should, however, work on all other variants of OpenStep for other +processors without modification. Feedback on this would be appreciated. + +To build on UNIX based systems simply type "make openstep". + +To build on Win95/WinNT based systems run the "win32-openstep.sh" script from +the Bourne shell provided with the development environment. + +Thiss build the libraries, places them in the "lib" directory and also builds +the "MesaView" example application. Older examples may be found in the +OpenStep/Old_Demos directory. These only work on UNIX based systems. The CC +variable is passed around by the Makefiles so fat libraries may be created +by alreting this on the command line, e.g. for m68k and i486 support you +can use the command "make CC='cc -arch m68k -arch i386' openstep". + +-Pete French. (pete@ohm.york.ac.uk) 28/5/98 diff --git a/docs/README.VMS b/docs/README.VMS new file mode 100644 index 0000000000..1763f700e3 --- /dev/null +++ b/docs/README.VMS @@ -0,0 +1,15 @@ + +VMS support contributed by Jouk Jansen (joukj@crys.chem.uva.nl) + + +I compiled the libs on a VMSAlpha7.0 system using DECC5.3. +But earlier versions may work as well. The make files were tested +use the DIGITAL make utility called MMS. There is also a public domain +clone available (MMK) and I think, but it is not tested, that this +utility will give no problem. + +To make everything just type MMS (or MMK) in the main directory of +mesagl. For MMS the deafult makefile is called descrip.mms, and +that is what I have called it. I included alse some config files, +all having mms somewhere in the name which all the makefiles need +(just as your unix makefiles). diff --git a/docs/README.WIN32 b/docs/README.WIN32 new file mode 100644 index 0000000000..6382624f56 --- /dev/null +++ b/docs/README.WIN32 @@ -0,0 +1,739 @@ + + 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 + + + + nmake /f nmake.mak GLIDE2X=g:\sdk\glide2x allfx + + + + 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 + + + + 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 + + + + 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 + + nmake /f nmake.mak fxMesaGL + + ... to build only Mesa on top of the S3 Toolkit ... + + nmake /f nmake.mak s3MesaGL32 + + 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 . 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 -- cgit v1.2.3