Rob Gordon

  • Content Count

  • Joined

  • Last visited

About Rob Gordon

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Good to know! Is that a 5.4 feature or a v6 feature?
  2. This is really more of a comment than a question since I needed a solution for version-controlling a spritesheet and couldn't see a straightforward way of doing it. To version-control the json file, I do this: var file = [{name:"ui", url:"ui.json?v=1"}] Now, the PIXI Loader will automatically load the image file and internally append "_image" to its name...but it will *not* carry over the "?v=1" part to the url. A solution to this problem is to use the 'pre' middleware to modify the url of the file, as follows: Loader .add(file) .pre(preProcessor) .load(); function preProcessor(resource, next) { if ( == "ui_image") { resource.url = resource.url.split("?")[0] + "?v=1"; } next(); } I'll leave this here for further comment or as an example of a working solution to this kind of problem.
  3. Just adding a quick note that this has now been addressed in the PIXI source code:
  4. I know this has come up in the past...but is there a 'best-practice' implementation of a Howler integration with PIXI v5 (including integration with the loader) that anyone can share? The few hits I see in the forum are a bit outdated. I have already (successfully) used pixi-sound...just want to compare... Cheers!
  5. Thanks Ivan - good luck with the release!
  6. Understood - though this is the kind of thing that should probably be reflected in the documentation (RenderTexture is a major feature, imo). Do you know if this is slated for the upcoming 5.3.0 release? I would think having parity between WebGL & Canvas would be critical. Anything you can share from your custom implementation? Is it as simple as removing the check for this.renderingToScreen, or will that break things?
  7. There appears to be an issue with clearing the context when rendering a container to a RenderTexture while using the CanvasRenderer (PIXI-legacy v5.2.4). Consider this example: Click anywhere to toggle the visibility of one of the bunnies. Using the CanvasRenderer the context is not cleared, and the bunnies remain visible. Using the WebGL renderer (switch forceCanvas to false) this works as expected. I believe the issue may be here: if (clear !== undefined ? clear : this.clearBeforeRender) { if (this.renderingToScreen) { if (this.transparent) { context.clearRect(0, 0, this.width, this.height); } else { context.fillStyle = this._backgroundColorString; context.fillRect(0, 0, this.width, this.height); } } // else { // TODO: implement background for CanvasRenderTarget or RenderTexture? // } } The 'TODO' needs to get done. It appears there is no context management for the case where we are not renderingToScreen (as I believe is the case when we are rendering a Container to a RenderTexture). ** I've posted this to the github issues, but thought it might make sense to post it here as well to ensure that this isn't an error of understanding or implementation on my part...
  8. Thanks Ivan. I've cooked up a solution that works well enough for now and I wouldn't want you to waste time (rather save that for when I'm really stuck!). Here's what I'm presently doing: renderTextureSprite = new PIXI.Sprite(PIXI.RenderTexture.create({width:mywidth, height:myheight, resolution:myresolution})); ...then for each sprite I create a shadow (copy of the sprite, tinted black, alpha of 0.4, blur filter applied) and render it: renderer.render(shadow, renderTextureSprite.texture, false); ... and then render the sprite: renderer.render(sprite, renderTextureSprite.texture, false); The advantage is that I can spread the work out and show a progress bar along the way. I'm happy to hear other ideas for how to do this (and learn more about PIXI), but for the moment this is working nicely.
  9. BTW - I can confirm that the performance of doing a manual renderTexture with the DropShadow filter applied is awful. Switching to using twice as many sprites with every other one being essentially a blurred black-tinted copy of its neighbour is considerably better. Since Blur and DropShadow are rather similar it seems what we really need is a performance DropShadow filter (preferably build into PIXI). Still hopeful there's a better way... UPDATE: just realized you can build up a renderTexture progressively by passing false as the 3rd parameter. I think that may be the answer...t least I can spread the work over a number of ticks/frames...
  10. >> Setting cacheAsBitmap to true for the container is considerably faster > It looks like cacheAsBitmap is also using a renderTexture for this operation. When I do this that way directly the operation is quite slow. Why would this be? >> Some of these things are known issues (though the filter rendering problem feels like a bug of cacheAsBitmap). >We fixed it sooo many times, maybe it actually works now, try I'm using v5.2.3, Is there something newer? > Is there a better approach here? >>Yes, but it depends on your case. I know many tricks for advanced users >>DropShadow is very slow, Blur is faster of course and I usually use DropShadow based on blur. Well...none of the sprite are interactive or animated. It's really just a complex background image made up of 100s of individual pieces - each requiring a dropshadow. I could build it up progressively in canvas - but would prefer to keep it all within PIXI if I can. Cheers!
  11. I have a Container with ~700 sprites in it, each with a filter applied (I have tried both dropShadow and blur). Obviously that's too many to render on stage. Creating a renderTexture works perfectly - but it's a very slow process to create it, and I worry about the impact on lower-end mobile devices. Setting cacheAsBitmap to true for the container is considerably faster - but doesn't seem to support either the dropShadow or blur filters that are applied to the individual sprites. Some of these things are known issues (though the filter rendering problem feels like a bug of cacheAsBitmap). Is there a better approach here?
  12. Right. Don't generally need that (but I can see how it can come up for others).
  13. I may have just answered my own question. It seems the InteractionManager doesn't NEED PIXI.Ticker.system, but can send it events and is set up by default to do so. You can do this to shut that down: app.renderer.plugins.interaction.useSystemTicker = false
  14. Greetings, I'm trying to understand what PIXI.Ticker.system actually does. I have experimented with doing the following after initializing my application: PIXI.Ticker.system.autoStart = false; PIXI.Ticker.system.stop(); The result is much less energy use (as measured by the Activity Monitor in OSX) and no change in the functionality of the application. The docs mention it's used by PIXI.interaction.InteractionManager (which I use a lot), but all my functionality is intact. FYI, I'm also stopping the shared Ticker and just using app.ticker for everything at maxFPS of 30. Thanks, r o b