I stand corrected.

On Wed, Apr 2, 2014 at 9:50 AM, Simon Danisch <[email protected]> wrote:

> Ah, the links are all the same...
> Output for Mikes solution:
> native: *https://gist.github.com/SimonDanisch/6270c01a6ea881877c4f
> <https://gist.github.com/SimonDanisch/6270c01a6ea881877c4f>*
> llvm:   https://gist.github.com/SimonDanisch/612e8b08d915d188c4d5
>
>
>
>
> 2014-04-02 15:46 GMT+02:00 Simon Danisch <[email protected]>:
>
> @ Mike
>> Good question. Well, I definitely would wish for a simpler solutions.
>> But as far as I understand the situation, every video card vendor makes
>> his own OpenGL implementation.
>> Also, even on one computer, you can have more than one rendering context.
>> This means, the correct function pointers can be just queried, after one
>> creates a particular context.
>>
>>
>> So I looked into the machine and llvm code and its pretty clear!
>> The version inspired by Mike generates a lot shorter llvm and machine
>> code.
>> It also doesn't matter if I call glGetString before inspecting the
>> machine code.
>>
>> My test program for Isaiah's solution:
>>
>> #glTest.jl
>>
>>
>>
>>
>> using GLUT, OpenGL
>>
>> glutInit()
>>
>>
>>
>>
>> glutInitDisplayMode(GLUT_DEPTH | GLUT_DOUBLE | GLUT_RGBA | GLUT_MULTISAMPLE 
>> | GLUT_ALPHA)
>>
>>
>>
>>
>> glutInitWindowPosition(0, 0)
>> glutInitWindowSize(1,1)
>>
>>
>>
>>
>>
>> window = glutCreateWindow("dummy")
>>
>>
>>
>>
>>
>> println(code_llvm(glGetString, (Uint16,)))
>>
>>
>>
>>
>>
>> println(bytestring(convert(Ptr{Uint8}, glGetString(0x1F02))))
>>
>>
>>
>>
>>
>> println(code_llvm(glGetString, (Uint16,)))
>>
>>
>>
>>
>>
>> #OpenGL.jl
>> module OpenGL
>>
>> function getFuncPointer(name)
>>
>>
>>
>>
>>     ccall( (:glXGetProcAddress, "libGL"), Ptr{Void}, (Ptr{Cchar},), name)
>>
>>
>>
>>
>> end
>> glGetString(name::Uint16) = ccall(getFuncPointer("glGetString"), Ptr{Cchar}, 
>> (Uint16,), name)
>>
>>
>>
>>
>>
>> export glGetString
>> end
>>
>>
>> Output:
>> https://gist.github.com/SimonDanisch/777bfc7783f9e96818f4
>>
>> Output for Mikes solution:
>> native: https://gist.github.com/SimonDanisch/777bfc7783f9e96818f4
>> llvm:    https://gist.github.com/SimonDanisch/777bfc7783f9e96818f4
>>
>>
>> Am I missing something?
>>
>>
>> Am Dienstag, 1. April 2014 14:30:12 UTC+2 schrieb Simon Danisch:
>>>
>>>  Hi,
>>> I'm working on the OpenGL package and I want to make it finally usable
>>> in a nice and clean way on all platforms.
>>> The problem is, that one needs pointer for the GL functions, which you
>>> can only get, after initialization of the OpenGL context.
>>> But initializing the context and creating a window shouldn't be part of
>>> the OpenGL package.
>>>
>>> So I tried two different approaches, which both seem to have their
>>> downsides:
>>>
>>> 1.
>>> Initialize OpenGL context when including the OpenGL package
>>> This is bad, because this makes the OpenGL package dependent on some
>>> third party OpenGL context creation library.
>>>
>>> 2.
>>> Load the functions later with a loading Function.
>>> Bad, because the function definitions are not visible for any other
>>> module, that relies on the OpenGL package.
>>>
>>> My ideal solution would be, to evaluate a macro when the function is
>>> called and not when the module is included.
>>> Like this, I can define all the OpenGL functions already in the OpenGL
>>> module, and when you call them the first time,
>>> the right function ptr gets inserted into the ccall, or an error is
>>> raised, when OpenGL context is not initialized.
>>>
>>> this could look like this:
>>>
>>>
>>> module OpenGL
>>>
>>> macro getFuncPointer(name::ASCIIString)
>>>    return getProcAddress(name)
>>> end
>>>
>>> glGetString(name::GLenum) = ccall(@getFuncPointer("glGetString"), ...., 
>>> ...., name)
>>> export glGetString
>>> end
>>>
>>>
>>> using OpenGL
>>> ...create OpenGL context
>>> #define getProcAddress
>>> global const getProcAddress = glutGetProcAddress # If using GLUT for GL 
>>> context creation
>>> #call gl Functions
>>> glGetString(GL_VERSION)
>>>
>>> Any ideas how to do this in a clean way?
>>>
>>>
>>> Cheers,
>>>
>>> Simon
>>>
>>
>

Reply via email to