Giter Site home page Giter Site logo

cginternals / glbinding Goto Github PK

View Code? Open in Web Editor NEW
820.0 42.0 94.0 24.62 MB

A C++ binding for the OpenGL API, generated using the gl.xml specification.

Home Page: https://glbinding.org

License: MIT License

CMake 1.21% GLSL 0.04% C++ 98.39% C 0.29% Makefile 0.03% Dockerfile 0.04%
c-plus-plus c-plus-plus-11 library opengl-bindings opengl-library

glbinding's Introduction


glbinding is a cross-platform C++ binding for the OpenGL API.

GitHub release C++ CI Travis Appveyor Tokei

Documentation Examples Tools

glbinding leverages C++11 features like enum classes, lambdas, and variadic templates, instead of relying on macros; all OpenGL symbols are real functions and variables. It provides type-safe parameters, per-feature API headers, lazy function resolution, multi-context and multi-thread support, global and local function callbacks, meta information about the generated OpenGL binding and the OpenGL runtime, as well as tools and examples for quick-starting your projects. Based on the OpenGL API specification (gl.xml) glbinding is generated using python scripts and templates that can be easily adapted to fit custom needs.

what-is-glbinding

Code that is written using a typical C binding for OpenGL, e.g., GLEW, is fully compatible for the use with glbinding and causes no significant impact on runtime performance (see compare example): just replace all includes to the former binding, replace the initialization code and use the appropriate API namespace, e.g., gl for full availability of the OpenGL API.

#include <glbinding/gl/gl.h>
using namespace gl;

// ...
auto shader = glCreateShader(GL_COMPUTE_SHADER);
// ...

glbinding is compatible with OpenGL-compatible windowing toolkits and we provide example integrations for the following ones within the examples:

Resources

Installation and Development

Feature Documentation and Code Snippets

Install Instructions

glbinding is available for different platforms using different distribution channels. You can either download the source and manually compile it or use one of the pre-compiled releases of this repository. For systems providing package managers, we generally strive for packages in these package managers. An overview on availability of glbinding can be found on repology.org.

Windows

The various glbinding packages can be installed either by downloading an installer, e.g., the x64 installer for glbinding v3.1.0 for Microsoft Visual Studio 2015, or downloading and extracting one of the precompiled archives, e.g. runtime, examples, dev, and tools. Since lately, glbinding is also available on vcpkg with more recent releases:

> vcpkg install glbinding

Alternatively, download the source code and commence building from source.

Ubuntu

glbinding is provided on Ubuntu using PPAs and in Ubuntu universe since Artful Aardvark. We maintain our own PPA for most recent releases. Using the current PPA as example, the following lines install glbinding including the GLFW examples:

> sudo apt-add-repository ppa:cginternals/ppa
> sudo apt-get update
> sudo apt-get install libglbinding-examples-glfw
> # start example
> /usr/share/glbinding/cubescape

To use glbinding as dependency, install the development package:

> sudo apt-get install libglbinding-dev libglbinding-dbg

Alternatively, download the source code and commence building from source.

Arch Linux

On Arch, glbinding is provided by the glbinding package in the community repository. To install glbinding execute the following line:

> sudo pacman -S glbinding

Alternatively, download the source code and commence building from source.

macOS

The package manager on macOS we depend on is homebrew. The package there is called glbinding. To install glbinding using homebrew, execute the following line:

> brew install glbinding

Alternatively, download the source code and commence building from source.

Debian-based Systems

glbinding is available for Debian 9 (Stretch), 10 (Buster), 11 (Bullseye) and Sid. Install it using apt install libglbinding-dev. For advanced use, download the source code and commence building from source.

Cross-Platform Package Managers

As one of the cross-platform package managers, conan provides glbinding in its center index. You can use the following line to install glbinding using conan:

> conan install glbinding/3.1.0@

Build Instructions

Prerequisites and Dependencies

The only mandatory run-time dependencies of glbinding are the STL of the used compiler and an OpenGL driver library, dynamically linked with your application. Building glbinding from source has several mandatory and optional dependencies:

  • CMake 3.0 or higher for building glbinding from source (mandatory for any build from source)
  • git for version control and script supporting tasks
  • GLFW 3.2 or higher for examples and tools
  • GLEW 1.6 or higher for the comparison example (optional)
  • cpplocate for the examples (optional)
  • Qt5 5.0 or higher for the qt-based example (optional)
  • googletest for tests (optional)
  • Doxygen 1.8 or higher for generating the documentation on your system
    • graphviz for generating diagrams (optional)

Compile Instructions

For compilation, a C++11 compliant compiler, e.g., GCC 4.8, Clang 3.3, MSVC 2013 Update 3, is required. First, download the source code as archive or via git:

> git clone https://github.com/cginternals/glbinding.git
> cd glbinding

Then, depending on the version of glbinding you want to build, choose the appropriate tag or branch, e.g., for the 2.1.4 release:

> git fetch --tags
> git checkout v2.1.4

The actual compilation can be done using CMake and your favorite compiler and IDE.

For building glbinding CMake via command line can be used (should work on all systems):

First, create a build directory (we do not recommend in-source builds):

> mkdir build
> cd build

Configure glbinding with your preferred or default generator, e.g., for Visual Studio 2017 in x64 use (note: some IDEs have integrated support for CMake projects, e.g., Qt Creator, and allow you to skip the manual project configuration):

> cmake .. -G "Visual Studio 17 2022" -A x64

In order to compile the project, either use you favorite Editor/IDE with the created project or use CMake as follows:

> cmake --build .

For multi-configuration projects specific configuration (e.g., on Windows using MSVC) can be built using:

> cmake --build . --config Release
> cmake --build . --config Debug

Update Generated Source Code

The generation scripts for glbinding are maintained within the khrbinding-generator project. Assuming a directory structure with both projects such as <projects>/glbinding and <projects>/khrbinding-generator, updating the source code is started as follows:

> python3 update.py -p "profiles/gl.json"
> python3 generate.py -p "profiles/gl.json" -d "../glbinding/source"

Tips for Linking

We suggest using the build system CMake for a smooth integration. For it, glbinding provides a configuration script that should be installed into your system or at least accessible by CMake. In your projects' CMakeLists.txt, add one of the following lines:

find_package(glbinding QUIET) # if you want to check for existence
find_package(glbinding REQUIRED) # if it is really required in your project

Finally, just link glbinding to your own library or executable:

target_link_libraries(${target} ... PUBLIC
    glbinding::glbinding
    glbinding::glbinding-aux # for additional, auxiliary features as logging, meta information, or debugging functionality
)

Dependency on KHR Headers

As of mid 2019, the OpenGL API depends on the platform headers from the Khronos group, even on desktop systems. This introduced a direct dependency of glbinding to the KHR/khrplatform.h header file. For most Linux systems, these headers are easily available (e.g., by installing libegl1-mesa-dev on Ubuntu), whereas on other systems, pre-existing packages are scarce. Even in the case of Ubuntu, one can argue that installing the EGL dependency is strange, as glbinding does not depend on EGL in any way.

For those cases, glbinding comes with a copy of the headers for internal use.

This solution has one significant downside: As those headers are used by the types of the OpenGL API and the types are used within the public interface of glbinding, the khrplatform.h headers needs to be present when building downstream projects, i.e., they need to be installed along glbinding. In order to not conflict with packages providing the official headers, this internal header has to be installed on a separate location. This complicates the project setup and results in the following usage scenarios for you to choose from:

KHR/khrplatform.h Usage

For this usage scenario, glbinding needs to get built with the CMake option OPTION_BUILD_OWN_KHR_HEADERS set to Off and system-wide availability of the KHR/khrplatform.h headers, e.g., by having libegl1-mesa-dev installed. If either the option is On or the system-wide headers are not found, the internally provided headers are used instead.

This decision is stored as property of the glbinding CMake target and will be used for downstream projects as well. The use and propagation of this decision is transparent to the user as well, i.e., the user should not need to handle this downstream. The only thing to consider is to have the system-wide KHR/khrplatform.h headers available when building the downstream project.

glbinding-internal khrplatform.h Usage

For this usage scenario, glbinding should get built with the CMake option OPTION_BUILD_OWN_KHR_HEADERS set to On. Alternatively, this scenario is the fallback if the official KHR/khrplatform.h headers are not found.

This decision is stored as property of the glbinding CMake target and will be used for downstream projects as well. The use and propagation of this decision is transparent to the user as well, i.e., the user should not need to handle this downstream.

Basic Example

The following examples are tailored for use with glbinding 3.0 and above.

glbinding has to be initialized once on the active OpenGL context you want to use glbinding with. For initialization, a callback for function pointer resolution must be passed, which your context creation API should provide. In the most basic case, you call glbinding::initialize once:

#include <glbinding/gl/gl.h>
#include <glbinding/glbinding.h>

using namespace gl;

int main()
{
  // create context, e.g. using GLFW, Qt, SDL, GLUT, ...

  // Assume context creation using GLFW
  glbinding::initialize(glfwGetProcAddress);

  glBegin(GL_TRIANGLES);
  // ...
  glEnd();
}

Features

The following examples are tailored for use with glbinding 3.0 and above.

Type-Safe Parameters

The original OpenGL API provides several concepts in their interface, namely functions, booleans, bitfields, enums, as well as special values and basic types but mostly does not differentiate between these types. Hence, actual knowledge about each function and its parameters is required; there is no way for a basic code assistance. As glbinding differentiates between all these types, IDEs and compilers can detect wrong usages of the OpenGL API.

One example is the passing of a named constant in places where a bit combination is expected:

glClear(GL_COLOR_BUFFER_BIT); // valid
glClear(GL_FRAMEBUFFER);      // compilation error: bitfield of group ClearBufferMask expected, got GLenum

In the case of bitfields, the OpenGL API offers groups and each parameter states the group valid values must come from. glbinding uses this information to prevent invalid bit combinations:

glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); // valid
glClear(GL_COLOR_BUFFER_BIT | GL_MAP_READ_BIT);     // compile error: both bitfields share no group

glClear(GL_STENCIL_BUFFER_BIT | GL_LIGHTING_BIT);   // compile error: bitwise or operation is valid,
                                                    // the shared group is AttribMask, but the
                                                    // resulting group does not match the expected.

Unfortunately, such groups are incomplete and unmaintained for enums (named values). Thus, glbinding could not provide any assistance for cases such as:

GLuint vertexShader = glCreateShader(GL_VERTEX_SHADER); // All good
GLuint colorShader = glCreateShader(GL_COLOR);          // No compilation error but a runtime error!

Compilation-Centered Header Design

C++ strictly separates interface from implementation. For improving the compilation time of a program or system written in C++ forward declarations of types are commonly used and includes of unnecessary symbols are omitted.

For an interface of a library, class, or module providing OpenGL related functionality, it is likely that only the type information of OpenGL is needed, not actual functions or constants usually required for implementation. In addition to the customary all-in-one header gl.h glbinding also provides specialized headers:

#include <glbinding/gl/gl.h>        // all of the headers below, meaning the complete OpenGL API

#include <glbinding/gl/bitfield.h>  // bitfield constants (e.g., GL_COLOR_BUFFER_BIT)
#include <glbinding/gl/boolean.h>   // boolean constants (GL_TRUE and GL_FALSE)
#include <glbinding/gl/enum.h>      // symbol constants (e.g., GL_VERTEX_SHADER)
#include <glbinding/gl/functions.h> // functions
#include <glbinding/gl/types.h>     // type declarations of the OpenGL API (including bitfields, boolean, enum, and extensions)
#include <glbinding/gl/values.h>    // special values (e.g., GL_INVALID_INDEX)

There is one additional header that provides all extensions and provide them as an enumeration in terms of C++ enums.

#include <glbinding/gl/extension.h>

Feature-Centered Header Design

The OpenGL API is iteratively developed and released in versions, internally (for the API specification) named features. The latest feature/version of OpenGL is 4.6. The previous version are 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 2.0, 2.1, 3.0, 3.1, 3.2, 3.3, 4.0, 4.1, 4.2, 4.3, 4.4., and 4.5. OpenGL uses a deprecation model for removing outdated parts of its API which results in compatibility (with deprecated API) and core (without deprecated API) usage that is manifested in the targeted OpenGL context. On top of that, new API concepts are suggested as extensions (often vendor specific) that might be integrated into future versions. All this results in many possible specific manifestations of the OpenGL API you can use in your program.

One tough task is to adhere to one agreed set of functions in your own OpenGL program (e.g., OpenGL 3.2 Core if you want to develop for every Windows, macOS, and Linux released in the last 4 years). glbinding facilitates this by providing per-feature headers by means of well-defined/generated subsets of the OpenGL API.

All-Features OpenGL Headers

If you do not use per-feature headers the OpenGL program can look like this:

#include <glbinding/gl/gl.h>

// draw code
gl::glClear(gl::GL_COLOR_BUFFER_BIT | gl::GL_DEPTH_BUFFER_BIT);
gl::glUniform1i(u_numcubes, m_numcubes);
gl::glDrawElementsInstanced(gl::GL_TRIANGLES, 18, gl::GL_UNSIGNED_BYTE, 0, m_numcubes * m_numcubes);

Single-Feature OpenGL Headers

When developing your code on Windows with latest drivers installed, the code above is likely to compile and run. But if you want to port it to systems with less mature driver support (e.g., macOS or Linux using open source drivers), you may wonder if glDrawElementsInstanced is available. In this case, just switch to per-feature headers of glbinding and choose the OpenGL 3.2 Core headers (as you know that at least this version is available on all target platforms):

#include <glbinding/gl32core/gl.h>

// draw code
gl32core::glClear(gl32core::GL_COLOR_BUFFER_BIT | gl32core::GL_DEPTH_BUFFER_BIT);
gl32core::glUniform1i(u_numcubes, m_numcubes);
gl32core::glDrawElementsInstanced(gl32core::GL_TRIANGLES, 18, gl32core::GL_UNSIGNED_BYTE, 0, m_numcubes * m_numcubes);

If the code compiles you can be sure it is OpenGL 3.2 Core compliant. Using functions that are not yet available or relying on deprecated functionality is prevented.

Lazy Function Pointer Resolution

By default, glbinding tries to resolve all OpenGL function pointers during initialization, which can consume some time:

// Assume context creation using GLFW
glbinding::initialize(glfwGetProcAddress); // immediate function pointer resolution

Alternatively, the user can decide that functions pointers are resolved only when used for the first time. This is achieved by:

// Assume context creation using GLFW
glbinding::initialize(glfwGetProcAddress, false); // lazy function pointer resolution

Multi-Context Support

glbinding has built-in support for multiple contexts. The only requirement is, that the currently active context has to be specified. This feature mixes well with multi-threaded applications, but keep in mind that concurrent use of one context often results in non-meaningful communication with the OpenGL driver.

In order to use multiple contexts, use your favorite context creation library (e.g., glut, SDL, egl, glfw, Qt) to request the required contexts. The functions to make a context current should be provided by these libraries and is not part of glbinding (except that you can get the current context handle). When using multiple contexts, glbinding has to be initialized for each context (when current).

Since each context can correspond to a different feature set of OpenGL and the drivers are free to assign their function pointers, glbinding cannot assume any equalities of requested function pointers. Thus, contexts switches have to be communicated to glbinding explicitly in order to have correctly dispatched function pointers:

// use the current active context
glbinding::useCurrentContext();

// use another context, identified by platform-specific handle
glbinding::useContext(ContextHandle context);

Multi-Threading Support

Concurrent use of glbinding is mainly intended for usage over multiple contexts in different threads (multiple threads operating on a single OpenGL context requires locking, which glbinding will not provide). For it, glbinding supports multiple active contexts, one per thread. This necessitates that glbinding gets informed in each thread which context is currently active (see multi-context example).

Note: multi-threaded communication with OpenGL will most likely result in a meaningless sequence of OpenGL calls. To avoid this, semantic groups of OpenGL calls should be treated as critical sections.

Example for usage of multiple contexts:

// Context 1 creation
// GLFWwindow * window1 = glfwCreateWindow(640, 480, "", nullptr, nullptr);
// glfwMakeContextCurrent(window1);
glbinding::initialize(0, glfwGetProcAddress); // 0 here is the context identifier
// Context 1 initialization
glClearColor(1.0f, 0.0f, 0.0f, 0.0f);

// Context 2 creation
// GLFWwindow * window2 = glfwCreateWindow(640, 480, "", nullptr, nullptr);
// glfwMakeContextCurrent(window2);
glbinding::initialize(1, glfwGetProcAddress); // 1 here is the context identifier
// Context 1 initialization
glClearColor(0.0f, 1.0f, 0.0f, 0.0f);

// Rendering
while (doNotClose()) {
  // Make context 1 active
  // glfwMakeContextCurrent(window1);
  glbinding::useContext(0);

  // Context 1 rendering
  glViewport(0, 0, width, height);
  glClear(GL_COLOR_BUFFER_BIT);

  // Swap buffer for context 1
  // glfwSwapBuffers(window1);

  // Make context 2 active
  // glfwMakeContextCurrent(window2);
  glbinding::useContext(1);

  // Context 2 rendering
  glViewport(0, 0, width, height);
  glClear(GL_COLOR_BUFFER_BIT);

  // Swap buffer for context 2
  // glfwSwapBuffers(window2);
}

Multiple OpenGL Contexts in Multiple Threads

The combination of multiple OpenGL contexts and multiple threads for OpenGL usage is supported by glbinding in general. You must tell glbinding which OpenGL context is used in which thread by calling the initialize method once the context is used first (glbinding::initialize) and if you want to switch the current context for one thread, you have to update the current context, too (glbinding::useContext). However, we discourage the use of one context in multiple threads.

Function Callbacks

To support orthogonal features of the OpenGL API, glbinding allows attaching a number of callbacks to several concepts of the OpenGL API (e.g. a function). Such orthogonal features include runtime error checking (i.e., glGetError after each function call), logging, and caching of driver information.

glbinding supports different types of callbacks that can be registered. The main types are

  • global and local (per-function) before callbacks, that are called before the OpenGL function call,
  • global and local (per-function) after callbacks, that are called after the OpenGL function call,
  • unresolved callbacks, that are called each time an unresolved OpenGL function should be called (instead of a segmentation fault),
  • context switch callbacks, that are called if the internal current OpenGL context of glbinding is changed.

The before callbacks are useful , e.g., for tracing or application-specific parameter checking. The available information in this callback is the wrapped OpenGL function (including its name and bound function address) and all parameters. The after callbacks are useful, e.g., for tracing, logging, or the obligatory error check (glGetError). Available information is extended by the return value. The unresolved callback provides information about the (unresolved) wrapped OpenGL function object.

Example for error checking:

setCallbackMaskExcept(CallbackMask::After, { "glGetError" });
setAfterCallback([](const FunctionCall &)
{
  const auto error = glGetError();
  if (error != GL_NO_ERROR)
    std::cout << "error: " << std::hex << error << std::endl;
});

// OpenGL Code ...

As a shortcut, glbinding 3.0 introduced a debugging interface for error-checking after callbacks within the glbinding-aux library:

#include <glbinding-aux/debug.h>

glbinding::aux::enableGetErrorCallback();

// OpenGL Code ...

Example for logging:

setCallbackMask(CallbackMask::After | CallbackMask::ParametersAndReturnValue);
setAfterCallback([](const FunctionCall & call)
{
  std::cout << call.function->name() << "(";
  for (unsigned i = 0; i < call.parameters.size(); ++i)
  {
    std::cout << call.parameters[i].get();
    if (i < call.parameters.size() - 1)
      std::cout << ", ";
  }
  std::cout << ")";

  if (call.returnValue)
    std::cout << " -> " << call.returnValue.get();

  std::cout << std::endl;
});

// OpenGL Code ...

Alternative Signatures

The OpenGL API is designed without function overloading using only simple parameter types. This results in explicit parameter encoding in function names for conceptually overloaded functions (e.g., glTexParameteri and glTexParameterf). Another design decision for the OpenGL API is the high similarity of the integer, boolean, enum, and bitfield data types. This means, that for overloaded functions, there is no separate function for GLboolean, GLenum, and GLbitfield types. Using type-save functions of glbinding, some typically compiling code constructs are now deliberately broken. For most of those cases, we provide alternative overloaded function signatures. Additionally, we also fix signatures that are semantically broken in the OpenGL API specification, i.e., when base types (C types) are similar such as in the case of enums and integers.

Alternative function signatures are enabled by default, so the following example works out-of-the-box:

#include <glbinding/gl/gl.h>

using namespace gl;

// ...
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexImage2D(GL_TEXTURE_2D, 0, GL_R8, 64, 64, 0, GL_RED, GL_UNSIGNED_BYTE, terrain.data());

Meta Information

Besides an actual OpenGL binding, glbinding also supports queries for both compile time and runtime information about the gl.xml and your OpenGL driver within the glbinding-aux library. This library comes with own includes and needs to be linked separately. Typical use cases are querying the available OpenGL extensions or the associated extensions to an OpenGL feature and their functions and enums.

The following example prints out a list of all available OpenGL versions/features:

#include <iostream>

#include <glbinding/Version.h>

#include <glbinding-aux/Meta.h>
#include <glbinding-aux/types_to_string.h>

// ...
using namespace glbinding;

for (const Version & v : aux::Meta::versions())
  std::cout << v << std::endl;

glbinding's People

Contributors

0xb8 avatar adsun701 avatar arsenic-atg avatar automaticp avatar billyoneal avatar cgcostume avatar cy20lin avatar dgimb89 avatar dommueller avatar dutow avatar ghisvail avatar jon-edward avatar jpgygax68 avatar julkw avatar karjonas avatar lw0 avatar mjendruk avatar morwenn avatar murashin avatar naios avatar pfultz2 avatar rlux avatar ryanshow avatar ryp avatar scheibel avatar somae avatar stephantlavavej avatar tachi107 avatar v1993 avatar zangetsu38 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

glbinding's Issues

Calling convention run-time check failure

The following program encounters a run-time failure:

#include <SFML\Window.hpp>
#include <glbinding\gl\gl.h>
#include <glbinding\Binding.h>

using namespace gl;

int main(int argc, const char* argv[])
{
    sf::Window window(sf::VideoMode(640, 480), "GLBinding Test");

    glbinding::Binding::initialize();
    glClearColor(0.0f, 0.5f, 0.8f, 1.0f);
   // truncated
}

With the error message:

Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention.

Which occurs on line 71 of Function.hpp and the call stack for the error originates from the glClearColor call:

template <typename... Arguments>
struct FunctionHelper<void, Arguments...>
{
    void call(const glbinding::Function<void, Arguments...> * function, Arguments&&... arguments) const
    {
        // truncated
        if (function->isEnabled(glbinding::CallbackMask::After))      // line 71
            function->after(functionCall);
    }
};

The toolchain used to build the library:

  • VS 2013 Version 12.0.30723.00 Update 3
  • CMake 3.0.2

The same tools were used to build SFML and GLEW which have no issues with the same program.

Can not build using clang on Linux

When trying to build on a Ubuntu Travis-CI worker with clang-3.5, I get many error messages like this:

In file included from /home/travis/build/xythobuz/OpenRaider/glbinding/source/glbinding/source/Binding.cpp:2:
In file included from /home/travis/build/xythobuz/OpenRaider/glbinding/source/glbinding/include/glbinding/Binding.h:9:
/home/travis/build/xythobuz/OpenRaider/glbinding/source/glbinding/include/glbinding/gl/types.h:102:1: error: 
      'hash' defined as a struct template here but previously declared as a
      class template [-Werror,-Wmismatched-tags]
struct hash<gl::GLenum>
^
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/stl_bvector.h:523:31: note: 
      did you mean struct here?
    template<typename> friend class hash;

I have removed the -Werror compiler flag in cmake/PlatformLinuxGCC.cmake as a work-around. That allows me to build the library.

Value.cpp wrapString() segfaults on nullptr

The implementation of wrapString() does not expect a nullptr value. This can cause the program to crash.

I've noticed this problem when attaching an After callback and calling glGetString() with an invalid enum. Trying to print the return value (which is nullptr in this case) will cause a segfault. The problem could easily be fixed by replacing:

ss << value;

by

ss << ((value == nullptr) ? "nullptr" : value);

Restructure per-feature include header locations

Currently, per-feature include headers are structured this way:

glbinding/gl/functions.h
glbinding/gl/functions10.h
// ...
glbinding/gl/functions32.h
glbinding/gl/functions32core.h
glbinding/gl/functions32ext.h
// ...

I suggest using this structure for glbinding 2.0:

glbinding/gl/functions.h
glbinding/gl10/functions.h
// ...
glbinding/gl32/functions.h
glbinding/gl32core/functions.h
glbinding/gl32ext/functions.h
// ...

Building Static Library Error

The following error occurs when trying to build as a static library.

CMake Error at source/glbinding/CMakeLists.txt:162 (install):
  install TARGETS given no ARCHIVE DESTINATION for static library target
  "glbinding".

Per-feature types include

Currently, per-feature type declarations only exist in the functions....h header, which seems rather large just to get a few type declarations.

Ambiguous call to overloaded function when using per-feature includes

The following snippet produces error C2668: 'gl45core::glGetUniformSubroutineuiv' : ambiguous call to overloaded function

#include <glbinding/gl/functions.h>  // < imagine this was included by a 3rd party library (e.g. globjects.hpp)

#include <glbinding/gl/functions45core.h>
#include <glbinding/gl/enum45core.h>

using namespace gl45core;

int main(int argn, char** argv) {
    GLuint index = 0;
    glGetUniformSubroutineuiv(GL_VERTEX_SHADER, 0, &index);
}

Full log:

1>c:\users\jole\documents\visual studio 2013\projects\glbindingambiguity\glbindingambiguity\main.cpp(10): error C2668: 'gl45core::glGetUniformSubroutineuiv' : ambiguous call to overloaded function
1>          d:\projects\glbinding\source\glbinding\include\glbinding\gl\functions45core.h(311): could be 'void gl45core::glGetUniformSubroutineuiv(gl45core::GLenum,gl45core::GLint,gl45core::GLuint *)'
1>          d:\projects\glbinding\source\glbinding\include\glbinding\gl\functions.h(1017): or       'void gl::glGetUniformSubroutineuiv(gl::GLenum,gl::GLint,gl::GLuint *)' [found using argument-dependent lookup]
1>          while trying to match the argument list '(const gl::GLenum, int, gl45core::GLuint *)'

If the first line is removed, the program compiles as expected. The problem is caused by argument dependent lookup and the fact that enums constants in the gl45core namespace use a type from the gl namespace. In order to fix this, per-feature declarations should be fully independent from the gl namespace.

Discuss about handling symbol names

A lot of other libraries define macros which clash with the opengl symbols.
Currently we add underscores to avoid that.

Is there a better way?

Get a homebrew recipe in place

It should not take more than brew install glbinding on Mac OS to get started.

Homebrew (http://brew.sh/) has become the de-facto standard of installing libraries and unix tools on Mac OS. glbinding adoption is definitively slowed down on Mac OS through not providing a brew recipe in the mainline of homebrew.

Build error with GCC after version 1.0.4

I'm compiling glbinding with TDM GCC 4.9.2 64 bit in Windows 7.

With glbinding 1.0.4 I never had problems, while with 1.0.5 the compiler gives me "unrecognized command line options" error.

Removing this instruction @ line 137 in "source/glbinding/CMakeLists.txt" from glbinding 1.0.5 sources:

target_compile_options(${target} PRIVATE ${DEFAULT_COMPILE_FLAGS})

resolved the problem. This line was not present in glbinding 1.0.4.

Thank you for your attention and best regards

glbinding cannot be used as a submodule

glbinding cannot currently be used as a submodule. This is because glbinding expects the .git directory to be in it's root source directory, which is not the case when it is cloned as a submodule. When cloned as a submodule however there will be a .git file in it's root source directory with something like gitdir: ../../.git/modules/ThirdParty/glbinding pointing to it's .git directory and it should be able to use this.

global namespace pollution

In files glbinding/include/glbinding/Function.h and other unnamed namespaces are used, so all classes declared insde are in fact global, because it's header file included from gl*.h.
I think such helper classes shouldn't pollute global namespace.
I just had compilation error because of this issue.

Including <glbinding/gl/gl.h> slows down compilation massively

You probably know about this - is there really nothing that can be done about it? I just cut down the compilation time of a small project from just about 3 minutes to 55 seconds by replacing a dozen or so gl.h with the actually needed types.h, enum.h, bitfield.h, functions.h... The thing is just, this is a lot of manual work.
I'd rather like to be able to just include gl.h and be able to use GL without killing my build times. Can we maybe outsource some non-GL functionality from gl.h to external headers? Maybe employ defines to disable features we don't need?

(I haven't bothered to figure out what's actually going on in gl.h, just pointing this out in general)

Strongly-typed enums conflicts with regular gl use

Consider this example:

GLuint buffer;
GLuint buffer2;
GLsizei size;
void* ptr;
GLbitfield flags = GL_MAP_WRITE_BIT | GL_MAP_PERSISTENT_BIT | GL_MAP_COHERENT_BIT; // Not compiling

glNamedBufferStorage(buffer, size, ptr, flags);
glNamedBufferStorage(buffer2, size, ptr, flags);

This isn't allowed by glbinding as far as as I know, due to the lack of conversion of the Mask* types to GLbitfield. But this kind of uses are often encountered in OpenGL code. This problem also arise when wrapping glbinding functions into objects.

// OpenGL reference
void glNamedBufferStorage(GLuint buffer, GLsizei size, const void *data, GLbitfield flags);
// glbinding
void glNamedBufferStorage(GLuint buffer, GLsizei size, const void * data, MapBufferUsageMask flags)

Current master fails to compile on Visual Studio 2013

There are several problems:

  • warning C4244: 'argument' : conversion from 'unsigned __int64' to 'glbinding::RingBuffer<glbinding::logging::BufferType>::SizeType', possible loss of data (RingBuffer uses SizeType (=unsigned int) in its external interface, but std::int64_t internally)
  • RingBuffer.hpp(93): warning C4127: conditional expression is constant
  • RingBuffer.hpp(133): warning C4389: '!=' : signed/unsigned mismatch
  • callbacks.cpp(32): error C2797: 'glbinding::FunctionCall::parameters': list initialization inside member initializer list or non-static data member initializer is not implemented
  • RingBuffer.h(49): error C2039: 'mutex' : is not a member of 'std' (missing include)
  • error LNK2019: unresolved external symbol "__declspec(dllimport) void __cdecl glbinding::logging::log(bool)" (__imp_?log@logging@glbinding@@YAX_N@Z) referenced in function "void __cdecl compare(void)" (?compare@@YAXXZ) (and two more)

Warnings must be fixed as well, as they are treated as errors.

Most should be easily fixable, but was there a reason for the first issue?

Specs Wishlist

A list of ToDos and issues for the XML-based OpenGL spec:

  • every Parameter or Return value of type GLbitfield should be replaced by appropriate bitfield group
  • every Parameter or Return value of type GLenum should be replaced by appropriate enum group
  • more to come ...

Shared library on Mac OS X has wrong install name

I have built and installed glbinding on Mac OS X 10.10.2 with XCode 6.2 and all the default options. However, the install name of the installed library seems wrong:

$ otool -D /usr/local/lib/libglbinding.dylib
/usr/local/lib/libglbinding.dylib:
libglbinding.dylib

The full path should be listed instead of only the filename. The expected output would be:

$ otool -D /usr/local/lib/libglbinding.dylib
/usr/local/lib/libglbinding.dylib:
/usr/local/lib/libglbinding.dylib

As a work-around, one can run this command to fix the install name:

$ sudo install_name_tool -id /usr/local/lib/libglbinding.dylib /usr/local/lib/libglbinding.dylib

But with the proper cmake settings, this should not be necessary.

Probably related is the following warning from cmake:

CMake Warning (dev):
  Policy CMP0042 is not set: MACOSX_RPATH is enabled by default.  Run "cmake
  --help-policy CMP0042" for policy details.  Use the cmake_policy command to
  set the policy and suppress this warning.

  MACOSX_RPATH is not specified for the following targets:

   glbinding

GL_FALSE unexpected behaviour

Hi,
I recently tried to extract the shader compilation log with the usual approach:

GLint status;
glGetShaderiv(vertexShader, GL_COMPILE_STATUS, &status);
 if (status == GL_FALSE) {
...
}

But this doesn't compile because of different types (GLint and const gl::GLboolean). From my pov that is not what I expect. Of course I can use !status, but this behaviour breaks the compatibilty, isnt't it?

Change error checking example in README to not loop callbacks

I tried to use error checking after-callbacks as shown in the main README, but using a glGetError() call in the callback caused it to loop back into the callback. Being new the library, I had no idea why my program became completely unresponsive. After some reading, I found using Binding::GetError.directCall() was the correct way to go.

Maybe the example should be changed so other people don't run into the same issue? Or is this possibly a bug?

Conflicting "None" in glbinding/callbacks.h with X11/X.h

/usr/include/glbinding/callbacks.h:30:5: error: expected identifier before numeric constant
enum class CallbackMask : unsigned char
{
None = 0x00,
...
};

None was declared in X11/X.h as:

ifndef None

define None 0L /* universal null resource or null atom */

endif

Maybe this will work:

if defined X_H

undef None

endif

enum class CallbackMask : unsigned char
{
None = 0x00,
Unresolved = 0x01,
Before = 0x02,
After = 0x04,
Parameters = 0x08,
ReturnValue = 0x10,
ParametersAndReturnValue = Parameters | ReturnValue,
BeforeAndAfter = Before | After
};

if defined X_H

define None 0L /* universal null resource or null atom */

endif

The problem I got

When I run the examples "meta" (glbinding make with GL_BY_STRINGS) the program crashed at Meta_BitfieldsByString.cpp line 13. And I tested when write block of code like that with my own, my program also crashed(may be vs12 not support this kind of code).
And when I run the example "callbacks" I got problem at Function.hpp line 30 with a error message "Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call". (enum class value can not as an interger?).
(I run this program in windows 7 and build it with visual studio 2013)

Virtual Contexts

Provide virtual contexts on top of real OpenGL contexts so that one real context can be used with multiple glbinding configurations including

  • global callbacks
  • per function callbacks
  • logging

That also enables applications and depending libraries to use multiple configurations per context, too.

Derived informations from the actual OpenGL context can be shared (e.g. function pointers).

GL_POINTS (and others) not in Meta_StringsByEnum

This is because of

d = sorted([ es[0] for v, es in groupEnumsByValue(pureEnums).items() ])

in gen_meta.py:68

The obvious fix would be to include all elements of es into the array list instead of just the first but this seems a bit too obvious to me, so I'll just raise this as an issue as there probably was an intend behind just inserting index 0.

Duplicated 'revision' file

Hi,
I just built glbinding with:

mkdir build-release
cd build-release
cmake .. # I used ccmake, but it doesn't matter now
make
make pack

I tried to install generated packages with

sudo dpkg -i glbinding-1.0.5-dev.deb glbinding-1.0.5-runtime.deb 

but dpkg complains that there's conflict because glbinding-runtime.deb tries to overwrite file /usr/share/glbinding/revision which belongs to glbinding-dev.deb

Edit: It can be fixed with --force-overwrite option added to dpkg invocation, but I think it's not the way.

LoadLibrary on win32 didn't accept wchar_t*

gcc gives error:

../source/glbinding/source/ProcAddress.cpp: In function 'void (* glbinding::getProcAddress(const char_))()':
../source/glbinding/source/ProcAddress.cpp:27:60: error: cannot convert 'const wchar_t_' to 'LPCSTR {aka const char_}' for argument '1' to 'HINSTANCE___ LoadLibraryA(LPCSTR)'
static HMODULE module = LoadLibrary(L"OPENGL32.DLL");

I'm not sure if this is related to gcc (I use gcc-4.9.1 Rev3 x86-64 from MSYS2)
remove the L prefix fix it

Convert classes with no members

glbinding contains several classes without members, so why not transforming it to a namespace?

Currently found classes:

  • Binding
  • Meta
  • ContextInfo

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.