GL ERROR :GL_INVALID_VALUE

[dominikhalvonik]

Version

• Phaser Version: 3.60.0-beta12
• Operating system: Android 10 , Android 11, Android 12 (these has been tested - all Pixel 1, 4, 6a)
• Browser: Chrome

Description

When used compressed textures via ASTC/PVR I received the following warrning for them:

[.WebGL-0xccadc200]GL ERROR :GL_INVALID_VALUE : glCompressedTexImage2D: dimensions out of range

For example this is the texture that we use: https://appspowerplaymanager.vshcdn.net/images/winter-sports/map/sprites/compressed/buildings-astc12x12-hash-correct-name.pvr

Additional Information

In the console log I can see that there are 20 of these errors and I have 19 textures used in my game. So it looks that almost all of them are throwing this issue. Right after these 20 issues I can see the following warrning:

[.WebGL-0xccadc200]RENDER WARNING: Render count or primcount is 0.

And this is happening in loop, it might be interconnected.

[mgemmel]

same issue with ASTC/PVR textures...

[gord007]

The same issue

[photonstorm]

Does Android even support this format fully? ETC1 is the most common format for Android. ASTC support was around 60% last time I checked.

If you create a single test case that does nothing but load in a compressed texture (with the fallbacks it should require) and adds a single sprite to the Scene, what happens then? Same error? Does it fail with the ASTC files available in the Phaser 3 Examples repo as well, or just yours?

I need a test case, really, as I don't have any Android hardware.

Is this only Beta 12 that does it? Or does Beta 10 do it as well? As I've not touched the compressed texture code for months, so it would be useful to know if it was the pipeline change that did this, or if it has always done it.

Also, no useless 'same issue' comments, please. If you want to help, provide test cases and debugging info.

[dominikhalvonik]

Hi @photonstorm ,

based on what I know, the support for ASTC is quite good at the moment. In 2020 for Android it was 77% (https://developer.android.com/guide/playcore/asset-delivery/texture-compression) so now it will be even more I think. On the other hand, based on what I red the ASTC is the best format because of multiple reasons (https://developer.nvidia.com/astc-texture-compression-for-game-assets). I choosed it becasue it has the textures has the same quality as it has with ETC2 but the disk size of the file is much lower with ASTC 12x12. Because we have a web based game it is quite important for us to reduce the network transfer.

Reagards to support on those specific devices, I am quite sure that they support it, because the only reason why I know that there are these type of warnings is that I opened JS console. The game is working without any issues, the VRAM is used on very low levels compare to PNG format and from user perspective, all is fine.

The code which we use is following:

For sprite sheets

export const atlasLoader = (phaser, loadArray) => {
  loadArray.forEach(({ name, compressed, data }) => {
    if (compressed) {
      phaser.load.texture(name, {
        ASTC: {
          type: data.astc.type,
          textureURL: data.astc.textureURL,
          atlasURL: data.astc.atlasURL,
        },
        S3TC: {
          type: data.s3tc.type,
          textureURL: data.s3tc.textureURL,
          atlasURL: data.s3tc.atlasURL,
        },
        ETC: {
          type: data.etc.type,
          textureURL: data.etc.textureURL,
          atlasURL: data.etc.atlasURL,
        },
        PVRTC: {
          type: data.pvrtc.type,
          textureURL: data.pvrtc.textureURL,
          atlasURL: data.pvrtc.atlasURL,
        },
        IMG: {
          textureURL: data.img.textureURL,
          atlasURL: data.img.atlasURL,
        },
      })
    } else {
      phaser.load.atlas(name, data.image, data.json)
    }
  })
}

For single files

import { pathImages } from '@/globalVariables'

export const imageLoader = (phaser, loadArray) => {
  loadArray.forEach(({ name, compressed, data }) => {
    if (compressed) {
      phaser.load.texture(name, {
        ASTC: {
          type: data.astc.type,
          textureURL: pathImages + data.astc.textureURL,
        },
        S3TC: {
          type: data.s3tc.type,
          textureURL: pathImages + data.s3tc.textureURL,
        },
        ETC: {
          type: data.etc.type,
          textureURL: pathImages + data.etc.textureURL,
        },
        PVRTC: {
          type: data.pvrtc.type,
          textureURL: pathImages + data.pvrtc.textureURL,
        },
        IMG: {
          textureURL: pathImages + data.img.textureURL,
        },
      })
    } else {
      phaser.load.image(name, pathImages + data.place)
    }
  })
}

So I assumed that Phaser as a framework will go to the list of available options and go one by one from first to last (ASTC - S3TC - ETC - PVRTC if no compressed format support available use IMG) and use the one, which is supported.

This was happening in Beta 10 , 11 and now 12. Thank you for your response.

Dominik

[photonstorm]

Yes, the order is important as it's in GPU priority order. So if there are 2 formats the GPU supports in the list, the first one is the one that is picked.

Are you saying that despite the errors, it's still actually rendering ok? Are they just warnings, rather than stop errors?

From the Khronos specs: "GL_INVALID_VALUE is generated if imageSize is not consistent with the format, dimensions, and contents of the specified compressed image data."

Which to me makes me think Android is expecting a dimension it isn't getting. This is why I asked if the textures in the Phaser Labs do the same as your own textures.

[dominikhalvonik]

Hi, yes I am getting the same outcome, this is an screenshot from Pixel 1 Android 10 but I can provide more devices if you want:

[dominikhalvonik]

Any update on this?

[photonstorm]

I've tested v3.80 Beta 1 with this example https://labs.phaser.io/view.html?src=src%5Ctextures%5Ccompressed%20texture%20atlas.js&v=dev on:

Google Pixel 4 - Android v10
Google Pixel 7 - Android v13
Samsung Galaxy S20 - Android v10

And they all render, but I get the following in the console once per texture:

GL_INVALID_VALUE: The texture is a non-power-of-two texture.

Which is fair enough I guess, as they aren't!

I don't have access to any devices lower than a Pixel 3, but that has Android 9 on it which doesn't run the Phaser labs. So currently am a bit stuck what else to try.

[photonstorm]

[dominikhalvonik]

Will check it next week.

[dominikhalvonik]

Ok I can see the following message in console

I tested the following list of devices:

Pixel 8 Pro Android 14
Pixel 8 Android 14
Pixel 7 Android 13
Pixel 7 Android Pro 13
Pixel 6 Android Pro 13
Pixel 6 Android 12
Pixel 6 Android Pro 12
Pixel 5 Android 11
Pixel 5 Android 12
Pixel 4 Android 11
Pixel 4 Android 10
Pixel 4 XL Android 10
Pixel 3a XL Android 9
Pixel 3a Android 9
Pixel 2 Android 8

But still when I enter my game which has all textures generated by TexturePacker I am getting the following warnings:

I do not know, how to solve this. Because the textures are displayed correctly.

[photonstorm]

Yeah, we'll look at this one soon, as it fits well with the new internal texture work.

[BenjaminDRichards]

We've dug through the compressed texture system, and made it more capable and better able to recognise issues within textures. We can't stop WebGL from complaining, but we can explain probable causes on a per-file basis, and block files that might work sometimes but still contain glitches.

The core problem is, tools like TexturePacker don't enforce some of WebGL's requirements. The files might be valid in another OpenGL context, but in WebGL they're not. Ordinarily I'd say these errors are due to mipmap levels, where the top level is fine but deeper levels are not; but TexturePacker doesn't generate mipmaps, as far as I'm aware.

We've looked at the texture in the initial issue report, and it's a perfect TexturePacker file, with no deeper mipmaps and fulfilling all the requirements in the ASTC format specifications. ASTC with no mip levels shouldn't have any restrictions on resolution. The safest resolutions in WebGL are always power-of-two, particularly when working with mipmaps, but that shouldn't be necessary here. (It is something to try if warnings persist.) The only issue is that it's in sRGB color, which we didn't previously support (we treated it as linear). Phaser's increased capabilities should treat the file correctly going forward.

I'm closing the issue, but please test the latest updates to Phaser, and we'll reopen if needed. If it invalidates any existing files, it will give a precise reason, and point us in the direction of resolving it!