Mike Tyson's Punch-Out!! (NES) SS and ILs (SS WR

2014-08-08 12:29:08 pm

General Kong - Bullets and Bananas

Quote from sinister1:

I randomly got a new SS record of 16:27.54.

Luck was incredible, but I am a bit rusty in this category so I made some silly mistakes. Oh well, still a pretty good run.

Sinister has that 1-2 that's sick like the flu...

zallard1

2014-08-13 03:38:12 am

B+Left, Left, Up+B, ★

Did about a half hour of offline attempts before going to sleep and got this fight.

Unfortunately I got one random star too many, which wastes a tiny bit of time and made Macho round my time up an entire second again. I took an extra risk because of my old fight, so I assumed he would stop at 3 spins in phase 3 and quick dodged the 3rd for enough time to where I cut the 50.

Deuceler

2014-08-13 09:37:27 am

SPEEDruns not SAFEruns

Behind the ball here, but congrats to Sinister1 !!!! Awesome stuff man! Also, Zallard - get after it

zallard1

Edit history:

zallard1: 2014-08-18 02:17:29 am

2014-08-18 12:14:12 am

B+Left, Left, Up+B, ★

Quote from Deuceler:

Zallard - get after it

Got it.

http://www.twitch.tv/zallard1/c/4930366

This is one of the strongest Punch Out IL's I've ever done. I even streamed it to boot! Volume warning at the end... the time kind of shocked me... haha

EDIT: Youtube encode incase you don't like Twitch vod's.

Omnigamer

Edit history:

Omnigamer: 2014-08-18 10:44:47 pm

Omnigamer: 2014-08-18 04:03:07 pm

Omnigamer: 2014-08-18 04:01:13 pm

2014-08-18 03:01:53 pm

All the things

Come one, come all, it's time for a story about everybody's favorite friend and enemy: the MTPO timer.

TECHNICAL DETAILS
The timer follows a pretty straightforward process, parts of which were already pretty well understood, others not so much. Every time the clock increments, it first checks whether a match has actually started ($0300), then checks if the clock is stopped ($0301). Bugs with how the clock is started/stopped is what triggers the clock stop glitch. Anyway, if both of those values are set to 1, the clock is running.

Let's next look at how the game tracks its own time. Each frame the clock is running it increments its hundredths counter ($0306) by a specified rate constant ($0308). If the hundredths counter is equal to or greater than 100, then it subtracts 100 from it and increments the seconds counter. Simple enough, right? The tricky part is that it also has a rate modifier ($0307) that is also always going and has its own constant ($0309). This rate modifier can be regarded as an occasional +1 to the rate every time it overflows. To put it into some pseudocode:

Code:

rateMod = rateMod + rateModConst

if( rateMod >=256 )
{
    rateMod = rateMod-256;
    hund = hund + rate + 1;
}
else
{
    hund = hund + rate;
}

if( hund >=100)
{
    hund = hund - 100;
    seconds = seconds + 1;
}

EDIT: I realized later on that it's easier to interpret these numbers as a single 16-bit number instead of two 8-bit numbers.

OK, so that's all good. What about converting the hundredths into the actual time displayed after the match?

When the clock is stopped after the last hit, it holds on to the hundredths value for displaying the resulting time. Specifically, it takes the top nibble of the hundredths and shifts it right by 3 to use as an index into a table at $01/BCB0. This table has exactly 14 values that can be accessed this way, which correspond to pairs of the upper and lower digits of the hundredths displayed on-screen.

RATE CONVERSION AND OTHER MATH
Now comes the tricky part: figuring out the math behind the actual rates. I have not been able to test every fight, but all of the circuit openers have the same constants: a rate of 4 and a rate mod of -7. The -7 makes things really ugly since it doesn't match up well in terms of multiples. In any case, this makes it such that most seconds take 20 frames but every 9th second takes 21 frames; the first second takes 21 frames. The 100th second (1'40") is 20 frames, however, but after that the cycle repeats. This makes a mess of things when trying to figure out a constant number of frames for each possible displayed hundredth value; the closest answer for these rate constants is "a little more than 3." All possible values are possible for either 3 or 4 frames, with a bias towards 3. The exception is .99, which can only ever have 1 frame or none at all. An example of this is 35.99 Von Kaiser; this time is simply not possible with how the timer works.

It's relatively simple to convert the number of frames the clock has been active to the resulting time so long as you have the constants. That's not helpful though; we have no indication of the actual number of frames the clock was active. Going backwards from a mathematical perspective is yucky, so instead we can precalculate a table of all possible times and just search that table. I set this up in an Excel spreadsheet for ease of use; just put in the achieved time and it will tell you the range of frames it was possible to finish on. Once we can confirm rate constants for every fight I can finish it off and make an actual full SS list of fighters based on their particular constants, but for now it just works off of the most common rate constants.

That said, the times given by the win screen are fundamentally flawed when summing across all fights. The numbers are too high relative to their probability of occurrance, so the mean is skewed to .54 as a result. Across all 14 fights this adds up to about half a second on average. It's not much, but it's not insignificant either. You can see this in the attached plot. Instead, for end timing purposes I propose using a different set of hundredths to fix the distribution. The new distribution is the blue line on the chart. This new distribution is based on the probability of appearance for different numbers and has a mean of exactly .50. The distribution is instead: .00, .19, .38, .58, .77, .96, .99 . Just match them up to the prior order. Do I recommend tracking this on-stream? No way! You'll confuse the hell out of viewers. It (or a fairly similar distribution) should be used for final timing purposes though in the case of submissions or direct comparisons. Also note that this does not affect ILs at all other than knowing an approximate frame range for your times; it's only when aggregating multiple values that the bias skews the results.

All that I've said so far is true for the most common rate constants, but there's at least one fight that uses a different set of constants: Super Macho Man. I didn't write down his rates last night, but his round 1 clock is significantly slower than the normal set. I will make a different set of times for him after I get home. That said, you MTPO pros can help! Just fire up an emulator and watch address $0309 when you start a fight. If it is F9 (-7), it's the regular rate. If it's something different, please tell me! I will calculate the appropriate tables. Some other misc notes: the rates are different for each individual round, with round 2 being faster than round 1, and round 3 being faster yet. I have not bothered to calculate out those tables because, well, they don't matter as much. If you'd like me to calculate those out as well for score purposes etc, let me know.

WHAT DOES IT MEAN?

So far this is just a description of what happens with the clock; the real question is how do we make use of this?

The first obvious point is what I've mentioned a couple of times: you can directly convert your resulting time to a small range of frames for how long the clock was active. Having a complete listing of how long each time is available also means that you can figure out the exact frame you finished on NTSC video by using certain cues to help you know when the clock actually finished and comparing to the last time the seconds counter updated. This isn't perfectly accurate because of discrepancies between NTSC video timing and NES operating frequency so there's a chance a frame can be decimated during that timeframe, but this is relatively unlikely. In any case, by playing back video you can determine a true frame count of the clock to a 2-frame range. This depends on no clock-stopping activity occurring within that last second though, which may not be possible for some fights. This has one other big implication as well...

Mike Tyson fights can now be timed to the appropriate in-game hundredths. Yes, Mike Tyson conforms to the normal rates and as such his frame count can be narrowed down by playing back video. The same note I made about NTSC video conversion still applies, however, so the range may be just accurate to 2 frames. That said, I have not experimented with the fight enough to actually see how his clock stopping activity works. The TAS at least can just watch that memory address and convert it to the appropriate time.

Whew. I think there are a few more implications but I've forgotten them for now.

Summary:
-Clock is predictable, can be converted.
-Clock moves at different rates for some fights, and changes for each round.
-Most possible hundredths values are available for only 3 or 4 frames. .99 is only possible for 1 frame or not at all.
-A different distribution can prevent skewing end time for SS.
-Mike Tyson can be timed to appropriate in-game time by watching back video.

I welcome any criticisms or otherwise. I can provide the timer subroutine if anybody's curious as well. There's some room to play with the adjusted distribution yet since it only has a weak basis; if anybody wants to math it further, I'd be happy to describe how I came up with the values and other relevant information.

EDIT: After some thinking, it occurs to me that the the combination of values is just one 16-bit number rather than two distinct 8-bit numbers. D'oh. This probably simplifies some math... I'll re-work the spreadsheets later.

Also, the remainder of the fight constants are below:

Glass Joe: 04F9
Von Kaiser: 04F9
Honda 1: 04F9
Don 1: 04F9
Hippo: 04F9
Tiger: 04F9
Bull 1: 0443
Honda 2: 04F9
Soda: 05F8
Bull 2: 04F9
Don 2: 05F8
Sandman: 03BA
Super Macho Man: 0443
Mike Tyson: 04F9

Updated/complete spreadsheets coming soon.

Come one, come all, it's time for a story about everybody's favorite friend and enemy: the MTPO timer.

[b]TECHNICAL DETAILS[/b]
The timer follows a pretty straightforward process, parts of which were already pretty well understood, others not so much. Every time the clock increments, it first checks whether a match has actually started ($0300), then checks if the clock is stopped ($0301). Bugs with how the clock is started/stopped is what triggers the clock stop glitch. Anyway, if both of those values are set to 1, the clock is running.

Let's next look at how the game tracks its own time. Each frame the clock is running it increments its hundredths counter ($0306) by a specified rate constant ($0308). If the hundredths counter is equal to or greater than 100, then it subtracts 100 from it and increments the seconds counter. Simple enough, right? The tricky part is that it also has a rate modifier ($0307) that is also always going and has its own constant ($0309). This rate modifier can be regarded as an occasional +1 to the rate every time it overflows. To put it into some pseudocode:

[code]
rateMod = rateMod + rateModConst

if( rateMod >=256 )
{
    rateMod = rateMod-256;
    hund = hund + rate + 1;
}
else
{
    hund = hund + rate;
}

if( hund >=100)
{
    hund = hund - 100;
    seconds = seconds + 1;
}
[/code]

EDIT: I realized later on that it's easier to interpret these numbers as a single 16-bit number instead of two 8-bit numbers.

OK, so that's all good. What about converting the hundredths into the actual time displayed after the match?

When the clock is stopped after the last hit, it holds on to the hundredths value for displaying the resulting time. Specifically, it takes the top nibble of the hundredths and shifts it right by 3 to use as an index into a table at $01/BCB0. This table has exactly 14 values that can be accessed this way, which correspond to pairs of the upper and lower digits of the hundredths displayed on-screen.

[b]RATE CONVERSION AND OTHER MATH[/b]
Now comes the tricky part: figuring out the math behind the actual rates. I have not been able to test every fight, but all of the circuit openers have the same constants: a rate of 4 and a rate mod of -7. The -7 makes things really ugly since it doesn't match up well in terms of multiples. In any case, this makes it such that most seconds take 20 frames but every 9th second takes 21 frames; the first second takes 21 frames. The 100th second (1'40") is 20 frames, however, but after that the cycle repeats. This makes a mess of things when trying to figure out a constant number of frames for each possible displayed hundredth value; the closest answer for these rate constants is "a little more than 3." All possible values are  possible for either 3 or 4 frames, with a bias towards 3. The exception is .99, which can only ever have 1 frame or none at all. An example of this is 35.99 Von Kaiser; this time is simply not possible with how the timer works.

It's relatively simple to convert the number of frames the clock has been active to the resulting time so long as you have the constants. That's not helpful though; we have no indication of the actual number of frames the clock was active. Going backwards from a mathematical perspective is yucky, so instead we can precalculate a table of all possible times and just search that table. I set this up in an Excel spreadsheet for ease of use; just put in the achieved time and it will tell you the range of frames it was possible to finish on. Once we can confirm rate constants for every fight I can finish it off and make an actual full SS list of fighters based on their particular constants, but for now it just works off of the most common rate constants.

That said, the times given by the win screen are fundamentally flawed when summing across all fights. The numbers are too high relative to their probability of occurrance, so the mean is skewed to .54 as a result. Across all 14 fights this adds up to about half a second on average. It's not much, but it's not insignificant either. You can see this in the attached plot. Instead, for end timing purposes I propose using a different set of hundredths to fix the distribution. The new distribution is the blue line on the chart. This new distribution is based on the probability of appearance for different numbers and has a mean of exactly .50. The distribution is instead: .00, .19, .38, .58, .77, .96, .99 . Just match them up to the prior order. Do I recommend tracking this on-stream? [b]No way! You'll confuse the hell out of viewers.[/b] It (or a fairly similar distribution) should be used for final timing purposes though in the case of submissions or direct comparisons. Also note that this does not affect ILs at all other than knowing an approximate frame range for your times; it's only when aggregating multiple values that the bias skews the results.

All that I've said so far is true for the most common rate constants, but there's at least one fight that uses a different set of constants: Super Macho Man. I didn't write down his rates last night, but his round 1 clock is significantly slower than the normal set. I will make a different set of times for him after I get home. That said, you MTPO pros can help! Just fire up an emulator and watch address $0309 when you start a fight. If it is F9 (-7), it's the regular rate. If it's something different, please tell me! I will calculate the appropriate tables. Some other misc notes: the rates are different for each individual round, with round 2 being faster than round 1, and round 3 being faster yet. I have not bothered to calculate out those tables because, well, they don't matter as much. If you'd like me to calculate those out as well for score purposes etc, let me know.

[b]WHAT DOES IT MEAN?[/b]

So far this is just a description of what happens with the clock; the real question is how do we make use of this?

The first obvious point is what I've mentioned a couple of times: you can directly convert your resulting time to a small range of frames for how long the clock was active. Having a complete listing of how long each time is available also means that you can figure out the exact frame you finished on NTSC video by using certain cues to help you know when the clock actually finished and comparing to the last time the seconds counter updated. This isn't perfectly accurate because of discrepancies between NTSC video timing and NES operating frequency so there's a chance a frame can be decimated during that timeframe, but this is relatively unlikely. In any case, by playing back video you can determine a true frame count of the clock to a 2-frame range. This depends on no clock-stopping activity occurring within that last second though, which may not be possible for some fights. This has one other big implication as well...

[b]Mike Tyson fights can now be timed to the appropriate in-game hundredths.[/b] Yes, Mike Tyson conforms to the normal rates and as such his frame count can be narrowed down by playing back video. The same note I made about NTSC video conversion still applies, however, so the range may be just accurate to 2 frames. That said, I have not experimented with the fight enough to actually see how his clock stopping activity works. The TAS at least can just watch that memory address and convert it to the appropriate time.

Whew. I think there are a few more implications but I've forgotten them for now.

Summary:
-Clock is predictable, can be converted.
-Clock moves at different rates for some fights, and changes for each round.
-Most possible hundredths values are available for only 3 or 4 frames. .99 is only possible for 1 frame or not at all.
-A different distribution can prevent skewing end time for SS.
-Mike Tyson can be timed to appropriate in-game time by watching back video.

I welcome any criticisms or otherwise. I can provide the timer subroutine if anybody's curious as well. There's some room to play with the adjusted distribution yet since it only has a weak basis; if anybody wants to math it further, I'd be happy to describe how I came up with the values and other relevant information.

EDIT: After some thinking, it occurs to me that the the combination of values is just one 16-bit number rather than two distinct 8-bit numbers. D'oh. This probably simplifies some math... I'll re-work the spreadsheets later.

Also, the remainder of the fight constants are below:

Glass Joe: 04F9
Von Kaiser: 04F9
Honda 1: 04F9
Don 1: 04F9
Hippo: 04F9
Tiger: 04F9
Bull 1: 0443
Honda 2: 04F9
Soda: 05F8
Bull 2: 04F9
Don 2: 05F8
Sandman: 03BA
Super Macho Man: 0443
Mike Tyson: 04F9

Updated/complete spreadsheets coming soon.

Omnigamer

Edit history:

Omnigamer: 2014-08-18 06:06:01 pm

2014-08-18 03:07:35 pm

All the things

Attachments for real this time.

EDIT: Removed old Excel doc, see new one below.

Attachment:

mtpo.PNG

Omnigamer

2014-08-18 06:11:56 pm

All the things

New Excel document attached.

The things you want to use this one for:

-Time Check: Enter your time for any fight and see how many frames it has.
-SS Entry: Enter your SS times and it will show both the original raw sum and the adjusted sum.
-Tyson Finder: Enter your Tyson time and get a list of valid frames and their corresponding count from when the clock stops.

Feel free to pretty it up however you'd like.

Attachment:

mtpo.xlsx

andrewg

Edit history:

andrewg: 2014-08-18 08:12:39 pm

andrewg: 2014-08-18 08:12:18 pm

2014-08-18 08:09:50 pm

Hi! I'm andrewg!

I feel that fight strategy could possibly change if everyone were to adapt a new timing scheme. I feel the game timer is a good timer to use, even in a SS setting. The end differences are very minimal really.

I look at Super Mario Bros as it's a game I know. We use real time for that, but it's flawed in a sense because the game rounds depending on the frame you end a level. One could add up all the frame lengths per level together for a better time measurement, but we've always gone by real time. This case is the opposite. We've always measured by in-game time, so to start measuring it by real time just doesn't seem right. I've had runs of Super Mario Bros that had faster in-game stages, but the rounding of my time is slower by real time. But I don't think the timing should change (even when it is technically flawed).

That is my opinion in the "official" stance of the timing on this game. However, this is a great resource for many reasons.

- Knowing the Mike Tyson decimal would be very cool, and I like the idea of tracking it somehow if it could definitely be known.

- If there was accidental stop clock glitch in a SS run, it seems analysing the fight could work to possibly remedy this kind of possible situation. I feel like doing stop clock glitch in a run shouldn't automatically disqualify the run for something that a runner could easily do by accident. It would be nice to somehow determine an appropriate time here.

- This is very good reference to how fast people are actually doing fights.

- Zallard, you are insane.

I feel that fight strategy could possibly change if everyone were to adapt a new timing scheme. I feel the game timer is a good timer to use, even in a SS setting. The end differences are very minimal really.

I look at Super Mario Bros as it's a game I know. We use real time for that, but it's flawed in a sense because the game rounds depending on the frame you end a level. One could add up all the frame lengths per level together for a better time measurement, but we've always gone by real time. This case is the opposite. We've always measured by in-game time, so to start measuring it by real time just doesn't seem right. I've had runs of Super Mario Bros that had faster in-game stages, but the rounding of my time is slower by real time. But I don't think the timing should change (even when it is technically flawed).

That is my opinion in the "official" stance of the timing on this game. However, this is a great resource for many reasons.

- Knowing the Mike Tyson decimal would be very cool, and I like the idea of tracking it somehow if it could definitely be known.

- If there was accidental stop clock glitch in a SS run, it seems analysing the fight could work to possibly remedy this kind of possible situation. I feel like doing stop clock glitch in a run shouldn't automatically disqualify the run for something that a runner could easily do by accident. It would be nice to somehow determine an appropriate time here.

- This is very good reference to how fast people are actually doing fights.

- Zallard, you are insane.

Omnigamer

Edit history:

Omnigamer: 2014-08-18 08:25:54 pm

2014-08-18 08:25:01 pm

All the things

Quote from andrewg:

I look at Super Mario Bros as it's a game I know. We use real time for that, but it's flawed in a sense because the game rounds depending on the frame you end a level. One could add up all the frame lengths per level together for a better time measurement, but we've always gone by real time. This case is the opposite. We've always measured by in-game time, so to start measuring it by real time just doesn't seem right. I've had runs of Super Mario Bros that had faster in-game stages, but the rounding of my time is slower by real time. But I don't think the timing should change (even when it is technically flawed).

So this is something that I've had multiple people misunderstand me on, so I want to be clear: nothing of what I mentioned above is different from game time. It is all still game time, real time is not a factor anywhere. What I'm referring to with changes to distribution is solely for the purposes of comparison of close SS runs. It is simply changing the hundredths values given by the game to slightly lower ones that do not skew results (as much). The end result is supposed to be a more accurate total sum of the time that is not affected by an improper distribution.

[quote="andrewg"]
I look at Super Mario Bros as it's a game I know. We use real time for that, but it's flawed in a sense because the game rounds depending on the frame you end a level. One could add up all the frame lengths per level together for a better time measurement, but we've always gone by real time. This case is the opposite. We've always measured by in-game time, so to start measuring it by real time just doesn't seem right. I've had runs of Super Mario Bros that had faster in-game stages, but the rounding of my time is slower by real time. But I don't think the timing should change (even when it is technically flawed).
[/quote]

So this is something that I've had multiple people misunderstand me on, so I want to be clear: nothing of what I mentioned above is different from game time. It is all still game time, real time is not a factor anywhere. What I'm referring to with changes to distribution is solely for the purposes of comparison of close SS runs. It is simply changing the hundredths values given by the game to slightly lower ones that do not skew results (as much). The end result is supposed to be a more accurate total sum of the time that is not affected by an improper distribution.

sinister1

2014-08-18 10:42:26 pm

sinister1

so pro u don't even know

Very quick of you Omni, I am impressed. I will look this over when I have some time and hopefully Adelikat and McHazard can chime in as well.

Omnigamer

2014-08-21 08:37:51 pm

All the things

To clarify a bit more: the conversion to a "number of frames" is only for reference and I am not suggesting that the frame count actually be used in place of the given time. It's more of a curiosity item; you can know that the relative frame range is for the end time you achieved (ie, did I have 3 frames to hit this time, or 4?). Some of the other things being brought up are issues with the clock stop itself. The clock stops for very minor things now and again, but at least from what I've seen it's consistent. The clock is stopped for 2 frames every time you hit somebody in stun, and the uppercut stops the clock for a consistent number of frames. It seems like it's based on some index ($04C9) sourced from an animation variable, but I'm not sure on that. The point is that it's pretty consistent though. You should be able to tell when the clock is or is not stopped. Either way though, it doesn't matter since the end time is still the same. Knowing when the clock is or is not stopped does not help you, since you're still optimizing for final game time.

My comments in regard to Tyson are much the same. The finder is just meant to identify find the appropriate range and corresponding hundredths according to video playback. I will work on some video examples soon.

To clarify a bit more: the conversion to a "number of frames" is only for reference and I am not suggesting that the frame count actually be used in place of the given time. It's more of a curiosity item; you can know that the relative frame range is for the end time you achieved (ie, did I have 3 frames to hit this time, or 4?). Some of the other things being brought up are issues with the clock stop itself. The clock stops for very minor things now and again, but at least from what I've seen it's consistent. The clock is stopped for 2 frames every time you hit somebody in stun, and the uppercut stops the clock for a consistent number of frames. It seems like it's based on some index ($04C9) sourced from an animation variable, but I'm not sure on that. The point is that it's pretty consistent though. You should be able to tell when the clock is or is not stopped. Either way though, it doesn't matter since the end time is still the same. Knowing when the clock is or is not stopped does not help you, since you're still optimizing for final game time.

My comments in regard to Tyson are much the same. The finder is just meant to identify find the appropriate range and corresponding hundredths according to video playback. I will work on some video examples soon.

andrewg

Edit history:

andrewg: 2014-08-21 10:19:19 pm

andrewg: 2014-08-21 10:12:24 pm

2014-08-21 10:11:42 pm

Hi! I'm andrewg!

Sorry if what I said came out the wrong way.

It's really cool/interesting and I'm curious about your findings. Smiley

I'm pretty sure I was just in a bad mood with my last post.

Also, I've decided to give up SS even though I've nearly learned the whole game (sorry guys!). Basically, I'm not sure why I don't want to do SS; I guess I'm much more interested in doing ILs to be completely honest.

KHANanaphone

2014-08-21 10:29:46 pm

Fiiive

Personally, I think we should just require that all Tyson fights be played in "Another World Circuit" mode, because it displays the accurate time after the fight.

(Tee hee)

sinister1

2014-08-21 10:30:24 pm

sinister1

so pro u don't even know

Frame(s) away from WR, Tyson down at 2:14.xx

@Omnigamer: Please let me know the decimals on this one even though I am pretty sure it is 00 Sad

@Khananaphone: Please don't make me hurt you.

andrewg

Edit history:

andrewg: 2014-08-21 10:32:52 pm

2014-08-21 10:31:28 pm

Hi! I'm andrewg!

Wow, nice job sinister!!!

There's a way to display Mike Tyson decimals? I'm referring to Khananaphone's post.

zallard1

2014-08-21 10:40:27 pm

B+Left, Left, Up+B, ★

Quote from andrewg:

I guess I'm much more interested in doing ILs to be completely honest.

If that's the case, then please help us with Soda Popinski! The fight is going to be luck intensive and the execution won't be that bad. It is possible to beat Turk's Soda time if you get the zero delay from Soda all 3 times and you don't get excessive stars, which will be pretty rough. Also just throwing this out there, but Khananaphone, Soda would probably also be within your reach since the strategy mostly assumes certain luck from him instead of needing to react to things.

Also grats to sin the 2:14 Tyson fight! The record is sooo close now, I can't wait for the inevitable 2:12 or lower!

Omnigamer

Edit history:

Omnigamer: 2014-08-21 11:06:45 pm

Omnigamer: 2014-08-21 11:05:22 pm

Omnigamer: 2014-08-21 11:05:12 pm

2014-08-21 11:04:24 pm

All the things

Sinister: I can't be too precise since your stream recording is 30 fps, but you were either 4 or 5 frames off from 2:13. So you actually probably have .25. The clock stops the frame before Tyson's head reels back, which is also the exact video frame the clock transitioned to 14 for you. The problem, however, is that it takes about 3 frames for the PPU to update the clock on screen after the memory address is set to it. This means that in some cases (typically for .00s) you will actually have stopped the clock with the final punch but you'll see the timer update afterwards anyway. I will spend some time looking into this specifically since it mucks with the Tyson side of things, but basic testing says the timer update is 3 frames behind when the memory value transitions.

Congratulations either way! Any improvement on this IL is huge!

KHANanaphone

2014-08-22 12:23:38 am

Fiiive

Quote from andrewg:

Wow, nice job sinister!!!

There's a way to display Mike Tyson decimals? I'm referring to Khananaphone's post.

Yeah, if you play through using the Another World Circuit code, it'll show the decimal after you beat Tyson (a.k.a. "ANOTHER MCHAMPIONN")

Also maaan that was close Sinister. Nice job!

Omnigamer

2014-08-22 09:17:27 am

All the things

I looked into the delay between transition and updating a bit more, but I can't find anything conclusive. The main thing is that I don't have a good understanding of how the PPU interacts with its memory as far as updating the number, and at worst it is dependent on the relative load it has for updating everything else on the screen. I did notice some mild consistency on the number of frames required to update a given number though; for example, updating to 4 typically takes 2 frames, updating to 5 takes 3, while updating to 6 occurs same frame. That said, there's a pretty wild swing to it. I saw 6 update same frame 4 times in a row, but on the 5th time it took 7 frames (also happened to coincide with a Sandman attack). I'd like to think it's more consistent for the final hits of a match since movement will typically be the same, but I can't confirm without more tests. A possible reason for the general consistency on given number transitions are cycles in the audience or fighter stances. For example, since a "second" is typically 20 frames long, an arbitrary audience cycle of 60 frames would occur every third second and create extra delay for the processor. I will read through some more documentation on the PPU until I figure out some better reasoning.

This also explains why you are weary of the timer, Sinister. The underlying actual timer in memory is consistent and stable, however due to variance in the update frequency of the on-screen timer it can appear very inconsistent with some seconds being arbitrarily long or short. Unfortunately this makes it a fair bit more difficult to time Tyson, but I will think of a few cues or methods to try to even up timing.

I looked into the delay between transition and updating a bit more, but I can't find anything conclusive. The main thing is that I don't have a good understanding of how the PPU interacts with its memory as far as updating the number, and at worst it is dependent on the relative load it has for updating everything else on the screen. I did notice some mild consistency on the number of frames required to update a given number though; for example, updating to 4 typically takes 2 frames, updating to 5 takes 3, while updating to 6 occurs same frame. That said, there's a pretty wild swing to it. I saw 6 update same frame 4 times in a row, but on the 5th time it took 7 frames (also happened to coincide with a Sandman attack). I'd like to think it's more consistent for the final hits of a match since movement will typically be the same, but I can't confirm without more tests. A possible reason for the general consistency on given number transitions are cycles in the audience or fighter stances. For example, since a "second" is typically 20 frames long, an arbitrary audience cycle of 60 frames would occur every third second and create extra delay for the processor. I will read through some more documentation on the PPU until I figure out some better reasoning.

This also explains why you are weary of the timer, Sinister. The underlying actual timer in memory is consistent and stable, however due to variance in the update frequency of the on-screen timer it can appear very inconsistent with some seconds being arbitrarily long or short. Unfortunately this makes it a fair bit more difficult to time Tyson, but I will think of a few cues or methods to try to even up timing.

andrewg

Edit history:

andrewg: 2014-08-26 11:04:14 am

2014-08-26 10:04:16 am

Hi! I'm andrewg!

A really noob question...you do have to beat Honda 2 before doing Soda, right? I mean there's no password to just face Soda Popinski?

EDIT: Also, I can't manage the Soda fight because I dont get it.

sinister1

2014-08-26 11:22:45 am

sinister1

so pro u don't even know

Quote from andrewg:

A really noob question...you do have to beat Honda 2 before doing Soda, right? I mean there's no password to just face Soda Popinski?

EDIT: Also, I can't manage the Soda fight because I dont get it.

If you are just practicing then you can use game genie to go directly to Soda or any other fight. When doing SDA attempts you have to fight Honda 2 first. If you have Powerpak that would also work since you can use game genie codes there. I think Zallard posted about the Soda fight in our PM. It is not easy.

Deuceler

2014-08-28 10:19:39 am

SPEEDruns not SAFEruns

Awesome stuff Omni, and great work Sin! Gotta TKO Turk once and for all!

Omnigamer

2014-08-29 11:17:52 am

All the things

I started to develop a new Tyson finder based on prominent visual cues that are consistent, however I'd like some help in simplifying things. The last major piece to a simple conversion scheme is knowledge about the downs themselves; from what I understand, Tyson can get up on random counts. What I need to know beyond that is whether the same count has any variation to it, ie does a "2 count" always take 561 frames, or can it take, for example, 570? If it's consistent then I can make a tool that just takes the count and converts it to the actual in-game frames. The current version of the tool instead relies on entering the frame number of certain visual cues, but this is prone to some error due to NTSC video frame conversion. In any case, Tyson decimals are on the way.

Omnigamer

Edit history:

Omnigamer: 2014-08-29 03:18:17 pm

2014-08-29 03:17:47 pm

All the things

New Tyson Finder attached. It starts off with the information filled in according to Sinister's latest 2:14, so you can use that as an example. Getting the video frames is at least a little annoying, but you only have to find the start and finish frames now at least. I can do a quick tutorial on how to do it with Media Player Classic or VLC if desired. In any case, the gist is that you fill in information about all the events that cause the clock to stop, namely downs and stuns. Downs are consistent; you can take 483 frames as a base number and add 39 frames to that for every number of the count (including on 1). The only oddity is when Tyson tries to get back up but falls again, which costs an additional 112 frames. Stuns are any situation where Tyson pauses with his mouth open for a second hit. Each one of these stops the clock for 6 frames. In any case, I convert the video frames to actual game frames and do calculations from that. Because there's some uncertainty about frame decimation by the capture card and/or capture software, I can only narrow it down to two frames with some degree of probability between the two. This probability is displayed, and possible time values are highlighted. It hopefully won't be an issue for most runs, but if something happens to be on the bubble then some additional analysis may be required. Instructions are also in the spreadsheet. Let me know if you have other questions or corrections.

Oh, and in case you can't check, the 2:14 is pretty solidly a .00

New Tyson Finder attached. It starts off with the information filled in according to Sinister's latest 2:14, so you can use that as an example. Getting the video frames is at least a little annoying, but you only have to find the start and finish frames now at least. I can do a quick tutorial on how to do it with Media Player Classic or VLC if desired. In any case, the gist is that you fill in information about all the events that cause the clock to stop, namely downs and stuns. Downs are consistent; you can take 483 frames as a base number and add 39 frames to that for every number of the count (including on 1). The only oddity is when Tyson tries to get back up but falls again, which costs an additional 112 frames. Stuns are any situation where Tyson pauses with his mouth open for a second hit. Each one of these stops the clock for 6 frames. In any case, I convert the video frames to actual game frames and do calculations from that. Because there's some uncertainty about frame decimation by the capture card and/or capture software, I can only narrow it down to two frames with some degree of probability between the two. This probability is displayed, and possible time values are highlighted. It hopefully won't be an issue for most runs, but if something happens to be on the bubble then some additional analysis may be required. Instructions are also in the spreadsheet. Let me know if you have other questions or corrections.

Oh, and in case you can't check, the 2:14 is pretty solidly a .00

Attachment:

mtpo.xlsx

zallard1

2014-08-29 04:31:58 pm

B+Left, Left, Up+B, ★

Tyson finder works great! It is 100% certain that my PB is a 2:16.82, which is right around where I was guessing it would be (82 or 97).