Well assuming I can get it to sync I'll be happy to make wips videos. no matter what you pick some people will have problems. My personal preference as far as video quality goes is jabo 1.6. All linux encoders and watchers will hate you if you pick that one but whatever. You're the one willing to run it so... :)
I like how there are 3x as many displayed frames as there are frames of input. That's a ridiculous discrepancy. Anyway I was entertained but was also expecting more from a skate game TAS. My meh/yes borderline vote will lean towards yes though.
It was in directx mode, but what's the difference?
For me, DirectX syncs. OpenGL doesn't.
Hmm. Well I'm capturing it now with direct64. I'll try rice in openGL later but I don't want to stop what's in progress. so far it's at the sonata of awakening (frame 156k)
It was in directx mode, but what's the difference? By the way, jabo 1.6 desyncs where everyone says, with him exiting west clock town incorrectly so he bangs into the pillar at the base of the clock tower. And Rice 6.1.1 beta 10 desyncs before that even. I forget where but I think it's before the first cycle.
I keep trying in the hopes that jabo 1.6 will work... no luck. and for some reason Rice stopped working for me. are there any objections to having an avi that is made entirely with direct64 (sound will sync)?
a dummy reset after the initial ram is made, preventing the desynch all together.
Would that fix it on your mupen? Like, start up the game, enter the name entry screen, reset and then hex in the rest of the data? Would jabo1.6 then work all the way through? If this is the case, The avi should be made that way... If not, then for future compatibility's sake, I still think a version of the m64 should be made that works in one go. I don't retract my Yes vote though because this is still an excellent run that works for me.
Are codes allowed? A few that come to mind are maximum upgrades or all balloons are blue.
Codes are on a game-by-game basis. Using codes to make the game easier isn't really in the spirit of TASvideos. I don't see it making the game any more entertaining, and would probably make it less so. I would highly doubt this would be accepted for DKR.
This is a long game. Very fun but also repetetive. Making all balloons blue would make it much faster, while not affecting goals. It would be like that doublespeed code used in the banjo-tooie run on SDA.... except not really.
Hey Chamale, now YOU get to trim down YOUR post about masturbating or whatever so YOU arent stretching the window 200 times its normal size.
get a wider screen?
Deign wrote:
http://www.youtube.com/watch?v=C3MT6Wi3Kp8&feature=bz301
Randomly found this after watching all the ones that Hala posted. Honestly wasn't searching for anything like this either. But this one wasn't featured on that post and it even goes to the music =D
http://tas.monotoli.org/index.php?sort=date&path=mov/mm/
as far as I know, there are only little bits and pieces missing. you can watch them in order, but stop after the first minute of 05, and don't watch 06. all of that stuff was redone in 07 (don't get the low quality one. it's really low quality). 07 flows into 08 and 08 flows into 09, which is the end. I think some of the earlier ones have bad a/v sync, but oh well. I'm sure someone will encode the entire thing into one nice file eventually.
for DaShiznawz: the only non-n64 game I can think of that I would enjoy watching a tas of that hasn't been (fully) made is top gear for super nintendo. Probably not a great choice for general audience though.
same number of frames. I can't remember any lag from this or MM's engine except when there are multiple explosions going on. It kind of helps that it has two thirds of the framerate of the average n64 3D adventure game to begin with.
Cool. I haven't gotten into avisynth much, but it is clearly very powerful. A frontend I use takes advantage of it though. Remember (you probably already know this): two of the best things you can do when encoding to save on bitrate or help with psnr is making sure it's mod16 in both directions and doing 2 pass for a much, much better distribution of bits.
Well I always strive for mod16, since x264.exe tends to complain if it's not (most of my 64 encodes are 464x352). And sure 2-pass distributes bits well, but different videos require different bitrates (bitrate of super mario bros to look good < sonic 1 < sonic 3 < f-zero 64) and it's just much easier (and half the waiting time) to give it a crf that gives consistent quality among all videos. crf is still variable bitrate. and with "--refs 12" I'm not worried about bad motion estimation. Besides, even with a high qpstep, fast/complicated motion still looks like shit in a 2-pass size-oriented encode (see: gunstar heroes spinning credits and spaceship level). At that point why waste time doing multiple ugly multi-pass encodes before you get it right, when crf (quality-oriented) does the job fine on the first try. :)
(can you tell I'm not a fan of detailless blocky encodes?)
For the record I was never able to watch comicalflop's WIP it desyched as soon as he got control.
After seeing it put up against mine I am embarrassed I even tried. I really don't belong on this site.
I guess wanting something and trying your hardest at it really doesn't help if you are talentless.
stop with the self-deprecation. now that you have a good example, try meeting or beating it. Doing this 3-minuteish game segment like that will provide a good foundation for the effort required for the following hour-and-change of gameplay. (I'm guessing there's a good 30 minutes of cutscenes or more)
Do you do all this stuff with straight mencoder or do you use some sort of frontend so you don't have to memorize all the mencoder switches?
nah never took the time to get mencoder working, I just rehash old scripts.
I record what I want from mupen using x264 at qp 18.
then I use an avisynth script. the side-by-side looks like this.
vid1 = DirectShowSource("C:\emulation\mupen64\tas\lol.avi", fps = 60)
vid2 = DirectShowSource("C:\emulation\mupen64\tas\lol2.avi", fps = 60)
StackHorizontal(vid1, vid2)
LanczosResize(640,240).Fadein(60).Fadeout2(60)
Then I just call x264.exe on it, one-pass usually with a constant rate factor (crf) of 26 (I have the cmd line saved in a text file so I don't have to memorize anything). I pull the wav from the avi and have lame turn it into mp3. mkvmerge does the rest. mencoder would probably be less steps if done right, but I have shortcuts to everything and so really it's like a 10-click process. Hope that helps.
Dashiznawz on the left, Comicalflop on the right. (13MB)
no fancy left-right audio stuff, just two different selectable audio tracks.
Anyway, this video speaks for itself, comicalflop's is consistently faster in every area. Oh, DS's capped with jabo which has the ugly pause screens. CF capped with direct64. I never noticed the black bars were different from plugin to plugin.
Well I really liked the health management and crazy speed obtained in some areas as well as the clever use of ceiling-waking for extra speed when you have to wait for something. I didn't really see any bad playing, so I vote yes because I enjoyed watching it.
http://tas.monotoli.org/mov/oot/wip/lozoot-wip5-ds.mkv (10MB)
Well I'm wondering why you didn't roll in the store. And while I like the idea of not changing camera angles between the garden signpost and the store shore... I'm not sure that was the fastest way.
I saw cf's wip when it was made but I have no idea which of the 100+ cryptically named .m64's in my mupen\tas\ folder it is. If it could be relinked, maybe I could do side-by-side comparison vids (or not :v). Does DaShiznawz even have it to use as a reference? Either way, I see improvement and as long as you think positively and post wips after every 5 to 10 minutes of actual gameplay, and redo what can be redone, there's no doubt your tas will be the fastest, and accepted.
On a side note, I wish I had more time to actually keep tasing banjo-kazooie or something. encoding is just pushing buttons and doing other stuff while you wait, tasing takes up more time than my workload allows. :(
http://tas.monotoli.org/mov/oot/wip/lozoot-wip4-ds.mkv (3MB)
Well down where we all mentioned looks better, but that third sidehop from the garden fence looks iffy. As in, probably unnecessary. it's not faster to roll or walk from the end of the second sidehop and make it in the hole faster? rolling rock area looks fine as usual...
at about 0:27 of the video. the angle into the grass goes too much in the corner and you mysteriously sidehop further from the ramp after you already have 2 rupees. That's all we're saying.
http://tas.monotoli.org/mov/oot/wip/lozoot-wip2-ds.mkv (5MB)
To get the grass's two rupees at the start, does the path really have to go so far into the corner? Also did we ever find out if it was faster to sidehop or roll in the house? Everything else looks perfect.
