I read a scientific article on a topic of which I have some experience, namely NES-era Mario Bros physics. It was “Acceleration Due to Gravity: Super Mario Brothers“. I was very disappointed in the quality of this article, as the entire basis of the article was made under more than one incorrect assumption. For shame Adam Lefky and Artem Gindin.

When I created this demo my usual formula for velocity/acceleration used on Mario simply did not work. I had to look carefully at his movements until I realized his acceleration was not constant. After some experimentation I estimated his acceleration downward to be 0.6 in pixels per frame (1 frame = 1000/30 ms) before the peak of his jump, then it dramatically increases to 3 after the peak of his jump. This produces Mario’s hovering jump, which can be hard to notice unless you’re looking for it, but it’s there. This is not taking into account when a player releases the jump button mid-jump, which also changes the acceleration.

Additionally, there is also a maximum velocity in the Mario world, which probably came into play for some of their experiments. Not that they’d notice while wontedly ignoring the scientific method. I am very disappointed in you Adam Lefky and Artem Gindin.

Update: There’s some indication this method no longer works in Flex 4, be careful.

If you use mxmlc and the [Embed] tag you may be aware that you’ve just involved Flex in your project since [Embed] is actually a Flex concept.

Using the “-link-report” option in mxmlc you can see what classes have been compiled into your swf and how much space they use. I found this entry like this in my link report for an [Embed]’d image.

<script name="com/brokenfunction/project/SomeClass_EmbeddedImage.as" mod="1236990005000" size="684" optimizedsize="343">
   <def id="com.brokenfunction.project:SomeClass_EmbeddedImage" />
   <pre id="mx.core:BitmapAsset" />
   <dep id="AS3" />

See the “mx.core:BitmapAsset” requirement? Since the [Embed]’d asset ends up as a class which extends BitmapAsset it is used even if you don’t use it. I generally just use it as a Bitmap, rather than a BitmapAsset, so it’s largely unnecessary for my needs.

Now, this is all fine, this is how mxmlc does embedding, so it’s necessary. But checking the documentation for BitmapAsset and looking at the link report, we see it’s actually bringing in a bunch of extra classes and interfaces.

<script name="/home/max/bin/flex3/frameworks/libs/framework.swc(mx/core/BitmapAsset)" mod="1224183575340" size="1300" optimizedsize="678">
   <def id="mx.core:BitmapAsset" />
   <pre id="mx.core:IFlexAsset" />
   <pre id="mx.core:FlexBitmap" />
   <pre id="mx.core:IFlexDisplayObject" />
   <dep id="flash.display:BitmapData" />
   <dep id="AS3" />
   <dep id="mx.core:mx_internal" />

All the “mx” classes are actually compiled into the swf. Now Flex isn’t really bogging down the swf, all in all I found these classes to be around 2k-3k when compressed, but they annoyed me anyway while trying to shrink a preloader for a project. After a lot of Googling I found a solution, but I decided to write a more complete solution here.

You can replace the mx.core.*Asset classes with your own, which replace the originals and remove those unnecessary dependencies. Something like this:

package mx.core {
   import flash.display.Bitmap;
   public class BitmapAsset extends Bitmap {}

You can download a collection of these I’ve made here.

I recommend adding them to a new AS3 library, rather than mixing it with any major ones you use, then adding it as another source path for a project.

These could interfere with how classes interact in AS3 if you mix classes using this library and classes that use Flex. Since saving that extra 2k is unnecessary for Flex projects anyway, it’s probably a good idea to use it for AS3-only projects that need to save space.