News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Foffy

Pages: [1]
Most of Tenchu 2's cutscenes are in-engine, realtime scenes. The Japanese version took advantage of the letterbox design of these scenes to add subtitles there. My guess, and this is perhaps a highlight of my own ignorance, would be to find what that new code is in the JP version, transplant that into the US version, and then replace the Japanese text that appears within these scenes with the English dialog. Unless someone wanted to actually translate the Japanese version itself as a workaround but that turns it more into a full blown fan translation...for a game already translated. I don't think a niche series would warrant all of that work, sadly, as much as I dig stealth games like Tenchu.

CG scenes would be another matter, but there's not many of those. None of these scenes have subtitles in the Japanese version, so I would imagine the obstacle is the video format itself.

Odd request here, but would anybody be interested in hacking in subtitles to the English version of Tenchu 2 for the cutscenes? The Japanese version, released months after the English version, actually features subtitles. Always found it odd that the first Tenchu had subtitles but the second game doesn't.

I'm just gonna shoot for the moon here, but it's something I've been thinking a lot since bsnes incorporated a widescreen mode for SNES games. Could something similar be done to the GBA?

1. Custom GBE+ build with increased resolution (not a romhack per se, but definitely step one)

Some time ago, a /r/emulation thread discussed the idea of increasing the resolution of GBA games horizontally.

Shonumi, a GBA+ dev, entertained the idea and shared a few screenshots of his experiment.

Later in the comments, he pointed out exactly which parameters must be modified on source code to increase display area.

Most likely, games would need to be heavily modified to take advantage of this.

2. Increased resolution hacks of GBA games.

Now, if theorically there was a build of GBE+ (or any other emulator) that allowed for increased resolution, how far could romhacks push it?

I'm thinking mainly for action platformers (Kirby, Metroid, Mega Man Zero). Could they be pushed to 320x240, as if they were released for a home console? That would possibly spark interest in romhacks with UI redesigns, complete expansion of map designs, and enemy placements (and attack patterns) to correctly fit the new resolution. Would it be possible to bring SNES to GBA ports back to their original resolution? (Probably more trouble than porting GBA content/relocalization to the SNES originals, I'm thinking theorically).

I was very disappointed when the NDS Mega Man Zero Collection didn't use the increased resolution at all. Now even more so with the ZX/Zero Collection. I would definitely be on board to at least try giving the Mega Man Zero series some attention.

Sorry if this is a "bump" to this idea, but I gotta say it's very amusing to me to ask for something like this using the same examples being brought up in this post. I hope in the future the community considers tackling stuff like this.

As said in my earlier post (which was like two or so posts before the one I'm quoting here :p), I think the best place to start is the SNES-to-GBA ports. Some GBA games might render enemies in the area, which I believe Kirby does, so you don't get many issues. But that's just Kirby; that's not an assured way to develop all games for the platform, so there's no assurance, for example, that any of the Castlevania games or some other title follow the same approach. But I believe all of the ported games from the SNES handle things very similarly to the SNES versions besides resolution, so those games would far and away be the easiest the mess around with. I've shared examples in a previous post to how it's mostly possible for the core gameplay as long as it's not using any GBA specific features, with the most frequent issue being texture size and overlap when expanding the resolution, which is where the need for a hack to come in.

I've never heard anything of the sort ever suggested. I guess it makes sense the GBA could draw resolutions bigger than its LCD physically allows.

Hacks that won't work on original hardware tend to be frowned upon, but this is a revolution. It opens the door for OVERWHELMINGLY improving games constrained by the screen size.

There appears to be limitations, but I imagine the hacking scene could probably figure this out on a game-by-game basis. Any game that uses GBA custom effects, for example is hard-coded to the default display. That's why in my original post, there's garbage effects in the opening screenshot to SMB2. It's something you'd have to take with the effort, like how widescreen patches might have T-Pose characters in the corners of the screen, or how widescreen Mode 7 games don't render many assets outside of the default SNES resolution space.

I think the SNES-to-GBA ports could be a good start at exploring this concept, as we know that these games at one point did display more than they presently do due to them being on systems with a larger display resolution than the GBA. In fact, the biggest issue with such ports are the loss of vertical space, and in the linked example in this post, one can see that it can be worked around.

This is also possible for GB and GBC games, but that's a game-by-game basis as well. I cited specific GBA games because we have a foundation or target to aim for more specifically than "expand the screen space" because we can actually compare the versions and see what visual real estate was cut. Other games might be able to be expanded by 16 pixels in terms of real estate (which is a decent bit for handheld games like this) and others might benefit less so. I think Shantae's example of it failing really shows the potential in having more space to work with, in terms of potential.

I think it's something worth entertaining, and something seriously worth looking into for the GBA ports. Right now the weakest thing about the Super Mario Advance ports is the real estate of the screen, and it appears something can be done about that.

Here's a difficult one I'm unsure if it's ever been asked before, that requires some explanation. Over the years, the rom hacking community has done a great deal at restoring SNES-to-GBA ports with changes making them more similar to the SNES originals. Most notably this has been found in color restoration and voice removal patches, such is the case for the Super Mario Advance games. With all of that said, has the community ever tried to hack the resolution of these games?

I've been having a small conversation with Shomuni, developer of the GBE+ emulator, after being inspired by some of his earlier posts on Reddit regarding resolution hacks for GBA and GB/GBC games that he showed possible in that emulator. I asked him about the Super Mario Advance games and the likelihood of them matching the SNES resolution, and he documented his results for the SMB2 and SMB3 ports. What's interesting is what the issue is with SMB3: it doesn't take into account the extra vertical resolution being added to the game, and for this reason it leaves all of the space below Mario to be empty. Taking into account the possibility of a larger screen resolution to work with, how difficult would it be to alter the game to account for this? I would imagine you would have to force the display of the game upwards the X amount of new vertical space produced, but I'm a complete fool with this stuff, so I'm probably wrong about that.

Same here, that was the thing I did not like about HSF2, the AI is way too cheap.

I wish there's a way to give the AI the same behavior the other console ports of SSF2T have, where you can actually beat the game without any problems.

Because I remember in the Saturn & GBA ports, the AI was a lot easier than its arcade counterpart.

I think the difficulty in HSFII is based on the arcade version of Super Turbo, which is infamous for being one of the hardest Street Fighter games even on the easiest setting. "Arcade perfect" games of that era usually kept the infamous button reading AI, as the games were designed to get money from you. If you were compromised in the home experience in terms of visuals, sounds, loading times and the like, they likely also altered the AI to compensate the downgrade.

Consider this a very stupid idea, but it's one that always bugged me and if I had the knowhow, I would have done something about it myself. Maybe someone here also found this stuff to be a bother but has the knowhow to do something about it.

In games like Hyper Street Fighter II in the PS2 version of the Street Fighter Anniversary Collection (that's a mouthful!!), the default colors of the character are actually not something you can select when playing the Super Turbo versions of the characters, which are the most recent versions you can select in the game. You couldn't do this in the original version of the game, either. Is there a way to force the default colors via a hack? What makes Hyper Street Fighter II so interesting is you can select any version of SFII at the character select screen. This means that the colors are actually available in the game, but you can only select the characters default colors if you select a non-Super Turbo version of them. This also means that version is from an older edition of the game. For example, if you want Ken to wear his red attire properly, you cannot pick the Super Turbo version, but have to pick the Super version if you want the most recent version of him that allows this, but this also means you lose balance changes and the super meter, including some of the balances Hyper SFII adds to Super Turbo. How difficult would it be to alter in the default colors for Light Punch from Super Turbo so it picks the Light Punch colors from the other versions, seeing as they consist of the same roster? The AI defaults to picking Light Punch attires so this would fix their color discrepancies as well.

Something similar happens with Street Fighter Alpha 3 (I'm using Alpha 3 Max for PSP for reference, but this is true for all versions IIRC). The default character colors are available, but that is dependant upon if they select a specific ism in regards to the AI. If it's not A/Z-ism, the opponent AI will be a non-default color. Default colors are Medium Punch, which the AI only selects via the A/Z-ism. If picking X-ism, they pick the Light Punch color, and if the V-ism, they choose the Heavy Punch color. I would prefer if it always defaulted to the Medium Punch color for the AI, though I'm not sure if this would be easier or harder work to do compared to the Hyper SFII example I shared.

I know this is incredibly dumb to be bothered about, but it always stood out to me as odd. We've seen color restorations for the GBA version of Super Turbo, but we've never seen such a restoration for the arcade perfect ports. I don't even think the 30th Anniversary Collection fixes this.

Kinda gonna put my Mario recolor hack idea to the side learning that at least two Koopalings share the same shell sprite in I believe both Mario games they're featured in when in current artwork they're different colors. I wouldn't even know where to begin with that and it probably is too much work for something you encounter for such a short amount of time.

However, something you do encounter for a long period of time exists in Castlevania: Harmony of Dissonance and I find quite annoying. The aftereffects when you jump, slide, and dash. There's already a hack available on the site already that gets rid of the dumb outline, but no hack to get rid of the effects. I always thought the effect was there for Alucard because he's a vampire, and I know they were totally trying to cash in on that character with Juste, but as a Belmont it seems like a really strange aesthetic decision. It's probably also there to help guide players as it was made before GBAs had backlights, so something cluttering the screen would be more likely to catch your eye, but it's just appalling to look at now. You end up defining Juste's movements by the afterimages and less so his actual animations and sprites, or at least that's what I've done.

This one should be easier than sprite editing and recoloring I'd imagine, as apparently in the game you can change the colors of these afterimages depending on the equipment you have on; for example, a piece of green clothing could make it a bright green effect instead of a blue one. Could this be as simple as disabling the function associated with that? I suppose the difficulty would be finding where and how the game looks for this and just preventing it from triggering it.

I suppose my idea is also a request for help in the possible chance it's not hard to learn the skills. My general question is how easy would it be to edit GBA sprites? From what I understand, color palettes for NES and SNES games played a role in what sprites were colored as, and the two games I was interested in dabbling with are both SNES ports/remakes/updates, them being SMB3 and SMW. More specifically, I was interested in recoloring the Koopalings to better match their artwork, as I believe they just used colors they had in the SNES version of SMW with zero consideration for the artwork of said characters, and the SNES version of SMB3 just seems to have visual oversights all over the place. I was curious as to how simple or complicated this can be, seeing as I'm largely interested in recolors with the potential of maybe using more fitting sprites made in that style.

The iQue DS was a little earlier, but has only about 5 translated games.
And the lockout is so feeble that patching the ROMs takes literally one byte.

I never knew there was an iQue based on the DS line. I only knew that they pushed region-locking pretty hard on handhelds with the DSi and later 3DS with really poor campaigning about how it's "good" regions get exclusive games. And this was at a time when Nintendo of America was skipping first-party releases for Wii, already in English; Operation Rainfall spawned from this type of thinking.

I'd say it would be about as easy and as much work as just properly emulating the actual peripheral. It shouldn't be that complicated for anyone with some experience working on emulating peripherals.

This game and peripheral would work on a western DS too right? IIRC the system is region free. It might be worth importing. Then I could take a look at the emulation as well. If it's not too much work I might even consider translating it.

I believe this would be a region free title, as it was made before the release of the DSi, which was Nintendo's go at region locking their handhelds.

This idea/request is probably very technical, and I imagine for a game probably known most through Super Smash Bros, it's probably niche in general.

I was curious if a hack could be done to the game Slide Adventure MAGKID for the Nintendo DS. The hack would be more to actually make it playable. What do I mean by that?

For those unaware, Slide Adventure MAGKID was a Nintendo DS game that required the use of the DS's second cart slot, as you were required to put in a peripheral for an optical mouse in order to play the game. This device allowed the system to act as an actual mouse like the one you use on PCs, and this was used to navigate the magnetic character around the screen. For an example of how the game works, here's a video.

Now, in the current environment, this produces a few problems. First, if you ever wanted to play this game, you're stuck on pre-DSi hardware, so we're talking decade old machines are the only way to play this. Second, as this peripheral was used for one game - this one - there's been little to no interest in actually emulating this device for any DS emulator, which means this has also closed off the window of even being fan translated; after all, if the game won't even boot without the device, how can you put it into another language.

So, my question was more an inquiry into something perhaps a bit deep and complicated. First, how difficult would it be to bypass the peripheral check? Starting the game without the optical mouse doesn't even let you see a title screen. Second, how difficult would it be to remap the input from the optical device to something like the d-pad or touch screen? There have been a few DS games that got hacks to remove the touch screen controls to other means, and I would imagine if the games check could be circumvented, and something like this introduced, you can essentially get a game that's unplayable today for most people and have it be playable, and potentially have that be a start for potential fan translations down the road. It seems a lot of these Japan-only games that have winks and nods in Smash seem to be of interest to people, enough so that they eventually get hacked and translated by fans, and I would imagine the fact the game checks for a peripheral and only works on 10+-year-old handhelds is enough to stop any momentum or interest dead in the water.

Personal Projects / Re: Castlevania 3 - Linear Version
« on: November 13, 2018, 09:35:50 pm »
This sounds so cool but I am presently unable to give it a full run through right now, but what is the level layout then? I presumed Sypha's and Alucard's paths both happen at the same "time" in the game.

This is the *only* important part in ROM hacking: finding what byte(s) you need to modify. Using a hex editor is exactly the same as using a text editor like notepad. I imagine what you want will probably just take modifying one or two bytes in the whole ISO.

So, how would I try to find it:
0. Start the game in Original Mode.
1. Find the X position of the main character.
    1.1. Open BizHawk's "Tools"->"Ram Search".
    1.2. Move character a bit to the right, search "Greater Than" "Previous Value".
    1.3. Move character to the left, search "Less Than" "Previous Value".
    1.4. Stand still, search "Equal To" "Previous Value".
    1.5. Repeat until you're only left with the real X-position's address in the result list.
2. Use an emulator with a debugger: pSX, MAME, no$psx, one of the PCSX mods, Mednafen, etc. (I prefer MAME.)
3. Set a memory write breakpoint at the X-position's RAM address and stand still.
4. Wait until an enemy hits you. If there's an horizontal knockback, it will write a new X position to our RAM address we found and it will trigger the breakpoint.
5. Take a note of the pc (Program Counter) in the debugger. Or even the ra (Return Address) to see what called the current routine.
6. Open IDA Pro and open the game's executable file. Go to the position(s) you took note of in step 5.
7. Repeat all steps from point 1, now in Arrange mode (maybe finding X *and* Y position now, to make sure we trigger the breakpoint when we're hit.)
8. Find the difference between modes in step 6.
9. Figure out what needs to be changed in the code and insert it with ARMIPS.

You will need to know some basic MIPS assembly, of course. Just keep this document open while you read the ASM code:

If you intend to keep working on this, I have an ultra secret Discord server dedicated to PSX hacking (and translating) where I could help you in real time with more details. Let me know if you're interested and I'll send you the invite link.

I am most definitely interested in this, but I should disclose I am very unfamiliar with MIPS and hacking in general. I am not a programmer outside of some Java learning from a decade ago! :P

I'm actually super compelled to explore my idea further, but as I lack the hacking skills, perhaps looking into hex editing might help me along.

The problem there, of course, is if I use a hex editor like Cheat Engine, for example, how in the world do I narrow that down to code that involves the specific area of damage taken and in-game knockback? It would be easier to probably figure out the in-game timer and health, but I think looking for knockback values might be quite hard to do. My guess was to find the values in Original Mode, then just force them in Arrange Mode, but this is presuming that the vertical code is the same to help "porting" the horizontal value is as simple as adding that to Arrange Mode.

All this depends on even finding the values of knockback, and I wouldn't know where to begin looking for that. :P

I don't know that I would attempt to have the game use the other function as much as find the behaviour for hit (which you said already includes some animation) and adding a few pixels of horizontal movement, possibly accounting for direction of attack (or maybe just using facing direction) and possibly trying to handle clipping issues.

If I didn't make it clear, as the bolded gives me the impression, in Arrange Mode you basically get the knockback animation but it's only vertical, not horizontal. You essentially hop in place. I'm actually not sure how Castlevania knockback works in detail, under the hood - I think you just get launched back from the direction where the attack is coming from - but being able to see how it works in Original Mode would give me the idea that perhaps they disabled the horizontal response in Arrange Mode, meaning the most "authentic" result would be to patch that back in without guesswork.

If I can give an example of the difference between the two modes, here's knockback in Arrange Mode, and then here it is in Original Mode. As you can hopefully see, the removal of horizontal knockback not only looks weird but does completely change game balance, as a great deal of pitfalls and platforning are challenging precisely because of the knockback.

Hi all, my request might seem silly, but I imagine it's not nearly as ambitious as others, so perhaps I can share it here for ideas.

So, I was thinking of a hack for Castlevania Chronicles, particularly the Arrange Mode. For people unaware, Arrange Mode is essentially a revised edition of Original Mode included in the game, which is itself the original version of Akumajo Dracula X86000. Unique to Arrange Mode are new sprites, new effects, new music, a more balanced difficulty in regards to enemy damage, and faster screen scrolling.

However - and this is where my want for a hack comes into play - Arrange Mode actually disables a Castlevania staple: knockback. Any attack you take just gives you this weird hopping in place animation, like Simon stubs his foot. There is no way to enable this mechanic back in Arrange Mode normally; you have to play Original Mode for this, but this means you lose the new (and the ones I personally prefer) Simon and Dracula sprites, the new music, the better balanced difficulty, the works. I was interested in perhaps a hack that enables the knockback from Original Mode while playing Arrange Mode, or at the very least, maybe hacking in the Arrange Mode sprites into Original Mode if that somehow was too technically complex to address.

Should this be perhaps an easy task to hack in? The feature is already in the game, but disabled in one of the modes. I would hope if there's hacks of the NES games adding air control with jumps that at the very least we can see someone add back a Castlevania feature back in one of the modes to Chronicles. :P

It might be wrong of me to ask, but are the Blood of Bahamut, Ace Attorney Investigations 2, Archaic Sealed Heat, or SaGa 3 translations notable for DS? Almost all of those seem to be moving at a good clip, unless you count ASH. That project's technically been "done" since September of last year according to the girl in charge of the project, but there's rumors that the she gave up despite the game being fully translated almost two years ago. From a leaked beta of the translation to the angry community about lack of updates over at GBATemp, many assume there that she just said "fuck it" after a while.

It's a shame too, because that game seems cursed. Nintendo of America's trend of skipping RPGs this generation (infamously peaking very recently with the Xenoblade/Last Story/Pandora's Tower situation that just happened) actually started with ASH. NoA was working on a version for North America, as the game was far along to be rated by the ESRB (the game would never be released in North America), and then there was the whole debacle with the fan project.

I think Crimson Nocturnal stopped their SaGa 3 project for the same reasons regarding the community, so the one I'm referring to is the more recent project.

Pages: [1]