On 14 April 2010 06:58, Andreas Raab <andreas.raab at gmx.de> wrote:
> On 4/13/2010 8:42 PM, Igor Stasenko wrote:
>>
>> On 14 April 2010 06:22, Andreas Raab<andreas.raab at gmx.de>  wrote:
>>>
>>> On 4/13/2010 8:10 PM, Igor Stasenko wrote:
>>>>
>>>> i just submitted a code, which could help us greatly in having
>>>> up-to-date and full OpenGL API coverage in Squeak.
>>>>
>>>> This package extracts data directly from spec files, used by OpenGL
>>>> folks for generating C headers (gl.h / glext.h etc).
>>>
>>> Sweet! I had no idea these spec files existed. Do you know if the spec
>>> files
>>> cover OpenGL ES as well? Also, have you run this against the existing
>>> OpenGL
>>> code to see if it produces matching output? (more to verify your
>>> translation
>>> than anything else)
>>>
>> I think better would be to check with C header files, like glew
>> (http://sourceforge.net/projects/glew/).
>
> True. Have you tried it?
>
well this might be a bit time consumig:
GLAPIData gl functions size 2063
:)
so, i think this is going to be a step by step discovery process, for
the functions which i will use :)


>> The FFI code generator is unfinished (if you look at it, its using an
>> OpenGL-defined standard type set, like GLEnum GLShort etc..)
>> So, there should be 1 more mapping step to turn them into 'long short'
>> etc.
>> Or, if FFI can cope with type aliases, then they could be kept as is.
>
> This should be straightforward.
>
>> There's also all constant values sitting parsed. But i haven't coded
>> the fileout yet.
>> The repository is open for write globally, so you can just commit your
>> stuff right there.
>>
>> But i'd like to note, that in order to avoid dependencies, it would be
>> better to use separate subpackage
>> for code generation, while in original package there should be just
>> classes for parsing and holding the data.
>
> Well, I don't really care since this would be (mostly) a one-time job unless
> someone cares about special API versions ;-)
>
i don't know, maybe i'm too picky
there is FFI and Alien, also i will use it for generating native code callouts,
so to not put much mess into classes which holding a data, it would be
better to keep code separated, like:
FFIOpenGL-Specs
AlienOpenGL-Specs
NBOpenGL-Specs

> OpenGL should be generated by something like:
>
>        OpenGLApiGenerator generateFunctions: 1.4 on: OpenGL.
>
> which would create the equivalent to the current OpenGL function set. Then
> we move on to, e.g.,
>
>        OpenGLApiGenerator generateExtFunctions: 'ARB_multisample' on:
> OpenGL.
>
> etc. The default OpenGL would include all versions and extensions but if
> you'd like to be more specific you can generate custom versions of the API
> for your use (we'd do this for Teleplace for example since we're trying to
> stick to 1.4 and certain extensions).
>
Yeah, i thought about similar approach for filtering a function set
by placing them into subclasses like:
OpenGL10 -> OpenGL14 -> OpenGL20 ->OpenGL30 etc

For instance there is:

GetFragDataLocationEXT(program, name)
	return		Int32
	param		program		UInt32 in value
	param		name		Char in array [COMPSIZE(name)]
	category	EXT_gpu_shader4
	dlflags		notlistable
	version		2.0
	extension	soft WINSOFT
	glfflags	ignore
	glxflags	ignore
	alias		GetFragDataLocation

and

GetFragDataLocation(program, name)
	return		Int32
	param		program		UInt32 in value
	param		name		Char in array [COMPSIZE(name)]
	category	VERSION_3_0
	dlflags		notlistable
	version		3.0
	extension
	glfflags	ignore
	glxflags	ignore

so, a generator could use a clever approach, like
defining a single method #glGetFragDataLocation
but depending on driver version, load 'GetFragDataLocationEXT' address
for gl 2.0,
or 'GetFragDataLocation' for gl 3.0

> Cheers,
>  - Andreas
>
>

-- 
Best regards,
Igor Stasenko AKA sig.