Lime 4 has been released, and among other changes, we have improved our support for OpenGL!
OpenGL has a large number of APIs, which may be available on only certain platforms (such as the desktop), or may require recent graphics drivers. This can create problems when seeking simplicity, broad device support or unifying cross-platform APIs. After much thought, we have designed a new system where we believe we can continue to expose new OpenGL APIs, while preserving the same simple cross-platform interoperability of current Lime releases.
Lime OpenGL support begins with a
GLRenderContext. This API more closely resembles the native OpenGL and OpenGL ES APIs, but is designed to operate also in the browser. Optionally, there is a static
GL class which access the last created context, but with multiple windows and future support for multiple OpenGL contexts, it was important that our native platforms move to GL context objects at the core, similar to how WebGL behaves.
The new Lime 4 API includes Haxe abstract types to provide guard rails or a more familiar syntax over the OpenGL context object:
In the WebGL API, the
count is determined automatically by the size of the
ArrayBufferView used to upload. In OpenGL and OpenGL ES, however,
bufferData requires a size parameter. The downside is that this is more verbose, but the benefit is that we can create a data pointer from an
BytesObject, or even a native pointer provided from a C++ extension library. Long-term, this can make things more flexible.
Bytes example above is perhaps not as nice as using the
Float32Array, either will work in the GLES2-style API. The benefit of being able to use pointers becomes more clear if you wish to upload multiple values from the same bytes object, such as in the following example:
In the WebGL API, a new
ArrayBufferView must be created for each upload, which is not ideal due to the garbage objects that will need to be deleted by garbage collection in the future. In the
GLES2Context example code, however, we are able to upload a pointer to the same byte object repeatedly, without allocating new objects.
If a GL context has been lost, Lime 4 will create a new
GLRenderContext object, even if the same OpenGL context object is returned by the native platform. This adds another way to be able to check if an OpenGL object comes from an invalid OpenGL context:
You can also use
bufferContext.isContextLost () on a dead context to determine if it is valid.
GLRenderContext also exposes
version properties, to make it easier to determine the current running environment, and what features may be available:
You may choose to use the
GLRenderContext directly (being careful which features you use), or you may choose to lock into a limited API, such as
WebGLContext to run on all platform types. Currently, desktop OpenGL should support OpenGL ES 2 APIs that Lime 4 exposes, and both desktop and mobile GL should support WebGL APIs.
We are in the process of adding support for GLES3 APIs, and are considering additional abstract types for varying desktop GL versions. We appreciate your feedback as we continue to evolve support for advanced features, while also preserving cross-platform support.
Lime 4 also introduces many missing typed APIs, for example,
getBooleanv as an alternative to the WebGL
getParameter. The goal is to support all of these APIs on all platforms, so HTML5 can have a typed forced on a parameter, while native can return a
Dynamic type using
getParameter, or specific type using a more exact API.
Lime 4 introduces better support for OpenGL extensions, beginning with known OpenGL ES 2 and WebGL extensions. With your feedback, we hope to continue to improve support for advanced features.
Thank you for your support! We are excited to continue to make Lime a better, more useful cross-platform layer!