initial rev
This commit is contained in:
parent
f9eae7b63b
commit
ecc88c1e1c
|
@ -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.
|
|
@ -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
|
||||||
|
|
|
@ -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)
|
|
@ -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
|
||||||
|
|
|
@ -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
|
|
@ -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
|
|
@ -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
|
|
@ -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).
|
|
@ -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
|
Loading…
Reference in New Issue