Jump to content

Rendering bug in WebGL


MonsieurPixel
 Share

Recommended Posts

Hi guys,

 

I've noticed a glitch when using the WebGL renderer with more than one 2048x2048 texture. This does not happen with the Canvas renderer.

 

From time to time, the whole spritesheet is printed out on the screen for like 1 frame.

 

In my code, everything worked fine as long as I only had one 2048x2048 spritesheet :

GameClip.assetsToLoader = [ "res/Spritesheet70_nocolor.json","res/gameFont.fnt"];

 

But when I added a background picture:

GameClip.assetsToLoader = [ "res/Spritesheet70_nocolor.json","res/gameFont.fnt", "res/background.jpeg"];

 

The glitch started to show. I already had this kind of glitch 15 days ago, but I "solved" it by reducing my sprites to make them fit on one spritesheet only : http://www.html5gamedevs.com/topic/7487-set-frame-rate/

 

Now that I want to add a parallax background, I have to solve this issue.

 

Any clue ?

 

Thanks,

Link to comment
Share on other sites

I just noticed that the glitch first appears on the screen when you jump on a foe's head. I then generate some particles to make an explosion. These particles are added to a PIXI.SpriteBatch.

 

As soon as I replaced:

particlesContainer = new PIXI.SpriteBatch();

 

By:

particlesContainer = new PIXI.DisplayObjectContainer();

 

The problem disappeared. So maybe there's an issue with the SpriteBatch or the way I use it...

Link to comment
Share on other sites

Hi, my game displays exactly the same issue with both PIXI version 1.5 and 1.6. When I first add a SpriteBatch to the stage in order to use it for rendering particles, if I am using the WebGL renderer my entire main texture atlas is drawn to the screen for one frame. (I should mention that my particle image is a separate png and not part of the atlas that flashes up) It happens so fast that only figured out that this was what the glitch actually was by using screen capture software and playing it back frame by frame! If I swap to either use the canvas renderer or a plain display object container the glitch goes away. The other graphics in my game are contained in two large texture atlases, one is 1930 x 2032 px, the other is 1791 x 1019 px.

I'm hoping somebody from GoodBoy will be able to fix this because I wouldn't have a clue where to start!  ;)

 

[Edit] - I added this as an issue on the pixi github page:

 

https://github.com/GoodBoyDigital/pixi.js/issues/864

Link to comment
Share on other sites

Hey guys - seems like I need to take a peek at the SpriteBatch class as it is causing a few issues. Its probably worth noting that regular display object containers are still really fast (they still use batching). SpriteBatch is really designed for things like particles ie 10000s of objects . Will let ya all know once the issue is sorted!

 

Cheers!

Link to comment
Share on other sites

Its probably worth noting that regular display object containers are still really fast (they still use batching). SpriteBatch is really designed for things like particles ie 10000s of objects . 

 

That's a very good point! My usage of sprite batch is probably a classic example of unnecessary pre-emptive optimization...

Thinking about it, the WebGL renderer is only really going to be used on desktops for my game and I don't particularly have any noticeable slow-down from the particles there. So I don't need to use the SpriteBatch anyway. I've switched to DisplayObjectContainer for the time being at least.

Thanks!

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...