Final Fight: Enhanced

[jotd]

Crazy it is!! Great, really great project! It reminds me (in spirit) of the transcode of Xevious, except that here no need to transcode.

However, resolving the "placeholder stuff" naively is going to lead to 1 frame per second... But then, special cases could be built to bypass the original game display logic in some places and do then things the amiga way.

[Retro1234]

Love to see that running with the placeholders on Amiga

[d4rk3lf]

Originally Posted by Brick Nash

- 2MB of Chip RAM is needed. I'm not sure if it'd work with modded A500s which can access 2MB Chip RAM, but I'm not using anything else which is ECS specific (yet), so I don't see why not (I'm not really knowledgeable enough to say though).

Well that puts me bellow hardware requirements with my Aca 500 plus, 1MB chip, 7 MB Fast, and processor up to 42Mhz speed.
Oh well, I'll play it on emulator.
Or this would be a good excuse to purchase some nice A1200.

Have you asked Richard Aplin how he managed to make it run on unexpanded A500, with just 512kb chip ram?

Thanks for other answers.

[Cris1997XX]

Originally Posted by d4rk3lf

Well that puts me bellow hardware requirements with my Aca 500 plus, 1MB chip, 7 MB Fast, and processor up to 42Mhz speed.
Oh well, I'll play it on emulator.
Or this would be a good excuse to purchase some nice A1200.

Have you asked Richard Aplin how he managed to make it run on unexpanded A500, with just 512kb chip ram?

Thanks for other answers.

We need to ask him about Double Dragon II as well, he really managed to pull off some programming magic at times

[Tsak]

Originally Posted by d4rk3lf

Have you asked Richard Aplin how he managed to make it run on unexpanded A500, with just 512kb chip ram?

Realtime character frames flipping and just a few frames included per character.

[Brick Nash]

Originally Posted by d4rk3lf

Have you asked Richard Aplin how he managed to make it run on unexpanded A500, with just 512kb chip ram?

He'll be able to tell you in more detail than me, but the game had its own custom memory manager which would decompress graphics and defrag memory on the fly. This allowed the program to load in new baddies from disk in real-time while the game was still running, so it appeared that there was more data stored in RAM than what actually was.

Also, a custom CPU sprite-flipping routine was used, which, when I was writing my own for the 1Meg version, discovered that's where most of the slowdown comes from. The CPU has to drop what its doing to go and flip bits in graphics data using a lookup table and place it in a buffer, but it's so much slower than doing it with dedicated hardware (which the Blitter can't do), and to add insult to injury, the Amiga's planar screen setup means it has to do this for each Bitplane, so it's 4 times the work (all on multiple massive sprites).

The memory managing stuff is way beyond my skill set. I'm just using stock OS Allocation/Deallocation functions between levels, but what Richard did was next-level stuff!

[gian2k]

32 colors on screen..

[jotd]

Originally Posted by Brick Nash

Also, a custom CPU sprite-flipping routine was used, which, when I was writing my own for the 1Meg version, discovered that's where most of the slowdown comes from.

Yes, using the cpu to flip memory in chipmem is just so slooow. Now try to run code from chip memory...
I think even if you flip then blit then flip the second plane while the first plane is being blit it's still slow.

Using a 8 bit lookup table is slow, using a 16 bit lookup table would take 128kb and would be slightly faster... but that's 128k you could have used for graphics...