What makes the hack even more awesome - the author, Sonic Hachelle-Bee, does all his hacking on a Mac, which is a rarity in any ROM hacking scene. Also, I agree with the sentiment above that a TAS is only done after the ROM is more or less finished, and SHB has stopped working on it. Or, at the very least, include a copy of the IPS along with any TAS attempted.
Also, just to make it 100% clear - SHB is only making this as his interpretation of what Sonic 2 might have been like, had there been more time to flesh out the levels that were dropped after the proto we have.
Are you complaining about the filesize of the interim AVI (if you're using one and not feeding an AVS straight to your encoder, should it allow you do to so), or the filesize of the encoded MPEG-2? If you're troubled by the interim disk space, I recommend using the CamStudio Lossless codec. When set to GZIP at level 9, it produces files that are quite small, but is slow. I use it for my emulator raws, before I manipulate them with Avisynth, and then I feed the AVS directly to TMPGEnc (my encoder of choice). As far as the final filesize on DVD, that depends on the encoding parameters, and to a point whether you use VBR or CBR. VBR usually takes longer to encode but will create smaller files than CBR at the same quality. Conversely, if you have both a VBR and CBR file of the same filesize, the VBR will have better quality (although if the bitrate is high enough then you probably won't notice a difference).
Did you just mistype or did you really use 325x240 instead of 352x240? I don't see why it would crash either way (unless it was the encoder crapping out during compression).
Well, if you dropped to 352x240, then you've destroyed the interlacing that makes Samus actually blink. The large file sizes suck, yes, but that's par for the course when working with any type of digital video. The reason that "on some parts she completely disappeared" is exactly due to the use of 352x240. To be able to display 60fps material such as classic video games, you must use a 480 line mode. DVD does support 352x480 as far as I know, however, so you can try this:
Or, if you needed to use the 224-line modifications, do this for line 4 and 5:
BilinearResize(325,224)
AddBorders(13,8,14,8)
Try that out, encoding to 352x480 (if your software allows it), and hopefully the filesize isn't quite as big as before (given that you have half as much video data). The image may not look quite as sharp as the 720x480 results, but it should nonetheless preserve the interlacing that's required for accurate NES video.
It should. Although you might not be able to tell unless you use a player that bobs the video (most software DVD players will do this, and ffdshow will also allow you to do the same). But, when you burn the disc, barring any other problems, Samus should indeed flicker when she's supposed to (although, of course, if you view the video on an LCD display, the flickering is liable to turn into a 50% transparency).
My golden test is how a standalone DVD player responds. If it plays good and proper there, then it will also look good on any device that handles interlaced video properly (such as software DVD players).
Evilheart: Part of your problem is that the emulator is only outputting 224 lines, but your script (which looks to be based off mine that I posted on Doom9) is assuming that the emulator is outputting a 240 line video. Two ways to fix this - either set FCEU up to output 240 lines in NTSC mode (in the Video options, there are settings for first and last scanline in both NTSC and PAL - set the top scanline to 0 and the bottom one to 239), or change the fourth through sixth lines of your script to read as follows:
PointResize(512,224) # omit this for softer vertical transitions
BilinearResize(650,224)
AddBorders(35,8,35,8)
The second method will hide any garbage that may exist on the top or bottom 8 lines.
The field order shouldn't be that much of an issue - as far as I understand, NTSC DVD is primarily top-field first (it's NTSC DV that is BFF).
jdurg: What type of audio did you use? AC3 (Dolby Digital) is notorious for having an incorrect audio level when not set up properly, due to things like "dialog normalization". Unfortunately, such audio issues are outside my current scope, but it's something that I am constantly trying to learn. As for interlacing the SM run properly, you might try using a variant of my NES Avisynth script, such as this (untested, but should be a good starting point):
AVISource("nesoutput.avi")
AssumeFieldBased()
AssumeTFF()
PointResize(512,240) # omit this for softer vertical transitions
BilinearResize(650,240)
AddBorders(35,0,35,0)
Weave()
AssumeFPS(30000,1001,true)
If your generated AVI is 224 lines, then make the same modifications that I recommended to Evilheart. Unless there is some audio skew in the SNES emulator output like there is with FCEU, then this should work for you.
In DX, if a Piece of Power or Guardian Acorn pops up, if you hit Start right after you pick one up, you can prevent the messagebox from popping up. I haven't measured it, but doing that and immediately dumping out of the subscreen seems to be a bit faster, plus the incentive of walking faster is quite lucrative in the case of the Piece of Power. You have to be careful, however, because I've had the game freeze in the middle of one of the fades between the subscreen and the game screen. It's definitely avoidable as it happens less often than not, but I haven't determined the cause of this glitch.
I've also never gotten this to work with any other messageboxes. Only the ones generated by picking up either a Piece of Power or Guardian Acorn.
As far as I know, the GBA has the same sound hardware as the original GB, supplemented by two PCM channels which can be fed via DMA to keep CPU load low. So, basically, the "sounds 8-bit" is really just the original GB sound hardware dominating the music. Look at Sonic Advance 1 for what I feel is a good example of mixing the GB sound hardware with the PCM channels.
It should be possible to programmatically detect lag, at least for some games. I know that, on the C64, lag is introduced when you are not using IRQs, but instead busywaiting until certain scanlines, and a piece of code overshoots one of those scanlines, then the game will busywait until that same scanline next frame. Perhaps something similar happens on the NES with regards to the sprite 0 hit and vblank.
Okay. According to the article you're right: 646 is the closest width for duplicating the stretching effect(1.21:1). I was assuming square pixels coming from the NES.
BTW, is it just my imagination, or do the graphics look better proportionally when not stretched?
That's really just a matter of personal taste, if you ask me. You will have some games with graphics that look a little "thin" (like, for example, play Rare's Wheel of Fortune on an emulator using square pixels, then play it properly stretched, and notice the shape of the full-screen wheel). But, for the most part, it's whatever you're used to.
Well, I basically took NES video that had been run through a TBC and captured it, then measured within the 720 pixel frame (which I realize is not square pixel video, but since my destination is video I'm not really working in square pixels to begin with). I also realize that it's not a 100% accurate method, as the number of pixels used by the NES would depend on the capture window of my capture device, which I haven't measured. I'm almost certain that a real NES has pixels much wider than you're accounting for. Remember, I'm not trying to make it look like the emulator, I'm trying to make it look close to a real NES (but not exactly, as the NTSC artifacts are one method of discerning between a realtime speedrun and a TAS).
Edit: Here's a good thread that talks about the NES aspect ratio.
It's not fooling your eyes - a standard NTSC video signal has 59.94 fields per second, two fields to a frame. But each field within a frame is from a different moment in time, and so you get 59.94 frames per second when dealing with older game console video. The only major difference between old noninterlaced signals and a normal interlaced signal is a single half-scanline at the bottom of the screen which causes the set to offset the next field by half the height of a scanline.
But yes, you're absolutely correct. Since an NES outputs 240 scanlines, two NES frames fit perfectly into an interlaced NTSC frame, with no vertical resizing whatsoever. All you have to do is resize horizontally to get the proper aspect ratio (somewhere between 650 and 658 pixels wide is close enough for government work), pad to 720 pixels wide, and then weave them together into frames to get 720x480x29.97 interlaced video which, when watched on a proper interlaced display (or on a PC using a bob deinterlacer), will result in perfectly smooth scrolling, and preservation of single-frame flickering.
Yes. You simply weave the frames together as if they were fields, as I've said. This produces 29.97i output on a standard DVD player, which is a standard part of the spec.
That would be disastrous for NES videos, as many NES games use 60Hz-flickering for various reasons, and dropping half the frames may cause sprites to disappear, depending on whether you drop even or odd frames.
Consoles pre-Dreamcast tend to mostly use a 60fps noninterlace mode (although the SNES and Genesis both do support an interlace mode, they weren't used much).
However, at least one code that was recently uncovered is known that is built-in to the game and will not check with password generators - namely, NARPAS SWORD0 000000 000000. This code gives Samus infinite health and missiles, making the task of clearing the game much easier; since one code is defined in the game as such, it is possible (though not probable) that more exist that are not known about to this day. There were small debates on what the password stood for. Some thought it referred to a "Narpas" sword. Others feel the password is properly read as "NAR PASSWORD", with "NAR" as an abbreviation for the name of the person who handled the conversion from the FDS and designed the password system, Tohru Narihiro, or, as an acronym of "North American Release". Another speculation is that it speaks of "Narpas's Word", believing the designers wished to steer you wrong with a misplaced space.
lol, I run the official BT client on my P166 box with 48MB of RAM, and it runs fine for me. I do use the curses client, and you are correct, you can't change any settings (at least that I know of) without canceling the torrent and changing the command line.
The only real way to tell is to actually burn a DVD and play it on a set-top player. I've done so with a couple of test runs using my method, and when accounting for FCEU's audio skew, the audio and video stay perfectly synced, with perfect playback.
I don't even do that. As soon as avi is recorded with snes or nes it is ready. I used to try to resize but it takes Virtualdub forever to save if you don't use direct streaming mode, and then you can't use filters, but the quality is the same. If you want to keep doing that, bicubic looks better than bilinear.
Well, you can do it that way, but it's not anywhere close to the real hardware. NES and SNES video both use pixels that are wider than they are tall, and if you keep the video exactly at 256x224 or 256x240, then your aspect ratio will be off. You can see from my screenshot that it is already quite close to the aspect ratio of a real NES. It's still not exact (doing some recent testing, I've found that the left edge of my NES frame is in the right place, but a real NES extends out just a few more pixels on the right), but it's close enough for me to call it accurate.
And no, for my purposes, bicubic does not look better than bilinear, especially since "looks better" is subjective. Since console video output is analog, there are no distinct pixel boundaries - they tend to blend smoothyl into one another. In my testing, I've found that a bilinear resize gives output that is extremely close to captured RGB or S-Video (yes, I know the NES doesn't do RGB, but other systems do, and S-Video has high luma resolution).
Also, about using avisynth, I've found that if you, well, let's say you want SMW DVD. Instead of downloading torrent and enlarging it and crap, just play the smv and make a direct avi whith huffyuv, and I've found that that has such a difference in quality that you don't to enlarge, the picture is so good, it still looks just as good blown up on T.V. screen.
That's pretty much what I do. I take direct emulator output and tweak it to fit a full 720x480 NTSC DVD frame. With NES/SNES video, I use a bilinear resize to 650x240 pixels, pad with black to 720x240, then weave those 60fps individual frames into 29.97fps DVD-compliant interlaced frames. With Genesis video, I do a bilinear resize to 640x240, pad to 720x240, then weave to 720x480. However, since many Genesis games use single-pixel dithering to create the illusion of more colors, and this blurs nicely on a stock Genesis, I'm considering doing a couple of resize cycles to soften the image horizontally - I just have to find a balance where the image isn't too blurry, but it isn't too sharp either.
I'm personally studying Adobe Encore DVD, due to it's integration with Photoshop and After Effects. But, like all Adobe products, the learning curve is quite steep, so I wouldn't recommend it if you don't already understand the intricacies of DVD-Video.
What in the hell is wrong with "tool-assisted speedrun"? It's short and to the point, and it doesn't confuse itself with a realtime run. You don't see us disparaging those who choose to limit themselves to realtime runs, so it's childish of people to call TAS runs "emu-rape". Good old Nate over there are M2k2 is a prime example of this, from what I read he sees himself as "superior" to TAS runners. A few choice quotes:
Nate, in response to someone asking if a run was TAS or not wrote:
i'm pretty sure it is. people are just confused, as usual, which is why producing such things ought to result in instant damnation.
Nate wrote:
Saturn wrote:
Now I know at least why Nate insists to disrespect me by intentionaly calling my run a rape instead of a tool assisted speedrun. Maybe its just too good and impresses too much so someone might get jealous, who knows.
what pray tell would someone be jealous of? like being jealous of an ant after you crush it because it was able to inflict pain on you: there's never any doubt in your mind which of you was superior, but it still hurts.
Nate wrote:
the only time when i have really felt as though i could take a firm position on something has been the "should emu rape be eradicated" argument. emu rapes hurt my friends and this community, so i decided that it would be alright if i sided against them (and with my friends). surely if everyone in my community thinks that rape is wrong, then it's not counterproductive of me to agree with them. indeed, if i were to side with the rapes (which i hardly see any value in), shouldn't my community start looking for a new leader, one who actually shared their views?
And this last one especially makes me sad (emphasis mine):
Nate wrote:
unless i'm mistaken, the current nomenclature on the emu rape side, "tool-assisted run", originated from the emu rape side, and the current nomenclature on the "contingent" (my community) side, emu rape, originated here, or close enough to here for our purposes. the contingent objects to "tool-assisted" out of clarity's sake - it has been shown time after time that newbs will not understand what the tools or the assistance is unless it is explained to them. failure.
and "emu rape" is pretty offensive, but that is the purpose of the contingent, to place an offensive name on what is offensive to us. however, unless it is to follow the example of "gay" or "nigger" and be "reclaimed" by the ostracized community it refers to, "emu rape" will probably not do saber's job for us.
the trouble in my mind is that this is hardly the first time this has been brought up. saber's suggestion seems quite cute and apt to me, but are rapists really going to change all of their nametags from "tool" to "cyborg", especially given that saber often seems to be a member of the contingent? in my experience, they (the rapists) do things when they want to for their own self-serving reasons, much as we do.
with no workable compromise on the horizon, i have to continue to protect my people and their property, and i will do everything in my power to discredit and destroy emu rape when it is not properly labeled as such. just as in real life, no one gets arrested for talking about taboo subjects, but they do make life difficult for themselves and everyone around them when they do.
He says that after labeling ALL TASrunners "rapists", without regard to how their run was published? I understand that M2k2 is his forum and he can say what he wants, but it's also my right to call him a loony for equating "makes emulated speedruns with slowdown and savestates" with "forcibly having sex with someone against their will".
The glitch has nothing to do with rings on the screen, it just happens after you've passed the endpost if you have all the emeralds and more than 50 rings, and you've jumped in the air. The only way to pass it is to either end up going off the right side of the screen before the glitch happens (and thus causing the results to appear), or have debug enabled and press B.
I've thought for a while now that, for games that don't lag on either emulation or hardware (and also games that lag exactly the same) that it would be possible to hook into the game's vblank interrupt and stuff the correct values into the game's internal handling of the controller (basically, replacing the joypad polling routine with one that just reads from a big long table at the end of the ROM, which would consist of the TAS keypresses converted to the game's internal format, with possibly some simple compression to handle stretches of time where there is no keypress - admittedly not too common in TAS runs but nonetheless every bit of space saved would help).
Problem is, this is an enormous amount of work, although part of it only has to be done once for each suitable game (and games like Sonic 2 that lag more on hardware won't be possible without even more manual work to determine where additional lagframes are and inseting them).
