Need help finding proper #WCALL prototype

[/ Rav]

I'm using APL+Win version 15.1.01.  I want to access some OpenGL functionality using #WCALL.  Right now I'm trying to get the glReadPixels function to work (see https://docs.microsoft.com/en-us/windows/win32/opengl/glreadpixels).  Here is the C++ syntax:

void WINAPI glReadPixels(
   GLint   x,
   GLint   y,
   GLsizei width,
   GLsizei height,
   GLenum  format,
   GLenum  type,
   GLvoid  *pixels
);

The original prototype as found in gl.h (which I downloaded from https://www.khronos.org/registry/OpenGL/api/GLES/1.0/gl.h) is:

GLAPI void APIENTRY glReadPixels (GLint x, GLint y, GLsizei width, GLsizei height, GLenum format, GLenum type, GLvoid *pixels);

Referring to the table of typedef's in gl.h, I converted the GL datatypes into the standard APL #WCALL datatypes.  So in the [Call] section of my APLW.INI file, I added this entry:

glReadPixels=(I x, I y, I width, I height, U format, U type, *C pixels) LIB Opengl32

In APL, I execute (displayed using ]apl2ascii):

     pPix {<-} #WCALL 'GlobalAlloc' 'GMEM_FIXED' 1000000

     #WCALL 'glReadPixels' 100 100 200 200 0x1907 0x1404 pPix

     @ 100=x coordinate, 100=y coordinate, 200=width, 200=height,

     @ 0x1907 is GL_RGB, 0x1404 is GL_INT, pPix is pointer to pixel array.

     #WCALL 'GetLastError'

126

     pix {<-} #WCALL 'W_Mem' (pPix 323 250000)

Unfortunately, GetLastError shows error 126 occurred, which is "The specified module could not be found."  And of course <pix> remains all 0's.

I don't understand why this should be.  Opengl32.dll exists in c:\windows\system32 as well as c:\windows\syswow64.  So I assume there's something wrong with how I've entered the function prototype.  Or there's something fundamental that I don't understand about OpenGL.

Does anyone have any ideas?  Thanks.

[Davin Church]

I don't know much about OpenGL, but I've done a little []WCALL work. I don't see anything in particular wrong with your definition at first glance, but I don't know what the real definitions of those GL-datatypes are (I haven't looked into it) ... perhaps there's a mismatch there?

Another thing you might check is the LIB naming. Sometimes I've found that it likes to see a path and/or extension on it for no apparent reason.

And I doubt this is the case but some Windows DLLs actually have ALIASes that need to be used, but I didn't see any when pulling up a list of names.

Just in case you'd like me to send it to you, I have a small function to handle GlobalAlloc/W_Mem operations a little more readably.

[/ Rav]

Thanks, Davin.  I tried a number of things and never did get it to work.  More than that, though, I found that there was a whole bunch of other stuff I would need to do BEFORE the call to glReadPixels (or any other OpenGL function).  Something about creating a "Rendering Context (RC)," which requires calling wglCreateContext, which first requires setting the pixel format of the device context of the window I'm working with, and THAT requires running Windows function SetPixelFormat, and SetPixelFormat requires a god-awful structure called a PIXELFORMATDESCRIPTOR, etc.  I decided to abandon that approach entirely and just use BitBlt, which although possibly slower, works (it may not actually BE slower, given all the gory stuff that would need to be executed with the openGL method).  Sorry for not updating this thread earlier with that resolution.  At any rate, I appreciate your input.  / Rav

[Davin Church]

You're welcome. I'm sorry I didn't see this sooner.

Whenever I'm working with a new group of functions like this, I like to start with the simplest one I can find first (fewest and simplest arguments) just to make sure I can talk to the package. Then I gradually ramp up the complexities as I need them.

I'm glad you got BitBlt working - it should be pretty fast.