KonstantinSeurer
/
mesa
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

initial rev

This commit is contained in:
Brian Paul 1999-02-23 03:41:13 +00:00
parent f9eae7b63b
commit ecc88c1e1c
9 changed files with 1393 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

181
docs/README.AMIWIN Normal file
View File

@ -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 <pragmas/xlib_pragmas.h>
extern struct Library *XLibBase;
#endif
NET CHANGE: xmesa.h
* mesa/src
Nov. 25, 1995 v 1.2.4
- added the necessary pragma calls for X functions to the following:
xmesa1.c, xmesa2.c, xmesa3.c, xfonts.c, glx.c
This prevents undefined symbols errors during the linking phase for
X library calls
- created smakefile
Dec. 1, 1995 v 1.2.5
- removed AMIWIN includes from xmesa1.c, xmesa2.c, xmesa3.c, xfonts.c,
glx.c since they are now defined in include/GL/xmesa.h
NET CHANGE: smakefile
* mesa/src-tk
Nov. 25, 1995 v 1.2.4
- added the necessary pragma calls for X functions to the following:
private.h
- created smakefile
Dec. 1, 1995 v 1.2.5
- removed AMIWIN includes from private.h since it is now defined in
include/GL/xmesa.h
NET CHANGE: smakefile
* mesa/src-glu
Nov. 25, 1995 v 1.2.4
- created smakefile
NET CHANGE: smakefile
* mesa/src-aux
Nov. 25, 1995 v 1.2.4
- added the necessary pragma calls for X functions to the following:
glaux.c
- created smakefile
NET CHANGE: glaux.c, smakefile
* mesa/demos
Nov. 25, 1995 v 1.2.4
- added the necessary pragma calls for X functions to the following:
xdemo.c, glxdemo.c, offset.c
- created smakefile
- put #ifndef AMIWIN ... #endif around sleep() calls in xdemo.c since
they are not part of AmigaDOS.
Dec. 1, 1995 v 1.2.5
- removed AMIWIN defines from xdemo.c, glxdemo.c, offset.c since
already defined in include/GL/xmesa.h
- modified Smakefile to include header and includes from the AmiTCP4.0
net.lib linkable library to provide unix-compatible sys/time.h and
the sleep() function
- removed AMIWIN defines in xdemo.c since sleep() now defined
NET CHANGE: smakefile
* mesa/samples
Nov. 25, 1995 v 1.2.4
- added the necessary pragma calls for X functions to the following:
oglinfo.c
- created smakefile
- put #ifndef AMIWIN ... #endif around sleep() in blendxor.c
- removed olympic from smakefile targets since <sys/time.h> not defined
Dec. 1, 1995 v 1.2.5
- removed AMIWIN defines from oglinfo.c, since already defined in
include/GL/xmesa.h
- modified Smakefile to include header and includes from the AmiTCP4.0
net.lib linkable library to provide unix-compatible sys/time.h and
the sleep() function
- removed AMIWIN defines in blendxor.c for sleep()
- added AMIWIN defines around _MACHTEN_ in olympic.c since xrandom()
functions are not defined in any libraries
- added olympic back into the Smakefile targets
NET CHANGE: smakefile, olympic.c
* mesa/book
Nov. 25, 1995 v 1.2.4
- created smakefile
- removed accpersp and dof from smakefile targets since the SAS/C compile seems to
confuse the near,far variables with near/far memory models.
NET CHANGE: smakefile
* mesa/windows
Dec. 1, 1995 v 1.2.5
- Removed directory to save space since this is only needed for Windows based
machines.

172
docs/README.GGI Normal file
View File

@ -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

123
docs/README.MINGW32 Normal file
View File

@ -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)

102
docs/README.MITS Normal file
View File

@ -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

6
docs/README.NeXT Normal file
View File

@ -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

27
docs/README.OS2 Normal file
View File

@ -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

28
docs/README.OpenStep Normal file
View File

@ -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

15
docs/README.VMS Normal file
View File

@ -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).

739
docs/README.WIN32 Normal file
View File

@ -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
<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