Category Archives: code

FlashBuilder 4.7 Win8.1 x64 unexplainable java.lang.NullPointerException

code, , , , , , , ,

This one’s a weird one. Sometimes Flash Builder 4.7 has a problem where weird errors come up in library code (Feathers, usually) that doesn’t have any actual errors in it.

The error raised is the following: com.google.common.collect.ComputationException: java.lang.NullPointerException

The (non-obvious) solution is to find a little button called “Mark Occurrences” in the toolbar and turn it to OFF.

Here’s a picture of what the button looks like when set to OFF:
mark occurrences off

And here’s what it looks like when set to ON:
mark occurrences on

Oh, and sometimes restarting Flash Builder doesn’t do it, so sometimes in order to fix it, I have to set mark occurrences to ON, close and restart FB, and then set it to OFF again to get it to work.

More info is available in this post in the Feathers forum here.

AIR for iOS Runtime Error #1520: Mutex cannot be initialized.

code, , , , ,

Situation: I’m making an app for iOS and Android using Flash Builder 4.7 and AIR SDK 4.0. It includes the Lua 5.2 interpreter as compiled from C code into a SWC using CrossBridge (formerly FlasCC). I’m just using the lua.swc file from the crossbridge samples. However, apparently there’s some problem with the multithreading code or something (is multithreading even supported in AIR 4.0? I don’t remember), because I get the following run-time error when debugging on the device (not on Android or AIR simulator, just iOS):

Error #1520: Mutex cannot be initialized.

Solution: I don’t know why this works, but if you add the following compiler options:

--swf-version=17

It works. This probably means I’m targeting an older flash player and one day I will need to figure out how to get the Lua interpreter code.

Here’s a pretty picture of the box where you enter the code in Flash Builder 4.7:
version17

Sensors in Box2D

code, , , , ,

Box2D has these things called “sensors”. What are they? They are shapes that can be attached to a body with a fixture just like any other, but the crucial difference is they don’t participate in collisions. In other words, something colliding with a sensor will never cause the object containing the sensor to change position, speed, rotation, or acceleration. “So, what’s the point?” you say. The point is you can still cause code to execute when these collisions begin or end, through your contact listener.

What good does that do? Plenty. You can use sensors to determine when any two shapes start or end colliding. You could use sensors to define field-of-vision for enemy units, create a proximity alarm when the player gets too close to laser tripwires or torpedoes, guide a heat-seeking missile, manage fog of war rendering decisions, or help enemies avoid crashing into other enemies and walls.

In my upcoming game Deep Space Demolition Derby, I’m using sensors in a few places. First, there is a big circular sensor surrounding the player:

20140408-015555.jpg

The above picture shows the game in debug mode, where the shapes overlaid on the sprites show the Box2D objects that represent the sprites for physics purposes. I have chosen to represent most of the objects in my game with circles. You can see a small circle around the player, and a small circle around each collectible crystal. This defines their physical extent – when those shapes touch, a collision has happened.

The large circle around the player is a sensor that doesn’t cause collisions, but causes collectible crystals and powerups to appear when you get close enough. Also, when you have a magnet powerup, any crystal that is within that distance will be sucked towards you.

Enemies have sensors to help control their AI. I put a couple of circles to the front left and right of enemies. These are like “vision” areas that help the enemy “sense” what’s in front of it to the right or left sides. When a wall or other enemy or the player overlaps either of those sensors, the enemy turns away to avoid a collision.

In the picture below, the enemy’s sensor has overlapped with the player and so it will turn to avoid a collision:

20140408-020112.jpg

The next picture shows the enemy has turned away and dodged the player:

20140408-020327.jpg

As development continues, I’m sure I’ll find a lot more uses for Box2D’s sensors. I’m excited to continue exploring this cool feature, and excited for the possibilities it has to improve my games.

FlashDevelop 4.5.2.5 crashes on startup under Win8.1 x64

code, , , , , , , ,

I use FlashDevelop for a lot of work projects. It’s a much better IDE for writing code-based ActionScript 3 projects than Flash itself.

Today, out of the blue, it started freezing on startup while trying to load the last project I had open. I thought I’d post about it in case a.) it ever happens to me again, or b.) it helps you, dear reader.

A quick Google search produced this forum thread, which solved it for me.

The solution was to rename/delete the file C:\Users\[USERNAME]\AppData\Local\FlashDevelop\Data\ProjectManager\Settings.fdb, which probably got corrupted.

Back to work! 🙂

Starling Tween Transition Cheat Sheet

code, , , ,

I’ve been making games using the Starling Framework, and I’ve been using a lot of tweens. Tweening is a great way to add what I call “juiciness” to a game (I borrowed that term from here). Tweening gives your user interface some animation, and if it’s not used too much, can really make your game more fun.

There’s a whole bunch of different motion types that can be used with tweens. This graphic helps when trying to picture the various tween transition types, or “easing” functions – not just in the Starling framework, but in any other platform.

sparrow-transitions

Graphic originally from here.

Supporting “the other landscape” in AIR for iOS

code, , , , ,

Most iOS games are either portrait-only or landscape-only. The AIR application descriptor file lets you easily specify this. All you have to do is add the following to your descriptor file, inside the initialWindow tag:

<aspectRatio>landscape</aspectRatio>
<autoOrients>false</autoOrients>

The above configuration will result in a landscape app that will be right-side up when the home button is on the right – known as “landscape right” – that doesn’t rotate to portrait when the device is turned. However, it will ALSO not rotate when the device is turned to “the other landscape orientation” – if you position your iDevice so that the home button is on the left, your app will be upside-down!

To have a truly industry-standard game, you’ll want your portrait games to support both “Default” and “Upside Down”, and your landscape games to support both “Landscape Left” and “Landscape Right”, as Apple calls them:
iphone_orientations

To accomplish this, we need to think about the concept of “stage orientation” as opposed to “device orientation”. Adobe’s StageOrientation class defines four orientations – DEFAULT, ROTATED_LEFT, ROTATED_RIGHT, and UPSIDE_DOWN. These orientations describe the orientation of the Flash stage relative to the physical device. DEFAULT simply means that the stage is oriented to match the physical orientation of the device. ROTATED_RIGHT and ROTATED_LEFT mean the stage is rotated either 90 degrees right or left. UPSIDE_DOWN means the stage is rotated 180 degrees.

For our game to work properly, we want to allow the stage to be in either the DEFAULT or UPSIDE_DOWN orientations, but NOT the ROTATED_LEFT or ROTATED_RIGHT orientations. Fortunately, Adobe has added some events that help us do just that. If your app descriptor has autoOrients set to true, the StageOrientationEvent.ORIENTATION_CHANGING event will be broadcast when the device’s accelerometer has detected the physical orientation has changed, and the Stage is about to rotate to follow suit. If you call Event.preventDefault(), you will prevent the Stage from rotating. So all we have to do is disallow rotating to the left or right, and allow rotating to the upside-down or default positions.

To accomplish this, add the following to your application descriptor file, to enable the Stage to rotate to follow the device’s physical orientation:

<autoOrients>true</autoOrients>

And add this to your app’s main class, to only allow a subset of those rotations to actually take place:

// we can control which orientations we want to allow with the following code
stage.addEventListener(StageOrientationEvent.ORIENTATION_CHANGING, onOrientationChanging );

function onOrientationChanging( event:StageOrientationEvent ):void
{
	// If the stage is about to move to an orientation we don't support, let's prevent it
	// from changing to that stage orientation.
	if(event.afterOrientation ==
		StageOrientation.ROTATED_LEFT || event.afterOrientation ==
		StageOrientation.ROTATED_RIGHT )
		event.preventDefault();
}

And voila! Your app now support both portrait orientations, or both landscape orientations!

Condensed from http://www.adobe.com/devnet/flash/articles/screen_orientation_apis.html

Also helpful: https://developer.apple.com/library/ios/featuredarticles/ViewControllerPGforiPhoneOS/RespondingtoDeviceOrientationChanges/RespondingtoDeviceOrientationChanges.html