terebentina

Hi, I was wondering if there's any way to access a texture that was already loaded via PIXI.loader by its given resource name. The reason for this is because I'd prefer not to use the path to the image all over my code, in case I change that. So if I load a resource like {name: 'foo', url: 'assets/img/foo.png'} I would like to then use PIXI.Sprite.fromName('foo');instead of PIXI.Sprite.fromImage('assets/img/foo.png');I know there's no "fromName" method in Sprite but is something like this doable without having access to the original resource object returned by the loader in the load() method?

Hmm, good question. I suppose tweening for width could be used instead of plainly setting it. Unfortunately I don't have time to look into it now but pull requests are welcome

Yes, this! Quite a pain now with i18n when text length is different and you want the bitmap text center aligned. Actually I would love to be able to align anything in relation to its parent or screen, not just multiline text. And +1 for improved scaling...maybe a NO_BORDER scale type could solve things?

Hi, I just want to point out that ES6 can be used right now. I am actually using it in a Phaser game I am developing. There are so called "transpilers" that can rewrite my ES6 code into ES5 compatible code at build time. X years from now on, when ES6 will be supported by all browsers this transpile step won't be needed anymore but there's nothing preventing you from writing ES6 code right now. There are so many goodies in ES6 that it's a shame not to use them. I haven't tried to wrap my ES6-to-ES5 game with cocoonjs yet to see if there is any issue but the game runs great in all browsers I tested with (desktop and mobile). Major js frameworks are already going full ES6 with transpilation to ES5 as an optional build step. I don't think using ES6 for Phaser's code will benefit Phaser users very much but it'll make Phaser more modular and will simplify some patterns. On Promises: They have already started going native in browsers. Latest Chrome for sure, probably latest Opera as well. The rest will follow eventually, if they haven't already so it's something pretty solid to rely on. Personally I use them very much for my day work and they're incredibly useful. Especially when you have no idea if the object that has to return the promise is synchronous or asynchronous, already finished or not started or ongoing. So +1 from me for implementing promises in Phaser wherever possible.

Ok, I'll wait and see. I wasn't thinking you were going to build the visual editor, btw. Just trying to imagine how a visual editor would look like if I were to create it on top of this json for game objects which you haven't even released yet. Got carried away

The way I imagined the Scene Builder was something like this: click "add new object" button -> it asks for object type -> I select Sprite -> I enter params or move the sprite around a canvas to position it where I want. Since this is a built-in object, sure, it's easy for the Builder to know the order of the params. It could even have the list of params already listed for me to fill in: x: <enter x> y: <enter y> key: <enter cache key> frame: <enter frame no> That's because the map you're talking about is already built into the Builder. Now let's say I found a nice class made by somebody else that I could use with Phaser (like my VisualTimer). I just drop it in a classes folder then, in the Builder: click "add new object" button -> it asks for object type -> I select VisualTimer -> the Builder doesn't know anything about this class so it won't know what to ask me. Sure it could ask me something like: first param: <enter value for param 1> second param: <enter value for param 2> The problem with this is that if I enter a wrong value for second param - let's say I put the 'key' value for param 2 instead of the 'x' value, I will have to rearrange the params to be in the right order and this is prone to bugs. What I wanted to be able to do was something like: <enter param name>: <enter param value> <enter param name>: <enter param value> which would look like this after I enter a few things: y: 20, key: 'sprites', x: 10, frame: 1 So even if x is the third param and y the first, this wouldn't matter because that class would use the key names: new VisualIndicator({y: 20, key: 'sprites', x: 10, frame: 1}) And this would be saved in json as something like: stage23: [ {className: 'VisualIndicator', params: {y: 20, key: 'sprites', x: 10, frame: 1, seconds: 30}}, ... ] Anyway, this is highly theoretical for now, at least for me and with your deeper understanding of Phaser I am sure you can come up with something good. And really looking forward to seeing it

I just updated this to use phaser timers instead of setInterval() so that it can be paused with the game.

@rich - the scene generation plan sounds great and I am really looking forward to seeing it. I actually took the first steps towards this in my playground and some things I stumbled upon were: 1. custom classes - you need to add the class type in json because the object might not be a pure sprite, for example, but a class extending sprite. 2. parameter order - a class extending sprite might not have all the sprite params or it might have them in a different order (when calling the constructor). This means that the game/scene builder will have to know about the parameter order which kind of makes it less modular. Means you won't be able to just add new classes, even ones made by someone else or you'd need a way to describe the order param for each class. I implement my custom classes with a single object param like this: function MyClass(params) { Phaser.Sprite.call(this, params.game, params.x, params.y,...);}var asd = new MyClass({ game: this.game, x: 0, y: 10, key: 'sprite', frame: 1, ...});This is perfect for storing the params in json, without worrying about future compatibility and without having to know the order of the params - I can send them in any order. Unfortunately, I cannot do it for built in classes, like the sprite so I'd probably have to extend all built in classes just to make the params into an object. Kind of wasted resources, I'd say. I wonder what your take is on this.

@rich, what do you mean by "scene generation" ?

Thanks guys. Would be nice to know if you put this to use.

Here's a progressbar I created for my projects: https://github.com/terebentina/VisualTimer Feel free to use it if you need one, I released it under MIT. Not much but I thought to give back to the community

Thanks, The example is using map.putTile() but I do see putTile() is basically setting the index of the tile. I'll give it a try. I am thinking of first tweening the coordinates of the initial tile to move over the destination tile and then set the index on tween complete. I'll let you know how it goes.

I am trying to swap 2 tiles (actually I just need to move a tile up/down/left/right, in place of an empty tile). I tried using tilemap.swap(tileA, tileB) but that only copies tileA over tileB, not the other way around too. The "swap tiles" example says it's supposed to really swap (copy A over B and B over A) but this doesn't happen there either. Is there any method that I am missing that can do this? And, since I am trying to move a tile over an empty place, is there a way to tween this move? Any help is greatly appreciated. Dan

It's great to see the project is not dead after all - I had a lot of fun playing with devkit and the docummentation was very good. The problem is that devkit is in much need of attention. Most of the examples aren't working, when they are working, they're only working in the default iphone 3 simulator and as soon as you switch to web or another device it starts throwing out errors. IRC support was pretty much useless for me - if I got 1 answer in 24 hours I was happy. The gameclosure.com site seems dumped and forgotten with the latest news entry from 2012 and the latest blog post eons ago. The github repo for devkit last updated more than 3 months ago. All these, to me, meant the project was abandoned.

I suggest you start using the semver notation (http://semver.org/) and 2.0 would be a good start for it. This will give you a structured and consistent way of releasing new stuff and great support for package managers like bower which let you auto-update to, say, new patch versions, without worrying about compatibility. This will also be a great help for your users, with basically no overhead on your side.