NES Metroid HD Pack

[Aclectico]

@Mugi - Thanks for your thoughts on the "jump" byte strategy. It seems like a reasonable solution to pursue. But, I must admit I am not quite sure how to execute. Creating conditions based on tiles hasn't been too bad as the PPU viewer in Mesen clearly shows tile information when right clicking and navigating to "copy tile (HD Pack Format)".

However, it sounds like this would be a little different. Do you believe the strategy you mentioned would require a memoryCheck function? If so, do you think you could point me in the right direction? Do you think the event viewer in Mesen the best place to start searching for a usable "jump" byte?

BTW, I checked out your Shatterhand pack and I really like what's done so far. The note in your hires.txt file that said the following made me smile:

"conditionals for stage select screen, caution! might be dangerous to mental sanity, do not edit"

[kya]

I've had some spare time lately, so I've decided to check out Samus running animation.
The result is here:

https://yadi.sk/d/CgBByv-y0vrXqw

Just unzip it over your 1.2 version pack.
Note that your mmm.ips and hires.txt will be overwritten.
The animation itself is quite badly scaled, but it's just a template for you to work on (if you choose to).
There are some other glitches to it:
1) Samus "backfacing" elbow does not get rendered. Unfortunately, there's no placeholder for it, so it should be removed from the png frames.
2) When running and shooting occasionally Samus torso gets shifted. This may be corrected by shifting all running frames 4 pixels left (revealing  parts of the hidden elbow),
but that removes a toe of Samus "front" leg.
3) samus-leg-**.png frames do not stitch well to her shooting and "up-shooting" trunk.

The animation is done for only one initial suit. If you find it acceptable, you may add condtions for the other suits by changing palettes in the <tile> tags.

I've also replaced the "prejumping" frame in mmm.ips, as you have requested,
although I'm not sure your changes to jumping will merge well with the attached code.

Note that after applying the mmm.ips the original Samus animation is totally broken, do not attempt to run the patched game without the HD Pack.

Check out the "SamusNotJumping" condition in hires.txt, maybe it will help you with your work on jumping.

[Aclectico]

@kya thank you once again! Your skills continually impress me. You were able to add frames AND fix the jumping issue that just recently came up!

After changing a few numbers in your hires.txt file, I was able to merge your conditions with the most recent version. The only thing it didn't seem to play nice with was some previously made level layout changes since version 1.2. But, I am going to attempt something that may still allow everything to work together (fingers crossed).

In any case, below is a quick illustration. It seems your changes allow for 10 frames. But, I think 5 may be a sufficient improvement since the most recent stable version only uses 3. For the illustration below, I simply used the 5 I had on hand and inserted them twice so it added up to the 10 you have coded in the hires.txt file.

The only question I have at the moment is - can the sound of the footsteps be changed so that they occur at a slower rate (or can the run frames increase in speed)? When looking at the running animation, it seems like it is not quite in sync with the sound of footsteps. If not, I suppose I could delete the footstep sound entirely as it is relatively subtle (although, that would not be ideal).

before:


now:


gameplay:

[kya]

The animation rate and the number of frames are now controlled entirely by hires.txt. You may make as many frames as you wish and set their rate.
An example is attached below:
https://yadi.sk/d/V5nkHKuyLsvmqA

There you have 5 different frames. Each frame is being displayed for a period of 5 video fields:
<condition>frame3,frameRange,25,20
<condition>frame2,frameRange,25,15
<condition>frame1,frameRange,25,10
<condition>frame0,frameRange,25,5

If you want to make the running animation faster, you change the numbers. For example to make each frame last 4 video fields, you write:
<condition>frame3,frameRange,20,16
<condition>frame2,frameRange,20,12
<condition>frame1,frameRange,20,8
<condition>frame0,frameRange,20,4
In the above example the entire animation cycle of 5 frames will last for 4*5 = 20 video fields.

You may make Samus run even faster like this:
<condition>frame3,frameRange,15,12
<condition>frame2,frameRange,15,9
<condition>frame1,frameRange,15,6
<condition>frame0,frameRange,15,3
But to my taste this is ridiculously fast.

I have not tried it yet, but I think I'm able to modify the footstep sound rate via mmm.ips
You may set up the desired animation rate via hires.txt, and then I'll try to adjust the sound.

[Aclectico]

@kya - Excellent - I tried a couple of different speeds and the option with 5 video fields seems right (the first one you mentioned). If the footsteps can match I think we might have a winner.

BTW - looking over your work that resulted in the final solution for running was very interesting. I was surprised to see you modified the .ips file so that the game running in the background would freeze the running animation entirely (so that Mesen could do all the work with running frames via the HD pack). But, it does make sense as you seem to have frozen the frame with the most tiles available to edit (allowing for maximum creative freedom) - very resourceful.

It will take some time to create frames and duplicate the conditions for all of the different suits and areas - so it may be a while before everything is complete. But, this is promising and I am very optimistic. Thanks again.

[mkwong98]

Good job! This is a very interesting way of doing it.

Currently you cannot match the footsteps because you have no control of which frame of the running animation is being shown first. I posted a feature request to Mesen for an advance of version of frameRange which can start and reset with conditions but I'm not sure how difficult it is for Sour to implement.

[Shade Aurion]

This is coming along nicely! This will be one of the greats guys. I can't wait to see it completed <3
Even what is available now is amazing but the potential for the future, especially after seeing that running animation is very promising

[kya]

To adjust footsteps delay while running Mesen, invoke its memory viewer (Ctrl-M). Go (Ctrl-G) to adress CD33. The default delay value is 09. Change it to the value you like. Then invoke Mesen debugger (Ctrl-D), choose menu item File->Save ROM as...
Extract the new ips patch using Lunar IPS "Create IPS patch" button.
Do not forget that the value is in hexadecimal, so 09+1=0A, 09+2=0B, ..., 09+6=0F, 09+7=10.
By the way, to my taste 10 is good enough, about twice as sparse as the original.

As for the frame I've chosen to freeze - all the three running frames hold enough bytes to define the new animation.
That exact frame wasn't used anywhere except running, so it was the least invasive.

Concerning the resettable frame counter, there is a problem to it. Imagine two red skeletons in Castlevania. They have a two frame collapsing animation. I want to replace it with four frames. I hit one skeleton, he starts to collapse, the frame counter gets reset and starts counting. While the first skeleton is collapsing, I hit the second skeleton. The frame counter resets again. First skeleton's collapsing animation starts from the beginning, which is not what I want. Ideally there should be multiple frame counters. But even in that case I do not know, how to tie a specific counter to a specific skeleton.

[mkwong98]

Concerning the resettable frame counter, there is a problem to it. Imagine two red skeletons in Castlevania. They have a two frame collapsing animation. I want to replace it with four frames. I hit one skeleton, he starts to collapse, the frame counter gets reset and starts counting. While the first skeleton is collapsing, I hit the second skeleton. The frame counter resets again. First skeleton's collapsing animation starts from the beginning, which is not what I want. Ideally there should be multiple frame counters. But even in that case I do not know, how to tie a specific counter to a specific skeleton.

You are right, it only works for animations which do not have multiple instances on screen at the same time.

[Mugi]

@Mugi - Thanks for your thoughts on the "jump" byte strategy. It seems like a reasonable solution to pursue. But, I must admit I am not quite sure how to execute. Creating conditions based on tiles hasn't been too bad as the PPU viewer in Mesen clearly shows tile information when right clicking and navigating to "copy tile (HD Pack Format)".

However, it sounds like this would be a little different. Do you believe the strategy you mentioned would require a memoryCheck function? If so, do you think you could point me in the right direction? Do you think the event viewer in Mesen the best place to start searching for a usable "jump" byte?

BTW, I checked out your Shatterhand pack and I really like what's done so far. The note in your hires.txt file that said the following made me smile:

"conditionals for stage select screen, caution! might be dangerous to mental sanity, do not edit"

yeah as you can see from my shatterhand project, i use a lot of memorycheck and memorycheckconstant in it to do things based on set bits.
depending on what you're doing it can be an extrmely effective way to condition stuff, but it seems that you solved your issue already so i guess all is good.

and yeah, there's some whitty remarks in that file. as you see i have completely written it by hand instead of using a template spit out by mesen, so it's been a long series of typing conditions @.@

the stage selection conditions comment is there for a reason, if you read through that, you'll see why i left it there.

[SourMesen]

Whoops, haven't been following this thread as much as I should have been.
I'm amazed at how good the animation looks now!

.. I'm also amazed that Mesen doesn't die from having that many conditions setup :p

If you've noticed patterns that often get repeated in terms of conditions that could be reduced by some additional HD Pack functionality, let me know and I'll see what I can do (or if there's anything else related to HD packs, really)

[Aclectico]

@SourMesen - good to hear from you, and thank you for the kind words on the animation. So far, the hires.txt file for Metroid: HD contains 29,873 lines of code (and counting) and it hasn't broken yet.... Knock on wood.

The Power Suit and Varia Suit are done and the "Zero Suits" are next to be done. I'm sure I could be more concise in the way I'm laying the conditions out, and there may be some unneeded ones in there too, but it seems to be working.

I did notice one issue that can be seen in the picture below. When obtaining items, the original graphics that are replaced by the HD pack still cast a "shadow" over the items. It seems to occur in many areas where graphics overlap (this also occurs when the player enters the area of the HUD). It's not a huge deal, but it is noticeable. I'm not sure if this could be addressed with conditions or if an adjustment would need to be made with Mesen. Aside from that, I am surprised how well the emulator is handling everything.

[Mugi]

It's so nice to see that "the man" himself is interested enough to follow this stuff up.
I have to say that i was expecting mesen to choke on the hires.txt much earlier than it does too.
although the bottleneck you fixed from mesen during one of our conversations in the github issues seemed to greatly help on this matter too.

as far as this particular project goes, im greatly interested of exactly how large this thing grows to be at the end (it's already double the size of mine lol.)

as for the shadow, i have to say i have no idea how metroid works, but from the looks of that picture alone, it looks like it's just drawing a black sprite there maybe.
try making it do that while you're recording a hdpack and see if it captures a new sprite. (this kind of stuff is why i requested the feature of keeping HDpack active during HDpack recording to begin with, i hunted some random hard to trigger sprites for an eternity in shatterhand.)

[Aclectico]

@Mugi- I tried re-recording sprites and it didn't seem to affect anything unfortunately. It's kind of odd as the shadow moves with the player and only shows up in some areas.

Moving over the HUD makes it a little easier to see. It's a silhouette of what the player sprite looks like before applying the pack. I believe this has been how the pack has behaved from the beginning. However, it was less noticeable before because the "HD" legs fairly closely matched the leg position of the original. However, since the jumping animation is drastically different from the original now, the "silhouette" effect that occurs on items and in the HUD is more noticeable.

This is just a shot in the dark, but perhaps it has something to do with how Mesen handles background/foreground priority.

[Mugi]

does your new texture have transparent area where the black leg appears or how does that work.

if it's not a sprite, the other thing that came to my mind is the whole sprite contour thing.
in my shatterhand pack, i masked the stage selection screen stuff into transparent tiles, and the new ones are drawn into the background,
but i had to turn off the sprite contours from the hires.txt for this to work because the transparent tiles were drawing garbage over the background
graphic.

if you dont have that enabled, try it out and see if that improves anything.

just throw a
<options>disableContours
to the beginning of the file

[Aclectico]

Thanks for the idea. Yes - the pack contains tiles are transparent where the black leg is showing (or anywhere other parts of the silhouette show depending on where the player is positioned). I did give the contours option a shot and it seems to be the same. Must be something else causing the silhouette....

As a sidenote, I just tried it out on Mesen rev 0.9.5 (I removed the background conditions first) based on a hunch that somehow implementing the custom backgrounds caused the issue. Unfortunately, it looks like that rev without custom backgrounds has the silhouette as well. So, dead end there too...

[mkwong98]

Did you check the PPU viewer for a black sprite? Also you can change the shape of the leg by adding/removing a few pixels in the rom to see if the black leg changes too. If it changes and you don't find any black sprite then it is a bug with the emulator.

[Aclectico]

@mkwong98, thanks for the idea. The .ips file has been modified to do exactly what you suggested and it seemed to do the trick.

Up until recently, I wanted to ensure the base graphics remained unchanged so that it would be relatively easy for users to implement 8-bit graphics with custom music if they wanted (just delete a few conditions). But, since the latest running solution breaks the 8-bit graphics anyway, I just realized it's now a moot point.

To make 8-bit graphics with custom music still relatively easy to implement, the best alternative may be to simply include a pre-compiled "8-bit" zip file in the download. This shouldn't be too difficult. It'll be added to the "to-do" list after "zero suit" running graphics are finished.

[SourMesen]

Sorry for the late reply (been rather engrossed in a "little" side project that has been taking every single minute of my spare time for the past 2 weeks :p)

Am I understanding properly that the black leg showing up is likely a bug in the replacement logic?  e.g making the original leg transparent in the ROM makes the leg go away in the HD version? If so, I'll add it to my list of things to check before the next release (I was originally planning on releasing 0.9.8 a couple of weeks ago, but got sidetracked by said side project, might be a few more weeks before I get around to releasing it, so I can investigate this before doing that)

[Aclectico]

@SourMesen, I'm still not sure if it should be considered an emulator bug or a quirk in how Metroid renders certain elements (such as items and the HUD). In any case, you are correct that the black leg shows up until the .ips file is modified so that the original leg is completely transparent. For this pack, it's not a huge deal as the .ips workaround is sufficient to generate satisfactory results. With that said, I'm not sure if other games are affected or if other HD pack authors would be interested in a fix. If you do plan to investigate, you may find the WIP pack down below useful (just run to the left after starting and it's noticeable right away with the morph ball).

WIP Pack 2_24_19: http://bit.ly/MetroidHDWIP02_24_19

Looking forward to the upcoming release of Mesen 0.9.8