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 - nintendo_nerd85

Pages: [1] 2 3 4
That's why the hack page specifies the "File/ROM SHA-1" and the "File/ROM CRC32".  If your ROM is zipped, then your unzipping program should be able to display the CRC32 of each file in the zip.  (SHA-1 generally has to be calculated with a separate program.)  If your CRC32 does not match what is on the page, then you have the wrong ROM and should look for a different one.

Yeah, okay, that was my bad, the ROM dump I have doesn't match the correct CRC32, SHA-1, etc and I'll need to figure out where to go from here. Sorry about that.

So, I wanted to try this ROM hack out for Ocarina of Time (version 1.0 USA) and I've had bad luck patching the BPS patches for it

Link here to said hack:

Well, I tried Beat and Floating IPS, nothing, both spew the message "this patch is not intended for this ROM". Why the read me doesn't mention what file to use, is beyond me. Are there utilities that actually patch N64 ROMs or am I out of luck?  :huh:

ROM Hacking Discussion / Re: Sparkster Snes
« on: January 21, 2020, 10:13:27 pm »
As someone who rented this game growing up, thank you! This boss was an absolute nightmare to fight, but this ROM hack makes it actually possible to beat  :thumbsup:

The chances of this happening seems really low, why was mz targeted? Doesn't seem random at all. It sucks it got put out there like that, but once people start playing it they'll realize how badly tuned it is for right now.

Being a bit negative, aren't we?

It is my private translation that was stolen and distributed without my permission. No one should owe you any kind of explanation...

In any case, it is not finished. It's extremely buggy and with an extremely shitty text.

If a moron wants to upload it to a shitty website for other morons to suffer it, it's up to them. RHDN seems to be a more decent place than those other websites you visit.

Oy vey, no need to make a federal case out of it. Nor is it necessary to be so condescending about it. I suppose it's true, no one and I mean no one, should ever be trusted. Take my word for it, always be cynical towards everyone you meet, never trust anyone, sound good?  :huh:  :-X

Yeah, I get it, it sucks to have things leak, but what's done is done. Unless you want people to invent a time machine and go back and un-leak what's been leaked. That'll work I'm sure.

Considering there are a ton of unfinished, incomplete, barely functional and even broken hacks/translation already on the site and still here, I doubt it was removed for this reason.

EDIT: Guess it's this?

shortcuts: hit alt+s to submit/post or alt+p to preview

Who knows? Either way, people are saying it's not 100%, no one has properly explained anything really

It may have been an unintentional mishap. Looks like both Itadaki Street and Star Ocean: Blue Sphere share the same page and ID # (5337)


Some allege it was due to the ROM hack not being complete, but it was removed without reason and I don't think it's a very judicious decision IMO. Indeed it's baffling.

Was that necessary? A game that's been in Japanese for so long and then gets removed from the site? Seems like kind of a stupid move, no?
Thankfully someone had the decency to upload it to his Google Drive, but come on, I thought this site was more open to major news like
the translation of an obscure game.

Maybe I'm a complete derp, but I can't seem to get the BPS patch to work in Snes9x 1.60 at all. When I use Lunar IPS (Floating IPS version), it says "this is not designed for this ROM".  Using the FF3(U][!]USA.SFC ROM and no avail.

I recall at the time bsnes was the most accurate emulator, though I can't even remember which version it was I had used to test. I do recall at the least bsnes had vblank limitations enforced. That was like byuu's #1 complaint against existing emulators to begin writing his own.
I do know that it was at the time people when 3Ghz was considered asking a lot.
That was like 2008-2009. So bsnes was like in like 03x-04x versions.

I can't recall if it was before or after I tested Emerald Dragon, but it was pretty close. I remember it seemed bsnes was about the only emulator to run THAT game correctly. SNES9x had spotty SPC emulation which caused crashes on some versions, and I recall that was one of the games where you could HEAR the audio-barf in ZSNES' sound emulation. :P
Zsnes absolute embodiment of ear rape, I don't know how anyone can use that and endure the horrid S-SMP emulation  :huh:  That said, Higan Accuracy (which runs like molasses on my Haswell Core i7 4470, *sigh*), and the Super NT got 100% identical results with the HUD issue. Like what was said, it's not detrimental to the display, but it's definitely odd, and something that will never be fixed. Short of using Snes9x 1.56, which doesn't exhibit it, yeah, *shrug*. I'll deal with it, I'll take hardware emulation over software emulation any day of the week.

Speaking of Snes9x, as of version 1.53, it's been using the same cycle-accurate S-SMP core as Higan.

What happens in those places anyway?

Just a few anomalies, but the game is completely playable from beginning to end regardless. ROM hack wasn't designed with real hardware in mind, unfortunately, most ROM hacks relied on inaccurate emulators a while back.

Your display isn't at any risk from flickering. You can play without any worries, though may want to just play on Snes9x so as to be less distracted.

Burn-in is caused by something staying on screen for a very long time, unchanging, and doesn't afflict LEDs as easily as it afflicted CRTs besides.

I mean, I can ignore it for the most part, I prefer the somewhat higher accuracy of hardware emulation than software emulation, it feels more authentic to me, using an 8bitdo controller versus an Xbox 360 pad, but that's just me. Apparently people report that issue being on a real Snes, so until the author can be contacted, not much can be done.

My apologies for bothering you guys with a trivial quirk -_-, but thank you for the reassurance.

You will find a number of visual oddities during your playthru. This translation was developed before high-accuracy became a thing. You'll see them in the Witch's Tower, Eva's Grand Church, and a few others.

Are these anomalies detrimental or bound to cause any damage to displays being used? I currently use an HP Omen 25" LED screen to play this on, will that flickering/line issue be any cause for concern? I don't want there to be any dead pixels or burn-in, mostly. Is there nothing I can do other than trying to get a hold of the translation team behind the ROM hack? What's weird is that Snes9x 1.55, despite being only second to Higan in accuracy, doesn't exhibit the HUD glitch. I want to be sure before I attempt to run it.

I was afraid of that, ugh.

This is a rather strange glitch that I've encountered in the following ROM hack, located here:

Specifically, the ROM hack from Ryusui's re-translation hack, has an odd behavior with the top-most line in the battle HUD. What's odd is I'm getting various results in how it's displayed. On the top of the HUD, it's showing about 1/4 of a black line flickering at the edge, tested on Higan Accuracy and a Super NT. But on Snes9x 1.55.2, the issue is nonexistent, and there's no black line or flickering of the edge of said line.

Snes9x 1.55.2 - no black line on battle HUD

Higan Accuracy - black line on 1/4 of battle HUD, flickering

Super NT/SD2SNES  - black line on 1/4 of battle HUD, flickering

As you can see, Higan and the Super NT have the exact same results with the black line anomaly.

I'm running it on a Super NT, which uses FPGA hardware simulation and not emulation, so emulation should be pretty indistinguishable to a 2/1/3 2-chip model SNES, running of the latest SD2SNES revision and firmware. What I was informed on the Krikzz forums is that this is "normal SNES behavior" and would require someone, notably the author, to debug this particular HUD issue. My question is, if the real hardware does it, and cycle-accurate emulators do it, what options are there more that one can look into?

Thank you for your time, I certainly hope I'm not wasting anyone's.

This post is more MSU-1 Focused this time:

Dragon Quest I-III (I've mentioned these games before)

Breath of Fire I & II
There has been people on youtube have done almost all of the tracks.

Shin Megami Tensei I-II & Kyuuyaku Megami Tensei
There is remixes out there for these tracks, but issue is tracking them down now for some of the remixes.

Super Castlevania IV
I would think this one would be simple to do considering it's a not RPG, and most of the tracks presented have been already remixed.

Final Fantasy Mystic Quest
The tracks have all been remixed.

There is a few Japanese Exclusive Games (which I can't remember right now) also had their soundtracks remixed, but if anyone can remember what those were then I think those games would be good for future MSU-1 Projects.

As a side-note I think it would be practical somebody provided a youtube tutorial for MSU-1 hacking in general because it would be more helpful than just documentation.

Earthworm Jim 1 and 2 would benefit greatly from this, too bad MSU-1 documentation's a joke.

Yeah, I don't see a dash/fast-walk hack happening in Breath of Fire ever.

I love Breath of Fire on the Snes, it has a special place in my heart and I love the story and far superior translation to the second game (barring the re-translation). But the only thing that absolutely kills it, is the lack of a faster walking speed. The GBA port has the dash feature, sure, but the GBA port has very weak audio and without the color hack, washed out colors. I tried looking for the offsets that control Ryu's walking speed, but to no avail. Where would I even look to change walk to dash? Is it even feasible for this to be achieved? Any help is appreciated. I don't know ASM or even C at all.  :(

ROM Hacking Discussion / Re: Breath of Fire - Faster walking
« on: September 01, 2017, 07:08:36 pm »
First step is if there is a feature (some games include it as an equipable item or something). If so there is likely a flag or value to allow it and you can use that. I see there is a monster avoidance so you would do something like this if you wanted a no encounters cheat. That said it appears it was a feature added to the GBA and is not there on the SNES in any capacity.

After that yeah it is hacking time. A simple twice as fast thing should be well within the realm of possibility, the times it gets tricky are when you want to move hundreds of times faster on older games (a modern PC game will probably assign a floating variable or something and that allows that, multiply SNES 16 bit fixed length values by hundreds and you can come unstuck).
The actual speedup can be similar to speeding up games mods but the general idea is movement is animation, speed up the animations (or get it to reach its end points faster) and you speed up the game.
I will start by watching some gameplay, may my ears forgive me
In this case it is a one square per press type thing as opposed to a move anywhere in micro steps affair which could be important. There also appear to be a whole bunch of animation frames that play during that.
Even though the SNES speed is paltry compared to the things of today it still operates at 60fps which is faster than humans can interpret quickly so there will be certain timers to say wait ? frames and then swap in the walk* sprite and move a couple of pixels in the relevant direction, repeat for all sprites until finished moving said square. The GBA version appears to have something like this.

This will be an assembly hack, however it should be an in place one for the most part if you can find the values it has to wait for (or convince it to add 2 to the counter for every period it waits rather than 1) without any radical retooling.

Doing that will have an always on effect, however it would not be the hardest to add a check for a button press and then make an if pressed then double speed type setup.

Assembly hack? Damn, I was afraid of that. I mean, the GBA and Snes have a lot of similarities hardware-wise and implemented a dash feature. Breath of Fire 2 re-translated did the same thing by holding the B button, and I erroneously assumed the same could be done with this. But given that I have absolutely zero programming knowledge or skills under my belt, it will be literally years before I even begin to understand how to implement this dash feature. So yes, it would be prudent of me to either pay someone who would be willing to modify whatever values determine his walk speed, or I simply pack up and go home and give up on this. I don't know what I got myself into, but clearly, this is far beyond anything I am capable of doing, and even were I to learn ASM, by the time I learn how the Snes works, I will have moved on. I feel like such a fool for even asking about this.  :'(

ROM Hacking Discussion / Breath of Fire - Faster walking
« on: September 01, 2017, 04:03:10 pm »
I love this game, it has a special place in my heart and I love the story and far superior translation to the second game (barring the re-translation). But the only thing that absolutely kills it, is the lack of a faster walking speed. The GBA port has the dash feature, sure, but the GBA port has very weak audio and without the color hack, washed out colors. I tried looking for the offsets that control Ryu's walking speed, but to no avail. Where would I even look to change walk to dash? Is it even feasible for this to be achieved? Any help is appreciated. Please, and thank you  :D

Personal Projects / Re: Snes9x MSU-1 Support
« on: November 18, 2016, 08:45:37 pm »
you are being a jerk, please stop it. Wii makes more sense right now given the stability, it is simple common sense

*Sigh* I don't feel so well...

Let's agree to disagree.

Pages: [1] 2 3 4