OpenGL

From Free Pascal wiki
Jump to navigationJump to search

Deutsch (de) English (en) français (fr) 日本語 (ja) português (pt) русский (ru) Tiếng Việt (vi) 中文(中国大陆)‎ (zh_CN)

OpenGL (Open Graphics Library) is a cross-platform API for producing 3D computer graphics. Most modern video cards provide hardware accelerated OpenGL support, wich makes OpenGL a good solution for writing advanced graphics software.

OpenGL units in Free Pascal

The FreePascal OpenGL interface consists of the following units:

  • gl: This unit contains the main functionality such as drawing polygons, applying transformations, setting colors and materials,... Procedures always start with the preposition "gl".
  • glu: This unit contains OpenGL utils. Although it has some useful functions, this unit is not necessary as you can implement all glu Procedures with the functionality of the gl unit. Procedures always start with the preposition "glu".
  • glext: Vendors can provide additional functionality through extensions. Use this unit to use these extensions.

    The functionality specific to higher OpenGL versions (1.2 and later) is available in this unit as well. Initializing this functionality is similar to initializing normal OpenGL extensions: just call Load_GL_version_X_Y function. If your OpenGL library version is older than X.Y, Load_GL_version_X_Y will return false.

  • glut: This unit provides functionality for creating an OpenGL window. Although this is a cross-platform unit, most Windows operating systems don't have a glut dll by default.
  • glx: glx provides functionality to set up an OpenGL window in an x window system. Procedures always start with the preposition "glx". Obviously, you cannot use this unit on non-x window systems such as Windows.

OpenGL units in Lazarus

Lazarus includes a TOpenGLControl - a LCL control with an OpenGL context. The lazarus package LazOpenGLContext can be found lazarus/components/opengl/lazopenglcontext.lpk. An example can be found in lazarus/examples/openglcontrol/openglcontrol_demo.lpi.

Third party OpenGL units

  • GLScene is a Lazarus package with lots of extra features for OpenGL applications.
  • Kambi VRML game engine allows you to navigate and render 3D worlds (in VRML, X3D and other 3D formats).

Tutorial

OpenGL Tutorial

Q/A using OpenGL binding

Q: I am loading Load_GL_version_X_Y, but it seems I can't get *ARB function to be loaded. It has been accepted as a standard in earlier OpenGL versions, and present in X.Y version too. Can the binding be changed to load all previous version in Load_GL_version_X_Y call?

A: The binding treats OpenGL versions in the same way as any other extension. Only new version function are loaded on demand. This makes the binding very *flexible*. Because some obsolete functions might be removed in future OpenGL versions.

Instead of changing the binding, you can just a single initialization function for your needs, for example:

The function loads all OpenGL routines available declared in 2.0 standard. But it does not load any routine that's available in OpenGL 2.0 as an extension you need to add the loading extensions manually.

<pascal> function Load_required_GL_version: Boolean; begin

 Result := Load_GL_version_1_2 and
           Load_GL_version_1_3 and
           Load_GL_version_1_4 and
           Load_GL_version_1_5 and
           // add any other extension you might need here
           // load_GL_ARB_vertex_buffer_object and
           Load_GL_version_2_0;

end; </pascal>

Changing the OpenGL binding is not acceptable, because changing might break some existing code written using the binding.



Q: I don't understand why the ARB version does not work. AFAIK it has the same entry points as the core functionality and OpenGL versions are required to support the ARB version of functions even if the non ARB version is in the core now.

A: No. OpenGL doesn't have to support the extension entry points, even when it supports the same functionality in core already. Vendor is free to remove the extensions, and support only the "core" functions.

Also, sometimes when functionality is promoted from ARB extension into core it's slightly changed (although in 99% cases it stays the same). Example is the GLSL shaders, that expose (very slightly) different API through ARB extensions and through core 2.0 specification.

Basically, what is exposed through extensions is completely orthogonal to what is exposed through core functionality, so they should be initialized separately. In particular cases, you can make tricks like

 if glIsBufferARB = nil then glIsBufferARB := @glIsBuffer;

but this should be left to the final programmer that knows that "ARB_vertex_buffer_object" behavior is identical to how it works in core.


Go to back Packages List