I don't like VBR in AVI, it's a hack. I always encode to CBR MP3 when encoding audio for an AVI. It works well enough, but if you want to do anything with it in VDub, you have to decode it and reencode it with CBR to prevent skewing.
VDub was making the audio 50MB because it was likely writing out uncompressed audio. I always compress the audio externally with LAME, as you did, then mux it in with direct stream copy. I generally use 128kbps or higher, depending on the quality of the source (like, if I record from a cable DVR that's set to 128kbps MP2, then I'll likely use 128kbps MP3 because any better is really a waste).
I think I came across something that prevents using this patch to do VS Unisystem runs - the emulator doesn't seem to record coin insertions. I did a practice run without rerecords through VS SMB, and when I played back the movie, it would not leave the attract mode. I should think that it would be a good idea to somehow retain the DIP switch settings as well.
This is strange, because the movie file format clearly supports those events.
Well, I just brought up DIP switches in case they weren't supported, I don't know if they actually are or not (I didn't even modify them for this practice run). I uploaded the recording to http://ssonicnet.com/localhmc/localh-vssmb-bullshit.fcm, so you can look at it if you want. I know for a fact the coin insertion didn't work, as I wouldn't have recorded the length I did if I hadn't actually inserted the coin. This movie uses no rerecording and only slowdown.
I already did that, since the first time I tried converting it without adding any frames it did not work correctly. After adding two frames, the video plays up until the aforementioned place in 3-1 where FCEU lags. I don't think it's an issue of Famtasia emulating the CPU faster, so much as I feel it's the fact that Famtasia is less accurate than FCEU, and so Famtasia does not lag where FCEU does. I would be willing to share the converted FCM, there are likely more places where FCEU lags and desyncs the movie even more, I haven't tried adding delay frames and fixing the existing FCM other than by adding two frames to the beginning.
it would show exceptional skill that you were able to nail a wall jump on the first attempt.
More like exceptional luck.
Well, I don't know, there are some situations where a wall jump can be done fairly reliably in realtime - for instance, in SMB2j 8-1, I can wall jump in several locations fairly consistently (it depends on other minor circumstances, but for example, at the point where the wind starts blowing, if i hit the first Paratroopa just right and bounce up, I can wall jump off the short tower right before the pit more often than not - also at the point closer to the end of the wind, I can reliably hatstomp the first two red Paratroopas and then walljump to the top of the upside-down pipe). I'll admit, I seem to be able to walljump more consistently with SMB2j than SMB1, but that's probably just due to the level layout of SMB2j giving more opportunities, and the fact that I play SMB2j more because I like the fact that Mario bounces higher.
For that matter, if they ban the wall jump, why don't they ban the high-bounce? They both serve the same purpose - to allow you to jump higher than normally possible. Or for that matter, why not ban hat stomps? They give an advantage over people who don't hat stomp, and we seem to consider it a trick rather than an intended aspect of gameplay.
I still say TG should allow non-cheat glitches/bugs, but consider them separate records from the ones that they currently allow.
It still pisses me off that TG doesn't allow glitches in any form - why not just set up a separate class of run, and let people choose, like they do with minimalist vs. full completion? In my opinion, wall jumps are tough enough to pull off that, unless you nail it on the absolute first try, you'll just waste time and blow your whole run, so to me it would show exceptional skill that you were able to nail a wall jump on the first attempt.
I feel that such a mod should be usable for legit records, including TG - but in a separate class from stock NES runs. Obviously people using an overclocked system would have a definite advantage, but other than that, in 99% of cases, it doesn't modify the actual gameplay, only the amount of lagged frames, so it's not like using a Game Genie code to cheat and do things outside the original parameters. It would be useful to determine the actual best possible speed while taking lag out of the situation. I don't see this happening, though, because I bet people in the legit speedrun scene will have a kneejerk reaction, similar to the initial reaction to TAS runs, and call it 'faking' and 'cheating' and 'made up' (hell, I'm even seeing a bit of that here now, although it's much less pervasive).
Besides, using Famtasia over FCEU is sort of like this, because FCEU seems to emulate the lag accurately, while Famtasia doesn't - I tried converting an SMB1 tricks FMV to FCM, and it played properly up until 3-1 when FCEU lags during the acrobatics near the powerup brick, then Mario just jumps into the side of the next pipe and soon gets killed by a Goomba. But the use of Famtasia is practical for other reasons and thus is accepted here, despite this 'feature'. So technically, using Famtasia is equivalent to using an overclocked NES, when it comes to the end result.
Also, this is really currently moot for TAS runs, since they're not done with hardware. Only when emulators have settings to overclock the CPU core, will it become an issue (and in that case, I'd recommend that the emulators should store the clock speed used within the controller movie, to prevent the invalidation of that particular emulator as qualified for TAS runs).
I agree, and also perhaps you could include some questions about the actual superplay-making process. This is used with excellent results on a Sonic board I visit.
Ok, I've been studying, and I've figured out a simple way to fix this problem, and all it requires is one small feature. Using AviSynth, there is an "AssumeFPS" function that changes the video frame rate and also changes the audio sample rate to keep a/v sync. Based on the ratio between 59.94 (NTSC) and 60 (FCEU), which is 1000/1001, if FCEU could generate audio at 48048Hz, then running the resultant 60fps file through AviSynth with "AssumeFPS(59.94)" should correct the audio sample rate to 48000Hz with only a tiny, most likely imperceptible pitch shift.
There should be no need to worry about computing this ratio for any other sample rate, as 48KHz is the standard for DVD (and this would only be useful for someone wanting to produce a DVD, as the 59.94 vs. 60fps issue only comes into play when making NTSC DVDs).
I still haven't figured out my plan of action for making PAL DVDs, should I need to. I would be making the DVDs all-region capable, so given that, aren't most PAL players able to output PAL60 (which should more or less be sufficient for this)?
1) What is your name? Where do you live?
2) How did you first hear of/get into timeattack videos?
3) What about timeattack videos captivates you? What makes it worth spending many many hours creating them?
4) What is the process you use to start, plan, and complete a timeattack video?
5) Which timeattack video that you've created are you most proud of? Why?
6) There seems to be some criticism/antagonism directed at the creators of timeattack videos. How do you explain this? Does this represent competing philosophies about how video games should be played?
7) Do you consider yourself a film maker?
1) Scott Jones, upper east Tennessee
2) I must be the only person who didn't see Morimoto's SMB3 as their first tool-assisted run...for me it was Crazygodtechnique. At first, I thought it was realtime, and when I found out it was done with Famtasia, I thought, "no wonder they were able to hit all those jumps dead-on". At this point, I hadn't really gotten fully interested. A bit later on down the road, my friend gave me some AVis of runs from Bisqwit's site, which rekindled my interest for good.
3) For me, these runs are all about being as impressive as possible. Things like manipulating luck, shooting before an enemy is visible onscreen, anything that shows extreme knowledge of the game. IMO, any run that does something outside the normal properties of the game engine is impressive.
4/5) I haven't actually created any released runs, only some small practice runs in SMB1 and SMB2j. And I haven't started using rerecording yet, I'm merely boning up my skills. Even at slow speed, it's not that easy to tweak the SMB engine.
6) I pretty much agree with others' comments on this issue. Realtime speedrunners feel threatened by tool-assisted runs, because they fear that someone will pass off a tool-assisted run as realtime. The difference is, tool-assisted speedrunners don't advocate that realtime speedrunners not be able to do realtime speedruns.
7) I don't see this so much as filmmaking, as I do a form of programming. Essentially, you're programming the emulator to depress certain buttons on certain frames.
Yes, but that's exactly what I don't want to do. With that method, it will basically drop one frame out of 1000. I want playback to be absolutely perfectly smooth - while we currently don't have a way to playback these movies on a real NES, I want this to look as close to a real NES as it can, without introducing blemishes to emulate an RF/composite signal. Currently, I bilinear-resize to 672 pixels wide from the original 256, I weave the NES-frames together to get either 480 lines (I have FCEU set to show 240 lines - if there are bugs such as in TMNT1, I will crop to 224). I then add black to fill to 720x480, which is exactly DVD-compliant. I ensure that I'm recording from the very first NES frame and set AVISynth to assume bottom-field-first. My only current problem is the difference between 60fps and 59.94fps, when it comes to a/v sync.
Doing PAL-recordings from any system (especially with C64 and Amiga demos) is much easier as you just weave the original 50fps AVI into 25fps and make sure you resize horizontally to keep the proper aspect if needed.
I have a feature request, but I don't know how much trouble it would be to implement.
As I've stated in the General forum, I want to produce video DVDs with the quality speedruns, so that it is easier to show the runs to someone who may not have the setup necessary to run the controller movies, but yet see the video in much better quality than the AVIs (due to the larger bitrate and viewing on a TV set). However, there is one slight snag - FCEU outputs a 60fps AVI, but the actual NTSC field rate is 59.94fps (which is output in an interlaced 29.97fps). This can cause loss of a/v sync during encoding. I have yet to find a high-quality way to transcode the 30fps interim AVIs (after resizing horizontally and weaving the fields together) into 29.97fps without problems of some kind. My request is that there be a toggle that causes the emulated NES to run at 59.94fps (and thus, assuming there is no major snag, the audio should be generated at that rate as well). That way, I can merely weave those fields into a DVD-compliant AVI that can then be transcoded to MPEG-2 and Dolby Digital AC3 within Encore DVD.
Perhaps you could have a sequence with a logo displayed prominently, and then use the same logo in corner of the video as a 'bug', as it's known in the TV industry. It'd be best if the logo was some multiple of 16 pixels in both directions, when used as a bug, due to the fact that MPEG-4's macroblocks are 16x16 (meaning that artifacts are more likely to occur if a straight edge hits anywhere else than these macroblock boundaries).
Or, you could increase the frame size vertically by 32 pixels and then use a subtitle that only covers up stuff in the bottom 16 pixels of the actual NES frame, if that works with the information you want to present.
Just a couple of ideas to throw out, keeping in mind that Bisqwit has already stated that he wants the subtitles/identification to be impossible to edit out. Perhaps if you went the logo route, you could make the logo universally accepted to mean 'non-realtime trick run/time attack done with savestates and slowdown', so that the mere presence of the logo would clue people in to the fact that these videos do not compete with realtime hardware speedruns.
You'll also need WinRAR to deal with those RAR files (I'm assuming you haven't decompressed them or anything, since you say you just put them in the FCEU folder). Install it then you can just right-click on the RAR files and go to "Extract here".
I think I came across something that prevents using this patch to do VS Unisystem runs - the emulator doesn't seem to record coin insertions. I did a practice run without rerecords through VS SMB, and when I played back the movie, it would not leave the attract mode. I should think that it would be a good idea to somehow retain the DIP switch settings as well.
May I recommend trying the latest version of the palette on BMF's page? I personally regard it as the best NES palette currently in existence. Quote from BMF's readme:
Third time's a charm, I guess. I got a few complaints about how dark final
revision 2 was, so I forced myself to give it one more shot (didn't I say that
5 revisions ago?). This revision is a blend of final revision 2 (after some
gamma correction) and kevtris's emulated NTSC palette. The end result is a
palette with a good mix of kev's hues and final revision 2's nicer saturation
and luminosity.
As for extracting Famtasia's palette, I have no idea.
Yeah, I just watched it, you're right, it's better than Cgt. I especially liked the sliding of the turtles through the floor. At that point in 4-1 after the bonus pipe exit, where the Lakitu comes back out, I was sitting there thinking "he's gonna hat stomp that motherfucker", and sure enough, hat stomp. GRATE stuff.
Myself, I feel videos should be as impressive as one can make them, even if it costs 15-20 seconds total to display that impressiveness instead of going for the absolute fastest speed. I'd gladly watch a longer video if it was more impressive. That's why I enjoyed Crazygodtechnique - it wasn't a speed run, it was just a total ravaging of the engine.
Sonic 1 is much worse for this than Sonic 2. S1 has a very low 'maximum' velocity, but it is possible to go faster than this if you are propelled by a spring or other object. As soon as you press forward you slow to that 'maximum' speed.
The shit? They don't even let you look around?
Too bad. I might have started going there, but I don't like boards/sites that don't even let you view as a guest.
Well, of course, but in this case he's going for impressive rather than fast. It might be somewhat slower, but I think it will still be entertaining.
Besides, he's going for Maru Mari only. There's no way, I don't believe, to get through the statue room this way without beating both bosses and extending the bridge.
Some people also feel that exploiting engine bugs, or any other things that you can do ingame that weren't intended by the designers, to be cheating as well.
And also, as with here, there's one type of 'cheating' that I'd imagine would even be allowed in competitive realtime gaming - cheat codes that increase the difficulty of the game.
Though, S1&K has somewhere in the neighborhood of, like, 130 million levels...even using the perfect bonus to skip 'em 10 at a time instead of playing them all, you'd probably die of old age before you could finish watching the completed run...O_O
Maybe just settling for doing the S3&K level select cheat and playing through the 16 "regular" special stages one after the other?...
Well yeah, but it'd probably just be best to make one run, and then split the generated AVI, if you're really interested in seeing some of the much later stages. I'd think it would just be quite impressive to see someone run through like 20 or 30 levels jumping around the red spheres and of course getting all perfect (taking into account that some stages make it really easy to get all the blue spheres before getting all the rings).