stupot

Members
  • Content count

    213
  • Joined

  • Last visited

About stupot

  • Rank
    Advanced Member

Recent Profile Visitors

1,099 profile views
  1. 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; }
  2. 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?
  3. Try finishing off your context drawing with a closePath()
  4. Try just drawing the world instead of the stage to your rendertexture to fix the upside down problem.
  5. 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.
  6. 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.
  7. 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.
  8. 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); }
  9. Try different versions of Phaser, see if you can find a working one, that might help pinpoint the problem
  10. look in the browser console for any problem logging
  11. 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.
  12. 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:
  13. 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.
  14. Your body is the root graphic, that cannot be changed, thus all the added children will appear in front of the body. I'd convert to a group (very simple), then you'll be free to re-order all your components however you want.
  15. ok, just checking as an animation of 1 frame isn't really an animation... in case that was something to do with your problem when you create a sprite using the key 'player' it inherits all the frame data, ie all the frame definitions from the atlas .json, so when you create an animation using those frame names it works. but when you create a sprite using a bitmapData as the source, it doesn't inherit all the frame data, it's only interested in copying the texture, so it points at the same source atlas texture but gets a single frame definition describing it all of the texture, thus any animations using the original atlas frame names will fail. after creating your sprite from the bmd, you'll have to copy the frame data from the source atlas manualy sprite.animations._frameData is what you should be investigating