OutRun: I started porting it!

[vulture]

You could still include those cut back options for lower speced systems, regardless of what gains further optimisations may yield, if it's not too much hassle of course.

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.

[paraj]

Originally Posted by reassembler

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.

I won't claim to be a C2P expert, but feel free to ask questions here or in DM (or via e-mail, get it from there).
But basically you're always doing it on 32 aligned pixels at once (so you end up with 8 long words of planar data). This is still good and relevant: https://amycoders.org/sources/c2ptut.html
For 8-bit screens You need 5 (log2(32)) passes to do it, and the blitter assisted onces are called c3b1 because they do 3 of the passes on the CPU and do one combined pass that handles 2 with the blitter (it's slightly more complicated, but that's the idea)

This has been optimized to death, so only substantive improvement is overlapping chipmem stores with other non-C2P computations (and I think this is only useful on 060+, but have not checked). It is not trivial though, as you're very limited in both the amount of instructions and what you can do (no cache misses for example). (I experimented with it a while back, and while it works it's not really generally useful: https://eab.abime.net/showthread.php?t=111352)


Don't think C2P optimizations are where you want look ATM, but since I don't know the engine, maybe there are opportunities I don't know about.

[reassembler]

paraj - That's a useful summary. When I next get back to looking at C2P related stuff, I'll give you a shout!

[alexh]

Originally Posted by reassembler

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.

I would recommend you look at LSP (light speed player) a relatively new module player for Amiga heavily optimised for speed, size or both. Significant runtime performance improvement over classic mod replay routines. Developed by Leonard of Oxygene it was created to help add music to record breaking demo attempts when CPU power was needed for the main effects

[tomcat666]

Originally Posted by alexh

I would recommend you look at LSP (light speed player) a relatively new module player for Amiga heavily optimised for speed, size or both. Significant runtime performance improvement over classic mod replay routines. Developed by Leonard of Oxygene it was created to help add music to record breaking demo attempts when CPU power was needed for the main effects

Don't think that natively supports playing of SFX at the same time though. It is more meant for demo productions.
I think https://aminet.net/package/mus/play/ptplayer would be more suitable for what is needed here, or ?

[jotd]

ptplayer is very good for sfx+music. However, it does not support varying engine noise, only looped/not looped.

I would drop engine noise altogether as it wastes 1 channel. Offer music+sfx or engine+sfx option like it was done for Supercars 2 AGA (which uses ptplayer unless engine noise is enabled)

[khph_re]

Roondar's sound mixer might be useful:

"mixing four samples onto a single channel at 11KHz takes only 3.7% CPU time on a 7MHz 68000 without Fast RAM"


https://eab.abime.net/showthread.php...ht=sound+mixer

[Don_Adan]

Originally Posted by tomcat666

Don't think that natively supports playing of SFX at the same time though. It is more meant for demo productions.
I think https://aminet.net/package/mus/play/ptplayer would be more suitable for what is needed here, or ?

LSP needs only 2 Amiga channels for playing converted MOD, if I remember right.
Then 2 channels are free for SFX.
If Roondar's mixing routine will be used, then up to 8 mixed SFX can be played.
For me LSP with or without mixing routine for SFX is optimal setup for new Amiga game (port) for fast handling music with SFX.

[roondar]

Originally Posted by khph_re

Roondar's sound mixer might be useful:

"mixing four samples onto a single channel at 11KHz takes only 3.7% CPU time on a 7MHz 68000 without Fast RAM"

https://eab.abime.net/showthread.php...ht=sound+mixer

Thanks for the mention

To add to this, I did test the mixer on much faster CPU's as well. 22KHz playback, single channel, four samples takes around 0,8% CPU on a 030/50MHz.

Do note however that my mixer only supports pitch changing through a plugin routine and that does cost quite some CPU time* (~5% per sample that has its pitch changed on the same 030/50MHz, assuming 22KHz playback).

*) I misread my own performance data table, which had plugin results per 4 samples having the plugin active instead of one . It's actually ~1,35% CPU time per sample that has its pitch changed on the same 030/050MHz, assuming 22KHz playback

Originally Posted by Don_Adan

LSP needs only 2 Amiga channels for playing converted MOD, if I remember right.
Then 2 channels are free for SFX.
If Roondar's mixing routine will be used, then up to 8 mixed SFX can be played.
For me LSP with or without mixing routine for SFX is optimal setup for new Amiga game (port) for fast handling music with SFX.

I can confirm that LSP uses as many channels to play back music as the original MOD did. It is really, really fast though, so well worth the use!

[Don_Adan]

Originally Posted by reassembler

paraj - That's a useful summary. When I next get back to looking at C2P related stuff, I'll give you a shout!

I think that You can use external c2p routine like for Gloom game.
File to load (stored in main game dir) can be called "default.c2p".
Others c2p routines can be stored inside "c2p/" subdir.
Amiga user can copy/rename c2p which want to tests.
F.e. Akiko plus fast ram, is fast enough for handling c2p, then CD32 with fast ram can be enough. Your game needs fast memory.
And of course Paraj or other coder can wrote own version of c2p routine for tests.

[DanyPPC]

On Aminet there is also a new c2p library:
https://aminet.net/package/dev/misc/c2plib

[vroom6sri]

Originally Posted by DanyPPC

On Aminet there is also a new c2p library:
https://aminet.net/package/dev/misc/c2plib

I've tried reading through the documentation but it is way beyond me. Is this aimed at developers rather than users? If it is for users please can anyone dumb it down enough for me to understand how to try out this new C2P library in games like aDoom and Gloom?

[DanyPPC]

I think games must be updated to support the new library.

[VladR]

Originally Posted by vroom6sri

I've tried reading through the documentation but it is way beyond me. Is this aimed at developers rather than users? If it is for users please can anyone dumb it down enough for me to understand how to try out this new C2P library in games like aDoom and Gloom?

It is absolutely aimed at developers. You can't do **** without having the source code of the game and being able to recompile it after replacing the current C2P routine with the new one.

[robxbl69]

Crashed (locked up the Amiga) when I tried to start from my normal workbench, but that could be anything from RTG to Network Stack causing issues. A quick reboot into minimal shell start-up (as I use for demo's and most games and worked fine).

A4000 with CyberStorm Mk2 060 + 68882 @ 50MHz, 2MB chip (obviously) and 366.5MB of available fast ram. Amiga OS 3.2.2.1.

Logic 20
Road BG 4/5
Road FG 2B/2C
Tiles 3E/3F
Sprites 2EF...2F5 (lots of flickering)
C2P E6/7
VBlanks 3

Runs really fast

Great work...

[vroom6sri]

Originally Posted by VladR

It is absolutely aimed at developers. You can't do **** without having the source code of the game and being able to recompile it after replacing the current C2P routine with the new one.

Thanks for clarifying.

[jotd]

if the game runs good on classic amigas even if it needs 68040 or 68060 that's already an achievement. We've been stuck with super-slow MAME for too long and even PacMan is unplayable on a 68060 on MAME, not sure RTG help at least not all cards are fast, Pixel64 was not.

[mrupp]

Originally Posted by jotd

if the game runs good on classic amigas even if it needs 68040 or 68060 that's already an achievement. We've been stuck with super-slow MAME for too long and even PacMan is unplayable on a 68060 on MAME, not sure RTG help at least not all cards are fast, Pixel64 was not.

I apologize if this is slightly offtopic, but at least this is still OutRun related:
Do we have a MAME 68k version that supports OutRun? I found out it needs MAME 0.36b2, but on Aminet the latest version is 0.35.12 (mame060.lha) and I tried that one and it doesn't run OutRun (of course). Apparently, there's supposed to be a v0.60, but I couldn't find any working links for downloading. Does somebody know a working link or could upload v0.60 to the Zone?

[tomcat666]

Originally Posted by mrupp

I apologize if this is slightly offtopic, but at least this is still OutRun related:
Do we have a MAME 68k version that supports OutRun? I found out it needs MAME 0.36b2, but on Aminet the latest version is 0.35.12 (mame060.lha) and I tried that one and it doesn't run OutRun (of course). Apparently, there's supposed to be a v0.60, but I couldn't find any working links for downloading. Does somebody know a working link or could upload v0.60 to the Zone?

There is a mame 0.60 , but actually it is 0.37 version. It does run OutRun, unfortunetly it still has minor gfx glitches (sprites shifted a bit, shadows not transparent, etc.) and this mame only opens 16bit screens (even though it has a DEPTH parameter which even when set to 8 opens 16 bit screens) so it seems its RTG only. In the zone.
With pistorm32 2.2ghz you get "smooth" gameplay with frameskip 2.

[Cris1997XX]

I'm not exactly a programmer, so I'm not sure if my words make any sense. But still...would it be possible to use sprites for the HUD in order to avoid straining the CPU even further? Maybe some blitter objects for things like cars, or simply just the road stripes. Otherwise sacrificing a few pixels of resolution might also work