> On Mar 30, 2017, at 9:40 AM, Kelvin Ma wrote:
>
> There are hundreds of gl functions… I have to rewrite the signatures for all
> of them??
Does GLFW expose any underlying loader mechanism or cached function pointer
variables underneath the macros it defines? Possibly you could access those
I’m also guessing I have to disable the default function loader GLFW
provides? What do I do about GL defined types such as GLenuum and GLint?
On Thu, Mar 30, 2017 at 11:40 AM, Kelvin Ma
wrote:
> There are hundreds of gl functions… I have to rewrite the signatures for
> all of them??
>
> On Thu,
There are hundreds of gl functions… I have to rewrite the signatures for
all of them??
On Thu, Mar 30, 2017 at 11:31 AM, Joe Groff wrote:
>
> > On Mar 30, 2017, at 7:47 AM, Kelvin Ma via swift-users <
> swift-users@swift.org> wrote:
> >
> > OpenGL functions are loaded at runtime by a function lo
> On Mar 30, 2017, at 7:47 AM, Kelvin Ma via swift-users
> wrote:
>
> OpenGL functions are loaded at runtime by a function loader (like GLFW).
> They’re defined in a header but obviously they don’t have definitions at
> compile time so it causes a slew of linker errors when I try to build
>
Hi Kelvin,
Do you mind sharing the code you’re using? I’m looking back at some code I
wrote a while back to learn OpenGL and I see that the implementation was pretty
straightforward.
The OpenGL.GL module already provides the implementations for runtime functions
such as glEnable, glBlendFunc a
OpenGL functions are loaded at runtime by a function loader (like GLFW).
They’re defined in a header but obviously they don’t have definitions at
compile time so it causes a slew of linker errors when I try to build
error: undefined reference to 'glEnable'
error: undefined reference to 'gl
