README.3DFX
1
2 3Dfx Glide device driver
3
4
5
6 Requirements:
7 -------------
8
9 A Voodoo-based videocard/accelerator
10 DOS (with DJGPP), Windows9x/2k (with MinGW), Linux
11 Glide3x library for your OS
12
13 http://sourceforge.net/projects/glide/
14
15
16
17 How to compile:
18 ---------------
19
20 DJGPP:
21 Place the Glide3 SDK in the top Mesa directory:
22 $(MESA)/glide3/include/
23 3dfx.h, g3ext.h, glide.h, glidesys.h, glideutl.h, sst1vid.h
24 $(MESA)/glide3/lib/
25 libgld3x.a, libgld3i.a, glide3x.dxe
26 Type:
27 make -f Makefile.DJ X86=1 FX=1
28 Look into the makefile for further information.
29
30 MinGW:
31 Place the Glide3 SDK in the top Mesa directory:
32 $(MESA)/glide3/include/
33 3dfx.h, g3ext.h, glide.h, glidesys.h, glideutl.h, sst1vid.h
34 $(MESA)/glide3/lib/
35 libglide3x.a, glide3x.dll
36 Type:
37 make -f Makefile.mgw X86=1 FX=1
38 Look into the makefile for further information.
39
40 Linux:
41 Place the Glide3 SDK in /usr/local/glide
42 /usr/local/glide/include/
43 3dfx.h, g3ext.h, glide.h, glidesys.h, glideutl.h, sst1vid.h
44 /usr/local/glide/lib/
45 libglide3x.a, libglide3x.so
46 Type:
47 make linux-glide
48 or
49 make linux-x86-glide
50
51
52
53 Compilation defines:
54 --------------------
55
56 FX_DEBUG
57 enable driver debug code
58 FX_TRAP_GLIDE
59 enable Glide trace code
60 FX_PACKEDCOLOR
61 use packed color in vertex structure
62 FX_TC_NAPALM
63 map GL_COMPRESSED_RGB[A] to FXT1. Works with VSA100-based cards only.
64 FX_COMPRESS_S3TC_AS_FXT1_HACK
65 map S3TC to FXT1
66 FX_RESCALE_BIG_TEXURES_HACK
67 fake textures larger than HW can support
68 (see MESA_FX_MAXLOD environment variable)
69
70
71
72 Environment variables:
73 ----------------------
74
75 The following environment variables affect MesaFX. Those that affect Glide
76 only, are beyond the scope of this section. Entries that don't have a "Value"
77 field, can have any value whatsoever
78 ex: set MESA_FX_IGNORE_CMBEXT=y
79
80 "Note" (*) means that the environment variable affects Glide, too; also, if
81 the var is not found in the environment, it is searched in windoze registry.
82 "Note" (!) means that the environment variable is not working as expected;
83 may have undefined effects, might have effects only at Glide level or might
84 not have any effect whatsoever. Caveat emptor! Those are to be revised soon.
85
86 It is recommended to leave the envvars alone, so that Mesa/Glide will run with
87 default values. Use them only when you experience crashes or strange behavior.
88
89 FX_GLIDE_NUM_TMU
90 OS: all
91 HW: dual-TMU cards (Voodoo2, Avenger, Napalm)
92 Desc: force single-TMU
93 Note: (*)
94 Value: "1"
95 FX_GLIDE_SWAPPENDINGCOUNT
96 OS: all
97 HW: all
98 Desc: max # of buffers allowed to build up
99 Note: (*) (!)
100 Value: "0", "1", "2", "3", "4", "5" or "6"
101 FX_GLIDE_SWAPINTERVAL
102 OS: all
103 HW: all
104 Desc: number of vertical retraces to wait before swapping
105 Note: (*) (!) works only at Glide-level?
106 SSTH3_SLI_AA_CONFIGURATION
107 OS: all
108 HW: VSA100-based cards
109 Desc: SLI/AA setup
110 Note: (*) (!) works only at Glide-level?
111 Value:
112 1, 2, 4 chip cards
113 "0" - SLI & AA disable
114 "1" - SLI disabled, 2 sample AA enabled
115 2, 4 chip cards
116 "2" - 2-way SLI enabled, AA disabled
117 "3" - 2-way SLI enabled, 2 sample AA enabled
118 "4" - SLI disabled, 4 sample AA enabled
119 4 chip cards
120 "5" - 4-way SLI enabled, AA disabled
121 "6" - 4-way SLI enabled, 2 sample AA enabled
122 "7" - 2-way SLI enabled, 4 sample AA enabled
123 "8" - SLI disabled, 8 sample AA enabled
124 SST_DUALHEAD
125 OS: win32
126 HW: ?
127 Desc: ?
128 Note: (!) disabled?
129 MESA_FX_NO_SIGNALS
130 OS: linux
131 HW: all
132 Desc: avoid installing signals
133 Note: (!) untested!
134 MESA_FX_INFO
135 OS: all
136 HW: all
137 Desc: verbose to stderr
138 Value: any; special value "r" to redirect stderr to MESA.LOG
139 MESA_FX_NOSNAP
140 OS: all
141 HW: Voodoo1, Rush, Banshee
142 Desc: do not snap vertices inside Mesa
143 Note: to be used with Glide3x that snaps vertices internally
144 MESA_FX_POINTCAST
145 OS: all
146 HW: dual-TMU cards (some Voodoo1, Voodoo2, Avenger, Napalm)
147 Desc: try to use pointcast palette
148 Note: may give adverse effects on UMA cards (Avenger, Napalm)
149 MESA_FX_IGNORE_PALEXT
150 OS: all
151 HW: all
152 Desc: disable 6666 palette
153 MESA_FX_IGNORE_PIXEXT
154 OS: all
155 HW: Napalm
156 Desc: force 565 16bpp mode (traditional Voodoo, no 32/15bpp)
157 MESA_FX_IGNORE_TEXFMT
158 OS: all
159 HW: Napalm
160 Desc: disable 32bit textures
161 MESA_FX_IGNORE_CMBEXT
162 OS: all
163 HW: Napalm
164 Desc: disable Napalm combiners (color/alpha/texture)
165 Note: this option allows dual-TMU cards perform single-pass
166 trilinear, but some advanced (multi)texturing modes
167 won't work (GL_EXT_texture_env_combine)
168 MESA_FX_IGNORE_MIREXT
169 OS: all
170 HW: all
171 Desc: disable mirror extension
172 MESA_FX_IGNORE_TEXUMA
173 OS: all
174 HW: all
175 Desc: disable UMA
176 MESA_FX_IGNORE_TEXUS2
177 OS: all
178 HW: all
179 Desc: disable Texus2
180 MESA_FX_MAXLOD
181 OS: all
182 HW: non VSA-100 cards
183 Desc: enable large texture support using SW rescaling
184 Value:
185 "9" - 512x512 textures
186 "10" - 1024x1024 textures
187 "11" - 2048x2048 textures
188 MESA_FX_ALLOW_VP
189 OS: all
190 HW: all
191 Desc: allow vertex program extensions
192 MESA_GLX_FX
193 OS: linux
194 HW: Voodoo1, Rush, Voodoo2
195 Desc: display mode
196 Note: (!) experimental
197 Value:
198 "w" - windowed mode
199 "f" - fullscreen mode
200 "d" - disable glide driver
201 OS: win32
202 HW: Rush, Banshee, Avenger, Napalm
203 Desc: display mode
204 Note: (!) experimental
205 Value:
206 "w" - windowed mode
207
208
209
210 Contact:
211 --------
212
213 Daniel Borca <dborca 'at' users 'dot' sourceforge 'dot' net>
214 Hiroshi Morii <koolsmoky 'at' users 'dot' sourceforge 'dot' net>
215
216
217
218 WARNING! The info below this line is outdated (yet some of it useful). WARNING!
219 *******************************************************************************
220
221
222
223 Info for Mesa 4.1
224 -----------------
225
226 The 3dfx Glide driver in Mesa is disabled by default. Not too many people
227 use this driver anymore and at some point down the road it will be dropped.
228
229 To use/enable the Glide driver either do this:
230
231 './configure --with-glide=DIR' Where DIR is the location of Glide, like
232 /usr/ or /usr/local
233
234 OR
235
236 'make linux-x86-glide' If using the old-style Makefile system.
237
238 The rest of this file hasn't changed since Mesa 3.3. Some of it's out of
239 date, but some is still valid.
240
241
242
243 What do you need ?
244 ------------------
245
246 - A PC with a 3Dfx Voodoo1/2 Graphics or Voodoo Rush based board
247 (Pure3D, Monster 3D, R3D, Obsidian, Stingray 128/3D, etc.).
248 The Quantum3D Obsidian3D-2 X-24 requires some special env. setting
249 under Linux (more information in the "Useful Glide Environment
250 Variables");
251
252 - The 3Dfx Glide library 2.3 or later for your OS (the 2.4 works fine).
253 The Voodoo2 requires the Glide library 2.51. The Glide 3.1 is not
254 compatible with the Glide 2.x so it doesn't work with the current
255 version of the driver;
256
257 - A compiler supported by the Glide library (Micro$oft VC++ (tested),
258 Watcom (tested), GCC for Linux (tested), etc.);
259
260 - It's nice to have two monitors - one for your normal graphics
261 card and one for your 3Dfx card. If something goes wrong with
262 an application using the 3Dfx hardware you can still see your
263 normal screen in order to recover.
264
265
266
267 Tested on:
268 ----------
269 Windows 95 - David Bucciarelli
270 Windows NT - Henri Fousse
271 MS-DOS
272 Linux - Daryll Strauss, Brian Paul, David Bucciarelli
273 FreeBSD
274 BeOS - Duncan Wilcox
275 MacOS - Fazekas Miklos
276
277
278 What is able to do ?
279 --------------------
280
281 - It is able accelerate points, lines and polygon with flat
282 shading, gouraud shading, Z-buffer, texture mapping, blending, fog and
283 antialiasing (when possible). There is also the support for rendering
284 in a window with a slow trick for the Voodoo Graphics (available only
285 for Linux) and at full speed with the Voodoo Rush chipset.
286 Under Linux is also possible to switch on-the-fly between the fullscreen
287 and in-window rendering hack.
288 There is also the support for using more than one Voodoo Graphics in the
289 some application/PC (you can create one context for each board and use
290 multiple video outputs for driving monitors, videoprojectors or HMDs).
291 The driver is able to fallback to pure software rendering when afeature
292 isn't supported by the Voodoo hardware (however software rendering is
293 very slow compared to hardware supported rendering)
294
295
296
297 How to compile:
298 ---------------
299
300 Linux:
301 ------
302 Here are the basic steps for using the 3Dfx hardware with Mesa
303 on Linux:
304
305 - You'll need the Glide library and headers. Mesa expects:
306 /usr/local/glide/include/*.h // all the Glide headers
307 /usr/local/glide/lib/libglide2x.so
308
309 If your Glide libraries and headers are in a different directory
310 you'll have to modify the Mesa-config and mklib.glide files.
311
312 - Unpack the MesaLib-3.1.tar.gz and MesaDemos-3.1.tar.gz archives;
313
314 - If you're going to use a newer Mesa/Glide driver than v0.27 then
315 unpack the new driver archive over the Mesa directory.
316
317 - In the Mesa-3.1 directory type "make linux-glide"
318
319 - Compilation _should_ finish without errors;
320
321 - Set your LD_LIBRARY_PATH environment variable so that the
322 libglide2x.so and Mesa library files can be found. For example:
323 setenv LD_LIBRARY_PATH "/usr/local/glide/lib:/SOMEDIR/Mesa-3.1/lib"
324
325 - You'll have to run Glide-based programs as root or set the suid
326 bit on executables;
327
328 - Try a demo:
329 cd gdemos
330 su
331 setenv MESA_GLX_FX f
332 ./gears (hit ESC to exit)
333
334 - You can find the demos especially designed for the Voodoo driver in
335 in the Mesa-3.1/3Dfx/demos directory (type "make" in order to compile
336 everything).
337
338 MacOS:
339 ------
340 Check the WEB page at http://valerie.inf.elte.hu/~boga/Mesa.html
341
342 MS Windows:
343 -----------
344
345 For the MSVC++:
346 - The glide2x.lib have to be in the default MSVC++ lib directory;
347
348 - The Glide headers have to be in the default MSVC++ include directory;
349
350 - You must have the vcvars32.bat script in your PATH;
351
352 - Go to the directory Mesa-3.1 and run the mesafx.bat;
353
354 - The script will compile everything (Mesa-3.1/lib/OpenGL32.{lib,dll},
355 Mesa-3.1/lib/GLU32.{lib,dll}, Mesa-3.1/lib/GLUT32.{lib,dll} and
356 Voodoo demos);
357
358 - At the end, you will be in the Mesa-3.1/3Dfx/demos directory;
359
360 - Try some demo (fire.exe, teapot.exe, etc.) in order to check if
361 everything is OK (you can use Alt-Tab or Ctrl-F9 to switch between
362 the Voodoo screen and the windows desktop);
363
364 - Remember to copy the Mesa OpenGL32.dll, GLU32.dll and GLUT32.dll in the
365 some directory were you run your Mesa based applications.
366
367 - I think that you can easy change the Makefile.fx files in order
368 to work with other kind of compilers;
369
370 - To discover how open the 3Dfx screen, read the sources under
371 the Mesa-3.1/3Dfx/demos directory. You can use the GLUT library or
372 the Diego Picciani's wgl emulator.
373
374 NOTE: the MSVC++ 5.0 optimizer is really buggy. Also if you install the
375 SP3, you could have some problem (you can disable optimization in order
376 solve these kind of problems).
377
378
379 Doing more with Mesa & Linux Glide:
380 -----------------------------------
381
382 The MESA_GLX_FX environment variable can be used to coax most
383 GLX-based programs into using Glide (and the __GLUT library
384 is GLX-based__).
385
386 Full-screen 3Dfx rendering:
387 ---------------------------
388
389 1. Set the MESA_GLX_FX variable to "fullscreen":
390
391 ksh:
392 export MESA_GLX_FX = "fullscreen"
393 csh:
394 setenv MESA_GLX_FX fullscreen
395
396 2. As root, run a GLX-based program (any GLUT demo on Linux).
397
398 3. Be careful: once the 3Dfx screen appears you won't be able
399 to see the GLUT windows on your X display. This can make using
400 the mouse tricky! One solution is to hook up your 3Dfx card to
401 a second monitor. If you can do this then set these env vars
402 first:
403
404 setenv SST_VGA_PASS 1
405 setenv SST_NOSHUTDOWN
406
407 or for the Voodoo2:
408
409 setenv SSTV2_VGA_PASS 1
410 setenv SSTV2_NOSHUTDOWN
411
412 Rendering into an X window with the help of the Voodoo hardware:
413 ----------------------------------------------------------------
414
415 1. Start your X server in 16 bpp mode (XFree86: startx -- -bpp 16)
416 in order to have the best performance and the best visual
417 quality. However you can use any visual depth supported by X.
418
419 2. Set the following environment variables:
420 export MESA_GLX_FX="window" # to enable window rendering
421 export SST_VGA_PASS=1 # to stop video signal switching
422 export SST_NOSHUTDOWN=1 # to stop video signal switching
423 OR
424 setenv MESA_GLX_FX window
425 setenv SST_VGA_PASS 1
426 setenv SST_NOSHUTDOWN 1
427
428 (the Voodoo2 requires to use "SSTV2_" instead "SST_").
429
430 3. As root, try running a GLX-based program
431
432 How does it work? We use the 3Dfx hardware to do rendering then
433 copy the image from the 3Dfx frame buffer into an X window when
434 the SwapBuffers() function is called. The problem with this
435 idea is it's slow. The image must be copied from the 3Dfx frame
436 buffer to main memory then copied into the X window (and when the X
437 visual depth doesn't match the Voodoo framebufffer bit per pixel, it
438 is required also a pixel format translation).
439
440 NOTE: the in-window rendering feature only works with double-buffering.
441
442
443 On the fly switching between in window rendering and full screen rendering
444 --------------------------------------------------------------------------
445
446 The Mesa 2.6 has introduced the capability of switching
447 on-the-fly between the fullscreen/fullspeed rendering and the in-window
448 hack and vice versa. The on-the-fly switching requires a direct support
449 by the application but it is really easy to add. You have to start
450 your X server in 16 bpp mode and to add the following lines to your
451 application:
452
453 #if defined(FX) && define(XMESA)
454 #include <GL/xmesa.h>
455
456 static int fullscreen=1;
457 #endif
458
459 ...
460
461 /* In the GLUT keyboard event callback */
462
463 #if defined(FX) && !define(WIN32)
464 case ' ':
465 fullscreen=(!fullscreen);
466 XMesaSetFXmode(fullscreen ? XMESA_FX_FULLSCREEN : XMESA_FX_WINDOW);
467 break;
468 #endif
469 ...
470
471 See the 3Dfx/demos/tunnel.c program
472 for an example. You have to set the -DXMESA flag in the Makefile's COPTS
473 to enable it.
474
475 Rendering into an X window with the X11 software driver:
476 --------------------------------------------------------
477
478 Set the MESA_GLX_FX variable to "disable" your GLX-based program will use
479 the X11 software driver (the 3Dfx hardware isn't used at all).
480
481
482
483 Useful Glide Environment Variables:
484 -----------------------------------
485
486 - To disable the 3Dfx logo, set the FX_GLIDE_NO_SPLASH variable.
487
488 - To disable video signal switching:
489 setenv SST_VGA_PASS 1
490 setenv SST_NOSHUTDOWN
491 or for the Voodoo2:
492 setenv SSTV2_VGA_PASS 1
493 setenv SSTV2_NOSHUTDOWN
494
495 - To set the default screen refresh rate:
496 setenv SST_SCREENREFRESH=75
497
498 the supported values are 60, 70, 72, 75, 80, 85, 90, 100, 120.
499
500 - To force the Mesa library to swap buffers as fast as possible,
501 without any vertical blanking synchronization (useful for benchmarks):
502 setenv FX_GLIDE_SWAPINTERVAL 0
503 setenv SST_SWAP_EN_WAIT_ON_VIDSYNC 0
504
505 - You can slight improve the performances of your Voodoo1 board with
506 the following env. var.:
507 setenv SST_FASTMEM 1
508 setenv SST_PCIRD 1
509 setenv SST_GRXCLK 57
510
511 (don't use this setting with the Quantum3D 100SB or with any other
512 SLI configuration: it will hang everything !).
513 The following setting can be used with the Voodoo2:
514 setenv SSTV2_FASTMEM_RAS_READS=1
515 setenv SSTV2_FASTPCIRD=1
516 setenv SSTV2_GRXCLK=95
517
518 - The Quantum3D Obsidian3D-2 X-24 requires some special env. setting
519 in order to work under Linux:
520
521 export SSTV2_FT_CLKDEL=5
522 export SSTV2_TF0_CLKDEL=7
523 export SSTV2_TF1_CLKDEL=7
524 export SSTV2_TF2_CLKDEL=7
525 export SSTV2_SLIM_VIN_CLKDEL=3
526 export SSTV2_SLIM_VOUT_CLKDEL=2
527 export SSTV2_SLIS_VIN_CLKDEL=3
528 export SSTV2_SLIS_VOUT_CLKDEL=2
529
530 (Thanks to Phil Ross for this trick).
531
532
533
534
535 The Mesa/Voodoo Environment Variables:
536 --------------------------------------
537
538 - Only for Windows/Voodoo Rush users, if you define the
539 env. var. MESA_WGL_FX:
540 export MESA_WGL_FX=fullscreen
541 you will get fullscreen rendering;
542
543 - Only for Windows/Voodoo Rush users, if you define the
544 env. var. MESA_WGL_FX:
545 export MESA_WGL_FX=window
546 you will get window rendering (default value);
547
548 - Only for Linux users, you can find more informations about
549 the env. var. MESA_GLX_FX in the "Doing more with Mesa & Linux Glide"
550 section;
551
552 - If you define the env. var. MESA_FX_SWAP_PENDING:
553 export MESA_FX_SWAP_PENDING=4
554 you will able to set the maximum number of swapbuffers
555 commands in the Voodoo FIFO after a swapbuffer (default value: 2);
556
557 - If you define the env. var. MESA_FX_INFO:
558 export MESA_FX_INFO=1
559 you will get some useful statistic.
560
561 - If you define the env. var. MESA_FX_NO_SIGNALS:
562 export MESA_FX_NO_SIGNALS=1
563 Mesa/FX will not install atexit() or signal() handlers.
564
565
566
567 Know BUGS and Problems:
568 -----------------------
569
570 - fog doesn't work in the right way when using the glDepthRange() function;
571
572 - Maximum texture size: 256x256 (this is an hardware limit);
573
574 - Texture border aren't yet supported;
575
576 - A GL_BLEND in a glTexEnv() is not supported (it is an hardware limit);
577
578 - Use the glBindTexture extension (standard in OpenGL 1.1) for texture
579 mapping (the old way: glTexImage inside a display list, download
580 the texture map each time that you call the display list !!!);
581
582 - Stencil buffer and Accumulation buffer are emulated in software (they are not
583 directly supported by the Hardware);
584
585 - Color index mode not implemented (this is an hardware limit);
586
587 - Thre is an know bug in the Linux Glide library so the in-window-rendering hack
588 and any other operations that requires to read the Voodoo frame buffer
589 (like the accumulation buffer support) doesn't work on Voodoo SLI cards.
590
591 - The driver switch to pure software (_slow_) rendering when:
592
593 - Stencil enabled;
594 - Using the Accumulation buffer;
595 - Blend enabled and blend equation != GL_FUNC_ADD_EXT;
596 - Color logic operation enabled and color logic operation != GL_COPY;
597 - Using GL_SEPARATE_SPECULAR_COLOR;
598 - The four values of glColorMask() aren't the some;
599 - Texture 1D or 3D enabled;
600 - Texture function is GL_BLEND;
601 - Using the Multitexture extension with Voodoo cards with only one TMU;
602 - Using the Multitexture extension with Voodoo cards with more than
603 one TMU, and texture function isn't GL_MODULATE;
604 - Point size is != 1.0 or point params vector != (1.0,0.0,0.0);
605 - Line width != 1.0 or using stipple lines.
606 - Using polygon offset or stipple polygons;
607
608 NOTE: this is list is not yet complete.
609
610
611 Hints and Special Features:
612 ---------------------------
613
614 - Under Linux and with a Voodoo Graphics board, you can use
615 XMesaSetFXmode(XMESA_FX_FULLSCREEN or XMESA_FX_WINDOW) in order to
616 switch on the fly between fullscreen rendering and the in-window-rendering
617 hack.
618
619 - The driver is able to use all the texture memory available: 2/4MB on
620 Voodoo1 boards and 8MB (!) on high-end Voodoo1 and Voodoo2 boards.
621
622 - Trilinear filtering is fully supported on Voodoo boards with two TMUs
623 (high-end Voodoo1 boards and Voodoo2 boards). When only one TMU is
624 available the driver fallback to bilinear filter also if you ask
625 for trilinear filtering.
626
627 - The Voodoo driver support multiple Voodoo Graphics boards in the
628 some PC. Using this feature, you can write applications that use
629 multiple monitors, videoprojectors or HMDs for the output. See
630 Mesa-3.1/3Dfx/demos/tunnel2.c for an example of how setup one
631 context for each board.
632
633 - The v0.19 introduces a new powerful texture memory manager: the
634 texture memory is used as a cache of the set of all defined texture
635 maps. You can now define several MBs of texture maps also with a 2MB
636 of texture memory (the texture memory manager will do automatically
637 all the swap out/swap in
638 texture memory work). The new texture memory manager has also
639 solved a lot of other bugs/no specs compliance/problems
640 related to the texture memory usage.
641
642 - Use triangles and quads strip: they are a LOT faster than sparse
643 triangles and quads.
644
645 - The Voodoo driver supports the GL_EXT_paletted_texture. it works
646 only with GL_COLOR_INDEX8_EXT, GL_RGBA palettes and the alpha value
647 is ignored because this is a limitation of the current Glide
648 version and of the Voodoo hardware. See Mesa-3.1/3Dfx/demos/paltex.c for
649 a demo of this extension.
650
651 - The Voodoo driver directly supports 3Dfx Global Palette extension.
652 It was written for GLQuake and I think that it isn't a good idea
653 to use this extension for any other purpose (it is a trick). See
654 Mesa-3.1/3Dfx/demos/glbpaltex.c for a demo of this extension.
655
656 - The Voodoo driver chooses the screen resolution according to the
657 requested window size. If you open a 640x480 window, you will get
658 a 640x480 screen resolution, if you open a 800x600 window, you
659 will get a 800x600 screen resolution, etc.
660 Most GLUT demos support the '-geometry' option, so you can choose
661 the screen resolution: 'tunnel -geometry 800x600'.
662 Clearly, you Voodoo board must have enough framebuffer RAM (otherwise
663 the window creation will fail).
664
665 - The glGetString(GL_RENDERER) returns more information
666 about the hardware configuration: "Mesa Glide <version>
667 <Voodoo_Graphics|Voodoo_Rush|UNKNOWN> <num> CARD/<num> FB/
668 <num> TM/<num> TMU/<NOSLI|SLI>"
669 where: <num> CARD is the card used for the current context,
670 <num> FB is the number of MB for the framebuffer,
671 <num> TM is the number of MB for the texture memory,
672 <num> TMU is the number of TMU. You can try to run
673 Mesa/demos/glinfo in order to have an example of the output.
674
675 Did you find a lot BUGs and problems ? Good, send me an email.
676
677
678
679 FAQ:
680 ----
681
682 For a complete FAQ check the Bernd Kreimeier's Linux 3Dfx HOWTO
683 available at http://www.gamers.org/dEngine/xf3D (it includes also
684 a lot of informations not strictly related to Linux, so it can be
685 useful also if you don't use Linux)
686
687 1. What is 3Dfx?
688
689 3Dfx Interactive, Inc. is the company which builds the VooDoo 3-D graphics
690 chipset (and others) used in popular PC cards such as the Diamond Monster 3D
691 and the Orchid Righteous 3D (more informations at http://www.3dfx.com).
692
693
694 2. What is Glide?
695
696 Glide is a "thin" programming interface for the 3Dfx hardware. It was
697 originally written for Windows/Intel but has been ported to Linux/Intel
698 by Daryll Strauss.
699
700 3Dfx, Inc. should be applauded for allowing the Linux version of Glide
701 to be written.
702
703 You can directly program with the Glide library if you wish. You can
704 obtain Glide from the "Developer" section of the 3Dfx website: www.3dfx.com
705 There's a Linux/Glide newsgroup at news://news.3dfx.com/3dfx.glide.linux
706
707
708 3. What is fxmesa?
709
710 "fxmesa" is the name of the Mesa device driver for the 3Dfx Glide library.
711 It was written by David Bucciarelli and others. It works on both Linux
712 and Windows. Basically, it allows you to write and run OpenGL-style programs
713 on the 3Dfx hardware.
714
715
716 4. What is GLQuake?
717
718 Quake is a very popular game from id software, Inc. See www.idsoftware.com
719 GLQuake is a version of Quake written for OpenGL. There is now a Linux
720 version of GLQuake with works with the Mesa/3Dfx/Glide combo.
721
722 Here's what you need to run GLQuake on Linux:
723 PC with 100MHz Pentium or better
724 a 3Dfx-based card
725 Mesa 3.1 libraries: libMesaGL.so libMesaGLU.so
726 Glide 2.4 libraries: libglide2x.so libtexus.so
727 GLQuake for Linux.
728
729 Also, the windows version of GLQuake works fine with the Mesa OpenGL32.dll,
730 you have only to copy the Mesa-3.1/lib/OpenGL32.dll in the GLQuake directory
731 in order to test 'MesaQuake'.
732
733
734 5. What is GLUT?
735
736 GLUT is Mark Kilgard's OpenGL Utility Toolkit. It provides an API for
737 writing portable OpenGL programs with support for multiple windows, pop-
738 up menus, event handling, etc.
739
740 Check the Mark's home page for more informations (http://reality.sgi.com/mjk_asd).
741
742 Every OpenGL programmer should check out GLUT.
743
744 GLUT on Linux uses GLX.
745
746
747 6. What is GLX?
748
749 GLX is the OpenGL extension to the X Window System. I defines both a
750 programming API (glX*() functions) and a network protocol. Mesa implements
751 an emulation of GLX on Linux. A real GLX implementation would requires
752 hooks into the X server. The 3Dfx hardware can be used with GLX-based
753 programs via the MESA_GLX_FX environment variable.
754
755
756 7. Is the Voodoo driver able to use the 4Mb texture memory of
757 the Pure3D boards ?
758
759 Yes, the Voodoo driver v0.20 includes the support for Voodoo
760 Graphics boards with more than 2Mb of texture memory.
761
762
763 8. Do the Voodoo driver support the Voodoo Rush under Windows ?
764
765 Yes, Diego Picciani has developed the support for the Voodoo
766 Rush but David Bucciarelli has a Pure3D and a Monster3D and Brian Paul
767 has a Monster3D, so the new versions of the Mesa/Voodoo sometime are
768 not tested with the Voodoo Rush.
769
770
771 9. Do the Voodoo driver support the Voodoo Rush under Linux ?
772
773 No because the Linux Glide doesn't (yet) support the Voodoo Rush.
774
775
776 10. Can I sell my Mesa/Voodoo based software and include
777 a binary copy of the Mesa in order to make the software
778 working out of the box ?
779
780 Yes.
781
782
783 11. Which is the best make target for compiling the Mesa for
784 Linux GLQuake ('make linux-glide', 'make linux-386-glide', etc.) ?
785
786 'make linux-386-opt-glide' for Voodoo1 and 'make linux-386-opt-V2-glide'
787 for Voodoo2 boards because it doesn't include the '-fPIC'
788 option (4-5% faster).
789
790
791 12. Can I use a Mesa compiled with a 'make linux-386-opt-V2-glide'
792 for my applications/programs/demos ?
793
794 Yes, there is only one constrain: you can't run two Mesa applications
795 at the some time. This isn't a big issue with the today Voodoo Graphics.
796
797
798 Thanks to:
799 ----------
800
801 Henri Fousse (he has written several parts of the v0.15 and the old GLUT
802 emulator for Win);
803
804 Diego Picciani (he has developed all the Voodoo Rush support and the wgl
805 emulator);
806
807 Daryll Strauss (for the Linux Glide and the first Linux support);
808
809 Brian Paul (of course);
810
811 Dave 'Zoid' Kirsch (for the Linux GLQuake and Linux Quake2test/Q2 ports)
812
813 Bernd Kreimeier (for the Linux 3Dfx HOWTO and for pushing companies to offer
814 a better Linux support)
815
816 3Dfx and Quantum3D (for actively supporting Linux)
817
818 The most update places where find Mesa VooDoo driver related informations are
819 the Mesa mailing list and my driver WEB page
820 (http://www-hmw.caribel.pisa.it/fxmesa/index.shtml)
821
822
823 David Bucciarelli (davibu (a] tin.it)
824
825 Humanware s.r.l.
826 Via XXIV Maggio 62
827 Pisa, Italy
828 Tel./Fax +39-50-554108
829 email: info.hmw (a] plus.it
830 www: www-hmw.caribel.pisa.it
831
README.AMIWIN
1 AMIGA AMIWIN PORT of MESA: THE OPENGL SOFTWARE EMULATION
2 ========================================================
3 Port by Victor Ng-Thow-Hing (victorng (a] dgp.toronto.edu)
4 Original Author (Brian Paul (brianp (a] ssec.wisc.edu)
5
6 Dec.1 , 1995: Port of release Mesa 1.2.5
7 - Modifications made to minimize changes to Mesa distribution.
8
9 Nov.25, 1995: Port of release Mesa 1.2.4
10
11
12 HISTORY
13 =======
14 As a 3D graphics progammer, I was increasingly frustrated to see OpenGL
15 appearing on so many platforms EXCEPT the Amiga. Up to now, the task
16 of porting OpenGL directly from native Amiga drawing routines seemed like
17 a daunting task. However, two important events made this port possible.
18
19 First of all, Brian Paul wrote Mesa, the OpenGL software emulator that
20 can be found on many platforms - except the Amiga and Atari (who cares
21 about the latter!). This was pretty ironic considering that Mesa was
22 originally prototyped on an Amiga! The second great event was when
23 Holger Kruse developed AmiWin, the X11R6 server for the Amiga (definitely
24 register for this great piece of software) and released a development kit
25 so one could compile X programs with SAS/C.
26
27 Since Mesa had X routines as its primitive drawing operations, this made
28 a marriage of Mesa and Amiwin feasible. I copied over the sources from
29 an ftp site, played with the code, wrote some Smakefiles, and voila,
30 I had OpenGL programs displaying on my Amiga.
31
32 Although the speed is nothing to be impressed about, this port can be
33 potentially useful to those who want to quickly test their code in
34 wireframe or perhaps learn more about programming with the OpenGL API.
35
36 I hope Amiga developers will continue to write excellent software for
37 their machine, especially more X clients for Amiwin. If you have any
38 solutions so some of my problems in the porting notes, please send me
39 some email!
40
41 See you around,
42 Vic.
43
44 HOW TO CREATE THE LIBRARIES AND SAMPLE CODE
45 ===========================================
46
47 Just run the shell script mklib.amiwin in the mesa directory. This will
48 make all the libraries and copy them into the mesa/lib directory. If you
49 don't want to compile everything, just go to the desired directory and
50 type smake in that directory.
51
52 Change any of the variables in the smakefiles as necessary. You will REQUIRE
53 the Amiwin development kit to compile these libraries since you need X11.LIB
54 and the shareable X libraries. Some examples require the AmiTCP4.0
55 net.lib static link library and related header files for unix related
56 header files and functions like sleep().
57
58 HOW TO USE THE MESA LIBRARIES
59 =============================
60
61 Study the Smakefiles in the demos, samples and book directories for the
62 proper SAS/C options and linkable libraries to use. Basically aux calls
63 require Mesaaux.LIB, gl calls require MesaGL.LIB, glu calls MesaGLU.LIB,
64 tk calls Mesatk.LIB. There is a preliminary port of MesaGLUT.LIB toolkit
65 available in the lib directory with the other Mesa libraries. However,
66 it seems to cause crashes on some of the sample code. Someone else may want
67 to attempt a more stable port.
68
69 PORTING NOTES TO AMIWIN
70 =======================
71
72 My strategy of porting was to leave as much of the code untouched as
73 possible. I surrounded any amiga specific changes with
74 #ifdef AMIWIN ... #endif or #ifndef AMIWIN ... #endif preprocessor
75 symbols. The code was ported on an Amiga 2000, with Fusion 40 accelerator
76 and a Picasso II graphics card. The SAS/C 6.56 compiler was used, with
77 the AmiWin 2.16 X development kit.
78
79 All compilations were done for a 68040 CPU with 68882 math coprocessor for
80 maximum speed. Please edit the smakefile for other compilers.
81 I wrote smakefiles for the directories I ported. I omitted the Windows
82 and Widgets directories. The former is for MS Windows and the latter
83 requires Motif, which is not easily available for the Amiga.
84
85 Here are the changes I did per directory:
86
87 * mesa
88 Nov. 25, 1995 v 1.2.4
89 - added a mklib.amiwin shell script that will make all the libraries and
90 sample code for Mesa
91 - created this readme file: readme.AMIGA
92
93 * mesa/include
94 Dec. 1, 1995 v 1.2.5
95 - added the following to GL/xmesa.h
96 #ifdef AMIWIN
97 #include <pragmas/xlib_pragmas.h>
98 extern struct Library *XLibBase;
99 #endif
100 NET CHANGE: xmesa.h
101
102 * mesa/src
103 Nov. 25, 1995 v 1.2.4
104 - added the necessary pragma calls for X functions to the following:
105 xmesa1.c, xmesa2.c, xmesa3.c, xfonts.c, glx.c
106 This prevents undefined symbols errors during the linking phase for
107 X library calls
108 - created smakefile
109 Dec. 1, 1995 v 1.2.5
110 - removed AMIWIN includes from xmesa1.c, xmesa2.c, xmesa3.c, xfonts.c,
111 glx.c since they are now defined in include/GL/xmesa.h
112 NET CHANGE: smakefile
113
114 * mesa/src-tk
115 Nov. 25, 1995 v 1.2.4
116 - added the necessary pragma calls for X functions to the following:
117 private.h
118 - created smakefile
119 Dec. 1, 1995 v 1.2.5
120 - removed AMIWIN includes from private.h since it is now defined in
121 include/GL/xmesa.h
122 NET CHANGE: smakefile
123
124 * mesa/src-glu
125 Nov. 25, 1995 v 1.2.4
126 - created smakefile
127 NET CHANGE: smakefile
128
129 * mesa/src-aux
130 Nov. 25, 1995 v 1.2.4
131 - added the necessary pragma calls for X functions to the following:
132 glaux.c
133 - created smakefile
134 NET CHANGE: glaux.c, smakefile
135
136 * mesa/demos
137 Nov. 25, 1995 v 1.2.4
138 - added the necessary pragma calls for X functions to the following:
139 xdemo.c, glxdemo.c, offset.c
140 - created smakefile
141 - put #ifndef AMIWIN ... #endif around sleep() calls in xdemo.c since
142 they are not part of AmigaDOS.
143 Dec. 1, 1995 v 1.2.5
144 - removed AMIWIN defines from xdemo.c, glxdemo.c, offset.c since
145 already defined in include/GL/xmesa.h
146 - modified Smakefile to include header and includes from the AmiTCP4.0
147 net.lib linkable library to provide unix-compatible sys/time.h and
148 the sleep() function
149 - removed AMIWIN defines in xdemo.c since sleep() now defined
150 NET CHANGE: smakefile
151
152 * mesa/samples
153 Nov. 25, 1995 v 1.2.4
154 - added the necessary pragma calls for X functions to the following:
155 oglinfo.c
156 - created smakefile
157 - put #ifndef AMIWIN ... #endif around sleep() in blendxor.c
158 - removed olympic from smakefile targets since <sys/time.h> not defined
159 Dec. 1, 1995 v 1.2.5
160 - removed AMIWIN defines from oglinfo.c, since already defined in
161 include/GL/xmesa.h
162 - modified Smakefile to include header and includes from the AmiTCP4.0
163 net.lib linkable library to provide unix-compatible sys/time.h and
164 the sleep() function
165 - removed AMIWIN defines in blendxor.c for sleep()
166 - added AMIWIN defines around _MACHTEN_ in olympic.c since xrandom()
167 functions are not defined in any libraries
168 - added olympic back into the Smakefile targets
169 NET CHANGE: smakefile, olympic.c
170
171 * mesa/book
172 Nov. 25, 1995 v 1.2.4
173 - created smakefile
174 - removed accpersp and dof from smakefile targets since the SAS/C compile seems to
175 confuse the near,far variables with near/far memory models.
176 NET CHANGE: smakefile
177
178 * mesa/windows
179 Dec. 1, 1995 v 1.2.5
180 - Removed directory to save space since this is only needed for Windows based
181 machines.
182
README.BEOS
1
2 Mesa / BeOS Information
3
4
5
6 * Introduction
7
8 Brian Paul added in Mesa 3.1 a driver for BeOS R4.5 operating system.
9 This driver implements a clone of the BGLView class. This class,
10 derived from BView, allows OpenGL rendering into any BeOS window. His
11 driver was updated in Mesa 4.1 and again in version 6.1 by Philippe
12 Houdoin, who's maintaining this driver since.
13
14 Any application which uses the BGLView should be able to use Mesa
15 instead of Be's OpenGL without changing any code.
16
17 Since Be's OpenGL implementation (as of R5) is basically just the
18 SGI sample implementation, it's pretty slow. You'll see that Mesa
19 is considerably faster.
20
21
22 * Source Code
23
24 The source code for the driver is in src/mesa/drivers/beos/ directory.
25 It's not 100% finished at this time but many GLUT-based demos are
26 working. No optimizations have been made at this time.
27
28
29 * Compiling
30
31 Since Mesa 6.x, it can be build under BeOS with both the R5 builtin gcc version
32 or more recent gcc versions available for BeOS, like this gcc version 2.95.3 for BeOS
33 you can find at http://www.bebits.com/app/2157.
34 Anyway, keep in mind that to take full advantage of Mesa x86 optimizations, you better
35 want to use gcc 2.95.3 or sooner versions...
36
37 To build Mesa-powered BeOS libGL.so version, open an Terminal window,
38 move to Mesa root folder and type this command:
39
40 $ make beos
41
42 Note that the "beos" argument is only needed the first time to setup build config.
43 Next times, typing "make" will be enough.
44
45 When it finishes the Mesa based libGL.so library for
46 BeOS will be in the lib/ directory, along libglut.so library.
47 Several demo/test programs should have been build too under progs/* folders.
48 If it stop when building one of the progs/* programs, you may want to ignore it
49 and force make to move on next target by adding the -k make option:
50
51 $ cd progs
52 $ make -k
53
54 To install it as Be's default libGL.so replacement, put it in your
55 /boot/home/config/lib/ directory. All your GL/GLUT apps will use
56 the Mesa based then.
57
58 By default, it build a non-debug version library.
59 The x86 (MMX, SSE and 3DNOW) optimizations are also supported for x86 target.
60 For PowerPC BeOS flavor, sorry, Mesa don't have ppc (Altivec) optimizations
61 yet.
62
63 To build a DEBUG version, type instead this :
64
65 $ DEBUG=1 make
66
67
68 * Example Programs
69
70 Look under progs/beos/ for some BGLView-based programs.
71 You should find under progs/samples and progs/redbook directories GLUT-based programs too.
72 They all should have been compiled along with the Mesa library.
73
74
75 * GLUT
76
77 A beta version of GLUT 3.7 port for BeOS, made by Jake Hamby, can be found at
78 http://anobject.com/jehamby/Code/Glut-3.7-x86.zip.
79 This is the version currently included in Mesa source code, and
80 build in lib/libglut.so.
81
82 A previous 3.5 version of this GLUT BeOS port used to be available at
83 http://home.beoscentral.com/jehamby/Glut-3.5-x86.zip.
84
85 They're special versions of GLUT for the BeOS platform. I don't
86 believe Mark Kilgard's normal GLUT distribution includes BeOS
87 support.
88
89
90 * Special Features
91
92 Mesa's implementation of the BGLView class has an extra member
93 function: CopySubBufferMESA(). It basically works like SwapBuffers()
94 but it only copies a sub region from the back buffer to the front
95 buffer. This is a useful optimization for some applications.
96 If you use this method in your code be sure that you check at runtime
97 that you're actually using Mesa (with glGetString) so you don't
98 cause a fatal error when running with Be's OpenGL.
99
100
101 * Work Left To Do
102
103 - BDirectWindow single buffering support is not implemented yet.
104 - Color index mode is not implemented yet.
105 - Reading pixels from the front buffer not implemented yet.
106 - There is also a BGLScreen class in BeOS for full-screen OpenGL rendering.
107 This should also be implemented for Mesa.
108 - Multiple renderers add-ons support, first step toward hardware acceleration
109 support.
110
111 * Other contributors to this BeOS port
112
113 Jake Hamby jhamby <at> anobject <dot> com
114 Marcin Konicki ahwayakchih <at> neoni <dot> net
115 Francois Revol revol <at> free <dot> fr
116 Nathan Whitehorn nathanw <at> uchicago <dot> edu
117
118
119 * Older BeOS Driver
120
121 Mesa 2.6 had an earlier BeOS driver. It was based on Mesa's Off-screen
122 rendering interface, not BGLView. If you're interested in the older
123 driver you should get Mesa 2.6.
124
125
126 * BeOS and Glide
127
128 Mesa 3.0 supported the 3Dfx/Glide library on Beos. Download Mesa 3.0
129 if interested. Ideally, the 3Dfx/Glide support should be updated to
130 work with the new Mesa 3.1 BGLView implementation.
131
132 The Glide library hasn't been updated for BeOS R4 and newer, to my knowledge,
133 as of February, 1999.
134
135
136 ----------------------------------------------------------------------
137
README.CYGWIN
1
2 Mesa Cygwin/X11 Information
3
4
5 WARNING
6 =======
7
8 If you installed X11 (packages xorg-x11-devel and xorg-x11-bin-dlls ) with the
9 latest setup.exe from Cygwin the GL (Mesa) libraries and include are already
10 installed in /usr/X11R6.
11
12 The following will explain how to "replace" them.
13
14 Installation
15 ============
16
17 How to compile Mesa on Cygwin/X11 systems:
18
19 1. Shared libs:
20 type 'make cygwin-sl'.
21
22 When finished, the Mesa DLL will be in the Mesa-x.y/lib/ and
23 Mesa-x.y/bin directories.
24
25
26 2. Static libs:
27 type 'make cygwin-static'.
28 When finished, the Mesa libraries will be in the Mesa-x.y/lib/ directory.
29
30 Header and library files:
31 After you've compiled Mesa and tried the demos I recommend the following
32 procedure for "installing" Mesa.
33
34 Copy the Mesa include/GL directory to /usr/X11R6/include:
35 cp -a include/GL /usr/X11R6/include
36
37 Copy the Mesa library files to /usr/X11R6/lib:
38 cp -a lib/* /usr/X11R6ocal/lib
39
40 Copy the Mesa bin files (used by the DLL stuff) to /usr/X11R6/bin:
41 cp -a lib/cyg* /usr/X11R6/bin
42
43 Xt/Motif widgets:
44 If you want to use Mesa or OpenGL in your Xt/Motif program you can build
45 the widgets found in either the widgets-mesa or widgets-sgi directories.
46 The former were written for Mesa and the later are the original SGI
47 widgets. Look in those directories for more information.
48 For the Motif widgets you must have downloaded the lesstif package.
49
50
51 Using the library
52 =================
53
54 Configuration options:
55 The file src/mesa/main/config.h has many parameters which you can adjust
56 such as maximum number of lights, clipping planes, maximum texture size,
57 etc. In particular, you may want to change DEPTH_BITS from 16 to 32
58 if a 16-bit depth buffer isn't precise enough for your application.
59
60
61 Shared libraries:
62 If you compile shared libraries (Win32 DLLS) you may have to set an
63 environment variable to specify where the Mesa libraries are located.
64 Set the PATH variable to include /your-dir/Mesa-2.6/bin.
65 Otherwise, when you try to run a demo it may fail with a message saying
66 that one or more DLL couldn't be found.
67
68
69 Xt/Motif Widgets:
70 Two versions of the Xt/Motif OpenGL drawing area widgets are included:
71
72 widgets-sgi/ SGI's stock widgets
73 widgets-mesa/ Mesa-tuned widgets
74
75 Look in those directories for details
76
77
78 Togl:
79 Togl is an OpenGL/Mesa widget for Tcl/Tk.
80 See http://togl.sourceforge.net for more information.
81
82
83
84 X Display Modes:
85 Mesa supports RGB(A) rendering into almost any X visual type and depth.
86
87 The glXChooseVisual function tries its best to pick an appropriate visual
88 for the given attribute list. However, if this doesn't suit your needs
89 you can force Mesa to use any X visual you want (any supported by your
90 X server that is) by setting the MESA_RGB_VISUAL and MESA_CI_VISUAL
91 environment variables. When an RGB visual is requested, glXChooseVisual
92 will first look if the MESA_RGB_VISUAL variable is defined. If so, it
93 will try to use the specified visual. Similarly, when a color index
94 visual is requested, glXChooseVisual will look for the MESA_CI_VISUAL
95 variable.
96
97 The format of accepted values is: <visual-class> <depth>
98 Here are some examples:
99
100 using the C-shell:
101 % setenv MESA_RGB_VISUAL "TrueColor 8" // 8-bit TrueColor
102 % setenv MESA_CI_VISUAL "PseudoColor 12" // 12-bit PseudoColor
103 % setenv MESA_RGB_VISUAL "PseudoColor 8" // 8-bit PseudoColor
104
105 using the KornShell:
106 $ export MESA_RGB_VISUAL="TrueColor 8"
107 $ export MESA_CI_VISUAL="PseudoColor 12"
108 $ export MESA_RGB_VISUAL="PseudoColor 8"
109
110
111 Double buffering:
112 Mesa can use either an X Pixmap or XImage as the backbuffer when in
113 double buffer mode. Using GLX, the default is to use an XImage. The
114 MESA_BACK_BUFFER environment variable can override this. The valid
115 values for MESA_BACK_BUFFER are: Pixmap and XImage (only the first
116 letter is checked, case doesn't matter).
117
118 A pixmap is faster when drawing simple lines and polygons while an
119 XImage is faster when Mesa has to do pixel-by-pixel rendering. If you
120 need depth buffering the XImage will almost surely be faster. Exper-
121 iment with the MESA_BACK_BUFFER variable to see which is faster for
122 your application.
123
124
125 Colormaps:
126 When using Mesa directly or with GLX, it's up to the application writer
127 to create a window with an appropriate colormap. The aux, tk, and GLUT
128 toolkits try to minimize colormap "flashing" by sharing colormaps when
129 possible. Specifically, if the visual and depth of the window matches
130 that of the root window, the root window's colormap will be shared by
131 the Mesa window. Otherwise, a new, private colormap will be allocated.
132
133 When sharing the root colormap, Mesa may be unable to allocate the colors
134 it needs, resulting in poor color quality. This can happen when a
135 large number of colorcells in the root colormap are already allocated.
136 To prevent colormap sharing in aux, tk and GLUT, define the environment
137 variable MESA_PRIVATE_CMAP. The value isn't significant.
138
139
140 Gamma correction:
141 To compensate for the nonlinear relationship between pixel values
142 and displayed intensities, there is a gamma correction feature in
143 Mesa. Some systems, such as Silicon Graphics, support gamma
144 correction in hardware (man gamma) so you won't need to use Mesa's
145 gamma facility. Other systems, however, may need gamma adjustment
146 to produce images which look correct. If in the past you thought
147 Mesa's images were too dim, read on.
148
149 Gamma correction is controlled with the MESA_GAMMA environment
150 variable. Its value is of the form "Gr Gg Gb" or just "G" where
151 Gr is the red gamma value, Gg is the green gamma value, Gb is the
152 blue gamma value and G is one gamma value to use for all three
153 channels. Each value is a positive real number typically in the
154 range 1.0 to 2.5. The defaults are all 1.0, effectively disabling
155 gamma correction. Examples using csh:
156
157 % setenv MESA_GAMMA "2.3 2.2 2.4" // separate R,G,B values
158 % setenv MESA_GAMMA "2.0" // same gamma for R,G,B
159
160 The demos/gamma.c program may help you to determine reasonable gamma
161 value for your display. With correct gamma values, the color intensities
162 displayed in the top row (drawn by dithering) should nearly match those
163 in the bottom row (drawn as grays).
164
165 Alex De Bruyn reports that gamma values of 1.6, 1.6 and 1.9 work well
166 on HP displays using the HP-ColorRecovery technology.
167
168 Mesa implements gamma correction with a lookup table which translates
169 a "linear" pixel value to a gamma-corrected pixel value. There is a
170 small performance penalty. Gamma correction only works in RGB mode.
171 Also be aware that pixel values read back from the frame buffer will
172 not be "un-corrected" so glReadPixels may not return the same data
173 drawn with glDrawPixels.
174
175 For more information about gamma correction see:
176 http://www.inforamp.net/~poynton/notes/colour_and_gamma/GammaFAQ.html
177
178
179 Overlay Planes
180
181 Overlay planes in the frame buffer are supported by Mesa but require
182 hardware and X server support. To determine if your X server has
183 overlay support you can test for the SERVER_OVERLAY_VISUALS property:
184
185 xprop -root | grep SERVER_OVERLAY_VISUALS
186
187
188 HPCR glClear(GL_COLOR_BUFFER_BIT) dithering
189
190 If you set the MESA_HPCR_CLEAR environment variable then dithering
191 will be used when clearing the color buffer. This is only applicable
192 to HP systems with the HPCR (Color Recovery) system.
193
194
195 Extensions
196 ==========
197 There are three Mesa-specific GLX extensions at this time.
198
199 GLX_MESA_pixmap_colormap
200
201 This extension adds the GLX function:
202
203 GLXPixmap glXCreateGLXPixmapMESA( Display *dpy, XVisualInfo *visual,
204 Pixmap pixmap, Colormap cmap )
205
206 It is an alternative to the standard glXCreateGLXPixmap() function.
207 Since Mesa supports RGB rendering into any X visual, not just True-
208 Color or DirectColor, Mesa needs colormap information to convert RGB
209 values into pixel values. An X window carries this information but a
210 pixmap does not. This function associates a colormap to a GLX pixmap.
211 See the xdemos/glxpixmap.c file for an example of how to use this
212 extension.
213
214 GLX_MESA_release_buffers
215
216 Mesa associates a set of ancillary (depth, accumulation, stencil and
217 alpha) buffers with each X window it draws into. These ancillary
218 buffers are allocated for each X window the first time the X window
219 is passed to glXMakeCurrent(). Mesa, however, can't detect when an
220 X window has been destroyed in order to free the ancillary buffers.
221
222 The best it can do is to check for recently destroyed windows whenever
223 the client calls the glXCreateContext() or glXDestroyContext()
224 functions. This may not be sufficient in all situations though.
225
226 The GLX_MESA_release_buffers extension allows a client to explicitly
227 deallocate the ancillary buffers by calling glxReleaseBuffersMESA()
228 just before an X window is destroyed. For example:
229
230 #ifdef GLX_MESA_release_buffers
231 glXReleaseBuffersMESA( dpy, window );
232 #endif
233 XDestroyWindow( dpy, window );
234
235 This extension is new in Mesa 2.0.
236
237 GLX_MESA_copy_sub_buffer
238
239 This extension adds the glXCopySubBufferMESA() function. It works
240 like glXSwapBuffers() but only copies a sub-region of the window
241 instead of the whole window.
242
243 This extension is new in Mesa version 2.6
244
245
246
247 Summary of X-related environment variables:
248 MESA_RGB_VISUAL - specifies the X visual and depth for RGB mode (X only)
249 MESA_CI_VISUAL - specifies the X visual and depth for CI mode (X only)
250 MESA_BACK_BUFFER - specifies how to implement the back color buffer (X only)
251 MESA_PRIVATE_CMAP - force aux/tk libraries to use private colormaps (X only)
252 MESA_GAMMA - gamma correction coefficients (X only)
253
254
255 ----------------------------------------------------------------------
256 README.CYGWIN - lassauge April 2004 - based on README.X11
257
README.DJ
1 Mesa 6.5 DOS/DJGPP Port v1.8
2 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3
4
5
6 Description:
7 ~~~~~~~~~~~~
8
9 Well, guess what... this is the DOS port of Mesa 6.5, for DJGPP fans... Whoa!
10 The driver uses OSMesa to draw off screen, and then blits the buffer. This is
11 not terribly efficient, and has some drawbacks, but saves maintenance costs.
12
13
14
15 Legal:
16 ~~~~~~
17
18 Mesa copyright applies.
19
20
21
22 Installation:
23 ~~~~~~~~~~~~~
24
25 Unzip and type:
26
27 make -f Makefile.DJ [OPTIONS...]
28
29 Available options:
30
31 Environment variables:
32 CPU optimize for the given processor.
33 default = pentium
34 GLIDE path to Glide3 SDK; used with FX.
35 default = $(TOP)/glide3
36 FX=1 build for 3dfx Glide3. Note that this disables
37 compilation of most DMesa code and requires fxMesa.
38 As a consequence, you'll need the DJGPP Glide3
39 library to build any application.
40 default = no
41 X86=1 optimize for x86 (if possible, use MMX, SSE, 3DNow).
42 default = no
43
44 Targets:
45 all: build everything
46 libgl: build GL
47 libglu: build GLU
48 libglut: build GLUT
49 clean: remove object files
50 realclean: remove all generated files
51
52
53
54 Tested on:
55 Video card: Radeon 9500
56 DJGPP: djdev 2.04 + gcc v4.1.0 + make v3.80
57 OS: DOS, Win98SE, WinXP (using Videoport driver)
58
59
60
61 FAQ:
62 ~~~~
63
64 1. Compilation
65
66 Q) `make' barfs and exits because it cannot find some stupid file.
67 A) You need LFN support.
68 A) When compiling for Glide (FX=1), pay attention to Glide path.
69
70 Q) Libraries built OK, but linker complains about `vsnprintf' every time I
71 compile some demo.
72 A) Upgrade to DJGPP 2.04.
73 A) Add `vsnprintf.c' to the CORE_SOURCES in `src/Makefile.DJ' (untested!).
74 A) Patch `src/mesa/main/imports.c' with the following line:
75 #define vsnprintf(buf, max, fmt, arg) vsprintf(buf, fmt, arg)
76 This hack should be safe in 90% of the cases, but if anything goes wrong,
77 don't come back to me crying.
78
79 Q) `make' complains about DXE3 or something, yet it builds the libraries.
80 A) DXE3 refers to the DJGPP dynamic modules. You'll need either the latest
81 DJGPP distro, or download the separate package from my web page. Read the
82 DXE3 documentation on how to use them.
83 A) When compiling for Glide (FX=1), make sure `glide3x.dxe' can be found in
84 LD_LIBRARY_PATH (or top `lib' directory).
85
86 2. Using Mesa for DJGPP
87
88 Q) Every test I tried crashes badly.
89 A) If you have compiled with SSE and you're running under plain DOS, you
90 have to disable SSE at run-time. See environment variables below.
91
92 Q) DMesa is so SLOOOW! The Win32 OpenGL performs so much better...
93 A) Is that a question? If you have a 3dfx Voodoo (any model), you're
94 lucky (check http://sourceforge.net/projects/glide for the DJGPP port).
95 If you haven't, sorry; everything is done in software.
96
97 Q) I tried to set refresh rate w/ DMesa, but without success.
98 A) Refresh rate control works only for VESA 3.0 and the 3dfx driver (in
99 which case FX_GLIDE_REFRESH will be overwritten if it is defined and
100 is not 0).
101
102 Q) I made a simple application and it does nothing. It exits right away. Not
103 even a blank screen.
104 A) Software drivers (VESA/VGA/NUL) must to be constructed as single-buffered
105 visuals. However, DMesaSwapBuffers must be called to get any output.
106 A) Another weird "feature" is that buffer width must be multiple of 8 (I'm a
107 lazy programmer and I found that the easiest way to keep buffer handling
108 at peak performance ;-).
109
110 Q) I'm getting a "bad font!" fatal error.
111 A) Always use GLUT_STROKE_* and GLUT_BITMAP_* constants when dealing with
112 GLUT fonts. If you're using `glut.dxe', then make sure GLUT_STROKE_* and
113 GLUT_BITMAP_* are mapped to integer constants, not to the actual font
114 address (same mechanism used for Win32 _DLL).
115
116 Q) What is NUL driver good for, if I don't get any output at all?
117 A) For debugging. The NUL driver is very much like OSMesa. Everything is
118 done just the same as VESA/VGA drivers, only it doesn't touch your video
119 hardware. You can query the actual buffer by issuing:
120 DMesaGetIntegerv(DMESA_GET_BUFFER_ADDR, &buffer);
121 and dump it to a file.
122
123 Q) How do I query for a list of available video modes to choose as a visual?
124 A) This is an ugly hack, for which I'm sure I'll burn in hell.
125 First, query for a list of modes:
126 n = DMesaGetIntegerv(DMESA_GET_VIDEO_MODES, NULL);
127 If `n' is strictly positive, you allocate an array of pointers to a given
128 struct (which is guaranteed to be extended only - not changed in future):
129 struct {
130 int xres, yres;
131 int bpp;
132 } **l = malloc(n * sizeof(void *));
133 Now pass the newly allocated buffer to fill in:
134 DMesaGetIntegerv(DMESA_GET_VIDEO_MODES, (GLint *)l);
135 And collect the info:
136 for (i = 0; i < n; i++) {
137 printf("%dx%d:%d\n", l[i]->xres, l[i]->yres, l[i]->bpp);
138 }
139
140 Q) The GLUT is incomplete.
141 A) See below.
142
143
144
145 libGLUT (the toolkit):
146 ~~~~~~~~~~~~~~~~~~~~~~
147
148 Well, this "skeletal" GLUT implementation was taken from AllegGL project and
149 heavily changed. Thanks should go to Bernhard Tschirren, Mark Kilgard, Brian
150 Paul and probably others (or probably not ;-). GLUT functionality will be
151 extended only on an "as needed" basis.
152
153 GLUT talks to hardware via PC_HW package which was put together from various
154 pieces I wrote long time ago. It consists from the keyboard, mouse and timer
155 drivers.
156
157 My keyboard driver used only scancodes; as GLUT requires ASCII values for keys,
158 I borrowed the translation tables (and maybe more) from Allegro -- many thanks
159 to Shawn Hargreaves et co. Ctrl-Alt-Del (plus Ctrl-Alt-End, for Windows users)
160 will shut down the GLUT engine unconditionally: it will raise SIGINT, which in
161 turn will (hopefully) call the destructors, thus cleaning up your/my mess ;-)
162 NB: since the DJGPP guys ensured signal handlers won't go beyond program's
163 space (and since dynamic modules shall) the SIGINT can't be hooked (well, it
164 can, but it is useless), therefore you must live with the 'Exiting due to
165 signal SIGINT' message...
166
167 The mouse driver is far from complete (lack of drawing, etc), but is enough to
168 make almost all the demos work. Supports the CuteMouse WheelAPI.
169
170 The timer is pretty versatile for it supports multiple timers with different
171 frequencies. While not being the most accurate timer in the known universe, I
172 think it's OK. Take this example: you have timer A with a very high rate, and
173 then you have timer B with very low rate compared to A; now, A ticks OK, but
174 timer B will probably loose precision!
175
176 As an addition, stdout and stderr are redirected and dumped upon exit. This
177 means that `printf' can be safely called during graphics. A bit of a hack, I
178 know, because all messages come in bulk, but I think it's better than nothing.
179 "Borrowed" from LIBRHUTI (Robert Hoehne).
180
181 Window creating defaults: (0, 0, 300, 300), 16bpp. However, the video mode is
182 chosen in such a way that first window will fit. If you need high resolution
183 with small windows, set initial position far to the right (or way down); then
184 you can move them back to any position right before the main loop.
185
186
187
188 Environment variables:
189 ~~~~~~~~~~~~~~~~~~~~~~
190 DMESA_NULDRV - (any value) force NUL driver
191 GLUT_FPS - print frames/second statistics to stderr
192 MESA_NO_SSE - (any value) safe option under pure DOS
193 DMESA_GLUT_REFRESH - set vertical screen refresh rate (VESA3)
194 DMESA_GLUT_BPP - set default bits per pixel (VGA needs 8)
195 DMESA_GLUT_ALPHA - set default alpha bits (8)
196 DMESA_GLUT_DEPTH - set default depth bits (16)
197 DMESA_GLUT_STENCIL - set default stencil bits (8)
198 DMESA_GLUT_ACCUM - set default accum bits (16)
199
200
201
202 History:
203 ~~~~~~~~
204
205 v1.0 (mar-2002)
206 initial release
207
208 v1.1 (sep-2002)
209 + added 3dfx Glide3 support
210 + added refresh rate control
211 + added fonts in GLUT
212 * lots of minor changes
213
214 v1.2 (nov-2002)
215 * synced w/ Mesa-4.1
216 - removed dmesadxe.h
217
218 v1.3 (mar-2003)
219 + enabled OpenGL 1.4 support
220 + added MMX clear/blit routines
221 + enabled SGI's GLU compilation
222 + added samples makefile
223 + added new GLUT functions
224 + added color-index modes
225 + added Matrox Millennium MGA2064W driver
226 + added 8bit FakeColor (thanks to Neil Funk)
227 + added VGA support (to keep Ben Decker happy)
228 ! fixed some compilation errors (reported by Chan Kar Heng)
229 * optimized driver for faster callback access... yeah, right :)
230 * overhauled virtual buffer and internal video drivers
231 * better fxMesa integration
232 * revamped GLUT
233 * switched to DXE3
234
235 v1.4 (dec-2003)
236 + enabled GLUT fonts with DXE
237 + truly added multi-window support in GLUT (for Adrian Woodward)
238 * accomodated makefiles with the new sourcetree
239 * fixed some ALPHA issues
240 * minor changes to PC_HW/timer interface
241 x hacked and slashed the 3dfx driver (w/ help from Hiroshi Morii)
242
243 v1.5 (jan-2004)
244 + added interface to query available "visuals" (GLFW - Marcus Geelnard)
245 + added GLUT timer callback
246 - removed Matrox Millennium MGA2064W driver
247 x more changes to the 3dfx driver
248
249 v1.6 (aug-2004)
250 + implemented NUL driver
251 + added DMesaGetProcAddress and glutGetProcAddress
252 * reorganized fxMesa wrapper to handle multiple contexts
253 ! fixed a horrible bug in VGA initialization routine
254 ! fixed partial clears
255
256 v1.7 (???-2005)
257 + enabled OpenGL 2.0 support
258 + added support for sw texture compression
259 + added FreeGLUT specific functions
260 * no more GLX sources in DOS GLUT
261 * made GLUT timer callbacks less accurate but safer
262
263 v1.8 (apr-2006)
264 * killed lots of code, the driver is now a front-end to OSMesa
265 * fixed problem with WinNT (http://www.volny.cz/martin.sulak/)
266 - removed 3dfx Glide3 support (temporarily?)
267
268
269
270 Contact:
271 ~~~~~~~~
272
273 Name: Daniel Borca
274 E-mail: dborca (a] users.sourceforge.net
275 WWW: http://www.geocities.com/dborca/
276
README.GGI
1 GGIMesa for LibGGI 2.x
2
3 Requirements:
4 -------------
5 LibGGI 2.0 or greater
6
7 Installation:
8 -------------
9 To install GGIMesa, follow the instructions in INSTALL.GNU. If you
10 wish to install GGIGLUT as well, first install GGIMesa and then run
11
12 make
13 make install (must be root)
14
15 in ggi/ggiglut.
16
17 Notes:
18 ------
19
20 * Set the environment variables GGIMESA_DEBUG and/or GGIGLUT_DEBUG
21 to 255 to see lots of debugging output.
22
23 * GGIGLUT contains support for all of the GLUT 3.6 API except for the
24 high-level primitive drawing functions, but many of the functions (in
25 particular the menu drawing functions) are just stubs.
26
27
README.LYNXOS
1
2 Mesa 3.0 for LynxOS builds in the following way:
3
4 make lynxos
5
6 This will build all the libraries and demo applications. You should have
7 around 400 megabytes free for everything since everything is done with
8 static
9 libraries.
10
11 Before using this make file however, you should perform the following
12 actions:
13 0) cd to the Mesa-3.0 directory
14 1) Copy the GL directory under the include directory to /usr/include.
15 2) Copy the files in the lib directory to /lib.
16 3) Make links so that the Mesa libraries look like ordinary OpenGL
17 libraries
18 in /lib. This is important for compatibility with other OpenGL apps. This
19 is done as follows:
20
21 cd /lib
22 ln -s libMesaGL.a libGL.a
23 ln -s libMesaGLU.a libGLU.a
24
25 Mesa 3.0 includes the GLUT (GL Utility Toolkit) by default.
26 The demo applications are done using this toolkit.
27
28 Mesa makefiles for building their apps could be used as well, but the
29 following one is much more concise. Note that the order of the X libraries
30 is important to the linker so that all symbols get resolved correctly.
31 Changing the order may result in having to list a library twice to make
32 sure all linkages are made correctly.
33
34 ----cut here for Makefile -----
35
36 FILES = your_app.x
37
38 SPECIAL_INCLUDES = -I/usr/include/GL
39
40 SPECIAL_CFLAGS = -g -ansi -pedantic -funroll-loops -ffast-math -DSHM
41
42 SPECIAL_LIBS = -lglut -lGLU -lGL -lm -L/usr/X11/lib -lXext -lXmu -lXi \
43 -lX11 -lbsd -g
44
45 STANDARD_OFILES = $(FILES:.x=.o)
46
47 %.o: %.c
48 gcc -c $(SPECIAL_CFLAGS) $(SPECIAL_INCLUDES) $< -o $@
49
50 all: $(STANDARD_OFILES)
51 gcc -o your_app $(STANDARD_OFILES) $(SPECIAL_LIBS)
52
53
54 ----cut here for Makefile-----
55
56 I have tested Mesa under LynxOS 3.0 and 3.01. It should build fine under
57 other
58 versions as well. Note, however, that LynxOS versions prior to 3.0 are not
59 binary compatible, so you will have to rebuild from source.
60
61
62 Vik Sohal
63 vik (a] lynx.com
64 January 13, 1999
65
README.MINGW32
1 Mesa 6.1 for MinGW32
2 ~~~~~~~~~~~~~~~~~~~~
3
4
5
6 Quick & dirty start:
7 --------------------
8
9 mingw32-make -f Makefile.mgw [OPTIONS...]
10
11 Look into the corresponding makefiles for further information.
12 Check README.3DFX to find out how to compile Mesa Glide3 driver
13 with MinGW32!
14
15
16
17 *******************************************************************************
18 The Mingw port for Mesa 3-D Graphics Library was created August 30, 1998 by Paul Garceau.
19
20 Updated January 13, 2000; June 3, 2005 -- Paul Garceau <pgarceau (a] users.sourceforge.net>
21
22 DISCLAIMER: I make this port of the Mesa 3-D Graphics Library as a service
23 to the general public. I can, in no way support or make any guarantee that the
24 build will work for your system.
25
26 Acknowledgements:
27
28 Daniel Borca, whose work and commitment to maintaining the Mingw port of the Mesa 3-D Graphics Library has been, and will continue to be greatly appreciated by an overworked and underpaid developer such as myself.
29 Without the creative inspiration and personal commitment provided by Mumit Khan, Jan-Jaap Vanderhagen and Colin Peters, Mingw would never have existed. Acknowledgements also need to be given to all of the developers who have worked on Mingw, Mesa and Msys over the years.
30 Last, but certainly far from the least, Brian Paul, who has dedicated at least the last seven or eight years of his life to making Mesa 3-D Graphics Library what it is today and managing the development for all of those years.
31 *********************************************************************************
32
33 Greetings,
34
35 Feel free to modify or change things related to the Mingw build as you see fit, just remember that, the author of the current build may not be able to support any modifications you might want to make to the files which have been included for the build.
36
37 Mesa core components are licensed under XFree-86 (for more on licensing of Mesa 3-D Graphics Library, check out the Mesa homepage (http://www.mesa3d.org).
38
39 The Mingw generated libraries themselves are licensed under the GNU-LGPL license. Source code for Mingw can be found at http://www.mingw.org. For licensing terms on Mingw, please visit http://www.mingw.org.
40
41 It is recommended that you use the latest "stable" release of Mingw. "Candidates" are beta testing distributions for Mingw. Mingw is available at http://www.mingw.org.
42
43 This build has been tested under WinNT4/SP6. Win9x and WinNT5 remain untested by me. I have not tested any of the demos included with Mesa3d.
44
45 Installation:
46
47 This readme assumes that you already have extracted the necessary files to a working directory/folder that Mingw can use to build the Mesa3D libraries and that you know where that directory/folder is located on your Windows system. If you have any questions about how to set things up properly which is specific to Mesa3D, the folks on the Mesa3D mailing lists (http://www.mesa3d.org) would probably be happy to assist you. Also you can probably ask anyone on the Mingw mailing lists for any questions specific to Mingw (http://www.mingw.org)
48
49 Targets and Environment variables used for Mingw build:
50
51 Before going into the actual build of the libraries, here is a list of available targets for the make process:
52
53 "all" or "libgl" -- this target will build libopengl.a, a static library. It will not build the demos, etc.
54
55 clean -- this target will clean up most of the Mesa 3-D Graphics Library/object code from your hard drive.
56
57 realclean -- this target will clean up all of the Mesa 3D Graphics Library and the Mesa object code that it can find.
58
59 Environment Variables:
60
61 The environment variables are used to determine what sort of graphics driver support needs to be included in the finished Mesa 3-D Graphics Library.
62
63 GLIDE path to Glide3 SDK; used with FX.
64 default = $(TOP)/glide3
65 FX=1 build for 3dfx Glide3. Note that this disables
66 compilation of most WMesa code and requires fxMesa.
67 As a consequence, you'll need the Win32 Glide3
68 library to build any application.
69 default = no
70 ICD=1 build the installable client driver interface
71 (windows opengl driver interface)
72 default = no
73 X86=1 optimize for x86 (if possible, use MMX, SSE, 3DNow).
74 default = no
75
76
77 Running the Build:
78
79 Launch Mingw.
80 From the Windows Command Prompt:
81 Set Environment Variables (as needed).
82 "cd" to your Mesa3D 'root' directory.
83 Enter "mingw32-make -f makefile.mgw <target>
84
85 That's all there is to it.
86
87 Enjoy!
88
89 Paul G. <pgarceau (a] users.sourceforge.net>
90 Daniel Borca <dborca (a] users.sourceforge.net>
91
92
93
94 ******This section is added by Heromyth <zxpmyth (a] yahoo.com.cn>*************
95
96 ====================
97 Updated on 2007-7-21
98 ====================
99
100 Notice:
101 1) The generated DLLs are *not* compatible with the ones built
102 with the other compilers like VC8, especially for GLUT.
103
104 2) Although more tests are needed, it can be used individually!
105
106 3) You can set the options about whether using STDCALL to build MESA. The
107 config file is <Mesa3D-root>\configs\config.mgw. The default setting is that:
108 ALL_USING_STDCALL = 1
109 , which means using STDCALL to build MESA.
110
111 4) Of course, you can MESA without using STDCALL,I like this:)
112 The setting is :
113 ALL_USING_STDCALL = 0
114 To do this, however, you must modify wingdi.h which is in MingW's include dir.
115 For example, run:
116 notepad C:\MingW\include\wingdi.h
117 , and delete all the lines where all the wgl*() functions are. Because they would
118 be conflicted with the ones in <Mesa3D-root>\include\GL\mesa_wgl.h.
119
120 >>>>>>>>>> Conflicted Functions List >>>>>>>>>>
121 WINGDIAPI BOOL WINAPI wglCopyContext(HGLRC,HGLRC,UINT);
122 WINGDIAPI HGLRC WINAPI wglCreateContext(HDC);
123 WINGDIAPI HGLRC WINAPI wglCreateLayerContext(HDC,int);
124 WINGDIAPI BOOL WINAPI wglDeleteContext(HGLRC);
125 WINGDIAPI BOOL WINAPI wglDescribeLayerPlane(HDC,int,int,UINT,LPLAYERPLANEDESCRIPTOR);
126 WINGDIAPI HGLRC WINAPI wglGetCurrentContext(void);
127 WINGDIAPI HDC WINAPI wglGetCurrentDC(void);
128 WINGDIAPI int WINAPI wglGetLayerPaletteEntries(HDC,int,int,int,COLORREF*);
129 WINGDIAPI PROC WINAPI wglGetProcAddress(LPCSTR);
130 WINGDIAPI BOOL WINAPI wglMakeCurrent(HDC,HGLRC);
131 WINGDIAPI BOOL WINAPI wglRealizeLayerPalette(HDC,int,BOOL);
132 WINGDIAPI int WINAPI wglSetLayerPaletteEntries(HDC,int,int,int,const COLORREF*);
133 WINGDIAPI BOOL WINAPI wglShareLists(HGLRC,HGLRC);
134 WINGDIAPI BOOL WINAPI wglSwapLayerBuffers(HDC,UINT);
135 WINGDIAPI BOOL WINAPI wglUseFontBitmapsA(HDC,DWORD,DWORD,DWORD);
136 WINGDIAPI BOOL WINAPI wglUseFontBitmapsW(HDC,DWORD,DWORD,DWORD);
137 WINGDIAPI BOOL WINAPI wglUseFontOutlinesA(HDC,DWORD,DWORD,DWORD,FLOAT,FLOAT,int,LPGLYPHMETRICSFLOAT);
138 WINGDIAPI BOOL WINAPI wglUseFontOutlinesW(HDC,DWORD,DWORD,DWORD,FLOAT,FLOAT,int,LPGLYPHMETRICSFLOAT);
139 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
140
141 ====================
142 Updated on 2007-7-22
143 ====================
144 I havn't thought that I would find a better way to solve my problems so soon.
145 I changed the method in which the import-libs and DLLs are made. After this update,
146 the DLLs of MESA are more optimized and more compatible.
147 It seems that there is no need to keep the building way of 'NO-STDCALL'.The
148 way of USING_STDCALL is so nice! The file <Mesa3D-root>\configs\config.mgw is
149 also not needed, and can be deleted safely!
150
151
152
153 *********************************************************************************
README.MITS
1
2 Mesa 3.0 MITS Information
3
4
5 This software is distributed under the terms of the GNU Library
6 General Public License, see the LICENSE file for details.
7
8
9 This document is a preliminary introduction to help you get
10 started. For more detaile information consult the web page.
11
12 http://10-dencies.zkm.de/~mesa/
13
14
15
16 Version 0.1 (Yes it's very alpha code so be warned!)
17 Contributors:
18 Emil Briggs (briggs (a] bucky.physics.ncsu.edu)
19 David Bucciarelli (tech.hmw (a] plus.it)
20 Andreas Schiffler (schiffler (a] zkm.de)
21
22
23
24 1. Requirements:
25 Mesa 3.0.
26 An SMP capable machine running Linux 2.x
27 libpthread installed on your machine.
28
29
30 2. What does MITS stand for?
31 MITS stands for Mesa Internal Threading System. By adding
32 internal threading to Mesa it should be possible to improve
33 performance of OpenGL applications on SMP machines.
34
35
36 3. Do applications have to be recoded to take advantage of MITS?
37 No. The threading is internal to Mesa and transparent to
38 applications.
39
40
41 4. Will all applications benefit from the current implementation of MITS?
42 No. This implementation splits the processing of the vertex buffer
43 over two threads. There is a certain amount of overhead involved
44 with the thread synchronization and if there is not enough work
45 to be done the extra overhead outweighs any speedup from using
46 dual processors. You will not for example see any speedup when
47 running Quake because it uses GL_POLYGON and there is only one
48 polygon for each vertex buffer processed. Test results on a
49 dual 200 Mhz. Pentium Pro system show that one needs around
50 100-200 vertices in the vertex buffer before any there is any
51 appreciable benefit from the threading.
52
53
54 5. Are there any parameters that I can tune to try to improve performance.
55 Yes. You can try to vary the size of the vertex buffer which is
56 define in VB_MAX located in the file src/vb.h from your top level
57 Mesa distribution. The number needs to be a multiple of 12 and
58 the optimum value will probably depend on the capabilities of
59 your machine and the particular application you are running.
60
61
62 6. Are there any ways I can modify the application to improve its
63 performance with the MITS?
64 Yes. Try to use as many vertices between each Begin/End pair
65 as possbile. This will reduce the thread synchronization
66 overhead.
67
68
69 7. What sort of speedups can I expect?
70 On some benchmarks performance gains of up to 30% have been
71 observerd. Others may see no gain at all and in a few rare
72 cases even some degradation.
73
74
75 8. What still needs to be done?
76 Lots of testing and benchmarking.
77 A portable implementation that works within the Mesa thread API.
78 Threading of additional areas of Mesa to improve performance
79 even more.
80
81
82
83 Installation:
84
85 1. This assumes that you already have a working Mesa 3.0 installation
86 from source.
87 2. Place the tarball MITS.tar.gz in your top level Mesa directory.
88 3. Unzip it and untar it. It will replace the following files in
89 your Mesa source tree so back them up if you want to save them.
90
91
92 README.MITS
93 Make-config
94 Makefile
95 mklib.glide
96 src/vbxform.c
97 src/vb.h
98
99 4. Rebuild Mesa using the command
100
101 make linux-386-glide-mits
102
103
README.NeXT
1 The NeXT support has now been incorporated into the OpenStep support.
2 You can build NeXT libraries simply by typing "make next", though before
3 linking they will need to be ranlib'd by hand. For more information see
4 the README.OpenStep file, together with the README files in OpenStep/Old_Demos.
5
6 -Pete French. (pete (a] ohm.york.ac.uk) 28/5/1998
7
README.OpenStep
1 This is a port of the GL and GLU libraries to NeXT/Apple object
2 orientated systems. As these systems have their own window handling
3 systems we simply use the offscreen rendering capability of Mesa
4 to generate bitmaps which may then be displayed by the application
5 with a View as required. Example pieces of code may be found in the
6 OpenStep directory.
7
8 Sadly there are now a proliferation of different system that we need to
9 support compilation for: The original NextStep system, The OpenStep
10 system, the Rhapsody/Mac OS X system and also the windows implementations
11 of the latter two systems. This version of the code has been compiled and
12 tested under the following architectures:
13
14 NextStep 3.3
15 OpenStep 4.2
16 Rhapsody DR2
17 WebObjects for NT 3.5
18 WebObjects for NT 4.0
19
20 All tests were done with Intel processors. Feedback on other systems would,
21 however, be appreciated !
22
23 On UNIX systems simply type "make openstep". Under Windows systems
24 with WebObjects run the "win32-openstep.sh" script from within the Bourne
25 shell provided with the development environment. In both cases this will
26 build the libraries and place them into the "lib" directory. Some examples
27 may be found in the OpenStep directory showing how to use the code in an
28 actual application (MesaView) as well as some command line demos.
29
30 The CC variable may be specified on the command line for doing such things
31 as building FFAT libraries or using alternative compilers to the standard 'cc'
32 e.g. make CC='cc -arch m68k -arch i386' openstep" will build the libraries
33 with both intel and motorola architectures.
34
35 -Pete French. (pete (a] ohm.york.ac.uk) 7/6/1999
36
README.OS2
1 README for port of Mesa 3.x to XFree86 on OS/2 (X/2)
2 (as of 19990514)
3
4
5 Contents:
6
7 1) Binary release
8 2) Building from sources
9 3) History
10 4) Todo
11 5) Mesa Home Page
12
13
14 1) Binary release
15
16 Though the Mesa sources should build in a quite reasonable time even on
17 a 585 class machine a binary relase is available (check topic 4) for an URL)
18 This package includes:
19
20 - lib/MesaGL.dll, MesaGL.a
21 - lib/MesaGLU.dll, MesaGLU.a
22 - lib/glut.dll, glut.a
23 - include/GL/*.h
24
25 Installing this in your XFree86 tree will enable you to build and
26 run all applications compatible with Mesa (and the current DLL
27 interface, of course ;-)
28 As usual the OMF-style libraries can be created using emxomf.
29 (e.g. "emxomf foo.a" creates the foo.lib omf-style library).
30 The static libraries are rarely used and you have to rebuild
31 Mesa to get them. They're a supported target, so you get
32 them in a straightforward way (see below).
33
34 The testing of these libraries was limited to the supplied
35 demos/examples and a quite small number of third-party apps.
36 No warranty ... as usual ... ;-)
37
38
39 2) Instructions to build Mesa 3.x for XFree86/OS2 from sources:
40
41 Except the official Mesa source distribution you need:
42 - a recent version of XFree86 (3.3.x or above) including
43 the programming libraries
44 - EMX 0.9c (0.9d might work, never checked)
45 - GNU make
46 - REXX (!)
47
48 The creation of the DLLs as well as of the static libraries
49 (if you want to have them) is handled in "mklib-emx.cmd",
50 a small REXX script. Perhaps not the best idea, but this
51 way it fits best in the scheme used to build libraries
52 on all platforms in Mesa 3.x.
53
54 To actually build the libraries and demos, check mklib-emx.cmd
55 and modify it as desired. Then type
56 make os2-x11
57 and wait for completion ;-)
58
59
60 3) History
61
62 Initially Darren Abbott (abbott (a] hiwaay.net) ported Mesa versions 2.x
63 to XFree86 OS/2. This port might still be available from
64 http://fly.HiWAAY.net/~abbott/xfree86-os2/xfree86.html
65
66 The current port picked up things during the beta test for 3.0.
67 No major changes in the source were done. The build mechanism under OS/2
68 has been made very similar to other platforms (if you treat mklib-emx.cmd
69 as a "black box").
70 Advantage is that X/2 is now a valid target and all files are
71 integrated in the official source distribution.
72 Disadvantage is that this port (i.e. the DLLs' interface itself) is
73 definitly NOT COMPATIBLE to those of version 2.x.
74 It's uncertain whether this would be at all possible but since there
75 a _very_ few those apps it's not worth to find out anyway.
76 Also some libs (MesaTK, MesaAUX) are withdrawn from the Mesa distribution,
77 and accordingly from the OS/2 port.
78
79 4) Todo
80
81 By now binary compatiblity is ensured by using the function names
82 as entry points instead of ordinals. This might cost performance and
83 is subject to change in future. In addition the supplied X86 assembler
84 source is not used yet.
85
86 5) Mesa Home Page
87
88 You can get the source code and more information about Mesa from
89 http://www.mesa3d.org/
90
91 The OS/2 ports should be available from
92 http://r350.ee.ntu.edu.tw/~hcchu/os2/ports
93
94 --
95 Alexander Mai
96 st002279 (a] hrzpub.tu-darmstadt.de
97
README.QUAKE
1
2 Info on using Mesa 3.0 with Linux Quake I and Quake II
3
4
5
6 Disclaimer
7 ----------
8
9 I am _not_ a Quake expert by any means. I pretty much only run it to
10 test Mesa. There have been a lot of questions about Linux Quake and
11 Mesa so I'm trying to provide some useful info here. If this file
12 doesn't help you then you should look elsewhere for help. The Mesa
13 mailing list or the news://news.3dfx.com/3dfx.linux.glide newsgroup
14 might be good.
15
16 Again, all the information I have is in this file. Please don't email
17 me with questions.
18
19 If you have information to contribute to this file please send it to
20 me at brianp (a] elastic.avid.com
21
22
23
24 Linux Quake
25 -----------
26
27 You can get Linux Quake from http://www.idsoftware.com/
28
29 Quake I and II for Linux were tested with, and include, Mesa 2.6. You
30 shouldn't have too many problems if you simply follow the instructions
31 in the Quake distribution.
32
33
34
35 RedHat 5.0 Linux problems
36 -------------------------
37
38 RedHat Linux 5.x uses the GNU C library ("glibc" or "libc6") whereas
39 previous RedHat and other Linux distributions use "libc5" for its
40 runtime C library.
41
42 Linux Quake I and II were compiled for libc5. If you compile Mesa
43 on a RedHat 5.x system the resulting libMesaGL.so file will not work
44 with Linux Quake because of the different C runtime libraries.
45 The symptom of this is a segmentation fault soon after starting Quake.
46
47 If you want to use a newer version of Mesa (like 3.x) with Quake on
48 RedHat 5.x then read on.
49
50 The solution to the C library problem is to force Mesa to use libc5.
51 libc5 is in /usr/i486-linux-libc5/lib on RedHat 5.x systems.
52
53 Emil Briggs (briggs (a] tick.physics.ncsu.edu) nicely gave me the following
54 info:
55
56 > I only know what works on a RedHat 5.0 distribution. RH5 includes
57 > a full set of libraries for both libc5 and glibc. The loader ld.so
58 > uses the libc5 libraries in /usr/i486-linux-libc5/lib for programs
59 > linked against libc5 while it uses the glibc libraries in /lib and
60 > /usr/lib for programs linked against glibc.
61 >
62 > Anyway I changed line 41 of mklib.glide to
63 > GLIDELIBS="-L/usr/local/glide/lib -lglide2x -L/usr/i486-linux-libc5/lib"
64 >
65 > And I started quake2 up with a script like this
66 > #!/bin/csh
67 > setenv LD_LIBRARY_PATH /usr/i486-linux-libc5/lib
68 > setenv MESA_GLX_FX f
69 > ./quake2 +set vid_ref gl
70 > kbd_mode -a
71 > reset
72
73
74 I've already patched the mklib.glide file. You'll have to start Quake
75 with the script shown above though.
76
77
78
79 **********************
80
81 Daryll Strauss writes:
82
83 Here's my thoughts on the problem. On a RH 5.x system, you can NOT build
84 a libc5 executable or library. Red Hat just doesn't include the right
85 stuff to do it.
86
87 Since Quake is a libc5 based application, you are in trouble. You need
88 libc5 libraries.
89
90 What can you do about it? Well there's a package called gcc5 that does
91 MOST of the right stuff to compile with libc5. (It brings back older
92 header files, makes appropriate symbolic links for libraries, and sets
93 up the compiler to use the correct directories) You can find gcc5 here:
94 ftp://ecg.mit.edu/pub/linux/gcc5-1.0-1.i386.rpm
95
96 No, this isn't quite enough. There are still a few tricks to getting
97 Mesa to compile as a libc5 application. First you have to make sure that
98 every compile uses gcc5 instead of gcc. Second, in some cases the link
99 line actually lists -L/usr/lib which breaks gcc5 (because it forces you
100 to use the glibc version of things)
101
102 If you get all the stuff correctly compiled with gcc5 it should work.
103 I've run Mesa 3.0B6 and its demos in a window with my Rush on a Red Hat
104 5.1 system. It is a big hassle, but it can be done. I've only made Quake
105 segfault, but I think that's from my libRush using the wrong libc.
106
107 Yes, mixing libc5 and glibc is a major pain. I've been working to get
108 all my libraries compiling correctly with this setup. Someone should
109 make an RPM out of it and feed changes back to Brian once they get it
110 all working. If no one else has done so by the time I get the rest of my
111 stuff straightened out, I'll try to do it myself.
112
113 - |Daryll
114
115
116
117 *********************
118
119 David Bucciarelli (tech.hmw (a] plus.it) writes:
120
121 I'm using the Mesa-3.0beta7 and the RedHat 5.1 and QuakeII is
122 working fine for me. I had only to make a small change to the
123 Mesa-3.0/mklib.glide file, from:
124
125
126 GLIDELIBS="-L/usr/local/glide/lib -lglide2x
127 -L/usr/i486-linux-libc5/lib -lm"
128
129 to:
130
131 GLIDELIBS="-L/usr/i486-linux-libc5/lib -lglide2x"
132
133 and to make two symbolic links:
134
135 [david@localhost Mesa]$ ln -s libMesaGL.so libMesaGL.so.2
136 [david@localhost Mesa]$ ln -s libMesaGLU.so libMesaGLU.so.2
137
138 I'm using the Daryll's Linux glide rpm for the Voodoo2 and glibc (it
139 includes also the Glide for the libc5). I'm not using the /dev/3Dfx and
140 running QuakeII as root with the following env. var:
141
142 export
143 LD_LIBRARY_PATH=/dsk1/home/david/src/gl/Mesa/lib:/usr/i486-linux-libc5/lib
144
145 I think that all problems are related to the glibc, Quake will never
146 work if you get the following output:
147
148 [david@localhost Mesa]$ ldd lib/libMesaGL.so
149 libglide2x.so => /usr/lib/libglide2x.so (0x400f8000)
150 libm.so.6 => /lib/libm.so.6 (0x40244000)
151 libc.so.6 => /lib/libc.so.6 (0x4025d000)
152 /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00000000)
153
154 You must get the following outputs:
155
156 [david@localhost Mesa]# ldd lib/libMesaGL.so
157 libglide2x.so => /usr/i486-linux-libc5/lib/libglide2x.so
158 (0x400f3000)
159
160 [root@localhost quake2]# ldd quake2
161 libdl.so.1 => /lib/libdl.so.1 (0x40005000)
162 libm.so.5 => /usr/i486-linux-libc5/lib/libm.so.5 (0x40008000)
163 libc.so.5 => /usr/i486-linux-libc5/lib/libc.so.5 (0x40010000)
164
165 [root@localhost quake2]# ldd ref_gl.so
166 libMesaGL.so.2 =>
167 /dsk1/home/david/src/gl/Mesa/lib/libMesaGL.so.2 (0x400eb000)
168 libglide2x.so => /usr/i486-linux-libc5/lib/libglide2x.so
169 (0x401d9000)
170 libX11.so.6 => /usr/i486-linux-libc5/lib/libX11.so.6
171 (0x40324000)
172 libXext.so.6 => /usr/i486-linux-libc5/lib/libXext.so.6
173 (0x403b7000)
174 libvga.so.1 => /usr/i486-linux-libc5/lib/libvga.so.1
175 (0x403c1000)
176 libm.so.5 => /usr/i486-linux-libc5/lib/libm.so.5 (0x403f5000)
177 libc.so.5 => /usr/i486-linux-libc5/lib/libc.so.5 (0x403fd000)
178
179
180 ***********************
181
182 Steve Davies (steve (a] one47.demon.co.uk) writes:
183
184
185 Try using:
186
187 export LD_LIBRARY_PATH=/usr/i486-linux-libc5/lib
188 ./quake2 +set vid_ref gl
189
190 to start the game... Works for me, but assumes that you have the
191 compatability libc5 RPMs installed.
192
193
194 ***************************
195
196 WWW resources - you may find additional Linux Quake help at these URLs:
197
198
199 http://quake.medina.net/howto
200
201 http://webpages.mr.net/bobz
202
203 http://www.linuxgames.com/quake2/
204
205
206
207 ----------------------------------------------------------------------
208
README.THREADS
1
2
3 Mesa Threads README
4 -------------------
5
6 Thread safety was introduced in Mesa 2.6 by John Stone and
7 Christoph Poliwoda.
8
9 It was redesigned in Mesa 3.3 so that thread safety is
10 supported by default (on systems which support threads,
11 that is). There is no measurable penalty on single
12 threaded applications.
13
14 NOTE that the only _driver_ which is thread safe at this time
15 is the OS/Mesa driver!
16
17
18 At present the mthreads code supports three thread APIS:
19 1) POSIX threads (aka pthreads).
20 2) Solaris / Unix International threads.
21 3) Win32 threads (Win 95/NT).
22
23 Support for other thread libraries can be added src/glthread.[ch]
24
25
26 In order to guarantee proper operation, it is
27 necessary for both Mesa and application code to use the same threads API.
28 So, if your application uses Sun's thread API, then you should build Mesa
29 using one of the targets for Sun threads.
30
31 The mtdemos directory contains some example programs which use
32 multiple threads to render to osmesa rendering context(s).
33
34 Linux users should be aware that there exist many different POSIX
35 threads packages. The best solution is the linuxthreads package
36 (http://pauillac.inria.fr/~xleroy/linuxthreads/) as this package is the
37 only one that really supports multiprocessor machines (AFAIK). See
38 http://pauillac.inria.fr/~xleroy/linuxthreads/README for further
39 information about the usage of linuxthreads.
40
41 If you are interested in helping with thread safety work in Mesa
42 join the Mesa developers mailing list and post your proposal.
43
44
45 Regards,
46 John Stone -- j.stone (a] acm.org johns (a] cs.umr.edu
47 Christoph Poliwoda -- poliwoda (a] volumegraphics.com
48
49
50 Version info:
51 Mesa 2.6 - initial thread support.
52 Mesa 3.3 - thread support mostly rewritten (Brian Paul)
53
README.VMS
1
2 VMS support contributed by Jouk Jansen (joukj (a] hrem.stm.tudelft.nl)
3
4
5 The latest version was tested on a VMSAlpha7.2 system using DECC6.0, but
6 probably also works for other versions.
7
8 At the moment only the libraries LIBMESGL.EXE/LIBMESGL.OLB,
9 LIBMESAGLU.EXE/LIBMESAGLU.OLB and LIBGLUT.EXE/LIBGLUT.OLB and the demos of the
10 directory [.DEMOS] can be build.
11 However, feel free to create the missing "decrip.mms-files" in the other
12 directories.
13
14 The make files were tested
15 using the DIGITAL make utility called MMS. There is also a public domain
16 clone available (MMK) and I think, but it is not tested, that this
17 utility will give (hardly) any problem.
18
19 To make everything just type MMS (or MMK) in the main directory of
20 mesagl. For MMS the deafult makefile is called descrip.mms, and
21 that is what I have called it. I included alse some config files,
22 all having mms somewhere in the name which all the makefiles need
23 (just as your unix makefiles).
24
25 On Alpha platforms at default a sharable images for the libraries are created.
26 To get a static library make it by typing MMS/MACRO=(NOSHARE=1).
27 On VAX platforms only static libraries can be build.
28
29 23-sep-2005
30 changed default compilation to use /float=ieee/ieee=denorm. The reason for
31 this is that it makes Mesa on OpenVMS better compatible with other platforms
32 and other packages for VMS that I maintain.
33 For more information see
34 http://nchrem.tnw.tudelft.nl/openvms
35 https://bugs.freedesktop.org/show_bug.cgi?id=4270
36 You may want to compile Mesa to use VAX-floating point arithmetic, instead
37 of IEEE floating point by removing the /float=IEEE/denorm flag from the
38 compiler options in the descrip.mms files.
39
README.WIN32
1 File: docs/README.WIN32
2
3 Last updated: Apr 25, 2007 - Karl Schultz - kschultz (a] users.sourceforge.net
4
5 Quick Start
6 ----- -----
7
8 Unzip the MesaLib, MesaGLUT, and MesaDemos ZIP files into the same
9 directory. The libs and demos build separately, so if you do not care
10 about the demos or GLUT, you only need to unzip MesaLib. If you unzip
11 more than one ZIP file, they all need to be unzipped into the same
12 directory. Don't worry, you will not overwrite anything.
13
14 The Windows build system uses Microsoft Visual Studio. Project files
15 for a specific version of Visual Studio are in their own directory in
16 the top-level "windows" directory. For example, Visual Studio 8 files
17 are in windows/VC8.
18
19 Support has been dropped for versions of Visual Studio prior to 8. The
20 main reason is because Microsoft now provides a free compiler and
21 developer environment. Visual Studio Express can be found at
22
23 http://msdn.microsoft.com/vstudio/express/visualc/default.aspx
24
25 You'll also need the Platform SDK. Instructions for obtaining and
26 using the SDK with Visual Studio Express can be found at
27
28 http://msdn.microsoft.com/vstudio/express/visualc/usingpsdk/
29
30 The project files to build the core Mesa library, Windows Mesa
31 drivers, OSMesa, and GLU are in the mesa directory. The project files
32 to build GLUT and some demo programs are in the progs directory.
33
34 Makefiles are no longer shipped or supported, but can be generated
35 from the projects using Visual Studio.
36
37
38 Windows Drivers
39 ------- -------
40
41 At this time, only the GDI driver is known to work. Most of the demos
42 in progs/demos should work with this driver.
43
44 Source code also exists in the tree for other drivers in
45 src/mesa/drivers/windows, but the status of this code is unknown.
46
47 The GDI driver operates basically by writing pixel spans into a DIB
48 section and then blitting the DIB to the window. The driver was
49 recently cleaned up and rewitten and so may have bugs or may be
50 missing some functionality. The older versions of the CVS source may
51 be useful in figuring out any problems, or report them to me.
52
53 To build Mesa with the GDI driver, build the mesa, gdi, and glu
54 projects in the Visual Studio workspace found at
55
56 windows/VC8/mesa/mesa.sln
57
58 The osmesa DLL can also be built with the osmesa project.
59
60 The build system creates a lib top-level directory and copies
61 resulting LIB and DLL files to this lib directory. The files are:
62
63 OPENGL32.LIB, GLU32.LIB, OSMESA32.LIB
64 OPENGL32.DLL, GLU32.DLL, OSMESA32.DLL
65
66 If the MesaDemos ZIP file was extracted, the DLL files are also copied
67 to the demos directory. This facilitates running the demos as described
68 below.
69
70
71 GLUT and Demos
72 ---- --- -----
73
74 A Visual Studio workspace can be found at
75
76 windows/VC8/progs/progs.sln
77
78 It can be used to build GLUT and a few demos. The GLUT lib and DLL
79 are copied to the top-level lib directory, along with the Mesa libs.
80
81 The demo build system expects to find the LIB files in the top level
82 lib directory, so you must build the Mesa libs first. The demo
83 executables are placed in the demos directory, because some of them
84 rely on data files found there. Also, the Mesa lib DLL's were copied
85 there by the Mesa lib build process. Therefore, you should be able to
86 simply run the demo executables from the demo directory.
87
88 If you want to run the demos from the Visual Studio, you may have to
89 change the startup directory and explicitly state where the executables are.
90
91 You may also build all the demo programs by using a makefile. Go to
92 the progs/demos directory and make sure you have executed VCVARS32.BAT
93 or whatever setup script is appropriate for your compiler. Then,
94
95 nmake -f Makefile.win
96
97 should build all the demos.
98
99
100 Build System Notes
101 ----- ------ -----
102
103 VC8
104 ---
105
106 No notes.
107
108
109 General
110 -------
111
112 After building, you can copy the above DLL files to a place in your
113 PATH such as $SystemRoot/SYSTEM32. If you don't like putting things
114 in a system directory, place them in the same directory as the
115 executable(s). Be careful about accidentially overwriting files of
116 the same name in the SYSTEM32 directory.
117
118 The DLL files are built so that the external entry points use the
119 stdcall calling convention.
120
121 Static LIB files are not built. The LIB files that are built with are
122 the linker import files associated with the DLL files.
123
124 The si-glu sources are used to build the GLU libs. This was done
125 mainly to get the better tessellator code.
126
127 To build "mangled" Mesa, add the preprocessor define USE_MGL_NAMESPACE
128 to the project settings. You will also need to edit src/mesa.def to
129 change all the gl* symbols to mgl*. Because this is easy to do with a
130 global replace operation in a text editor, no additional mangled
131 version of mesa.def is maintained or shipped.
132
133 If you have a Windows-related build problem or question, it is
134 probably better to direct it to me (kschultz (a] users.sourceforge.net),
135 rather than directly to the other Mesa developers. I will help you as
136 much as I can. I also monitor the Mesa mailing lists and will answer
137 questions in this area there as well.
138
139
140 Karl Schultz
141
README.WINDML
1
2 WindML Driver for Mesa 4.0
3
4
5 Requirements
6 ------------
7
8 Tornado 2 + WindML, Cumulative Patchs are recommended.
9
10 I suppose you have a valid WindML installation. Double buffer hardware
11 gives better performance than double buffer software so if you can
12 compile your WindML driver with this option, just do it. I/O
13 redirection is adviced in target server.
14
15
16 Tested on
17 ---------
18
19 During the development, my main target was a CoolMonster:
20 - Video card: CT69000
21 - CPU: PENTIUM 266MHz
22
23 and my host a Windows NT + Tornado 2.
24
25
26 Installation
27 ------------
28
29 1. Mesa sources must be in root directory (C:\)
30
31 2. Add the following line to your torVars.bat:
32 set MESA_BASE=C:\Mesa
33
34 OR copy the new torVars.bat in your bin path:
35 c:/Mesa/src/ugl/tornado/torVars.sample ->
36 /mnt/nt/Tornado/host/x86-win32/bin/torVars (for example)
37
38 3. In a command prompt:
39 $ torVars
40 $ cd c:\Mesa
41 $ make -f Makefile.ugl CPU=PENTIUM
42
43 Take a long while...
44
45 5. Include all the files from ugldemos folder to build some downloadable
46 application modules
47
48 4. Download UGL/Mesa object files on target
49
50 For example via the WindShell:
51 ld < c:\Tornado\target\lib\objMesaGL.o
52 ld < c:\Tornado\target\lib\objMesaUGL.o
53 ld < c:\Tornado\target\lib\objMesaGLU.o
54 ld < c:\Tornado\target\lib\objGLUTshapes.o
55 ld < c:\Tornado\target\lib\objMesaOS.o
56
57 You can put the previous lines in a file and use:
58 < filename
59
60 6. Download the application modules.
61
62 7. In WindShell, run:
63 -> uglalldemos
64
65 During the show some messages will appear, it provides some useful
66 information on key management.
67
68
69 Coding
70 ------
71
72 Sample Usage:
73
74 In addition to the usual ugl calls to initialize UGL, (may be find an
75 input driver), you must do the following to use the UGL/Mesa interface:
76
77 1. Call uglMesaCreateContext() to create a UGL/Mesa rendering context,
78 given the display format.
79
80 2. Call uglMesaMakeCurrent() to bind the UGL/Mesa buffers to an
81 UGL/Mesa Context and to make the context the current one.
82
83 3. Make gl* calls to render your graphics.
84
85 4. Use uglMesaSwapBuffers() when double buffering to swap front/back buffers.
86
87 5. Before the UGL is destroyed, call MesaDestroyContext().
88
89 6. Before exiting, call if required uglEventQDestroy and then
90 uglDeinitialize();
91
92 Limitations
93 -----------
94
95 I found the following limitations in my driver :
96 - Color Indexed management is only in 8 bits
97 - It's possible to mix UGL/OpenGL application with a software
98 double buffer
99
100 Modifications
101 ------------
102
103 New files in Mesa:
104 - Makefile.ugl
105 - rules.windmlmesa
106 - docs/README.UGL
107 - include/GL/uglmesa.h
108 - si-glu/Makefile.ugl
109 - src/Makefile.ugl
110 - src/ugl/torGLUTShapesInit.c
111 - src/ugl/torMesaUGLInit.c
112 - src/ugl/ugl_api.c
113 - src/ugl/ugl_dd.c
114 - src/ugl/ugl_glutshapes.c
115 - src/ugl/ugl_line.c
116 - src/ugl/ugl_span.c
117 - src/ugl/ugl_tri.c
118 - src/ugl/uglmesaP.h
119 - ugldemos/*
120
121 Modified files in Tornado 2.0:
122 - c:\Tornado\host\x86-win32\bin\torVars.bat
123 rem Command line build environments
124 set WIND_HOST_TYPE=x86-win32
125 set WIND_BASE=C:\Tornado
126 set MESA_BASE=C:\Mesa
127 set PATH=%WIND_BASE%\host\%WIND_HOST_TYPE%\bin;%PATH%
128 - c:\Tornado\target\config\comps\VxWorks\01uglmesa.cdf
129 - c:\Tornado\target\h\GL\*
130
131 Todo
132 ----
133 - GCC 2.96, ASM compilation
134
135 Thanks to:
136 ----------
137
138 Precision Insight team for their great job around Mesa, XFree, and DRI.
139 Wind River Systems to take me as an intern.
140
141
142 Stephane Raimbault
143 <stephane.raimbault (a] windriver.com>
144 <stephane.raimbault (a] deesse.univ-lemans.fr>
145
146 July 24, 2001
147