Hi, not sure my last message sent correctly (I tried to change the
subject line to something more descriptive), resending just in case.|
-------- Original Message --------
On 17/11/2011 15:11, 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 thought support might be rare among mobiles, my aim was simply to have
it as a convenience for desktop systems which do commonly support it. I
don't think it's much of a risk since some old desktop OpenGL 1.x
systems don't support it either, so it's always been the case even on
the desktop that you assume textures must be power of two, unless the
presence of that extension indicates otherwise. Since I anticipate
WebGL will usually be used while wrapped inside some framework (like the
engine I'm developing), this would be a useful feature for library
writers who can implement it correctly. Also anyone writing a WebGL app
with experience on the desktop will also be aware of how to use the
extension correctly. So I don't really see this breaking things.