On a bitplane

Zynga and originality.

2012-02-02T13:13:00.003+01:00

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

2012-01-19T15:38:00.004+01:00

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

2011-12-15T00:47:00.002+01:00

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

2011-12-09T22:43:00.001+01:00

Bliss by Muse in 3 channels (Not easy):

For those with dead A600 or A1200 internal floppy drives.

2011-11-30T10:08:00.004+01:00

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.

Hola Amiga. Cuanto tiempo!

2011-11-28T14:57:00.002+01:00

It seems I'm now in possession of a stock A1200 with a second diskdrive (and the obligatory knackered mouse).

Now to give it a compact flash card, some means of transferring stuff and ideally a little extra RAM...

Reaxion lives (on the ZX Spectrum)

2011-11-02T00:27:00.000+01:00

It's been a long time coming...

2011-10-20T18:42:00.002+02:00

But I've nearly done it...

Hopefully my next game won't get delayed by half a decade of life happening.

You have to love how accurate Spectrum emulators are

2011-09-26T23:13:00.001+02:00

When you can just pipe the tape noise out of an emulator into a real machine and it loads perfectly every time (so long as you remember to emulate a machine with no YM soundchip, otherwise it gets confused)

Back on with the 68K/Amiga

2011-09-25T20:12:00.003+02:00

Seeing as I've passed my driving test I should now be able to nip off and pick up my* trusty Amiga 1200 and see if my code is as hardware-friendly as I hope it is. It's a stock 1200, but I'm hoping whatever I turn out will run on a stock Amiga 500 with 1Mb of RAM (I'm assuming 512k chip, 512k unknown).

In the meantime I've gone back to my scrollcode and it worked okay, but it made no use of the Blitter. I've corrected that now, although it took a couple of attempts to decipher the documentation for the minterm stuff.

The minterm docs run to a couple of pages and goes through boolean algebra and venn-diagrams, but it's really not as complicated as that. I reckon it should be explained like this:

You have a truth table for the 3 possible inputs. Just write in the fourth column where you want a 1 or 0 to be generated, and put those into the bottom byte of bltcon0 with the first row as the lowest bit. So a direct copy from A to D would be:

A	B	C	D
0	0	0	0
0	0	1	0
0	1	0	0
0	1	1	0
1	0	0	1
1	0	1	1
1	1	0	1
1	1	1	1

so reading bottom-to-top the bottom byte of bltcon0 would be 11110000. Also, the 4 bits before that are the flags to use each channel, so those would be 1001 to use only channels A and D.

All the other registers do exactly what they say on the tin and don't seem to hold any nasty surprises.

problem is the scroller has a buffer that is just over 2 screens wide and draws each character twice, so once the buffer has hardware scrolled to the second half the first half should be visually identical, so I can snap back to the first half with no visible effects whatsoever. It uses a little extra memory and 2 blits, but it should perform better than shifting the entire buffer in one blit and then drawing a character in a second blit.

My next Problem is that the code busy-waits on the first blit, and then carries on to do other things on the second blit, so it's wasting time it could potentially be using for other tasks and not making good use of the machine. My next task is to get the code to build a blit list and then have an interrupt handler to dispatch the jobs to the blitter when it's no longer busy. Definitely overkill for this little framework, but when I generalise it for a game engine I can run game logic and blitting in parallel and scrape more power out of the thing.

*Actually it belongs to my brother, but he's not using it...

It's not all retro you know...

2011-07-05T17:34:00.006+02:00

..although am coding this on an iPhone 3G, which some apple fanboys would consider oldschool.

I'm using a load of old graphics and code from some old university 2D openGL game assignment I did, fixing the fact that it's a bit of a mess (I learned the pitfalls of writing code that survives compiler changes, endian switches and being 64-bit friendly afterwards) and fixing it up for openGL ES.

Although I'm reusing some of the assets it is a different game (although inspired by a few 80s arcade machines) and hopefully should be a nice distraction worthy of the price of a pint of beer*

At the moment it's just a mishmash of code that gives the right results if you stare at it in the debugger, but looks nothing like a game yet, but I'm currently sat at home in a Lemsip-induced haze working on this so hopefully something should come together soon enough.

*half a pint if you live inside the M25.

Sometimes rebuilding can take a while...

2011-06-29T11:18:00.004+02:00

so I started playing with the previous code and knocked out a chunky scroller whilst I'm at it.

The WIP version I have also has a chessboard zoomer in the background, but it's a bit dodgy (I think my interrupts are overrunning a bit), so I've disabled it for this video. If I can't fix up the interrupts I'll seperate them out into seperate parts, fix the scroll position or find some other workaround.

Oddly enough the chessboard is less dependent on lookup tables than the one I did on the ST (It's generated from scratch) and uses a hell of a lot less rastertime to run. I think for a lot of what I want to do the SMS is more powerful than the ST :)

or it could just be my shoddy 68K assembler abilities...

2011-06-22T12:53:00.003+02:00

I've been playing with some Sega mastersystem coding. So far I've got a toolchain up and running that takes a level-sized bitmap, chunks it up, RLE compresses the columns of of tiledata and lets it run on the mastersystem.

The levelmap and graphics are from 'Edge Grinder' - an 8-bit collaborative project hosted at Format war led by Jason 'TMR' Kelk, and were designed for the C64, which is why all of the coloured pixels are double-width. They could be improved for the mastersystem and it's more liberal palette and 1x1 16 colour graphics mode, but at the moment I'm more concerned with getting the code up and running.

Looking at the Sega Megadrive/genesis it looks like it's pretty much the same technique to get things going there, albeit with nicer graphics and a faster 68000 CPU so when I have enough to be going on with I'm going to port it all across.

The sprites look like hassle though - I'm working with 8 sprites per line of 8 pixels width, as opposed to the 24 pixel wide ones on the C64 so it looks like things might get a little difficult.

Maybe a bit of flicker or creative use of background characters might be in order...

So... what happened?

2011-06-22T12:50:00.002+02:00

I started with good intentions, but then the whole financial crisis kicked in and it ended up being impossible for me to find a job in Spain, so I ended up on a flight back to the UK for an interview.

I got the job, returned to Spain to collect my stuff and then started working on graphics drivers which has kept me pretty damn busy until now. So I've ended up doing low-level coding but nothing I can talk about in public.

I've just started finding time to do code in my free time again, so watch this space.

Taking a break from 68k

2009-09-21T11:15:00.000+02:00

At least for a little while to write some tools. That's the beauty of crossdev - you can chew up relatively massive amounts of CPU time to distil your data into a form that is as close to being able to dump it straight into the hardware registers as possible. I prefer having my data this way because processing = time and time = limited. You could just go to google and look for native or crossdev tools that are out there already, but I couldn't find anything that did what I wanted (or in this case even work) so I ended up rolling my own. Maybe when it does everything I think it needs to do I might put it out there to save others the hassle.

First one up is the awe-inspiringly titled 'IFF Manager'.

Okay... maybe the least awe-inspiring screen shot ever, but it does actually work. I'm adding features as I need them but currently after unpacking an IFF picture file it can extract individual bitplanes in whole or rectangles for sprites (although at the moment the rectangles need to be byte-aligned) and output them as sequential bitplanes, interleaved to reduce Amiga blitter overhead or in ST screen format.

The code is factored nicely so I can wrap it up as a command line tool, build a GUI on top of it or maybe make the tool LUA scriptable to automate the cycle of modifying the graphics file and exporting the relevant data. Not sure what people would like for the best. I suppose I could combine the LUA and GUI options so if you start it from a prompt with a NOGUI parameter it'll just run as a (slightly bloated) commandline tool.

Playing nice with the OS

2009-09-14T11:12:00.000+02:00

I just had a quick count of what is needed to manage a graphics application on the 16/32 bit machines I've been playing with. The startup library contains exactly what is needed to leave the OS, get a working fullscreen display, wait for the vertical sync, swop the screen buffers and return to the operating system without killing other applications or causing a crash.

These are the results at the moment.

Amiga - about 120 lines of 68000, although a copperlist is needed on top of that, but that's application specific.

Atari ST - about 90 lines of 68000

Acorn Archimedes - 25 lines of ARM.

RISC OS is nice like that, you just ignore the operating system apart from a couple of calls to swop buffers, pick a screenmode and check for input and it restores itself afterwards.
The Amiga has the most heavyweight startup library, but even in the small example code I've knocked together I've saved more than the 30 lines difference between the ST and the Amiga (along with the associated rastertime).

It's a damn shame the Arc was so underrated, it gives the ST a bit of a kicking, although it falls short of the Amiga. Quite a respectable second place I reckon.

...And on to the Amiga

2009-09-11T15:00:00.001+02:00

Like many companies in the 1980s I decided to take my first steps onto the Amiga in the time-honoured traditional manner - by cutting and pasting my existing Atari ST code into Devpac Amiga and fiddling the screen output routines a bit. Okay it was slightly more effort than that, but not much. Most of the effort was put into removing code rather than adding it.

Although the screenshot doesn't seem to show much happening the screen is nicely divided up under the control of the copper coprocessor, with a 320x43x4 planes (16 colours) logo at the top, a 4-plane screenbuffer in the middle for rendering effects to (double buffered, naturally) and a 1-bitplane scrolling message along the bottom. There's also a protracker module playing in the background. Because the screen splits are all handled by the copper there's no interrupt uncertainty so the splits are 100% rock solid and no CPU time is lost.

The great thing here is the 'red bar of doom' code profiling method is in effect (turn the border red when your frameloop starts, turn it black when you're done and the thicker the red area the less CPU time you have) but there's nothing showing. If you remember I said the scroller alone on the ST used about 15% of the CPU time. In the Amiga code the bar doesn't even show.

This is what I love about the Amiga - the flexibility of the display hardware. It's a pain to set up (out of 3 days trying to get this going about half was spent just trying to get the screen setup without crashing the OS) but well worth it once you manage it. The ST version worked with an off-screen buffer 336 pixels wide (1 screen plus space for one character) and every frame each byte of graphics data had to be loaded, moved 2 bits to the left, the overflow put into the preceding byte and everything written back. It also had to be copied to the screen (not even using the fast block copies due to the annoying ST plane format) in the correct place.

The Amiga version is more cunning - the scroll buffer is now 84 bytes wide (twice as wide as it was) and each frame the hardware fine scroll is incremented by 2. when that overflows after moving 16 pixels the screen address is incremented 2 words until we've moved along to the right of the buffer. So where do we go then? well every 8 frames we draw the new character twice, so by the time we reach the right hand side of the buffer the left contains an identical copy of it so we can seamlessly snap back to the beginning. This means instead of moving 672 bytes left 2 pixels, then copying those 672 bytes to the screen as on the ST we're just writing 2 bytes every frame (for the fine scrolling), and 70 bytes every 8 frames (2 new characters to draw and to reset the graphics pointer).

Even with an increased resolution of 320x256 and an extra bitplane to bring us up to 32 colours it looks like there's going to be a lot more time on the Amiga for doing stuff.

..and I haven't even touched the blitter yet.

First steps in 68000

2009-09-11T14:13:00.001+02:00

During the late 80s/early 90s all the cool kids had an Amiga. Some pressed on with an ST but still they had their games. Then there was me. I rolled the dice once again and tried the time-tested 'It'll help me with my homework, dad!' line to get myself an Amiga.

He looked around the school computing room and came home with an Archimedes. Not the worst machine, but not exactly overflowing with games released on a weekly basis. Nevertheless it was a good machine for a coder - the ARM 2 wasn't bad, the 12mhz ARM250 was quite nice, the 256 colour palette was naff but it was a friendly machine to code for. And these days ARM is a pretty good skill to have all things considered - they're everywhere, just not that visible.

But coming from a commodore 64 with hardware sprites, rastersplits and videochip trickery I always longed for something with interesting hardware and a few tricks. So to occupy myself a little recently I decided to right the wrongs of the 1990s and jump in to starting out with 68000 assembler... More specifically the ST.

I started with the Atari because of the simpler architecture - A screenbuffer and... yup. That's about it really. It has a few things in common with the Amiga (planar graphics), the palette is only 16 colours and you don't have such fine control (unless you target the STe), no blitter (STe again) but I figured the less custom hardware to setup the less I could get wrong whilst learning the instruction set.

And here we have the generic 1980s logo and scroller. Bit rough codewise because although it runs at 50hz there's 86 out of 200 lines taken up with static logos and the remaining chessboar area takes about 60% of the CPU time.

The 1-bitplane scroller has to be manually rotated and is then copied into the screen buffer, using another 15-ish percent of the frametime. Not a problem though because the screen is controlled by 2 interrupts - one just below the first logo to set the palette for the 'effect area', and a second below it which swops the video pointers (this doesn't take effect until the next frame), calls the music player (which basically streams out YM soundlog format data) and sets the logo palettes. Not exactly awe-inspiring but not bad for a first attempt and kinda smooth.

There's a youtube video of it in all it's 'glory' stashed away here.

Now let's try the Amiga...