• 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,755 profile views
  1. pixi js documentation crashed???

    Should be back up now, sorry about that!
  2. 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.
  3. We upload the texture to the GPU, we never draw to your canvas or even open a context on it.
  4. 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
  5. Show fps on screen

    Time your animation loop and display it anyway you want. stats.js is good for this.
  6. 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
  7. 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).
  8. 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.
  9. loading textures > sprites in a loop

    You can't do that in HTML5 (in a portable way). You should have a list of the files to load, then load them. Loading until a failure is possible, but not recommended because it would be so slow. If you are loading files in sequence until one fails it will take a *very* long time, and you can't parallelize. Instead, just build you application with the number of files known already. Or request a manifest file first that details what files to load, then load all of those files at once. By the way, this has nothing to do with pixi; just the nature of high-latency loads. I wouldn't do what you are describing on disk either, I would load a manifest that told me explicitly what to load. That way I can parallelize. The pixi loader does a good job of saturating network request threads when loading multiple objects, without overloading and slowing everything down. It also allows you to configure the concurrency if you want.
  10. Remember to call reset before calling .load() a second time on the same instance of a loader. Usually it is best to .add() all the resources you want to load, then call .load() once. Then reset and load again if you need to load another batch of resources. Calling add/load/reset for each resource is not going to work well.
  11. The only reason anything would stop in the background is the browser stops it. Since the event loop is controlled by the user in Pixi, we don't (and shouldn't) touch what your event loop does at any time.
  12. CreateSprite2D(spriteName, filename) { console.log("loading"); PIXI.loader.add(spriteName, filename).load((loader, resources) => { var texture = resources[spriteName].texture; console.log(texture); this.sprites2D[spriteName] = new PIXI.Sprite(texture); this.textures2D[spriteName] = texture; console.log("loaded"); }); };
  13. Have you profiled it to determine what is eating the CPU?
  14. We just echo the events the browser sends, so our behavior will match your browser's. Specifically for "tap" we send the event on touchend. There is no timing of how long the touch lasted.
  15. Use raw WebGL texture as sprite

    Note that you cannot share GLTextures between contexts. If you create a texture using a context it will not work if you try to render it with a different context.