Hi Anthony, Thanks for your tip! I just committed some code that removes the Classes, SysUtils and GL units from GLPT. This is indeed better and cleaner.
As for your questions about supporting different GL versions. GLPT only creates a native GL context and hides some of the platform specific code for the developer. As far as I am concerned there is no interaction with specific GL versions or extensions or whatever. But I could be wrong here, please correct me in that case. On my whish list (next to Mac support) are indeed resolution modes, monitor support, timer and a number of other items. I'm open for pull requests to speed up the progress :). Looking forward for other suggestions and some use cases of course. https://github.com/daar/GLPT Rgds, Darius On Mon, Sep 24, 2018 at 4:53 PM Anthony Walter <sys...@gmail.com> wrote: > Darius, > > I read you message and checked the git repository. I didn't find the > answers to a few questions I had by browsing you source, so I'll ask them > here. Also, I have some comments. > > First questions: > > Do you support requesting context types, such as OpenGL ES 2.0 versus > OpenGL 3.1? > Do you support callback stubs for querying extension strings and loading > extension functions? > Do you provide a curated list of available OpenGL functions and related > constants and types? > Repeat question above, but for all GL extensions and extension constant > and types? > Do you support enumerating available exclusive resolution modes and > switching between modes after a context has been created? > Do you provide a platform independent high resolution timer? > > Comments: > > I noticed you are using the Classes unit inside GLPT. Would it be possible > to remove this reference? In some situations users might not want to use > that unit (which also causes SysUtils to be used) because they desire to > implement their own exception base types or other RTL functions or types. > You really shouldn't be using Classes for a base library like you're > implementing. > > I noticed you are using the existing Free Pascal GL unit. If you are > planning to support OpenGL context types, it might be better to separate > OpenGL functions into different curated units. Units that expose only the > functionality, plus extensions, of a specific context type. This way users > cannot accidentally use functions unsupported by the context they requested. > > Example: > > unit GL30; // defines all the functions and types required by OpenGL 3.0 > unit GLES20; // defines all the functions and types required by OpenGL ES > 2.0, excludes many normal GL functions > unit GLES30; // defines all the functions and types required by OpenGL ES > 3.0, excludes many normal GL functions > > Then users can define a macros {$define GL=GLES20} and can switch APIs for > either testing or development purposes. The separated units with different > functions and types can then easily reveal differences between APIs and > also possibly the subtle differences between how they work. > > _______________________________________________ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
_______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
