stupot

Members
  • Content count

    215
  • Joined

  • Last visited

About stupot

  • Rank
    Advanced Member

Recent Profile Visitors

1,231 profile views
  1. Thanks for the update samme. My local fixed setTexturePriority() allows non-image components to be specified, thus allowing a wider range of things with textures to be added. It's a few commits behind now but I could update it and check in? I got my whole game down to 1 draw (I think) and it ran slower, probably something to do with issue #198, so didn't pursue the mutitexture route any further.
  2. or build phaser yourself and exclude all the parts you don't need
  3. The tween manager doesn't do an update when between chains. Try this Phaser.TweenManager.prototype.update = function () { var addTweens = this._add.length; var numTweens = this._tweens.length; if (numTweens === 0 && addTweens === 0) { return false; } var i = 0; while (i < numTweens) { if (this._tweens[i].update(this.game.time.time)) { i++; } else { this._tweens.splice(i, 1); numTweens--; } } addTweens = this._add.length; // stumod, process all new tweens now // If there are any new tweens to be added, do so now - otherwise they can be spliced out of the array before ever running if (addTweens > 0) { this._tweens = this._tweens.concat(this._add); this._add.length = 0; } return true; }
  4. Just upgraded to 2.7.3 and thought I'd try out multi-texture. It appeared to work (less draw calls) but I noticed the following: The setTexturePriority() accepts an array of keys and checks only the image cache for matches. I wanted to include some rendertarget and text textures. I was able to manualy set the textureIndex property of those textures and the draw count dropped accordingly, so that appeared to work. Is there any reason why setTexturePriority() doesn't allow a wider variety of targets? The docs say to clear out the multi-texture settings by passing in an empty array to setTexturePriority(), which doesn't do anything. It wrongly references 'index' instead of 'i', to reset the texturePriority of the textureNameCollection[] list. A[art from this fault, I'm thinking that this should really be clearing every texturePriority to include any manualy set ones, not just the ones remembered from the last setTexturePriority() call. What's the thinking on this?
  5. Try finishing off your context drawing with a closePath()
  6. Try just drawing the world instead of the stage to your rendertexture to fix the upside down problem.
  7. Check your network tab in the console for any traffic during runtime, if there is none then the two setups 'should' be equal. If' you're using a live reload system then that'll still be hammering the network even though the game assetts are loaded, and will cause stuttering.
  8. Phaser's AUTO logic goes - if WebGL available use that, else use Canvas. Browser performace depends on many variables, the device itself being the biggest factor. I've seen mobile browsers unable to push half as many pixels in landscape as they can in portrait. I've seen browsers perform the best in webgl at low resolution, then perform better in canvas at higher resolutions. Deciding on canvas/webgl mode based on it being a desktop browser might just seem right given the number of devices you've tested on, but in the real world it's different and forever changing. If you can afford a bit of a delay on startup, then benchmark the device in both modes at the resolution and orientation you want to run at, and use that to decide. ps. Phaser has a built in 'Phaser.Device.desktop' that you can use to determine which mode to set Phaser into (and a load of other useful ones ios/android/iphone/opad etc). There are other libs that specialise in determining the browser spec.
  9. Skeptron is right that it's quite a task. Be prepared to rewrite it as you go as you work out better ways of doing things. You might even end up parting with cash to pay for decent server space. If you do go down this route, then you'll learn a lot.
  10. You'll have to do something like this. It'll works with 2.7.3 and before. if (typeof winEmitter.gravity == "number" )) { winEmitter.gravity = 200; } else { winEmitter.gravity.set(0, 200); }
  11. Try different versions of Phaser, see if you can find a working one, that might help pinpoint the problem
  12. look in the browser console for any problem logging
  13. If you run any logic in the client that affects outcomes, then players will hack and exploit that, so keep the important things server side. The server should be recieving player movement requests, updating it's view of the world, including running the logic of the collisions, then updating the clients view. The client could be allowed to do a little prediction to help with visual smoothness. You could investigate getting Phaser running in headless mode in node, I'm not sure if this was ever maintained/completed. Also checkout Phanton.js, it's a browser emulator, could be the quickest way of getting Phaser running in nodejs. Failing that, you don't have to use Phaser's physics, you could find another Physics engine that runs server side.
  14. Here we go, this may or may not have the same reason why you are experincing this, but it's reproducible. It's a browser warning in the console. When the warning is displayed, the draw operation appears to have worked. This code (typed into console with Phaser running, note that what everybody else calls 'game' I call 'mpg, so adjust as necessary), works without warnings: var rtBG = mpg.add.renderTexture(1024, 1024, 'rtBG'); rtBG.renderRawXY(mpg.world, 0, 0); var imgRTBG = mpg.add.image(0, 0, rtBG); Where as this code, with 2nd and 3rd lines swapped, produces the warning: var rtBG = mpg.add.renderTexture(1024, 1024, 'rtBG'); var imgRTBG = mpg.add.image(0, 0, rtBG); rtBG.renderRawXY(mpg.world, 0, 0); Here's the console log for the warning:
  15. I've had this in v2.6.2 the other day, can't remember exactly what I was doing but I was comparing bitmapData and renderTexture functionality.