It really is a shame that this run had no framebuffer enabled so the encode couldn't use it. I'm glad it's finally published but for the record the published encode does not have lens flare effects (sages, sun) or flame coronas.
I wasn't going to say anything. At all. But now I have to.
Saturn wrote:
If you look at the history of TASvideos, almost all published runs that were thought to be more or less unimprovable were obsoleted by new runs that were several minutes faster in the end. This is especially for longer runs like this one the case. The difference is that the other authors just weren't aware of the improvements, so they obviously never stated them beforehand. It isn't the case here, so why shouldn't I inform the people about the facts? This more than 40 minutes long run is only improvable by at most 15 seconds as mentioned before, not several minutes like in most other cases. I think people can make their own mind about what is sounding better.
Saturn wrote:
why shouldn't I inform the people about the facts?
Because then no one will be surprised when an obsoletion pops up!
I was browsing the japanese-youtube-like-site and came across 2 fun TAS videos of this game about 2 weeks old, kind of in the vein of antdgar's playarounds. (If you hate the scrolling comment overlay you can turn it off with the button that looks like a bird talking, next to the volume slider.)
one and two
Stop bitching about the past and work on the future.
Is it cool to bitch about the future? Because I don't see this site getting any better if all we plan on doing is bitch and argue and argue about bitching. >:(
is grinding anything like stuttering when you are at the edge of something? I've never seen that teleport mario, he usually just stutters on a ledge and then falls or grabs on or recovers.
oh. whatever, my point got across. if the check is indeed like I said then it would be impossible* to stay standing underwater once that animation exception or whatever is done. the only way you could stay underwater is if it did a plane collision check of the water's surface to mario's entire hitbox. which a) seems silly and b) we know at least to not be true inside the castle since mario warps to the surface in the gameshark vid.
But hey it might be different for the moat. I know for a fact that if you can go beneath the surface of water without actually touching the water surface in banjo-kazooie (click clock wood during spring, for example) and banjo-tooie (various broken seams in jolly roger lagoon) and other games, the game lets you walk underwater until you do touch the surface. But that doesn't mean anything for the case at hand so whatever.
*probably
Great work! 2 things though.
1) In labyrinth act 3, when you hit the switch to move the waterfall wall, you spindash on it, hit a wall, fall, and spindash again. Wouldn't it be faster to just walk off the switch and spindash only once since you have to fall anyway and the wall negates any good speed you could get from the first?
2) probably a hack glitch or something I pressed during the end credits but tails jumped off the scrap brain gravity spinning wheel the wrong way and was killed by lightning :D
Collision in water is likely like so:
Water volumes likely have a minX and a maxX and same for Y.
If Mario's X GREATERTHAN water's minX and mario's X LESSTHAN water's maxX and mario's Y GREATERTHAN water's minY and mario's Y LESSTHAN water's maxY and mario's Z LESSTHAN water's surface Z (maxZ?), then underwater.
Edit: bbcode needs to stop destroying this post. :( I've fixed it like 3 times now
EDIT4: JESUS CHRIST BBCODE STOP FUCKING WITH GREATER THAN AND LESS THAN
It's like people don't look at links or read the thread and just want to post repeating other people and asking things that have been answered. It sure is a good thing people in this community are cheerful and helpful and openminded!
ThMrksman wrote:
And on the topic of breaking into the moat door, is it possible to BLJ inside the castle wall and enter the door from the other side?
I'm not taking sides, but everyone's attitude has been pretty terrible. I feel like I'm reading the Super Metroid thread from months back where someone posted a video of an impossibly quick time at the beginning section of the game and then someone else posted a video showing that it's easy to fake that time in an out-of-context video. Plenty of nasty forum posts ensued. I think that story had a happy ending to it though and now that area can be beaten even faster than the at-the-time-ridiculous first video.
In any case, there was no proof in that situation until the input recording format* started from power-on was used as proof because as has been said before, videos prove exactly nothing.
*.smv for the snes game, .m64 applies here
I have nothing to say regarding the moat door, but for standing on the slope trick in the lobby, I have managed to stand up there once without any codes. It was on the left side of the key door, though, not the right, and when I finlly managed it, my head was stuck in the ceiling and I couldn't move so I ended up having to reset. But just saying.
There's also the TAS input plugin which allows for very precise analog stick positioning. Useful for frame-by-frame movement but kind of useless if you want to play at full or half speed or whatever. and autofire is of course ok no matter the case.
No point in making an encode at 320x240 that needs a quad-core 4GHz machine using hardware acceleration to run smoothly :P
For some reason, the video gets so blurry it's nothing more than a joke if I don't downscale, but looks good if I do.
Not sure what that has to do with what I said. If you want to make a high res encode (say, 640x480 for example), you can't use a video filter that makes the first pass output to a different resolution. multiple pass encode need a few things consistent between the passes. input and output video size, and framerate are among them, as well as number of bframes used. Also a good rule of thumb is that bitrate should almost increase linearly with one of the dimensions. so a 640x480 encode should get about 2x the bitrate of a 320x240 encode. Even though it's 4x the area, the quants should end up about the same.
Not that I don't trust the official documentation on this, but the document you linked also stated that 7 was the maximum for subq, although the manpage states it's 9. I will try it out something, though. Thanks for the link :)
Look at the difference in 7 and 9. ENORNMOUS encoding speed hit.
Some notes about playback-power-changing parameters...
1) I highly recommend against ever using more than 3 bframes in a row. CPU usage ramps up exponentially for playback (but do use b_pyramid if you use bframes).
2) If you do use 3 bframes, (because that's fine when you don't want to decimate) using bidirectional motion estimation (option is "bime") is pretty good at helping to save bits. but if you want to use that option, keep "frameref" at 3 or below (maybe 4 if the resolution is very small) because CPU usage ramps up exponentially exponentially. And with "mixed_refs" on, it's exponentially exponentially exponential. :)
Those above notes are really only valid when the resolution is above 256x224 and other small rez's used here. No point in making an encode at 320x240 that needs a quad-core 4GHz machine using hardware acceleration to run smoothly :P
By the way guys, My WIP encode repository for this game has been overhauled. All progress (parts 0 through 8 as the previous encodes numbered them) from power-on to the end of Mad Monster Mansion in one convenient file that hopefully is a good mix of filesize and quality. :)
Every extra letter costs 3/60 of a second each time it's said. I'm gonna guess the name is said like 50 times, so 2.5 seconds per extra letter is added to the movie. So if he wanted it to be, say, "Link", the name entry screen would be about 1.5 seconds longer and the run would have 7.5 (2.5*3) seconds added. for a run ending up 9 seconds longer (an increase of 0.083%)
The format is like this:
current VI/total VIs (current input/total inputs)
VI is vertical interrupt and is exactly 60fps, and is what the avi has. The N64 can poll the controller multiple times per VI (kinda rare), or can poll the controller 0 times during multipe VIs (due to loading or whatever). This means that inputs can never be used for time estimates in an N64 tas.
Wherever you were in you movie, it was the 233rd input frame which was 3.85 (231/60) seconds into a movie that totals 116.53 (6992/60) seconds long.
The number of MB/min is entirely dependant on how many frames are skipped (with -vf decimate). 3 MB/min is a bitrate of 409 if no frames are ever skipped. (..and higher if so. example would be: half of all frames skipped = bitrate of 818) Also you might want to lower those numbers if your 3MB/min figure included audio.
To see what settings other people used to encode the final pass of any h264 video, open it with a hex editor, and it will tell you near the beginning of the file (usually begins with "cabac=1") :)
go ahead and give me access too. I fixed some m64 bugs, and I might as well put it on the svn instead of making rars.
1) if you look at my mupen64.cs lines 300 through 303, you'll see that I am ignoring the work I did lines 296 through 298 and then you'll laugh at me... same goes for 283-290. This mistake makes saving C directions include analog stick directions which made for an amusing mario64 desync during a test.
2) I made sure the unused values at the large end of input byte 1 get recognized too since resets mark all bits as 1, and that would be "lost in translaton" otherwise.
3) analog directions were inversed for no reason other than I like to release code that hasn't been tested at all.
I could also fix your resizing (though I think it's fine) and call it v0.13
Another video option. Pretty much the same as shinydoofy's. I was doing some unrelated testing and ended up with a passable result so sharing just because.) Never heard of this game before, but I was entertained for 40 minutes so good job :)
dear comicalflop, I don't want to download something that's over 5x bigger than it should be. download razorlame, a lame frontend, and make a mono mp3 between 56 and 92 kbps (voice doesn't need better). You say 35mins are missing so your should have a file that's around 120MB or less. :) (or audacity is fine too but really you should have just made the mp3 first instead of)
Thanks for understanding.
Edit: oh, more than 35 minutes missing. whatever the case, I look forward to the smaller file.
