It fixes the Honda mathcup though (LOL)
From the looks of the akuma hack looks he just edited regular akuma to use the boss moves with a nice touch to load the palette from the opening.
I was talking about the FAB bug. Not the o gief reversal bug. Which only exists in the world version.
The FAB bug doesn’t really affect gameplay. And has that huge wtf moment which I love.
I assume you guys are referring to the fact that FAB won’t come out, even if properly executed?
I think he means the one bug where the first grab misses yet and the second one lands which makes it that the opponent could still move. Which was explained on this very page.
That portrait is so much better than both 3s and sf4 (in both cases he looks like a retard)
Yeah, I guess they didn’t want him to look like a boss anymore.
Nice! Is it possible to change Sarah in the system data to either Akuma or Gouki, then assign it to him?
<blockquote class=“Quote”>
<div class=“QuoteAuthor”><a href="/profile/3027/Jizzon">Jizzon</a> said:</div>
<div class=“QuoteText”>Nice! Is it possible to change Sarah in the system data to either Akuma or Gouki, then assign it to him?</div>
</blockquote>You’d have to draw a new graphic for that, the character name labels are really just graphics with no real “text” data behind them.
BTW: here’s that latest Shin Akuma patch: http://www1.axfc.net/uploader/so/3008824 Password is “neogeo” (needs to be put in the text field before pressing the grey button).
Wonder if there is a font that would look decent for that already in the game.
The 16x16 system font matches the lifebar names, so creating a new lifebar name should be easy. The larger, italic name labels for the select and VS screens would be a bit more difficult. You could cut and paste together letters out of the existing ones, but none of the other characters’ names start with “A”, so there’s no large “A” to start Akuma with. You’d have to try and draw a new one.
Yeah the 16x16 is good enough.
As for art.
I wonder when somebody will redraw the hud portraits to work with the character palettes.
Yes, the system font should do, but just for fun, going with cutting and pasting, you could opt for the Japanese Gouki. None of those letters are missing =).
I would imagine that would be very difficult if it were not an intended feature to begin with. You would either have to program in the palette key for each character OR redraw all the images… But then you would have to reprogram the game to select a different portrait for each palette
Not that it would be impossible though. The thing is both of those tasks would be very trivial if we had access to the source code (just cut and paste/modify/call the code in the character select screen). The problem lies in needing to reverse engineer the HUD and bytecode to make meaningful changes
Modifying existing values and references (what’s been done so far) is much more doable than creating and inserting new code.
It’s mainly a redraw and telling the game to read the same palette in the ram as the sprite nothing else which is what the Vampire and Alpha games did exactly.
Edit:
With out any editing on the 16x16.
Edit 2:
Not sure I said this before in detail may of alluded to it, but the small character select portraits are not the same portraits used for the hud. Character select mini portraits are 32x32 background layer graphics. As the Hud is a sprite reading standard 16x16 tiles.
Yeah,then that’s certainly doable. I didn’t know ST handled all artwork palettes that way or Maybe they DID intend to have that HUD swap then ditched it eventually.
So on that ROM where you got that screenshot, if you pick o ken then his hair turns red right? Because the screenshot alone doesn’t tell me much. I can only make assumptions. For all I know that could be a static image and his hair turns blue no matter what. Best would be a link to a ROM patch if you have it so I can patch myself and check how the game behaves
That was the main issue though, detecting and assigning the sprite colors was one thing I assumed would have to be reverse engineered then coded… But if the portion of the bytecode has already been identified/the work/code is already in the game (either due to ditched ideas or just system design that just caters to these changes well) and just not implemented than that’s a different story
You’re thinking way too hard about this.
Part of setting the graphics is to set which line in the palette ram to use. What I’m talking about will make it where there is no extra coding I just tell portrait on 1P to load the exact same palette as the sprite itself (Switching 0x07 to 0x01 for 2P 0x08 to 0x10 since this data is in the same palette bank).
The only hard part would be redrawing the portraits.
I already agreed with you and said it could be done (after seeing your screenshot). And it wouldn’t be too difficult.Afterward, I was just clarifying what I meant before and why i thought it would be difficult because it appears you misunderstood.
Which clearly you did because if you understood my intention the first time, you would have simply stated what parameters exist/are required to set graphics as you did just now.
Regardless, I still would like the ROM patch so I can mess with it a bit if you still have it.
I’m in the process of finding the data (again). Sorry, that I can’t keep notes.
Edit:
Found some old notes on my Google drive for the graphic ram for character select name. I found where the hidden tile map was again.
It’s only ram.
Hud 1P Character Portrait
0x910318
Edit2:
Player 1
0104DC: move.w #$1127, D1
Player 2
010508: move.w #$1108, D1
Switch 0x1127 to 0x1121 and 0x1108 to 0x1110. Now the portraits are loading the sprite palette.
Why not just use Gouki as the name. We have uppercase G, lowercase o, u, i, and k