OutRun: I started porting it!

[saimon69]

Originally Posted by reassembler

The main thing - and I'm going to regret saying this no doubt - is that a lot of the remaining game logic should be relatively easy. It's almost a copy and paste job from the original source code. I've found solutions for all of the rendering required and just about have enough colours remaining. It also isn't particularly performance intensive.

I remember the original cannonball blog that was describing how they did organize the traffic flow in the arcade game, and wonder if will scale properly

[trixster]

A demo would be great!

I’d be keen to test on my 28Mhz 020 8MB A1200.

[Cathal]

Amazing Work!
When the Demo is available I can test a lot of different A1200/A4000 setups from 030/50 to 060/66, Vampire V4 (Icedrake & Firebird) and PiStorm32/CM4.

[mrupp]

This really looks amazing and the last video already was very promising.
I love this game and was quite hooked to it when I was a teenager. I remember that I once even dreamed of playing a perfect port on the Amiga and that when I woke up I was feeling... err.. well, you know... as we're stuck with this horrible US Gold port.

So this is LITERALLY a dream coming true!

Can't wait to beta test on my A4000/060, A1200/030 (Blizzard), CD32 TF030 and Vampire V4.

Keep up this excellent drive of yours, you're amazing
Michael

[reassembler]

Latest video showing things running on hardware:

[ Show youtube player ]

[DanyPPC]

Simply excellent

[gingerbeardman]

Lovely! Looking great.

ps: in the long video there's a graphical glitch at 02:05 you are probably aware of but I thought I'd mention just in case.

[reassembler]

Originally Posted by gingerbeardman

Lovely! Looking great.

ps: in the long video there's a graphical glitch at 02:05 you are probably aware of but I thought I'd mention just in case.

Well done for spotting this. I was going to ask on here if anyone had any theories as to what caused this.

It's a random bug that occasionally seems to spam a single frame of erroneous graphics data to the screen. I've attached a slightly better quality image. You can spot a ghosted image is split down the centre of the screen and mirrored in two directions. It's almost as if some of the individual bitplanes are going haywire and displaying in the wrong place. I write to the copper list to swap bitplanes every frame, so perhaps it's related to my double buffering code or timing?

I can reproduce this in UAE, which makes me think it's some sort of timing issue or memory corruption that I've introduced.

It's not consistently repeatable so I haven't spent time trying to address it... yet.

[demoniac]

Excellent update.

Is that the same bug that seems to remove the lanes in the first level?

[Keops/Equinox]

Really nice!

[jotd]

Did you bench your engine with all cars displayed? Small blits can kill performance as much as big blits

great work!

[reassembler]

Originally Posted by jotd

Did you bench your engine with all cars displayed? Small blits can kill performance as much as big blits

great work!

Not yet. Traffic will probably be one of the more significant performance killers remaining. But there may be optimizations elsewhere to compensate for that.

[reassembler]

Back to that minor graphical corruption bug. Is this a dumb way of doing double buffering?

In my Coplist, one of the first things is the usual list of bitplane pointers. The actual addresses of the bitplanes are written by code, but the start of the coplist is...

    
    DC.W    BPL1PTH,0       ; High word APTR bitplane 1
    DC.W    BPL1PTL,0       ; Low word APTR bitplane 1
    DC.W    BPL2PTH,0       ; High word APTR bitplane 2
    DC.W    BPL2PTL,0       ; Low word APTR bitplane 2
; etc for the rest of the bitplanes!

The final entry in the CopList is a standard, wait for VBLANK entry:

dc.w    $ffff,$fffe

At which point the coplist will wrap and setup the bitplane pointers again during the VBlank itself.

My main 68K loop ends by waiting for a VBlank as follows, pseudo code:

    bsr           Chunky2Planar   ; Output to the *current* bitplanes
    bsr           SwapBitPlanes   ; Update the coplist to point to the *current* bitplanes and then denote next time round we'll be writing to the alternate set.
    bsr           WaitVBlank      ; At which point the Coplist will also wrap and process the bitplane pointers
    bsr           DoVBlankStuff   ; Palette changes and OutRun specific code

Now presumably there could be a timing mis-match where SwapBitPlanes occasionally gets called just after a VBlank, dependent on frame timing. This would mean that the Bitplane pointers in the CopList were written to, let's say, halfway through the point at which the Copper is reading them. And cause a temporary frame of corruption.

I hope I'm making sense. Is there an obvious solution to this I'm missing?

[reassembler]

Hmm... and yes I'm sort of talking to myself here. Maybe I need to disable the copper DMA during the SwapBitPlanes routine.

Edit: Well that might have fixed it. Although given the intermittent nature of the issue, we shall see.

[jotd]

I usually swap the bitplanes in the copper interrupt (so bottom of frame, not top of frame), not vblank, so there is plenty of time to set them.

From vblank, I think I had issues for the reason you stated: changing copperlist while copper is potentially reading too is a big problem.

[reassembler]

Originally Posted by jotd

I usually swap the bitplanes in the copper interrupt (so bottom of frame, not top of frame), not vblank, so there is plenty of time to set them.

From vblank, I think I had issues for the reason you stated: changing copperlist while copper is potentially reading too is a big problem.

This also occured to me as well. I'm presuming the approach of disabling copper DMA is faster than enabling Copper interrupts, so long as disabling DMA doesn't cause the copper to miss doing something important...

Anyway, it sounds like there's a backup/alternate approach so thanks for the response.

[saimon69]

So you are using a 030/50, what the performance would be in a EC030/40 like the one i have? (i would suggest some kind of rendering reduction option like skip one side object every 2 or 3 unless needed or maybe side object rendering in 2x2 or even 4x4 pixels))

[d4rk3lf]

Originally Posted by reassembler

Latest video showing things running on hardware:

[ Show youtube player ]

Fantastic job.

Just out of curiosity, what you think would happen if you run it on a Stock A1200 (maybe with some added Fast Ram)?
Will it refuse to run at all? Or it will crawl?

Keep up the amazing job.

[chiark]

Not an original comment but huge congrats, this is awesome to see, and great that you've stuck at it! Brilliant work, keep going, can't believe how much you're managing to optimise this.

[reassembler]

Originally Posted by d4rk3lf

Fantastic job.

Just out of curiosity, what you think would happen if you run it on a Stock A1200 (maybe with some added Fast Ram)?
Will it refuse to run at all? Or it will crawl?

Keep up the amazing job.

Using WinUAE, cycle accurate - it runs on an A1200 configuration with added FastRAM. But it's too slow to be anything beyond a curiosity - although US Gold would have probably released it. I haven't tried on hardware.

I will be implementing toggles for a lot of the graphical elements in the final release, so you'll be able to compromise visual fidelity to claw back some speed - but not to the point where it's ever going to be any fun on an A1200.