CannonBall 0.21 - New Views & Attract Mode

This is a minor update I've been working on for just a couple of days, but it contains some fun features. Get it here.

Viewpoints

The first is the ability to change the camera viewpoint. There are a choice of three views: original, in-car and overhead. You can use the shift key to toggle between them, although this can be redefined. You can toggle the view at any point during gameplay. 

Original View

Overhead View

In-Car View

The in-car view is rather experimental. As OutRun doesn't use a true 3D engine, it's not really possible to implement such a view correctly from a camera perspective. However, it's kind of fun to play with.  The overhead view probably makes the game easier, as you can see more of the upcoming road. 

Attract Mode

I then decided to recode the attract mode to show off the viewpoints.  Doing so also reminded me how awful the attract mode AI is. The existing AI works fine for the first stage, but after that tends to crash continually. Combined with the Best OutRunners overlay showing every 20 seconds or so, attract mode never really showed the game's full potential. So I recoded the attract mode AI too. 

Some of the improvements to the AI are as follows:

• Better at driving tracks without crashing into scenery.
• No weird car shaking/juddering when turning corners.
• Reduced brake light flickering
• Can drive any stage in the game competently.
• Selects a true random route, rather than a pre-defined route (as a result of the above)
• Can handle split tracks correctly.
• Handles the road split better. 

The AI code I've written is a lot simpler than the original code. It works differently, by looking at a distant position of the road and then adjusting the steering to drive towards it. If it gets too close to the road edge, it brakes. 

It still crashes into scenery occasionally, but I think that's ok. The AI is ultimately a compromise between driving safe and racing aggressively. And you want to see a crash sequence sometimes, just not at every bend.

Some of the original code still makes no sense to me, and I'm pretty sure it became a case of saying "this sort of works, let's ship it" towards the end of the project. One example of this is that the original code actually brakes when passing traffic, even when that traffic is right on the other side of a 6-lane road. You can spot this during the first two curves. The new code takes into account the x and z position of the traffic before braking. 

My AI still has difficulty passing trucks, as these drive slower than other traffic. Actually fixing this would probably take a fair chunk of code and I wanted to keep things simple. Plus the original AI suffers from this problem too, although arguably worse. 

You can toggle between the original attract mode and my new version in the game engine options located within the settings menu. The original mode uses the old AI and the new mode uses my rewrite. The code is here, if this sort of thing interests you.  

Other New Options

I finally implemented the ability to preview the audio track during the music select screen. You can enable this setting in the sound menu. Thanks to James Pearce who also submitted a fix for this.

Finally, there's a FPS counter that can be enabled in config.xml too if desired.

Following on from this I need to decide what to work on next. Most of the easy pickings are now done. Stuff like ghost-racing, multiplayer and so forth would be great but also a lot of coding work. :)

LayOut Open Pandora Port

Sebastian is working on a port of LayOut to the Pandora handheld. I didn't expect to see the editor ported to a handheld before anything else! Imagine, you'll be able to design and play OutRun levels whilst on the train to work. Here are some screenshots:

Grab it from here.

The forums were recently reset, so sadly a few posts were lost. They're back up and running now though. Be sure to checkout this cool CannonBall cabinet project from Mart, using an old Monaco GP cabinet he's salvaged from inevitable scrap!

CannonBoard

Colin Davies and myself are working on an exciting new project for owners of original OutRun cabinets: CannonBoard. 

The goal is to allow the original OutRun PCB to be cleanly replaced with a modern PC running CannonBall. There will be no soldering; no cable cutting and absolutely no cabinet butchery. Damaging original cabinets makes us very very sad. Simply unplug the cables from the PCB and connect to our interface. Restore your cabinet to the original PCB at any point. It's plug and play!

This approach has a number of advantages. You'll have 60 fps, a wealth of easily configurable options and the ability to play tracks from LayOut. Plus you can tinker with the CannonBall source code if you're technically minded. If this fills you with horror, you can turn all the options off to ensure your experience is identical to the original game whilst furiously sucking a Werther's original.

Colin is working on the hardware interface. A standard Windows, Mac or Linux machine will connect via USB to a cheap $10 Arduino board, mounted on a custom PCB. This custom PCB plugs into the cabinet controls.

Custom PCB

I'm working on the software side of things. CannonBall will communicate with the Arduino to receive inputs from the controls and output to the cabinet motors and lights. I've got the easy job, although I do need to port some more of the OutRun cabinet related code that I missed out. 

Arduino

We're aiming to support all cabinet models from the mini through to the deluxe sitdown. Like all good hobby projects, there is no strict schedule attached to the project. But progress so far is looking promising.

LayOut 0.11 - First Track & Source Code Release

Supper has created a track with LayOut and it plays quite nicely for a first attempt. You can try the track using the latest CannonBall from the command line:

cannonball -file test.bin (where test.bin is the name of the LayOut track to load) 

Head over to the forums to check it out.

I also released a new version of LayOut with some minor bug fixes for issues raised here. 

The source code has also been added to github here. I'll add some compilation instructions when I have time. Please note that for now I've only tested with MSVC 2010 and Qt 5.1, so it probably won't compile on other platforms out of the box yet. 

Dynamite Dux: Easter Egg

Yes following the LayOut launch, I'm on a roll today. I'm not a big fan of Dynamite Dux, it's one of the weaker AM2 titles from the late 80s. However, knowing it was coded by Satoshi Mifune (aka Bin Chan), I knew there might be some goodies locked away waiting to be found.

This is one of the best AM2 extras I've found. It's an oldskool demo sequence with caricatures of the team.

To activate the sequence, you need to complete the game. On the Congratulations screen, hold player 2 start and press Player 1 start exactly 15 times.

I've uploaded a video of the complete sequence to youtube here.

LayOut 0.1: A Track Editor for OutRun

LayOut: A Track Editor For OutRun
It's finally here. Create your own OutRun tracks and edit the original ones.

Features:

• Track Editing: Create your own OutRun tracks from scratch
• Import: Edit original OutRun tracks and supporting data
• Scenery Pattern editor
• Height Pattern editor
• Road, Sky & Ground Palette editing
• Realtime Preview
• Export and play tracks using CannonBall.
• Export to original arcade ROMs coming soon.

Download LayOut here.

You will also need the latest version of CannonBall.

You will definitely need to read the manual. And I'd welcome input to make the manual clearer. 

New Forum:

There's a new forum here.
Hopefully this will be a more useful place to post tracks, report bugs and ask questions than the blog comments. Thanks to Steve (Tipus4u) for volunteering to set this up and provide the hosting.

What's Next? 

I'll focus on LayOut support and fixing the inevitable bugs that will be found. However, I need to take a break from LayOut in terms of implementing new features for a short period. I have an exciting hardware/software project planned that I'm working on with Colin from the Jamma+ forums. I'll post some details on that in due course. 

Interview with Yu Suzuki & Ryu: The Making of After Burner

I'm delighted to bring you the first English translation of a piece of SEGA history from 1988. This interview with Yu Suzuki and Ryu presents a rare insight into the development of a number of classic AM2 titles.

I'd like to thank Fabrizio Bartoloni for translating the article. I tried to cajole a number of people into helping, and he was the first to agree. I've adjusted some of the wording slightly, but the original translation and Japanese text can be found here.

I'd politely request that other sites link to this article, rather than pasting the contents. This is a non-profit site with no advertising, so please be nice. :)

Interviewees:
Yu Suzuki. (Lead Developer)
Ryu. (Head of the consumer office)

YU: I'm the one responsible for "YU" as a name entry [on the high score table] when you power up After Burner. I've overseen the software coordination and planning of After Burner. I started my career with Hang On and then went on to create Space Harrier and Out Run.

RYU: I'm RYU and in charge of growing the consumer office. So far I've worked on the Out Run conversion [to the Master System]. This is the second time I've converted a body experience¹ game, but as the hardware is different, recreating the original experience is cumbersome in my opinion. Additionally, I've also created characters for the Anmitsu Hime² series and other titles.

¹ 体感ゲーム is a game genre when your body is used to control the game (and may or may not receive some bodily feedback from it).

² Anmitsu Hime is a Sega Master System game from the eponymous manga. Its Western market release has been adapted with heavy changes and it's better known as Alex Kidd: High-Tech World

RYU: The features of the forthcoming Mark III After Burner conversion are made possible by the new 4 Megabit cartridges. Until now 1-2 Mb cartridges were common; 4 Mb is not an industry first, but with so much more space the graphics and action can be closer to the original.

There aren't the 23 stages of the coin-op, but there are still 18 stages and the refuelling scene. The home version contents will be more or less the same. There will be differences, but I'm making the backgrounds and everything else to be as close as possible.

At first I thought converting After Burner would be easy. After Burner and Space Harrier use a similar system, but they should be better considered different challenges.

I'm sorry I can't show you anything yet; we're already at the stage where something works on screen. Please keep your expectations high as this is the risky phase where I need to be at my best. It's like performing a somersault. I asked Yu to show me source code to help with the conversion and he told me to look at the original (laughs).

The Master System version will feature FM sound and the graphics are also an improvement on Space Harrier.

YU: The After Burner arcade project started around December 1986. Our way of working during the project was quite different from common practice. Usually you start with a plan, but instead we went ahead without having defined one. We started with the things I wanted to do, those that were interesting and already feasible. This approach is like having three possible paths ahead and you have to try all three of them to find the best. 

Such an approach is wasteful as you can find two of the choices prove useless. You often have to go back and fix problems and can't find the way forward. Therefore, in our case there was a written plan, albeit a hazy one. Planning continuously changes according to the situation you're facing. 

There was a movie called "Top Gun". I'd wanted to make a game with war planes before watching that movie. My initial inspiration was [the anime by Miyazaki] Laputa: Castle in the Sky. I'd thought about capturing that science fiction anime-like feeling.

Anyway, as Sega's 'body experience' game wasn't intended solely for the Japanese market but was due to be exported to Europe, US and the rest of the world, it would need to be understood by an international audience. So I switched my plan and gave it the shape of a F-14. Americans seem to have a preference for realistic graphics on screen rather than Japanese anime-like fantasy worlds. Now Americans are developing a better understanding of Japanese fantasy though.

Development costs are an extremely confidential matter, as might be expected. But if we were to make a comparison with ordinary game hardware which doesn't have to change that much, the costs are incomparably high. This is because there are few common components. You have to change the PCB, mask rom, chassis and so on - all of them. It's a totally new thing, despite using some of the same concepts. It's technological innovation stacking up. When Hang On was made, the background was almost empty, but since we've been using Out Run's new system we can say that games like Space Harrier and Hang On are totally different from a technical point of view.

At first I wanted the scenery to be set between the Mediterranean area and the Soviet Union... but it went wrong (laughs). Although I wanted it to be like that.

RYU: I wanted to say Persian Gulf! (laughs)

YU: You wouldn't have seen the Persian Gulf. Anyway, it would sell if America could beat the enemy side, just like Rocky¹ did.

¹ a reference to Rocky Balboa winning over Russian champion in Rocky IV 

It's real scenery, and would tie together well. I have the big picture in my head. It would be set in Europe, including Italy and the pyramids. When we created Out Run I went to see the real thing. We don't have spare time like that now. I'm browsing issues of the oversees travel information magazine AB-Road. It costs just 300 yen (laughs). I'd like to make the backgrounds look as close as possible to the real ones.

When it comes to the Soviet Union, it seems you have to abandon the idea of 16-bit machines. Apparently, it would be a violation of CoCom. [The embargo against Warsaw pact countries by US and some Western countries]. I wanted to depict the Kremlin building but in the end I gave up. This is due to the enormous variation and number of patterns which would be impossible to fit into memory. A spherical shape consists of merely one pattern, but here you must render a large number of cylinders. 

The landing scene is indeed big, but it exists on its own, so there is just one pattern in it. There were so many things I wanted to do, but they couldn't be done within the limits of development deadlines. For example, I wanted the pilot to be ejected from the aircraft with a parachute. For the end sequence, I also wanted the protagonist to carry the princess in his arms whilst flying the enemy plane. 

I think it's important to make the characters stand out. The protagonists of Space Harrier, Hang On and Out Run all stood out. I'd like the same to happen with After Burner.

RYU: Despite the continuous advancement of console hardware for domestic use, there is still a huge gap compared to professional coin-op hardware. In the future, much will be said about narrowing this gap. 

YU: I want to work on body experience games from now onwards. I've been working on Hang On, Space Harrier, Out Run and After Burner, but to say it emphatically, they were all left half done. After Burner is roughly 60% done. I wanted to include a dogfight. Right now it's many versus one, there is no one-on-one. A fight of one versus a few strong enemies represents the real world.

All of this is because of a lack of time and technical problems. The incomplete features will be implemented in upcoming games. Our goal is to make games, from the onset, as close to the real thing as possible. If you look at other driving games when an ordinary car bumps into another you sometimes see an explosion or big accident as a result. 

I've tried to make Out Run as close to the real world as possible. Although the game is not the real thing, I've added many ingenious solutions to make it work realistically. As much as you could expect from a game. My plan was to aim at what would have been probable in a realistic setting. I didn't want Out Run to feel ridiculous when compared with reality.

Even if After Burner and Outrun have some way to go before reaching their goals, trying to make them entirely flawless would result in enormous costs. It would be nice to be able to create a game without worrying about the cost though. For this reason, it's an exaggeration to call them simulations. But I'd like to get closer to reality.

(1988)

Check out more interviews here.

LayOut - Complete Level Video

Here's a video showing a (not very playable) level I made whilst testing and bug fixing.


Click here to watch at full quality on youtube.

October Update

Things are really coming together now. It's possible to make a level that's more varied and interesting than most of those found in the original game. You can quickly export to CannonBall with a single button click and be playing instantly.

I coded some handy routines to quickly generate your own sky palette and ground palette, interpolating between two colours. Here's an example I generated in just 15 seconds.

I improved the interface and usability in certain areas as well, including the addition of zoom to the top-down road view.

At the moment I'm not really coding anything that interesting. I'm basically making a level and fixing any small bugs I encounter along the way. There are lots of minor bugs that arise in an application this complex and they take time to fix.

At the end of October I'm going to feature freeze completely. In November, I'll write the documentation, packaging the accompanying release of CannonBall and preparing for release. I'm excited at the prospect at releasing this thing.

In the meantime, check out this great article (in French) regarding unauthorized advertising in arcade games. It makes use of the System 16 Sprite Viewer I posted some time ago. 

OutRun Anniversary Update

It's the 27th anniversary of OutRun and we're long overdue a post about what I've been upto. Things may have seemed quiet, but that's only because I've been working intensely on LayOut behind the scenes. I say intensely, but as I'm married, 33 years old and have a full-time job in the games industry, finding spare time to program can be a luxury!

Excuses aside, yes, I thought I'd finish this project sooner. It would have been great to release LayOut for the anniversary. However, during development I came to the realisation that producing an editor people loved was more important to me than simply releasing a rushed product. And this is a hobby, so it's important that I love working on it myself.

Along the way, the feature set has ballooned beyond what I originally planned and LayOut, whilst imperfect in many ways, is greater than ever imagined. Let’s consider the features so far:

Realtime Level Preview
Full visualisation of the stage you are editing. All changes are shown in realtime. This uses a special widget that is an enhanced version of the core OutRun rendering engine from CannonBall.

Full Import of OutRun Data
Import and edit existing OutRun levels including unused/hidden levels.

Full road path editor
Define the path of the road, set the number of lanes and split the road into two.

Height Map Editor
Create 2D height maps, apply them to any section of road and preview your work in realtime. Every option is configurable, including options available in the original engine but not used by OutRun's levels.

Scenery Pattern Editor
Define your own scenery patterns. All options are configurable: shadows, sprite positioning, horizontal flipping, palettes, the internal engine draw/collision routine to use, repeat properties etc.

Palette Editor
Change the road, sky and ground colours. I will also implement sprite palette editing in the future so you can change the colours of everything in-game.

Level Mapping
Easily change the order of your levels, and map them to the 15 stages available in OutRun.

Multiple Export Options
Easily export to CannonBall. I'm simultaneously working on a new version of CannonBall to handle the exported level data. Shortly after release, I will work on an exporter that allows you to write directly to the original arcade ROM images. Yes, you'll be able to play your levels on arcade hardware.

Cross platform & Open Source
Coded using QT, the editor will function on Windows, Mac and Linux. The editor will be released under a similar non-commercial license to MAME.

Common questions I tend to get asked, that I will cover here:
1/ What about other games?
Whoooa one step at a time fella! Super Hang On uses a very similar track format so it wouldn't be inconceivable for me, or you, to add support in the future. But let's get OutRun to a good place first.

2/ What about sprite editing?
Yes definitely, in a future version. It's more complicated than you might think to do this properly.

3/ When will this be released?
I would expect November 2013 at the latest. Followed by a series of frantic updates.

I’m also thinking that we probably need to get a forum setup for discussion once the editor is released. Does anyone fancy hosting that?

CannonBall - Javascript Version

Yes, now you can play OutRun directly from a modern web browser at 60fps with sound and no plugins. 

You may remember that one of my goals was to bring OutRun to every modern platform and this takes us another step closer. Here's the Javascript version of CannonBall. 

It would be even more seamless if I could bundle the ROMs, but sadly you will have to provide these yourself for obvious reasons. 

It runs on mobile devices, although it's not playable yet due to a lack of controls. I recommend the Firefox Beta browser on Android. I can run the engine at 40fps on a Samsung Galaxy S3 phone, so 30fps mode works fine.

Technically, the core engine is converted from C++ using Emscripten, which is an amazing piece of technology. I also wrote a wrapper around the C++ engine in Javascript to handle timing and audio. Audio uses the new WebAudio API. 

It's clearly "very beta" at the moment. For example, full-screen mode works only in Firefox. Audio only works in Firefox Nightly and Chrome. Getting things running nicely has been a bit of a frustrating balancing act. 

The source code is currently forked and can be found here. It's quite hacky at the moment, as my main focus has been to simply get this running. 

Exactly how much I support this will depend on the level of interest. I want to get back to LayOut, amusing as this project was. You are welcome to embed it in your webpage if you provide a link back to my blog. 

CannonBall in a Web Browser? (Updated!)

I've started converted CannonBall to Javascript so that it will run straight from a web browser with no plugins. I wanted to do this for a number of reasons:

• It saves porting and means CannonBall will run on any every platform with a modern browser (e.g. tablets, phones etc.)
• It's a good opportunity to show that CannonBall is pretty fast (some people doubt this). 
• It will be pretty cool when LayOut is finished to be able to play a customised level by simply clicking a link. No download or messing around with files. 
• It's interesting to me from a technical/tinkering perspective.

This might not be as painful as it sounds. I'm using emscripten which can convert C++ code to Javascript. (Technically it converts LLVM bitcode to Javascript, but you get the idea). And just to be clear, this version isn't intended to replace the downloadable CannonBall :)

So far, progress isn't particularly exciting to observe:

But actually this is more promising than it may appear. The entire codebase compiles and begins to run. It's simply stumbling on finding the roms as I need to package them with emscripten's file system. 

So far the process I've followed to get things running was as follows:

1/ Followed the tutorial here for the Windows setup. 

I failed to get everything working from within Visual Studio 2010. Suspect this is an issue with a 32-bit VS 2010 process trying to spawn a 64-bit process as part of the toolchain. But actually fixing this issue proved problematic as I couldn't get clang to compile under Windows, so was unable to compile a 32-bit version to test this theory.

From reading some forum posts, it appears that using Windows 8 would probably solve this issue and the prebuilt clang would work.

2/ Switched to using a Unix/MinGW approach. Plugged the following platform file into CMake.  Ran mingw32-make; prior to this point the makefiles are butchered by CMake to work with Clang and emscripten instead of MinGW. 

3/ Created a customized emscripten.cmake file, which essentially doesn't do very much. 

4/ Fixed the three million compiler warnings reported by clang. It's a more fussy compiler than VS or GCC. I also removed the dependency on the boost library for now to speed up getting something working. 

5/ Converted the bytecode to a html page with embedded javascript using:

emcc cannonball.bc -o cannonball.html

6/ Loaded the file into a web browser. It fails in the way we would expect and spits out some sensible output about the roms. Hurrah!

Overall, it's only taken a couple of evenings to get this far. And most of this time was spent messing around installing stuff, and failing to get things working in Visual Studio. Once I hit upon the right approach, things went relatively smoothly. 

I'll carry on coding over the next few days. As Emscripten supports SDL libraries out of the box, it shouldn't be too tricky to get something working. But let's see... 

Edit: Couldn't resist implementing the file system before bed to see what happened. It kind of runs. But obviously not very well as there's a bunch of stuff I need to do like replace the main loop. Not sure on the colours for now, but probably an easy fix.

14th July: I fixed the colours, and it is now running and playable:

Unfortunately, it's using the software renderer for now. The OpenGL renderer would need a rewrite to make it WebGL compatible. It doesn't just work out of the box. 

The speed is reasonable at 30fps currently, although a little choppy in places. I'm not sure what kind of improvement I could expect if I rewrote the renderer...

If anyone is desperate to work on this further, I can check my work into git for them to mess around with. I may work further on this in the short-term or I may switch back to LayOut again!

I also tested on my Samsung Galaxy S3 phone. It runs pretty well on the Firefox Beta browser (maybe at around 20fps). There's no way to actually control the game though! It runs like a dog on Chrome.

15th July: I realised that using the emscripten_set_main_loop was causing the performance problems. Rewrote the main loop, so that the frame timing is done in pure JavaScript, with a call to the external C++ tick function. This is a similar approach to the port of Snes9x.

The results are outstanding. Unthrottled, the engine runs in widescreen at 80fps in Firefox on my desktop PC.

On my Samsung Galaxy S3, the engine now runs at a solid 30 fps in the Firefox browser (I haven't tried it unthrottled yet). Given that most elements of the game only update at 30fps in the original arcade game, this means you can run OutRun at full-speed. Pretty impressive for Javascript running in a phone's web browser!

24th July: After some experimentation, I now have relatively solid audio working on the PC. Unfortunately, directly porting the SDL audio code didn't lead to good results. Instead I replaced the SDL code with custom Javascript using the WebAudio API and an interface into the C++ code.

The results are decent on a fast enough PC with Chrome or Firefox Nightly.

Cannonball 0.19 - OpenGL Rendering

I've updated Cannonball to support OpenGL rendering. This means:

• Large performance improvement, especially when using full-screen mode. 
• Scanlines can now be used in both full-screen and stretch modes.
• Filtering can be toggled in the config.xml for a softer look, similar to MAME.

The old software renderer will still be supported, but is toggled at compile time by unsetting the OPENGL flag in your build.cmake file. 

There are a few other improvements rolled into this build:

• A minor bug was fixed in the road rendering. This occasionally caused road pixels furthest into the horizon to be displayed at the wrong position.
• In widescreen mode, sprite clipping is now correct, so sprites close to the camera aren't deactivated so aggressively. This is most noticeable on levels with wide grassy strips etc. 

I'd consider this build beta for now. Please try it out and let me know if you spot any problems. If I haven't broken anything along the way, I will update the main page. Then it's back to LayOut, which has been neglected a little lately.

Download here.
Marcus has also updated the Mac version here.

Thanks to Legooolas for having a stab at the OpenGL code originally. In the end I rewrote everything myself as I wanted to untangle the SDL rendering code from the native OutRun video code. So now the codebase is a little cleaner in this area. 

Layout - Object Placement Video

I'm starting a new job soon, so there's likely to be a short break in proceedings. In the meantime, here's a video showing object placement and the new preview window. This makes using LayOut so much more fun.

Progress is a little slower than I would like, but hey, we've waiting 27 years for this so maybe it's not really an issue.

LayOut: Preview Mode

Layout

Those of you who watched the previous LayOut video will have noticed one significant problem; whilst editing the track technically worked, the visualization of your actions leaved something to be desired.

As planned, I've moved on to editing sprite placement next. And in doing so, I incorporated a real-time preview of the changes you are making. If you create a new curve, hill or even change the placement of an object, this is updated in real-time. You can also change the camera angle by dragging in the preview window with the mouse.

In this screenshot, I've imported the Devil's Canyon track. The 2D path is shown in the lower panel, and the actual rendering in the top panel. The panels can be linked so as you scroll through a level, the placement remains in sync. The 2D window is in scenery editing mode. The large dots indicate the start of a 'segment' of scenery items. Scenery in OutRun is segmented like this, so that patterns can be reused multiple times to save on storage space. Each time you use a segment, its length is variable. Segments wrap if the length exceeds the number of items in the segment.

Switching to the scenery tab, you are immediately linked to the segment selected in the 2D view. There is a lot of complexity here, and I haven't even finished work on this part of the editor. The list on the left represents the segment and shows the list of items used in this section. Here you can see items including, rocks, road debris and so forth. The timing at which this list is rendered is affected by the pattern frequency. The engine can render two sprites per road position. Although it's possible to create the illusion of more. For example, on the Gateway stage the top beam is actually positioned behind the pillars. Or you can adjust the y values in some cases. 

Clicking an item in this list invokes object specific properties on the right hand side. In this case, you can edit the x and y position, select whether to horizontally flip the sprite, whether the object has a shadow and the custom draw routine used. Changing these properties only affects a single entry of the item in the segment. All of this is of course based on how the original OutRun engine works. 

Where we deviate from how the original engine works is with the new preview window. The preview window is cool because you can just say 'show me the track at position 704'. The original engine doesn't work like this; it must render the entire level from start to finish. If you were to hack the original game so that each level started at position 704, you would see something completely incorrect. Similarly, there is no easy way to reverse backwards through a track and this is now possible. The downside to this is that it adds complexity and possibly bugs where the rendering deviates. The upside in terms of previewing all changes in real-time is immense though. You can position the camera on the track, create a curve and watch the environment change in front of your eyes as you turn a dial. 

There's still a lot of work to do; it's a relatively complex project, which I guess is why no one has attempted it before. Additionally, I haven't done a lot of GUI based application development before, so I'm learning as I go.

CannonBall

Neil from the OutRun and Space Harrier Replicas project has kindly made this rather stunning logo for CannonBall. 

For now, it's only featured on the CannonBall page, but I will incorporate it into the build itself in future. I do plan to get back to CannonBall and add hardware rendering and other new features when LayOut is released.

I also moved the standard CannonBall download page to a new cleaner page on github. The old blog page was full of dated comments and somewhat messy. 

Sprite Outtakes

You might think that after years of pulling OutRun apart I would have exhausted the hidden extras. Not quite yet! Here are a few unused sprites that are in the game.

Firstly, here's a motorbike that didn't make the final cut. The above is a mock-up to show what it would look like in-game. There is a preliminary data structure to hook the bike up in the game code, and that data structure is similar to the existing traffic entries so we can assume this was an early attempt to include other forms of traffic. However, the final higher level data structure is missing, which would include the palette information. So I've just used a random palette here.

Here's an extra frame from the end sequence with the genie. I guess there was originally concern that it wouldn't be clear who the genie was, so the extra frame on the left was made.

Finally here's another end sequence idea that was dropped. The existing sequence sees the guy kissed by the girl awarding the trophy, before flexing his muscles. It looks like the original plan was to also have him fall over. You can see the extra frames below:

You can use my quick and dirty sprite viewer to browse sprite data in other Sega titles. 

LayOut - WIP Video

Here's a quick video showing the latest progress with LayOut. You will want to view this full-screen to see the detail and turn the quality level up. As a bonus, there's some dodgy narration from myself, so turn the sound on. 

Current Features:

• Edit Road path, width and height.
• Import existing OutRun levels for editing and refinement. 
• Export to Cannonball. Levels are fully playable.

I'm quite pleased with the ability to import existing levels. The import function generates the entire track path using nothing but the Curve Info value and direction that was discussed in a previous blogpost. So the large amount of data specifying the x,y of each road segment is completely redundant.

As you can see from the video, creating a playable level literally takes minutes. However, for the final release it will be important to quickly edit/preview sections of each level. I will be making additional changes to Cannonball to support that.

I must stress this is very much a work in progress; it's ugly, but it works!

Height Map Hell

One of the more complex areas of road data is the way in which setting the road height is handled. Each OutRun stage has 1948 positions that correspond to the path the level takes. We previously saw how a series of tables reference these positions to control aspects like the road width. This same table is also used to configure the height.

One of the entries in the table denotes whether the entry relates to a width change or a height change. Height changes are more complex than width changes. Each height change points to an entry in a separate table of 225 height maps.

So for example, on Coconut Beach at road position 1 the table references height map 211. In the diagram below, taken from my recent work on LayOut, you can see the data contained in this segment and a crude visualisation of the height map on the right.

The interesting thing is exactly how these maps correspond to a position in the level. We know when they are applied and therefore the start position of each height section, but how long do they last for? If the above map starts at road position 1, where does it end? 

The answer is relatively complex, as the height data you can see in the above table varies in length depending on the step adjust and multiplier values. Changing these values can either compress or expand the duration of the same height map. The road data isn't fixed to a particular road position increment. In fact in this example, changes in height are parsed through different multipliers to the straight sections and the end result would look something like this, presuming a start of road position 0. 

So here you can see the length of each data section in this single map and the road position it corresponds to at the bottom. I won't delve into the algorithms that map this data here, as it will probably confuse matters. I haven't yet visualized this in the editor itself. But we're starting to understand how these values correspond to a particular road position. 

Think of the actual values (0, 576 and -576) as the angle or steepness of the height section. And then the length pretty much specifies how high or how long that section of slope lasts for. 

To make things more complex there are four distinct types of height map in OutRun. Each type is rendered with a completely separate customized routine executed by the sub CPU that handles the road layer. Type 1 is the most common and shown above. 

Type 2 is more simple and used to create very long hills. It pretty much sets an angle and specifies a length or delay value. This is used at the point of the sharp chicane in Coconut Beach.

Now with Type 2, actually mapping this accurately to the road position gets interesting. Due to some quirks in the game code, the length of these sections actually depend on how fast you're driving. OK, you're not really going to notice this at normal speeds. But if you drive slowly, you can exploit a bug that pretty much elongates these sections way beyond where they should be. 

Here we are elongating the climb at the end of the Chicane. I'm driving slowly, and admittedly I've frozen the game timer. If we drive slow enough the hill can pretty much last right through to the end of the level:

OK, this is slightly silly stuff. But the point is that there is not a direct mapping between level position and the height map data. It's rather loose. So creating an editor where we can definitely say "the hill definitely ends here" or "this peak is exactly in line with this sign" simply isn't possible. The game code doesn't work in that way and there will always be ambiguity in some cases.  

Type 3 is a combination of Type 1 and Type 2. It's essentially some normal height data with a delayed section in the middle. The length of the section is handled differently again but is hard coded this time. Quite why, I don't really know. Typically a height entry will correspond to 8 road positions. This section isn't commonly used. 

Type 4 performs horizon y position changes. This can be seen at the start of Gateway, when the horizons level is raised. The only data attached to these entries is the new horizon position and the speed at which the change should happen.

It should be pointed out that the original assembler for this area of the game is horrendous and mildy terrifying.Therefore nailing all this detail down took a while, and unfortunately came at a time when things have been pretty busy for me. So apologies for the lack of exciting updates lately. 

In addition to this, I needed to expand my QT knowledge significantly to visualize this effectively in the LayOut editor. I implemented the ability to import the existing OutRun height map into the editor and display it in a logical tree format. 

There is still more work to be done, including basics like editing and creating new height map entries, although for a casual user, the existing maps should suffice. Once this is done, it will be time to move onto the fun stuff - adding level objects!

On Cannonball, a couple of people have kindly submitted changes that I will look into including in the future. The first is some control improvements from James and there is also some initial OpenGL rendering work from Legooolas, which will enable faster screen stretching/resizing than the current software approach. I'm holding off on Cannonball work for now and the next release is likely to be in conjunction with LayOut.