Hi Joshua,

You are raising an issue that I haven't investigated yet deeply enough
to give you any definitive answers. Here's what I can say for sure:
OpenGL extensions have to be looked up dynamically and the lookup
mechanisms are different from your "regular OS lookup". I think that's
because different renderers may expose different extensions and
therefore the extensions are really renderer specific. In order to call
an extension you will have to use wglGetProcAddress (on Windows) which
will answer the address of the function (if it exists) or zero
otherwise. This should look like:

wglGetProcAddress: lpszProc
	<apicall: ulong 'wglGetProcAddress' (char*) module:
'opengl32.dll'>
	^self externalCallFailed

and needs to be used as in

	glx wglGetProcAddress: 'glResetHistogram'.

The problem is that this only tells you the address of the function but
you cannot invoke "an address" - you need a fully spec-ed out external
function in order to use it. The external function can be constructed as
in:

	"declare glResetHistogram"
	meth :=  ExternalLibraryFunction
		"name+module are omitted since we get the handle by
other means"
		name:'' module: '' 
		"calling convention"
		callType: ExternalFunction callTypeAPI
		"return type"
		returnType: ExternalType void
		"argument types"
		argumentTypes: (Array with: ExternalType ulong).

	"set the function handle manually"
	fnAddress := (glx wglGetProcAddress: 'glResetHistogram').
	fnAddress = 0 ifTrue:[^self error: 'Unable to locate
glResetHistogram'].
	fnAddress := ExternalAddress new fromInteger: fnAddress.
	meth setHandle: fnAddress.

and then be invoked via

	meth invokeWith: 16r8024 "GL_HISTOGRAM"

You'll have to do this for any extension you want to use and yes, it
sucks big time. 

<hack of the day>

I'll show you something that you may use AT YOUR OWN RISK WITH NO
WARRANTY AND ABSOLUTELY NO RESPONSIBILITY ON MY PART. Don't ever try the
following in any other system:

GLXWin32>>glResetHistogram: aTarget
	<apicall: ulong 'glResetHistogram' (ulong)>
	^self extensionCallFailed: #glResetHistogram:
withArguments:{aTarget}

GLXWin32>>extensionCallFailed: selector withArguments: args
	| ffiSpec fnName fnAddress |
	ffiSpec := thisContext sender method literalAt: 1.
	(ffiSpec isKindOf: ExternalLibraryFunction) 
		ifFalse:[^self error: 'WHAT THE HELL ARE YOU
TRYING???'].
	ffiSpec getHandle ifNotNil:[
		ffiSpec getHandle asInteger = 0 ifFalse:[^self
externalCallFailed]].
	fnName := ffiSpec name.
	fnAddress := self wglGetProcAddress: fnName.
	fnAddress = 0 ifTrue:[^self error: 'Unable to locate ', fnName].
	fnAddress := ExternalAddress new fromInteger: fnAddress.
	ffiSpec setHandle: fnAddress.
	^self perform: selector withArguments: args

DANGERS: If your renderer changes this is likely to crash your system. I
have only tried it once and it worked (and it should) but I cannot say
what else may happen during a full session.

ADVANTAGES: You can use any extension you'd like as long as you follow
the scheme used for glResetHistogram (e.g., declare the function with no
"module:" and use #extensionCallFailed:withArguments: to reinvoke it).
Also, except for the first-time invokation the above will be as
efficient as any other ffi call.

</hack of the day>

Cheers,
  - Andreas


> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org 
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> Behalf Of Joshua 'Schwa' Gargus
> Sent: Saturday, December 21, 2002 10:09 PM
> To: Squeak Mailing List
> Subject: Croquet ARB_imaging
> 
> 
> Hi,
> 
> I was wondering how to access the OpenGL ARB_imaging functions from
> withing Croquet.  Whenever I try, I get the error "Unable to find
> function address".  I used glGetString(GL_EXTENSIONS) to verify that
> GL_ARB_imaging is supported.  I thing that the problem is the
> opengl32.dll doesn't provide the appropriate hooks (stupid Microsoft),
> even though NVIDIA's driver implements the functionality.  I tried
> substituting the library "nvoglnt.dll" for "opengl32.dll", because
> the "strings" command told me that glMinMax appeared in the former
> file, which is part of the NVIDIA driver.  This didn't work either,
> which isn't surprising, since it was basically a guess.
> 
> Other ideas?
> Joshua
>