11 March 2016 - Forum Rules

Main Menu

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.

Show posts Menu

Messages - DocStrangelove

Gaming Discussion / Re: The Game Music Thread
July 21, 2021, 10:57:15 PM
Journey to Silius (NES). It never ceases to amaze me, it feels like the NES has no business sounding this good without extra sound chips. But this is what it can do in expert hands.

What I meant is, let's look at the progression:

   A  B  C# B  A     G# A  B  A  G#    F# G# A  G# F#    F  F# G# F# F
   F# G# A  G# F#    E  F# G# F# E     D  E  F# E  D     C# D#D  C#
F#--------------- E---------------- D---------------- C#---------------

I put the part in bold, in the last section the middle voice uses D# (the major second of the C# major scale, as expected) when moving up but D (minor second) when moving down. When the "synth line" kicks in, this quirk disappears because this voice is now used for the synth line.
Quote from: PresidentLeever on December 12, 2020, 05:46:10 AM
Interesting, any particular Depeche Mode song?
No particular song, just the feel, the mood of it. If DM played it on a gig (with their instruments and vocals of course) it wouldn't feel out of place at all in my opinion. But that may be just me. It's one of the few game soundtracks that I just couldn't stop listening to after looking it up on Youtube, resonates really well with me.


Yes MM1 is a bit more serious and less cartoony at times in comparison to later games, I can see that. But as you say it also feels like a result of the aesthetics not being fully developed yet.
I just read an Inafune interview from 2005 about Mega Man Powered Up!, that PSP MM1 remake with the chibi style. My initial reaction to that was "omg what did they do to my Mega Man" but Inafune said that was what he actually wanted the original game to look like. It just looked the way it did because he didn't have the hardware to realise his vision. So I guess MM1 feeling somewhat more serious was completely unintended.
About Mega Man 1 Wily 1...

I get a strong Depeche Mode vibe from this one. The chord progression is textbook flamenco, but that is as ubiquitous in modern music as the blues pattern, so it hardly deserves mention. The reason why I mention it anyway is the lovely little detail that the melody on top uses the major second when moving up, but the minor second when moving down again, which gives it just that little bit of extra flamenco touch in my opinion.

As for best music, this is actually my favourite track in the entire Mega Man series, narrowly beating even MM2 Wily 1. It's even my favourite NES tune. One thing that makes MM1 special to me is that it can be almost gloomy at times, in contrast to the more upbeat/colourful nature of all later games. Those were filled with cutesy animal robots while the sparsely populated/more robotic MM1 could feel somewhat lonely and isolated. Now of course you might think why in the world that would be a good thing, or if that was even intended or just a side effect of its relatively unpolished nature.

But still it gives me a mood that none of the later games has, and the bitter-sweet-sad Wily 1 theme absolutely nails that feeling for me.
Phew, that's a long story and I haven't made notes so I forgot some of it.

I was using FCEUX. I was running the hex editor while playing to find patterns. Some memory adresses there were easy enough to spot (e.g. $0030 seems to be 0 when walking/standing, 1 when jumping/falling, 2 when hovering. $0328 and $033C are your X position, so e.g. absolute position 255 would be 255 at $0328 and 0 at $033C, while adding one to that (256) would be 0 at $0328 and 1 at $033C. This coordinate would be pretty easy to spot in the code in many situations.

While moving around, one address in particular seemed suspicious. $0314 only changes when moving left/right while jumping/falling. It is static when on the ground, static when hovering, static when jumping straight up/falling straight down. It was only changing when you were moving left/right in jump mode. It was increased by $C0(192) per frame when moving right and decreased by the same amount when moving left. This resulted in a pattern of four values $00, $40, $80, $C0 (0, 64, 128, 192) rapidly cycling on a per-frame basis.

I had a feeling I was on to something here and I had a theory: what if the carry flag from the +192 decided if you moved forward or not? Like, in 8-bit logic:

0 + 192 = 192 -- carry flag = 0
192 + 192 = 128 -- carry flag = 1
128 + 192 = 64 -- carry flag = 1
64 + 192 = 0 -- carry flag = 1

I had an idea that maybe the game decides if you move a pixel or not is decided by the carry flag from this operation. Move only when carry flag is set would mean 75% speed, which is exactly what you get in the game.

I set a cheat code to lock it to 0, and as expected, 0+192 would never set the carry flag, and I couldn't move right anymore during jump. Locking it to 192 meant subtracting 192 would never set the carry flag, so I couldn't move left anymore during jump. Locking it to 128 meant the carry flag would always be set either way, and indeed I got full 100% horizontal speed. It seemed to work.

Sadly, this messed up a few other things, like moving platforms. They also move at 75% speed, but locking the RAM value forced Firebrand to move at full speed instead of 75%, so he'd fall off the edge. It also messed with the pushback from the Blower boss. I realised that the end result stored at $0314 was a sum of several independent operations, and locking it would really mess with those.

So I started digging into the code via FCEUX's debugging disassembly. I understood a little of it thanks to my previous humble forays into x86 assembly, but was completely lost most of the time. With the help of this friggin amazing interactive 6502 tutorial: I understood more.

In the end, I don't really remember how, I found that the game's jumping subroutine stores $C0(192) at $038C before that value is added to/subtracted from $0314. Locking this value via cheat code again didn't do any good either, but tbh I don't remember how exactly. However, changing this particular instruction in the ROM (changing the value to be added/subtracted) to value $FF so that it would set the carry flag in 255 of 256 frames did the trick. No issues with platforms or Blower. That's how I got here.

December 11, 2020, 06:51:43 PM - (Auto Merged - Double Posts are not allowed before 7 days.)

Uploaded it to RHDN, here's the link if anyone's interested:
Thanks everyone, yeah I also noticed somebody already uploaded no-skid hacks for Mega Man 1/2 which I was planning to look into next, so it seems cool.

I'll submit it, but after I did more QC testing with other emulators and different region ROMs.
Hey everyone, I'm seeking advice about if a super-simple hack is RHDN material or not. I'll have to elaborate a little to clarify.

So I'm new to all this and this is my first "ROM hack". Gargoyle's Quest 2 (NES) jumping physics always bugged me. Walking and hovering has 100% horizontal speed (1 pixel per frame) but while jumping/falling that is reduced to 75%. That makes it feel sluggish and kind of punishes jumping. No other game in the series does that, including GQ2's Game Boy port, making that one actually the fastest-paced game in the series while the NES original is the slowest. It causes some unnecessary frustration like in that infamous long flight over the river of fire, which is not an issue in its GQ1 or even GQ2(GB) equivalents, which made me wonder if that stage was originally designed without the slowdown in mind. It's the prime issue that makes GQ2(NES) feel less satisfying in my opinion.

So I dug into GQ2's code to remove that and make it feel more like the other games, and I found a very simple solution. At one point, there's an LDA instruction whose value kind of determines the speed percentage when in jump/fall mode. Changing LDA #$C0 (192/256 = 75%) to LDA #$FF (255/256 is virtually 100%) does the trick and I've playtested two full playthroughs with and without overclocking using the Mesen core in RetroArch. I've tried finding more elaborate solutions but found it very difficult to keep track of what's going on through all the sub-sub- and sub-sub-sub-routines, and of how the game exactly uses the carry flag for multiple operations at a time. Changing that one value seems safe and does what it's supposed to perfectly fine.

Now what I'm struggling with is if this is the kind of "hack" that's supposed to be on RHDN. I thought it'd be a shame not to share this but I'm not sure RHDN is the right place, in the sense that it seems to be a place for far more sophisticated hacks. I've read the guidelines and I believe it's in a grey area. I'd hate to submit something that the site isn't meant for.

Like, on the one hand you could say "it fixes the sluggishness, it's a more fluid experience now, a genuine gameplay improvement, and if changing a single byte does the job, then why not?"

On the other hand you could say "this is too crude for the quality standards here" or "it just changes one value to FF and it makes the game easier, it's just a cheat code!" (note: I did try to solve this via cheat/Game Genie code, but the RAM address in question is used by different subroutines, so I couldn't find a way other than manipulating the specific jumping subroutine in the ROM)

Thanks for reading, any feedback is appreciated!
Newcomer's Board / Re: Introduction Topic
December 07, 2020, 05:21:55 AM
Hello everyone!

I'm a total newb to ROM hacking, I'm coming from a very different angle and only started getting into this very recently. I started some hobbyist C++/C programming earlier this year, with the lofty long-term goal of porting one of my favourite games of all time--Gargoyle's Quest 1--to PC, with extensive modding support, widescreen support etc. and even much loftier, possibly procedurally-generated content.

Very recently, unsatisfied with some of GQ2's physics, I started digging into that and learning some basic 6502 assembly, and fixed what I felt was flawed (I'll start a topic about that after this post). This stuff fascinates me and I was unaware of the sheer scope of ROM hacking being done by others, I'm just beginning to explore.