Some Basic OpenGL Questions

[parallax7d]

I'm trying to piece together some very basic info. I'm a bit confused about OpenGL. It seems like the features it supports are a moving target, which is complicated by client OS and graphics card/drivers. I apologize for the naivete of the following questions.

From what I understand, Love 0.10.0 now has a minimum requirement of OpenGL 2.1?

Does Love always use OpenGL 2.1, or will it use a newer standard if a particular client supports it?

I ran love.graphics.getRendererInfo() on my mac, and it only supports OpenGL 2.1. But why does my mac support multicanvas and texturesize of 8192 if it only supports OpenGL 2.1? Is it because my particular graphics driver supports more than the minimum required for OpenGL 2.1?

If we want to support all clients that can run Love, does that mean we should generally code our projects to comply with the minimum requirements of OpenGL 2.1? For instance maximum 64x64 px textures? Or is it better to target some other 'reasonable' set of features, like what Intel chips supported in 2008? Any elaboration on this point in particular would be very valuable.

Framebuffer Objects are canvases? It looks like FBOs were moved into openGL 3.0 'core' according to their wiki, does that mean that Love implements the EXT (extension) version of FBOs? Is this less efficient than on systems where it's part of 'core'? If this question makes no sense it's because I don't know what I'm talking about.

edit: I like the new forum software!

Also, according to this article, it seems like Mac OS 10.7+ (the minimum OS for Love 0.10.0) supports OpenGL 3.2 'core'. Why is Love still using OpenGL 2.1 then?

[s-ol]

For the last part, support != always uses I guess, but I don't know a lot about mac.

OpenGl 2.1 is a standard, but it doesnt standardize all capabilities of a card. Cards can support more or less and smaller or bigger textures, FBOs etc, OpenGL just provides ways to access these. Using a newer standard if available doesn't really make too much sense (afaik?) because it barely improves speed or at least not with big modification to the API, improvements only come from new concepts/ways to do things being introduced.

And yeah FBOs were moved out of extension into core, I don't know whether that brings a speed improvement also but I doubt it. It's just that OpenGL 3 forces gpus to support it and makes the setup easier.

[slime]

From what I understand, Love 0.10.0 now has a minimum requirement of OpenGL 2.1?

Technically LÖVE requires either OpenGL ES 2.0, or OpenGL 2.1 plus the GL_EXT_framebuffer_object extension (which provides support for Canvases). Or OpenGL 2.1 plus GL_ARB_framebuffer_object, which has more features than the EXT extension. Or OpenGL 3+ Compatibility Profile.

Does Love always use OpenGL 2.1, or will it use a newer standard if a particular client supports it?

It's Complicated™. As you've figured out, OpenGL versioning is a bit weird.

LÖVE's graphics code works as long as the OpenGL version of the Graphics Context is compatible with OpenGL 2.1 or OpenGL ES 2.0. It does use some features from newer OpenGL versions when either the driver creates a Compatibility Profile context of a higher GL version, or the driver provides the features via extensions. Compatibility Profile OpenGL 3+ contexts are supported by some drivers and provide full backwards compatibility down to code written for OpenGL 1.0 (for better or worse).

The HDR / floating point Canvas Formats are an example of an OpenGL 3 feature LÖVE optionally supports (either via extensions or a Compatibility Profile GL3 graphics context). Gamma-correct rendering is another example.

I ran love.graphics.getRendererInfo() on my mac, and it only supports OpenGL 2.1. But why does my mac support multicanvas and texturesize of 8192 if it only supports OpenGL 2.1? Is it because my particular graphics driver supports more than the minimum required for OpenGL 2.1?

OS X doesn't support Compatibility Profile GL3, only legacy GL2.1 (with many extensions that provide features from GL3), and Core Profile GL3 and GL4, which isn't backwards-compatible with code written to work with GL2 (like LÖVE).

So LÖVE creates a "legacy" opengl 2 context in OS X, even when the GPU is capable of GL3 / DX10 and its features (all Macs running OS X 10.8 and later are guaranteed to have GPUs that support at least GL3).

Apple has a nice table of the OpenGL versions and extensions OS X supports, for both Legacy GL2 and Core Profile GL3: https://developer.apple.com/opengl/capa ... _1090.html

If we want to support all clients that can run Love, does that mean we should generally code our projects to comply with the minimum requirements of OpenGL 2.1? For instance maximum 64x64 px textures? Or is it better to target some other 'reasonable' set of features, like what Intel chips supported in 2008? Any elaboration on this point in particular would be very valuable.

The OpenGL 2.1 specification technically doesn't require drivers to provide support for larger textures, but in practice all desktop OpenGL 2+ drivers support at least 2048x2048 textures, and most support 4096x4096 or larger. This is partly because 2048x2048+ textures are common and useful, and partly because DirectX 9 (which is roughly equivalent to OpenGL 2) has less lenient requirements for conforming GPUs.

Framebuffer Objects are canvases? It looks like FBOs were moved into openGL 3.0 'core' according to their wiki, does that mean that Love implements the EXT (extension) version of FBOs? Is this less efficient than on systems where it's part of 'core'? If this question makes no sense it's because I don't know what I'm talking about.

Yeah, Canvases use Framebuffer Objects. Full-featured FBOs including support for all the Canvas Formats listed on the wiki page are part of GL3.0.
Desktop GL2 doesn't technically have FBOs in its specification but the GL_EXT_framebuffer_object extension provides support and is completely ubiquitous among systems that only support GL2. It provides FBOs in a more limited manner (e.g. fewer guaranteed canvas formats), but it's not less efficient.

[parallax7d]

thanks Slime, super useful

It does use some features from newer OpenGL versions when either the driver creates a Compatibility Profile context of a higher GL version, or the driver provides the features via extensions. Compatibility Profile OpenGL 3+ contexts are supported by some drivers and provide full backwards compatibility down to code written for OpenGL 1.0 (for better or worse).

So Love's graphics code does act a little differently if provided a Compatibility Profile above 2.1? Are these simply back end refinements, like calls to non-deprecated functions? Would Love potentially provide a feature to a client with a newer CP, which would not be backwards compatible with a client running just CP 2.1 (macs)?

Could you provide any other general pointers about what feature limits to target, given the constraints of the OS's and the modernity of their graphics hardware/drivers? This is really the info I'm driving at. Like try to keep textures at <=2048, how many canvases are too many, try not to go over n amount of VRAM, etc.. I know a lot of this stuff is dependent on various things, I'm just looking for safe/reasonable targets, which aren't as restrictive as the minimum specs listed for OpenGL 2.1 compatibility suggest.

[slime]

So Love's graphics code does act a little differently if provided a Compatibility Profile above 2.1? Are these simply back end refinements, like calls to non-deprecated functions? Would Love potentially provide a feature to a client with a newer CP, which would not be backwards compatible with a client running just CP 2.1 (macs)?

Well, for the most part (with a couple minor exceptions) it only uses functions from newer OpenGL versions and from extensions to provide new features, rather than to change internal functionality. Currently all optional graphics features in LÖVE are usable in the legacy GL 2.1 context in OS X because it has the necessary extensions.

In the future I do want to add full backend support for Core Profile GL3 (while also keeping backend support for GL2 when GL3 isn't supported), but the shader situation is tough because Core Profile GL3 doesn't support GLSL 1.20, and while the newer shading languages are mostly a superset of GLSL 1.20, I don't want people to write shader code that works on their machine and unexpectedly doesn't work on machines that only support GLSL 1.20.

Could you provide any other general pointers about what feature limits to target, given the constraints of the OS's and the modernity of their graphics hardware/drivers? This is really the info I'm driving at.

I made a small table of some things here: https://bitbucket.org/rude/love/issues/ ... t-16078603
It's more about the GPU hardware than the OS (for the most part).

how many canvases are too many

With Canvases (and Images), it's more about the total amount of graphics memory taken up by all of them together, rather than a specific number of Canvases. [wiki]love.graphics.getStats[/wiki] provides an estimate of the current amount of graphics memory used for textures. For low-end desktops I'd say try to keep it below 256MB at all times.

[parallax7d]

What are the future plans for OpenGL and GLSL version support? Anything in the short/medium term to look forward to? Any new extensions/features?

Also, does Love currently support any additional features not included in GLSL 1.20?

[slime]

What are the future plans for OpenGL and GLSL version support? Anything in the short/medium term to look forward to? Any new extensions/features?

Right now I'm working on extending Textures (Images and Canvases) to support different texture types - 2D array textures (https://bitbucket.org/rude/love/issues/ ... y-textures), cubemaps, and 3D textures. Cubemaps and 3D textures only have niche uses for 2D games, but 2D array textures are quite useful and better than texture atlases in a lot of ways. However they require a GPU which is capable of DirectX 10/OpenGL 3-level features.

I also plan to support GLSL 3.3 / GLSL ES 3.0 (which enables some new features and functions people can use in shaders). However it requires some extra internal changes in love.graphics (a Core Profile OpenGL 3 backend, for one). But I'm at least partway done work on that.

Once that's in, I'll probably add support for hardware instancing of Meshes (which allows you to render thousands of the same Mesh with different transforms and other per-mesh properties, with a single draw call). That will also require a GPU that supports DX10/GL3-level features.

Asynchronously (without stalling the CPU while waiting for the GPU) capturing screenshots is also something I want to do – and to do it well requires using OpenGL 3's sync objects to query whether an OpenGL operation has completed on the GPU.

Being able to profile how long certain things take on the GPU is another thing that OpenGL 3 provides which I might write an API for.

Also, does Love currently support any additional features not included in GLSL 1.20?

In terms of shaders? Not directly at the moment, although (on most drivers, except for Mesa on linux and possibly mobile devices - see here) you can use the #extension directive in shader code to enable some extra features provided the driver supports them.

[MachineCode]

Cubemaps and 3D textures only have niche uses for 2D games

Does that mean you can have a skybox as a backdrop? Can the proposed cubemap feature be used to render a spherical surface to a canvas? Those two features would be good. You could do some quite nice space simulations without really stepping outside of 2D. Full 3D game engines have too much baggage, but just a few 3D features like that would be a great addition to LÖVE.

[s-ol]

By the way, you can filter through loads of GPU capability reports on this page: http://opengl.gpuinfo.org