OutRun: I started porting it!

[Havie]

Originally Posted by jotd

no a 68882 isn't going to help, it's not really 3D. Scalar power is required, not FPU

About low performance of AGA: that's the "feature" that makes it challenging. If it was too powerful, a lot of those games would already exist, or there would be a useable MAME and no point trying to shoehorn those games on Amiga.

(which leads me to the hot question: what's the point of trying that on vampire or pistorm? is that an improvement over MAME? that's an honest question, don't flame me)

Fair enough question. The version of Cannonball runs OK on my 1200 but sound is a problem (which I think we would agree is half the game) and there are no backgrounds. Plus who wouldn't want to run an Amiga coded version on their actually Amiga?

And it's not a specific Vampire/Pistorm port - just runs faster. We need to justify our purchases

[Don_Adan]

Originally Posted by reassembler

What are your Amiga's specs?

In other news I did try the HOMM2 C2P rendering routine from Meynaf in place of the one I was already using, but it was slightly slower on hardware. I guess that C2P is pretty much as fast as it's going to get unless I do something destructive like reduce the screen height.

I think that You made something wrong (out of 240 bytes caches?).
Speed differences are too big for me between meynaf and Kalms version on 68030.


https://eab.abime.net/showpost.php?p...&postcount=196

[reassembler]

Thank you - yes I did originally see your post, which was one of the reasons I was encouraged to try a different C2P algorithm. I'm no C2P expert, but I'm guessing they're going to be impacted by DMA usage, screen resolution, number of bitplanes, bitplane transfer modes, accelerator card design and various other factors.

As a result, my singular test will probably not match your results exactly. Don't get me wrong, the HOMM algorithm was maybe about 5% slower from memory - there wasn't a lot in it. But either way, it didn't make me believe there was a lot of performance to be gained by experimenting with different algorithms vs. optimizing elsewhere in the codebase.

[Don_Adan]

If this is not special Kalms version for 68030. Then only T030 and HOMM2 versions are fast on 68030. Others are much slower.

Edit. Of course from benchmarked c2p. You can benchmark others c2p routine by replacing already available c2p, or by adding new entry for c2p. If I remember right (re)source code was attached.

[Don_Adan]

Dont exist 1 universal fast c2p routine for all Amiga configs.
For me every good Amiga game/port which used c2p and speed is important must have menu/config.
Amiga user can choose c2p routine used by game/port.
Maybe You can create test/demo version of OutRun port within choosable c2p?
Most of c2p routines are free, i think. Credits for author can be enough.

[braunaudio]

Stats:

Logic 14
Road BG 5
Road FG 1C
Tiles 17
Sprites 7D
C2P FC

Vblanks 1



AA3k+ with BFG060 @50mHz

Again, as noted previously, with Network active (Genesis/AmiTCP), the demo locks up very quickly.

Also did notice a solid horizontal black bar at times that moved with the background (see attachments).

Fantastic Work though!!!!

[idrougge]

Originally Posted by jotd

(which leads me to the hot question: what's the point of trying that on vampire or pistorm? is that an improvement over MAME? that's an honest question, don't flame me)

Quoted for truth. Just waiting for the UAE scores…

[Seiya]

winuae with cpu_speed=max, No JIT. information taken as soon as start the engine:

Logic C
Road BG 1
Road FG 2
Tiles 2
Sprite 1B0
c2p 94
Vblanks 1

[lmimmfn]

Originally Posted by jotd

no a 68882 isn't going to help, it's not really 3D. Scalar power is required, not FPU

About low performance of AGA: that's the "feature" that makes it challenging. If it was too powerful, a lot of those games would already exist, or there would be a useable MAME and no point trying to shoehorn those games on Amiga.

(which leads me to the hot question: what's the point of trying that on vampire or pistorm? is that an improvement over MAME? that's an honest question, don't flame me)

There's nothing wrong with users posting Vampire or PiStorm scores, yes they would probably get good enough FPS with MAME(if a decent 68k version exists with compatibility ).
What we all like to have is a decent Amiga version of Outrun that can run on hardware if tgr time, maybe it needs a 040 or higher, so be it.
If others gave more powerful hardware thrn maybe they get 60FPS rather than 30 on native hardware, it's all good

[skyzoo73]

I wonder how much room for improvement is left
once the cars and all the logic are in the game.
I see it very hard for a poor 030.

[alexh]

Originally Posted by skyzoo73

I see it very hard for a poor 030.

Get a PiStorm32 lite? €100

[trixster]

100Mhz BFG9060

Logic: D
Road BG: 4
Road FG: 10
Tiles: 13
Sprites: 169
C2P: E5

Vblanks: 2

[skyzoo73]

Originally Posted by alexh

Get a PiStorm32 lite? €100

I already own an 040, and in the future I will get a Pistorm.
But my comment above does not relate in what I have available. My interest was in knowing what kind of performance will be achievable on the 030, and how much further performance improvement over the current version again with the 030.

[reassembler]

I think we've got enough speed reports now. It runs on a variety of setups, which is the news I needed. I've fixed the lock-up bug also in the codebase.

Originally Posted by skyzoo73

My interest was in knowing what kind of performance will be achievable on the 030, and how much further performance improvement over the current version again with the 030.

It's a fair question and we won't truly know until all features are implemented.

The most significant performance drains are already in:
- Sprite Scaling (still some performance improvements to be found I suspect)
- C2P (marginal improvements based on target hardware and algorithm)
- Road Rendering (pretty optimized now, but you never know)

The remaining game logic is relatively light. Rendering the Ferrari won't be significant. Rendering the traffic slightly more so, as it needs to sprite scale.

However, even if I don't speed things up further by ingenuity, there are obvious areas to gain a 'cheap' increase in speed.

- Reduce scenery (could easily speed dense levels up by 50% overall)
- Remove the smaller tile layer which needs to be mixed transparently (or simply blit it over the background tile layer and have them both scroll at the same speed)
- Toggle Shadows
- Reduce the display height. Simply not rendering the top 32 pixels in a C2P fashion where the HUD lives could yield a decent increase.
- Insert your idea here.

I quite enjoy optimizing code though. So my preference is always to optimize as much as possible rather than immediately reach for the scissors. It's not like I'm employed by US Gold and have to get this out for a deadline!

I'm unsure what drain a MOD player and effects mixing will have at this stage, having not coded for the Amiga previously. All part of the adventure.

[emiespo]

Originally Posted by Bruce Abbott

Ideally the A1200 would have had AAA, but even with 15 engineers working on it they couldn't finish it in time. AGA was an incremental improvement on ECS that they did manage to produce before the market collapsed. I wouldn't say that was 'messing' the Amiga.

Having watched the tests on various setups I can say that lack of bandwidth and/or chunky mode is not the issue. This thing just needs a lot of CPU power.

On the A1200 with Blizzard 1230 III only 14% of the time is spent on c2p.

On the A4000 with Cyberstorm 060 c2p time increases to 20%, so the CPU is still spending 80% of its time doing the other stuff. If ChipRAM bandwidth was doubled it would speed up by a mere 11%.

Correct, but I was referring to the combo: faster VRAM and a chunky mode, no silly Akiko. Add a bit of fast RAM and Doom and many other 3d games would've been more than playable on any AGA machine, with performances inline with PCs for faster CPUs.

Also, those numbers don't look too right, I get that the C2P used might not be the best for the 68060, but how can it spend 20% vs 14% being almost 4 times faster than the 68030 in the Blizzard?

Or maybe it says exactly the opposite, ie that the c2p takes *a lot of time* as it really steals a lot of valuable time from a faster CPU.

Back to the AAA, 15 engineers for how long? Every insider said that the engineering team was heavily underfunded and incremental projects were cancelled more often than not. Lack of any business plan, according to Pleasance.

[emiespo]

Originally Posted by reassembler

- C2P (marginal improvements based on target hardware and algorithm)
- Insert your idea here.

Is the blitter doing anything atm? If not, given CPU needs any tiny bit of performance to cope with sprites and other logic, it might make sense to give it a go with a blitter-assisted C2P.

I found that with DoomAttack, the blitter C2P gives almost the same results as the Akiko c2p. Might also make the game playable on lower specced CPUs (ie: 68030@25MHZ).

[paraj]

Originally Posted by reassembler

I think we've got enough speed reports now. It runs on a variety of setups, which is the news I needed. I've fixed the lock-up bug also in the codebase.



It's a fair question and we won't truly know until all features are implemented.

The most significant performance drains are already in:
- Sprite Scaling (still some performance improvements to be found I suspect)
- C2P (marginal improvements based on target hardware and algorithm)
- Road Rendering (pretty optimized now, but you never know)

The remaining game logic is relatively light. Rendering the Ferrari won't be significant. Rendering the traffic slightly more so, as it needs to sprite scale.

However, even if I don't speed things up further by ingenuity, there are obvious areas to gain a 'cheap' increase in speed.

- Reduce scenery (could easily speed dense levels up by 50% overall)
- Remove the smaller tile layer which needs to be mixed transparently (or simply blit it over the background tile layer and have them both scroll at the same speed)
- Toggle Shadows
- Reduce the display height. Simply not rendering the top 32 pixels in a C2P fashion where the HUD lives could yield a decent increase.
- Insert your idea here.

I quite enjoy optimizing code though. So my preference is always to optimize as much as possible rather than immediately reach for the scissors. It's not like I'm employed by US Gold and have to get this out for a deadline!

I'm unsure what drain a MOD player and effects mixing will have at this stage, having not coded for the Amiga previously. All part of the adventure.

Yeah, there doesn't seem be much point in optimizing C2P now (since you're not overlapping it with anything else). It can (potentially) be a cherry on the top at the end.

Sprite scaling seems to be the major bottleneck, for good reasons of course. If you're currently just doing the obvious thing of scaling down large sprites, maybe it is worth looking into using precomputed mipmaps. Not for fidelity, but to limit memory fetches needed for smaller incarnations.
For transparent ones (which I guess are most of them) maybe it's also possible and faster to process them "SIMD-like" one long word at a time? (Haven't though this one through).

Just some food for thought, as you seem quite capable of optimizing on your own



Playing mods is usually not that bad, but effect mixing might be depending on how advanced stuff you're doing.

[trixster]

@emiespo please let us not go back to AAA arguments with Bruce Abbot. This thread is about this amazing Outrun port. There are other threads for what ifs.

[jotd]

are you sure you need to scale the cars too? Or maybe scale them in a cache and use the cache afterwards? there aren't too many car types IIRC.

[reassembler]

Originally Posted by paraj

For transparent ones (which I guess are most of them) maybe it's also possible and faster to process them "SIMD-like" one long word at a time? (Haven't though this one through).

Yes these sprite ideas have potential. The Arcade hardware (and this port) use ~5 pre-computed sizes to work from in fact. It's not simply one source image scaled up and down.

For the sprites - I actually think one decent optimization would be to not worry about x-clipping the sprites and making the chunky buffer wider with padding either side. It may sound counter-intuitive, but often the dumb approaches can work as well as the intellectual ones when looking for speed increases. Sometimes it's just faster to write data no matter what.

I haven't really delved into the C2P algorithms deep enough to understand whether this is trivial, or would incur a performance decrease - if they expect the chunky data to be contiguous for example and an equal size (well bitplane wise) to the target bitplanes.

If anyone out there has coded C2P algorithms in detail and is happy to talk me through it in detail via e-mail and answer dumb questions, drop me a PM.