Saturday, November 06, 2010

Support for Tile Layers Implemented

The hardware tile layer is now supported in my framework. So in addition to the text layer previously mentioned, the ported code can now utilize tiles.

Here's a screenshot to provide an example of this, using ported code to display the tiles from the music selection screen:


Much of the detail from the music select screen is missing, because it also makes use of sprites, which are currently unsupported by the framework.

To summarize the components of the port, the following 68k code has been ported to C++ in order to reach the above stage:
  • Routines to setup palette ram
  • A new text routine to blit text with a height of two tiles to the text layer (this displays the Select Music By Steering text string) 
  • The routine which decompresses a tile map from rom and outputs it to tile ram
  • The routine to update tile hardware on a vertical interrupt
And the framework itself emulates the following:
  • Tile Layers
  • Text Layers
  • Palette Hardware
So we're getting to a stage where basic routines are coming along nicely. The final ported C++ code is more readable and far more concise than the original assembler.

5 comments:

bluepillnation said...

Fast work sir - cap doffed!

So does the screenshot combined with the post imply that the cloud background (also the horizontal scrolling backdrop of Coconut Beach) is driven by the sprite engine? Or is it just the text displaying the tune names?

yt said...

The 'blue' fill on the backdrop is actually handled by the road layer hardware I believe.

The player's hand turning the radio, as well as the radio EQ and FM station readout are sprites.

Most other things are on the text layer, I just haven't really implemented the music selection code fully yet...

Magic Knight said...

Hi, I love the project, can't wait for the final release.

Anyway, do you happen to know of any major differences between Revisions A and B? I have a Rev.A and was trying to figure out if there's any point in getting Rev.B ROMs burned or not.

Also, what kind of performance would you expect to get for your recomplied version on a Sharp X68000 - either with a 68000 running at 16MHz, or a 68030 running at 25MHz.

Thanks

yt said...

Magic Knight: I haven't looked into the Rev A/B differences in detail yet from a code point of view.

The most major differences are between the initial release of the game in Japan and the typical A/B revisions common in Europe and America as you're probably aware.

See:
http://reassembler.blogspot.com/2010/04/outrun-version-differences.html

The Easter Egg is easier to activate on Rev A as well. Personally, I would stick with Revision A if you're happy with it as I haven't noticed anything compelling between the versions.

With regard to the X68000, this project wouldn't run acceptably I'm afraid. Don't forgot the video hardware still has to be emulated, and rewriting in C++ will result in a performance hit.

The X68000 deserves a dedicated port in assembler, using the original source for reference I reckon. Even then, expect a big hit if you wanted aspects including the road rendering to behave like the original hardware.

Magic Knight said...

Ok, thanks for that, I'll just keep the A revision, playing around with the B revision in MAME I couldn't see any differences at all.

I figured that for the X68000 it would need to be written in assembly language, and would need to be optimized for the machine - reduced graphics etc. The X68k version of Super Hang-On is superb, the best home version there is. Pity no-one ever tried releasing Outrun. Last year Data East's Road Blaster was released for X68060, so there is still an active scene. Don't know what Sega would think of the idea though.