mirror of
https://github.com/glfw/glfw.git
synced 2024-11-21 17:45:10 +00:00
Convert some external links to reference links
This commit is contained in:
Camilla Löwy
parent
532bd66e7f
commit
63397fb0d5
@ -41,12 +41,13 @@ In other words:
|
||||
- Do not include window system headers unless you will use those APIs directly
|
||||
- If you do need such headers, include them before the GLFW header
|
||||
|
||||
If you are using an OpenGL extension loading library such as
|
||||
[glad](https://github.com/Dav1dde/glad), the extension loader header should
|
||||
be included before the GLFW one. GLFW attempts to detect any OpenGL or OpenGL
|
||||
ES header or extension loader header included before it and will then disable
|
||||
the inclusion of the default OpenGL header. Most extension loaders also define
|
||||
macros that disable similar headers below it.
|
||||
If you are using an OpenGL extension loading library such as [glad][], the
|
||||
extension loader header should be included before the GLFW one. GLFW attempts
|
||||
to detect any OpenGL or OpenGL ES header or extension loader header included
|
||||
before it and will then disable the inclusion of the default OpenGL header.
|
||||
Most extension loaders also define macros that disable similar headers below it.
|
||||
|
||||
[glad]: https://github.com/Dav1dde/glad
|
||||
|
||||
```c
|
||||
#include <glad/gl.h>
|
||||
@ -80,8 +81,9 @@ Only one of these may be defined at a time.
|
||||
|
||||
@note GLFW does not provide any of the API headers mentioned below. They are
|
||||
provided by your development environment or your OpenGL, OpenGL ES or Vulkan
|
||||
SDK, and most of them can be downloaded from the
|
||||
[Khronos Registry](https://www.khronos.org/registry/).
|
||||
SDK, and most of them can be downloaded from the [Khronos Registry][registry].
|
||||
|
||||
[registry]: https://www.khronos.org/registry/
|
||||
|
||||
@anchor GLFW_INCLUDE_GLCOREARB
|
||||
__GLFW_INCLUDE_GLCOREARB__ makes the GLFW header include the modern
|
||||
@ -153,9 +155,10 @@ hard-coded into your build environment. See the section for your development
|
||||
environment below. On Linux and other Unix-like operating systems, the list
|
||||
varies but can be retrieved in various ways as described below.
|
||||
|
||||
A good general introduction to linking is
|
||||
[Beginner's Guide to Linkers](https://www.lurklurk.org/linkers/linkers.html) by
|
||||
David Drysdale.
|
||||
A good general introduction to linking is [Beginner's Guide to
|
||||
Linkers][linker_guide] by David Drysdale.
|
||||
|
||||
[linker_guide]: https://www.lurklurk.org/linkers/linkers.html
|
||||
|
||||
|
||||
### With MinGW or Visual C++ on Windows {#build_link_win32}
|
||||
@ -217,7 +220,9 @@ target_link_libraries(myapp OpenGL::GL)
|
||||
```
|
||||
|
||||
For a minimal example of a program and GLFW sources built with CMake, see the
|
||||
[GLFW CMake Starter](https://github.com/juliettef/GLFW-CMake-starter) on GitHub.
|
||||
[GLFW CMake Starter][cmake_starter] on GitHub.
|
||||
|
||||
[cmake_starter]: https://github.com/juliettef/GLFW-CMake-starter
|
||||
|
||||
|
||||
### With CMake and installed GLFW binaries {#build_link_cmake_package}
|
||||
@ -261,12 +266,13 @@ target_link_libraries(myapp OpenGL::GL)
|
||||
|
||||
### With makefiles and pkg-config on Unix {#build_link_pkgconfig}
|
||||
|
||||
GLFW supports [pkg-config](https://www.freedesktop.org/wiki/Software/pkg-config/),
|
||||
and the `glfw3.pc` pkg-config file is generated when the GLFW library is built
|
||||
and is installed along with it. A pkg-config file describes all necessary
|
||||
compile-time and link-time flags and dependencies needed to use a library. When
|
||||
they are updated or if they differ between systems, you will get the correct
|
||||
ones automatically.
|
||||
GLFW supports [pkg-config][], and the `glfw3.pc` pkg-config file is generated
|
||||
when the GLFW library is built and is installed along with it. A pkg-config
|
||||
file describes all necessary compile-time and link-time flags and dependencies
|
||||
needed to use a library. When they are updated or if they differ between
|
||||
systems, you will get the correct ones automatically.
|
||||
|
||||
[pkg-config]: https://www.freedesktop.org/wiki/Software/pkg-config/
|
||||
|
||||
A typical compile and link command-line when using the static version of the
|
||||
GLFW library may look like this:
|
||||
|
||||
111
docs/compat.md
111
docs/compat.md
@ -15,16 +15,16 @@ be considered a breaking API change.
|
||||
|
||||
## X11 extensions, protocols and IPC standards {#compat_x11}
|
||||
|
||||
As GLFW uses Xlib directly, without any intervening toolkit
|
||||
library, it has sole responsibility for interacting well with the many and
|
||||
varied window managers in use on Unix-like systems. In order for applications
|
||||
and window managers to work well together, a number of standards and
|
||||
conventions have been developed that regulate behavior outside the scope of the
|
||||
X11 API; most importantly the
|
||||
[Inter-Client Communication Conventions Manual](https://www.tronche.com/gui/x/icccm/)
|
||||
(ICCCM) and
|
||||
[Extended Window Manager Hints](https://standards.freedesktop.org/wm-spec/wm-spec-latest.html)
|
||||
(EWMH) standards.
|
||||
As GLFW uses Xlib directly, without any intervening toolkit library, it has sole
|
||||
responsibility for interacting well with the many and varied window managers in
|
||||
use on Unix-like systems. In order for applications and window managers to work
|
||||
well together, a number of standards and conventions have been developed that
|
||||
regulate behavior outside the scope of the X11 API; most importantly the
|
||||
[Inter-Client Communication Conventions Manual][ICCCM] (ICCCM) and [Extended
|
||||
Window Manager Hints][EWMH] (EWMH) standards.
|
||||
|
||||
[ICCCM]: https://www.tronche.com/gui/x/icccm/
|
||||
[EWMH]: https://standards.freedesktop.org/wm-spec/wm-spec-latest.html
|
||||
|
||||
GLFW uses the `_MOTIF_WM_HINTS` window property to support borderless windows.
|
||||
If the running window manager does not support this property, the
|
||||
@ -50,16 +50,18 @@ compositing window manager to un-redirect full screen GLFW windows. If the
|
||||
running window manager uses compositing but does not support this property then
|
||||
additional copying may be performed for each buffer swap of full screen windows.
|
||||
|
||||
GLFW uses the
|
||||
[clipboard manager protocol](https://www.freedesktop.org/wiki/ClipboardManager/)
|
||||
to push a clipboard string (i.e. selection) owned by a GLFW window about to be
|
||||
destroyed to the clipboard manager. If there is no running clipboard manager,
|
||||
the clipboard string will be unavailable once the window has been destroyed.
|
||||
GLFW uses the [clipboard manager protocol][ClipboardManager] to push a clipboard
|
||||
string (i.e. selection) owned by a GLFW window about to be destroyed to the
|
||||
clipboard manager. If there is no running clipboard manager, the clipboard
|
||||
string will be unavailable once the window has been destroyed.
|
||||
|
||||
GLFW uses the
|
||||
[X drag-and-drop protocol](https://www.freedesktop.org/wiki/Specifications/XDND/)
|
||||
to provide file drop events. If the application originating the drag does not
|
||||
support this protocol, drag and drop will not work.
|
||||
[clipboardManager]: https://www.freedesktop.org/wiki/ClipboardManager/
|
||||
|
||||
GLFW uses the [X drag-and-drop protocol][XDND] to provide file drop events. If
|
||||
the application originating the drag does not support this protocol, drag and
|
||||
drop will not work.
|
||||
|
||||
[XDND]: https://www.freedesktop.org/wiki/Specifications/XDND/
|
||||
|
||||
GLFW uses the XRandR 1.3 extension to provide multi-monitor support. If the
|
||||
running X server does not support this version of this extension, multi-monitor
|
||||
@ -104,44 +106,49 @@ Wayland protocols to implement certain features if the compositor supports them.
|
||||
GLFW uses xkbcommon 0.5.0 to provide key and text input support. Earlier
|
||||
versions are not supported.
|
||||
|
||||
GLFW uses the [xdg-shell protocol](https://wayland.app/protocols/xdg-shell)
|
||||
to provide better window management. This protocol is mandatory for GLFW to
|
||||
display a window.
|
||||
GLFW uses the [xdg-shell][] protocol to provide better window management. This
|
||||
protocol is mandatory for GLFW to display a window.
|
||||
|
||||
GLFW uses the
|
||||
[relative pointer protocol](https://wayland.app/protocols/relative-pointer-unstable-v1)
|
||||
alongside the
|
||||
[pointer constraints protocol](https://wayland.app/protocols/pointer-constraints-unstable-v1)
|
||||
to implement disabled cursor. If the running compositor does not support both
|
||||
of these protocols, disabling the cursor will have no effect.
|
||||
[xdg-shell]: https://wayland.app/protocols/xdg-shell
|
||||
|
||||
GLFW uses the
|
||||
[idle inhibit protocol](https://wayland.app/protocols/idle-inhibit-unstable-v1)
|
||||
to prohibit the screensaver from starting. If the running compositor does not
|
||||
support this protocol, the screensaver may start even for full screen windows.
|
||||
GLFW uses the [relative-pointer-unstable-v1][] protocol alongside the
|
||||
[pointer-constraints-unstable-v1][] protocol to implement disabled cursor. If
|
||||
the running compositor does not support both of these protocols, disabling the
|
||||
cursor will have no effect.
|
||||
|
||||
GLFW uses the
|
||||
[libdecor library](https://gitlab.freedesktop.org/libdecor/libdecor) for window
|
||||
decorations, where available. This in turn provides good quality client-side
|
||||
decorations (drawn by the application) on desktop systems that do not support
|
||||
server-side decorations (drawn by the window manager). On systems that do not
|
||||
provide either libdecor or xdg-decoration, very basic window decorations are
|
||||
provided. These do not include the window title or any caption buttons.
|
||||
[relative-pointer-unstable-v1]: https://wayland.app/protocols/relative-pointer-unstable-v1
|
||||
[pointer-constraints-unstable-v1]: https://wayland.app/protocols/pointer-constraints-unstable-v1
|
||||
|
||||
GLFW uses the
|
||||
[xdg-decoration protocol](https://wayland.app/protocols/xdg-decoration-unstable-v1)
|
||||
to request decorations to be drawn around its windows. This protocol is part
|
||||
of wayland-protocols 1.15, and mandatory at build time. If the running
|
||||
compositor does not support this protocol, a very simple frame will be drawn by
|
||||
GLFW itself, using the
|
||||
[viewporter protocol](https://wayland.app/protocols/viewporter)
|
||||
alongside subsurfaces. If the running compositor does not support these
|
||||
protocols either, no decorations will be drawn around windows.
|
||||
GLFW uses the [idle-inhibit-unstable-v1][] protocol to prohibit the screensaver
|
||||
from starting. If the running compositor does not support this protocol, the
|
||||
screensaver may start even for full screen windows.
|
||||
|
||||
GLFW uses the [xdg-activation
|
||||
protocol](https://wayland.app/protocols/xdg-activation-v1)
|
||||
to implement window focus and attention requests. If the running compositor
|
||||
does not support this protocol, window focus and attention requests do nothing.
|
||||
[idle-inhibit-unstable-v1]: https://wayland.app/protocols/idle-inhibit-unstable-v1
|
||||
|
||||
GLFW uses the [libdecor][] library for window decorations, where available.
|
||||
This in turn provides good quality client-side decorations (drawn by the
|
||||
application) on desktop systems that do not support server-side decorations
|
||||
(drawn by the window manager). On systems that do not provide either libdecor
|
||||
or xdg-decoration, very basic window decorations are provided. These do not
|
||||
include the window title or any caption buttons.
|
||||
|
||||
[libdecor]: https://gitlab.freedesktop.org/libdecor/libdecor
|
||||
|
||||
GLFW uses the [xdg-decoration-unstable-v1][] protocol to request decorations to
|
||||
be drawn around its windows. This protocol is part of wayland-protocols 1.15,
|
||||
and mandatory at build time. If the running compositor does not support this
|
||||
protocol, a very simple frame will be drawn by GLFW itself, using the
|
||||
[viewporter][] protocol alongside subsurfaces. If the running compositor does
|
||||
not support these protocols either, no decorations will be drawn around windows.
|
||||
|
||||
[xdg-decoration-unstable-v1]: https://wayland.app/protocols/xdg-decoration-unstable-v1
|
||||
[viewporter]: https://wayland.app/protocols/viewporter
|
||||
|
||||
GLFW uses the [xdg-activation-v1][] protocol to implement window focus and
|
||||
attention requests. If the running compositor does not support this protocol,
|
||||
window focus and attention requests do nothing.
|
||||
|
||||
[xdg-activation-v1]: https://wayland.app/protocols/xdg-activation-v1
|
||||
|
||||
|
||||
## GLX extensions {#compat_glx}
|
||||
|
||||
@ -19,8 +19,8 @@ GLFW uses [CMake](https://cmake.org/) to generate project files or makefiles
|
||||
for your chosen development environment. To compile GLFW, first generate these
|
||||
files with CMake and then use them to compile the GLFW library.
|
||||
|
||||
If you are on Windows and macOS you can
|
||||
[download CMake](https://cmake.org/download/) from their site.
|
||||
If you are on Windows and macOS you can [download
|
||||
CMake](https://cmake.org/download/) from their site.
|
||||
|
||||
If you are on a Unix-like system such as Linux, FreeBSD or Cygwin or have
|
||||
a package system like Fink, MacPorts or Homebrew, you can install its CMake
|
||||
@ -28,9 +28,10 @@ package.
|
||||
|
||||
CMake is a complex tool and this guide will only show a few of the possible ways
|
||||
to set up and compile GLFW. The CMake project has their own much more detailed
|
||||
[CMake user guide](https://cmake.org/cmake/help/latest/guide/user-interaction/)
|
||||
that includes everything in this guide not specific to GLFW. It may be a useful
|
||||
companion to this one.
|
||||
[CMake user guide][cmake-guide] that includes everything in this guide not
|
||||
specific to GLFW. It may be a useful companion to this one.
|
||||
|
||||
[cmake-guide]: https://cmake.org/cmake/help/latest/guide/user-interaction/
|
||||
|
||||
|
||||
### Installing dependencies {#compile_deps}
|
||||
@ -263,10 +264,11 @@ __USE_MSVC_RUNTIME_LIBRARY_DLL__ determines whether to use the DLL version or th
|
||||
static library version of the Visual C++ runtime library. When enabled, the
|
||||
DLL version of the Visual C++ library is used. This is enabled by default.
|
||||
|
||||
On CMake 3.15 and later you can set the standard CMake
|
||||
[CMAKE_MSVC_RUNTIME_LIBRARY](https://cmake.org/cmake/help/latest/variable/CMAKE_MSVC_RUNTIME_LIBRARY.html)
|
||||
On CMake 3.15 and later you can set the standard CMake [CMAKE_MSVC_RUNTIME_LIBRARY][]
|
||||
variable instead of this GLFW-specific option.
|
||||
|
||||
[CMAKE_MSVC_RUNTIME_LIBRARY]: https://cmake.org/cmake/help/latest/variable/CMAKE_MSVC_RUNTIME_LIBRARY.html
|
||||
|
||||
@anchor GLFW_USE_HYBRID_HPG
|
||||
__GLFW_USE_HYBRID_HPG__ determines whether to export the `NvOptimusEnablement` and
|
||||
`AmdPowerXpressRequestHighPerformance` symbols, which force the use of the
|
||||
@ -326,8 +328,9 @@ cmake -S path/to/glfw -B path/to/build -D CMAKE_TOOLCHAIN_FILE=CMake/x86_64-w64-
|
||||
The path to the toolchain file is relative to the path to the GLFW source tree
|
||||
passed to the `-S` flag, not to the current directory.
|
||||
|
||||
For more details see the
|
||||
[CMake toolchain guide](https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html).
|
||||
For more details see the [CMake toolchain guide][cmake-toolchains].
|
||||
|
||||
[cmake-toolchains]: https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html
|
||||
|
||||
|
||||
## Compiling GLFW manually {#compile_manual}
|
||||
|
||||
@ -735,8 +735,10 @@ indication of where they are located on the device. Their order may also vary
|
||||
between platforms even with the same device.
|
||||
|
||||
To solve this problem the SDL community crowdsourced the
|
||||
[SDL_GameControllerDB](https://github.com/gabomdq/SDL_GameControllerDB) project,
|
||||
a database of mappings from many different devices to an Xbox-like gamepad.
|
||||
[SDL_GameControllerDB][] project, a database of mappings from many different
|
||||
devices to an Xbox-like gamepad.
|
||||
|
||||
[SDL_GameControllerDB]: https://github.com/gabomdq/SDL_GameControllerDB
|
||||
|
||||
GLFW supports this mapping format and contains a copy of the mappings
|
||||
available at the time of release. See @ref gamepad_mapping for how to update
|
||||
@ -811,9 +813,8 @@ the largest available index for each array.
|
||||
|
||||
### Gamepad mappings {#gamepad_mapping}
|
||||
|
||||
GLFW contains a copy of the mappings available in
|
||||
[SDL_GameControllerDB](https://github.com/gabomdq/SDL_GameControllerDB) at the
|
||||
time of release. Newer ones can be added at runtime with @ref
|
||||
GLFW contains a copy of the mappings available in [SDL_GameControllerDB][] at
|
||||
the time of release. Newer ones can be added at runtime with @ref
|
||||
glfwUpdateGamepadMappings.
|
||||
|
||||
```c
|
||||
|
||||
@ -105,14 +105,15 @@ glfwGetJoystickHats. Possible values are `GLFW_TRUE` and `GLFW_FALSE`.
|
||||
|
||||
@anchor GLFW_ANGLE_PLATFORM_TYPE_hint
|
||||
__GLFW_ANGLE_PLATFORM_TYPE__ specifies the platform type (rendering backend) to
|
||||
request when using OpenGL ES and EGL via
|
||||
[ANGLE](https://chromium.googlesource.com/angle/angle/). If the requested
|
||||
platform type is unavailable, ANGLE will use its default. Possible values are
|
||||
one of `GLFW_ANGLE_PLATFORM_TYPE_NONE`, `GLFW_ANGLE_PLATFORM_TYPE_OPENGL`,
|
||||
request when using OpenGL ES and EGL via [ANGLE][]. If the requested platform
|
||||
type is unavailable, ANGLE will use its default. Possible values are one of
|
||||
`GLFW_ANGLE_PLATFORM_TYPE_NONE`, `GLFW_ANGLE_PLATFORM_TYPE_OPENGL`,
|
||||
`GLFW_ANGLE_PLATFORM_TYPE_OPENGLES`, `GLFW_ANGLE_PLATFORM_TYPE_D3D9`,
|
||||
`GLFW_ANGLE_PLATFORM_TYPE_D3D11`, `GLFW_ANGLE_PLATFORM_TYPE_VULKAN` and
|
||||
`GLFW_ANGLE_PLATFORM_TYPE_METAL`.
|
||||
|
||||
[ANGLE]: https://chromium.googlesource.com/angle/angle/
|
||||
|
||||
The ANGLE platform type is specified via the `EGL_ANGLE_platform_angle`
|
||||
extension. This extension is not used if this hint is
|
||||
`GLFW_ANGLE_PLATFORM_TYPE_NONE`, which is the default value.
|
||||
@ -145,11 +146,12 @@ the `VK_KHR_xlib_surface` extension. Possible values are `GLFW_TRUE` and
|
||||
#### Wayland specific init hints {#init_hints_wayland}
|
||||
|
||||
@anchor GLFW_WAYLAND_LIBDECOR_hint
|
||||
__GLFW_WAYLAND_LIBDECOR__ specifies whether to use
|
||||
[libdecor](https://gitlab.freedesktop.org/libdecor/libdecor) for window
|
||||
__GLFW_WAYLAND_LIBDECOR__ specifies whether to use [libdecor][] for window
|
||||
decorations where available. Possible values are `GLFW_WAYLAND_PREFER_LIBDECOR`
|
||||
and `GLFW_WAYLAND_DISABLE_LIBDECOR`. This is ignored on other platforms.
|
||||
|
||||
[libdecor]: https://gitlab.freedesktop.org/libdecor/libdecor
|
||||
|
||||
|
||||
#### Supported and default values {#init_hints_values}
|
||||
|
||||
|
||||
@ -16,8 +16,9 @@ required to create full screen windows with GLFW 3.
|
||||
The GLFW 3 header is named @ref glfw3.h and moved to the `GLFW` directory, to
|
||||
avoid collisions with the headers of other major versions. Similarly, the GLFW
|
||||
3 library is named `glfw3,` except when it's installed as a shared library on
|
||||
Unix-like systems, where it uses the
|
||||
[soname](https://en.wikipedia.org/wiki/soname) `libglfw.so.3`.
|
||||
Unix-like systems, where it uses the [soname][] `libglfw.so.3`.
|
||||
|
||||
[soname]: https://en.wikipedia.org/wiki/soname
|
||||
|
||||
__Old syntax__
|
||||
```c
|
||||
@ -36,18 +37,20 @@ The threading functions have been removed, including the per-thread sleep
|
||||
function. They were fairly primitive, under-used, poorly integrated and took
|
||||
time away from the focus of GLFW (i.e. context, input and window). There are
|
||||
better threading libraries available and native threading support is available
|
||||
in both [C++11](https://en.cppreference.com/w/cpp/thread) and
|
||||
[C11](https://en.cppreference.com/w/c/thread), both of which are gaining
|
||||
traction.
|
||||
in both [C++11][] and [C11][], both of which are gaining traction.
|
||||
|
||||
[C++11]: https://en.cppreference.com/w/cpp/thread
|
||||
[C11]: https://en.cppreference.com/w/c/thread
|
||||
|
||||
If you wish to use the C++11 or C11 facilities but your compiler doesn't yet
|
||||
support them, see the
|
||||
[TinyThread++](https://gitorious.org/tinythread/tinythreadpp) and
|
||||
[TinyCThread](https://github.com/tinycthread/tinycthread) projects created by
|
||||
support them, see the [TinyThread++][] and [TinyCThread][] projects created by
|
||||
the original author of GLFW. These libraries implement a usable subset of the
|
||||
threading APIs in C++11 and C11, and in fact some GLFW 3 test programs use
|
||||
TinyCThread.
|
||||
|
||||
[TinyThread++]: https://gitorious.org/tinythread/tinythreadpp
|
||||
[TinyCThread]: https://github.com/tinycthread/tinycthread
|
||||
|
||||
However, GLFW 3 has better support for _use from multiple threads_ than GLFW
|
||||
2 had. Contexts can be made current on any thread, although only a single
|
||||
thread at a time, and the documentation explicitly states which functions may be
|
||||
@ -84,13 +87,14 @@ __Removed functions__
|
||||
|
||||
### Removal of GLFWCALL macro {#moving_stdcall}
|
||||
|
||||
The `GLFWCALL` macro, which made callback functions use
|
||||
[\_\_stdcall](https://msdn.microsoft.com/en-us/library/zxk0tw93.aspx) on Windows,
|
||||
has been removed. GLFW is written in C, not Pascal. Removing this macro means
|
||||
there's one less thing for application programmers to remember, i.e. the
|
||||
requirement to mark all callback functions with `GLFWCALL`. It also simplifies
|
||||
the creation of DLLs and DLL link libraries, as there's no need to explicitly
|
||||
disable `@n` entry point suffixes.
|
||||
The `GLFWCALL` macro, which made callback functions use [\_\_stdcall][stdcall]
|
||||
on Windows, has been removed. GLFW is written in C, not Pascal. Removing this
|
||||
macro means there's one less thing for application programmers to remember, i.e.
|
||||
the requirement to mark all callback functions with `GLFWCALL`. It also
|
||||
simplifies the creation of DLLs and DLL link libraries, as there's no need to
|
||||
explicitly disable `@n` entry point suffixes.
|
||||
|
||||
[stdcall]: https://msdn.microsoft.com/en-us/library/zxk0tw93.aspx
|
||||
|
||||
__Old syntax__
|
||||
```c
|
||||
@ -109,7 +113,9 @@ Because GLFW 3 supports multiple windows, window handle parameters have been
|
||||
added to all window-related GLFW functions and callbacks. The handle of
|
||||
a newly created window is returned by @ref glfwCreateWindow (formerly
|
||||
`glfwOpenWindow`). Window handles are pointers to the
|
||||
[opaque](https://en.wikipedia.org/wiki/Opaque_data_type) type @ref GLFWwindow.
|
||||
[opaque][opaque-type] type @ref GLFWwindow.
|
||||
|
||||
[opaque-type]: https://en.wikipedia.org/wiki/Opaque_data_type
|
||||
|
||||
__Old syntax__
|
||||
```c
|
||||
@ -129,7 +135,7 @@ instead of passing `GLFW_FULLSCREEN` you specify which monitor you wish the
|
||||
window to use. The @ref glfwGetPrimaryMonitor function returns the monitor that
|
||||
GLFW 2 would have selected, but there are many other
|
||||
[monitor functions](@ref monitor_guide). Monitor handles are pointers to the
|
||||
[opaque](https://en.wikipedia.org/wiki/Opaque_data_type) type @ref GLFWmonitor.
|
||||
[opaque][opaque-type] type @ref GLFWmonitor.
|
||||
|
||||
__Old basic full screen__
|
||||
```c
|
||||
@ -376,14 +382,15 @@ glfwGetJoystickAxes and @ref glfwGetJoystickButtons functions.
|
||||
|
||||
### Win32 MBCS support {#moving_mbcs}
|
||||
|
||||
The Win32 port of GLFW 3 will not compile in
|
||||
[MBCS mode](https://msdn.microsoft.com/en-us/library/5z097dxa.aspx).
|
||||
However, because the use of the Unicode version of the Win32 API doesn't affect
|
||||
the process as a whole, but only those windows created using it, it's perfectly
|
||||
The Win32 port of GLFW 3 will not compile in [MBCS mode][MBCS]. However,
|
||||
because the use of the Unicode version of the Win32 API doesn't affect the
|
||||
process as a whole, but only those windows created using it, it's perfectly
|
||||
possible to call MBCS functions from other parts of the same application.
|
||||
Therefore, even if an application using GLFW has MBCS mode code, there's no need
|
||||
for GLFW itself to support it.
|
||||
|
||||
[MBCS]: https://msdn.microsoft.com/en-us/library/5z097dxa.aspx
|
||||
|
||||
|
||||
### Support for versions of Windows older than XP {#moving_windows}
|
||||
|
||||
@ -429,10 +436,12 @@ invalidating any window handles you may still have.
|
||||
### GLU header inclusion {#moving_glu}
|
||||
|
||||
GLFW 3 does not by default include the GLU header and GLU itself has been
|
||||
deprecated by [Khronos](https://en.wikipedia.org/wiki/Khronos_Group). __New
|
||||
projects should not use GLU__, but if you need it for legacy code that
|
||||
has been moved to GLFW 3, you can request that the GLFW header includes it by
|
||||
defining @ref GLFW_INCLUDE_GLU before the inclusion of the GLFW header.
|
||||
deprecated by [Khronos][]. __New projects should not use GLU__, but if you need
|
||||
it for legacy code that has been moved to GLFW 3, you can request that the GLFW
|
||||
header includes it by defining @ref GLFW_INCLUDE_GLU before the inclusion of the
|
||||
GLFW header.
|
||||
|
||||
[Khronos]: https://en.wikipedia.org/wiki/Khronos_Group
|
||||
|
||||
__Old syntax__
|
||||
```c
|
||||
@ -446,11 +455,13 @@ __New syntax__
|
||||
```
|
||||
|
||||
There are many libraries that offer replacements for the functionality offered
|
||||
by GLU. For the matrix helper functions, see math libraries like
|
||||
[GLM](https://github.com/g-truc/glm) (for C++),
|
||||
[linmath.h](https://github.com/datenwolf/linmath.h) (for C) and others. For the
|
||||
tessellation functions, see for example
|
||||
[libtess2](https://github.com/memononen/libtess2).
|
||||
by GLU. For the matrix helper functions, see math libraries like [GLM][] (for
|
||||
C++), [linmath.h][] (for C) and others. For the tessellation functions, see for
|
||||
example [libtess2][].
|
||||
|
||||
[GLM]: https://github.com/g-truc/glm
|
||||
[linmath.h]: https://github.com/datenwolf/linmath.h
|
||||
[libtess2]: https://github.com/memononen/libtess2
|
||||
|
||||
|
||||
## Name change tables {#moving_tables}
|
||||
|
||||
@ -61,10 +61,11 @@ GLFW now supports specifying the app_id for a Wayland window using the
|
||||
|
||||
GLFW now provides the
|
||||
[GLFW_ANGLE_PLATFORM_TYPE](@ref GLFW_ANGLE_PLATFORM_TYPE_hint) init hint for
|
||||
requesting a specific rendering backend when using
|
||||
[ANGLE](https://chromium.googlesource.com/angle/angle/) to create OpenGL ES
|
||||
requesting a specific rendering backend when using [ANGLE][] to create OpenGL ES
|
||||
contexts.
|
||||
|
||||
[ANGLE]: https://chromium.googlesource.com/angle/angle/
|
||||
|
||||
|
||||
#### Captured cursor mode {#captured_cursor_34}
|
||||
|
||||
|
||||
@ -336,13 +336,14 @@ presses _Escape_ or closes the window.
|
||||
|
||||
@snippet triangle-opengl.c code
|
||||
|
||||
The program above can be found in the
|
||||
[source package](https://www.glfw.org/download.html) as
|
||||
The program above can be found in the [source package][download] as
|
||||
`examples/triangle-opengl.c` and is compiled along with all other examples when
|
||||
you build GLFW. If you built GLFW from the source package then you already have
|
||||
this as `triangle-opengl.exe` on Windows, `triangle-opengl` on Linux or
|
||||
`triangle-opengl.app` on macOS.
|
||||
|
||||
[download]: https://www.glfw.org/download.html
|
||||
|
||||
This tutorial used only a few of the many functions GLFW provides. There are
|
||||
guides for each of the areas covered by GLFW. Each guide will introduce all the
|
||||
functions for that category.
|
||||
|
||||
@ -406,8 +406,9 @@ mode, which may provide additional error and diagnostic reporting functionality.
|
||||
Possible values are `GLFW_TRUE` and `GLFW_FALSE`.
|
||||
|
||||
Debug contexts for OpenGL and OpenGL ES are described in detail by the
|
||||
[GL_KHR_debug](https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_debug.txt)
|
||||
extension.
|
||||
[GL_KHR_debug][] extension.
|
||||
|
||||
[GL_KHR_debug]: https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_debug.txt
|
||||
|
||||
@note `GLFW_CONTEXT_DEBUG` is the new name introduced in GLFW 3.4. The older
|
||||
`GLFW_OPENGL_DEBUG_CONTEXT` name is also available for compatibility.
|
||||
@ -440,8 +441,9 @@ current one. If the behavior is `GLFW_RELEASE_BEHAVIOR_NONE`, the pipeline will
|
||||
not be flushed on release.
|
||||
|
||||
Context release behaviors are described in detail by the
|
||||
[GL_KHR_context_flush_control](https://www.opengl.org/registry/specs/KHR/context_flush_control.txt)
|
||||
extension.
|
||||
[GL_KHR_context_flush_control][] extension.
|
||||
|
||||
[GL_KHR_context_flush_control]: https://www.opengl.org/registry/specs/KHR/context_flush_control.txt
|
||||
|
||||
@anchor GLFW_CONTEXT_NO_ERROR_hint
|
||||
__GLFW_CONTEXT_NO_ERROR__ specifies whether errors should be generated by the
|
||||
@ -449,8 +451,9 @@ context. Possible values are `GLFW_TRUE` and `GLFW_FALSE`. If enabled,
|
||||
situations that would have generated errors instead cause undefined behavior.
|
||||
|
||||
The no error mode for OpenGL and OpenGL ES is described in detail by the
|
||||
[GL_KHR_no_error](https://www.opengl.org/registry/specs/KHR/no_error.txt)
|
||||
extension.
|
||||
[GL_KHR_no_error][] extension.
|
||||
|
||||
[GL_KHR_no_error]: https://www.opengl.org/registry/specs/KHR/no_error.txt
|
||||
|
||||
|
||||
#### Win32 specific hints {#window_hints_win32}
|
||||
|
||||
@ -2648,9 +2648,10 @@ GLFWAPI void glfwGetMonitorWorkarea(GLFWmonitor* monitor, int* xpos, int* ypos,
|
||||
* specified monitor.
|
||||
*
|
||||
* Some platforms do not provide accurate monitor size information, either
|
||||
* because the monitor
|
||||
* [EDID](https://en.wikipedia.org/wiki/Extended_display_identification_data)
|
||||
* data is incorrect or because the driver does not report it accurately.
|
||||
* because the monitor [EDID][] data is incorrect or because the driver does
|
||||
* not report it accurately.
|
||||
*
|
||||
* [EDID]: https://en.wikipedia.org/wiki/Extended_display_identification_data
|
||||
*
|
||||
* Any or all of the size arguments may be `NULL`. If an error occurs, all
|
||||
* non-`NULL` size arguments will be set to zero.
|
||||
@ -3160,18 +3161,21 @@ GLFWAPI void glfwWindowHintString(int hint, const char* value);
|
||||
* @remark @macos The GLFW window has no icon, as it is not a document
|
||||
* window, but the dock icon will be the same as the application bundle's icon.
|
||||
* For more information on bundles, see the
|
||||
* [Bundle Programming Guide](https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFBundles/)
|
||||
* in the Mac Developer Library.
|
||||
* [Bundle Programming Guide][bundle-guide] in the Mac Developer Library.
|
||||
*
|
||||
* [bundle-guide]: https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFBundles/
|
||||
*
|
||||
* @remark @macos On OS X 10.10 and later the window frame will not be rendered
|
||||
* at full resolution on Retina displays unless the
|
||||
* [GLFW_COCOA_RETINA_FRAMEBUFFER](@ref GLFW_COCOA_RETINA_FRAMEBUFFER_hint)
|
||||
* hint is `GLFW_TRUE` and the `NSHighResolutionCapable` key is enabled in the
|
||||
* application bundle's `Info.plist`. For more information, see
|
||||
* [High Resolution Guidelines for OS X](https://developer.apple.com/library/mac/documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Explained/Explained.html)
|
||||
* in the Mac Developer Library. The GLFW test and example programs use
|
||||
* a custom `Info.plist` template for this, which can be found as
|
||||
* `CMake/Info.plist.in` in the source tree.
|
||||
* [High Resolution Guidelines for OS X][hidpi-guide] in the Mac Developer
|
||||
* Library. The GLFW test and example programs use a custom `Info.plist`
|
||||
* template for this, which can be found as `CMake/Info.plist.in` in the source
|
||||
* tree.
|
||||
*
|
||||
* [hidpi-guide]: https://developer.apple.com/library/mac/documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Explained/Explained.html
|
||||
*
|
||||
* @remark @macos When activating frame autosaving with
|
||||
* [GLFW_COCOA_FRAME_NAME](@ref GLFW_COCOA_FRAME_NAME_hint), the specified
|
||||
@ -3345,8 +3349,9 @@ GLFWAPI void glfwSetWindowTitle(GLFWwindow* window, const char* title);
|
||||
* @remark @macos Regular windows do not have icons on macOS. This function
|
||||
* will emit @ref GLFW_FEATURE_UNAVAILABLE. The dock icon will be the same as
|
||||
* the application bundle's icon. For more information on bundles, see the
|
||||
* [Bundle Programming Guide](https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFBundles/)
|
||||
* in the Mac Developer Library.
|
||||
* [Bundle Programming Guide][bundle-guide] in the Mac Developer Library.
|
||||
*
|
||||
* [bundle-guide]: https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFBundles/
|
||||
*
|
||||
* @remark @wayland There is no existing protocol to change an icon, the
|
||||
* window will thus inherit the one defined in the application's desktop file.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user