Jump to content

The march towards 1.0


rich
 Share

Recommended Posts

Honestly at this pace it should be pretty soon. The areas left to convert are:

 

Groups

Sound

Physics

Scale Manager

Tile Maps

 

Sounds is easy, just haven't had a chance yet. I want to redo how scaling is handled, so that will need a few days. Groups I'm not too sure about, they are being used for collision and object pooling only now, not rendering, so probably can cut out a huge load of cruft from the original class. Physics I'm reverting back to the original Flixel implementation for now and will leave it as easy as possible to swap out. Tile Maps are an easy conversion but I need to render them to a buffer now, rather than every single tile due to WebGL, so a bit of experimenting needed.

 

Obviously have got client work to do between all of this, but keep an eye on this thread as I'll post my daily progress up :)

Link to comment
Share on other sites

Hi All,

 

Starting a project to port a Flixel game to Phaser, should I just get started on using the 1.0TS083 branch and upgrade whenever?

 

I notice a few API changes (ie no TransformManager), will the new physics system be largely compatible with the previous TS version?

 

Phaser looks fantastic, and I'm super impressed at the performance having looked at both Jangaroo and Haxe/HaxeFlixel to do the migration already.

Link to comment
Share on other sites

Honestly for a direct flixel port I would use the current 0.95 version as it's the closest to Flixel. Or actually I think the 0.96 branch is quite safe too.

 

I'm going to clean-up the repo this week so it's just the latest (old) TS build and the new JS version up there. Everything else will do as it's getting a bit messy now.

Link to comment
Share on other sites

Progress has been steady on the JS rebuild. After a load of math work I've now got accurate bounds checking and Camera culling done. Sprites how have nicely optimised edge points for each corner, a proper dead accurate bounds and optional automatic camera culling. With all data cached in the Sprite I've kept it as lean as I can.

 

Time to hit the Sound Manager, should hopefully be quite a fast conversion.

Link to comment
Share on other sites

Well that was a productive night! Sound Manager totally converted and working. Woot :) But also added Tiling Sprite and Text support too, and created a handful of fun demos to show them all off. Using a new object extension method as well which is far more flexible and has cut down on the volume of code in the gameobjects a lot, so very pleased with that. As ever the 1.00JS branch is your friend if you want to experiment early.

 

Tomorrow (or, err.. later on today) I'll attack the Bitmap Fonts and probably game scaling. Dull but vital. Then it's literally a re-working of Groups, collision and tilemaps and I've finished everything I wanted for core. Still don't want to put a release date on it but I'd say next week is looking very hopeful now indeed.

Link to comment
Share on other sites

Today I sort of eschewed the boring stuff and hit physics instead :) But that's all back in now and working. I've integrated the original flixel physics system for now, but kept it all easy to modify and replace (and I intend to release the advanced physics package shortly after release too).

Link to comment
Share on other sites

Ok we've got a totally brand spanking new QuadTree system in place, and it's working beautifully :) The Flixel quadtree used to get built and torn down for every single time you called 'overlap' (or collide). That was fine in Flash because the AVM is nice and speedy, but on mobile I needed a different approach. So now I've got a single world quadtree which every alive physics body adds itself to each loop. So you can now run collide against this single tree as many times as you like, and it won't ever need to re-build the tree again until the next frame.

 

This isn't always perfect, for example an object receiving lots of collision may technically shift to another quadrant as a result of the collision so I've left it easy enough to change as you need.

 

Also fixed a bug in the separation code and fixed the velocity calculations, so you can now have 'world' and object based gravity, or stop an object being affected by gravity at all. "world bounds" is in now too, so objects can collide with the edge of your world if needed.

 

My todo list is getting nicely smaller now, just Group and scaling are the big ones left, and I think Group needs a total rethink rather than blanket porting the massive old version of the code over.

 

post-1-0-06927100-1378299595.png

Link to comment
Share on other sites

I'm using pixi for rendering now, which has limited (but available) Graphics support. So things like lines, rects, circles, etc are supported in canvas and webgl mode. No idea how far you could push this though, re: data exported from Flash like easelJS uses. If you want to send me some example FLAs and exports I'd be happy to experiment.

Link to comment
Share on other sites

Hm, I just checked out pixi.js, and the functionality is very similar to easelJS. I was just wondering because I want to use a framework for my project that has good support (and is open-source). createJS has pretty good docs but the devs seem somewhat unapproachable. Also I suck at collision detection, which you seem to have a zeal for. I like this board and that you and the pixi.js dev are so active :) So since you do plan on including pixi in Phaser, I might go ahead and make the switch when you release 1.0 (since I assume that's when the api will be out?). I do plan on using sprites eventually, I just like using vector graphics for testing basic game mechanics and such since i like to do all my art assets at once

Link to comment
Share on other sites

After a slight detour into swapping nodes in linked lists I dived into the Group class and am ploughing through that at light speed. It has some awesome new functions and yet is still incredibly smaller (file size) than the previous Group implementation. For example you can now do things like:

alienGroup.addAll('angle', 10);

And it will add 10 degrees to the angle of all members of the group, i.e. it will update their local transforms. Groups also have x/y/rotation properties, as they are DisplayListContainers at heart, so you can rotate the group itself and all the children will rotate around that point. Or you could move the whole group down and all children will move down too. Very handy indeed :)

 

Once Groups are done that's another massive thing out of the way.

Link to comment
Share on other sites

Ok Groups are now finished and have a whole bundle of really useful functions! I also sorted out the game loop order, removed quite a few iterations from it and resolved some issues with the physics bounds and quadtree.

 

I'm down to 11 things on my list, 10 of which are essential and 1 is a "nice to have". It's a mixture of quite small and easy things to do vs. a couple that will require a good bit of research to get done right, but I'm still very hopeful to release next week. I've not yet finished all the documentation, but I'm thinking right now that I'd rather release first and see if people can help me finish it off collaboratively. I will definitely have a "getting started" guide done though.

Link to comment
Share on other sites

Hanging on your every word ... and what I mean by that is that I am eagerly consuming everything you are posting about your progress.

 

Having said that, don't kill yourself.  It sort of feels like you have put yourself on a self-imposed "death march".  I hope you don't feel like you must..  Yeah it was supposed to have been released already.  Things change.  There is no REAL deadline here, keep your balance.  Phaser will be better if you don't rush the last bits.

Link to comment
Share on other sites

Ok I've finished the Input component for Sprites, so now sprites can be clicked, dragged, thrown and generally abused via mouse and touch. Also created a Button object type. Created a build script too and for the first time I'm seeing this new version of Phaser coming out at just 250KB minified (remember it includes a nearly complete version of Pixi too). So I'm really pleased with this - gzipped that's next to nothing really. The more I convert the old TypeScript version the more I realise how inefficient TS generated code is.

 

8 things left on the list. One of them is quite a biggie (game scaling) but the rest are nice bite sized chunks of work.

Link to comment
Share on other sites

... (remember it includes a nearly complete version of Pixi too)...

I am currently experimenting with modulizing grapefruit, when I am happy with the result Matt and I will likely do something similar to Pixi, you should be able to get a super lean version of Pixi with only the features you need in the near future :)

Good work Rich!

Link to comment
Share on other sites

I've removed lots of classes from it, so the package size is down quite a bit already - I think everything that is left is stuff I need. But won't hurt to have it more modular too. Taking out the InteractionManager and all the loaders saved a nice bundle of space.

Link to comment
Share on other sites

Today was a good day. I got the StageScaleMode handler in and done, the Stage updated, Graphics and RenderTextures in and recoded the Particle Emitter from 0.95 so it's a lot more flexible and powerful now.  Fixed some Input issues too, added a Sprite "out of world" handler, added a "lifespan" value to Sprites which is ignored by default but really useful for Sprites as particles or bullets. Also added Pointer Lock to the Mouse class.

 

I need to do a few more tweaks on tilemaps but otherwise Phaser 1.0 is now feature complete :)

 

I've got a list of bugs and device testing to do (I know it crashes on iOS right now for example), but this is a damn exciting place to be right now.

Link to comment
Share on other sites

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...