xerver

Members
  • Content count

    1,532
  • Joined

  • Last visited

  • Days Won

    12

xerver last won the day on September 16 2016

xerver had the most liked content!

5 Followers

About xerver

  • Rank
    Pixi.js Moderator

Contact Methods

  • Website URL
    http://github.com/englercj
  • Twitter
    rolnaaba

Profile Information

  • Gender
    Male
  • Location
    USA

Recent Profile Visitors

2,373 profile views
  1. 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
  2. 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).
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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"); }); };
  8. Have you profiled it to determine what is eating the CPU?
  9. 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.
  10. 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.
  11. Electron uses something similar called asar that works pretty well. I think it would be cool to see something like that in browserland (but optimized for network). https://github.com/electron/asar
  12. PIXI loader doesn't recognize pictures?

    You can just assign the baseUrl property before adding resources, you don't have to create a new loader. fromImage is working here but the image is loaded asynchronously. Which means you won't know the size until later after the image has loaded. There are events you can listen to, but it is honestly easier and more robust to use the loader than it is to use the fromX() methods.
  13. Extending Sprite Class

    Unfortunately it is not. If you assign the prototype object (like happens in the line above) then .prototype.constructor will not be properly set. Normal usage you wouldn't notice because the new operator would work fine. However if you ever needed to read the constructor value from an instance (which I have had to do) it would be wrong if the person extending the prototype didn't reset it properly. Take for example a scenario where you need to create a new instance from an existing one. You could do something like: (var obj = new otherInstance.constructor()) which would obviously create the wrong instance unless you set it up properly. Also some debugging utilities read the .constructor property and will pull the wrong one if it isn't set. You don't *have* to reset it back to a correct value, but it is good practice because not doing so might lead to unexpected behavior down the line. The extend keyword does this for you in ES6. A quick correction here, setting the .constructor prototype property does not effect how the new operator works. `new` simply will run the function you specify as a constructor.
  14. baseTexture from loader alias

    Yup, sorry about that; I'll edit my original post.
  15. baseTexture from loader alias

    No need to use fromX methods, just use the resources the loader made for you: PIXI.loader.add("sprites", "sprites.png"); PIXI.loader.load(function () { const baseTexture = PIXI.loader.resources.sprites.texture.baseTexture; // loader made you a base texture, no need to create your own. }); Additionally, don't do "new PIXI.BaseTexture.fromX()" the from methods are not a constructor. Either do "new PIXI.BaseTexture()" or do "PIXI.BaseTexture.from()" or (my preference) do neither and just use the one the loader made for you.