Experienced Forum User, Published Author, Active player
(420)
Joined: 9/21/2009
Posts: 1047
Location: California
I think Mickey told me once that the J version isn't faster for a 0 Star run due to text or something. I've never personally verified this though.
Edit: Confirmed my sketchy memory:
[9:36:05 PM] Jeremiah (SP): Hi Mickey. Is the Japanese ROM faster than the U ROM for a 0 Star run?
[9:37:24 PM] Vis⇔SONY/MICKEY: No
[9:37:37 PM] Vis⇔SONY/MICKEY: USA version is faster than J ROM
[9:37:45 PM] Jeremiah (SP): Because of text speed?
[9:38:42 PM] Vis⇔SONY/MICKEY: Loading time is slower than U ROM. Of course, text speed is slower
Experienced Forum User, Published Author, Active player
(420)
Joined: 9/21/2009
Posts: 1047
Location: California
Kyman wrote:
sonicpacker wrote:
Kyman wrote:
DarkKobold wrote:
Kyman wrote:
Here is a temporary video of the improvement that I found... http://www.youtube.com/watch?v=Lu_Oe4SF7xU
This uses a GWK to save a wallkick and ends up saving 15 frames (so far) and as of right now, the final time would be 5:02.22.
So, you found nearly triple the number of frames that inspired this submission.
....
Only using 300 rerecords, and about 10 minutes of my time.
Without snark's new wall kicking strategy, this wouldn't have saved. ;)
I shouldn't of even pulled off that GWK in the first place, pure luck that I found it.
Not complaining though, anything closer to sub 5 is always good for me.
Hey bro, I feel the same way. I wasn't taking anything away from you. Just pointing out that it was a team effort! In fact, we'd like to include you as an author if you're okay with that.
Experienced Forum User, Published Author, Active player
(420)
Joined: 9/21/2009
Posts: 1047
Location: California
Kyman wrote:
DarkKobold wrote:
Kyman wrote:
Here is a temporary video of the improvement that I found... http://www.youtube.com/watch?v=Lu_Oe4SF7xU
This uses a GWK to save a wallkick and ends up saving 15 frames (so far) and as of right now, the final time would be 5:02.22.
So, you found nearly triple the number of frames that inspired this submission.
....
Only using 300 rerecords, and about 10 minutes of my time.
Without snark's new wall kicking strategy, this wouldn't have saved. ;)
Experienced Forum User, Published Author, Active player
(420)
Joined: 9/21/2009
Posts: 1047
Location: California
Kyman wrote:
...ends up saving 15 frames (so far)...
Explanation:
[17:47] <sonicpacker> i think this is improvable though
[17:47] <sonicpacker> not this part
[17:47] <sonicpacker> but
[17:47] <sonicpacker> snark purposely killed height so he could do that double wall kick
[17:47] <Kyman> yeah
Experienced Forum User, Published Author, Active player
(420)
Joined: 9/21/2009
Posts: 1047
Location: California
DarkKobold wrote:
At this rate, I'm thinking we should just leave SM64 on the workbench indefinitely.
(joking)
Haha, you never can tell with this game.
Anyway, for some reason, when I tried hex editing the new BitFS (20"87) onto the official .m64, it made the spiral stairs desync. I'm not exactly sure why, but instead of redoing it, I went ahead and used the spiral stairs input from the currently published run (I'm the one that TASed that part, so it's my input anyway). Since they tie each other, it doesn't really matter which is used. Here's the currently final .m64. The time is 5'02"716667, meaning 5'02"72. If someone with the power to do so could update the submission file, we'd appreciate it. I'll go ahead and update the submission text to match what we now have as well.
Experienced Forum User, Published Author, Active player
(420)
Joined: 9/21/2009
Posts: 1047
Location: California
SoulCal wrote:
sonicpacker wrote:
Mickey and I are trying to as I'm typing this. Oddly, the same thing happened in the first 0 Star I was involved with. I remember I had improved the spiral stairs section and hex edited it onto the existing .m64, and for some reason it lost a VI as well. I tried playing with the camera and other input, but nothing was working. I'm not really sure what causes this. There might be some weird frame rule, but we'll keep trying.
That lost VI may be a result of a hex editing error, but idk anything about Mupen TASing. Really the only way to confirm it is to create a new .m64 from the beginning and manually input all the commands until you see if that lost VI occurs, but that's a lot of work. :p
I already know it's not from hexing. It's simply a frame rule. There's no real way to save it except by losing time.
Experienced Forum User, Published Author, Active player
(420)
Joined: 9/21/2009
Posts: 1047
Location: California
Apparently Snark was able to combine one of my ideas to use a diving method after the pole part with his new wall kicking strategy and save ANOTHER frame. He's trying to save one more and also fixing the camera angles. I likely won't have an .m64 until late tonight (maybe 11PM - 12PM my time zone?), so the new YouTube encode needs delayed once again.
Mickey and I are trying to as I'm typing this. Oddly, the same thing happened in the first 0 Star I was involved with. I remember I had improved the spiral stairs section and hex edited it onto the existing .m64, and for some reason it lost a VI as well. I tried playing with the camera and other input, but nothing was working. I'm not really sure what causes this. There might be some weird frame rule, but we'll keep trying.
Experienced Forum User, Published Author, Active player
(420)
Joined: 9/21/2009
Posts: 1047
Location: California
sonicpacker wrote:
SoulCal wrote:
sonicpacker wrote:
Please wait for the improvements to be updated to the submission. Thanks! =)
I saw your FML post; how much of an improvement is that?
I'm not actually sure because Snark timed it differently than normal, but I *think* 5 frames. I'll get the .m64 and make sure when Mickey gets on his computer.
Okay, I'm a complete idiot. Snark did time correctly and I was just thinking there was no way the improvement would be that much...but now I have the .m64 and it turns out he saved 2 more frames since his YouTube video. This means that his new BitFS saves 28 frames total over the currently published 0 Star run. This run will have a final time of 5'02"73...aka 32 frames, aka over 1 second, aka quite an improvement for a run of this caliber. Official YouTube encode should be up tomorrow!
Edit: For some reason, it loses a VI in the transition from BitFS to the B2 fight. Here's the new .m64 with a time of 5'02"75.
Experienced Forum User, Published Author, Active player
(420)
Joined: 9/21/2009
Posts: 1047
Location: California
SoulCal wrote:
sonicpacker wrote:
Please wait for the improvements to be updated to the submission. Thanks! =)
I saw your FML post; how much of an improvement is that?
I'm not actually sure because Snark timed it differently than normal, but I *think* 5 frames. I'll get the .m64 and make sure when Mickey gets on his computer.
Experienced Forum User, Published Author, Active player
(420)
Joined: 9/21/2009
Posts: 1047
Location: California
mklip2001 wrote:
* My movie stopped at the very last moment before the final "star" was grabbed, which starts the credits. Instead, my movie stops with a pause screen.
...
I'll vote Yes, but that last movie frame worries me a bit. Did the last frame of the movie get corrupted?
That's just a Mupen pause bug. It decides to press all the buttons when a movie ends, thus the game pauses because start is included in the buttons it presses. There's no way to fix it.
Experienced Forum User, Published Author, Active player
(420)
Joined: 9/21/2009
Posts: 1047
Location: California
YoungJ1997lol wrote:
the youtube vid is still processing, but i voted yes anyway (the fact that it is an improvement)
The current one in the submission text is lacking subtitles, so I'm working on a new encode. That video will stay unlisted for now until I can get the new one uploaded.
Experienced Forum User, Published Author, Active player
(420)
Joined: 9/21/2009
Posts: 1047
Location: California
Lex wrote:
If the game can be played back with proper graphics with that run time, then the extra run time isn't necessary. If not, then the extra run time is necessary.
Experienced Forum User, Published Author, Active player
(420)
Joined: 9/21/2009
Posts: 1047
Location: California
Mitjitsu wrote:
The hack looks well made, but I couldn't bare the thought of watching another 0 star run. The only way I can see the run being accepted is if it collected all the stars. Personally, if I think it would be best if someone was to create a hack that comprised of several varied obstacle courses. That way you would be seeing most of what the hack has to offer.
Star Road has 130 Stars and extremely varied levels. The production values are ridiculously high. You should play through it if you have a chance! =)
Experienced Forum User, Published Author, Active player
(420)
Joined: 9/21/2009
Posts: 1047
Location: California
Found an easy (but sometimes lengthy) way to do this:
I usually use Sony Vegas to edit videos. The big timer that tells you where you are in the video/audio track(s) is a very nice tool. Right click the numbers, then go to "Time Format," and click "Absolute Frames." Now you can open your .dtm in Dolphin and use the frame counter (NOT VIs) to take note of which visual cues match up with real time frames. Edit the capture to line up the .dtm frames with the Vegas frame timer, and voilà, you have yourself an accurate encode. However, don't forget to, in Vegas, go to File > Properties, and change the project to "Double NTSC" (60 FPS).
Experienced Forum User, Published Author, Active player
(420)
Joined: 9/21/2009
Posts: 1047
Location: California
sonicpacker wrote:
bobmario511 wrote:
Using Jabo's video 5 or 6 it is possible to finish this 34 frames faster (1266 total) as this .m64 shows (assuming it synchs). Since the only way this game can be reasonably encoded is with glide napalm wx, the frames were needed.
The final time should not reflect the need to "fix" the .m64 for encoding IMO. We have to extend the .m64 in SM64 for Aktan to encode it as well because of the Mupen pause bug, but never have we been asked to change the time of the run because of this.
