Your question isn't very clear!

I mean sure, you can centre bitmap graphics in the sense that you can put them anywhere you like on the screen. But presumably that's not what you meant?

Does anyone know of any way I can achieve this?

The hitTest method on BitmapData can do this provided that your images have transparent pixels wherever you don't want them to collide.

You need to set secondObject to be the other game image's BitmapData (the one that isn't getting the method called on it). For most games your game coordinate system can be used directly to fill the two Point parameters.

Impressive... looks like I'd better ready my crayons!

If you've got the skills to make an iPhone game you could try guru.com as a source of money, maybe?

The other thing to bear in mind about London is that it's really too large to be considered one place. How good it is as a venue depends very much on exactly where in London we'd be. The centre is fun, but way too expensive accommodation-wise, whilst most of the bits further out are significantly inferior to Oxford or Cambridge.

What sorts of venues seem likely?

i'm pretty sure it is some sort of memory corruption

Is there any way with the debug system you're using to switch on some kind of "guard page" style thing to trap bad memory accesses?

Just completed it - very nice game! 

I can see why you had trouble selling it, though. The gameplay mechanics are simple and elegant, but the theme's really surreal. In fact it seemed like a bad choice to me until I was most of the way through the game and suddenly saw the point (as it became clear how the new scenic content was generated).

I'll be interested to see how many plays it gets. I assume you get that data?

Ewww!

I sounds like the clip you're importing has had some kind of weird framerate pulldown applied to it. Certainly it's not really at 30fps, even if something has told you it is.

Do you have the option to produce/export it in some much less processed format in preference to H.264? You said AVI was bad due to "no control over codecs", but I'm not quite sure what you mean there. Camstudio -> AVI -> After Effects -> FLV is the workflow I would use myself under WinXP.

Those are excellent! 

I particularly love the mechanics. Facial hair FTW!

I'm no After Effects expert, but since it doesn't seem likely there are many of those here I'll make a few suggestions anyway (I do use the package)...

1) Select "Composition Settings" (for example, from the menu in the top corner of the Composition window).

2) Make sure the dimensions of the Composition are set as you want them, that the pixel aspect ratio is set to "square pixels", that the frame rate is set to whatever you want the output to run at (not whatever your input is in), that the start timecode is zeroed and that the end timecode corresponds to the length of the clip (note: fractional seconds are not hundredths, the denominator is the frames per second).

3) With the Composition selected, choose "Make Movie" from the Composition menu. This will add your clip to the Render Queue. DO NOT render it yet.

4) In the Render Queue, click on the output module entry (probably yellow and underlined, probably currently set to "Lossless").

5) Change the output format to FLV (never use any other format unless you're forced to). Ensure the Video Output is ticked and set to RGB/"Millions of colours"/Premultiplied. Ensure the "Audio Output" is ticked (note: it isn't by default) and set to 48000 kHZ, 16 bit, Stereo.

6) If required, click on the "Output To" setting and make sure it's going to save it somewhere sensible.

7) Save the Project, then hit the "Render" button for the Render Queue.

Wait for (probably) a long time. (Sorry about the "cool smiley"... it's number "8"!)

9) Check the output FLV in Adobe Media Player. (No, not your favourite playback software, always start by checking it with Adobe Media Player.)

10) After Effects doesn't do anything special with disk management, so the only way to get a "lack of disk space" error is if it's getting an error back from the OS. Is it possible your disk is extremely fragmented or suffering from high latency?

There are two basic techniques for animating bitmaps, at least one of which should help:

* If you're using a BitmapData buffer for all your rendering you can simply store each animation frame as a separate BitmapData or separate region within a larger BitmapData and render (via BitmapData.copyPixels) only what you need. This reduces the problem of animation to the need to draw correctly aligned frames and some way to work out which frame you want.

* If you're using the display list (that is, building a hierarchy using addChild on some DisplayObjectContainer) then the "visible" property of DisplayObject can be used to animate things. Store each frame as a different object and set only the one you want to visible (having added them all to some container specific to the individual game object).

Animating vector graphics is just a question of modifying the drawing parameters each frame (position, rotation and so on). It's not all that easy, but not so much for lack of API support as because it's inherently not easy!

I think it is a fun exercise to imagine how your design and business would be different if you were trying to make a game that was part of a player's life for weeks instead of minutes or hours.

Ten year project cycles and impossible funding difficulties!

I cannot see why fixed rotation should affect Box2D's ability to sleep bodies

It doesn't per-se. It matters because it means the object will always have only a single point of contact. Compare this with a typical rigid body: in a situation where the latter is almost at rest there will be some contact pretty much ever frame, so it will lose energy quickly.

or how frequently it is on contact

I contend that it does affect this (see above).

stopping on a slope requires the object to be put to sleep

The sleep system works fine. In cases where this problem arises, the object is never eligible for sleep.

I'm a relatively good programmer. At least I assume I am, since people seem to want to pay me large sums of money to write code (not games, sadly).

Scope clearly exists to do something like PacManhattan, but fully automated. Also, augmented reality is a good area to explore if the camera APIs are good enough.

Is this right?! I thought that this was only a problem in position-based sims, and that box2D handled this nicely. At least, from the demos it seemed like objects did fully come to rest on slopes..

It is right, but I perhaps didn't explain it as clearly as I might have done.

Objects can come to rest on slopes in Box2D and frequently will, but when you have an object with a single point of contact (which Glaiel does since he's preventing his box from rotating) that will result in complete iterations where there is no collision at all, so the object will bounce down the slope in a series of tiny hops (maybe several per video frame, since Box2D is normally run at a higher rate than the frame rate).

Since then, the game doesn't seem to want to start again after you die once... I have no idea why, though...

The most likely reason is that something you do during the second game start is throwing a runtime Error.

You can find out what by inserting a try/catch block around your game object creation code (and possibly another one in the body of the step function) and calling getStackTrace() on any Errors you catch.

Looking at your code, I'd recommend that you get into the habit of writing an init() function and a deinit() function for complex classes to keep your resource management in one place and hopefully make it more comprehensible, then remove all code from the constructors of your classes (except for possibly a call to init()). You might think it's a bit weird to be writing a deinit() function in a garbage collected language, but in fact it's a very good idea for large, monolithic classes like this which use lots of resources (such as event listeners) which survive after their destruction.

For example, your current code fails to clear up its keyboard events before returning to the menu.

Also, as a general debugging tip for this kind of problem: put tracing everywhere. At the very least you want a line of tracing at the entry point for each event handler and at each exit point. There is no such thing as too much tracing. (My record so far was debugging a VP Assembler program which generated a 4GB trace file... and yes, it did find the problem!)

You can't.

Well OK, let me clarify that a bit: "friction" in Box2D is a force perpendicular to the collision normal. The trouble is, whilst this makes sliding objects along flat surfaces quite realistically difficult it's not very good for slopes because keeping only the normal component of each reaction will leave the object very slightly in the air, at which point gravity will move the object back down, taking it slightly along the sloped surface in the process.

There are quite a lot of things you could do to hack in a solution, but they're all quite ugly. (For example, if you detect a very low-velocity collision involving such an object then just forcibly zero its motion and explicitly put it to sleep!)

Uh oh... we'll have to pause this discussion gentlemen . I have some actual grumpiness I wish to report:

It's looking like I'll have to rewrite my game's entire graphics layer almost from scratch. This close to IGF, this is definitely not a good thing.

Oh well, on the plus side at least it's not a 3D game or that would add a couple of years to the project.

(For the record, my critical error was to assume I could composite layers in any order without much performance overhead. This is very wrong if some layers are only a few pixels across and others are full screen! )

The three cities I've lived in are Cambridge, Oxford and London, so I approve of all three options... and might actually be able to attend this time (!).