Graphics glitches in fullscreen mode

cocos2d-x JavaScript
#1

Hello,

Up until Cocos2D HTML 2.2.0, I used my own fullscreen logic in my game, and things worked fine. However, with 2.2.1, a fullscreen API was added, and I thought I’d better use it. I wanted to use it to make my code simpler, and to ensure the fullscreen mode worked in native mode, not just in browser mode.

However, I’m seeing graphic issues with the Cocos fullscreen mode. I use sprite sheets for graphics, but when the fullscreen mode is enabled, sprite frames are not cut exactly properly, resulting in thin horizontal or vertical glitch lines.

See:
Game with custom fullscreen: http://stifu.fr/cc/Whip-A-Wimp1/
Game with Cocos fullscreen: http://stifu.fr/cc/Whip-A-Wimp2/
[Edit: screenshot here: http://www.cocos2d-x.org/attachments/3489/cocos_glitch.png]

With the 2nd version, you’ll see horizontal lines above the player head, for example, as you move around (use keyboard direction keys).

By the way, the game ensures all node positions are integer values, not float values, to avoid similar graphic issues (blurry sprites that I already mentioned here before).

So, I’d like to ask: what’s the recommended way to fix this problem, to make the Cocos fullscreen mode work with no such visual glitches? I thought of adding extra space around each sprite frame, in the sprite sheet, but I’d prefer something nicer.

Thanks.

#4

Have you tried upgrading to v2.2.2?

#5

Sebastián Vansteenkiste wrote:

Have you tried upgrading to v2.2.2?

Forgot to say, this is with 2.2.2. The links above use 2.2.2.

#6

Bumping this topic to make sure there is no solution to this problem, other than leaving extra space in the sprite sheets.

#7

Sorry Thomas,

In China, we have a famous “Great Fire Wall”, we do have technique to break through it. But even though… I can’t access to your website.
So can you post some screen caption?

BTW… Seems ovh hosted website can’t be accessed in China no matter how…

Huabin

#8

Hey Huabin,

Oh yeah, I remember reading about that OVH ban. Here’s a screenshot attached to this post. Thanks for having a look!

This is in a web browser, forcing canvas mode (renderMode:1), because I have too many visual glitches with the WebGL mode.

On the screen, you can see a line above the character head. The line actually comes from the sprite sheet, it’s the bottom of another frame, which should not be visible. I did not have this bug with my custom fullscreen code (which set the canvas CSS dimensions in JavaScript).

I do not know if it’s a Cocos or browser bug (bug happens with Chrome, Firefox and IE). I haven’t tried native mode (iPhone / Android) yet, so do not know if I’d have the same bug there.

On a related note, I’ve been experimenting with disabling anti-aliasing on the canvas, like this (in index.html):

        var disableAntiAliasing = function () {
            var ctx = document.getElementById('gameCanvas').getContext("2d");
            ctx.imageSmoothingEnabled = false;
            ctx.webkitImageSmoothingEnabled = false;
            ctx.mozImageSmoothingEnabled = false;
        };
        
        window.onload = function(event) {
            window.onresize = disableAntiAliasing;
            disableAntiAliasing();
            document.getElementById('gameCanvas').focus();
        }

Result:

  • Chrome: anti-aliasing disabled, visual glitch gone
  • Firefox: anti-aliasing disabled, visual glitch still here
  • IE: anti-aliasing still enabled, visual glitch still here
#9

Can you show us how you create your sprite frames from the sprite image, and how you create your sprite? So that it will be easier to locate the problem

Huabin

#10

The whole code is here: https://code.google.com/p/whip-a-wimp/

In particular:

player.js: https://code.google.com/p/whip-a-wimp/source/browse/src/player.js
animatedSprite.js: https://code.google.com/p/whip-a-wimp/source/browse/src/animatedSprite.js

The player class creates and passes rectangles to animatedSprite.
Then animatedSprite does cc.SpriteFrame.createWithTexture(texture, rect);

Note that this work perfectly (pixel perfect) when there is no zoom at all. I do not believe the problem comes from my code, but who knows.

Thanks.

#11

pandamicro wrote:

Can you show us how you create your sprite frames
…
Huabin

Please tell us where to upload the code for your easy access.

#12

Hi Don

We don’t have a host of code, but you can simply paste your code fragments in your comment.

@Stifu, I will check the code and find where is wrong.

#13

Thanks a lot for your time, Huabin.

Let me know if I can help. I could put the game on a different host that will hopefully work for you, for example.

#14

Hi, Stifu

The behavior is pretty strange, I checked our code of draw function in CCSprite.
context.drawImage(image, locTextureCoord.x, locTextureCoord.y, locTextureCoord.width, locTextureCoord.height, flipXOffset, flipYOffset, locDrawSizeCanvas.width, locDrawSizeCanvas.height);
When the glitches happens, the real value for this line is :
context.drawImage(image, 0, 96, 32, 48, 0, -420, 280, 420);

And (0, 96, 32, 48) is the correct value for cutting sprite from the texture.

Then I have done some test

In this image, context.drawImage(image, 0, 48, 32, 48, 0, 0, 280, 420); draws the first sprite with one real pixel on top of the head
context.drawImage(image, 0, 49, 32, 48, 280, 0, 280, 420); draws the second one, with one original pixel lost at the top and one original pixel plus at the bottom. And if you look closely, you can still see one real pixel above the head which shouldn’t be there
context.drawImage(image, 0, 48, 32, 49, 560, 0, 280, 420); draws the third one, which appears to be normal.

When I start to cover the image with white pixels, strange things happens. With the exact same rect, there always remains one pixel at the top.
Code I used was these lines:

context.fillRect(0, 0, 280, 420);
context.fillRect(280, 0, 280, 420);
context.fillRect(560, 0, 280, 420);

I think it’s a bug of browser in full screen mode. In the code of engine, we can’t do any thing about it. You mentioned that your own implementation of full screen doesn’t do the same thing, I wonder how? If it do work, I’m interest in the difference between our implementations. Thanks

Huabin

#15

Hi Huabin,

Thanks for spending time on this issue, and for all the details. I also think it’s a browser bug. As I said, the bug goes away with Chrome when disabling antialiasing, but this doesn’t work with other browsers. I guess we’ll add empty space in our sprite sheets to avoid this.

You mentioned that your own implementation of full screen doesn't do the same thing, I wonder how? If it do work, I'm interest in the difference between our implementations. Thanks

I simply set the canvas CSS size in the index.html file.
See the resize function: https://code.google.com/p/whip-a-wimp/source/browse/index.html?r=36eab9389f5f2ff565378a5ca22cff5cb6136d27

Thanks again.

#16

Everything we do is to improve our engine, so we should thank you guys to report us problems,:wink:
Indeed we haven’t used full-screen meta tag, I’ll give it a try also.

#17

More info about the visual glitch in Firefox: it’s caused by GPU acceleration. Disabling GPU acceleration not only fixes this bug, but also greatly improves performances on the computers I experimented on. (Again, this is in canvas mode.)

To disable GPU acceleration in Firefox, go to about:config, look for the gfx.direct2d.disabled flag, set it to true, then restart Firefox.

PS: off topic, but according to my tests, Chrome is slow without GPU acceleration and fast with it, but it’s the other way around for Firefox.

Edit: filed a Firefox bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=994122

#18

@Stifu wrote:

More info about the visual glitch in Firefox: it’s caused by GPU acceleration. Disabling GPU acceleration not only fixes this bug, but also greatly improves performances on the computers I experimented on. (Again, this is in canvas mode.)

To disable GPU acceleration in Firefox, go to about:config, look for the gfx.direct2d.disabled flag, set it to true, then restart Firefox.

PS: off topic, but according to my tests, Chrome is slow without GPU acceleration and fast with it, but it’s the other way around for Firefox.

Edit: filed a Firefox bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=994122

That’s indeed bizarre.

Thanks for keeping everyone posted!