下载链接:2.5:http://content.gpwiki.org/index.php/GLFW:Tutorials:Basics
http://download.csdn.net/detail/m1230315/7128497
最新版:http://www.glfw.org/download.html
1. Introduction
Welcome to version 2.5 of the GLFW OpenGL framework. GLFW is a free,open source, portable framework for OpenGL application development. Inshort, it is a library that constitutes a powerful API for handlingoperating system specific tasks, such as opening an OpenGL window, readingkeyboard and mouse input, creating threads, and much more.
2. Compiling GLFW and the example programs
A top level makefile can be found in the root directory of the GLFWdistribution that has been designed to work with several compilers. If yousimply enter the GLFW root directory in a shell and typemake (ornmake or gmake, depending on the name of your maketool), and a list should appear with the currently supported options forsystems and compilers.
For example, one of the options is to compile GLFW for Windows withthe LCC-Win32 C compiler. To do that, typemake win32-lcc in theshell (as specified in the previously mentioned list). That will compilethe GLFW static link library and the supplied example programs. ForWindows compilers, a Win32 DLL will also be compiled.
Currently supported compilers and systems are:
- Borland C++ Builder compiler 5.x for Windows
- Cygwin (GCC) for Windows
- LCC-Win32 for Windows
- Microsoft Visual C++ 6.x for Windows
- MinGW32 (GCC) for Windows
- OpenWatcom for Windows
- Pelles C for Windows
- Unix or Unix-like systems running the X Window System (auto detect compiler, or force GCC)
- Geek Gadgets (GCC) for AmigaOS
- VBCC for AmigaOS
- Apple Developer Tools (GCC) for Mac OS X
- DJGPP (GCC) for DOS
If your compiler/system is not in the list, you will have to create newmakefiles in thelib\win32, lib/x11, lib/amigaos,lib/macosx orlib\dos directory, and in the examplesdirectory. If you have any problems, do not hesitate to contact me (I maynot know how your compiler works, but I know the GLFW source code). I wouldalso like to add support for more compilers and verify that GLFW compilesunder as many systems as possible, so if you had to make any modificationsor additions to the source and/or makefiles in order to make GLFW compilesuccessfully, I would like to know what you had to do.
2.1 Note for Microsoft Visual C++ users
When MSVC is installed, you are asked if it should be possible toaccess the compiler from the command line. For some strange reason, thedefault answer to this question is NO. If you answered no to this questionyou will have to run a file namedVCVARS32.BAT, which is located inthe bin directory of your Visual C++ folder, before you can use thecompiler from the command line.
Note that VCVARS32.BAT must be run from the same shell as youintend to use for compiling GLFW (simply clicking on the file from theexplorer willnot work).
After that is done, it is possible to compile GLFW by entering the GLFWroot directory and issuingnmake win32-msvc.
For instance, if MSVC is installed in the directory 'C:\ProgramFiles\Microsoft Developer Studio\VC98', then you should be able to compileGLFW with this procedure:
- Start a command prompt (MS-DOS prompt)
- "CD" to the directory where you unzipped the GLFW source distribution (where this readme file is located)
- Type "C:\Program Files\Microsoft Developer Studio\VC98\BIN\VCVARS32" (with quotation marks)
- Type nmake win32-msvc
2.2 Note for MinGW/DevC++ users
Do not use the MSYS shell for compiling GLFW, because the suppliedbatch file "compile.bat" will only work under a Windows command prompt (orMS-DOS prompt).
Under Windows 98, the MinGW make program may set the $(MAKE) variableincorrectly. To remedy this, uncomment the line at the beginning of thetop level Makefile that says MAKE = make (possibly replacing make withsome other name, e.g. mingw32-make).
2.3 Note for Cygwin users
The top level makefile was designed to run from a Cygwin bash shell.You can not use an MS-DOS prompt (or NT cmd prompt) to compile GLFWwith the win32-cygwin option. Similarly, the win32-clean option will notwork from a Cygwin shell, which is why there is a special cygwin-cleanoption.
2.4 Note for OpenWatcom users
In order to compile GLFW successfully with OpenWatcom (for Windows),execute "nmake MAKE=nmake win32-ow" in the GLFW root directory. Also makesure that you have all your environment variables set up correctly. It isthe default option when installing OpenWatcom to permanently set up allthe required environment variables. If nmake does not work, you probablyhave to run "WATCOM\setvars.bat" from the command prompt before executingnmake, where WATCOM is the directory in which you installed OpenWatcom(e.g. C:\Watcom).
2.5 Note for Pelles C users
To build GLFW with Pelles C, you need at lest version 2.80.3 of Pelles C(POCC and POLINK).
Type 'pomake win32-pellesc' to build GLFW.
2.6 Note for Unix/X11 users
Compiler and link library capabilities are auto-detected with a scriptcalled compile.sh. It has been tested under Linux Mandrake 10.1,Mac OS X 10.2, SunOS 5.6 (GCC), IRIX 5.3, FreeBSD 5.0 and QNX, but shouldhopefully run on the majority of available Unix/Unix-like systems andgenerate functional Makefiles. You do not have to run the script manually,since it is called from the top level Makefile.
2.7 Note for AmigaOS users
The current AmigaOS implementation of GLFW requires VBCC (an excellentfree C compiler) or Geek Gadgets GCC, the StormMesa developer package, andof course the AmigaOS include files (not included with VBCC or GCC due tocopyright reasons).
To compile GLFW and the example programs for AmigaOS (68k) with VBCC,you need a make program that understands AmigaDOS paths. I use the SAS/Ccompiled version of GNU make 3.75, which can be found on Aminet.
It should also be noted that the current version of GLFW for AmigaOS isonly a subset of the full GLFW API. Most of the core functionality hasbeen implemented, but there are still some things missing (e.g. hiding themouse cursor in windowed mode, iconification handling etc).
2.8 Note for Mac OS X users
To compile GLFW for Mac OS X, you will need to have installed the BSDsubsystem and the Developer Tools, which can be found on your Mac OS XCD:s. When they are installed, simply open Terminal and go to theroot GLFW directory. From there, you can build the library and all theexamples by running make, i.e. make macosx-gcc.
2.9 Note for DOS users
The current port for DOS is very preliminiary. It is based on alphaversions of DJGPP and Mesa 5.1, and in my experience the mouse interfaceseems error prone (random crashes). At the moment the DOS port should beconsidered experiemental at best, so use it at your own risk.
Also, if you decide to build GLFW under pure DOS you will need somesoftware to support long file names (I have used DOSLFN without problems).
3. Installing GLFW
3.1 Windows
After compiling GLFW with MinGW32 or Cygwin, three files of interestshould have appeared in thelib\win32 directory. They are:libglfw.a (the static link version of GLFW),glfw.dll (theDLL version of GLFW) and libglfwdll.a (the DLL import library).
If you used Borland C++ Builder, LCC-Win32, Microsoft Visual C++ orOpenWatcom, the files are namedglfw.lib (the static link versionof GLFW), glfw.dll (the DLL version of GLFW) andglfwdll.lib(the DLL import library).
The static link library and the DLL import library should be copied toyour compiler'sLIB directory (where all other link libraries arelocated). The DLL can be copied either to your Windows system directory(where opengl32.dll is located), or to the project directory of yourGLFW-based projects (where you place your compiled EXEs).
You should also copy the GLFW include file, include\GL\glfw.h,to theGL directory of your compiler's include directory (wheregl.h, glu.h etc. are located).
3.2 Unix
After compiling GLFW, a file named libglfw.a should haveappeared in thelib/x11 directory. This is the GLFW static linklibrary, which should be copied to your compiler'slib directory(where all other link libraries are located).
You should also copy the GLFW include file, include/GL/glfw.h,to theGL directory of your compiler's include directory (wheregl.h, glu.h etc. are located).
3.3 AmigaOS
After compiling GLFW, a file named glfw.lib should haveappeared in thelib/amigaos directory. This is the GLFW static linklibrary, which should be copied to your compiler'slib directory(where all other link libraries are located).
You should also copy the GLFW include file, include/GL/glfw.h,to theGL directory of your compiler's include directory (wheregl.h, glu.h etc. are located).
3.4 Mac OS X
After compiling GLFW, a file named libglfw.a should appear inthelib/macosx directory. This is the GLFW static library, whichshould be copied to an appropriatelib directory, preferrably/usr/local/lib. Note that you must runranlib on the libraryafter it has been copied, in order for it to be usable, i.e.
sudo mkdir -p /usr/local/lib
sudo cp libglfw.a /usr/local/lib
sudo ranlib /usr/local/lib/libglfw.a
You should also copy the GLFW include file, include/GL/glfw.h,to theGL directory of an appropriate include directory,preferrably/usr/local/include, i.e.:
sudo mkdir -p /usr/local/include/GL
sudo cp glfw.h /usr/local/include/GL
4. Using GLFW
There are two aspects to using GLFW:
- How does the GLFW API work
- How to compile programs that use GLFW
The first point is covered in the GLFWUsers Guide and theGLFW ReferenceManual, and I suggest that you read at least the Users Guide, sinceit is a good introduction to the GLFW API.
Designing and compiling programs that use GLFW is not very difficult.A few rules for successfully designing GLFW-based programs are presentedin the following sections.
4.1 Include <GL/glfw.h>
In your program, you should include <GL/glfw.h>. This includefile defines all the necessary constants, types and prototypes that areused to interact with the GLFW API. It also includes <GL/gl.h> and<GL/glu.h>, and -this is very important - it definesall the necessary constants and types that are necessary for OpenGL towork on different platforms.
For instance, under Windows you are normally required to include<windows.h> before you include <GL/gl.h>. If you write such aprogram, it would not compile under e.g. Linux since <windows.h>does not exist under Linux. <GL/glfw.h> takes care of these thingsfor you. Note however that it does not actually include <windows.h>,it merely mimics the parts of it that are needed for <GL/gl.h> and<GL/glu.h> (this way we do not get the thousands of constants,types and prototypes that could otherwise possibly interfere with our owndeclarations).
In other words:
- Do not include <GL/gl.h> or <GL/glu.h>! (GLFW does it for you)
- Do not include <windows.h>! (unless you really need it)
Note: If you do need to include <windows.h>, do itbefore including <GL/glfw.h>.
4.2 Link with the right libraries
4.2.1 Windows static library
If you link with the static version of GLFW, it is also necessary tolink with some system libraries that GLFW uses.
When linking a program under Windows that uses the static version ofGLFW, you must also link with the following libraries:opengl32,user32 and kernel32. Some of these libraries may be linkedwith by default by your compiler. In the table below you can see theminimum required link options for each supported Windows compiler (you maywant to add other libraries as well, such as glu32):
Compiler | Link options |
Borland C++ Builder | glfw.lib opengl32.lib |
Cygwin | -lglfw -lopengl32 |
LCC-Win32 | glfw.lib opengl32.lib |
Microsoft Visual C++ | glfw.lib opengl32.lib user32.lib |
MinGW32 | -lglfw -lopengl32 |
OpenWatcom | glfw.lib opengl32.lib user32.lib |
Pelles C | glfw.lib opengl32.lib user32.lib kernel32.lib |
4.2.2 Windows DLL
To compile a program that uses the DLL version of GLFW, you need todefine the GLFW_DLL constant. This can either be done with acompiler switch, typically by adding-DGLFW_DLL to the list ofcompiler options. You can also do it by adding the line:
#define GLFW_DLL
...to all your source files that include glfw.h, beforeincluding it.
When linking a program under Windows that uses the DLL version of GLFW,the only library you need to link with for GLFW to work isglfwdll.In the table below you can see the minimum required link options for eachsupported Windows compiler (you may want to add other libraries as well,such asopengl32 and glu32):
Compiler | Link options |
Borland C++ Builder | glfwdll.lib |
Cygwin | -lglfwdll |
LCC-Win32 | glfwdll.lib |
Microsoft Visual C++ | glfwdll.lib |
MinGW32 | -lglfwdll |
OpenWatcom | glfwdll.lib |
Pelles C | glfwdll.lib |
4.2.3 Unix static library
Since there are so many flavors of Unix and Unix-like systems, it isimpossible to give a standard rule for properly linking GLFW applications.In general, it is a good idea to look at the automatically generatedMakefile.x11 file in the examples directory, which should containall the necessary compiler and linker directives. Following is a briefdescription of what should work for many (but not all) systems:
When compiling and linking a program under Unix/X11 that uses GLFW, youmust also link with the following libraries:GL, X11 andpthread. For XFree86 you also need to link withXxf86vm.
Of course, in all cases you should also link with glfw.
A typical compile and link command line may look like this (using gcc):
gcc myprog.c -o myprog -lglfw -lGL -lX11 -lpthread
For XFree86 you also add -lXxf86vm, and under Linux (and perhapsother environments) you need to specify the location of the X11 libraryfiles using-L/usr/X11R6/lib:
gcc myprog.c -o myprog -L/usr/X11R6/lib -lglfw -lGL -lX11 -lpthread -lXxf86vm
FreeBSD systems require that you use -pthread instead of-lpthread.
QNX systems require that you use -lsocket instead of-lpthread. Usually, X11 is installed in /opt instead of /usr underQNX, so use-L/opt/X11R6/lib.
To use GLFW from KDevelop under Linux, you usually add the following toProject->Project Options->Configure Options->Linker Flags:
-L/usr/X11R6/lib -lglfw -lGL -lXxf86vm -lpthread
If you use GLU functions in your program you should also add-lGLU.
4.2.4 AmigaOS static library
When compiling and linking a program under AmigaOS that uses GLFW, youmust also link with the following libraries:GL, amiga andm (the latter can bem881 or m040 etc, depending onwhich compiler and CPU you use).
Of course, in all cases you should also link with glfw.
A typical compile and link command line may look like this (using vbcc):
vc -cpu=68020 -fpu=68881 -lglfw -lGL -lamiga -lm881 -o myprog myprog.c
Hint: For VBCC, you can specify -c99 to support things like C++style comments.
4.2.5 Mac OS X static library
When compiling and linking a program under Mac OS X that uses GLFW, youmust also link with the following frameworks:Carbon.framework,AGL.framework and OpenGL.framework.
If you are using an IDE, such as Project Builder or Xcode, you simply addthe GLFW librarylibglfw.a and these frameworks to your project. If,however, you are building your program from the command line, you will needto add them to your command line using the-l and -frameworkswitches, i.e.:
gcc -o myprog myprog.c -lglfw -framework Carbon -framework AGL -framework OpenGL
Note that you do not add the extension to a framework when adding it fromthe command line.
These frameworks contain all GL and GLU functions, so there is no need toadd additional libraries or frameworks when using GLU functionality. Also notethat even though your machine may have Unix-style GL libraries, they are foruse with the X server, and will not work with the Mac OS X nativeversion of GLFW.
5. Version history
v2.5
- Added the function glfwWaitEvents
- Added window close callback, which enables a program to prevent a user from closing a window with the window manager
- Added window refresh callback, which is called when the window needs to be refreshed
- Added support for loading alpha textures (GLFW_ALPHA_MAP_BIT)
- Added support for the Lua programming language
- Added support for the D programming language
- Added support for the Pelles C compiler for Windows
- Added API level support for up to eight mouse buttons
- [Win32] Added support for up to five mouse buttons
- [Win32] Mouse down events capture mouse input
- [Win32] Bugfix: The DLL now exports glfwSetTime
- [Win32] Fix: The GLFW window is now placed in the upper left corner of the desktop working area
- [Win32/X11] Bugfix: More robust check for SwapInterval
- [X11] Added support for USB joysticks under Linux (/dev/input/js*)
- [X11] Bugfix: Added support for GLX extensions in glfwExtensionSupported
- [X11] Bugfix: More robust fullscreen mode (?)
- [X11] Bugfix: Runtime check of XF86VidMode support for the active display
- [X11] Bugfix: Some mouse button events were reported incorrectly
- [MacOSX] Added support for the input char callback.
- [MacOSX] Added video mode validation and duplicate elimination.
- [MacOSX] Switched to a new MakeBundle.sh script.
- [MacOSX] Added emulation of the window refresh callback.
- [MacOSX] Bugfix: The window and its associated resources are now properly released.
- [MacOSX] Bugfix: Removed support for more than eight mouse buttons.
- [x86 CPUs] Improved Intel mobile CPU detection (e.g. disables RDTSC timing on Centrino systems)
v2.4.2
- Preliminary native Mac OS X support (via the Carbon interface)
- Preliminary DOS support (DJGPP + Mesa)
- Changed license to the zlib license (almost identical to the previous GLFW license), so now GLFW is OSI Certified
- Rewrote the GLFW documentation in LaTeX, meaning several improvements (both visual and practical)
- Added the support folder to the distribution, which includes support for various languages
- [Win32] Added OpenWatcom compiler support (thanks Sebastian Schuberth!)
- [Win32] Changed fallback timer from GetTickCount to timeGetTime, which usually provides better resolution
- [Win32] Bugfix: Accumulator buffer selection should be more robust
- [Win32] Bugfix: If stereo rendering is requested, and no stereo pixel format could be created, glfwOpenWindow now fails
- [Win32] Bugfix: glfwSetWindowSize now sets the size of the client area, NOT the entire window, meaning that there is a 1:1 relationship between glfwSetWindowSize and glfwGetWindowSize
- [X11] Added FreeBSD and QNX support
- [X11] Added support for non-pthread capable systems
- [X11] Hopefully more robust configuration script (compile.sh)
- [X11] Bugfix: When mouse cursor is hidden, mouse sensitivity is no longer degraded
- [X11] Bugfix: Source files EOL was PC style (CR/LF) in v2.4.1 (blame my WinCVS configuration)
- [X11] Bugfix: When a GLFW window is closed, input focus is properly released
- [X11] Bugfix: Iconification of fullscreen windows should now work properly
- [x86 CPUs] Improved RDTSC timing (e.g. RDTSC support on single-CPU Intel Hyper-Threading enabled systmes)
- [AmigaOS] Added joystick support
- [AmigaOS] Mouse cursor positioning is now implemented
- [AmigaOS] Added support for Geek Gadgets GCC
- [AmigaOS] Bugfix: glfwGetWindowParam now returns proper values for all parameters (except for GLFW_ACCELERATED)
v2.4.1
- Added AmigaOS support (preliminary)
- GLFW for the X Window System now works under Mac OS X
- [Win32] Bugfix: glfwWaitCond treated the timeout as milliseconds instead of seconds
- [X11] Bugfix: GLFW should now compile under IRIX v5.3
- [X11] Bugfix: GLFW should now compile with Kylix
v2.4
- Major source code rearrangement - much code is now shared between different platforms, and it should be easier to port GLFW to new platforms
- Added a Unicode keyboard text input interface (CharCallback)
- Keyboard key input is now slightly more internationalized: GLFW now uses 8-bit ISO-8859-1 encoding for keys representing printable characters (e.g. "Ö", "§", etc), as opposed to the previous 7-bit US-ASCII encoding
- Added more key constants (F13-F25, keypad '=')
- Added an enable/disable swicth for automatic event polling from glfwSwapBuffers
- [X11] Added support for sysctl for querying the number of processors in the system (if POSIX sysconf is not supported)
- [X11] Bugfix: compile.sh now works with Sun sh (and hopefully others too)
- [X11] Bugfix: compile.sh now detects the need for -ldl when dlopen is used
- [Win32] Bugfix: When closing a fullscreen window under Win 9x/NT4, the task bar icon now disappears properly
- [Win32] Bugfix: GLFW should now compile on a wider range of MSVC compilers (e.g. .NET) - Thanks Tim Little!
v2.3.2
- Removed the silly limitation of 100 threads (the thread information is now kept in a linked list)
- General source cleanup (window state is now kept in a single struct, plus some other minor changes)
- [X11] Added Solaris gethrtime() support (not tested yet), which should give an improved timer for Sun/Solaris stations
- [X11] Some fixes to the 'compile.sh' script (-O for non-gcc compilers and 'make x11-gcc' should now really force GCC)
v2.3.1
- [X11] A minimalist configuration script was added that solves the issue with glXGetProcAddressARB, and unifies all Unix/X11 Makefiles into one template Makefile (well, one for GLFW, and one for the examples)
v2.3
- Added OpenGL stereo rendering support
- Added a function for parsing the OpenGL version string (glfwGetGLVersion)
- [x86] Bugfix: Hopefully the CPU core clock dependent timer RDTSC will never be used on CPUs with variable core frequencies anymore
- [X11] Bugfix: GLFW could create stereo rendering capable windows, even if it was not requested (GLFW v2.2.x did not support selection of stereo rendering)
- [X11] Bugfix: glfwGetProcAddress returned NULL on most systems (even on those that supported glXGetProcAddressARB). Now GLFW assumes that glXGetProcAddressARB is supported on all systems, which solves the bug, but may result in compiler errors on some systems (please let me know if you have any related problems).
v2.2.3
- Bugfix: Checking for GL_SGIS_generate_mipmap is more robust
- Bugfix: glfwLoadTexture2D will now fail if no window is opened
- [Win32] Bugfix: Right shift was not detected under Win 9x/ME (it is still not as good as under NT/2K/XP, but at least you get right shifts)
- [X11] Bugfix: Visuals are now selected more accurately. For instance, glfwOpenWindow will no longer fail if you request a 24-bit color buffer if only 16-bit color visuals are avilable (which means that pong3d should work on 16-bit displays).
v2.2.2
- [Win32] Bugfix: Windows did not always get focus (this was a tough one!)
- [Win32] Bugfix: glfwGetWindowParam did not work with GLFW_ACCUM_*_BITS or GLFW_AUX_BUFFERS
- [X11] Bugfix: Linux joystick Y axis positions were reversed
v2.2.1
- [X11] Added joystick support for Linux
v2.2
- Added joystick support (only supported under Windows so far)
- Added joystick controls to pong3d.c (only 3 more lines of code)
- Added glfwOpenWindowHint() function
- It is now possible to specify a desired vertical monitor refresh rate (for fullscreen windows)
- It is now possible to request an accumulator buffer and auxiliary buffers
- Added glfwSetTime() function
- Added a GLFW conversion of the MESA/GLUT gears.c demo to the example programs
- [Win32] gdi32.dll and winmm.dll are now loaded dynamically when glfwInit() is called. This means that there is no need to link with gdi32.lib or winmm.lib when using the static version of GLFW, which should make GLFW usage more convenient.
- [Win32] Bugfix: Greatly improved keyboard input (detect left/right CTRL etc)
- [Win32] Bugfix: glfwExtensionSupported now detects all WGL extensions (e.g. WGL_ARB_pbuffer)
- [Win32] Bugfix: Mouse cursor was not re-hidden when a GLFW window was deselected and then selected again (with ALT+TAB)
- [X11] Bugfix: Minor bug in the SGI timer - and ugly (unintended) SGI timer debug info removed
- [X11] Bugfix: glfwGetDesktopMode and glfwGetVideoModes no longer give segmentation faults if no X server is available
v2.1
- Added image and texture loading capabilities (support for the TGA file format at the moment)
- Added a new example program (mipmaps.c) for showing off the automatic mipmap generation and texture loading capabilities of GLFW 2.1
- Removed the separate TGA loader (tga.c in the examples directory) since texture loading is supported natively by GLFW. Also updated the Pong3D demo to use GLFW texture loading instead of tga.c.
- Improved keyboard handling (e.g. numeric keypad keys can be detected)
- Added a new example program, keytest.c
- Changed the GLFWvidmode structure and the corresponding API functions to report pure color bits instead of the confusing (and unportable) "BPP" field
- Changed glfwSetWindowSize so that it operates in fullscreen mode too
- Added mouse wheel support under Windows (not Win95) and X11
- Added window iconification functions (glfwInconifyWindow and glfwRestoreWindow)
- Improved iconification and deactivation handling under both Windows and X11
- Made it possible to turn on/off key repeat (the default is now no key repeat)
- Added SGI hardware timer support (CLOCK_SGI_CYCLE) for improved timer resolution for SGI computers
- Added support for the free Borland C++ Builder 5.x compiler for Windows
- Made it possible to compiler GLFW as a Windows DLL using any of the supported compilers
- Some constants have changed names (e.g. GLFW_REDBITS is now called GLFW_RED_BITS)
- Updated GLFW documentation (GLFW Users Guide and GLFW Reference Manual) to reflect the changes in the API
- [Win32] Bugfix: Corrected Cygwin toplevel makefile entry
- [Win32] Bugfix: Fixed event lag bug
- [Win32] Bugfix: Fixed Radeon 8500 crash
- [X11] Bugfix: Fixed the window close bug
- [X11] Bugfix: Iconification/deactivation is now detected
- [X11] Bugfix: Non-OpenGL visuals are not listed anymore
- [XFree86] Bugfix: Undesired video mode changes are now prevented
v2.0.3
- Added precise CPU cycle based timing support (RDTSC) for x86 CPUs (under both Windows and Unix)
- Added a makefile option for building for Windows with Cygwin
- Corrected the CC for Unix/X11 makefiles (-Wall is usually not a supported flag for CC, so it was removed from the CFLAGS list)
v2.0.2
- Added a makefile option for building for X11 with 'cc' rather than 'gcc' (useful for IRIX users for instance).
- [Win32] Bugfix: Mouse coordinates are now relative to the window upper left corner, which also means that disabling the mouse cursor in windowed mode should work much better.
- [X11] Bugfix: Added a bunch of more keys that are recognized by GLFW.
- [X11] Bugfix: glfwGetNumberOfProcessors now works for IRIX (earlier versions of GLFW would not compile under IRIX).
v2.0.1
- glfwTerminate() will now be called automatically upon normal program termination (using atexit())
- [Win32] Bugfix: Buffer-swapping did not work if a window lost focus.
- [Win32] Bugfix: Top level Makefile did not work under Windows 9x.
- [Win32] Bugfix: NULL declaratoin in glfw.h was not MSVC 7.x compatible.
- [X11] Bugfix: GLFW would not build with C++ (e.g. g++).
v2.0
- GLFW is no longer a single source file, but an entire link library.
- Added multi threading support.
- Added more window control.
- New distribution layout (both Win32 and X11 version in same archive).
- Added GLFW Users Manual and GLFW Reference Manual as PDF files.
- Some bugfixes.
v1.0.2
- Improved fullscreen functionality.
- Added fullscreen support for X11.
v1.0.1
- Added support for the X Window System.
- Fixed bugs.
v1.0.0
- First release.
- Only supported Windows.
6. Directory structure of the GLFW distribution
Here is an overview of the directory structure of the GLFW distribution:
docs | GLFW manuals in PDF format | |
examples | Several example programs in C | |
images | Images for this HTML document | |
include | ||
GL | Here is the GLFW C/C++ include file | |
lib | The source code for GLFW | |
amigaos | AmigaOS specific implementation | |
dos | DOS specific implementation | |
macosx | Mac OS X specific implementation | |
win32 | Windows specific implementation | |
x11 | Unix/X11 specific implementation | |
support | ||
d | D support | |
delphi | Delphi support | |
masm | MASM32 support | |
win32dll | Compiled version of the GLFW Win32 DLL | |
visualbasic | Visual Basic support |
7. The author
My name is Marcus Geelnard, marcus.geelnard@home.se.Please contact me if you have any problems with GLFW, or any questions atall concerning compiling or using GLFW.
The official GLFW web site can be found here:http://glfw.sourceforge.net/.It contains the latest version of GLFW, news and other information that isuseful for OpenGL development.
8. Acknowledgements
GLFW would not be what it is today without the help from:
- Keith Bauer, for his invaluable help with porting GLFW to Mac OS X, and for his many ideas.
- Camilla Berglund, for her efforts with porting GLFW to Mac OS X (continuing Keith Bauers work).
- Ozzy @ Orkysquad, for his dedication to GLFW, for debugging my source, and for his valuable experience with game development.
- Jeff Molofee, the author of the excellent OpenGL tutorials at NeHe Productions. Much of the Windows code of GLFW was originally based on Jeff's code.
- Douglas C. Schmidt and Irfan Pyarali, for their excellent article Strategies for Implementing POSIX Condition Variables on Win32, which is the basis for the Win32 condition variable implementation in GLFW.
- Gerald Franz, who made GLFW compile under IRIX, and supplied patches for the X11 keyboard translation routine.
- Glenn Lewis, for helping out with support for the D programming language.
- David Medlock, for doing the initial Lua port.
- Frank Wille, for helping me with the AmigaOS port and making GLFW compile under IRIX 5.3.
- Matt Sealey, for helping me with the MorphOS port.
- Paul R. Deppe, who helped me with Cygwin support, and made an adaption of PLIB so that it can use GLFW (instead of GLUT).
- Jarrod Davis, for the Delphi port of GLFW.
- Toni Jovanoski, for helping me with the MASM32 port of GLFW, and supplying the example program and fixed OpenGL & GLU bindings for MASM32.
- Sebastian Schuberth, for the OpenWatcom makefiles.
- Dmitri Shuralyov, Samuli Tuomola, Santi Zupancic, Sylvain Hellegouarch, and many others for support, bug reports and testing.
- www.opengl.org, and all the people on the discussion forums there that have provided help during the development of GLFW.
- The MSDN Online Linrary, which was used extensively for Windows development.
- All the feedback from GLFW users - thank you!