Aonic, Sonic on the Amiga: Chris White on pushing the A1200 to its limits

We interviewed Chris White, better known as REASSEMBLER, the developer behind Aonic, the Amiga port of Sonic the Hedgehog. Chris spoke to us about the limits of a stock Amiga 1200, the challenges still ahead and what it would take for him to consider Aonic complete.

Now that people can actually run Aonic rather than just watch development videos, has the public demo taught you anything unexpected about the engine or about how it behaves on real Amiga hardware?

A number of people have tested it and sent me their findings, but thankfully, there were no nasty surprises, just lots of cool photos and videos of the demo running. WinUAE is a pretty awesome emulator for development and I have an A1200, which is the target platform. The usual caveats apply around network drivers and other drivers you might have running in memory. It's always best to run from a clean boot.

Looking beyond Green Hill Zone, which part of the original Sonic the Hedgehog do you expect to be the hardest to reproduce on a stock Amiga 1200? Are there later zones, bosses or situations that could put the engine under much greater pressure?

Labyrinth Zone will be a tough one. It has a mid-screen effect that changes the palette colours for the underwater sections. Definitely possible on the Amiga conceptually - the question is how easy or doable it is once integrated with the rest of the engine. I've said it before, but one of the challenges in delivering a complete game engine is ensuring all the components play nicely together rather than just in isolation. I'm hammering the bus of the A1200 very hard, so there isn't much room for manoeuvre.

The rotating 'Special Stage' will also be intriguing to develop. It is pretty much a separate codebase, even within the Mega Drive code. Bringing that to the Amiga could be like writing a completely independent game engine and set of rendering tricks to make it playable.

Aside from that, what's tricky on the Amiga is simply any screen with a substantial amount of graphical updates per frame. My rendering engine can handle it conceptually, but individual optimisations often have to be found for particular situations. For instance, the giant vertical moving platforms in Green Hill Zone 2 currently have their own custom routines to ensure they can animate in a performant manner, simply due to their size.

But these challenges are exactly what makes the project interesting. If I was porting Pong, no one would care!

At this stage, what do you consider the real hardware ceiling of a stock A1200? Is there anything in the Mega Drive original that you already believe cannot be reproduced faithfully without changing your approach or making compromises?

Yes, you can already see there are compromises and we're hitting the ceiling in areas of the demo. Just rendering a large number of rings simultaneously is too much data for the Blitter to move in a single frame. To even reach this level of performance, I've implemented sprite caching, deferred rendering techniques to split drawing operations between frames and profiled the codebase extensively to run the Blitter and CPU in parallel where possible. But in many instances, it's still a struggle on the plain A1200. The easy solution would be to drop a bitplane and reduce the colour depth to 16 colours, but the game would look visually compromised as a result. As such, I keep deterministic demo recordings of the levels, to profile whether optimisations I've made have really had a material difference.

If a team had attempted this port in 1992 or 1993, how much of what you are doing today would realistically have been possible with the development tools, documentation and knowledge available at the time?

For a professional team with state-of-the-art tools and hardware, yes it would have been possible. For a hobbyist bedroom coder, probably not. Sega, for example, had their custom Digitizer art hardware and software, plus high end development PCs. When all is said and done, you have a list of 68K instructions that assemble for the CPU pretty much as they did in 1991. You either have a team of well equipped full-time people to get there (as per the 90s), or modern development tools (as per today).

Working so closely with the original Sonic code, what has surprised or impressed you most about the way Sonic Team engineered the Mega Drive version? Has studying it changed your perception of the original game in any way?

What impresses me regarding Sonic, is that it is not only a technically excellent piece of coding, but also amazing fun from a design perspective. Many developers were only capable of achieving one or the other - something technically impressive (Shadow of the Beast), or something that played great and felt fresh but marked a modest technical evolution of what came before (Speedball 2). Delivering both in one hit is incredibly unusual. There are many clever nuances to the level design that I'm still spotting now! Plus the design flexibility Sonic Team squeezed into a 512K cart is very cool.

When performance and faithfulness come into conflict, what is your hierarchy of compromises? Between frame rate, graphics, physics, level behaviour, audio and other elements, what are you least willing to sacrifice?

Firstly, Gameplay (handling, 'physics' and level layout) has to be identical to the original game. The Internet is littered with terrible Sonic clones. Secondly, I wanted to run the game at 50fps (PAL). I think a 25fps Sonic game would be a little... meh. Thirdly, keeping as close to the original as possible visually. I can't talk about audio as I haven't started implementing it yet, but I want to ensure there is simultaneous music and effects. I don't really like to make compromises unless absolutely necessary. If you're going to take on a classic, you should do it right and treat it with respect.

You have mentioned the possibility of exploring an A500-compatible engine. Is that still a serious technical objective? Would it essentially require a different rendering approach rather than simply scaling the current A1200 engine down?

Yes, it's still an objective. Very little of the current engine uses AGA specific functionality. The two exceptions are the 32-bit fetch mode for the bitplanes (a performance boost) and the 16 colour AGA sprites, which are used for the level backgrounds. On the A500, I'd definitely have to reduce the game from 32 colours (5 bitplanes) to 16 colours (4 bitplanes). There simply isn't scope to move that much data around in a frame. The backgrounds will also have to be simplified significantly. But the feel of the game should be completely identical. I'm sceptical as to whether this will run in 1MB of Chip RAM though, unless I drastically removed animation frames and simplified the graphics. Just the memory consumed for the screen display is around 200k on the A1200, due to double buffering and scrolling, plus there are a significant number of runtime caches in operation. The A500 version is actually more of a tech art project in many ways due to the graphical rework required. But I'd at least want to provide the foundations for it, if an artist wanted to take it on.

Audio is another important part of Sonic's identity, and the current demo understandably focuses on other aspects of the project. How challenging will it be to reproduce the original game's music and sound effects on the Amiga while the rest of the engine is running? Have you already decided what technical approach you would like to use?

In some ways easy, in other ways very hard. I've already written tooling to convert the assembly code that contains the music data into a MOD file for the Amiga. The hard part is sample size. Sonic's music is tiny on the Mega Drive, because, aside from three drum samples, it's all synthesized. Once that is translated into 8-bit samples it balloons in size. The challenge is therefore ensuring it sounds great, whilst not using too much of that precious Chip RAM. For OutRun, I really went to town with huge high-quality samples because it targeted expanded Amigas, I had loads of Chip RAM free and I also wanted MOD files that sounded good enough to release on vinyl. For Sonic, that luxury won't be an option, and optimisation will be critical.

What would make you personally consider Aonic finished? Is the ultimate goal a complete port of Sonic the Hedgehog, a technical experiment pushed as far as possible, an engine that could be useful for other projects, or perhaps something else?

The question I'm trying to answer is: "Is running Sonic on the Amiga possible?" But a one-level demo doesn't prove that in my mind. It's easy to make a tech demo or a fragment of a game whilst cutting corners in a way that doesn't scale up. Therefore, it's finished when there's a complete port of Sonic the Hedgehog. Following that I'll release source code and tools so others can edit levels and tinker to their heart's content. I'd like to include a few extra features as well, like the Sonic Spin Dash.

Is there anything about Aonic, its development, or your experience working on the project that you would like to tell Retro-Gamers.it readers and that we haven't asked you about?

It's easy enough to fire up an emulator and play Sonic on any modern platform of your choosing these days, and as such you could be justified in asking, "What's the point of all this?" For me, what makes this project interesting, is the question of how far I'll get, how I'll overcome the challenges and what compromises I'll be forced to make along the way. As such, I figured it would be interesting to document the progress on YouTube and Patreon on a monthly basis. It's worth signing up to both of those channels if this project intrigues you.

There is still a long way to go: the demo reproduces the first level and currently has no music or sound effects, but Chris’s goal is clear: Aonic will be a complete port of Sonic the Hedgehog for the Amiga.

We’ll be following its development closely. Stay tuned to Retro-Gamers.it!