OutRun: I started porting it!

[agermose]

Originally Posted by acidbottle

well this is shaping up real nicely, so smooth.

is this project in any way in conjunction with the agermose AGA outrun port that is also ongoing? just wondering, not seen it mentioned.

The projects are unrelated. Since they target different hardware requirements, there is room for both
With the awesome stuff shown here, the pressure is on to deliver my thing on low end AGA machines.

[reassembler]

I've been having a really really wild time optimizing sprite routines. Oh boy.

Some highlights:
1/ All 15 Stages are in and rendering correctly with original level data. You can progress through them, via the road split and cursor keys. The engine and the optimizations I've made seem technically sound. All the levels should be pixel perfect with the original in terms of layout, road height maps, curves, sprite layout.

2/ The sprite routines are now much much faster. By a factor of 2-3x performance. I split the sprite rendering into 6 custom routines that can each make a variety of assumptions about how the sprite is going to be rendered. This code is a nightmare to maintain, but as optimized as my brain can handle for now. Only a new paradigm could improve things. Or just culling scenery.

3/ I optimized some of the original OutRun codebase. To be honest, it's not the critical path in terms of performance, but there were inefficiencies in the most called sprite routines. I guess I'm the first person to optimize the original code since 1986, so that's kind of fun and satisfying.

4/ In a move that somewhat surprised myself, I've mostly got shadow translucency working and with a solution that's no slower than rendering a sprite - well it's faster than rendering the blobs I had previously! So yes, the engine can designate a shadow to a sprite and it will darken the underlying pixels of the road layer as per hardware. I'm actually using the correct values derived from hardware analysis for darkening. I'm not sure if MAME is still buggy, but its shadows were way too bright for many years. Let's make the Amiga version better!

There is an alternate shadow mode that OutRun also uses. I don't think I'll be able to support this from a performance standpoint as it would require a per-pixel rendering check that would tank performance. But this is less visible and used to minor effect in comparison.

5/ I optimized my road code further still. It's funny - you think there's nothing left, and then you look at it another day and figure out a set of ideas. It's marginal gains at this point.

Overall I think this is the most complex optimization and porting project I've ever undertaken. Whilst I don't want to create a false sense of hope - the sprite scaling and scenery rendering was the area I was most concerned about. And it's working faster now.

I'm away from my Amiga at the moment, so I haven't checked speeds again on hardware. I'll post a video next week. I've attached a few picture postcards. Enjoy. And any coding questions welcome. There's a lot of detail I could go into...

PS Thanks to Agermose for nudging me to turn the black border on!

[Amigajay]

All sounds amazing progress you are making! Still aiming stock A1200 or some fastram will be needed?

But great job, look forward to the next video!

[jotd]

that's completely unexpected great news! the pics are awesome.

[reassembler]

Originally Posted by Amigajay

All sounds amazing progress you are making! Still aiming stock A1200 or some fastram will be needed?

But great job, look forward to the next video!

I've never been aiming at a stock A1200 with this project for better or worse as it's running the arcade code and makes liberal use of FastRam.

Agermose is battling away on the A1200 with his version. An even tougher project than this one.

[jotd]

A1200 AGA with fast will be fair enough for that one.
My Marble Madness 2 project will probably required fastmem too (if it sees the light of day)

[Tsak]

Originally Posted by reassembler

I've never been aiming at a stock A1200 with this project for better or worse as it's running the arcade code and makes liberal use of FastRam.

Great work!

I have a question, how often real-time sprites flipping is actually used? I.e. given the amount of sprites on screen, does flipping occurs once per sprite type or with every rendered sprite on screen (that needs flipping)?

[reassembler]

Originally Posted by Tsak

I have a question, how often real-time sprites flipping is actually used? I.e. given the amount of sprites on screen, does flipping occurs once per sprite type or with every rendered sprite on screen (that needs flipping)?

About 50% of the time in terms of level scenery. Pretty much all scenery needs to be flipped at some stage. My sprite flipping routine is only a few cycles slower than normal sprite rendering so it's not a performance drain.

It's more complicated overall. Sega's sprite hardware can render all sprites from left-to-right or right-to-left (both flipped and unflipped). Think of this as x-anchoring. The OutRun engine will actually update the anchoring applied as the screen is scrolled left and right. This is where the D-Pad style movement through the level I have comes in useful for testing.

In a further twist, the original hardware performs x-clipping automatically. That needs to be handled in our software interpretation. Y-clipping is handled in the original engine in software. Bear in mind that sprites are completely free-form in size and the larger ones scale beyond screen size. There's no nice assumptions of 'hey this is a multiple of 8' or whatever!

There are a lot of variables to consider. You can potentially begin to understand why I march all sprites through one of six routines. In fact, the same sprite will often be rendered in multiple ways by the engine I'm writing once it's spawned in the game world:

1/ Is the sprite clipped? No... We can render faster!
2/ It's clipped. What direction are we rendering in (x delta/anchoring). We can make assumptions and render faster.
3/ Is the sprite horizontally flipped? This determines the read direction of the source data and again uses a custom routine.

The sprite routines I've written handle the free form zooming and palette remapping. I've avoided anything that could be considered slow: division, multiplication and even logical shifts to do this. As much as possible is register driven.

But ultimately there's a huge amount of sprite data pounding around. Hang On and Space Harrier would be really easy in comparison if I ever moved onto them.

[dlfrsilver]

Originally Posted by reassembler

About 50% of the time in terms of level scenery. Pretty much all scenery needs to be flipped at some stage. My sprite flipping routine is only a few cycles slower than normal sprite rendering so it's not a performance drain.

It's more complicated overall. Sega's sprite hardware can render all sprites from left-to-right or right-to-left (both flipped and unflipped). Think of this as x-anchoring. The OutRun engine will actually update the anchoring applied as the screen is scrolled left and right. This is where the D-Pad style movement through the level I have comes in useful for testing.

In a further twist, the original hardware performs x-clipping automatically. That needs to be handled in our software interpretation. Y-clipping is handled in the original engine in software. Bear in mind that sprites are completely free-form in size and the larger ones scale beyond screen size. There's no nice assumptions of 'hey this is a multiple of 8' or whatever!

There are a lot of variables to consider. You can potentially begin to understand why I march all sprites through one of six routines. In fact, the same sprite will often be rendered in multiple ways by the engine I'm writing once it's spawned in the game world:

1/ Is the sprite clipped? No... We can render faster!
2/ It's clipped. What direction are we rendering in (x delta/anchoring). We can make assumptions and render faster.
3/ Is the sprite horizontally flipped? This determines the read direction of the source data and again uses a custom routine.

The sprite routines I've written handle the free form zooming and palette remapping. I've avoided anything that could be considered slow: division, multiplication and even logical shifts to do this. As much as possible is register driven.

But ultimately there's a huge amount of sprite data pounding around. Hang On and Space Harrier would be really easy in comparison if I ever moved onto them.

Going on Space Harrier and hang on would be awesome. With such a rework/optimising of the engine for Amiga, you could even go at Turbo Outrun, which uses the same engine as Outrun !

[reassembler]

Turbo OutRun uses the same hardware, but it's not the same engine. In so far as OutRun can be said to have an engine in the modern sense of the word. Some of the data formats will be similar from memory.

I'm not a fan of Turbo OutRun in terms of the arcade original. They made a number of design decisions that didn't deliver better gameplay. I did love the C64 version mind you!

[encore64]

Following the thread with great interest

[d4rk3lf]

These screenshots are absolutely beautiful.

[kriz]

Looks amazing!

[Tsak]

Originally Posted by reassembler

About 50% of the time in terms of level scenery. Pretty much all scenery needs to be flipped at some stage. My sprite flipping routine is only a few cycles slower than normal sprite rendering so it's not a performance drain.

Well, I'm asking because you said that you're targeting fast ram configurations, so surely RAM is of no huge concern in this case. Given you're using auto flipping in 50% of time and the fact that you have a gazillion sprites on screen means that even if the routine is fast per object it should also accumulate a lot.

Afaik the general consensus it that software flipping on Amiga is better to be avoided if you actually have ram to spare and you can do otherwise. F.e. the recent port of Final Fight got rid of it and this (according to the author) is an important reason of why the game performs that much better than the original old port (which uses it). Several other projects and coders I've worked with (or I am aware of) all came to the same conclusion.

Ultimately and even if the gains are not gonna be massive, it still seems like a waste if you can do otherwise (i.e. use pre-flipped sprites). All that assuming you do have enough RAM left (of course).

[aros-sg]

I tried how cannonball looks with half vertical resolution (320 x 112) and maybe it would make sense to have an option for this as it still looks quite nice actually. Especially in motion. Even better (or less bad) would be if the road stayed hires (if it was done with 2 planes reserved for road only) and the Ferrari was done with normal/hires Amiga hw sprite.

cannonball/src/main/sdl2/rendersurface.cpp:

void Render::draw_frame(uint16_t* pixels)
{
    uint32_t* spix = screen_pixels;

#if 0


    // Lookup real RGB value from rgb array for backbuffer
    for (int i = 0; i < (src_width * src_height); i++)
        *(spix++) = rgb[*(pixels++)];
#endif

#if 1
    for (int y = 0; y < src_height; y++)
    {
         for(int x = 0; x < src_width; x++)
	 {
	   *(spix++) = rgb[pixels[x]];
	 }
	 
	 if ((y % 2) == 1) pixels += src_width * 2;
    }
    
#endif
}

[TEG]

Originally Posted by d4rk3lf

These screenshots are absolutely beautiful.

+1

[reassembler]

Pre-flipping sprites is definitely faster when you are simply copying sprite data unmodified from A to B. I can totally understand why it's an obvious and logical approach for any simple sprite based game where you have the memory to do so. Especially on OCS/ECS.

However, once you're scaling and stretching sprites in real-time, there's no real performance advantage in pre-flipping. You're ultimately sampling the source data on a per pixel basis anyway. So the flipping comes for free as part of the process.

You might then logically conclude - why not pre-scale AND pre-flip everything. Well, maybe. OutRun has 1mb of sprite data. Let's say you pre-cache 50 scaled values of each sprite in memory, which is less granularity than you'd have doing it at runtime (OutRun actually has approx 300 potential scaled sizes per sprite). 50 scaled sprites would probably take around 75mb of memory given that a lot of the scaling makes things larger. Now double that 75mb again for the flipping and I suppose you're at 150mb ram just for the sprites.

There's an approach using less granularity. But I'd rather have smoother scaling. If I get to a point where I finish the engine to the point where there is the potential for a performant game, there are other level layout optimisations I'd make first.

[Tsak]

Originally Posted by reassembler

Pre-flipping sprites is definitely faster when you are simply copying sprite data unmodified from A to B. I can totally understand why it's an obvious and logical approach for any simple sprite based game where you have the memory to do so. Especially on OCS/ECS.

However, once you're scaling and stretching sprites in real-time, there's no real performance advantage in pre-flipping. You're ultimately sampling the source data on a per pixel basis anyway. So the flipping comes for free as part of the process.

You might then logically conclude - why not pre-scale AND pre-flip everything. Well, maybe. OutRun has 1mb of sprite data. Let's say you pre-cache 50 scaled values of each sprite in memory, which is less granularity than you'd have doing it at runtime (OutRun actually has approx 300 potential scaled sizes per sprite). 50 scaled sprites would probably take around 75mb of memory given that a lot of the scaling makes things larger. Now double that 75mb again for the flipping and I suppose you're at 150mb ram just for the sprites.

There's an approach using less granularity. But I'd rather have smoother scaling. If I get to a point where I finish the engine to the point where there is the potential for a performant game, there are other level layout optimisations I'd make first.

Excellent explanation, thanks!
In regards to pre-scaling I had no doubt that would be a no-go. That would also absolutely kill granularity.

[reassembler]

Glad that explanation made some vague semblance of sense. For what it's worth this runs with 2mb chip, 4mb of fast RAM. I'd expect the final version to maybe need 8mb fast RAM - finger in the air guess!

On Sunday, I'll get the latest code on the real Amiga. I've clocked UAE to 28Mhz cycle accurate in the hope it matches my 030 @ 50 Mhz more closely. Some of the stages fly along quite smoothly in UAE at that speed. But I can't count my chickens until I check again on hardware. I was pretty disappointed last time.

Porting games is a funny one philosophically. A lot of the greatest games throughout history have been native to their hardware. If you look at say Lotus 2, it's a brilliant experience because it exploits what the A500 did well - fast copper fills, smart blitter usage, carefully considered colour palettes, novelty weather effects to distract from the limited road layouts etc.

With OutRun the philosophy must have been - "OMG we have 30,000+ colours - almost infinite scaling sprites for free and dedicated road hardware!" And as such Yu Suzuki, Bin Chan and the programming team rightfully created a visual tour de force that paired a feast for the eyes with great gameplay. It made perfect sense in terms of attracting gamers in the arcade. However, when it comes to porting that approach to other platforms of the era, really it makes more sense to design a game from the ground-up that exploits what that hardware does well!

When I look back at how many poor arcade ports I played on the Spectrum in the 80s, I wonder why I bothered being suckered into buying them. The best Spectrum games were generally native to the platform and much better as they were designed around the limitations from the ground-up. Apart from Chase HQ, which was awesome on the Spectrum. Arguably the same is true for the Amiga - Bitmap Brothers stuff, Monkey Island, Lemmings and the Team 17 titles delivered some of the best pairings of design and hardware.

[jotd]

yes, that's why "technology equivalent" ports are difficult. That's also why I personally engage only on very old games (and there's still some challenge as even some 1983 games can have a 256 color palette, and others have selectable palette per sprite, with possible 64 sprites!!)

A1200/020 with fastmem is what most users with A1200 have (with CF IDE + whdload) so it's a reasonable target when you can't do vanilla A1200.