[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] WebGL
On Thu, Nov 17, 2011 at 1:40 PM, Benoit Jacob <email@example.com> wrote:
For example, something we realized recently is that OES_texture_float isn't supported on mobile hardware in the same way as it is on the desktop.
On 17/11/11 03:02 PM, Chris Marrin wrote:
On Nov 17, 2011, at 7:11 AM, Benoit Jacob wrote:
On 17/11/11 09:49 AM, Ashley Gullen wrote:
I'm writing a 2D game engine in WebGL (see www.scirra.com), and this is
my first mail to the list - apologies if this has been discussed before.
I've found the power-of-two restrictions in WebGL a little inconvenient,
since NPOT textures are common in 2D games. It seems a shame that in
WebGL NPOT textures can't be mipmapped or directly tiled without
stretching to a POT texture first. I've done some work with desktop
OpenGL and found the GL_ARB_texture_non_power_of_two extension to be
widely supported and very useful for this situation: it allows direct
tiling and mipmapping of NPOT textures which is great for 2D games.
There does not appear to be an NPOT extension for WebGL. Could I suggest
that one be added to indicate the relaxing of POT rules? Since many
desktop systems seem to support it this means the workarounds could be
disabled on these machines for a better gaming experience.
An important data point to discuss that is: how widely is GL_OES_texture_npot supported on current mobile devices?
I think I might lean toward adding a WebGL extension for NPOT textures as we already have some extensions that are not well supported on mobile devices anyway; but this is a little bit more dangerous as textures are a basic feature and this opens the door to whole games that wouldn't run at all on mobile devices.
I'm not sure what you mean by that. I think all the extensions we have ratified are well supported by mobile hardware. iOS supports everything in the list, for instance.
The difference is that on most OES hardware, even if OES_texture_float is supported, float textures cannot be rendered to (attached to FBOs).
Another big difference is that whereas vertex-shader-texture-fetch is now ubiquitously supported on the desktop, it is not supported by most current mobile hardware.
Now that the cat is out of the box, I can't help thinking that it is still a good thing that WebGL supports these features, even if they're poorly supported on mobile platforms, in view of the really interesting applications that they allow. I find some comfort in the fact that due to how WebGL extensions work, it is relatively hard to come to depend on one without noticing. A more worrisome risk though is that developers would start (consciously) using certain extensions, without realizing that they incur a portability degradation. This is a communication/documentation problem; not sure what we can do about it.
The best path forward might be to define a WebGL extension which covers the least common denominator of all of these extensions, so that it can be supported on the majority of existing hardware.