Jump to content

patrickfabrizius

Members
  • Content Count

    17
  • Joined

  • Last visited

  1. Since this is still one of the most relevant hits on Google, I figured I'd share the trick I ended up using, in case someone else end up here (just as I did, looking for a solution). var radius = 20; // Create "intermediary" container for graphics var gContainer = new PIXI.Container(); stage.addChild(gContainer); var myCircle = new PIXI.Graphics(); gContainer.addChild(myCircle); // Draw graphic x2 size myCircle.beginFill(0xFF0000); myCircle.drawCircle(0, 0, radius * 2); // Use cacheAsBitmap to render bitmap gContainer.cacheAsBitmap = true; // Scale down (the bitmap) to get smooth ed
  2. Hi! Just upgraded my project to PIXI 4, and noticed that all assets are displayed at 200% on regular (non-retina) resolution devices. The problem seems to be that PIXI now reads and uses the "scale" meta key. From how Texturepacker seems to use the scale value, it seems logical that "scale" differs between the hi-res and lo-res texturepacks, but at the same time I doubt that this is a bug in PIXI? So, could anyone explain the rationale behind this (and point me in the right direction if my Texturepacker settings are invalid). Thanks!
  3. Thanks, will continue testing, works like a charm thus far. My problem is that I prep the view (create sprites etc) and then instantly init my animations. I have a requestAnimationFrame-dependent animation module that counts ticks since last call, and animate accordingly (so that animations run for the same amount of time regardless of FPS). The first requestAnimationFrame after the animation has been created has a high tick-value (in some cases up to 500ms because everything is frozen due to rendering), thus an animation with a duration of say 1000 ms could start animating from the m
  4. Thanks guys! Ok, so (simplified), instead of: container.addChild(mySprite); startAnimations(); I should be able to do something like: container.addChild(mySprite); requestAnimationFrame(() => { startAnimations() }); And the startAnimations() method would run first after everything is up and ready? I tried it, and it seems to work. Just worried that requestAnimationFrame in some odd cases would find an available frame before the PIXI internals are completed, but it should be safe you think? The other method looks interesting, but only seems to apply to the GL ren
  5. Hi! Is there a way to know when a container is fully rendered? I often trigger animations after setting up a view (container with sprites, text, rects etc) but on slower computers the animations are sometimes half-way done before the actual view is rendered. I use PIXI.loader with a progress that waits for all assets to load, so everything should be in memory. Not sure if the delay is because some textures are not fully stored in memory or if it's the actual rendering of sprites. I have looked at container.renderable, container.worldVisible, sprite.texture.baseTexture.isLoadin
  6. Could you be more specific as to what doesn't work, any devices in particular, etc?
  7. Which version of PIXI & Ejecta was that? It doesn't work for me with Ejecta 2.0 and PIXI 3.0.2. (For CanvasRenderer it breaks with TypeError: this.interactionDOMElement.addEventListener is not a function and for GLRenderer I get TypeError: this.view.addEventListener is not a function.)
  8. Ok .. I did use the convenience methods at first, then tried directly from the loader resources, but as I said before there was actually a noticeable penalty (which, given what you said, would indicate I must have done something else wrong ) Here is an excerpt from the code, I had to rewrite it a bit in order to not flood this post .. It should be all the relevant parts, I hope. // Game.js (main)module.exports = function() { var exports = {}; var state; var loader = require("./loader.js"); exports.init = function() { state = "loading"; // Usual PIXI init stuff here - crea
  9. Ok, thanks! Hm ... But what about when sprites are drawn the first time? I have a 1024 x 1024 view with a full view background image, and about 5 movieclips that are ~300 x 300 with 20 - 40 frames each, loaded from a spritesheet manually. When running at resolution = 2 (thus consequently loading high-res assets instead with twice the width / height) I get a significant delay. When leaving a view I destroy all sprites. Even so, next time I draw the same view it is almost instant. I can live with a delay but would rather have a longer load time than having delays during the game. Any ideas
  10. Ok! Ok. Ok, just so I get this right - baseTexture would be the whole spritesheet? So, less spritesheets the better? The reason I'm asking is that I have several views and in that case it would make more sense to gather all the assets for each view in a single spritesheet, right? Ok! Thanks for your elaborate answer! Maybe I misunderstood the docs, I am using the loader to pre-fetch everything so that the game runs smoothly, but I don't create all sprites or textures in the loader. Instead I create sprites as I go, and wouldn't want the game to perform a network operation to fetc
  11. Are there any limits for canvas then (other than system memory)? Thanks, I've looked at those stats and 99.4% support for 4096 seems like a good baseline, I was more thinking in terms of best practice here, if (in your experience) one should settle for 2048 (or even less)? I meant if there's a difference using 10 different textures from 10 different sources (10 images or 10 spritesheets), compared to 10 different textures from a single spritesheet? Does PIXI just crop out the asset into RAM, or does it reference the whole spritesheet when it needs access to it? Ok, thanks!
×
×
  • Create New...