• Content Count

  • Joined

  • Last visited

  1. There was an option added to the dev branch a few days ago that turns off the multitexture batching. Try calling your renderer with the "legacy" option: renderer = new PIXI.WebGLRenderer(width, height, {legacy:true});
  2. It's up to the browser when garbage collection runs and when memory needs to be freed up. Chrome in particular will hold on to a lot of idle memory just in case it needs it later. Are you seeing performance problems?
  3. This is in a web browser? Are you creating multiple rendering contexts and multiple canvases on one page? That's the part I don't understand. If each object is using the same sprite sheet, could you load the texture once, in a global scope or as a static member of your class, and then each object could create a sprite referencing that one texture? In any case, yes, each Loader instance will only callback once without being reset.
  4. PIXI.loader is just a default convenience instance of PIXI.loaders.Loader, it's intended to be single use, one callback and it's done. Maybe you could instantiate a new one each time to do what you're trying to do? I can't exactly tell what you're doing, but it looks like a pretty unusual setup.
  5. Wait, so right now you're manipulating the WebGL context yourself to load shaders, and you just want to know how to use PIXI's interface for that instead? Is this just going over my head? I'm not even smart enough to configure Node.js. Pixi exposes shaders through the PIXI.Filter class. // use a custom shader and then the included Blur extension for this thing var filters = []; filters.push(new PIXI.Filter("Vertex GLSL Source", "Fragment GLSL Source")); filters.push(new PIXI.filters.BlurFilter()); PixiRenderableThing.filters = filters; PixiRenderableThing.filters[0].uniforms.sweet = true; PixiRenderableThing.filters[0].uniforms.sour = false; PixiRenderableThing.filters[1].blur = 7; renderer.render(PixiRenderableThing);
  6. It says that a filter is trying to multi-texture something with more than 16 textures at once, which is too many, and that the filter wasn't loaded. Are you using custom filters / shaders, or doing something weird to a filter? If you click the arrow next to "Pixi.js Error" you can probably see where the problem is coming from.
  7. Can you give an example, or describe the result you're seeing?
  8. It's probably reloading them each time, the fromImage methods aren't intended for that. Access your loaded frames like this: sprite.texture = loader.resources["animation.json"].textures["walkcycle1"] Using spritesheets is more efficient because if you draw ten things in a row from the same spritesheet, the texture is only being loaded to the GPU once. It's slower to load a lot of small textures one at a time.
  9. Using mipmapping on repeating textures in GL is the cause of those seams, that's why it only shows up when you scale. The explanation is here, scroll down to "Mipmapping Texture Atlases". It can be covered up with tricks like that "extrude" option, but the only way to fix it completely is to turn off hardware mipmapping.
  10. Wow, you guys aren't messing around! Thanks! If anyone else is confused, like I was at first, you now need to keep drawing your vector graphics past the edge of the view, and the off-screen pixels will be pulled into the blur before they're clipped off. No more bleeding edges.
  11. Hi. Setting filter padding follows the same behavior as drawing on the opposite edge - it only fixes the problem if the renderer is set to a Po2. In this example, setting the padding to 100 makes the problem disappear, and setting the renderer width to 255 or 257 makes it come back. I noticed that it was randomly working on some frames, and it turned out that was when the drawing happened to be a Po2 across. I did look through the source code for a while to see if there was a simple GL parameter that I could override or something, and went through all the properties and methods in the Chrome console, but no luck.
  12. When I apply a blur filter, the blurred image doesn't quite seem to clamp to the edge of the view. You can see the background color on the right edge here. I've tested this with the latest v4 dev, and the rc3, with Chrome and Firefox on Win7, and with Android Chrome. var renderer = PIXI.autoDetectRenderer(256, 256,{backgroundColor : 0x888888}); document.body.appendChild(renderer.view); var test = new PIXI.Graphics(); test.filters = [new PIXI.filters.BlurFilter(32,10,1)]; test.beginFill(0x000000, 1); test.drawCircle(175,128,100); renderer.render(test); Using image sprites instead of vector graphics doesn't seem to make a difference, neither does putting it in a container. The effect isn't consistent, it pops in and out based on what I draw. It seems to disappear if the total area being filtered is a power of two? For example, in this case, adding a single completely transparent pixel on the left edge fixes the problem. But if the renderer is set to width 257 instead of 256, the problem returns. (Now the black is bleeding out, but from what I understand that's the expected result from GL_CLAMP_TO_EDGE.) testg.beginFill(0x000000, 0); testg.drawRect(0,0,1,1); What I'm trying to do is create full screen masks for TilingSprites. I use a Perlin Noise library to draw a low-res vector mask on a RenderTexture, and use the blur filter to feather it and hide the jagged edges. This is the only approach I could find that's fast enough to draw the full view every frame. Making the RenderTexture ~50 pixels larger then the view hides the problem, but that seems inefficient, especially for several layers of this, right? So is this a bug, or is there something I should be doing differently?