Epoxy is a library for handling OpenGL function pointer management for you

Ubuntu macOS MSVC Build MSYS2 Build License: MIT

Epoxy is a library for handling OpenGL function pointer management for you.

It hides the complexity of dlopen(), dlsym(), glXGetProcAddress(), eglGetProcAddress(), etc. from the app developer, with very little knowledge needed on their part. They get to read GL specs and write code using undecorated function names like glCompileShader().

Don't forget to check for your extensions or versions being present before you use them, just like before! We'll tell you what you forgot to check for instead of just segfaulting, though.

Features

  • Automatically initializes as new GL functions are used.
  • GL 4.6 core and compatibility context support.
  • GLES 1/2/3 context support.
  • Knows about function aliases so (e.g.) glBufferData() can be used with GL_ARB_vertex_buffer_object implementations, along with GL 1.5+ implementations.
  • EGL, GLX, and WGL support.
  • Can be mixed with non-epoxy GL usage.

Building

mkdir _build && cd _build
meson
ninja
sudo ninja install

Dependencies for Debian:

  • meson
  • libegl1-mesa-dev

Dependencies for macOS (using MacPorts):

  • pkgconfig
  • meson

The test suite has additional dependencies depending on the platform. (X11, EGL, a running X Server).

Switching your code to using epoxy

It should be as easy as replacing:

#include <GL/gl.h>
#include <GL/glx.h>
#include <GL/glext.h>

with:

#include <epoxy/gl.h>
#include <epoxy/glx.h>

As long as epoxy's headers appear first, you should be ready to go. Additionally, some new helpers become available, so you don't have to write them:

int epoxy_gl_version() returns the GL version:

  • 12 for GL 1.2
  • 20 for GL 2.0
  • 44 for GL 4.4

bool epoxy_has_gl_extension() returns whether a GL extension is available (GL_ARB_texture_buffer_object, for example).

Note that this is not terribly fast, so keep it out of your hot paths, ok?

Why not use libGLEW?

GLEW has several issues:

  • Doesn't know about aliases of functions (There are 5 providers of glPointParameterfv(), for example, and you don't want to have to choose which one to call when they're all the same).
  • Doesn't support OpenGL ES.
  • Has a hard-to-maintain parser of extension specification text instead of using the old .spec file or the new .xml.
  • Has significant startup time overhead when glewInit() autodetects the world.
  • User-visible multithreading support choice for win32.

The motivation for this project came out of previous use of libGLEW in piglit. Other GL dispatch code generation projects had similar failures. Ideally, piglit wants to be able to build a single binary for a test that can run on whatever context or window system it chooses, not based on link time choices.

We had to solve some of GLEW's problems for piglit and solving them meant replacing every single piece of GLEW, so we built piglit-dispatch from scratch. And since we wanted to reuse it in other GL-related projects, this is the result.

Known issues when running on Windows

The automatic per-context symbol resolution for win32 requires that epoxy knows when wglMakeCurrent() is called, because wglGetProcAddress() returns values depend on the context's device and pixel format. If wglMakeCurrent() is called from outside of epoxy (in a way that might change the device or pixel format), then epoxy needs to be notified of the change using the epoxy_handle_external_wglMakeCurrent() function.

The win32 wglMakeCurrent() variants are slower than they should be, because they should be caching the resolved dispatch tables instead of resetting an entire thread-local dispatch table every time.

Comments
  • Upgrading libepoxy from 1.5.5 to 1.5.7 results in Xorg crashing on boot

    Upgrading libepoxy from 1.5.5 to 1.5.7 results in Xorg crashing on boot

    Hello,

    Basic info:

    • OS: Manjaro Linux KDE
    • Kernel: 5.11.18-1-MANJARO
    • GPU: Radeon R9 380 with AMDGPU drivers

    I encountered this issue after an recent Manjaro update which amongst other things updated the libepoxy version from 1.5.5 to 1.5.7 which (as I later found) was the package causing my Xorg to crash on boot. Using the git bisect I managed to find the problematic commit, which is: dbfa4b2

    This is the Xorg log after it crashed:

    [  5840.928] (WW) Failed to open protocol names file lib/xorg/protocol.txt
    [  5840.929] 
    X.Org X Server 1.20.11
    ... a lot more stuff (I can post if needed)
    [  5841.290] (II) Initializing extension XFree86-DRI
    [  5841.290] (II) Initializing extension DRI2
    [  5841.291] (II) AMDGPU(0): Setting screen physical size to 1377 x 285
    [  5841.311] (EE) 
    [  5841.311] (EE) Backtrace:
    [  5841.311] (EE) 0: /usr/lib/Xorg (xorg_backtrace+0x53) [0x55f225222fd3]
    [  5841.311] (EE) 1: /usr/lib/Xorg (0x55f2250dc000+0x151df5) [0x55f22522ddf5]
    [  5841.311] (EE) 2: /usr/lib/libc.so.6 (0x7f2164329000+0x3cf80) [0x7f2164365f80]
    [  5841.311] (EE) 3: /usr/lib/libc.so.6 (gsignal+0x145) [0x7f2164365ef5]
    [  5841.311] (EE) 4: /usr/lib/libc.so.6 (abort+0x116) [0x7f216434f862]
    [  5841.311] (EE) 5: /usr/lib/libc.so.6 (0x7f2164329000+0x26747) [0x7f216434f747]
    [  5841.311] (EE) 6: /usr/lib/libc.so.6 (0x7f2164329000+0x35646) [0x7f216435e646]
    [  5841.311] (EE) 7: /usr/lib/xorg/modules/drivers/amdgpu_drv.so (0x7f216485f000+0x8fd3) [0x7f2164867fd3]
    [  5841.311] (EE) 8: /usr/lib/xorg/modules/drivers/amdgpu_drv.so (0x7f216485f000+0x933a) [0x7f216486833a]
    [  5841.311] (EE) 9: /usr/lib/xorg/modules/drivers/amdgpu_drv.so (0x7f216485f000+0x1534d) [0x7f216487434d]
    [  5841.311] (EE) 10: /usr/lib/xorg/modules/drivers/amdgpu_drv.so (0x7f216485f000+0x1746a) [0x7f216487646a]
    [  5841.311] (EE) 11: /usr/lib/xorg/modules/drivers/amdgpu_drv.so (0x7f216485f000+0x19127) [0x7f2164878127]
    [  5841.311] (EE) 12: /usr/lib/Xorg (MapWindow+0x251) [0x55f22517f871]
    [  5841.311] (EE) 13: /usr/lib/Xorg (0x55f2250dc000+0x39619) [0x55f225115619]
    [  5841.311] (EE) 14: /usr/lib/libc.so.6 (__libc_start_main+0xd5) [0x7f2164350b25]
    [  5841.311] (EE) 15: /usr/lib/Xorg (_start+0x2e) [0x55f2251165de]
    [  5841.311] (EE) 
    [  5841.311] (EE) 
    Fatal server error:
    [  5841.311] (EE) Caught signal 6 (Aborted). Server aborting
    [  5841.311] (EE) 
    [  5841.311] (EE) 
    Please consult the The X.Org Foundation support 
             at http://wiki.x.org
     for help. 
    [  5841.311] (EE) Please also check the log file at "/home/my_username/.local/share/xorg/Xorg.1.log" for additional information.
    [  5841.311] (EE) 
    [  5841.327] (EE) Server terminated with error (1). Closing log file.
    

    Link to the Manjaro forum discussing the issue: https://forum.manjaro.org/t/upgrading-libepoxy-from-1-5-5-to-1-5-7-results-in-xorg-crashing-on-boot/66195

  • meson: add library versioning?

    meson: add library versioning?

    Hi,

    I maintain the libepoxy formula in Homebrew. After yesterday's release I decided to give the new meson build system a try, but noticed that the produced dylib is not versioned. This is a bit of a problem, as it breaks our gtk+3 binaries, and all packages that depend on it.

    The configure script based install produces:

    /usr/local/Cellar/libepoxy/1.4.1/lib/libepoxy.0.dylib
    /usr/local/Cellar/libepoxy/1.4.1/lib/libepoxy.dylib
    

    with libepoxy.dylib being a symlink to libepoxy.0.dylib

    and with the meson installation:

    /usr/local/Cellar/libepoxy/1.4.1/lib/libepoxy.dylib
    

    Since the meson docs mention support for versioned libraries, I wondered if it would be useful to use this feature? To me it makes sense that both installation types produce the exact same files.

    Best,

    Tom

  • libepoxy crash with AMDGPU-PRO

    libepoxy crash with AMDGPU-PRO

    Hello, I cherry-picked commit 8d58c890646fc1f43bcab702bb9ed6bae94daefe and this caused unbootability of some old proprietary AMD drivers

    Can you please enlighten me? Seems that 1.3.1 with that commit is a no-go, but I'm not sure how this can be solved, and if the revert is doable for you

  • Allow libopengl.so to be used when GLX_LIB is missing

    Allow libopengl.so to be used when GLX_LIB is missing

    This maintains compatibility with previous behavior of always using GLX_LIB if it is found. The only change is when there is no GLX_LIB.

    Previous behavior when no GLX_LIB:

    • abort.

    New behavior when no GLX_LIB:

    • Try to load libOpenGL.so as gl_handle (glx_handle remains NULL).
    • Else, abort.
  • 1.5.0 breaks KWin

    1.5.0 breaks KWin

    Updating libepoxy from 1.4.3 to 1.5.0 breaks KWin compositing. OGL 2 nor OGL 3.1 does work. More info can be found here: https://bugs.kde.org/show_bug.cgi?id=391486 and https://bbs.archlinux.org/viewtopic.php?id=235021.

    Is this a regression or intentional change? It has been suggested to report upstream, which is here.

  • Appveyor - Windows autobuilds

    Appveyor - Windows autobuilds

    I created an appveyor yml file for autobuilding libepoxy on Windows and uploading the install artifacts (include, lib, bin) as a zip file to the GitHub releases. Currently the script turns EGL support off. The appveyor yml file would have to be edited to upload to the main repo's GitHub page rather than mine (simply replace 'auth_token', with an encoded GitHub API token for appveyor.

  • Fix some bugs in loading OpenGL/GLX/EGL libraries

    Fix some bugs in loading OpenGL/GLX/EGL libraries

    Without additional check, even if libOpenGL was loaded, libGL.so will be loaded as well, and used both in gl_handle and glx_handle, so libglvnd libraries will not be used.

    The problem is that on Wayland-only system, there will be no libGL, so epoxy_load_gl will fail even if libOpenGL was loaded.

  • "Couldn't find current GLX or EGL context.\n" exits GNOME Games

    When running a game in GNOME Games in some ancient machine, the application quits with this message on stderr: "Couldn't find current GLX or EGL context.". The machine still has a powerful enough GPU (i915 driver) to run gnome-shell and power totem's clutter-gtk video display.

    The error message was found in epoxy_get_proc_address().

    I would like Games (which uses GtkGLArea) to be able to recover from this error by using a software rendering method, which implies for libepoxy to transmit its errors.

  • Meson build - Windows

    Meson build - Windows

    Hello. I am having an issue building with Meson on Windows.

    First, when I install Python 3.6 for windows, the executable is python.exe (not python3.exe). When I run meson.py .. . --backend=vs2015 I get an error saying Program python3 found: NO.

    I created a symlink from python.exe to python3.exe. This resolved that issue and successfully creates a MSVC solution. However, when building, it has several errors along the lines of:

    "C:/Python36/python3.EXE" "python" "C:/projects/libepoxy/src/gen_dispatch.py" <...>
    C:/Python36/python3.EXE: can't open file 'python': [Errno 2] No such file or directory
    

    It appears as though the gen_dispatch.py is set to be called from python twice, which is what causes the error.

  • macOS epoxy_has_gl_extension() only working with legacy OpenGL

    macOS epoxy_has_gl_extension() only working with legacy OpenGL

    I've been playing with trying to understand why VICE Gtk3 performs so bad on macOS vs linux and Windows.

    I discovered that VICE works great if Gdk doesn't ask for OpenGL 3.2 or 4.1, and gets the legacy renderer instead. Host CPU performance goes from about 75% to 45%.

    When running with gl 2.1, epoxy_has_gl_extension() reports support for GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle and GL_EXT_framebuffer_blit. When running with gl 3.2 or 4.1, epoxy_has_gl_extension() does not detect support for these extensions.

    I found that if I force the detection result for these extensions in Gdk, VICE performance is also great with the 3.2 and 4.1 renderers. So I assume there must be something wrong with epoxy_has_gl_extension() in this case. In fact, I just have to force detection of GL_EXT_framebuffer_blit to get the result i'm looking for

    I intend to try to understand and fix this, but I thought i'd open an issue to track it.

  • Fix build if EGL/X11 headers are in a custom prefix

    Fix build if EGL/X11 headers are in a custom prefix

    Currently the build works on most systems since these headers are usually installed in the same directory as other dependencies or in the default include directory. However, on some platforms the X11/GL headers are installed to a different prefix, and then the build fails due to missing includes.

  • not compiling under musl

    not compiling under musl

    [16/23] cc -Isubprojects/libepoxy-1.5.9/src/libepoxy.so.0.0.0.p -Isubprojects/libepoxy-1.5.9/src -I../../home/mangix/devstuff/wrapdb/subprojects/libepoxy-1.5
    ninja: job failed: cc -Isubprojects/libepoxy-1.5.9/src/libepoxy.so.0.0.0.p -Isubprojects/libepoxy-1.5.9/src -I../../home/mangix/devstuff/wrapdb/subprojects/lIn file included from ^[[01m^[[K../../home/mangix/devstuff/wrapdb/subprojects/libepoxy-1.5.9/src/dispatch_common.h:46^[[m^[[K,                                                from ^[[01m^[[Ksubprojects/libepoxy-1.5.9/src/egl_generated_dispatch.c:11^[[m^[[K:
    ^[[01m^[[K../../home/mangix/devstuff/wrapdb/subprojects/libepoxy-1.5.9/include/epoxy/glx.h:36:10:^[[m^[[K ^[[01;31m^[[Kfatal error: ^[[m^[[KX11/Xlib.h: No su   36 | #include ^[[01;31m^[[K<X11/Xlib.h>^[[m^[[K                                                                                                                 |          ^[[01;31m^[[K^~~~~~~~~~~~^[[m^[[K
    compilation terminated.
    ninja: job failed: cc -Isubprojects/libepoxy-1.5.9/src/libepoxy.so.0.0.0.p -Isubprojects/libepoxy-1.5.9/src -I../../home/mangix/devstuff/wrapdb/subprojects/lIn file included from ^[[01m^[[K../../home/mangix/devstuff/wrapdb/subprojects/libepoxy-1.5.9/src/dispatch_common.h:46^[[m^[[K,                                                from ^[[01m^[[Ksubprojects/libepoxy-1.5.9/src/glx_generated_dispatch.c:26^[[m^[[K:
    ^[[01m^[[K../../home/mangix/devstuff/wrapdb/subprojects/libepoxy-1.5.9/include/epoxy/glx.h:36:10:^[[m^[[K ^[[01;31m^[[Kfatal error: ^[[m^[[KX11/Xlib.h: No su   36 | #include ^[[01;31m^[[K<X11/Xlib.h>^[[m^[[K                                                                                                                 |          ^[[01;31m^[[K^~~~~~~~~~~~^[[m^[[K
    compilation terminated.
    ninja: job failed: cc -Isubprojects/libepoxy-1.5.9/src/libepoxy.so.0.0.0.p -Isubprojects/libepoxy-1.5.9/src -I../../home/mangix/devstuff/wrapdb/subprojects/lIn file included from ^[[01m^[[K../../home/mangix/devstuff/wrapdb/subprojects/libepoxy-1.5.9/src/dispatch_common.h:46^[[m^[[K,                                                from ^[[01m^[[K../../home/mangix/devstuff/wrapdb/subprojects/libepoxy-1.5.9/src/dispatch_glx.c:28^[[m^[[K:
    ^[[01m^[[K../../home/mangix/devstuff/wrapdb/subprojects/libepoxy-1.5.9/include/epoxy/glx.h:36:10:^[[m^[[K ^[[01;31m^[[Kfatal error: ^[[m^[[KX11/Xlib.h: No su   36 | #include ^[[01;31m^[[K<X11/Xlib.h>^[[m^[[K                                                                                                                 |          ^[[01;31m^[[K^~~~~~~~~~~~^[[m^[[K
    compilation terminated.
    ninja: job failed: cc -Isubprojects/libepoxy-1.5.9/src/libepoxy.so.0.0.0.p -Isubprojects/libepoxy-1.5.9/src -I../../home/mangix/devstuff/wrapdb/subprojects/lIn file included from ^[[01m^[[K../../home/mangix/devstuff/wrapdb/subprojects/libepoxy-1.5.9/src/dispatch_common.h:46^[[m^[[K,                                                from ^[[01m^[[K../../home/mangix/devstuff/wrapdb/subprojects/libepoxy-1.5.9/src/dispatch_egl.c:28^[[m^[[K:
    ^[[01m^[[K../../home/mangix/devstuff/wrapdb/subprojects/libepoxy-1.5.9/include/epoxy/glx.h:36:10:^[[m^[[K ^[[01;31m^[[Kfatal error: ^[[m^[[KX11/Xlib.h: No su   36 | #include ^[[01;31m^[[K<X11/Xlib.h>^[[m^[[K                                                                                                                 |          ^[[01;31m^[[K^~~~~~~~~~~~^[[m^[[K
    compilation terminated.
    ninja: job failed: cc -Isubprojects/libepoxy-1.5.9/src/libepoxy.so.0.0.0.p -Isubprojects/libepoxy-1.5.9/src -I../../home/mangix/devstuff/wrapdb/subprojects/lIn file included from ^[[01m^[[K../../home/mangix/devstuff/wrapdb/subprojects/libepoxy-1.5.9/src/dispatch_common.h:46^[[m^[[K,                                                from ^[[01m^[[K../../home/mangix/devstuff/wrapdb/subprojects/libepoxy-1.5.9/src/dispatch_common.c:174^[[m^[[K:
    ^[[01m^[[K../../home/mangix/devstuff/wrapdb/subprojects/libepoxy-1.5.9/include/epoxy/glx.h:36:10:^[[m^[[K ^[[01;31m^[[Kfatal error: ^[[m^[[KX11/Xlib.h: No su   36 | #include ^[[01;31m^[[K<X11/Xlib.h>^[[m^[[K                                                                                                                 |          ^[[01;31m^[[K^~~~~~~~~~~~^[[m^[[K
    compilation terminated.
    ninja: subcommands failed
    

    missing X11 dependency. The build should not have gotten this far.

  • Add a public GetProcAddress returning pointers to libepoxy wrapper functions

    Add a public GetProcAddress returning pointers to libepoxy wrapper functions

    Some libraries, such as libmpv's render API, need a GetProcAddress function in order to be initialized. However, when the GL context in question was initialized by a platform using libepoxy, for example a GTK 4 GLArea, the relevant GetProcAddress can be any one of them, with the only recourse at the moment being for the application to select glXGetProcAddress or eglGetProcAddress on its own.

    In order for code written against cross-platform libraries such as these to stay cross-platform, I believe libepoxy should provide its own epoxified GetProcAddress for situations such as this. Unfortunately, epoxy_get_proc_address is already taken, but I'm sure someone can think of a good name for a public function of this nature.

  • Khronos registries need bump

    Khronos registries need bump

    It seems that the registries haven't been updated since 2019, which is a shame because I wanted to make use of EGL_EXT_PLATFORM_xcb from 2020. There's nothing stopping me from adding #defines myself, but it would be much appreciated if the registries could be bumped to latest.

  • gl_version 0 - compat profile

    gl_version 0 - compat profile

    I am using virtio-gpu on NVIDIA T4

    when start VM by qemu cmdline: ##epoxy_internal_gl_version version=4.6.0 NVIDIA 510.47.03 ## version_string=7938 ##epoxy_internal_gl_version version=4.5.0 NVIDIA 510.47.03 ## version_string=7938 gl_version 45 - core profile enabled

    when start VM by libvirtd: ##epoxy_internal_gl_version version=2.1 Mesa 18.3.4 ## version_string=7938 ##epoxy_internal_gl_version version=(null) ## version_string=7938 gl_version 0 - compat profile

    who can tell me why ? thank ...

Related tags
A Tiny 2D OpenGL based C++ Game Engine that is fast, lightweight and comes with a level editor.
A Tiny 2D OpenGL based C++ Game Engine that is fast, lightweight and comes with a level editor.

A Tiny 2D OpenGL based C++ Game Engine that is fast, lightweight and comes with a level editor.

Apr 12, 2022
A simple 2d snake game made using opengl in c++
A simple 2d snake game made using opengl in c++

opengl-snakegame A simple 2d snake game made using opengl in c++ Demo Keyboard Controls P - To resume/start or pause the game R - To restart the game

Dec 8, 2021
A minecraft clone built in c++ opengl for the purpose of prefecting graphics programming skills.

LearnOpenGL - CLion This is a project template for OpenGL development with JetBrains CLion IDE. It was created mainly for LearnOpenGL tutorials. Inclu

Dec 28, 2021
FPS Game built from scratch using C++ and Legacy OpenGL.
FPS Game built from scratch using C++ and Legacy OpenGL.

A small game made by a couple of students as a university project. Built from scratch using C++ and Legacy OpenGL, hence the name.

May 23, 2022
Game Engine that is being developed by a computer science student using C and OpenGL

Project LOGLE Contents About the Project Project Status Known Issues Setup ?? About Game Engine that is being developed by a computer science student

Jan 21, 2022
An OpenGL 4.3 / C++ 11 rendering engine oriented towards animation
An OpenGL 4.3 / C++ 11 rendering engine oriented towards animation

aer-engine About An OpenGL 4.3 / C++ 11 rendering engine oriented towards animation. Features: Custom animation model format, SKMA, with a Blender exp

Jul 25, 2021
GlslViewer is a flexible console-base OpenGL Sandbox to display 2D/3D GLSL shaders without the need of an UI
GlslViewer is a flexible console-base OpenGL Sandbox to display 2D/3D GLSL shaders without the need of an UI

GlslViewer is a flexible console-base OpenGL Sandbox to display 2D/3D GLSL shaders without the need of an UI

Jun 22, 2022
A foobar2000 component which allows you to load and play ncm files directly.
A foobar2000 component which allows you to load and play ncm files directly.

Play NCM files directly with our favourite How to setup and build project Download foobar2000 SDK and extract into vendor/sdk Download WTL from source

Jun 7, 2022
A faster drop-in replacement for giflib. It uses more RAM, but you get more speed.

GIFLIB-Turbo What is it? A faster drop-in replacement for GIFLIB Why did you write it? Starting in the late 80's, I was fascinated with computer graph

Jun 9, 2022
SampPy is a plugin for SA:MP that allows you to create gamemodes from Python
SampPy is a plugin for SA:MP that allows you to create gamemodes from Python

SampPy is a plugin for SA:MP that allows you to create gamemodes from Python. A fork of PySAMP, which has been abandoned for quite some time.

Jul 31, 2021
Guess a random number between your selected range within the chances you select to win the game!

Number-Guessing-Game Guess a random number between your selected range within the chances you select to win the game! This project was developed by Sa

May 13, 2022
In this repository you'll find the fully reversed source code for GTA III (master branch) and GTA VC (miami branch).
In this repository you'll find the fully reversed source code for GTA III (master branch) and GTA VC (miami branch).

Intro In this repository you'll find the fully reversed source code for GTA III (master branch) and GTA VC (miami branch). It has been tested and work

Nov 11, 2021
A Game Boy game that rewards you for playing it on several console models!
A Game Boy game that rewards you for playing it on several console models!

GB Corp. A Game Boy game for the Game Boy Competition 2021 by Dr. Ludos (2021) This is the source code, you can get a precompiled rom from here: https

Oct 21, 2021
A fun game where you don't press the red ball!

DarkBall DarkBall is a fun to play game where you can press little balls/button, but never press the red ball(or any of its friends) You can find/play

Jan 14, 2022
Do you have what it takes? - 2-bit Dungeon Escape game implemented on the Arduino Platform
Do you have what it takes? - 2-bit Dungeon Escape game implemented on the Arduino Platform

This game was created as part of the Introduction to Robotics course I took during my 3rd year of studying Computer Science @ University of Bucharest,

Feb 28, 2022
Unreal Engine 4 vulnerability, that allows you to run shellcode directly into the target game process.

Unreal Engine 4 vulnerability, that allows you to run shellcode directly into the target game process, to load any DLL undetected from most game anti cheats, such as Easy Anti Cheat, BattleEye, Ricochet, Vanguard, ATG, and more.

Jun 15, 2022
The wordle game, but when you want to use sudo!
The wordle game, but when you want to use sudo!

pam_wordle OS arch Build Status Ubuntu 20.04 x86_64 They say "practice makes perfect", and that is perhaps true. So, let's practice more on the game,

May 26, 2022
This project is a small 2D game with minilibx. You'll learn about textures, sprites and tiles.
This project is a small 2D game with minilibx. You'll learn about textures, sprites and tiles.

(੭。╹▿╹。)੭ so_long This project is a small 2D game with minilibx. You'll learn about textures, sprites and tiles. Preview How play the game To play thi

May 9, 2022
This tool allow you to create / load / edit models used for create a cinematic in game for World of Warcraft 3.3.5 version
This tool allow you to create / load / edit models used for create a cinematic in game for World of Warcraft 3.3.5 version

CameraCinematic - Discord Introduction This tool allow you to create / load / edit models used for create a cinematic in game for World of Warcraft 3.

Mar 14, 2022