Cheers Jack

It looks like the founder of Commodore, Jack Tramiel is no more.

It's pretty safe to say that without the C64 I wouldn't have had so much fun with games, learned to code because 'the game I wanted wasn't exactly what was there' and then kind of accidentally fell into coding as a career. Likewise my family were definitely one of the masses, not the classes, so love or hate his 'get it out the door cheap' attitude I wouldn't be where I am without it.

so cheers for everything...

Those iOS trailer videos that everyone hates doing.

There's always a question on the touch arcade developers forum from someone trying to grab gameplay video for a trailer but they don't want the frame rate fluctuations of the simulator being picked up by screen camera software, or to spend a ton of cash on a hardware solution to capture from the device.

I do most of my coding within a windows framework, and switch to OS X to do a phone build periodically to check my code work, and that helps in this case.

KKapture by Farbrausch is a great capture tool - everything looks silky smooth every time, but this comes at a price. Basically the capture software lies to your software, telling it that it is running at a rock-solid 60FPS and grabs every frame it produces to stitch together a video. Your code is only producing 20FPS? No worries - it'll run slowly but it'll get there in the end and you'll still end up with a full-framerate video. The downside to this is that playing the game at that speed is either impossible or at least looks very unnatural.

To get around this I added 2 commandlines to my Windows framework - Record and playback. In record mode vsync is enabled, locking the gamecode to a constant 60hz framestep, and all touch events are logged to a file, along with the number of the frame they occured in. The random number used to seed the random number generator is also stashed away.
In playback mode the events contained in the file are passed into the application through the framework instead of the real input, so the game can be run through exactly as you played it.

Capture this noninteractive version with kkapture et voila! Nice smooth gameplay videos.

Of course, it assumes that the game will run at 60fps solid when recording input, but on an average PC if the game starts dropping frames this is probably the least of your worries. If your game isn't too heavy and your PC is fast enough you can probably kkapture it at 60FPS whilst playing it. In fact, in the case of Reaxion it runs above 60FPS whilst being captured.

Zynga and originality.

Isn't this bloke just a class act?




Moral of the story is this: If you see a Zynga game you would like to play don't bother - just Google it, find whatever they cloned to build it and go play that instead, thereby supporting the actual creative people who did the work.

Spending a little time on modern platforms - Reaxion lives on iOS

I haven't forgotten about Reaxion for the Spectrum - but time hasn't been on my side of late, but it's worked out easier to grab the odd moment here and there to put together a bit of C++ in windows. Problem is what I actually want to do is a smartphone game.

What I now have is a small lightweight openGL-based framework running that massages windows events into a format similar to those that come from iOS, and provides just enough primitive functions to allow image loading, screen drawing and timing to be handled in a way that is abstracted from the bulk of my game code. Once I had this running under windows it was a small matter of porting this little chunk of code to IOS, merging the 2 projects into a common folder structure and this was the result:



Now I have the advantage of being able to grab the odd minute that I find in front of a PC with visual studio installed to write and debug the game code, and then I can throw it all back onto my main machine and build for iOS. There are a few sacrifices in the way I've done this - multitouch isn't supported, I need to stub out gamecentre functions in the windows build and my current code is less than optimal, but it means I can hopefully get proof of concept games stuff done much quicker.

I'm currently using 'Reaxion' as a testbed for this, but I'm still undecided about releasing it...

Testing out Amiga algorithms the cheating way

Despite working for a 3D graphics IP company I've never actually tried coding any 3D stuff from the ground-up on an 8/16-bit machine and I figure I might want to give that a try someday.

The problem is that there's all sorts of places an algorithm can go wrong. Is my maths shoddy to start with? Have a made a mistake converting it to fixed-point? Or have I just misunderstood some instruction?

Although I grew up prodding around with an action replay (and to be fair using windbg on kernal mode drivers for windows isn't that much better) it's a bugger of a way of working, especially when the error might involving trashing memory so you've not got any way to investigate.

To help me solve the problem of at least getting the algorithm right I've knocked up a framework. All it does is allow you to set up a palette (using Amiga colour values), give you 1-5 bitplanes (plane 0 providing the LSB) and allow you to read and write from them with bounds checking. Once your function (which should draw a single frame) returns it dumps the plane contents to binary files and spits out a .bmp with the output.

So what does this mean? It means you can breakpoint, single-step and printf the smeg out of your code when you are developing it and write it all as C with floating point maths, just like a PC routine but with a wierd graphics configuration. Once I'm happy with that I can convert the algorithm to use fixed-point 16-bit maths and keep an eye on it as I go. When that's working fine I can subdivide the steps taken until it becomes pseudo-68k and all with pretty much the same level of comfort as debugging a windows application.

By that point the remaining thing to do would be to convert it to 68k assembler (which should be a line-by-line translation if I've kept to the plan) and hope I don't introduce any bugs along the way.

Taking a break to play with some C64 music

Bliss by Muse in 3 channels (Not easy):

For those with dead A600 or A1200 internal floppy drives.

This bloke does a decent job at going through the process:




There is a bit of the video missing though, but for that part:

towards the front of the drive there are a couple of tabs which can gently be pushed outwards, allowing you to lift the second layer of the top of the casing. Once you've lifted the top part take care to lift the top read/write head clear before sliding the casing clear of the drive.

And don't worry about the spring that infuriated the bloke in the video - you don't actually need to remove that at all.

About 5 minutes with cotton wool buds and some cheap alcohol-based makeup remover and it was booting right up again.