I have stuff like


public static class fGL
{
	nothrow @nogc extern(System)
	{
		alias CullFace = void function(tGL.Enum);
		alias FrontFace = void function(tGL.Enum);
		alias HInt = void function(tGL.Enum, tGL.Enum);
		alias LineWidth = void function(tGL.Float);
		alias PoIntSize = void function(tGL.Float);
                ...
        }
}


public static struct tGL
{
	alias Void = void;
	alias IntPtr = ptrdiff_t;
	alias SizeInt = int;
	alias Char = char;
	alias CharARB = byte;
	alias uShort = ushort;
	alias Int64EXT = long;
	alias Short = short;
	alias uInt64 = ulong;
	alias HalfARB = ushort;
        alias BlendFunc = void function(tGL.Enum, tGL.Enum);
        ...

        __gshared {
	    CopyTexImage1D glCopyTexImage1D;
            TextureParameterf glTextureParameterf;
            VertexAttribI3ui glVertexAttribI3ui;
            VertexArrayElementBuffer glVertexArrayElementBuffer;
            BlendFunc glBlendFunc;
            ...
}


public struct eGL
{
	enum ubyte FALSE = 0;
	enum ubyte TRUE = 1;
	enum uint NO_ERROR = 0;
	enum uint NONE = 0;
	enum uint ZERO = 0;
	enum uint ONE = 1;
        ...
}


And when I use this stuff(which is clearly openGL being cleaned up a bit(I know I can use modules to essentially do this too but that is irrelevant):

I get errors like


Error: null has no effect in expression (null)	

Error: more than one argument for construction of extern (Windows) void function(uint, uint) nothrow @nogc	


This is when using it like

fGL.BlendFunc(eGL.SRC_ALPHA, eGL.ONE_MINUS_SRC_ALPHA);

What's going on? Please no responses about "You are going to run into a lot of problems since all the openGL code uses the flat accessing"... The whole point is to get away from that ancient way and backwards way.

On 6/14/16 11:29 AM, Joerg Joergonson wrote:
> I have stuff like
>
>
> public static class fGL
> {
>     nothrow @nogc extern(System)
>     {
>         alias CullFace = void function(tGL.Enum);
>         alias FrontFace = void function(tGL.Enum);
>         alias HInt = void function(tGL.Enum, tGL.Enum);
>         alias LineWidth = void function(tGL.Float);
>         alias PoIntSize = void function(tGL.Float);
>                 ...

Your aliases are a bunch of function pointer types. This isn't what you likely want.

I'm assuming you want to bring the existing functions into more categorized namespaces? What you need is to do this:

public static struct fGL
{
   alias CullFace = .CullFace; // or whatever the fully qualified name is.

I don't have much experience with the opengl modules, so I can't be more specific.

-Steve

On Tuesday, 14 June 2016 at 16:08:03 UTC, Steven Schveighoffer wrote:
> On 6/14/16 11:29 AM, Joerg Joergonson wrote:
>>                 [...]
>
> Your aliases are a bunch of function pointer types. This isn't what you likely want.
>
> I'm assuming you want to bring the existing functions into more categorized namespaces? What you need is to do this:
>
> public static struct fGL
> {
>    alias CullFace = .CullFace; // or whatever the fully qualified name is.
>
> I don't have much experience with the opengl modules, so I can't be more specific.
>
> -Steve

This is how derelict does it, I simply moved them in to the class for simplicity.

> This is how derelict does it, I simply moved them in to the class for simplicity.

I mean glad: http://glad.dav1d.de/

On Tuesday, 14 June 2016 at 17:34:42 UTC, Joerg Joergonson wrote:
>> This is how derelict does it, I simply moved them in to the class for simplicity.
>
> I mean glad: http://glad.dav1d.de/

It seems that a loader is required for some reason and that possibly could be one or both of the problems.

On 6/14/16 1:37 PM, Joerg Joergonson wrote:
> On Tuesday, 14 June 2016 at 17:34:42 UTC, Joerg Joergonson wrote:
>>> This is how derelict does it, I simply moved them in to the class for
>>> simplicity.
>>
>> I mean glad: http://glad.dav1d.de/
>
> It seems that a loader is required for some reason and that possibly
> could be one or both of the problems.
>

I don't know what glad is doing. What I do know is that if you have an alias like this:

alias CullFace = void function(tGL.Enum);

This is type alias, saying variables of type CullFace will be pointers to functions that return void, and take tGL.Enum type.

If you attempt to "call" a type, then I don't think it works, you need a variable of that type to call it. I think this is why you see such strange errors.

It's possible a loader will fill in the details. I don't know.

-Steve

On Tuesday, 14 June 2016 at 17:37:40 UTC, Joerg Joergonson wrote:
> On Tuesday, 14 June 2016 at 17:34:42 UTC, Joerg Joergonson wrote:
>>> This is how derelict does it, I simply moved them in to the class for simplicity.
>>
>> I mean glad: http://glad.dav1d.de/
>
> It seems that a loader is required for some reason and that possibly could be one or both of the problems.

You absolutely need a loader to load most opengl functions. They are not usually exposed in the shared object, as gl function pointers are tied to a specific opengl context.

You are trying to call function pointer types, which is invalid. You need to declare some variable with the type, load the function pointer into the variable (platform specific; there are plenty of tutorials on how to do this in C), and call that variable.


(Also I disagree that separating the opengl API based on what the symbol is is a step up from the "ancient and backwards flat access" way. Functions are, by neccessity, coupled to the types and enums they take. A better categorization would be based on version introduced or extension, iirc jogl does that)

On Tuesday, 14 June 2016 at 17:37:40 UTC, Joerg Joergonson wrote:
> On Tuesday, 14 June 2016 at 17:34:42 UTC, Joerg Joergonson wrote:
>>> This is how derelict does it, I simply moved them in to the class for simplicity.
>>
>> I mean glad: http://glad.dav1d.de/
>
> It seems that a loader is required for some reason and that possibly could be one or both of the problems.

Yes, Derelict and glad both work this way. A loader is required because you are using function pointers, which means you need the memory addresses of the functions in the library, which are only known at runtime when the library is loaded into memory. There's no way around it. You are doing manually what the system loader does when you declare a normal function and link with an import library (on Windows) or directly with a dynamic library (on Posix systems).

You should be declaring your functions something like this:

// Most functions in C libraries should be extern(C), but OpenGL needs to
// be extern(Windows) on Windows and extern(C) everywhere else. extern(System)
// handles that for you. Making them nothrow and @nogc is very handy for D
// code that needs those attributes.
extern(System) @nogc nothrow {
    alias aClear = void function(int);
}

struct GL {
   aClear clear;
}

void loadFuncs(ref GL gl) {
    // This is system specific. You can see the possibilities in
    // the module derelict.opengl3.gl3
    version(Windows) ennum libName = "OpenGL32.dll"

    // loadSharedLibrary should wrap OS-specific LoadLibrary/dlopen
    auto lib = loadSharedLibrary(libName);

    // loadFunc should wrap OS-specific GetProcAdress/dlsysm
    gl.clear = cast(aClear)lib.loadFunc("glClear");
}