Tony Polinelli
Tarwin Stroh-Spijer

contact [at]
touchmypixel.com

6/25 Easey Street
Collingwood, 3066
Vic, Australia

+61 3 8060 5321

Archive for the ‘Flash’ Category

Saturday, May 23rd, 2009

After the haxe meeting last saturday night, i was excited that the topic of targeting the iphone was brought up. This could cause a lot of adoption of haxe as a language. Being able to develop games for flash and Iphone at the same time would be perfect and something lots of flash game developers would love!

I tried my hand at compiling c++ into and ObjC wrapper a few weeks ago, and in my inexperience… failed miserably. Hugh (the haxe C++ target creator) has taken the challenge, and in the last few days, successfully made some first tests for haxe C++ on the iphone. Hopfully over the next few weeks everything will continue to come to plan (and more people just on bord for testing and dev) and we’ll have an iphone target :P

I cant wait to get a chance to do some testing (looking to buy a macbook next week when we go to LA for e3).

read about it here:

http://gamehaxe.com/2009/05/22/haxe-on-iphone-simulator/

cheers

Tony

Monday, April 27th, 2009

jellyroids-01

After only a day or two playing in hxcpp i’ve got my first little test to show – Jellyroids!

This gametest compiles (using haxe) out to flash & C++ (exe in the cpp folder for windows only – i dont have a mac or linux, so cant test as yet).

Running the software rendered c++ version is a little slow – ~200fps on my comp, opengl is ~1500fps. Whereas flash clocks in at 100fps (maxed out). Prerendering the explosion animation (currently vector animation from a swf) will make it MUCH faster for c++ (stop the slowdown on shoot), as i feel its vector animation code isnt anywhere as optimized as that in flash.

Overall, its fun to see how easy its been to get out a simple test in hxcpp.

download the game test here

cheers – Tony

UPDATE:

to get it to work you need to change a few small things in the neash 0.9. realease.

There are two issues with the current release of neash that need fixing. Just change the following lines:

1/ in neash.display.MovieClip:
add in some stubs for functions (just copy in the following lines)

public function gotoAndPlay(frame:Dynamic, ?scene:String):Void { }
public function gotoAndStop(frame:Dynamic, ?scene:String):Void { }

public function stop(){}
public function play(){}

2/ in neash.display.DisplayObject:
make getRotation method look as follows:

public function GetRotation()
{
return mRotation * (180.0 / Math.PI);
}

Saturday, April 18th, 2009

Its finally time! The Scarygirl project has been in the works for about 2 years, in production for about a year and a half, and in my nightmares for quite a while. So, we are slightly excited to see it out in the wild… and not on our todo lists :P

We have been surprised by the reaction so far, 200,000+ plays in the last 3 days. We’ve had to upgrade servers twice, and are rapidly making some fixes to bugs and improvements to gameplay.

As a bit of background, the project is based on the concepts and designs of Nathan Jurevicius. He is a comic artist from Melbourne, Australia, but living in Toronto. The character Scarygirl has had quite a journey over the last 10 years, but is finding her feet in this online game (Funded by Film Victoria & Passion Pictures), soon to be released graphic novels, and an upcoming feature film. We had the opportunity to work on the project due to our friend Suren at Renmotion, and his contact with Nathan.

The project has stretched our skills and through its arduous process, we’ve learned a lot about planning, designing and developing a game. TouchMyPixel is only two people (Tarwin & myself) so the project was a huge workload. We have a background in Flash development, design, and smaller advertising style games, but not a larger scale game of any sort. Scarygirl, in its essence was only planned to be a 9 month project (sorry Sophie), but I think, in our excitement of making a “proper game”, not what people generally see a flash game to be, we overshot the timeline a little. We tried to give the game a depth which most Flash games don’t have, as it seems most flash games are focussed on being small, fun snippets of a game. We wanted to produce a full experince. I think everyone on the project felt this way, and wanted to push themselves and the project.

The game is quite artwork driven, which is obviously one of the major requirements (being to promote Nathan’s artwork). This challenged us with the task of designing a world which would well reflect Nathan’s irregular style while keeping farmiliar game mechanics. We spent a lot of time finding ways to faithfully display his artwork. For instance, we wanted the character to be able to walk over irregular surfaces, surfaces we could quickly mockup in Flash to match to the artwork as needed.

Our first stage was conceptualizing what each level would entail (or even if there were “levels”). Nathan had given us a basic ideas for some levels, and a pre-release of the graphic novel for story reference. Then it was up to use to sketch out some levels. We wanted to incorporate adventure game elements to highten the journey aspect, but also keep with traditional platform style gameplay. From sketches of characters, we would decide how they would fit into the world and react to the player. After producing mock levels without artwork (see non-graphical demo), we handed over level designs to Nathan to have them beautified. At this stage we often had NO IDEA what a level would look like, which gave us the joy and sometimes suprise when we finally saw what a level really looked like; we may have just drawn a small brown patch for tree which would come back as a beautiful peice of art. This was wierd, and made level design hard, as we really didnt have much of a concept of what we were designing, or more to the point were worried that our concepts was wrong.

underwater_progression

Progression of level design: 1. sketch  2. level in Flash  3. artwork overlay  4. final product

After getting the graphics and adding them to levels, we found that the game ran at about 1FPS. Which was a slight issue. This brought us to the stage of optimizing, refactoring, and rebuilding all of the levels to work with graphics. In the end all of the level graphics are pre-cached as tiles of bitmaps (starting as vector to save download), as the level might be up to 20,000 x 20,000 pixel in some cases. The bitmaps then have effects such as noise and glows applied to more closely replicate what Nathan is currently doing with his art. Some levels such as the peninsula (Escapade) have multiple levels of background and foreground. We then started adding the animated characters and enemies and found they too slowed the game to a carwl. So all of the animations needed to have each frame pre-cached as well, and kept in a frame cache in memory. Every sprite then works off the same frame information. With all of this caching some levels started to take up to 600mb of memory… which was the next issue. After overcoming the many trials of technically getting the game working, gameplay testing and debugging proceeded for about five months.

As i stated earlier, we’ve learned a lot about planning and developing a game, and think we’ll fair a little better in the future. As for Scarygirl, a standalone version might be on the horizon. We’d also love to look at other platforms too, such as iPhone; not sure if i want to learn Objective C too quickly though.

Well its good to see it released. We are still be making some notable tweaks, and are taking users comments into account, so the job still isn’t over yet, but there’s light at the end of the tunnel.

cheers

Tony – TouchMyPixel

Wednesday, February 11th, 2009

When AS3 came out many people, myself including, were frustrated and confused by the lack of a quick and dirty function to check whether a key was down (pressed). You can have a listener that gets fired when a key is pressed and see which key it was within that function. This could lead to someone putting all their key behaviour code in one spot which could become quite messy.

The best way to fix this is with a class that does all the heavy lifting for you. Without any any further ado here’s the test. Use the arrow keys, space, z and shift+z to try it out [source]:

Friday, November 28th, 2008

Apparantly drawing each frame of an animation to a single bitmap and then selecting a region to display is better for memory and speed than keeping each frame in its own bitmapData object.

The issue i’ve had is that for larger animations a sprite sheet of 2880×2880 is a little restrictive. To counter this ive modified bit101′s BigAssCanvas to allow a copyPixels of a rect, in order to get our frame data from a BIG Sprite sheet. This makes the test a little unfair, but small spritesheets are not an option for us.

The results are as follows:

uncached:  ~16fps
cached as frames: ~120fps
cached on spritesheet: ~70fps

memory usage:

frames: 249 856
spritesheet: 270 336

so caching each frame seems the way to go for us. There doesnt seem to be any advantage in the spritesheet. It might run faster if it was a single bitmapData object and direct coptyPixels – but who’s to say :P

Friday, November 28th, 2008

We needed to copy out the BitmapData from a BigAssCanvas so i added this to bit101s class. It doesnt really work like BitmapData's copyPixels - as that copys pixel INTO the bitmap object, so i've named it copyPixelsOut and it returns a new bitmapData of the rect.

You will notice the red lines at 2880 when you move the viewable region over them the data you are given is atually sourced from 2 bitmapData objects (inside the BigAssBitmap).

PS: Thanks to Jonno from Something Splendid for helping me when my maths brain had disappeared.

Its basically :

Actionscript:
  1. public function copyPixelsOut(rect:Rectangle, transparent:Boolean=true, fillColor:uint=0xff000000 ):BitmapData
  2. {
  3. var bitmapData:BitmapData = new BitmapData(rect.width, rect.height, transparent, fillColor);
  4.  
  5. for(var i:int = 0; i <_bitmaps.length; i++)
  6. {
  7. var bmp:Bitmap = _bitmaps[i] as Bitmap;
  8. var temp:Rectangle = rect.clone();
  9. temp.x -= bmp.x;
  10. temp.y -= bmp.y;
  11.  
  12. if(temp.intersects(new Rectangle(0,0,2880,2880))){
  13. bitmapData.copyPixels(bmp.bitmapData, temp, new Point());
  14. }
  15. }
  16.  
  17. return bitmapData;
  18. }

Wednesday, November 26th, 2008

Almost a year ago I was reading about how normal mapping works (on Wikipedia I think) and it struck me that this would be a great way to define a useful height map for games, maybe a mini golf game as an example.

My understanding is that normal maps work by encoding the X and Y angle difference from a flat surface (generally a polygon). That is the difference between a larger polygon from a low count polygon model, and the multiple polygons that made up a high count polygon model. This is normally saved as red and green channels. The blue channel (from what I could work out) was used in some way for height (or Z).

Thursday, June 19th, 2008

We've recently been playing around with a physics engines in Flash, including a little romance with Glaze, a slight flirting with PhysaXe and now seeming to settle for Box2D ... (the dependable old dog)

All these engines work only with convex polygons, and in no way support concave polygons. They do however support more than one shape (or polygon) in each of their rigid bodies. This gives us the change to fake concave shapes by making multiple convex ones. But how do we convert from concave to convex?

I did a bit of a search around and heard about such things as Ear Clipping and Minimum Convex Decomposition. The second I could even find code for (http://www.cs.ubc.ca/spider/snoeyink/demos/convdecomp/MCDDemo.html) which was awesome, and in Java none the less. But alas, even with the help of this awesome Java to AS3 converter, I failed at getting it to work.

Then I stumbled upon a great post on the Box2D forums "Concave Polygon Decomposition in Flash". Someone had converted an Ear Clipping example in Processsing to a JSFL tool. Sweet!

So between the two example I managed to cobble together some not too shabby AS3 classes, and an example app. I'm hoping to add this to our Box2D wrapper (more on that later) so we can easily draw concave polygons ASAP.

Have fun!

Friday, May 9th, 2008

When creating external libraries, you often want the contents to have have a base class from your application. When you do this however, the whole application will often be compiled into your library due to its imports. This means two issues arise:

1/ You have a whole lot of duplicate code comipiled into your libraries, which will not be used (as when the lib is loaded any classes of the same name will not override the existing ones)

2/ It takes a bloody long time to compile your library (when it should be fast)

Solution:
The best way we have found to get around this is to create a empty classes, which work similar to intrinsics (but are totally empty -no functions, vars or imports), to replicate the base class.

Eg.
If in your application you have a class for example: 'sprites.enemies.Monster'
In your lib you will want to create an asset with identifier: 'Lib_Monster' and base class 'sprites.enemies.Monster'. Normally this would compile in the full Monster class and all its dependencies.

If you set up your lib.swf in a seperate folder to the application then create another class, lets call it a placeholder class, 'sprites.enemies.Monster' and just have it empty eg:

Actionscript:
  1. package sprites.enemies
  2. {
  3.     import flash.display.MovieClip;
  4.     public class Monster extends MovieClip{
  5.         public function Monster{}
  6.     }
  7. }

When it compiles the Lib_Monster will have the correct baseclass, but it will not include any code.

The trick is that, when the lib is loaded into your application the class 'sprites.enemies.Monster' will conflict. The application should have its own compiled version (the one with functionality) and when the lib loads in, it will ditch its version (the empty one) and adopt the existing (correct) version.

It only takes a few seconds to create the placeholder class for the library reference.

If you want to have the lib.fla in the same folder as the application, then you can even set up a different classpath for the lib. To do this go tot the publish settings and add a new classpath (eg. ./intrinsics). This path will be checked first for your placeholder class.

If for some crazzzy reason your classes arn't used (and so compiled) in the application (if you reference them with weak references), you will need to force them to be compiled in like this.

Friday, May 9th, 2008

when you use the "import package.Class; " or "import package.*; " in AS3 the class(s) is not forced to be imported. A class is only imported if you use it somewhere in your code.

The simplest way is to just type its name:

Actionscript:
  1. import sprites.Ball
  2.  
  3. public function init(){
  4.    Ball;
  5.    // Or for many at once
  6.    (Ball,Dirt,Kid,People);
  7. }

Just simply typing the class type somwhere in your application will force it to compile in. Why is this of any use you may ask?

We use it for level building in games, where you have a generic component as a placeholder used in flash to lay out content/levels. Your Ball class for instance, might then simply build itself using externally loaded assets, and attach itself to the stage. It may not need to be referenced anywhere in the application, but is still compiled in.

Our Friends:

Powered by haXe / poko cms | Copyright 2008-09 TouchMyPixel