On Mon, Apr 8, 2013 at 1:59 AM, Sven Barth <span dir="ltr"><<a href="mailto:pascaldragon@googlemail.com" target="_blank">pascaldragon@googlemail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>Am 08.04.2013 01:37 schrieb "Anthony Walter" <<a href="mailto:sysrpl@gmail.com" target="_blank">sysrpl@gmail.com</a>>:</p><div class="im"><br>
><br>
> In addition I have been writing a OpenGL which creates stubs for loading the correct OpenGL library and loading the OpenGL core functions and extensions for every platform.<br>
></div><p></p>
<p>Don't we have that already? And even if not in my opinion it would be better to extend the existing GL units...</p>
<p>Regards,<br>
Sven</p>
</blockquote></div><div><br></div><div>I don't want my three questions to get too side tracked, but I'll give you my reasoning on this point.</div><div><br></div><div>SDL 2.0 adds improved support and unified (all platforms/architectures, android, ios, osx, linux, windows, ect) for OpenGL extension querying, library loading/unloading, context management, but in cases only if you allow SDL to handle the management of OpenGL resources (modules, windows, contexts). Valve brought hired the original SDL author to manage the development of this 2.0 version. The licensing of 2.0 is friendlier (there are no restrictions to static linking), and I believe when it's done, it's going to be a very strong/popular API, especially given how they've added a basic 2D drawing system and much better window management (multiple windows, more event types like touch, full screen toggling without context destruction, and more).</div>
<div><br></div><div>The current Jedi GL unit doesn't mesh well with this. It uses hard coded OpenGL module names, splits extensions into a separate unit (anything beyond OpenGL 1.X), uses an extension loading system which might be incompatible on some platforms when using the SDL 2.0 such as SDL_GL_ExtensionSupported. I think it would be better to have one OpenGL pascal unit which only lists types, constants, function stubs, and leave the actual OpenGL module picking/loading/unloading and extension querying/loading available for other libraries to manage, and dispense of code like:</div>
<div><br></div><div>GL.pas</div><div><div><br></div><div>  {$IFDEF Windows}</div></div><div><div>  LoadOpenGL('opengl32.dll');</div><div>  {$ELSE}</div><div>  {$ifdef darwin}</div><div>  LoadOpenGL('/System/Library/Frameworks/OpenGL.framework/Libraries/libGL.dylib');</div>
<div>  {$ELSE}   </div></div><div><br></div><div>GLExt.pas</div><div><br></div><div><div>{$IFDEF Windows}</div><div>{ Declared in Windows unit as well in FPC; but declared here as well, to be</div><div>  fully compatible to upstream version  - sg }</div>
<div>function wglGetProcAddress(proc: PChar): Pointer; extdecl; external 'OpenGL32.dll';</div><div>{$ELSE}</div><div>function wglGetProcAddress(proc: PChar): Pointer;</div><div>{$ENDIF}</div></div><div><br></div><div>
And instead have something like this in an OpenGL.pas unit:</div><div><br></div><div><div>var</div><div>  OpenGLManager: record</div><div>    Load: function: Boolean;</div><div>    GetProcAddress: function(ProcName: PAnsiChar): Pointer;</div>
<div>    ExtensionSupported: function(Extension: PAnsiChar): Boolean;</div><div>  end;</div></div><div><br></div><div>And allow other units to control how the OpenGL unit manages some functions. Essentially what this involves is a rewrite of the GL unit, which is what I am doing. See every one of the function Load_XXX: Boolean in GLext.pas.</div>