phaser-ce
phaser-ce copied to clipboard
WebGL error when destroying TileSprite using setTexturePriority
This Issue is about:
- A bug in the API:
- Phaser version(s): 2.7.9
- Live example: https://codepen.io/anon/pen/NjLXKd
- What should happen: The TileSprite should be destroyed and not throw WebGL errors.
- What happens instead: When the TileSprite is destroyed, the following errors are thrown every tick in the console. This only happens when batching textures with WEBL_MULTI and setting them in
setTexturePriority
.
[.Offscreen-For-WebGL-0x7ff958a8fe00]RENDER WARNING: there is no texture bound to the unit 2
Odd, Firefox doesn't show a warning.
Sorry, forgot to mention that this is only happening in Chrome as far as I can tell (or at least Chrome is the only one throwing an warning).
This warning may involve WebGL and Video Card Drive. The same I post here: https://github.com/photonstorm/phaser-ce/issues/221
It's not something specific with Phaser. Involves the implementation of any WebGL Framework
In melon issue they used this "hack": http://stackoverflow.com/questions/19722247/webgl-wait-for-texture-to-load/19748905#19748905
In mapbox issue they added something like this to check load:
_prepareImage(gl, image) {
if (this.tile.state !== 'loaded') {
this.tile.texture = gl.createTexture();
@Gurigraphics Those issues mention that it has to do with using the texture before it has loaded. That clearly isn't the case in my example as the TileSprite has loaded and been displayed, but the issue happens after the TileSprite has been destroyed (as if it is still trying to render it after it has been removed).
@goldfire Yes. Texture bound to the unit 0,1,2... is just one type of .Offscreen-For-WebG warnings.
This example that I showed no use texture: https://mdn.github.io/webgl-examples/tutorial/sample1/
Warnings: GL ERROR :GL_INVALID_ENUM : glTexImage2D: <- error from previous GL command GL ERROR :GL_INVALID_ENUM : GetIntegerv: <- error from previous GL command
Others: GL ERROR :GL_INVALID_ENUM : glBufferData: <- error from previous GL command GL ERROR :GL_INVALID_ENUM : GetShaderiv: <- error from previous GL command
To get error: console.log( gl.getError() ); //1280
1280 is the warning: GL ERROR :GL_INVALID_ENUM : GetIntegerv:
Errors list:
1280 GL_INVALID_ENUM // unsupported enum value to a GL function.
1281 GL_INVALID_VALUE
1282 GL_INVALID_OPERATION
1283 GL_STACK_OVERFLOW
1284 GL_STACK_UNDERFLOW
1285 GL_OUT_OF_MEMORY
@Gurigraphics Yes, but I don't see how you can just assume that the issue I've posted about here isn't an issue in Phaser. Even if it isn't strictly a Phaser issue, that doesn't mean there shouldn't be a fix for it in Phaser.
@goldfire This is simple to understand.
1- This issue is to Chrome or Firefox Engines because it does not occur in all computers and video cards. 2- Phaser and others frameworks not can nor need solve this because they not have low level code access. 3- "Hacks" and "Jerry riggs" is not fix.
I think that this issue can remain open to no create others.
Similar issues can be directed to Chrome https://bugs.chromium.org/p/chromium/issues/detail?id=653135
@Gurigraphics I'm sorry, but I simply don't agree with you at all. A specific action within Phaser causes this to happen. It doesn't matter that it only happens within certain browsers, it is still an issue that needs to be fixed.
Sometimes you need to use "hacks" to fix cross-browser issues. That is just a fact of life when working with the web. Regardless, without actually pinpointing what is causing this within Phaser, there's no way you can say that it requires a hack in the first place. It could just as easily be an issue where Phaser isn't cleaning up something correctly, etc.
@goldfire Ok. I also think you is unique supposing things here. I have already shown that this warnings happens with any framework. In my case, just "canvas.getContext (" webgl ")" already appears these warnings. And this is absolute proof that the problem is not Phaser and that they can not do anything about it. That's why I closed my issue topic.
But, you do not have to agree. If you think Phaser can or should resolve your warning, you have the right to believe whatever you want. Good hope for the "hack".
@Gurigraphics Maybe you haven't been doing development for very long, but has it ever occurred to you that warnings/errors can be caused by different things? This isn't a case of just loading up the game on specific hardware and the error being thrown. This is a case of performing a very specific action within Phaser that is causing an issue. Please stop hijacking this issue because you don't know how to solve your own issues.
Yes I'm Noob. Sorry for anything.
https://codepen.io/samme/pen/GRgwoLX