If implemented by the user, it is called periodically after processing
input events and before draw event and does not depend on whether there
are any input events or the application needs to redraw.
Useful in this case:
std::optional<Platform::Context> context;
context = Platform::Context{};
This was currently possible only with calling context.emplace(), which
in my opinion is confusing and looks like a no-op. Move assignment is
still not allowed, because having two separate state trackers (and
deleting one of them) currently makes no sense.
It is superseded by core functionality. The only annoyance is that you
need to use TextureFormat::SRGB in ES2 and TextureFormat::SRGB8 in ES3,
but that's with many other formats anyway. Also apparently the unsized
format is still allowed in core desktop GL, which is a shame.
Intel drivers on Windows print out "No errors." when the shader is
compiled/linked successfully. I consider that as unnecessary spam and
filter it out.
The original goal was to avoid branches when binding the vertex
attributes for drawing, so I stored float, integral and double
attributes in separate std::vector instances and then was going through
each one of them in separate loop. In retrospect that was _not_ a good
idea, because it results in larger Mesh class, two more allocations
resulting in far more pointer chasing and more complicated
constructor/destructor.
Now everything is stored in a single vector. I may optimize it further
by not calling the constructor/destructor on it when VAOs are used.
The original problem was that I was using 3D wrapping mode (S, T, R) for
cube map textures, but GL_TEXTURE_WRAP_R was not defined on ES2 so it
seemed rather suspicious.
Google seems to be lost on this and most of the online tutorials seem to
be setting GL_TEXTURE_WRAP_R even for cube map textures, so I need to
investigate myself. As seen in the rather old ARB_texture_cube_map
extension, there is no new GL_TEXTURE_WRAP_R token added, it is defined
only for 3D textures and there is no apparent dependency between these
two. The wrap mode for cube maps is defined as follows:
* The sampler determines one of the six faces and then employs
conventional 2D texture mapping on given face.
Thus wrapping mode for CubeMapTexture is now changed to be only
two-dimensional (instead of 3D).
For texture arrays the mode is also only one- or two-dimensional (not
two- or three-dimensional), because, as said in the (also rather old)
EXT_texture_array extension, the texture layer is _always_
(independently of any sampling state) selected as follows:
l = clamp(round(t), 0, num_layers - 1)
Thus wrapping mode for Texture1DArray is now changed to be only
one-dimensional (instead of 2D) and for Texture2DArray only
two-dimensional (instead of 3D).
Wrapping for CubeMapTextureArray is now also two-dimensional instead of
3D (with the original way of thinking it would have needed to be 4D!).
For more clarity it's now better to explicitly list all extensions for
each API even though they might get duplicated. For WebGL they also link
to WebGL spec, which might contain a bit more info.