[mkwong98]

Have you tried using conditions to check for bottom-rear sprites to distinguish between jumping and running?

[Aclectico]

I haven't. Conditions are used quite a bit in the Metroid: HD pack for inserting backgrounds. However, I am unfamiliar with using them for this particular purpose. In fact, I have been told that conditions can be used to simplify things (like when the same tile is used in multiple areas). However, I didn't discover this until the pack was already mostly finished. As a result, there are many graphics that are duplicated for each area. In short, there are probably many advanced features that could have made life a lot easier.

In any case, I did just check the documentation on Mesen's main website:

https://www.mesen.ca/docs/hdpacks.html#using-conditions

The syntax isn't quite clear to me. Is this something you have done in the past? I am familiar with instructing Mesen to look for a tile or sprite in a specific area. However, do you know the proper command to instruct Mesen to look for a particular tile anywhere on the screen (perhaps using the img index command)? If so, are you also familiar with the proper command to trigger a tile adjacent to the tile meeting the condition to then be transformed into a custom graphic that does not exist else ware in the game (like the front of Samus's feet in a jumping pose)?

[mkwong98]

Check this out:
https://www.mesen.ca/docs/hdpacks.html#lt-condition-gt-tag

You can use "spriteNearby" to do that.

I use it in my Double Dragon II title screen test. The "II" is made of sprites and many of them are repeated. I use condition to check the horizontal and vertical distance between a sprite and the unique sprite at the corner of the "II" and uniquely identify each of the repeated sprites. This means I'm not constrained by the repeated sprites when creating the HD version of the "II".

I use "tileNearby" in my Donkey Kong pack. The game use a series of flat tiles with height of 1 to 8 to represent a slop and simply reverse the order of the tiles when the slop changes from going up to going down. With 4X resolution, this will not look smooth so I have 2 HD versions for each of the tiles and use conditions to work out the direction of the slop.

Be aware a "spriteNearby"/"tileNearby" condition involves 2 tiles and both of them must be on screen in order to function. So a large object scrolling into the screen will have problems. You will need to consider the scroll direction and use tiles within the same column if the object scrolls in horizontally or use tiles within the same row if the object scrolls in vertically.

One fun use of "tileNearby" is that you can use it to identify the blank background tiles around a background object and expand the replacement graphics into those blank tiles.

[Aclectico]

I examined the Donkey Kong pack - I'm impressed. It seems to use conditions almost exclusively and there are over one thousand of them 

For the Metroid pack, I fear it may be difficult to implement conditions based on the player sprite since the player inputs will not be predictable (I'm hoping I'm wrong). I have some notes below that I think may be helpful to reference:

  *Syntax from Mesen's website:
  <condition>[name - text], [conditionType - text], [x value - integer], [y value - integer], [tile data], [palette data - hex]
  <tile>[img index - integer], [tile data], [palette data], [x - integer], [y - integer], [brightness - 0.0 to 1.0], [default tile - Y or N]

  *Tile Information from the game (Power Suit in Brinstar):
  Samus rear jumping tiles that can be referenced: 519,FF161927 or 520,FF161927
  Samus upper and lower leg that needs to change to custom tile when jumping: 546,FF161927 and 562,FF161927

  *Name of custom .png files that can be used to replace front jumping leg: "SamusCustomJumpUpper.png" and "SamusCustomJumpLower.png"

When the Mesen website mentions the "current tile" in the description for "spriteNearby" is that referencing the sprite the player is controlling? If so, I attempted a couple of conditions below. My attempt below is trying to tell Mesen to look for tile 519,FF161927 within 32 pixels of the sprite the player is controlling. If the first condition is met, how would one instruct Mesen to then replace tiles 546,FF161927 and 562,FF161927 with the custom tiles "SamusCustomJumpUpper.png" and "SamusCustomJumpLower.png"? I have an example below. However, it must be incorrect as this command seems to break the pack if it is implemented in the hires.txt file.

*Example WIP:

#Custom Jump
<condition>SamusCustomJump1,spriteNearby,32,32,519,FF161927
<condition>SamusCustomJump2,spriteNearby,-32,-32,519,FF161927
[SamusCustomJump1]<tile>SamusCustomJumpUpper.png,546,FF161927,0,0,1,N
[SamusCustomJump1]<tile>SamusCustomJumpLower.png,562,FF161927,0,0,1,N
[SamusCustomJump2]<tile>SamusCustomJumpUpper.png,546,FF161927,0,0,1,N
[SamusCustomJump2]<tile>SamusCustomJumpLower.png,562,FF161927,0,0,1,N

Also, one more question - Is it possible to have a replacement graphic extend beyond the area of a target tile to be replaced? I just noticed more room than eight pixels is needed in the rear bottom of Samus when jumping to make a good looking graphic. Thanks.

[mkwong98]

The current tile is the one that the system is rendering. So lets say the image index of SamusCustomJumpUpper.png is 1 and SamusCustomJumpLower.png is 2, Samus tiles face right in the ROM and 546(B) and 562(D) are the front tiles and 519(A) and 520(C) are the rear jumping tiles in the following arrangement:
AB
CD

<condition>CheckForTileA,spriteNearby,-8,0,519,FF161927
<condition>CheckForTileC,spriteNearby,-8,0,520,FF161927
[CheckForTileA]<tile>1,546,FF161927,0,0,1,N
[CheckForTileC]<tile>2,562,FF161927,0,0,1,N

So when rendering tile 546, the emulator finds the line with condition "CheckForTileA". The condition tells the emulator to check if a sprite 519 is located 8 pixels to the left of tile 546 (the current tile). If the sprite 519 is found then it will use SamusCustomJumpUpper.png

Unfortunately you cannot extend the replacement for sprite tiles, you can only do that for background tiles because the background tiles cover the whole screen but sprite tiles don't.

I use a tool to generate the conditions so they are pretty easy to work with.

[Aclectico]

Thank you for the feedback. I believe I understand. Below are a few screenshots that may be helpful.

Samus Diagram


Hires.txt Screenshot


SamusCustomJumpUpper.png


SamusCustomJumpLower.png


Using the instructions you provided I created the following condition and placed it at the very end of the hires.txt file. I tried a few different values for the x and y entries.

#Custom Jump
<condition>CheckForTileA,spriteNearby,-8,0,519,FF161927
<condition>CheckForTileC,spriteNearby,-16,-8,520,FF161927
[CheckForTileA]<tile>303,546,FF161927,0,0,1,N
[CheckForTileC]<tile>304,562,FF161927,0,0,1,N

However, it does not seem to have an effect. Perhaps the tile information I have listed is in error? Would 303 and 304 be listed if there were 302 image tags listed before in the hires.txt file?

Also, that is too bad that a replacement tile cannot be larger. That will be a problem. However, if the spriteNearby command is successful, it may be possible to still work around this limitation.

BTW, I'm using Mesen 9.6 to generate tile information as there is a little bug in 9.7 (right clicking currently creates hex values but conditions still only work with numeric tile values).

[mkwong98]

You have to place those lines above the lines for walking, otherwise the lines for walking will have higher priority and always get rendered as those don't need to check for conditions. So basically the emulator will stop looking further down as soon as it finds one that matches the one it is trying to render and in this case it is the walking version.

[Aclectico]

Thank you. Moving the command up between the image tags and tile tags seemed to do the trick. The conditions below look to mostly work (there still does seem to be some type of issue with the "waist" commands.)

<img>SamusPowerJumpFrontHead.png
<img>SamusPowerJumpFrontWaist.png
<img>SamusPowerJumpFrontFeet.png
<img>SamusPowerJumpFrontFeetBlank.png
<img>SamusPowerJumpBackHead.png
<img>SamusPowerJumpBackWaist.png
<img>SamusPowerJumpBackFeet.png
<img>SamusPowerJumpBackFeetBlank.png

#Custom Jump
<condition>SamusPowerJumpFrontHead,spriteNearby,8,16,519,FF161927
<condition>SamusPowerJumpFrontWaist,spriteNearby,8,8,519,FF161927
<condition>SamusPowerJumpFrontFeet,spriteNearby,8,0,519,FF161927
<condition>SamusPowerJumpFrontFeetBlank,spriteNearby,8,-8,519,FF161927
<condition>SamusPowerJumpBackHead,spriteNearby,8,16,520,FF161927
<condition>SamusPowerJumpBackWaist,spriteNearby,8,8,520,FF161927
<condition>SamusPowerJumpBackFeet,spriteNearby,8,0,520,FF161927
<condition>SamusPowerJumpBackFeetBlank,spriteNearby,-8,0,519,FF161927
[SamusPowerJumpFrontHead]<tile>302,512,FF161927,0,0,1,N
[SamusPowerJumpFrontWaist]<tile>303,577,FF161927,0,0,1,N
[SamusPowerJumpFrontFeet]<tile>304,546,FF161927,0,0,1,N
[SamusPowerJumpFrontFeetBlank]<tile>305,562,FF161927,0,0,1,N
[SamusPowerJumpBackHead]<tile>306,513,FF161927,0,0,1,N
[SamusPowerJumpBackWaist]<tile>307,576,FF161927,0,0,1,N
[SamusPowerJumpBackFeet]<tile>308,519,FF161927,0,0,1,N
[SamusPowerJumpBackFeetBlank]<tile>309,520,FF161927,0,0,1,N

Regardless of the "waist" command issues, it still looks like the rule that Mesen cannot insert a replacement graphic larger than the target graphic may be a deal breaking issue for this strategy anyway. Below represents an effort to squeeze Samus into the available player squares.



In my opinion, crunching the legs into the available space makes the animation look a bit jarring since the sizing is noticeably different. Maybe it's just me, but playing with these changes makes the game feel worse than before. It's like the legs of Samus inexplicably transformed into the legs of a six year old child.
Ideal Jumping Graphic:


Alternatives that come to mind are as follows:

-Hack the ROM to add a new square below the bottom-rear of the player sprite (the front has sufficient space). Then, incorporate the change into the .ips file included in the pack.
-Hack the ROM to simply move the rear foot square (520,FF161927) so that it is now directly underneath Samus rather than out to the side. This would also need to be incorporated into the .ips file.
   *This is not ideal as it would remove some of the customization options available to the player (like playing with 8 bit graphics but 16 bit sound)
-Find some type of workaround using additional conditions in Mesen.
   *As a sidenote, I did attempt changing the x and y coordinates of the very last command in hopes it would move the block. Unfortunately, it seems to move the graphic within the fixed block rather than move the block itself.
-Throw hands up in frustration, walk away, and go out for bubble tea instead.

If anyone has the technical knowledge to pursue any of these alternatives, I would be happy to incorporate into the master pack For now, it appears I may be stumped again.

[mkwong98]

I think the legs of her jumping pose while aiming up in Super Metroid is more compact. Would that fit?

[SourMesen]

As is, I can't think of any way to get this done with conditions alone, unfortunately.
Allowing replacement tiles to be bigger than their original versions, while probably not impossible, would probably be rather tricky to get right (when considering sprite priority, draw order, etc.) and would either be limited to overflowing in a specific direction (e.g right and bottom), or would require additional syntax to specify how the oversized replacement would align itself over the original tile, etc.

With the way the code is right now, it probably wouldn't be simple to implement.  Since the pixel replacement process is done pixel by pixel, rather than tile by tile, it makes it harder to draw outside the bounds of the original tile.

I'll keep it in mind for now, and maybe I'll come up with an easy solution eventually!

[mkwong98]

May be add a pass through OAM before rendering and if a sprite in OAM with matching tile data and palette data is found then add an OAM entry into a separate HD pack OAM with the same priority and flip but with x and y offset from that sprite. When rendering with HD pack, read the HD pack OAM too. The line can be something like this:
<ExSprite>[img index], [tile data], [palette data],

• , [y], [offsetx], [offsety], [brightness], [default tile]

 

[Aclectico]

@mkwong98, thanks for the suggestion on Samus looking up. I did check that out. While it helps, I do think it still looks a little odd. I can't quite put my finger on it. Maybe part of the issue is the small number of frames. Since Samus becomes condensed into a small number of tiles so quickly with the "conditions" strategy, the change between running and jumping isn't very smooth. So, the answer may lie in either adding frame animations so that it isn't quite so jarring (or extending beyond the available tiles so that the difference between running and jumping isn't so drastic to begin with).

[mkwong98]

I think which leg is the front leg also contributes to the problem. Facing left, the left leg is in front in the frames before the desired frame and it is the right leg in the desired frame. The animation may look less odd if the frames have the same leg in front.

[Aclectico]

That is a good observation. I will try to fiddle with it a bit and see if adjusting that helps.

[Aclectico]

**Update**

I have a new art example below and I am making efforts to implement it in the game. I did notice an obvious problem with the mid-section. However, I received some advice from mkwong98 that may allow me to overcome this limitation. I hope to have a working prototype soon.

Desired jump art:


Current in-game rendering of jump art (failure for now):

[Aclectico]

**Update #2**

I inserted a little over 5,000 new condition lines in the hires.txt file, and now have a working prototype for jumping that I believe is less awkward looking - Thank you mkwong98!

I think it is very close. But, I have hopes that one aspect of the new animation can be still be improved.

When jumping, the game briefly flashes one frame that happens to be shared with the running animation before it shows the new jump art that has been created. Before, this was not a big deal as the shared frame shown was very similar to the frame that followed shortly after. Samus is shown with the rear leg facing outward. However, this shared frame is now more noticeable because it is so different from the new art that has been created. I was hoping I could replace this intermediary frame using the same "spriteNearby" method mentioned by mkwong98. However, there appears to be no unique tiles in this intermediary frame. Perhaps there is another solution using memoryChecks? I am open to ideas. I think it could still look acceptable if the intermediary frame shares a frame with running. However, it would probably look better to use the frame where the legs of Samus are closer together. Illustrations are available below.





In any case, I am happy to share the prototype in the following link. I wouldn't consider this a stable release yet as I have not done much bug testing (and there are one or two things I think I'd like to add as well). So, I haven't updated the original post at the start of the thread. But, if anyone is interested and also has an idea to improve the jump in the meantime, I'm all ears

WIP HD pack (not yet bug tested): http://bit.ly/MetroidHD_WIP_2_12_19

[darthvaderx]

The Brinstar theme track included in the WIP HD pack is worse than the 1.2 version (just in my opinion).

[mkwong98]

Good work! I'm surprised by the number of conditions required to change that animation. 

[Aclectico]

@darthvaderx - Thanks for the honest feedback. You may be surprised to learn I'm actually a little relieved to hear that. I had a few requests for music that was a little more 16-bit-esque for that area. I think the new version fits that criteria. But, after listening to it a few more times, I don't think the trade off is worth it in this case. I experimented and went back and forth a few times. I changed the default music back to what was in place before and I updated the WIP pack. I'll still include the 16-bit-esque version. But, I think it will be best to keep it in the "AlternateArtAndMusic" folder instead. I'll also make sure to do this when the stable version of 1.3 is released as well.

@mkwong98 - I was also surprised at the number of conditions (thanks again for your assistance by the way). One was needed for every tile, every suit, every color (missiles on/off plus blue), every area, and every aiming direction. The combinations added up quickly. There may have been a better way to have done it, but it works. Thankfully, Microsoft Excel and the "find/replace" function in Notepad helped keep things relatively manageable.

[Mugi]

for your issue with replacing the last missing frame, i would propably approach this by trying to look for a "jump" byte that shows whether or not samus is jumping, and condition the sprite change based on that in order to only have it happen during jumps..

i share your pain with the stuff... i conditioned all the 8 robot suits to change color in shatterhand.... it was a number of conditions i really did not want to write lol.