Originally Posted by reassembler (Post 1676298)

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! :spin

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.

Originally Posted by reassembler (Post 1676319)

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.

Originally Posted by reassembler (Post 1676298)

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.

Originally Posted by alexh (Post 1676378)

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

Originally Posted by tomcat666 (Post 1676379)

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 ?

Originally Posted by khph_re (Post 1676384)

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

Originally Posted by Don_Adan (Post 1676386)

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.

Originally Posted by reassembler (Post 1676353)

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

Originally Posted by DanyPPC (Post 1676586)

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

Originally Posted by vroom6sri (Post 1676713)

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?

Originally Posted by VladR (Post 1676779)

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.

Originally Posted by jotd (Post 1676983)

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.

Originally Posted by mrupp (Post 1677083)

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?