I was interested to see what the performance difference would be between rendering each tile to the screen for three layers, versus rendering three individual layer images. Unsurprisingly, the latter is much faster on my machine! This does, however, raise an important point - for that speed gain, is it worth a ridiculous increase in memory usage? Consider a 64*64 tile map with 32*32 pixel tiles. That's a 2048*2048 bitmap, and since flash decompresses any images into memory (and for good reason) one would run out of memory incredibly quickly with multiple layers. I'm only referring to the case of scrolling of course, but nevertheless I felt it worth confirming by experiment. I'm only going to be doing this for a menu screen I think.

Sooo, I wanna make a top down racing game... and I've started playing with it. Currently, my hope is to be able to take the level image and just turn it into a collision map - in this demo, all cells with any non alpha pixels are marked in a tiled map as collidable, and then we do a broad phase followed by a pixel level collision search. Which is sort of ok, but the car (star) still gets stuck occasionally. I'm guessing some maths is in order :) Experiment here: woopwoop

I partially used some code from Emanuele Feronato's top down racing tutorial that rotates the player when a collision is detected - but it's not the smooth motion I want. I think I can project out of the collision smoothly using the current angle and velocity but it's late now.

[EDIT]

Having had one last play, I reckon it's getting there but It could definately be smoother in places.

[EDIT 2]

Seems to be working fine now! Adapted the code from emanuele feronato's site. I think parsing an svg to create polygons is a better way to approach the problem than per-pixel collision detection though, once I've implemented that I'll post a tutorial!

So, I wrote this little game:

SUPERAWESOMETANKS I need to change the happy star to be a bullet. But it has comedy value I think :D PLAY IT

So for fun I ported the example as3 scroller I did yesterday to PulpCore, which has turned out rather nicely - performance in IE and Firefox seems to be the same this time. It's pretty much the same code, with fixed timestep used again for scrolling updates. here it is! - I don't use PulpCore's Scene2d or anything, just blit from a spritesheet to the graphics context. Seems to work ok :S

I've modified the last example to read from a simple tiled map now, so the scroller uses a tilesheet instead of loading one large background image to scroll. I'm still upset about performance in IE, I've even tried Jeff Fulton's game loop in place of the one I've been working with, to no avail... So sadly this means that, in firefox, I'm pretty confident that the last few experiments should run smoothly, but not in ie :(

This example contains the basic code for a little scrolling tank game that I'm going to try and knock out sometime this weekend, and should work just as well with arbitrarily large maps!

[EDIT]

After some more experimentation, keeping the scroll speed low masks the jerking issue exhibited in IE, and for a 'tanks' game this would be fine... but for something like sonic the hedgehog it would sadly be very noticeable.

I wanted to add some other tests to the experiment I made the other day, since I want to use this in a tile engine - so for this, we need to be able to iterate through (width/tilesize) by (height/tilesize). That way we can just have one tileset image and just use traditional tile engine methods to draw our levels. So I simulated this in the new demo, with the following:

//draw the mask image with transparency
for(var x : int = 0; x < bg.width/32; x++){
  for(var y : int = 0; y < bg.height/32; y++){
    bg.copyPixels(msk,new Rectangle(x*32,y*32,32,32),
    new Point(x*32,y*32));
  }
}

Performance is actually fine; in the latest iteration which is here, we have a background image which you scroll, and which is drawn thusly:

//draw scroll image
bg.copyPixels(im,new Rectangle(sx-bg.width,sy-bg.height,
              bg.width,bg.height),new Point(0,0));

It then has some nice stars that are rotated using matrix operations and the BitmapData draw() method; I was just playing around with it as I would really use a spritesheet for that kind of thing (seeing as the whole point of managing your own rendering via BitmapData blitting is to avoid the flash vector renderer!). All in all performance is quite good, so I'll probably use the tilesheet method to implement scrolling (as having a separate image for each level seems a tad wasteful!)

Having had a read of Gafferongames' physics related articles, I started messing around with some improvements to my game loop. The result of my playing is this experiment, which combines scrolling based on copypixels with a fixed timestep game loop. WASD to move around, apologies for the boring image :D I think I might knock up a little tank shooter based on this now...

I've decided objective c is not fun. Here's a wee example:

AS3:

var x:String = "hello world";
x = x.replace("world","cheese");

Objective-C:

NSString *x = @"hello world";
x = [x stringByReplacingOccurrenceOfString:@"world",
withString:@"cheese"];

I mean, really? Is such a method name strictly necessary? Apparently one can leave out the param name but even then it seems excessive...

Sooo, having spent the last couple of weeks coming up with a tile engine in AS3, and having come up with some speed optimizations, and having added support for tiled maps I still feel that performance is somewhat lacking [EDIT: not anymore, at least in firefox and the standalone player]. So I've half a mind to port the engine as it stands (for the third time!) to PulpCore, an engine I saw mentioned ages ago on the Slick forums, but never got round to playing with. Performance looks to be incredible, their demos really are very smooth and impressive!

So I translated my javascript tile engine as it stands to AS3 and did some more artwork for it. It's shaping up ok, although I still need to implement multiple rooms/scrolling depending on what Mieke's Adventure demands! I still maintain that if I had reliable audio playback I'd keep the whole thing in javascript, but I suppose flash is ok too :)