Odin Computer Graphics Part Two : 1986 - 1987

Continued from part one.

That Telecomsoft Deal

On the strength of the commercial success of Nodes of Yesod and Robin of the Wood, Odin Managing Director Paul McKenna had convinced British Telecom (in the shape of Telecomsoft, aka Firebird - I've used the names interchangeably in this post) to pay us a (middle, UK pounds) six-figure fee in return for 10 games (or equivalents, with ports counting as half a game), which were to be delivered over the space of 1 year. It was a lucrative deal for us, but very aggressive obviously. That's about all there is to say about this deal right now, but it was to flavor just about everything Odin did from this point out.

Heartland Spectrum

Notch number one for Firebird. Heartland was created by Colin Grunes (who had done the animation for Astro Charlie in Nodes) and myself, with others pitching in here and there. The gameplay was very simple, and I suppose ultimately the game was a vehicle for Colin's excellent animations and backdrops, and for some new coding ideas I had. 

I think there was definitely a feeling of quality about the game, due to these same two things: first, Colin's graphics, and second the masking technique used on the sprite objects and various background (or foreground I guess) objects - this technique tended to give a "gliding" impression, as various screen objects slid behind or in front of each other.

The sprite objects used a "masking" technique whereby every row of pixels in a masked object had a corresponding mask which was applied to the underlying background to create a "hole" into which the new object will be drawn. The net result on screen is to give objects a more solid appearance (although you do not get full value from the 2 bits needed per pixel - that would give 4 colors and you really only get 3 this way, pixel off, pixel on, transparent). The order in which objects are drawn determines their "priority" or "layer".

Because we wanted to avoid loading between levels, it was determined that all graphics should fit into memory. This caused quite a headache because there were 5 levels, and the additional memory overhead of the masks didn't help.

In the end, I decided that the only way to make it all fit would be to generate the masks programmatically as each level was initialized. The main character, all the enemies, weapon projectile animations, plus various background objects were all masked. With some careful attention (by Colin) to what space individual pixels occupied, it proved perfectly feasible to generate the masks on the fly. Basically, each graphic was copied to a buffer. It was then shifted left by one pixel and OR'd in with the original shape. Next, it was shifted right by one pixel and OR'd into the accumulation buffer. Next, the whole image was shifted up and OR'd back into the accumulator, then shifted down, etc. Finally, the whole accumulator was bitwise inverted to create the final mask.

The game used a similar dirty rectangle method to Robin of the Wood, which worked fine with the masking technique provided things were restored in the right order. The combination of all the masking, coupled with the dirty rectangle stuff, hit the frame rate quite hard, so it's a good job the game design didn't call for lots of fast reflex action. :-)

I always wished there'd been more than one height (the ground) to it - that it was more of a platform game rather than just a maze. In the end, time was the limiting factor, but as it stands Heartland is a charming maze/puzzle game, with a little blasting of various bad guys thrown in for good measure.

For a more in-depth discussion of Heartland, check out my detailed "making of" post here.

Again, Heartland was written 100% in Z80 assembler using the trusty BBC tools. Heartland was launched to a decent press reception.

Fit Birds Apply Within

This is a UK colloquialism, which roughly translated might read, "Attractive Women Wanted". A sign like this inexplicably appeared in the Odin window one day (until management aka Paul found out). The unlikely outcome was that this (directly or indirectly) led to one of the Odin programmers getting married! I guess I feel obliged to add, "it was a different time".

Nodes of Yesod Amstrad CPC

It seemed natural for Odin to create an Amstrad version of Nodes, though I declined to do the work (too busy with other things). So, a young programmer called Stefan Walker was hired to do the job. The game was completed and ran in CPC mode 1 4-color mode, but not before Stef had entertained us with various amusing incidents. On one occasion, Stef was excited to show us his progress - the game was playable for the first time! - and so we all gathered around. And, voila - here's Nodes of Yesod on the CPC! One problem - the entire screen was upside down. Stef had taken some advice from other programmer staff members and was drawing the sprites from the bottom-up to avoid (or minimize) flicker as you catch the raster. So, Stef was logically pointing his graphics draw to the end of each graphic and stepping back through the data. He'd forgotten to do the analog process on the screen though. Stef did fix that before shipping. :)

The CPC version turned out OK but I think Stef parted ways with Odin once the game was complete.

When the Wind Blows

Paul had picked up on the new animated movie, When the Wind Blows, which was written by Raymond Briggs (author of The Snowman). I remember going on a company outing to watch the film at the local ABC cinema. After some negotiations with the rights holders, we believed we were very close to closing the license deal on the movie, but at the last minute, Mr. Briggs had some misgivings and decided he didn't want a video game based on his story. Instead, his camp told us, the Snowman license was up for renewal (there had already been at least one Snowman video game). We passed, and so nothing came of this. Even though we presented a design document (which I helped create, the game was to be built on the Heartland engine) to the licensor, I was always uneasy about how we could have made a game out of this particular movie. The subject material is pretty dark. In retrospect, I don't remember how this fits in with the timing of the Telecomsoft deal. I have a firm recollection of this being post-Heartland which would put it in the Telecomsoft timeframe.

Robin of the Woods CPC

This game did not see the light of day, but we did make a start on it. We contracted with a remote external programmer who would come into the office periodically to show us his progress. For some reason, the progress was very slow and soon the project was canceled and shelved. Unfortunate really because (judging by how Heartland would turn out) RotW could have been a very nice CPC game. I think we considered picking it up in-house (probably would have been yours truly), but it was only worth half a point on the Telecomsoft scale, so we focused on making original games. Note: since RotW was completed prior to the Telecomsoft deal, it is possible that any port of this game would also be outside the scope of the agreement.

Heartland Amstrad CPC

On the Firebird scale, this counted for half a game, as it was a port. I enjoyed doing the port, as I recall it was done really quickly and I think I did most of it working from home. Colin did a great job refactoring all the graphics for the CPC low res (160x200) 16 color mode, which is kinda chunky, but colorful nonetheless. The game played quicker on the CPC since the masking was done almost for free by virtue of the 16 color mode (color 0 as transparent, 15 other colors to play with). No need to precompute masks - just draw stuff in the order you want to see it on screen.

I'm pretty sure there was a tape version, as well as the disk version. I have a feeling the code was compiled on the Amstrad PCW8256 (again running the friendly neighborhood M80/L80/Memo combination under CPM). Actually, we were considering making PCW versions of our Spectrum titles, but the market seemed uncertain. I do remember playing Batman (from Ocean) on this system though - and very good it was too.

See the Heartland post for a bit more detail.

Sidewize Spectrum

I posted here about how the scrolling backdrops for Sidewize were created, and here about how how the screen updates were synchronized with the display.

Notch number 2.5 for Firebird, there were two things that motivated and inspired Sidewize: Delta on the C64 (pretty cool shooter, even though it was on C64 :) and my desire to build a Spectrum game that ran at 50 fps.

Delta on C64 was a simple sideways shooter game, but it was smooth, had lots of (multiplexed, I believe) sprites, and the enemy attack patterns were cool. Being a C64 game, it ran @ 50 fps. I wanted to do something equivalent on the Spectrum.

I spent untold hours exploring ways to extract the maximum performance from the Spectrum. In order to accomplish a 50hz update rate, there are a number of considerations. First, all the game logic must run in 1/50 of a second, in addition to screen update code. Of course, it is not acceptable for the screen to flicker. Next, the gameplay cannot be so trivial that the game is pointless to play - there has to be a challenge. A sideways scrolling shooter naturally lends itself to this - the logic is not too hard, but the challenge to a player can be very high.

I made a couple of interesting discoveries along the way. The first was that the CPU stack is the quickest way to update the screen (at the cost of more unrolled instructions, and a little extra complexity). The stack also proved to be a very effective way of pulling source data from memory (for a sprite, for example). As you'll see on the Crosswize section later on, it is also possible to do both at the same time (that is, use the stack to pull graphics data from memory, then do some stack pointer manipulation to point the stack at the screen and update the screen using the stack). Sidewize had a much less elaborate version of the Crosswize system, and I'll talk about that here shortly.

The other discovery was based on a rumor that was going around at the time, which is that "there is a port on the Spectrum where you can read the current attribute value". I was never told which port that was (or at least, it didn't work as advertised when I tried it) but I did discover a useful variant. I found that by reading port 0x40FF, you could in fact read the current attribute value (meaning, the current color of the screen area that the display raster crossing), in addition to some other values which I took to be bitmap bytes. I believe the attribute value finds its way onto the bus due to some side effect of the way the Spectrum ULA works (the so-called "floating bus" in the Spectrum), but ultimately this allows you to wait for a specific point on the screen if you manage your screen attributes carefully. 

Not quite as nice as a horizontal blanking interrupt, but useful nonetheless. I ended up waiting for the very bottom of the useful gameplay area (this was essentially the top two-thirds of the screen - the status panel lived below). Here's how that code looked in Sidewize (this code checks for the raster crossing bright black attributes, which only occur in one position on the screen, a single line of bright black attributes directly under the active play area):

1 2 3 4 5 6 7 8

LD BC,40FFh LD E,40h ; bright black WAIT: LD A,R IN A,(C) CP E JP NZ,WAIT RET

Since I now knew that the raster was not in the active game area, it was now safe to start updating the screen (so you get much more time than simply doing a vertical blanking wait). I took great care to update the screen from the top to the bottom where possible, so that, worst case, you'd be as far ahead of the raster on the next video field as possible.

Of course, the screen has to be drawn quickly. Sidewize has two types of backgrounds: type A, a scrolling starfield which filled two-thirds of the screen (ie, the active playing area); and type B, a scrolling starfield filling the top one-third, with a scrolling "landscape" in the middle third of the screen.

In type A, the sprites simply erased themselves using our friend the dirty rectangle. The clear code was very fast, however, pointing the stack at the screen and blasting pre-zeroed registers at the screen. When the scrolling landscape came into play in type B, the landscape itself was drawn using the stack (again, using preloaded registers) and since the whole middle third of the screen was redrawn every frame, there was no need to erase the sprites in that region. The landscape relied on a repeating block pattern, 64 pixels wide (8 bytes, or 4 register pairs) by 64 pixels tall, which was pre-shifted in memory (the block wrapped around left to right, eight versions, shifted 2 pixels each), so that after you draw the block in the same place 8 times, you just need to start drawing it 16 pixels to the left the next time around to achieve smooth scrolling.

The PUSH RR instruction (where RR is a register pair) accomplishes a 16-bit move to memory via a second register pair (the stack pointer in this case) with pre-decrement. All this in a 1-byte opcode! This makes it much faster than LDD (for example) which only moves one byte and requires a source and destination register pair. The inverse is true for POP RR for pulling data from the stack.

The sprite routines similarly used the stack to point to the source of the sprite data. It is very convenient to do something like:

1 2 3 4 5 6

pop de ;grab source byte and mask ld a,(hl) ;grab byte from screen and e ;apply mask for sprite (make hole in screen) or d ;or in the sprite data ld (hl),a ;write the updated byte to the screen inc l ;step to next screen byte

The alternative might look something like this:

1 2 3 4 5 6 7 8 9

ld a,(de) ;grab the screen byte ld c,(hl) ;grab mask byte and c ;apply the mask inc hl ;step to sprite data byte ld c,(hl) ;grab data byte or c ;merge in the sprite data inc hl ld (de),a ;write combined byte to screen inc de ;step screen

As you may have gathered, I'm a fan of the stack pointer on Z80. :) I did go on to use similar techniques on 68000 a little later on. Blame the Spectrum. :)

Sidewize played very smoothly, although looking at it now, it is very monochromatic (there was a color theme for each of the levels - well, really more of a "color" than a "color theme") with the cyan level, the yellow level, the magenta level, the white level. Crosswize added color in here, as another improvement.

Unfortunately, the ULA "bug" with the attribute value finding its way onto the bus was not reliable across Spectrum revisions, and in fact, this method did not work at all on some later Spectrum issues. It does appear to work on in some recent Spectrum emulators, however (though not in the emulator that was used to capture the animated scene extracts above, where it looks like the player's weapons are not rendering).

I was playing the game on an emulator recently (after I hacked out the "attribute wait" code) and was reminded of the "congratulations" message displayed upon completing the game after defeating the "Mega Prawn" boss on the final level. These immortal words appeared on the screen:

Mmmm. I was rather partial to a Prawn Bhuna at the time. :) I also love the fact that the Megaprawn features on the packaging artwork.

Telecomsoft (post-Odin, I think) did a conversion to C64 without my knowledge or assistance. What was a reasonable technical accomplishment on the Spectrum looked pretty average (crap) on the C64 (no attempt had been made to add color or more detailed scrolling). Certainly, it was no Delta! The music sounded pretty good, though.

One minor point of detail, and this was probably indicative of something, is that by the time Sidewize was done, we had lost the fight to keep the Firebird logo off the loading screen for the game. Heartland was just Odin Computer Graphics, Sidewize had both. Additionally, the packaging art was not done by Gerry Fisher, another first for an Odin title. I wish I could remember what happened there because the game's loading screen is not based on the packaging, another first.

Another 100% Z80 assembly language game, Sidewize was launched to decent reviews on the Spectrum, not so much on the surreptitious C64 port done independently by Firebird.

Enter the AMIGA

Sometime during 1986, we acquired several Commodore Amigas (the first in Europe, some say). I remember Paul driving Marc and me down to Birmingham in his Range Rover one dark and rainy evening to collect the machines. There was much excitement around the office - I think we eventually ended up with 5 x A1000 Amigas, with 256KB of RAM, External 256KB expansion, Kickstart booting from floppy disk, etc.

The two things that impressed me most initially about the machine (one landed on my desk) were DPaint (still the best paint package I've ever used - ProMotion on the PC is a great modern-day Windows clone, or at least it was the last time I used it, which is probably about 10-15 years ago now -  and the fact that these machines could speak (using the Say command from the command line). One of our artists was very perplexed when his Amiga started talking to him one morning when he turned it on. He thought he'd had some really good stuff the night before. :)

The Amiga text editor we were using was very dicey - even compared to the CP/M stuff I was accustomed to (though I don't recall off-hand which editor it was). The assembler seemed OK - I believe we were using the Metacomco assembler at that time. These were early Amiga days though, so we took what we could. Things obviously improved later on.

Back to the plot. Odin still had commitments to Telecomsoft (boy, did we ever) and the titles were all Spectrum and C64 titles, so the Amiga stuff really didn't fit into that picture.

Marc and I did manage to make a little progress on the Amiga. He had some simple scrolling happening with some hardware sprites. I seem to recall that I had some boxes bouncing around the screen - possibly some Heartland characters. Some of our artists produced some amazing-looking stuff as they got to grips with (shock) 32 color mode; however, we did not get anywhere near a complete product, let alone a prototype or even a design. It was clear that the future of Odin depended on the Telecom deal, and so the Amiga stuff was effectively put on hold while we focused on the 8-bit titles.

And that was about it for the Amiga, apart from ...

Electronic Arts?

At around this time (1987), a certain US-based publisher was looking to establish a UK operation. I believe the intention was to set up a sales and marketing operation, possibly with distribution included. And so it was, after a series of phone calls by Paul to the US office of Electronic Arts, that a certain Mark Lewis came to be in Liverpool, meeting with Paul, and taking a close look at the Odin facility, and at the development work in progress.

As an aside. I'll never forget how Paul was able to just able to pick up the phone - we were not even in Paul's office, he was using a wall-mounted phone near Marc's desk - cold-call the front desk of Electronic Arts in San Mateo, California, and be put through to a business development person. This was pretty typical of the way Paul worked and I witnessed many similar examples.

Paul had a way with words, and though I was not a party to the discussions between Paul and Mark, I did get to meet Mark as he was toured around the Odin building. I believe discussions were along the lines of EA entering into some sort of deal to take over the building (which had warehouse space, remember), with additional talks about the Amiga development that was underway (all the Amigas were powered up and looking business-like for this tour and I did exchange a few words with Mark at the time).

It didn't amount to anything, ultimately, but it is a testament to Paul's salesmanship that EA would even talk to a company like Odin, let alone send the future MD of its European operation to visit.

What's all this, then?

Odin's Firebird deal meant we had to deliver 10 games inside one year. I am sure that Telecomsoft expected (or at least desired) 10 games of the quality of Nodes of Yesod. But, attempting to deliver 10 games of that caliber within 1 year was impossible, and so this time pressure, almost by definition, led to some rushed products. A few were published, such as ICUPS, Mission AD, On The Tiles, and The Plot (about the Guy Fawkes gunpowder plot). The non-published titles included: 

• UFO. This was "inspired" by an arcade game of the time. Funnily enough, the reason it seemed like a good idea was that the arcade game was so primitive (i.e, possible on meager 8-bit platforms). Pretty uninspiring stuff. Note: Frank Gasking points out that this game actually did ship. The reviews listed there line up with my recollection of the game.
• Gladiator Fighting Game. An early fighting game, no doubt inspired by the stuff appearing in the arcades at the time. Screens here.
• Tank Game. This one had some design merit, but it was just too late to make any difference and was a long way from being finished. 
• PLOD A sideways scrolling shooter called PLOD. I don't recall much about this except for the weird name, and the fact that Joffa Smith helped programmer Dougie Burns with some cool graphics.
• Lusitania. A game about a sunken ship. Pretty ironic, really.  Screens here.

As a quick aside on this, when I later worked directly with Telecomsoft on Crosswize, they offered me a deal to deliver 1 game per month for 1 year for £20,000, and while the £20K might have sounded attractive to 1987 me (not really, actually, that's about £50K in 2022 pounds), I think BT generally had some very unrealistic expectations for what was possible, at what quality, in what timeframe. I did not take that deal, but I am self-aware enough to see that there's an element of pot-kettle-black here with respect to the Odin situation.

Odin's Demise

And so came Odin's demise. The situation with Telecomsoft became very tense. Paul's position was that we had delivered the agreed-upon number of titles, Telecomsoft did not agree. We were at an impasse, with Telecomsoft refusing to accept or pay for a number of titles. This turned out to be the fatal blow for Odin who had invested everything into building the Telecomsoft games. As a last resort, we did try to shop some of these titles around to other publishers, but nobody was biting. Honestly, some of them were pretty poor games.

We struggled on. Sidewize was completed without pay, and this really cranked up my personal financial stress levels. Paul McKenna had some great ideas. He was amongst the first in the UK to see the coming potential of the Amiga platform, for example. He had some good ideas for games; however, Odin was unable to make the leap from one team working on one game to multiple teams on multiple projects. We just didn't have enough experience in product management and production management.

Ultimately, Odin made a messy crash landing and everyone was forced to go their separate ways and find alternative ways of paying the bills. Perhaps I could find some work as an independent developer?

Goodbye, Canning Place

Canning Place during demolition (image via Twitter)

On a trip back to England around 2000, I had the occasion to visit Liverpool. I was surprised to see that Canning Place (the erstwhile home of Odin Computer Graphics) had been completely demolished. Odin was in a tower block (albeit at ground, or mezzanine level) and this was no small structure. At the time there were billboards around the demolition site stating that it was to be the site for some sort of science museum or another such venue. Looking at Google Maps it seems that it is actually a Hilton Hotel now. Since the site is directly across "dock road" from the Albert Dock (one of Liverpool's biggest tourist draws) it really isn't surprising that the boring, grey concrete, 1960's office block is making way for more tourist attractions (though I have to say that the Hilton that stands on the site has an uncanny resemblance to the old Odin era structure). Still, it was sad to see the building in rubble.

Addendum

I should point out that at no time did Telecomsoft own the Odin IP, it was more of an exclusive publishing agreement. This explains why in more recent years we've been able to publish such things as Nodes of Yesod for the iPhone devices and license these games to various emulator producers.