Final Fight AE CPS2 Beta Starts February 1st!

[undamned]

@Grego, thanks for the response!  That's great that Final Fight didn't require serious overhauling to work with a battery-less B-21!  With your knowledge of Capcom code & hardware style, there are some follow-up projects that I know many people are frothing for (https://www.arcade-projects.com/forums/index.php?thread/4734-bounty-cps1-5-games-with-q-sound-on-cps2-multi/).  I'll shoot you a PM regarding another item
-ud

[Grego]

Not sure how many of you saw my previous post talking about doubling the sprites.  But we have verified the technique on real hardware.

A bit of background:

The CPS1 controls where sprite ram is located via the "OBJ RAM base" pointer at $800100.  The CPS1 can show a maximum of 256 sprites per frame and per scanline, normally. Since a sprite uses 4 words to designate its position, tile id, and attributes, a full sprite buffer is $800 bytes, or 2k.

However, between the object and first scroll layer there is $8000 bytes available, or 16 times the amount of space for a single buffer. Final Fight uses this extra RAM to double buffer the sprite data, alternating between buffers at $900000 and $904000.  It does this because updating a single buffer results in artifacts on the real hardware.  The outcome is random if sprite RAM is being updated at the same time it is being drawn.

Final Fight's sprite drawing system works on a priority system with players coming first, then bosses, enemies, and so on. If the game detects that a sprite that should be drawn would overflow the 256 sprite limit, it will simply not draw the object.

In some of Final Fight's more action intensive scenes, some sprites will flicker or simply fail to draw. Due to the aforementioned sprite drawing priority system, first items and other inanimate objects will flicker, but eventually enemies will be affected too. Having too many enemies on screen will result in the enemies towards the end of RAM overflowing, leaving only enough room for a few items which only take up a few sprites. By a rough estimate the overflow is only a few dozen extra sprites, so if the CPS1 can in fact draw 256 sprites per scanline, perhaps it would be possible to double buffer sprites and reduce or outright eliminate flickering.

The task:

We have entered uncharted territory. The information about the CPS1 is scarce, and only one-liners like "Simultaneously displayable: 256 (per scanline)" on Wikipedia gave any hope this might work. Looking at MAME's source code it is clear that the only raster techniques it supports is the rowscroll table that Street Fighter II uses to render a perspective effect on the ground. However, it turns out there is an additional interrupt available on the CPS1's 68k. Some games use it for input related reasons, but according to the MAME source it is not entirely known why. Hijacking the hsync and vsync handling of MAME I was able to trigger this interrupt on a specific scanline and switch buffers.  There was no apparent effect. Since MAME does not assume any hsync based raster effects could occur in CPS1 its draw handling does not support it.  After modifying MAME further I was finally able to generate a real hsync based effect, disabling the sprites on the second half of the screen.

Clearly this is just a prototype, and alas may not work on the real hardware. I spent some time looking at schematics and planning my attack, soldered some lines to the hsync and vsync connections of my C board and set out to try some hardware. Initial tests were simple. I disabled Final Fight's double buffering, hooked up my hsync generator, and manually clicked through the hsync lines with microswitches.  I modified the code to switch which buffer was shown when the interrupt was generated, and after clicking to the correct scanline, sprites were disabled. Clicking more times renabled the sprites and I decided it was time to really give it a go.

Hooking up the hsync/vsync lines to my interrupt generater resulted in an interesting but planned-for effect. Every half frame the game switched between a full buffer and an empty buffer. The result being only half the screen is being drawn at a time. Since the human eye cannot percieve this and I do not have a camera fast enough to record individual scanlines, the apparent effect is transparency.

Here is some footage:

https://www.youtube.com/watch?v=cxichPTzGAw


Clearly something good is happening, but how do we know it will work with multiple sprite buffers?

The proof:

As mentioned earlier Final Fight already has two sprite buffers it uses. Disabling one shows the artifact of memory being written as a sprite is drawn.  This often appears as flickering on the sprite, but can also appear as the wrong sprite being shown, or offset strangely. By using the interrupt generater to switch mid frame to the sprite buffer that's currently being written to, we can see this effect.

Video:

https://www.youtube.com/watch?v=4I1hVhmdkXg

Notice the trashcan in the middle of the screen. It glitches ever so slightly because it is an item and has low priority when being drawn. However, in most cases the switching of buffers is virtually unnoticable, meaning that switching sprite buffers midframe is feasible. Since the sprite vram region is 16x the size of a single buffer, and we are only using two buffers regions currently, additional buffer room is available.

The final piece of the puzzle:

So this is all fine and well, but we still have an issue.  Sorting sprites would be too much for a 12mhz 68k.  So we need an algorithm that lets us split sprites into buckets. By tracking the y position of all sprites drawn in an accumulator and dividing by the number of sprites shown we can find the middle point of all sprites. Telling the interrupt generator that this is the line we wish to cause an interrupt on allows us to change buffers at the correct time. So now we need to create our sprite buffers. Using the previously calculated middle point of the last frame we can leverage our knowledge that objects move around VERY little in the y position frame to frame to fill our buffers. Objects below that line go in one buffer, above it another, and if it is within one sprites height of the mid-line, both. This has a computational complexity of O(n), as we are only doing a few additional comparisons, and no additional looping. Very handlable by the 68k.

So there it is, a technique to increase the sprite limit of the CPS1.  It even has the potential to be done multiple times per frame to further increase the upper limit.

[Goros Lair]

Grego, I have no words to describe what I'm feeling: awesome, amazing, incredible?

You made a dream come true to me when you enabled the 3 player mode and now, you not only made this possible, but taught to everyone How to do when face up the Challenge concerning to possible problems regarding something like that on CPS-1. You share your knowledge, and, as I've written above this is amazing. To be honest, I've been waiting for this update for 30 years... And, now, I know that this task is really with the right person.

Thank you for ALL your efforts and dedication, Grego. Waiting since the First page for the final release.

Congrats, buddy.

ALL the best to you.

C ya,
Goro.

[sztojanov]

Grego! In your last shared picture looking very great the new healthbars! Really love them! :-) The added shadows also great idea!

Using in the final hardware the "popular" B-21 C board is very good. Cant wait for the new teaser video!  Keep informed us please! Well done!!!

[Grego]

The second round of hardware testing was completed yesterday. Everything went very well, and we identified a bug in MAME with palette handling.

Our current estimates of progress:

AI Changes - 70%
Gameplay Systems - 100%
Enhancements - 90%
UI/Health Bars - 100%
Remaining Bugs - 40%

We are getting very close to completing the remaining bugs and nearly every feature is in place. We will be releasing a final teaser trailer in November which will include the release date. Christmas is coming early.

[Grego]

After many months and innumerable hours of development, Rotwang and I are proud to present the release trailer for Final Fight 30th Anniversary Edition!

Trailer:
https://www.youtube.com/watch?v=WKswmEWGb_0

Please keep an eye on this thread or the description of the video on December 1st 2019 to find download links and installation instructions.

[Goros Lair]

Hi Grego, thanks for the update. I'm waiting anxious for It. 12/01/2019 could be tomorrow.

[Cédric V]

GREAT WORK you've made a dream Come true
Good job 👍👍😍😉

[Grego]

Final Fight Anniversary Edition has been released!

Installer:

https://github.com/originalgrego/FinalFightAE-Installer

Source Code:

https://github.com/originalgrego/FinalFightAE-Source

Features:

* Three Players
* Selectable Palettes
* Unlocked Character Selection
* More Health for Enemies/Bosses with three players
* Uncensored Intro / No Region Warning

Enjoy!

Update: Please do not put the installer in a location with spaces in any of the paths directory names. Crc32.exe is having issues with spaces in the path, I am working on a fix. Sorry.

[ListoMefisto]

Congratulations!!! Great work!!! I have just played the game with 2 friends and we enjoyed it a lot!!! Fantastic!!!

Offtopic :

Could it be possible to do a hack from Dungeons & Dragons: Shadow over Mystara so it could be played with 6 players simultaneously? :

[Grego]

Thank you Listo! Cps2 cannot support six player without linking systems via the network adapter. Probably not going to happen any time soon. 😃

Edit: Actually you could do a hardware hack that multiplexed inputs and do six player possibly.

[kairi1977]

wow, can you do a video tutorial how it does ?

[Grego]

Kairi, not sure what you mean. A tutorial on how we made this?

[ListoMefisto]

One question. We noticed that the 3rd player increases points correctly but the last digit, the one that represents the number of credits used doesn't increase when you die and continue. Is it possible to increase the number of credits used? We would like to do a 1 credit clear game (3 players) and that digit is the proof that you didn't use more credits We are enjoying a lot playing 3 players Final Fight! It rocks!!

[Cédric V]

Sorry to inportune you but i 've tried with Many zipped roms with the good CRC and it doesn't work for me ( Always message with Bad crc's)
I don't unsterdstand ??

I've the last java version

[Solid One]

Great job. Playing this classic with three players will be awesome!

BTW, is it possible to play this hack on other emulators, such as Final Burn Neo (so I could play it on a Raspberry Pi, per example)? Or only on the MAME fork mentioned in your github repo?

[CrispX]

Thank you! 

[ListoMefisto]

Another question. We noticed that the 3rd button is disabled, the one you could use to avoid the attacks from Andores (the attack they use when they grab you). Is it disabled on purpose? Thanks!

[Grego]

Listo - Sorry about the continue point, we will correct that in the future. About Andore, not sure what you mean, Final Fight is a two button game.

Cedric - Do not put the installer or the rom in a directory that has spaces in it.  The safest bet currently is to do something like creating a c:\ffae_installer\ folder and putting the installer and the ffight.zip in the directory and running the installer. I apologize for the inconvenience.

Solid One - It is possible to play this rom on any emu that supports it.  I fully expect other emulators to add FFAE support soon.

CrispX - You're welcome!

To everyone having issues with the installer, I apologize, it was the least tested component of the hack and clearly we didn't do a great job with file handling. We will be releasing an update to the installer in the next day or so, it's been a long development cycle and we are both tired and need a few days rest.  For now please put the installer AND THE ROM into a folder that has absolutely no spaces in the path.  For example:

c:\ffae_installer\ <- Put ffae_installer zip contents and your ffight.zip rom here!

Sorry again for the inconvenience, we will make it a priority to improve the installer as soon as we can bear to look at a computer again.

[snesfanboi]

This is awesome and plays a treat, would love to see you revisit Final Fight snes down the line!