<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote">Ryan,</div><div class="gmail_quote"><br></div><div class="gmail_quote">1&2:</div><div class="gmail_quote"><br></div><div class="gmail_quote">Typically what happens is the programmer can enumerate the supported exclusive (full screen and dedicated to a graphics context) resolution modes. The available resolution modes is dependent on their monitor, video driver, and operating system. Each mode defines a width and height in pixels, the color depth, and refresh rate. When the programmer creates a window they need some way to find, or enumerate, these modes, and they also need a way to switch the window and context to fit one of these modes. These are all things that should be supported by the underlying graphics toolkit. That is, the toolkit should allow the programmer to find out what modes exists on the end users computer, and pick one of those modes possibly before creating the window and context.</div><div class="gmail_quote"><br></div><div class="gmail_quote">3: </div><div class="gmail_quote"><br></div><div class="gmail_quote">The OpenGL API functions such as glGenBuffers, or glUseProgram are provided by either an open source community, or from the operating system, or from the hardware manufacturer driver. You cannot statically link these functions to a so (shared object) or dll (dynamic link library) at compile time, because based on the users configuration they reside in several possible locations. For example on Linux when an OpenGL ES 2 context is needed the OpenGL functions must come from libGLESv2.so located in in a vendor specific lib folder created by nVidia. For a core context the libGL.so is a different name and located in a different folder. It is the job of the toolkit to determine based on the request context type which OpenGL library should be loaded. That library should then be passed back to the programmer so that he can link to the correct OpenGL API for the context he requested.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Each platform Windows, Linux, and Mac have their own APIs to make it easier to find the correct OpenGL library. Windows has wgl, Linux has egl, and mac has something else. Your toolkit should at least cover the differences in wgl, egl, and the Mac API so that programmers don't need to add their own wgl or egl code.</div><div class="gmail_quote"><br></div><div class="gmail_quote">The Free Pascal LoadLibrary and FetProcAddress should be sufficient enough to load the appropriate OpenGL function if you can tell then either the path to the OpenGL library, or more realistically the handle to the already OpenGL library already loaded by you.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Regarding extensions, each platform and library has their own implementation of how to get the address of an OpenGL extension. On Windows you can use wglGetProcAddress, while on Linux you would use wglGetProcAdress. Your toolkit should provide an abstraction so that it's doesn't matter which platform you are on and the extension loading is handled the same.</div><div class="gmail_quote"><br></div><div class="gmail_quote">4:</div><div class="gmail_quote"><br></div><div class="gmail_quote">In your source code for Windows you are using GetTickCount to return the time. See this stack overflow answer to see why that's a bad thing.</div><div class="gmail_quote"><br></div><div class="gmail_quote"><a href="https://stackoverflow.com/questions/24009263/why-queryperformancecounter-and-gettickcount-does-not-keep-in-pace">https://stackoverflow.com/questions/24009263/why-queryperformancecounter-and-gettickcount-does-not-keep-in-pace</a><br></div><div class="gmail_quote"><br></div><div class="gmail_quote">The code I provided you should give high resolution timing on all platforms. Use it if you want, but please don't rely on GetTickCount for time on Windows.</div></div></div></div></div>