• Content count

  • Joined

  • Last visited

  • Days Won


xerver last won the day on September 16 2016

xerver had the most liked content!


About xerver

  • Rank
    Pixi.js Moderator

Contact Methods

  • Website URL
  • Twitter

Profile Information

  • Gender
  • Location

Recent Profile Visitors

2,900 profile views
  1. xerver

    Why the ticker is not redrawing the stage?

    All the ticker does is run the function you give it on some interval. To render the scene you need to create a renderer and call the render method on it, passing in the scene you wish to render. Application does this for you. I'd expect your OP to render a circle that does not move. Is that what you get?
  2. xerver

    help with splitting an application

    You added a resource to a loader that was already running, as the error states.
  3. xerver

    PIXI loader error (loader is running)

    Video on mobile is weird, you can't load/play video until the user interacts with the page. I have no idea what the issue is without debugging it live, and I don't own any of those devices If you figure it out, feel free to open an issue!
  4. xerver

    PIXI loader error (loader is running)

    Keep in mind that the .fromX() methods in PIXI do not use the resource-loader library.
  5. xerver

    PIXI loader error (loader is running)

    Not what you mean "they don't have a loader"? Resource-loader supports loading audio/video, and you can pass an array of urls that will each be added as sources. You can also pass an array of parallel mimeTypes to `metadata.mimeType` so that each URL has a mime associated. You can even create and prepare your own <video/> element if you have some complex setup that is required and pass it into the loader as `metadata.loadElement` and set `metadata.skipSource` to true so it just tracks the loading of the element and doesn't create a new one. The event that resource-loader waits for is the `load` or `canplaythrough` event, whichever comes first.
  6. xerver

    PIXI loader error (loader is running)

    Even once loading is complete, you must call reset() before starting a new load. Each loader is really meant to be a one-time-use object, where it collects resources, loads them, then the lifetime ends. The reset() method is there for you to be able to use a single instance again rather than allocating a new one. It is best if you think of the lifetime of a loader as over as soon as it completes a load, with reset() acting as a "revive" that brings the loader back to life for another use. It is a state machine that only marches forward, and can restart if you explicitly tell it to.
  7. xerver

    PIXI loader error (loader is running)

    If you are in the process of loading any resources, you must specify a parentResource for any resources you add in (usually these are adding via a middleware). Otherwise, loading a new root resource during an active load is an error. You will need to call .reset() before you can add root resources again. If there is active loading then reset will abort all active loading and reset the loader to be used for new resources.
  8. xerver

    pixi js documentation crashed???

    Should be back up now, sorry about that!
  9. xerver

    PIXI Loader handling failed loads

    Depends on the asset. For example, if you need to load a map; and it fails, you can't play the game. Generally what I've done in the past is catch all asset errors and if the errors were ones that a retry might fix (like a timeout, or 503, or some such) then retry those at the end. If I get a fatal error like a 404, I just show an error to the user and exit.
  10. We upload the texture to the GPU, we never draw to your canvas or even open a context on it.
  11. It works fine when you call sprite.update(). You just forgot to clear your canvas when you drew to the canvas in your lightenGradient function. Working pen: https://codepen.io/anon/pen/mxyezY
  12. xerver

    Show fps on screen

    Time your animation loop and display it anyway you want. stats.js is good for this.
  13. Not sure why innerWidth/innerHeight would be wrong (I'm not a mobile dev), but I would recommend not using innerWidth/innerHeight anyway (see #3 here: https://webglfundamentals.org/webgl/lessons/webgl-anti-patterns.html) Maybe try this: Ensure autoResize is set to `false` Use CSS to style the canvas to 100% width/height (remember to make html/body/canvas parent have 100% height too) Call renderer.resize() with the values of canvas.clientWidth and canvas.clientHeight
  14. I did something similar in the past when I was first learning what it meant to make games on the web. https://github.com/grapefruitjs/grapefruit There are a lot of old patterns there, and some code I'm not proud of. But it was a good start towards a 2D game engine based on Pixi for me. I don't have any tutorials, because I learn better from reading/writing code rather than words but hopefully you find this helpful (remember this was 4-5 years ago before webpack, gulp, etc).
  15. xerver

    loading textures > sprites in a loop

    Nothing, this has nothing to do with pixi. Pixi can load files if you tell it to, that is all it does. I was suggesting you create one with your build process, then write code that reads it and loads the appropriate files. Pixi is just a renderer, I think you are expecting it to do too much No, it is not synchronous. We synchronously create the JS object and asynchronously load the image in the background. Then once the image loads we upload it to the GPU. This is why you will get a blank image if you render it before the image loads, and may even get errors if you try to use it in size calculations before it loads. You can listen for events on the BaseTexture for when the underlying image has loaded or failed to load. Not counting synchronous XHR (which is deprecated on the main thread) there are no networking operations from JS that are synchronous. If you are basing your loops termination condition on whether or not the previous load failed you can't move to the next iteration of the loop util the previous one succeeds. The loads still happen asynchronously, but the load is serial not parallel. Which was my point. Examples below. ---------------------- OPTION 1 - Known number, asynchronous loads, parallel This loads async but without listening to events on each texture individually, and tracking the number loaded you don't know when they are loaded. This may not matter to your app though, so this is pretty simple: // creates textures synchronously so you can use them immediately, but the // textures will pop in asynchronously as they load. var textures = []; for (var i = 0; i < 30; ++i) // I know there are 30 { textures.push(PIXI.Texture.fromImage('resources/img-' + i + '.png')); } // use textures OPTION 2 - Unknown number, asynchronous loads, serial This is what you are suggesting, loading the next one only if the previous succeeded. This means you have to wait for previous loads before you can use textures. As you can see this can get pretty complex, and this is just a naive thing I wrote in like 30 seconds: // creates textures asynchronously, because we don't know when to stop making them. function loadTex(url, cb) { var tx = PIXI.Texture.fromImage(url); if (tx.baseTexture.complete) { cb(null, tx); } else { var onload = function () { tx.baseTexture.removeListener('loaded', onload); tx.baseTexture.removeListener('error', onerror); cb(null, tx); }; var onerror = function () { tx.baseTexture.removeListener('loaded', onload); tx.baseTexture.removeListener('error', onerror); cb(new Error('Failed to load: ' + url); }; tx.baseTexture.on('loaded', onload); tx.baseTexture.on('error', onerror); } } function loadUntilFail(i, cb, _textures) { i = i || 0; _textures = _textures || []; loadTex('resources/img-' + i + '.png', function (err, tx) { if (err) { cb(_textures); } else { _textures.push(tx); loadUtilFail(++i, cb); } }); } loadUntilFail(0, function (textures) { // got textures, phew now we can use them! }); OPTION 3 - Known number, asynchronous loads, parallel Ideally you just use the loader to load the textures you know you want, that way you know they are loaded when you use them (problem in #1) and you can load them parallelized (problem in #2): for (var i = 0; i < 30; ++i) // I know there are 30 { PIXI.loader.add('texture-' + i, 'resources/img-' + i + '.png'); } PIXI.loader.load(function () { // at this point i know it is loaded and they loaded about as fast as possible. var sprite = new Sprite(PIXI.loader.resources['texture-0'].texture); }); The loader that Pixi exposes is just an instance of resource-loader with some helpful Pixi middleware tacked on. fromImage does not use the loader. That method is a shortcut helper for creating a new Image() object, assigning the .src property and creating a texture from the new Image() object. That is basically all it does.