<v0idify>
or, well, zig-opengl are autogenerated bindings and zgl are homemade bindings :P
<v0idify>
zig-opengl != zgl, i'm comparing zig libraries here :P
<noam>
because OpenGL sucks? /s
<v0idify>
hmm, i remember i ended up choosing zig-opengl for some reason. is there a reason i shouldn't be using zgl?
2021-04-30
<klltkr>
Yeah, I was basically experimenting with a "pure" (you can't get that pure, i.e. static binary, because you will always end up needing OpenGL)
2021-03-24
<forgot-password>
Is it possible to get call site information at comptime? I have some custom wrapper to automatically check for OpenGL errors and it would be awesome if it could automatically point to where the error was generated
2021-03-18
<yyp>
I'm not an OpenGL expert and have no idea how to use that, sorry
<v0idify>
zig-opengl doesn't use epoxy
<yyp>
You should definietly .linkSystemLibrary("opengl") in build.zig
<v0idify>
how do i call load in zig-opengl? I don't understand the parameters
<v0idify>
if i generate a file with zig-opengl it can be just saved in the repo instead of zig-opengl no?
<ikskuh>
i will port over zgl to use zig-opengl at some point in the future
<ikskuh>
you won't be able to call any opengl function :D
<ikskuh>
so it's nothing that *adds* any layer, it's just required to use modern opengl
<ikskuh>
glew, gl3w, libepoxy, zig-opengl
<ikskuh>
newer opengl (>= 3) will not expose it's api in libGL
<ikskuh>
it loads opengl
<v0idify>
i'm new to opengl
<ifreund>
yeah that's right, though I have seen some zig opengl bindings floating around
<ifreund>
I've been meaning to port emersion's hello-wayland opengl example but haven't had time
2021-03-17
<v0idify>
opengl backends that share rendering functions but not initalizations that are os dependant
<karchnu>
talking about projects, I want to do a QML-like UI system based on zig and *probably* opengl, that's a kinda big application
2020-11-21
<andrewrk>
my system runs opengl and vulkan but there is no loader installed
<dominikh>
then people probably don't use that system to run opengl or vulkan :P
<dominikh>
as for how the loader actually finds /run/opengl-driver/, the relevant nix packages patch RUNPATH (both for opengl and for vulkan)
<andrewrk>
shakesoda, either way, the strategy does find opengl, because it gives us the path to the directory that has all the files from libglvnd
<dominikh>
note that for X11, many window managers will have absolutely no need for OpenGL or Vulkan
2020-11-03
<maxrazer>
I see OpenGL, but higher level I imagine.
2020-10-14
<ryuukk_>
waleee-cl: no, i just want reuse the glad lib for opengl
2020-10-13
<TheLemonMan>
negotiating an opengl version is harder than it should :\
2020-09-17
<andrewrk>
opengl hello world triangle (or vulkan, whatever)
<andrewrk>
marler8997, if you do a proof of concept that does an opengl triangle window and provide a static linux binary that works on Ubuntu, Alpine, and NixOS, that would be big news
2020-09-14
<ikskuh>
and a opengl loop
<ifreund>
see the various branchs for opengl examples
<klltkr>
ikskuh ifreund: I believe OpenGL without libwayland is possible using dmabufs
<ikskuh>
software rendering and OpenGL would be enough anyways :D
<ifreund>
and then you have the issue that you need to pass the libwayland stucts to mesa if you want to use opengl
2020-09-12
<layneson>
C is so easy to use from Zig that I just pull in GLFW and Epoxy for OpenGL stuff
* ikskuh
is working some Zig stuff with OpenGL again
2020-06-29
<Aransentin>
OpenGL is rather tightly coupled with the X11 C libs
<ifreund>
looks promising, no opengl support planned? that'd probably be the easiest hardware accelerated thing to get going
<Aransentin>
Is there a way of checking whether a variable is used anywhere else in the code? If so, it'd be kinda useful for function-loading libraries (e.g. for OpenGL and Vulkan). If you know that the function "vkDoStuff" is never called you don't have to bother with loading it from the driver.
2020-06-26
<nephele>
also, running wine on WSL2 makes perfect sense... with windows caring less about backwards compatibility (and dx9 -> opengl giving better performance than dx9 comparitively, so that could be used on win potentially)
2020-06-22
<blinghound>
that's a good idea, I've got a lot of opengl code that could do with refactoring anyway
2020-06-20
<blinghound>
I'm getting a ?*c_void back from the openGL call glMapBufferRange
2020-06-19
<blinghound>
I have to allocate space for the string returned from the opengl call glGetShaderInfoLog(GLuint shader, int len, int chars_written, char *log)
2020-06-17
<pixelherodev>
I broke my OpenGL setup :(
2020-06-01
<ikskuh>
so, wayland+opengl→ smooth graphics without tearing *and* kiosk mode
<ikskuh>
i have to check out how to do some OpenGL or Vulkan output without wayland/X11
2020-05-19
<daurnimator>
also how do you define "underlying platform": ntapi? kernel32? user32? everything (which includes e.g. opengl?)
2020-04-28
<mq32>
zigazeljko: OpenGL works cross-compatible, as the layout of libGL/OpenGL32.lib is defined
<zigazeljko>
there are already quite a few zig wrappers (on the internet) for native GUI / OpenGL / etc. libraries
2020-04-27
<shakesoda>
consider also how old opengl 3.3 actually is (over a decade!)
<shakesoda>
all opengl drivers are differently bad
<pixelherodev>
Well, Intel's OpenGL drivers are good
<shakesoda>
besides, native opengl drivers are really cursed, and this is an opportunity to rid myself of the curse
<shakesoda>
opengl over vulkan isn't mature enough anyways
<pixelherodev>
OpenGL over Vulkan will probably be around for as long as Vulkan is
<shakesoda>
i've had moving things to vulkan on my list for a while, since the writing is on the wall for opengl
2020-04-23
<ikskuh>
context for my project: It's an arm-freestanding demo for an embedded platform that uses glm (OpenGL mathematics library) and other header-only c++ stuff
2020-04-17
<shakesoda>
i had this problem with the opengl bindings with rust
2020-04-01
<shakesoda>
oh, you're using opengl? how about not. oh, you distribute outside the app store? haha cute
2020-03-24
<shakesoda>
no, it's a declarative style mid-level rendering library, so you can focus on the graphics techniques you are implementing instead of the dark arts needed to make opengl do the work for you
<mq32>
shakesoda: tinyfx is an OpenGL 4 loader?
2020-02-24
<shakesoda>
oh, sdl2+opengl
<shakesoda>
BaroqueLarouche: opengl?
2020-02-19
<dimenus>
the zig/vulkan version is quite a bit faster than the OpenGL version :)
2020-01-30
<Snektron>
I expect opengl to do a staging buffer kind of thing in the background
2020-01-29
<mq32>
OpenGL doesn't need libc except for dlopen right now :)
<metaleap>
just want to avoid both that dep and deps that dep on it.. yeah if i were doing real-world things i might need opengl or libpng or postgresql or sqlite but for now... i seem to get by interfacing with the outside world via []u8
2020-01-25
<Snektron>
However, these are unlike OpenGL where those function pointers can be loaded in advance
2020-01-19
<pixelherodev>
Maybe just do raw OpenGL?
2020-01-07
<Snektron>
that would also allow the development of OpenGL bindings
2019-12-21
<cshenton>
I'm thinking I should actually just remove that compileError for now, since I use @typeInfo on my vector types for some other stuff (automatically formatting an opengl vertex buffer)
2019-12-13
<Snektron>
Take Vulkan for example, or even OpenGL
2019-12-04
<dimenus>
the scenario i'm thinking here is a graphics frontend that points to either vulkan or opengl
2019-12-03
<mq32>
first style is marching cubes + OpenGL
2019-12-02
<mq32>
OpenGL 4.5 is also a pretty good and *fast* API
<mq32>
but you need a lot more code than OpenGL
<mq32>
pretty much the best thing that happened to modern OpenGL PERIOD
<mq32>
it wraps the OpenGL 4.5 API for direct state access for older versions
<mq32>
*all* tested OpenGL 3.3 compliant cards (and before OpenGL 3.3 it does not make sense) have that extension
<mq32>
also: OpenGL also has inheritance:
<Snektron>
but that introduces the problem that not every device has that extension (even in this day and age), so you severely limit your target audience. Not that i care when i'm making an OpenGL application, but i don't think thats viable as general OpenGL library.
<mq32>
Snektron: yeah this really sucked pre opengl-4.5
<Snektron>
btw, mq32: I always find it hard to build an abstraction over opengl calls. Take for example how you upload data to a buffer (in pre-4.3 opengl): you bind a buffer to a specific register, then you upload data to whatever is bound to that register
<mq32>
i also just had a great idea on the use of mixins for an OpenGL wrapper
2019-12-01
<Snektron>
If you're for a general OpenGL project that doesn't use libepoxy, i have one that uses fairly modern OpenGL
<Snektron>
no i haven't done any opengl development on Zig yet
<Snektron>
This has been my go-to tool for OpenGL development
<Snektron>
gonz_: if you just wana use OpenGL, i recommend the glad headers
<mq32>
gonz_: i have one right now, that runs on linux with OpenGL ES
2019-11-13
<andrewrk>
hm, the video core chip has opengl built into it? that's a surprisingly high level API
<mq32>
i have a small library for OpenGL and similar
2019-10-13
<pixelherodev>
Or openGL, or any other library
2019-10-12
<mq32>
why? OpenGL is a quite straightforward object oriented API :D
<Snektron>
I always find it weird to write wrappers around opengl functions with members
2019-10-11
<mq32>
i'm working on a thin opengl abstraction layer and i'm using tagged enums for this
2019-10-07
<mq32>
only dependency to extern code is SDL2 for creating OpenGL context and the window
2019-10-06
<mq32>
it's OpenGL ES 2.0, all written in Zig except for SDL
2019-10-05
<mq32>
it exports all OpenGL symbols by name (just converted the C headers) and loads a function pointer in background
<mq32>
i now have a zig-only OpenGL ES 2.0 binding
2019-10-04
<mq32>
most stuff in zig, except for opengl loader and SDL
<mq32>
opening a window with sdl, render a rotating 3d triangle with OpenGL ES
2019-10-01
<mq32>
as i wanted to play around with zig and OpenGL, i could hack some simple demo together using such a system
2019-09-05
<mq32>
pure function loader for opengl profiles
<mq32>
i want to create an opengl loader more similar to gl3w than glfw
<mq32>
it tells you: "yes, i was able to load glGetString, but that call returns null because i don't have an OpenGL context"
<mq32>
opengl calls it mix, directx calls it lerp
2019-08-26
<Tetralux>
Also RE OpenGl, it would be fine because you'd be calling the same code you'd use at runtime to use it.
<Tetralux>
The way you load OpenGl might be different across systems for example...
<Tetralux>
But being able to open a window, use OpenGL, shaders, threads, and godknows what else at comptime, LIKE ITS JUST A PROGRAM, is a powerful tool to have in your toolbox.
2019-08-14
<mq32>
and only provide symbols defined for this OpenGL version :)
<mq32>
the cool thing is that i can now give the user the OpenGL version he wants
<mq32>
i use comptime to iterate over the struct fields, refactor the name from "foo" to "glFoo" and load that function from the OpenGL library
<mq32>
btw, zig provides a beautiful way to load OpenGL functions :)
2019-08-12
<mq32>
dimenus: neat. i'm thinking about a two-level OpenGL library for zig. first level would be the pure binding stuff done right (so allowing multiple contexts for different threads and so on) as well as the second layer which does semantic binding of OpenGL objects (so buffer.bind() instead of glBindBuffer(buffer))
<mq32>
i was thinking about porting the OpenGL headers to zig, but it seems better to generate them from the registry directly
2019-08-07
<AlexMax>
i always flip Y-coordinates dealing with opengl
2019-08-06
<mq32>
andrewrk: why i'm bringing up the topic: exactly this topic forces me to edit .NET assemblies by hand to just say: "god damn, use the library with OpenGL backend instead of DirectX. all public members are literally the same, only the *name* of the library differs"
2019-07-28
<mq32>
it's so annoying that OpenGL just has GLuint for object identifiers
<mq32>
also the example of daurnimator in the issue is quite a thing. i'm using OpenGL a lot and want to have the methods of OpenGL objects as methods, not function calls
2019-07-18
<ntgg>
using OpenGL
2019-07-11
<daurnimator>
why ship (e.g.) opengl for windows but not linux?
<daurnimator>
andrewrk: looking at your PR.... why is e.g. GL/gl.h in there? although OpenGL is part of the windows sdk, it's not part of the kernel32 (OpenGL is its own library included in the windows sdk)
2019-07-06
<supereti>
`zig build-exe --c-source -std=c99 /path/to/game/main.c --library c --object /path/to/game/zig-cache/o/zg-nWwYdUXY_etMH0AARbU_eOhLsMHTDn197R32r1jwa_bxYwCw1WQn0MOjtIhB5/libraylib.a --cache-dir /path/to/game/zig-cache --name game -isystem /path/to/game/zig-cache/o/zg-nWwYdUXY_etMH0AARbU_eOhLsMHTDn197R32r1jwa_bxYwCw1WQn0MOjtIhB5 -framework OpenGL -fra
<supereti>
Hi! I'm trying to use `zig build` to do static linking with C project that uses raylib. I want to do the equivalent of `clang -framework CoreVideo -framework IOKit -framework Cocoa -framework GLUT -framework OpenGL libraylib.a game.c -o game` in build.zig file. Here's the build.zig work in progress: https://pastebin.com/rTU6LarJ and here's the er
2019-07-04
<emekankurumeh[m]>
so i was thinking i could have the functions defined as `const fn_name = dlopen(opengl_dll, "fn_name");`
<emekankurumeh[m]>
i'm trying to write a lazy opengl loader (ie functions are only loaded when called)
2019-07-02
<dimenus>
andrewrk: does translate-c expand macros (eg for OpenGL function pointers)
2019-06-24
<scientes>
that uses libwine to provide directX on OpenGL
2019-05-22
<shritesh>
Is OpenCL language independent? I always thought you’d have to pass the kernel source code to the driver like OpenGL shaders?
2019-05-09
<andrewrk>
opengl isn't even a good target anymore, it's deprecated on macos, and vulkan is the future on linux and windows
<daurnimator>
andrewrk: so it's sort of "one layer deeper" than opengl; and makes glfw not required
<daurnimator>
andrewrk: you use EGL to *get* a GL context, that you can use with opengl
2019-05-08
<andrewrk>
the idea is to make a proof of concept GUI application. in opengl or whatever, implement a bunch of widgets. buttons, scroll bars, dockable panes, menus, etc
2019-04-25
<tgschultz>
Looks like I just load extensions manually through if I need them, which I don't usually because I mostly just use OpenGL to put a framebuffer on the screen. I used to use SDL2 though, I don't recall having any significant trouble getting it loaded dynamically.
<wilsonk>
Did you load OpenGL dynamically or use a .lib?
<tgschultz>
that I definitely didn't. COM is all kinds of complicated and I only really used it for getting a window up, making OpenGL work, and getting input events.
2019-04-07
<telemach>
yes, and I in particular don't need event OpenGL's low-level, not talking about Vulkan, I'm resorting to OpenGL because most of frameworks are not friendly to plug-in type embedding
<wrl>
yeah opengl's not great or nothing – vulkan just needs a few years more imo to have a critical mass for hardware
<scientes>
before vulkan it is true opengl is legacy, some developers wanted to support directX11 after the other modernization project of opengl was scrapped
<telemach>
hryx: I knew about pushing, but Metal is not x-platform, why to deprecate opengl when people want to write portable stuff
<andrewrk>
hmm. I just tried adding `-framework OpenGL` and still getting file not found
<telemach>
I found gl.h in ` /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/OpenGL.framework/Headers`, but somehow clang understands this directory when just OpenGL prefix is given
<telemach>
gamester: I'm on master and in build.zig I have standard setup for a dynamic library plus lib.linkFramework("OpenGL")
<telemach>
hello, does anyone know how to #include <OpenGL/gl.h> in Zig on macOS? adding OpenGL framework in build.zig doesn't help (and probably shouldn't as it's about linking i guess)
2019-04-02
<mikdusan>
there’s serveral claims/examples of opengl games on mac ported to MoltenVK getting excellent fps improvements
<mikdusan>
on macos, it’s all metal from apple. opengl is on lifeline stuck at some old version. vulkan has no support from apple but a company open-sourced MoltenVK which is a vulkan wrapper around metal. apparently it works pretty darned good. was sponsered by one of the big game engine companies iirc.
<andrewrk>
I'm not sure how to make that work. OpenGL is deprecated on macOS, so I'm not sure what a real fix would look like, apart from implementing a metal-specific graphics backend
2019-03-15
<Hejsil>
Wasn't there someone who used reflection to load opengl functions or something like that?
2019-02-11
<andrewrk>
for the opengl case, it's actually a case of loading at runtime, which I am researching if we can do without depending on system libc
<shachaf>
I'd rather statically link everything, but for things like OpenGL that's not an option (right?)
2019-01-14
<forgot-password>
Wait, I'm gonna put together a little sample. I want to pass the data to OpenGL
2019-01-05
<forgot-password>
andrewrk: Thanks, first of all. I don't intend to call the c function at compile time, I think this is where my misunderstanding is coming from. It's an OpenGL function, which makes it require a bound context.
<forgot-password>
knebulae: I justed used that as an example, in my actual code it's importing the OpenGL header
2018-11-29
<forgot-password>
I'm still playing around with OpenGL, you? :)
2018-11-28
<forgot-password>
MajorLag, do I need to initialize staticMemory? I updated the gist from earlier (the function of concern is `getShaderInfoLog`) if you want to take a look at it. I'm currently working on a Mac and OpenGL support was deprecated by Apple earlier this year, so I'm not sure whether my problems are caused by that or if they happen due to my code. The latter is obviously much more likely
<forgot-password>
Hey :) I'm currently playing around with OpenGL in zig, but the glShaderSource function is giving me a few problems.
2018-11-13
<mattdavies>
I've yet to attempt to try OpenGL yet
<mattdavies>
I am porting a windows OpenGL application to try to get to grips with it
2018-11-11
<shachaf>
And then when you get to things that you just have to dynamically link, like OpenGL, it more or less pulls in the system libc anyway.
<shachaf>
I guess DNS is less of an issue than things like OpenGL.
<hoppetosse>
I also basically translated glad.h and I'm loading opengl dynamically
2018-08-23
<andrewrk>
it's the same problem with open file descriptors, opengl texture handles, pipes, sockets, etc
2018-08-10
<unique_id>
It might seem surprising, but it actually takes a lot of work to reach OpenGL's GPU (not CPU) performance with Vulkan, simply because you're sort of taking the role of the driver writer. On the CPU side you'll destroy OpenGL, not so on the GPU side.
<unique_id>
I haven't checked out Metal but it is probably what OpenGL Next should have been. Vulkan should be buried in the deepest and darkest corners of huge game engines, and nowhere else.
<unique_id>
You don't have to do this, but if the computer is low on vram then your app will perform worse than on OpenGL if you don't. What's more? Integrated GPUs vs dedicated GPUs. Dedicated GPUs have device_local memory which is a pain to move things to. On Integrated GPUs you'll have to not do that, and not doing things is also work.
2018-08-09
<unique_id>
andrewrk: Do you not want to start with OpenGL and then you or others can port later to vulkan? It seems like vulkan could be an enormous distraction and could also cause streaming problems. Even with validation layers you could have issues with your system becoming unresponsive / it being difficult to shut down your program. Vulkan is also so low level that it might not make sense for 99% of the apps to write directly in vulkan.
2018-08-03
<MajorLag>
wink_: I really like the way LibGDX structured their API. It's all in layers that you're free to choose where you want to interact with it. It's base is straight OpenGL, upon which are Textures => TextureRegions => Sprites => Actors => Widgets => GUI elements => Scene graph.
<MajorLag>
wink_, andrewrk: Yes, that SDL. I've converted most of my projects to straight win32 api calls and OpenGL right now (though just to dump a framebuffer to screen). When I start doing something more serious on the gamedev front I'll probably write my own proper platform layer in pure zig.
2018-08-02
<Dirkson>
Having worked in both opengl and vulkan, I am strongly of the opinion that vulkan is better. Lots more boilerplate, but you can actually get meaningful errors out of it reliably. And tell it stuff like "Use this graphics card, not that one."
<andrewrk>
sounds like I should ditch OpenGL immediately
<unique_id>
andrewrk: glGenBuffers doesn't actually allocate gpu resources, it just "reserves" a name. You'll have to call glBindBuffer for that. GL_OUT_OF_MEMORY can be 'returned' from any command, it's implicit. That's what the spec says. As you can see, OpenGL likes implicitness :)
<unique_id>
My last comment on the stream: I don't know what the heck you're supposed to do on OpenGL. Can you can call glGetError and check for GL_OUT_OF_MEMORY? I don't know. Is the documentation missing this? But your application just deadlocked? I don't know. All I know is that Vulkan is not lacking in this regard, in fact you can take care of CPU-side allocation for the driver via VkAllocationCallbacks.
<Dirkson>
I noticed that bit. I also noticed opengl code going up on the screen
<unique_id>
Vulkan is extra, extra verbose. The Khronos people really want it to run on MacOS and it's looking like the solution will be MoltenVK. I believe it was bought by Valve and open sourced, and Dota 2 runs better on MoltenVK than OpenGL on MacOS
2018-07-12
<unique_id>
andrewrk, afaik the vulkan xml spec has enough information in it to generate complete zig bindings with correct usage of optionals and [*] :) OpenGL I don't know about, its xml does have a 'len' attribute. The xml files are definitely ugly, you need to parse C types, and it might be better to write a non-generic parser that's very hacky looking but you know it works for the current and probably all future specs. This isn't something I
2018-06-21
<very-mediocre>
and WebGL is a derivation of OpenGL ES 2
<very-mediocre>
For targeting mobile many teams stick with OpenGL ES 2
<very-mediocre>
ltr__ for OpenGL there are 2 main "mobile" versions (OpenGL ES 2 and 3) with a big discontinuity of feature sets
<ltr__>
im always lost with opengl versions , supported hardware and capabilities of each one
<alexnask>
I've used windows and opengl headers before really easily, vulkan headers must be doing something pretty weird to not work with @cImport
<ltr__>
yes, i was under the impresion that vulkan was much more lightweight than opengl
<king_button>
because lots of c libraries like opengl and vulkan want to be called through function pointers, at least for best performance (in the case of vulkan anyways).
2018-05-23
<donpdonp>
not sure why. archaic opengl stuff
<donpdonp>
in addition to learning zig's c-interop, im learning that opengl is too low level to put somethingson the screen.
2018-05-12
<MajorLag>
Skilfingr: I think someone mentioned writing a loader for OpenGL functions, but I don't recall who it was.
<alexnask>
For OpenGl, you should just be able to @cImport(@cInclude("gl/gl.h")) and get all GL types + functions
<alexnask>
I have some code that does that but it's windows-only (with a nice OpenGL loader based on metaprogramming too)
<alexnask>
You should be able to call into OpenGL really easily using @cImport()
<bodie_>
that would be fun. I'm looking for cross-platform opengl game stuff
2018-04-23
<andrewrk>
consider that what would previously be your "namespace" in C, you can make an actual namespace in zig. so for example if you're opengl, and all your functions are prefixed with gl, such as glSwapBuffer
2018-04-21
<alexnask>
@MajorLag All the OpenGL functions are missing "opengl32" and stdcallcc in your package
<alexnask>
I think I forgot to release the dummy window (for the OpenGL loading) DC
<alexnask>
(the modern OpenGL context)
<alexnask>
This is so weird, I can get a simple OpenGL window up and going with wglCreateContext but when I use wglCreateContextAttribsARB to get a newer version of OpenGL I get no window
2018-04-20
<MajorLag>
as far as the context thing, what casey does in hmh is create a whole new window and opengl context just for loading extensions, then throw them away when he's done.
<MajorLag>
oh, yeah, win32 kind hates opengl > 1.1. Otherwise I have pretty much the oposite opinion and find Win32 API makes a lot more sense to me than posix.
<alexnask>
Only if nice OpenGL bindings are also available
<andrewrk>
I wonder if a cross platform abstraction for creating a window + opengl context makes sense to be in std
<alexnask>
Just give me the best version of OpenGL you can handle man :P
<alexnask>
The one that triggered me right now is all the juggling to create a rendering context, then load OpenGL functions just to make a modern OpenGL enabled rendering context
<alexnask>
Pretty nice, I just use a struct with function pointers (+ a global instance named gl) and a func that automatically loads all of them from OpenGL
2018-04-19
<alexnask>
I just need a window with an OpenGL context and ESCAPE to work, really :P
<MajorLag>
alexnask_: I actually don't link to C for OpenGL (on windows). I just used translate-c on the headers and link to OpenGL.lib. Obviously also the relevant Win32 wgl code.
<Hejsil>
I think that's how all projects that want opengl does it
<alexnask_>
Anyone knows if there are opengl bindings available? Or should I just cInclude + link it and work that way?
2018-04-16
<alexnask>
And you can only link against default windows libraries (+ opengl or directx)
2018-04-05
<MajorLag>
but can you do this with that?: `var window = sdl.CreateWindow("test", 0, 0, 640, 480, sdl.SDL_WINDOW_FULLSCREEN | sdl.SDL_WINDOW_OPENGL); ?
2018-03-28
<jab>
man "Create an OpenGL library that does not depend on libc."
2018-03-24
<Tobba>
i.e for dealing with shader uniforms with OpenGL or setting up networking tables for a game
2018-03-05
<MajorLag>
strange... my --verbose-link is identical to yours (plus opengl). I invalidated my zig-cache just to be sure there wasn't something stupid going on there, still built fine.
<MajorLag>
that's not much more helpful. Hmm... I wonder what's different? I'm not even linking against anything other than OpenGL that Zig doesn't link behind my back. My build script is just `zig build-exe main.zig --library "./OpenGL32.Lib"`
2018-02-24
<hoppetosse>
opengl
2017-11-17
<dimenus>
i don't know how common this type thing is, but i've seen it a lot in OpenGL