V3.1.4 improvements and Feathers

Hey there,

With this new update, we have included Feathers into all SWCs builds including Starling. Feathers isn’t used by the engine itself (at this time so this addition won’t change final file size if you don’t use it), but it was requested by many guys to make advanced user interface for their game. With this new update, you’ve all the Adobe Gaming SDK in one framework especially designed for building awesome games! Using SWC file, you will compile your game in no time, and also we make sure those libraries are up to date, and compatible between them!

This update involves many improvements concerning camera, State management, Flash Pro as a level editor, UI and physics objects. Also we have started the draft for the V3.2.0 and as usual we will enjoy your feedback!

    Changelog:

  • Renamed AVirtualButtons and VirtualButtons classes into AVirtualButton and VirtualButton. Yes, they just add one button now. Easier to add many.
  • Added Starling’s simple trick to avoid the state changes (alpha 0.999).
  • StarlingCitrusEngine and Away3DCitrusEngine accepts State, useful to display quickly a state with graphics from a swf, ect.
  • States classes have a new method killAllObjects(…except). The _objects variable has also a getter.
  • States classes have a protected variable _ce which refers to the Citrus Engine.
  • Nape’s Hero has a static friction removed when the player move, and set when it stops moving (to prevent sliding).
  • ObjectMakerStarling has a FromMovieClip function. The second argument is the TextureAtlas. Objects made in Flash Pro can use a texture name for their view.
  • Added Panning to SoundManager.
  • Added a camera lens parameter to view.camera.setUp function.
  • Added zoomFit() to StarlingCamera and SpriteCamera.
  • Added a get function command for the console.
  • Added a trace to inform if we create a group with a high value.
  • view.camera.setUp returns the instance of the ACitrusCamera.
  • StarlingArt doesn’t generate mipmaps if view is a Bitmap.
  • Added Crate object to Nape.
  • Added a UI package for inventory and lifebar.
  • Added a Path class which is a set of points (MathVector) that can be used with the MovingPlatform.
  • Added Nape version of the Moving Platform managing also a Path if it’s specified.
  • Added line equation to MathUtils.
  • Added linear interpolation function to MathUtils.
  • Added Tools class with a print_r function to display objects and arrays content.
  • Improved the Timer’s cannon: it is paused if the CE is not playing.
  • Added a Bridge, Rope and Pool objects, into the new objects.complex.box2dstarling package.
  • Added a Multiply2 function into Box2DUtils.

UI
UI and HUD are really important in your games. Adding Feathers to the Citrus Engine will help you to make cool menu and interfaces for your game. Also you’ve certainly noticed the new ui package. At this time, there is only a life bar made for Starling and an inventory package managing objects (you defined) state.
In the Citrus Engine, we used to make a compatibility with new features: they were available on the display list and Starling. Since we believe that Starling is the future of Flash gaming, we won’t port all the future features on the display list. Based on the inventory example, we will make the UI using Feathers. This will save us lots of time, but it won’t help to make a port easily of this inventory on the display list. So we prefer to drop the display list compatibility for those kind of features (saving time), and make sure they will be very powerful.

V3.2.0: Physics improvement
As a developer, it’s very important to try different tools. This last month, I played a lot with Unity3D and really enjoyed it! It gives me ton of ideas on level editing and coding.
Do you remember our issue using the Frame Rate Independant Motion? Using the same code logic than Unity, it will help us to make sure that our game is running exactly at the same speed on different devices. Explanations:
In Unity there is an Update function (called on each object) which is like a function called by the enter frame event in Flash. In this function you’re never sure that the call is made exactly at the same time than the previous one. There is also a FixedUpdate function which is performed at the same time than the physics engine doing a step. In the FixedUpdate function, we’re sure the time elapsed between each function is exactly the same.

So what I’m suggesting is to replicate this behavior:
- keep our update function with the time delta as a parameter coming from the CitrusEngine class using an enter frame and the Date.time, and create a protected variable in APhysicsObject to register the timedelta (so it can be used in FixedUpdate).
- then create a fixedUpdate function in APhysicsObject which will be called each time the physics engine make a step. The step of the engine comes from a Timer which have exactly the same delay than the physics engine step.
This way we keep our view syncronized with the FP/AIR, and are sure the physics engine is performing at the same speed on each devices.
The downside are we will have to rewrite some physics objects code, and there can’t be a backward compatibility. What do you think?

Happy coding!

11 thoughts on “V3.1.4 improvements and Feathers

  1. I say move on with the physics upgrade. It sounds much more important than backwards compatibility since it’s an effort to make all devices run the same way.

  2. I’ve been using Unity pretty exclusively for the past couple years. The Update/FixedUpdate functions are very useful…but only once COMPLETELY UNDERSTOOD. The problem is that many people don’t know which code to put in Update() and which code to put in FixedUpdate(). For example, input events such as IsForwardPressed() should be in Update(), but MoveForward() should be in FixedUpdate(). Usually people this functionality into the same code chunk. So there is a big paradigm and understanding shift that must be trained to the users and (IMO) Unity does not do a very good job of this. In fact, they often break these rules in much of their own code samples, showing that their own doc writers don’t even understand the difference.

    I don’t have a better solution, though. But I encourage you to try to think of one…or at least a good way to educate the users on when to use each function.

    • Hi Eric, it’s pretty cool to see you there!

      You’re right, those differences must be clearly explicated into the documentation (source code and the new wiki). I’m sure it worth it! Finally an engine also teach you logic, how to structure code, ect. And people coming with an Unity background will feel at home.
      When I read this awesome article, I tried to duplicate how QuickBox2D does the FRIM, but didn’t find the best approach to include it in the CE.

  3. Hi, a noob question, If we make graphics or edit on the flash pro and export that levels filled with vector graphics into citrus engine, would it affect the game’s performance on mobile? Or the Citrus engine would rasterize the vector graphics as bitmap. Thanks!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>