Dreamcast-Talk.com

justin wong came up with this interesting ratio system for marvel vs capcom 2. instead of players being able to pick 3 top-tier characters and making a large portion of the cast competitively unviable, he created this table where each character corresponds with a point value. a player has a maximum of 7 points to "spend" in choosing characters.

my idea was to hack the character select screen of mvc2 to force this ratio system. my experience with hacking arcade games is with super puzzle fighter 2 for cps2 - I did a hack which changes drop patterns and damage values as well as adds some quality-of-life changes. so the jump from 68k to sh4 has been an interesting one!

here is my progress thus far:
[JP version]
memory address P1 cursor char: 0x0c2fb188
memory address P1 cursor row: 0x0c2fb15c
memory address P1 cursor col: 0x0c2fb15e
PC which writes new character c1c5636

[USA version]
P1 cursor row: 0x0c2fb2be
P1 cursor col: 0x0c2fb2bc

the next step is to get into some sh4 asm hacking.
I need to find a place in memory to store P1 and P2's current ratio totals. should need just 1 byte each.
then I need to append a table to the end of the ROM with the ratio data. the table could look like (from the start) 22322441...22411, with 0 for 19, 1A, 1B.
so when the lookup happens the game can cross reference the new character select space with this table.

preliminary work would be to add the character's respective ratio table value to the player's current ratio total. so, for example, if player 1 selects ryu, zangief, and guile, their current ratio total byte should be 0x08. if p1 selects spiral, iron man, and sentinel, it should be 0x0F.

I've got a couple different ideas on how to prevent a player from selecting a character that is greater than their current ratio amount left:
A) insert code before the button press of selecting a character which checks the cursor character's ratio data against 7-player current ratio total. if <0, break past the selecting code.
B) modify the cursor movement code to add a check. currently, for example, if you've already selected a character, and you try to put your cursor on that character, the cursor will jump past them.

it would be very helpful if anyone could point me towards resources they're using for disassembly/hacking. I'm not sure what format this ghidra plugin is looking for
https://github.com/lab313ru/ghidra_sdc_ldr
and it seems ghidra doesn't have sh4 support, so not sure how to go about that.

I got this tool "SuperH disassembler" and it seems pretty useful. currently trying to track down the binary code within the naomi files. it seems like since the USA version of mvc2 (mvsc2u) is just one file, there's a good chance that this is the main binary.

at around 0c2f8cd8 (JP) is the text like "press start button" and "credit(s) X" so you can see there's a %d, I was going to see if I could change this to display some arbitrary byte of memory instead of the number of credits inserted. that could be a way to display remaining points per player. the text would need to be enabled even when 2 players are present - currently it is only present while 1 player is present at character select.

thanks for looking!

I got ghidra working with naomi mvc2 usa. the binary seems to be the singular file in mvsc2u and it opens as superh4 little endian.
now working on a disasm of the character select system. when the player moves the joystick, it starts up what I've labeled as moving_cursor_a at PC 0xDEA2 (ghidra and mame address differently, in mame this is 0x0C1CDEA2)
right above moving_cursor_a, it seems to be testing on every frame that the currently selected cursor character is the same as the one that should be loaded there, so I guess input changes the target and the test fails and then we go to moving_cursor_a
so it goes through UP TO 5 of these checks, eventually spitting out the destination character's number minus 1: if I try to move onto characters that are already taken, it runs through the a through e checks for each one. separately, I spoke with someone from nulldc bear and they stated that having the disasm of the game would help in implementing rollback netcode for the game, so that's pretty hype.

I like your initiative and altought i see your goal with that deep hacking to add a ratio for the characters, i am more in having a proper arcade port for the dreamcast.

You know, both naomi and dreamcast are almost the same game and share code but have their differences like some characters are in different place on the select screen , there are more images in the ending sequence and finally the ability to straight pass to the character selection without seeing the menu.

If you can combine both in one game a la neo geo with the console and arcade options maybe the main menu can be accesed in the same fashion as mortal kombat trilogy from n64 (pressing up+start or another button combo in the press start screen after the coins).

Other than that i wish you the best of the patiente to achieve the dissasemble and i invite you to share this work in the romhacking forums too.

mountainmanjed's disasm of mvc2 dc https://github.com/jedpossum/marvelous2/ had this table dumped RAM from mame and found it here and now I'm working on the code that reads it if I change all the entries in the top row to megaman's, now whenever I move in this row it only selects him. if I move up from the row below it'll go to megaman even if I wasn't below him but I don't think changing this table will be a solution for restricting character selection, because any change here will affect both players

I've done enough on moving the cursor and the structure of the chr select screen, now it's time to look at input and selecting characters
dc/naomi uses 'maple' input system, will go to 0x005f6c00 for mvc2

after inspecting the PC which read this memory, I came across one which captures joystick input
when I moved the joystick I got the results I was expecting, 400, 1000, 2000, 800
and then from that watchpoint I was able to press button 1 and I got a new result, 220, which is button 1
that gave me new PC C02E054 (MAME) which in ghidra is 000E054

and now I'm going to see how this works and after that, I'm going to attempt my first mod

the two steps I have in mind are:
[mod1] when player selects a character, copy that character's ID to some free location in memory
[mod2] change the copy to add

the methods I am considering for restriction are as follows:

A) [prior to moving cursor onto a square, is destination ID's ratio value greater than player's remaining points? if so, skip to the next in the same fashion as if that character was already selected] this is related to the CURSOR MOVEMENT functions
B) [player's cursor is on a character, player presses button, check current cursor ID ratio vs player's remaining] this is related to the INPUT functions
C) [player's cursor is on a character, every frame check the current cursor ID ratio vs player's remaining] this is related to the VSYNC functions

bankbank wrote:
the methods I am considering for restriction are as follows:

A) [prior to moving cursor onto a square, is destination ID's ratio value greater than player's remaining points? if so, skip to the next in the same fashion as if that character was already selected] this is related to the CURSOR MOVEMENT functions
B) [player's cursor is on a character, player presses button, check current cursor ID ratio vs player's remaining] this is related to the INPUT functions
C) [player's cursor is on a character, every frame check the current cursor ID ratio vs player's remaining] this is related to the VSYNC functions

From a user perspective, if there was a way of showing that the characters weren't selectable, based on option A, it would give anyone playing a better idea of what was left for them rather than frustratingly trying to select chars that go above the ratio limit and the cursor jumping over them. In much the same way it puts a marker on chars that have been selected already.

Ideally you'd want to darken or grey out the options not available but I assume that's going to take a lot more work to alter the char pics, unless there's something in the code somewhere that brightness/colours/contrast/saturation etc could be changed. It's been so long since I've played this I' can't rem if the profiles are ever darkened/greyed at any point that you could use.

Best of luck with this as it's an intriguing project and I can't wait to see the end result.

first test mod done

this code runs every frame, might be related to vblank.

before: after: now I'm gonna try replacing those NOPs with some code

I found that in chr select, for each chr a player chooses, that ID gets saved in memory
c2d71e9 = 1st chr selected
c2d7d31 = 2nd chr selected
c2d8879 = 3rd chr selected

so ideally I will be copying the ID (well later the ratio related to that ID) when player presses a button to choose character. but I didn't find any empty space to change/inject code yet. so for now I'm gonna try to do a preliminary hack which will, on every frame, add the contents of these 3 addresses into some other address. so if someone selects Dhalsim 0x25, Juggernaut 0x29, and Jin 0x37, that address will total to 0x85 every frame.

edit:
I realized that NOP code was never getting run. just the rts.

fraggle200 wrote: Ideally you'd want to darken or grey out the options not available

probably wouldn't work because it's a selection screen for two players simultaneously, and each player has their own remaining number of points. if I darken a character's portrait because p1 doesn't have enough points, but p2 does have enough points for that character, that isn't really a good solution.

bankbank wrote:

fraggle200 wrote: Ideally you'd want to darken or grey out the options not available

probably wouldn't work because it's a selection screen for two players simultaneously, and each player has their own remaining number of points. if I darken a character's portrait because p1 doesn't have enough points, but p2 does have enough points for that character, that isn't really a good solution.

hadn't considered 2 players selecting at the same time. DOH!

after spending a lot of time trying to understand how the character select screen prevents the player's cursor from going onto a character which has already been selected by that player, I am moving on to the second method related to input functions.
it would've been really neat to have the cursor 'skip' past characters which were too expensive for a player, but it'll be so much easier to inject code into the 'choose with button press' code. I really tried!
a secondary reason why I am OK with leaving the 'skip' method behind is that it could have caused problems. for example, let's say a player only has 1 point left to spend. there could be a full row or column with characters that all cost more than 1 point. so what happens if the player's cursor gets onto that row or column? does it loop forever, locking the cursor? can they move off of it? would I need to reorder the characters into a checkerboard pattern based on their costs?