Curse of reality and game graphics

The expression curse of reality is applied in the movie world in connection with animated movies and refers to the observation that the closer an animation is to reality, the more sensitive are the watchers to small production errors. This is quite understandable, since we live in the reality, and once someone approaches our domain we are sure to spot the glitches. At the opposite end, if graphics is far from reality, why should we care if it fails to resemble it?

The same principle can be applied to game graphics - when producing pixel art, you are not producing "cheaper" art or "easier" art, but an art of a different style which is less related to reality than others. Therefore your players rely less on their senses but more on their imagination to build up their inner image of the game - and moving the imagination of players is a powerful consequence! Remember the games on the ZX Spectrum? Some of the actors in the games were mere blobs of pixels but the player felt excited nevertheless.

Don't break consistency

While I'm not great at graphics, my general goal is to produce consistent artwork where the parts fit together. I prefer a less detailed but self-consistent style than a style with more detail at some parts but less at others, because the latter inconsistency alerts the player that something fishy is going on and interferes with expanding his or her free imagination.

This is the beginning of my journey to the pixel art world, and I'm curious to explore the hidden treasures.

Haxe is a swiss toolkit language: write all your code in haxe and then compile to different platforms like neko or php (for the server), flash or javascript. Now I will consider the javascript target.

Haxe and multi-file javascript

When compiling to javascript, you often would like to separate functionality into a common core and smaller modules. However when compiling with Haxe, it will generate all the core data into the sub-modules too (well, this is not a precise description of what is happening, but let's stick with it for now).

Fortunately it doesn't seem to be hard to decouple the modules from the core. I wrote a small python script that I call JsUnHaXe, which removes redundant entries from generated js files. Download and try it using python jsunhaxe.py out_dir my_core.js my_core_ext1.js. Note that sub-modules, sub-sub-modules, etc. can be passed, in this case the Kth output file will lack all entries beginning from the first and up to the K-1th input file.

Happy Haxing!

The serializer not only serializes the object passed to it, but also automatically follows and serializes references to other objects. As an example, if you pass the root element of a tree structure for serialization, it will follow the links to the child nodes and as a result serialize the whole tree. This is very fine, but if the objects contain cyclic references - like child nodes linking back to their parents - the serializer would run into an endless loop.

For avoiding this, the serializer has an option called useCache, which when turned on, the serializer keeps a memory of previously met objects and won't re-serialize them. Unfortunately, for technical reasons the lookup of an object in this memory takes O(n) time, n being the number of objects met while serializing, so the full serializing takes O(n^2) time.

This means that if you are keen on speed, you must not use the useCache option, and take care of serializing structures without cyclic references. And, unconvenient as it is, but sometimes you may have to consider going down to the level of (un)serializing by hand, which would enable for highly tuned speed. ]]> ron 2009-09-20T10:12:00-00:00 2009-09-20T10:12:00-00:00 tag:mindlesslabsdevblog,2011:MindlessLabsdevblog.43

<?xml version="1.0" encoding="utf-8"?>
<shx:resources version="9" compress="false" package="resources.classes"
   xmlns:shx="http://mindless-labs.com/samhaxe"
   xmlns:snd="http://mindless-labs.com/samhaxe/modules/Sound">

   <!-- 
      Empty first frame. You may put resources
      required in preloader animation here. 
   -->
   <shx:frame/>

   <!-- Frame with heavy assets -->
   <shx:frame>
      <snd:sound class="Music" import="path/to/a/large.mp3"/>
   </shx:frame>

</shx:resources>

class PreloadingDemo {

   // progress bar
   var progress: flash.display.Shape;
   var fully_loaded: Bool;

   public function new() {
      // background for the progress bar
      var progressBg = new flash.display.Shape();
      var g = progressBg.graphics;
      g.beginFill(0x002288);
      g.drawRect(-2, -2, 104, 14);
      flash.Lib.current.addChild(progressBg);
      progressBg.x = 10;
      progressBg.y = 10;

      // the progress bar itself
      progress = new flash.display.Shape();
      g = progress.graphics;
      g.beginFill(0x00ff88);
      g.drawRect(0, 0, 100, 10);
      flash.Lib.current.addChild(progress);
      progress.x = 10;
      progress.y = 10;

      fully_loaded = false;
      flash.Lib.current.addEventListener(flash.events.Event.ENTER_FRAME,
            onEnterFrame);
   }

   function onEnterFrame(e: flash.events.Event) {
      var totalBytes = flash.Lib.current.loaderInfo.bytesTotal;
      var actBytes = flash.Lib.current.loaderInfo.bytesLoaded;

      if (!fully_loaded && actBytes <= totalBytes) {
         // animate progress bar
         progress.scaleX = 1.0 * actBytes / totalBytes;
      }

      if (!fully_loaded && actBytes == totalBytes) {
         fully_loaded = true;

         var music: flash.media.Sound = Type.createInstance(
              Type.resolveClass("resources.classes.Music"), []
         );
         music.play();
      }
   }

   public static function main() {
      new PreloadingDemo();
   }
}

People will also be able to extend it via plugins to support importing their favourite formats into the library swf. So far we use it with success for importing png, jpg, alpha-masked jpeg images, binary data and mp3 sound into the asset library. As it turned out, the since far sought pure Haxe-based preloading is also possible via the tool. Read on for some insight!

(Edit: Don't forget to check out our latest article Preloading with Haxe and SamHaxe on the topic!)

KukkerMan does a nice work implementing the modular import system: The asset library is described with an xml file, something like swfmill's simple format. However, a separate configuration xml file describes which tags are handled by which import modules. For example, the image tag is currently handled by our default Image plugin, but you could easily change that in the configuration file. (By the way, KukkerMan had hard time trial-and-erroring how to use the poorly documented ImageMagick library, and is now considering to throw the whole code into trash and restart with a better library :)

About preloading with Haxe: I implemeted the Sound import module, currently with mp3 support and more to come. For that, the hxformat lib was extended with mp3 support (more to come of course). When testing the sound import, placing the DefineSound swf tag on the second frame of the asset lib made the flashplayer cry out loud. It had a SymbolClass exported. After experimenting, it turned out that flash requires (? correct me, I'm not an AVM2 insider) an AS3 class definition for resources with a SymbolClass.

But you can say: "Hey, I use an asset lib with Haxe and I don't write class definitions for my assets!" Well, that works because Haxe generates the class stubs for you if this is the case. "Ok, but then why did you get that error?" That happened because Haxe only generates these class stubs for resources on the first frame of the asset lib.

So basically if you can generate class stubs for those resources, you can put all your heavy assets on the first second frame, wait with Haxe code for the whole file to load (possibly displaying preloader gfx), and continue executing rest of the code once the whole file (or at least the required frames) are ready. How to generate class stubs?

1. You can do that by hand, creating simple class definitions with a constructor calling super(), with Haxe. The stubs will be on frame 1, but they don't eat up much space.
2. Or you can generate an AS3 code block along with the asset onto the frame it resides (frame 2 currently). I tried this and seems to work nice (not sure about generating a code block for frame1 would not collide with Haxe, I will have to research this later).

      // ctx is the format.abc.Context
      var cl = ctx.beginClass(_name, true); 
      cl.superclass = ctx.type("flash.media.Sound");
      ctx.endSubClass();
      ctx.finalize();

      ...
      beginFunction([],null);
      var cst = curFunction.f.type;
      curFunction.f.maxStack=1;
      if (callsuper) {    // this block was added
         op(OThis);
         op(OConstructSuper(0));
      }
      op(ORetVoid);
      endFunction();
      ...

As a bottom line, this tool would prove to be useful and is an interesting challenge, so I hope that we are able to have an initial release in some weeks time. In the meanwhile (or during the meanwhile, Brian? :) you can try to guess the name of the tool, you get three hints for this:

1. Assets are not only important for flash developers, but also for whom?
2. Let's hope that this friendly tool won't inform on you to the FBI ;)
3. ???

This way Flash developers dropping "HaXe can compile to Flash? And what? So can AS3" will be comforted to use familiar language constructs and emulated Flash API with flash.display.Sprite and pals, for targeting Flash and IPhone with the same code.

Now go and fire up HaXe! ;)

Usage example: Setup a local web proxy (like privoxy) on a remote university machine, and connect to it from home. This way you can access university resources with ease. ]]> ron