[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] backwards compatibility handling
The texture image enum combo jungle is one of the worst aspects of tedious mini changes between desktop/mobile/web GL versions, especially for engines that are designed and written with a "use latest GL version available everywhere" runtime initialization. Specifically for this case, each of the engines (e.g. Unity3D, UE4, internally knows and are interested in saying "initialize me a texture of format R32G32B32A32_FLOAT_LITTLE_ENDIAN", and what they have to do is manage a switch-case mapping of initialized GL version and flavor -> the GL enum triplet that will give the desired format. This is horrible, and time is often wasted when this mapping is not correct. This always amounts to just a simple "oh, right, this GL version X GL flavor needs that enum here instead", so it's not a huge deal to change, but it wastes time due to a pointless api inconsistency. Like you mention, there is no backwards compatibility, and there is no forwards compatibility, and there is no compatibility across GL flavors, so it is quite hairy indeed.
I am not sure if there is a good overall solution to this, but what I would prefer here is that WebGL would strictly follow the GLES specs to minimize the number of disruptions in this front, so it feels like the option 1. would be the easiest from the perspective of GLES<->WebGL parity and engines that multi-target WebGL, GLES and desktop GL.