Taz

Members
  • Content count

    57
  • Joined

  • Last visited

  1. You can make a 1x1 texture with generateCanvasTexture by changing your demo like this: var renderer = PIXI.autoDetectRenderer(256, 256); document.body.appendChild(renderer.view); var stage = new PIXI.Container(); var rect = new PIXI.Graphics(); rect.beginFill(0xFFFFFF, 1); rect.drawRect(0, 0, 1, 1); rect.endFill(); ////////////////////////////////////////////////////////////////////////////////////// var tex = rect.generateCanvasTexture(PIXI.SCALE_MODES.LINEAR, renderer.resolution); // ////////////////////////////////////////////////////////////////////////////////////// var s = new PIXI.Sprite(tex); s.width = s.height = 32; s.x = s.y = 128 - s.width / 2; stage.addChild(s); renderer.render(stage);
  2. Using the top left corner as the origin is common for 2D computer graphics, but you can convert the bounds like this: var bounds = sprite.getBounds(); bounds.x -= renderer.width / 2; bounds.y -= renderer.height / 2;
  3. Typically resolution is set to window.devicePixelRatio, which is 2 for retina 2X devices and 1 for 1X devices, and is 4 for a 2X device that is zoomed in 200%, for instance. Stage scaling is what's typically used to fit content to the window. You can also create small, medium, and large versions of your assets to reduce the amount of scaling needed. I added a frame rate monitor to the demo I posted and it stays at 60 fps except when the window is resized, etc., as expected, but it's just a couple of squares created with PIXI.Graphics. What images are you using? IDK what's dropping your frame rate to 15, but if you post more info/code I can try to help more.
  4. Here's a little demo for Pixi version 4.5.0 that I think does what you're after. The demo uses a blue background so you can see the "black bars" and there's a red square at the center of the demo.
  5. Hmm, you could also try redrawing less often using setInterval. There's probably a frequency where it isn't killing the frame rate but still looks smooth enough. Likely audio.currentTime gets updated less than 60 times per second anyway, so its display is being updated more often than it changes when tied to the rendering frame rate. Between that and only redrawing the parts that have changed color, the lag can be addressed IMO.
  6. Have you tried rotating the stage instead of the canvas? You can rotate the stage 90 degrees like this: app.stage.pivot.set(app.stage.width / 2, app.stage.height / 2); app.stage.rotation = Math.PI / 2;
  7. For going backwards, maybe set the color back to grey and draw from start of arc to current position (instead of from current position to end of arc). Or if you keep track of the last time value it could work like below I think. Something like this could work as a good starting point IMO, for optimizing and for supporting backwards movement: // initialize radiansPerSecond var radiansPerSecond = 2 * Math.PI / audio.duration; // initialize audio.lastTime audio.lastTime = 0; // before draw loop: if (audio.currentTime > audio.lastTime) { // needle is moving forwards graphics.lineStyle(7, 0xff0066, 1); var start = audio.lastTime * radiansPerSecond; var end = audio.currentTime * radiansPerSecond; } else if (audio.currentTime < audio.lastTime) { // needle is moving backwards baseGraphics.lineStyle(7, 0xB3B3B3, 1); var start = audio.currentTime * radiansPerSecond; var end = audio.lastTime * radiansPerSecond; } else { // needle is not moving return; } audio.lastTime = audio.currentTime; // inner draw loop if (start > points[i][a][1] || end < points[i][a][0]) { // arc doesn't need to be drawn, so continue to the next arc continue; } var arcStart = start; if (arcStart < points[i][a][0]) { arcStart = points[i][a][0]; } var arcEnd = end; if (arcEnd > points[i][a][1] { arcEnd = points[i][a][1]; } // then draw arc from arcStart to arcEnd, same as before
  8. You can get the first wedge to draw by moving the graphics.moveTo call so that it comes right before the graphics.arc call. The lag I think is from drawing each pink part each frame. Here's a possible solution to avoid redrawing: for each wedge, save the last drawn arc's end value as lastDrawEnd, which is initialized to the wedge's start. Then only draw an arc for the wedge if the wedge's lastDrawEnd is less than the wedge's end. When the arc is drawn, it starts at the wedge's lastDrawEnd and goes to arcEnd. After the arc is drawn, the wedge's lastDrawEnd is set equal to arcEnd. For this approach, it would work better IMO to make each wedge an object instead of an array, e.g. with properties start, end, lastDrawEnd. It's the drawing that's tanking the frame rate, but there's also little things you can do to make the loops faster, like (1) Move calculations that don't change so that they're outside of the loops (some can be outside of the animate function all together). (2) Keep everything in radians to rid the inner loop of conversions. (3) Cache point since it's used several times in the inner loop (4) Cache the array lengths
  9. Here's a way that to find the center that factors in the position and scale of the parent by applying the parent's transform: var bounds = shape.getBounds(); var center = new PIXI.Point(bounds.x + bounds.width / 2, bounds.y + bounds.height / 2); console.log(center.x + ", " + center.y); You can also get the shape's position from applying the parent transform like this (but I think you would still have to manually scale width & height to calculate shape's center point): var position = shape.parent.toGlobal(shape.position);
  10. If you want to avoid updating and drawing sprites that go off-camera, setting the sprite's visibility can achieve this. There's still some extra processing to loop through and call render and check this.visible for each sprite, but the invisible sprites' transforms aren't updated and they aren't drawn either. So this can sometimes perform better than adding to and removing from the stage, for instance if the sprites are going on and off camera quickly and repeatedly, back and forth. On the other hand, sometimes adding to and removing from the stage can perform better, for instance if the sprites are moving on and off camera infrequently. You can also try combining both methods, for example when the sprite first goes off camera set sprite.visible to false. Then if it comes back into the camera's view soon, just set sprite.visible back to true. But if it stays off camera too long, then remove it from the stage. And grouping the sprites into containers can sometimes boost performance too. For instance, if several sprites always move on and off camera at about the same time, then you can reduce the amount of add/remove processing by adding/removing the whole container at once, instead of performing a separate add/remove for each sprite. And if a container is invisible, then its children aren't processed, so grouping can reduce the amount of invisible elements that need to be processed/checked.
  11. If you can group the sprites into containers, one per area for instance, you can reduce the amount of add/remove calls that way. Also, have you tried setting sprite.visible to true/false instead of adding/removing from stage?
  12. These two steps fix the second shape, which now gets filled and works with containsPoint 1. Change graphics.beginFill and graphics.endFill to graphics2.beginFill and graphics2.endFill 2. Move graphics2.beginFill to before graphics2.moveTo var graphics2 = new PIXI.Graphics(); graphics2.lineStyle(1, 0xFFFFFF, 1); graphics2.beginFill(0x999999, 1); graphics2.moveTo(120, 10); graphics2.bezierCurveTo(130, 0, 130, 0, 200, 10); graphics2.bezierCurveTo(250, 100, 250, 100, 120, 200); graphics2.bezierCurveTo(130, 0, 130, 0, 120, 10); //graphics2.currentPath.shape.closed = true; graphics2.endFill(); viewerStage.addChild(graphics2);
  13. Setting interactive to true and handling the event should be enough. Can you post the code that isn't working or a CodePen or JSFiddle? It's hard to guess what's wrong otherwise. Also some interactivity issues have been addressed since v4.3.4, so it's probably good to stay up to date.
  14. If you're drawing the canvas at the proper size, then scaling the sprite shouldn't be required IMO.
  15. Yeah fromCanvas should work too. But they did (do?) cache differently and take different parameter options, so you might need to use the constructors instead sometimes. But I'm not sure if you'll run into this, and it might be easier to start with fromCanvas and see when it works for you. And actually, I'm not sure that the textures need to be explicitly destroyed, either. I tend to guess it's better to free up resources sooner than later, but I haven't seen it used in the examples nor explicitly called for in the docs, so I'm not sure.