hungrybutterfly

I had a crash on the stock android browser on a Samsung Galaxy S4 4.3 whenever a sample tried to stop playing. I'm using 1.1.3 but I think the same problem exists in 1.1.4. On line 36065 of 1.1.4 that reads "this._sound.stop(0)" I was getting "Uncaught Error: InvalidStateError: DOM Exception 11". I would assume this browser doesn't like stopping a sound if it's not really playing. I've 'fixed' this by putting it in a try/catch.

Awesome. Thanks for your help

BTW Rich I forgot to say thank you so much for this awesome engine

I thought about that but why should that affect the child sprites so badly? I NEVER change the child's rotation so surely it would should only affect the root sprite (the book) and the children would just inherit the parent's transform?

Yes it starts out rotated then straightens up to be read. I've just discovered (seems like an obvious thing to try in hindsight) by NOT doing this tweening all is fine.

I have a completed project that works on almost all devices. Yeah! Except for Samsung Galaxy S3/Mini 4.1.2. So far it's specifically that version of firmware. On this device (and everything else) MOST of the time the game looks like this... but SOMETIMES it looks like this... Obviously something is going wrong in the context's transform. And it might happen anywhere in the game but it's always the rotation that's broken. Scaling and translation are always fine. To be clear * I never touch any transforms myself but I do some rotation and scaling of the book (which is the root sprite) by setting the .angle and .scale fields. * I attach sprites to each other using addChild. * not everything is wrong in the same way (have the same bad rotation). You can see in the image different elements have a different bad rotation ie the text is more rotated that it's button. * The buttons look weird because they're made of 3 separate images, left bit, middle bit, right bit. * Once a sprite is created with a bad rotation it stays that way until it's destroyed. * The sprites don't change their rotation over time. They stay as you see in the image. One observation I've made is it SEEMS to be the deeper the sprite tree goes the worse the rotation error gets. So as an example the button graphic is attached to the paper and the button text is attached to the button graphic. The paper is rotated say 30 degrees, the button graphic is rotated 45 and the button text is rotated 60. This might suggest the same erroneous transform is being applied each time the renderer descends to a child. Any clues or ANYTHING please suggest away cos I've got no idea.

Turns out I'm a donkey. I had a load of bitmap text images that I'd *ahem* forgotten about which was causing all the slow down. So I just render them into a texture now and all is fine. ee-or Thanks for the help guys

Ok thanks for the suggestion. I'm drawing very few sprites but they're quite large (4 * 450x640) so I can only assume it's a pixel fill rate issue. There's at least 2 machine I have access to with the same problem. Anyone else out there experiencing this?

I'm slowly coming to terms with the limitations of Canvas and found image rendering on Firefox (version 25) to be very slow, compared to say Chrome. I presume it's still rendering in software. Slow down is fine, I can just compensate for that by updating the game with the given time delta. The problem I can't fix is audio playback. When the frame rate drops the audio stutters constantly and sounds awful.

I'm on version 1.1.3 and just started using Sprite.getLocalUnmodifiedPosition. Lets assume my test point is within the sprite area. If the sprite has unit scale applied I get numbers back between 0 and SpriteWidth for x and 0 and SpriteHeight for y. All good. However if the sprite is non-unit scaled on x I get back numbers between 0 and 1. Non-unit scaling on y works the same as unit scaled.

Ok here goes. At load time I load the texture with many blank frames like this... var BaseName = "Test";var MaxNumFrames = 100;var ImageFileName = "assets/Images/Test.png"var NewJSON = {};NewJSON.frames = [];for( var i = 0;i < MaxNumFrames;i += 1 ){ var NewObject = { filename : BaseName + i, frame : {x:0,y:0,w:1,h:1}, rotated: false, trimmed: true, spriteSourceSize: {x:0,y:0,w:1,h:1}, sourceSize: {w:1,h:1} } NewJSON.frames.push(NewObject);}Game.Phaser.load.atlas(BaseName, ImageFileName, null, NewJSON);Next I add a new function to the Phaser.cache like this... changeFrame = function (Texture, key, x, y, Width, Height) { var Frames = this._images[Texture].frameData._frames; for( var i = 0;i < Frames.length;i += 1 ) { if( Frames[i].name === key ) { break; } } var Index = i; var Data = this._images[Texture].frameData._frames[Index]; Data.x = x; Data.y = y; Data.centerX = Width / 2; Data.centerY = Height / 2; Data.distance = Math.sqrt(Width * Width + Height * Height); Data.width = Width; Data.height = Height; Data.sourceSizeW = Width; Data.sourceSizeH = Height; Data.spriteSourceSizeW = Width; Data.spriteSourceSizeH = Height; var Frame = Phaser.PIXI.TextureCache[Data.uuid]; Frame.width = Width; Frame.height = Height; Frame.frame.width = Width; Frame.frame.height = Height; Frame.frame.x = x; Frame.frame.y = y;};Game.Phaser.cache.changeFrame = changeFrame;Note I wasn't sure how get access to PIXI properly so I had to expose it by adding "PIXI: PIXI," to line 60 of phaser.js. Shame on me. Finally I populate the frames each time start a new puzzle like this... var BaseName = "Test"var NumPieces = 5;var PieceWidth = 10;var PieceHeight = 10;var NewSprites = [];for( var i = 0;i < NumPieces;i += 1 ){ var Name = BaseName + i; // fiddle the frame Game.Phaser.cache.changeFrame(BaseName, Name, i * PieceWidth, 0, PieceWidth, PieceHeight ); // create the sprite using the new frame NewSprites[i] = Game.Phaser.add.sprite(i * PieceWidth, 0, BaseName, Name);} The result should be 5 sprites at 10x10 pixels in size. Enjoy.

Ok I finally figured it out but it's not nice. Basically I followed the "local json object.js" example to load in a texture with enough frames to cope with the maximum number of jigsaw pieces I might need. At this stage it doesn't matter what the position or size of each frame is because it's just a buffer. Then just before I create my sprites for each jigsaw piece I pick the next available frame from Phaser's framedata and fiddle the x/y/width/height as well as Pixi's texture cache (using Phaser's framedata.uuid). Nasty but it works. If anyone wants code just let me know. BTW thanks for the awesome engine!

I'm trying to dynamically crop an image many times. Imagine many jigsaw pieces made from a single source image. Initially I reached for Sprite.crop but it seems that all sprites using the same image will render with the same cropping rather than unique cropping. It seems to end up being a property of the image rather than the sprite. I tried changing the Sprite.textureRegion without effect. I thought I could dynamically create a texture atlas to represent the different pieces... but I'm not sure how. To be clear I need this to be dynamic so the user can select the complexity of the jigsaw and I can build the pieces at run time.

Is it possible to recolour sprites given an RGB? If not are there plans for this functionality? Sorry if this has been answered elsewhere, I couldn't see this question on the forum