How-to: Move & Resize the Net Graphic (NHL '94)

---

It appears that each Net graphic is arranged in 6 x 4 tile qudarants. So four 48 px by 32 px chunks make up the top net, and four different 48 px by 32 px chunks make up the bottom net.

We already know how to change the colour palette for each quadrant thanks to this post by @clockwise:

 

In this post I'll show you how to move around these quadrants. Why might you want to do this? Well, you could…

• Relocate the net graphic.
• Shrink it by moving more of it to overlap itself.
• Make the Net(s) match the Rink symmetry. (In case you haven’t noticed, the Nets are an odd number of pixels, in Rink, Crease, etc. made up of an even number of pixels.)

It’s possible that more can be done than this. I was investigating making the Net(s) symmetrical, and once I achieved that, I abandoned this project. I’m posting my notes in case someone else can make use of this, or wants to keep investigating this area of code.

I have included the minor adjustments needed if you want to make the Net symmetry match the Rink symmetry.

 

---

 

Top Net

Top Net: Top Left quadrant

X-position / Y-position
0xA16BB / 0xA16BD

Original
E8 / E9

Symmetrical (1 pixel to the right)
E9 / "
 

Top Net: Top Right quadrant

X-position / Y-position
0xA16C3 / 0xA16C5

Original
FF / E9
 

Top Net: Bottom Left quadrant

X-position / Y-position
0xA16CB / 0xA16CD

Original
E6 / F9

Symmetrical (1 pixel to the right)
E7 / "
 

Top Net: Bottom Right quadrant

X-position / Y-position
0xA16D3 / 0xA16D5

Original
11 / F9

 

---

 

Bottom Net

Bottom Net: Top Left quadrant

X-position /  Y-position
0xA16DB / 0xA16DD

Original 
E8 / E6

Symmetrical (1 pixel to the right)
E9 / "
 

Bottom Net: Top Right quadrant

X-position / Y-position
0xA16E3 / 0xA16E5

Original
FF / E6
 

Bottom Net: Bottom Left quadrant

X-position /  Y-position
0xA16EB / 0xA16ED

Original
F8 / E4

Symmetrical (1 pixel to the right)
F9 / "
 

Bottom Net: Bottom Right quadrant

Sorry, I never got this far. If anyone else figures this out, let me know and I will update it here.
 

Edited December 27, 20232 yr by AdamCatalyst
standardizing naming and formatting

Thanks for this eh. I've always had some issues with how the new nets were recoloured. This can really open up some possibilities.

Now the question is, if it's possible to translate this over to the puck...

It's unfortunate that the stuff I found offers such limited customization. I had grand ideas of mixing colour palettes, and other things, but haven't been able to get any of my ideas to work or look good within these restrictions. I suspect there is more to discover here, I gave up early on this one, it was not an exhaustive search. 

Interesting coincidence that the radio today had a show that concentrated on the history of the story of, and the modern take on the term "Holy Grail".

While the commercial aspect of using the term has gotten too aggrandizing, despite the level of historical connection to how "acquire this thing and your life will be better." is what the legend has been for centuries, I find that the "questing" part, for something that is so challenging that it can be either a white whale or grail, does still resonate, perhaps to a notably modest level, with the quest for the hole ice puck.

6 hours ago, von Ozbourne said:

Now the question is, if it's possible to translate this over to the puck...

Wait, what are you trying to do with the puck?

3 hours ago, AdamCatalyst said:

Wait, what are you trying to do with the puck?

Oh, there was an urban legend that the puck's palette could be changed to match the team colours, and thus change with the home team.
But the concrete evidence and methodology have been either lost to time with Damascus steel or that lighthouse near Alexandria. At our current stage, it also can't be ruled out that the proof of concept was never actualized.

Got it. I can’t help but be drawn to such a challenge. Will review my notes and venture out into the wilderness today over breakfast. 

found it.

Edited April 27, 20233 yr by AdamCatalyst

14 hours ago, von Ozbourne said:

Oh, there was an urban legend that the puck's palette could be changed to match the team colours, and thus change with the home team.
But the concrete evidence and methodology have been either lost to time with Damascus steel or that lighthouse near Alexandria. At our current stage, it also can't be ruled out that the proof of concept was never actualized.

 

 

Man, I know @clockwise had done this hack (changing puck color to home team) in his ROM updates years back.  I can't find the info though.

On 4/26/2023 at 9:54 AM, AdamCatalyst said:

It's unfortunate that the stuff I found offers such limited customization. I had grand ideas of mixing colour palettes, and other things, but haven't been able to get any of my ideas to work or look good within these restrictions. I suspect there is more to discover here, I gave up early on this one, it was not an exhaustive search. 

There's a missing piece to this. What you have found are codes that move the top and bottom net. I found them many years ago and applied them to my smallest goal rom. These codes are needed to fine tune the location of the top and bottom goal to "match" the exact boundary created by the codes that control the invisible boundary of the goal scoring window :

https://forum.nhl94.com/index.php?/topic/18850-how-to-make-puck-hit-boards-instead-of-invisible-barrier/#comment-176501

To achieve accurate fine-tuned collision you have to adjust both of those sets of codes to "align" with one another. These move around the whole of the "goal artwork" of codes on their position on the ice. It's hard to get a full appreciation for how complicated this is and how much balancing is involved, but I've worked through this and know how to make meaningful changes to any goal artwork or size. The codes you found can often help with additional alignment of collision of when the puck crosses the rink ice not crossing the goal-line threshold at the correct pixel. And you've already edit the normal goal artwork and you move the goals around this way and see what happens.

So it's important to understand how important these codes are to doing what I did in the smallest goal rom for example. If you test my rom you'll notice how tight the goal collision is. It's no coincidence. It took extensive research of balancing of 4 distinct sets of codes. The sense I got from your comment was you conclude that you were limited, by I think not realizing how all this relates to my barriers code and the other ways to edit the goal artwork. It's very complicated but I'm pleased to say that I've worked though this and have the missing links.

In my experience the default collision with the normal goal artwork is not satisfactory which is why I've been working so hard not only to make smaller goals but to improve the accuracy of shots on goal generally and how they interact with the goal and the posts. One thing we know about NHL 94 on Genesis is that often the puck might go through where the post art is and becomes a goal, often depending on the angle that the puck is moving towards the goal. With the barriers code (and appropriate edits to the goal artwork, and these goal position codes) you can achieve a customly placed goal window (size) of your choice. But there are multiple steps involved, of testing in-game then fine turning the art and the position to reach the barriers set in the other code. You realized that you couldn't actually resize it but you initially thought you could because of the limits to how you can edit and move the top goal art. What you observed there was a real limitation, it's because the only part you can "move" is the upside down U shape part. The inner part of the top goal is uneditable by the normal goal art and can only be altered by editing the rink art in those tiles.

With my collision codes you can fine tune whatever edits you made to the goal artwork or the goal position code that you found, but there's no running away from the collision values. They govern the goal window (and how the goal art aligns with them) whether you use edit or not. You've concluded that there is limited customization because you've run into real limits and haven't worked through them. Fortunately for you I have a solution to this dilemma and all that it takes is an understanding that it takes various separate sets of codes to align the goal art and the physical barriers. Through thorough testing (of shots near posts, etc, testing the boundary alignment with the goal art) you can learn how these 3 distinct code sets interact with one another.

First there's editing the goal art itself to make the goal bigger or smaller, narrower or wider depending on what the barrier code is. This needs to be done after setting the barriers code. But you can only do so much without the position codes you found which are crucial to alignment. You do as much as you can with the normal goal art getting it where you want it, in relation to my barriers code. But then you test it and it's not quite aligned properly. Example - even after extensive edits to my barriers code, and to the goal artwork, the barriers might still not be properly aligned with the goal or ice art. (goal-line, etc) The puck might go through the top part of the goal and miss, so you need to move that top goal down a few pixels. Remembering that with the top goal you can move the top bar down a few pixels (in the artwork) to tailor the adjust down U-shaped art of the top goal to where the collision is. You might find that the goal edges even after extensive edits to the goal art and to the barriers code, you will find it's still a pixel or two off from where you want it to be. That's where these position codes come into play. With these you can fine tune it further, you move the position of the overall goal artwork on the ice, pixel by pixel if the barrier value is still not matching the goal art. Note that these codes you found can also be found in RAM and fine tuned with the game running to get the position right. And Three, to tie it all together my barrier codes.

It's important to note that Regardless of what size goal you are using, even if you're simply using the "original" size goals, that all these sets of codes are interacting with one another whether you are aware of it or not. Remember that you can determine the size of the goal "window" with the barrier codes. But where those physical barriers are are not aligned with the goal art or even the default values in your goal position codes. If you tested my smallest goal rom you'd have experienced the end result of tying these loose ends together.

@Brodeur30 This post is *only* about “Moving & Resizing the Net Graphic.” That's not an oversight or omission, that's just what the focus is here. The actual collision area for the Net can be reshaped and moved, but I've not had the time to post notes on those variables. Your thread is still the best resource to learn how to affect that.

2 hours ago, AdamCatalyst said:

@Brodeur30 This post is *only* about “Moving & Resizing the Net Graphic.” That's not an oversight or omission, that's just what the focus is here. The actual collision area for the Net can be reshaped and moved, but I've not had the time to post notes on those variables. Your thread is still the best resource to learn how to affect that.

Resizing it can be done this way, but there's an important distinction. There's an integral difference between "resizing" the goal with these codes vs resizing the goal manually by editing the goal art and making the goal art bigger or smaller that way. When you do it through your codes, if i recall correctly, when you "resize" the goal artwork by converging the quadrants inward lets say, through the codes you found here, you're not only moving the artwork but you're also affecting the location of the goal window related to the barrier code. In some cases, to "align" the invisible barriers with the artwork, it requires edits to the goal artwork. Because when you do it that way, you can make changes to the top and side goal to "align" the barrier code with the artwork. So yes you can resize the goals with your quadrant positioning codes, but when you do it only this way (without editing the goal art and redrawing it manually) you can't "correct" the inconsistency between where my barrier code set the boundary vs where the goal art actually is in relation to that. What your codes do for example is it allows you (if you move all quadrants down a few pixels for example) you'll notice that this will cause the puck to cross the goal-line at the correct pixel, in relation to the goal-line on the ice. To visualize it, your codes above essentially move the "outer" boundary of each "corner" area of the goal. But as I explained, with the top goal, the inner rectangle of the goal is uneditable and if you try to move the top goal quadrant goal artwork inward the inner sections will disappear due to this box. I'm trying to help you understand that, the limits you ran into when you (perhaps?) couldn't "correct" or align the boundary and the goal art properly to your liking by these codes. It's because these codes maintain the integrity to the boundary to a degree whereas manually editing the goal art doesn't. Each set of codes are important for different reasons but to create custom goal sizes and to align it correctly it requires manually editing the goal art in addition to adjustments of your codes to the overall position and shape within the boundary. Note that I have learned how this works over time. The sense I get is taht you weren't putting it all together and got frustrated so I was trying to explain the issue.

After further testing of these codes, particularly the top goal codes, I can confirm that you can take any normal goal art and converge it inward as you described and the upside down U shaped top goal art moves in over the uneditable area. So I want clear up any confusion. As far as what I said earlier, it is true that these codes can be used to align the goal art with the goal line on the ice, but these codes do not appear to affect the barriers as I implied. But more testing is needed to fully confirm this. It has been quite a while since I've been modding NHL 94 so I'm trying to remember everything that I had previously learned. Extensive testing is needed to see how a converged normal goal art through only the codes above interact with a lower barrier code. In some cases, the barriers code may have a different geometry of the scoring area that would require some manual adjustments to the goal art in tile layer pro but that remains to be seen. I'll have to test your latest rom to see what your barrier interaction is like.

But for context, the way I did my smaller goal rom was not by using these codes primarily, but by drastically editing the normal goal art to go beyond the normal editable boundary, which caused the side posts to be deleted in the goal art and I made them reappear through rink art of those pixels. That's why when the net is knocked off its moorings in my rom the side posts stay in place and only the top part of the top goal moves. This unique way that I achieved that wasn't exactly the most straight forward way but at the time it was the only way that I knew how. And perhaps by using only the codes above combined with the barrier codes you'll be able to have an more straight forward way of reducing the size of the goal art, but no matter which way you do it, micro fine turning of these codes in combination with the barriers code are crucial to getting the puck to hit the post or if it does go through it misses at the exact pixels that the post art is at rather than becoming a goal. And that means, in practice, to adjust the goal art to the barrier, and that is done by testing, viewing slow mo replay of near misses, when it hits the pits, when it bounces of the back of the net, etc. And in the case of converging the quadrants as you described it would still require manual goal art editing to delete the parts that converged upon itself.

Example : 

As you can see, through your codes you can bring in the normal side posts into the inner area that is normally off limits to editing. As in, you cannot "move" those side posts into that inner area and be that narrow as shown above just by editing the tiles. But through the X-position codes, you can bring the side posts into this area,, which is obviously hugely important and was something that I didn't know about when I made my rom. I discovered these codes but it was after I had already designed it via the other method. Notably, as you can see from the screenshot, when converging, it seems that what happens is that the top goal art shows up "over" the bottom goal art. This means that, after converging, you have to go into the goal art tiles and delete parts of the net so it all aligns up without parts from one quadrant on top of parts from other quadrants.

This is a viable method to creating your own custom smaller goal, in a distinctly different way that I initially did it but one that I'm surely going to utilize moving forward. When you get the size you want, then you adjust the barriers code to align with the goal art as best you can which requires trial and error. My overly complicated way of doing itt isn't necessarily the best way to go about this, so if any of what I said was confusing, well I'm trying to work all this out myself and get back up to speed. But your codes are invaluable to making it easy for everyone to make their own smaller goals. Without these codes, it's much harder to do. But with either method it requires manually editing the goal art, and adjusting the shape of the back of the net may also be needed to adjust to the barriers. As you'll find out, it's not just the goal scoring window it's also related to the barrier of the back of the goal and how that interacts with the barriers code. Getting everything aligned can be a challenge and you're well on your way to that now.

I've been doing a lot of testing of these codes, on various roms, and I have come to some conclusion that something in the Fighting code disables the use of these codes. In my experience, it doesn't seem to be the expanded rom or widescreen mode that causes these codes not to work, but rather the addition of the fighting code.

However, on roms without Fighting added, these codes work very well and you can do a lot with them. For my purposes, I have made some meaningful edits to the top and bottom goal art, edits that aren't possible any other way. And I have an important update to the original post, to issue some clarity for Bottom Goal codes.

As I explained in my previous post from a while back, what happens when you use these codes on the top goal is that when you adjust the quadrants inward, the 4 quadrants converge on themselves, with the top two quardants a layer above the bottom two quadrants. This is interesting and makes a lot of sense given my experience with making goals smaller. If you try to make the goal smaller through these codes, for the top goal in particular, it would require deleting some of the tile pixels for the top part of the top goal, the top two quadrants, namely the bottom edge pixels of the top two quadrants so they don't cover the bottom two quadrants after you move it downward, which would be over the top part of the side posts.

Through additional testing of the bottom goal codes, I've discovered is that while the top goal has these 4 quadrants as described, the bottom goal only has 2 quadrants, each whole side. With the Top Goal's bottom left and bottom right quadrant codes, these are essentially each side post part along with its accompanying side netting, able to move independently in any direction, which is below the layer of the top two quadrants.

With the bottom goal however, you don't have this quirk that the top goal has, and what I've found is that you can move each side of the bottom goal (entirely) by Adam's First Two Sets of the Bottom Codes Alone. So, for the purposes of adjusting the Bottom Goal, these two sets of codes do everything you need to do for the Bottom Goal :

On 4/26/2023 at 7:28 AM, AdamCatalyst said:

Bottom Net

Bottom Net: Top Left quadrant

X-position /  Y-position
0xA16DB / 0xA16DD

Original 
E8 / E6

Symmetrical (1 pixel to the right)
E9 / "
 

Bottom Net: Top Right quadrant

X-position / Y-position
0xA16E3 / 0xA16E5

Original
FF / E6
 

So for the Above Codes from the Original Post for the Bottom Goal ^^^ it's not exatly the Top Left and Top Right Quadrant, these first two sets of codes represent the Entire Left and the Entire Right Side of the Goal that you can move.

That means that these codes Below do not appear to do anything to the Bottom Goal, which perhaps is why Adam couldn't verify them :

On 4/26/2023 at 7:28 AM, AdamCatalyst said:

Bottom Net: Bottom Left quadrant

X-position /  Y-position
0xA16EB / 0xA16ED

Original
F8 / E4

Symmetrical (1 pixel to the right)
F9 / "
 

Bottom Net: Bottom Right quadrant

Sorry, I never got this far. If anyone else figures this out, let me know and I will update it here.
 

^^^So, unlike for the Top Goal, there is no Bottom Left or Bottom Right quadrant for the Bottom Goal like there is with the Top Goal, where the side posts and side netting can be moved independent of the top parts of the goal.

For the Bottom Goal, all you need is these two sets of codes :

0xA16DB / 0xA16DD These Two move the Whole Left Side of the Bottom Goal Left / Right and Up / Down respectively.

0xA16E3 / 0xA16E5 These Two move the Whole Right Side of the Bottom Goal Left / Right and Up / Down respectively.

It's important to look at each default value as a 2-byte code, and adjust from there.

For both the Left and RIght Side Y-Position Code, the 2-byte default value is FFE6. The way it works is if you increase the E6, it will move Each Side of Goal Down, and if you decrease the E6, it will move Each Side of the Goal up.

So to move the entire Bottom goal up or down a set amount of pixels, you increase or decrease both 0xA16DD and 0xA16E5 to the same value. But, unlike the Top Goal, you can't adjust the top bar's height in relation to the side posts, as it all moves together as one, on each side. To illustrate on a Medium Size Bottom Goal that I'm working on : (with each side Y-Position code as a different value)

For all intents and purposes, these are adjustment codes, as they do not appear to affect the collision barriers, which remain at or near the original placement of the goal art. The value is that these codes can make micro adjustments to the goal art's position when the barriers are not aligned to your liking. (for example, if a puck is bouncing off an invisible barrier a pixel or two off the post, you can use these codes to move the goal art so that it will hit of the post where the post actually is)

The reason why it's important to look at these codes as 2-bytes instead of 1 byte is beacause of what happens if you increase beyond FF, or beyond FFFF the full code. For example, for the Bottom Goal's Right Side X-Position code 0xA16E3, the default value is FFFF. So to make the right post slightly wider, for example, by 1 pixel lets say, you "increase" the FFFF to 0000. This is exactly what I just did for one of my roms where the bottom goal was slightly narrower than the top goal on the right side. I used these codes to align the top and bottom goal and to make the art more accurate to the barrier code, and to align the bottom goal posts with the top goal's posts which were slightly off. Note that you can't actually do this by just editing the tiles because it mirrors the tiles to each side. With these codes you can make that 1 pixel micro-adjustment to just one side of the goal, which solves the "always a pixel off one way or the other" problem that you'll notice if you pay close attention.

Note that when you use the X-Position codes for the Bottom Goal, it moves each entire side of the goal left or right, which changes the alignment at the middle of the goal. So if you make the goal too wide, for example, through these codes, by more than a pixel or so, you'll notice that the two sides of the goal will disconnected at the middle.

Here you'll see what happens when you use the X-Position codes to make the goal art wide :

See how the bottom one is split at the middle into two parts. You'll see in this one that the goal itself is wider, but it disconnects at the middle. This is what happens when you make it too wide by adjusting the X-Position codes. But in my case I needed it to be slightly wider to get it aligned, both with the top goal's post and with the barrier code, so I may need to go into the tiles to try to re-join it at this wider size through the use of these codes. Meaning, go into the tiles and try to extend the artwork at the middle so this slightly wider goal can be re-joined at the middle. It's something I might have to do, depending on which barriers code I use to ensure accurate art and barrier alignment. More testing is needed as I continue to develop the medium goal and apply it to various roms and these codes are very useful for my purposes.

I'm really deep into this stuff so a lot of this stuff might sound complicated, but it really isn't. The main purpose of this post is just to clear up the confusion about how the bottom codes work and that you don't have 4 separate quadrants like the top goal, you only have two, each full side of the goal.

I can't stress how valuable these codes to fine-tuning misaligned top and bottom goal art, or to slightly adjust as needed if the barriers are off. Meaning, if when you're playing, you notice that the puck isn't hitting the post where it should, at the correct pixel, you can use these codes to bring the collision into alignment. Now if we can only get these codes to work with Fighting Enabled.

Edited June 1Jun 1 by Brodeur30

1 hour ago, Brodeur30 said:

I've been doing a lot of testing of these codes, on various roms, and I have come to some conclusion that something in the Fighting code disables the use of these codes. In my experience, it doesn't seem to be the expanded rom or widescreen mode that causes these codes not to work, but rather the addition of the fighting code.

However, on roms without Fighting added, these codes work very well and you can do a lot with them. For my purposes, I have made some meaningful edits to the top and bottom goal art, edits that aren't possible any other way. And I have an important update to the original post, to issue some clarity for Bottom Goal codes.

As I explained in my previous post from a while back, what happens when you use these codes on the top goal is that when you adjust the quadrants inward, the 4 quadrants converge on themselves, with the top two quardants a layer above the bottom two quadrants. This is interesting and makes a lot of sense given my experience with making goals smaller. If you try to make the goal smaller through these codes, for the top goal in particular, it would require deleting some of the tile pixels for the top part of the top goal, the top two quadrants, namely the bottom edge pixels of the top two quadrants so they don't cover the bottom two quadrants after you move it downward, which would be over the top part of the side posts.

Through additional testing of the bottom goal codes, I've discovered is that while the top goal has these 4 quadrants as described, the bottom goal only has 2 quadrants, each whole side. With the Top Goal's bottom left and bottom right quadrant codes, these are essentially each side post part along with its accompanying side netting, able to move independently in any direction, which is below the layer of the top two quadrants.

With the bottom goal however, you don't have this quirk that the top goal has, and what I've found is that you can move each side of the bottom goal (entirely) by Adam's First Two Sets of the Bottom Codes Alone. So, for the purposes of adjusting the Bottom Goal, these two sets of codes do everything you need to do for the Bottom Goal :

So for the Above Codes from the Original Post for the Bottom Goal ^^^ it's not exatly the Top Left and Top Right Quadrant, these first two sets of codes represent the Entire Left and the Entire Right Side of the Goal that you can move.

That means that these codes Below do not appear to do anything to the Bottom Goal, which perhaps is why Adam couldn't verify them :

^^^So, unlike for the Top Goal, there is no Bottom Left or Bottom Right quadrant for the Bottom Goal like there is with the Top Goal, where the side posts and side netting can be moved independent of the top parts of the goal.

For the Bottom Goal, all you need is these two sets of codes :

0xA16DB / 0xA16DD These Two move the Whole Left Side of the Bottom Goal Left / Right and Up / Down respectively.

0xA16E3 / 0xA16E5 These Two move the Whole Right Side of the Bottom Goal Left / Right and Up / Down respectively.

It's important to look at each default value as a 2-byte code, and adjust from there.

For both the Left and RIght Side Y-Position Code, the 2-byte default value is FFE6. The way it works is if you increase the E6, it will move Each Side of Goal Down, and if you decrease the E6, it will move Each Side of the Goal up.

So to move the entire Bottom goal up or down a set amount of pixels, you increase or decrease both 0xA16DD and 0xA16E5 to the same value. But, unlike the Top Goal, you can't adjust the top bar's height in relation to the side posts, as it all moves together as one, on each side. To illustrate on a Medium Size Bottom Goal that I'm working on : (with each side Y-Position code as a different value)

For all intents and purposes, these are adjustment codes, as they do not appear to affect the collision barriers, which remain at or near the original placement of the goal art. The value is that these codes can make micro adjustments to the goal art's position when the barriers are not aligned to your liking. (for example, if a puck is bouncing off an invisible barrier a pixel or two off the post, you can use these codes to move the goal art so that it will hit of the post where the post actually is)

The reason why it's important to look at these codes as 2-bytes instead of 1 byte is beacause of what happens if you increase beyond FF, or beyond FFFF the full code. For example, for the Bottom Goal's Right Side X-Position code 0xA16E3, the default value is FFFF. So to make the right post slightly wider, for example, by 1 pixel lets say, you "increase" the FFFF to 0000. This is exactly what I just did for one of my roms where the bottom goal was slightly narrower than the top goal on the right side. I used these codes to align the top and bottom goal and to make the art more accurate to the barrier code, and to align the bottom goal posts with the top goal's posts which were slightly off. Note that you can't actually do this by just editing the tiles because it mirrors the tiles to each side. With these codes you can make that 1 pixel micro-adjustment to just one side of the goal, which solves the "always a pixel off one way or the other" problem that you'll notice if you pay close attention.

Note that when you use the X-Position codes for the Bottom Goal, it moves each entire side of the goal left or right, which changes the alignment at the middle of the goal. So if you make the goal too wide, for example, through these codes, by more than a pixel or so, you'll notice that the two sides of the goal will disconnected at the middle.

Here you'll see what happens when you use the X-Position codes to make the goal art wide :

See how the bottom one is split at the middle into two parts. You'll see in this one that the goal itself is wider, but it disconnects at the middle. This is what happens when you make it too wide by adjusting the X-Position codes. But in my case I needed it to be slightly wider to get it aligned, both with the top goal's post and with the barrier code, so I may need to go into the tiles to try to re-join it at this wider size through the use of these codes. Meaning, go into the tiles and try to extend the artwork at the middle so this slightly wider goal can be re-joined at the middle. It's something I might have to do, depending on which barriers code I use to ensure accurate art and barrier alignment. More testing is needed as I continue to develop the medium goal and apply it to various roms and these codes are very useful for my purposes.

I'm really deep into this stuff so a lot of this stuff might sound complicated, but it really isn't. The main purpose of this post is just to clear up the confusion about how the bottom codes work and that you don't have 4 separate quadrants like the top goal, you only have two, each full side of the goal.

I can't stress how valuable these codes to fine-tuning misaligned top and bottom goal art, or to slightly adjust as needed if the barriers are off. Meaning, if when you're playing, you notice that the puck isn't hitting the post where it should, at the correct pixel, you can use these codes to bring the collision into alignment. Now if we can only get these codes to work with Fighting Enabled.

The fighting code has to move the frame data to new space since it is adding new frames. The tile locations are not changed. What you are editing here is the offset of the sprite tile in the frame, relative to the position the code labels as the center of that frame.

For example, the player's frame uses their feet as the frame center, and uses this location for collision purposes.

The offsets you are editing are in the frame data that is getting moved. If you use the 94_custom_patch route, these changes you made in the frame data should be copied over (I had updated it a few months ago to get this working, previously it was just copying over data from the vanilla ROM). When you run the python program, you should see it saving the files needed.

I should write up a way to make your own frames. This way, you can just make your own sprite tiles, form them into a frame, add the data, and reassign the nets current frame to your new one.

18 hours ago, chaos said:

The fighting code has to move the frame data to new space since it is adding new frames. The tile locations are not changed. What you are editing here is the offset of the sprite tile in the frame, relative to the position the code labels as the center of that frame.

For example, the player's frame uses their feet as the frame center, and uses this location for collision purposes.

The offsets you are editing are in the frame data that is getting moved. If you use the 94_custom_patch route, these changes you made in the frame data should be copied over (I had updated it a few months ago to get this working, previously it was just copying over data from the vanilla ROM). When you run the python program, you should see it saving the files needed.

I should write up a way to make your own frames. This way, you can just make your own sprite tiles, form them into a frame, add the data, and reassign the nets current frame to your new one.

I haven't applied the Fighting Code to any roms myself but in trying to test these codes on roms that have, I have encountered the issue of not being able to use these codes on those roms. I guess I'm just trying to understand how moving the frame data might limit the use of other codes that utilize this area. But I would stress that in the roms that the Fighting Code has been applied, the data itself in the rom is still present at these addresses only editing it no longer causes the change to occur.

If it were simply a matter of finding a new address and adding that new address, then that wouldn't be a problem. I haven't really gone through what you went through with the FIghting Code to fully understand how that works. But if there is a way to use these goal moving codes on roms that the Fighting Code was applied, that would be very good.

I don't know if this is something that could be amended with the Fighting Code to retain the use of such codes but something is currently blocking these codes from working on roms with Fighting Enabled. If you have any suggestions on how we might get these codes to work with Fighting it would be important. And I would be intersted to know if you think there are other codes in the rom that might be affected as a result of having Fighting.

I wonder if, for example, I made some edits to these goal movement codes to a rom, putting the goal parts in a unique position, and then applied the Fighting Code, if the new arrangement would be retained or if it would revert back to the original placement. Only one way to find out.

2 hours ago, Brodeur30 said:

I haven't applied the Fighting Code to any roms myself but in trying to test these codes on roms that have, I have encountered the issue of not being able to use these codes on those roms. I guess I'm just trying to understand how moving the frame data might limit the use of other codes that utilize this area. But I would stress that in the roms that the Fighting Code has been applied, the data itself in the rom is still present at these addresses only editing it no longer causes the change to occur.

If it were simply a matter of finding a new address and adding that new address, then that wouldn't be a problem. I haven't really gone through what you went through with the FIghting Code to fully understand how that works. But if there is a way to use these goal moving codes on roms that the Fighting Code was applied, that would be very good.

I don't know if this is something that could be amended with the Fighting Code to retain the use of such codes but something is currently blocking these codes from working on roms with Fighting Enabled. If you have any suggestions on how we might get these codes to work with Fighting it would be important. And I would be intersted to know if you think there are other codes in the rom that might be affected as a result of having Fighting.

I wonder if, for example, I made some edits to these goal movement codes to a rom, putting the goal parts in a unique position, and then applied the Fighting Code, if the new arrangement would be retained or if it would revert back to the original placement. Only one way to find out.

If you make the changes to the goal frame data before applying the fighting patch on a custom ROM, it would maintain the changes.

All of the associated data with sprites and frames is organized like so in the regular ROM:

$5B1C-$76B2 - SPAList - Sprite Animation List: A table for each animation listing frames and the time to display the frame.

$5DE7A - Offset List:

1st long word (4 bytes long) - Offset to default sprite tile palette (128 bytes long) before frame data (default ROM has this offset as $4082A)

2nd long word (4 bytes long) - Offset to frame data (default ROM has this offset as $408AA)

$5DE82 (2 byes long) - # of Sprite Tiles (default set to $2041 tiles, which means the Sprite Tiles data is $40820 in size, since $2041 * 32 bytes/tile)

Sprite Tiles ($5DE84-$9E724): Exactly what it says. Sprites can be 1x1 tiles up to 4x4 (only 4x4 sprite is the glass breaking if I remember correctly). Also included in these are the goal tiles, the arrows, the stars.

Frame Sprite Data Offsets ($9E724-$9EDC2): This is a table of offsets. Each frame has an offset to its frame data. For example, frame 1, which is "Skating with the puck" frame, has an offset of $69E. $9E724+$69E = $9EDC2, which would be the where the frame data starts for frame 1. We can tell how many sprites each frame has by subtracting this offset from the next one in the list. In this example, the next offset is $6A6. $696-$69E = 8 bytes, which means there is 1 sprite in the frame (see next section). There are 845 frames in NHL94.

Sprite Data ($9EDC2-A44C9): $5708 long (There are 2,785 total sprites)

This is the data you are editing as it will point to the sprite tiles and position them in the frame.

 Offset 0-1: X Global. The X position of the upper left corner of the sprite in the frame. This is offset from the 0,0 point of the frame.
 Offset 2-3: Y Global. Same as above, in Y.
 Offset 4-5: Tile offset. Confusing, see link.
 Offset 6  : Palette stuff and default H/V flip.
 Offset 7  : Sizetab byte (# of tiles in the sprite) 

Hotlist table ($A44CA-$A4B54): 2 bytes for each frame, 1 for X and 1 for Y. Offset from the 0,0 point of the frame, it is used for collision purposes (like the player's stick which is a separate collision point from their body). There are 16 bytes missing from the end of this table. These are because the last 8 frames are direction arrows and stars for the 3rd and 4th player when 4-way is used. They don't have collision, so they were omitted (there's only data for 837 frames).

Since this data is so tightly packed and one after another, the SPAList, Frame Sprite Data offsets, Sprite Data, and Hotlist table get moved to new free space, since data needs to be added to all those tables for the fight frames. The sprite tiles stay put (for now), and I just add the fight sprite tiles to the end of it, overwriting some of the frame sprite data offset table. I was going to just pad the rest of it with FF, probably should. I also update the Offset List and the # of Sprite Tiles. So even though the data you are looking for is still there, it is not being used.

Check out my post where I dissect a frame and reassemble it for more info - https://forum.nhl94.com/index.php?/topic/37002-sprites-frames-and-animations/

I challenge you to follow the procedure to find the new location of the sprite data for the goal!

The top goal is frame # 405, bottom goal is frame # 406.

Frame Sprite Data Offset table starts at $202830.

I'm thrilled to report, that with help from chaos, that these codes can be found and edited successfully in roms with Fighting. Apparantly what happens is that the area that these codes exist get duplicated to another area of the rom, and it's there that you can make successful edits.

For example, the First Code, For the Top Net : Top Left quadrant X-position, the 2-byte code FFE8 that is found at 0xA16BA on non-patched roms, can be found at 0x2057F6 in a Fighting patched rom. This is a very important discovery for anyone interested in using these codes on a Fighting Patched Rom.