Something I found that might speed things up slightly - you know how, when you're gliding, and then you stop gliding and land on a piece of the level, you lose all of your horizontal velocity? Well, if you land on an object instead of a level piece (for example, moving platforms), you don't lose any speed and can continue running immediately. This is sort of nice for acrobatics in Final Zone while waiting for Eggman's attack cycle.
The only system I can think of off-hand that includes a checksum in the ROM is the Genesis - the two bytes directly following the product ID is the checksum (for example, Sonic 2 is D951 for the most common rev 01 version), and it's up to the game to checksum itself (many games don't bother - I recently hacked Wiz 'n' Liz to interlace mode 1 and didn't have to bypass any checksum verification). But this isn't a CRC32, so I don't think it would be so useful in this instance, since you need one system that works for all ROMs. Either use a CRC32 or an MD5 hash, I would think either one would suffice. If emulators already put the CRC32 in the movie files then it would probably be best to just go ahead and use that, then you could literally just extract the checksum from the movie file.
Rather than worrying about Good* names, we should worry about CRC32 checksums of ROMs. That way, even if you dumped your own carts, you would know that you have exactly the right one. Since I don't know of anyone else who seems to care about checksums, it wouldn't necessarily have the side-effect of 'promoting' illegal ROM distribution.
True, but that's really just Marble Zone, which can be slow and boring anyway. You can do it a bit in Spring Yard but not nearly as much of the level as MZ.
Knuckles in Sonic 1
This should be worth doing a TAS of. I'm not good enough with Sonic 1 to make a TAS, but the game does play differently with Knuckles' physics and abilities, different enough that I think it's worthy of being the first "hacked" game to be given the TAS treatment.
For my raw AVIs, I use the CamStudio Lossless codec. Best thing is, it's GPL, and while the binaries posted are for Windows, the source is available, and thus it's possible (but I don't know how practical) to port it to other OS's. It's a bit slow to encode the more you compress, but on gzip level 9 the files are quite small. I used Gigafrost's Zelda 2 run as a testbed most recently and the raw file was only 107,814,400 bytes (including mono PCM audio at 44KHz).
I think in situations like these, cheat codes should be allowed (not to supplant the existing runs, but to supplement them). It would be awesome, for example, to see someone tear through Sonic 2 as Super Sonic from the beginning (which requires the use of cheats to turn on the "all emeralds" code). I don't think we should allow the debug cheat, for obvious reasons, and the game should start from the first zone (since you have to enable level select to access the emeralds code on Sonic 2). However, in S3&K, the debug cheat would have to be used to go this route, since the only non-savestate and non-saveRAM way to get Hyper Sonic/Tails/Knuckles is to use debug and drop an S monitor, then break it. I don't think the cheats should be utilized outside of what is required to go super/hyper, obviously.
That was a fun game, I remember it as part of a Blockbuster videogame championship. I even entered it and played it way back then, but I forgot my score. Didn't come anywhere close to winning though :/
OP said Genesis games guys =P
Generally, Genesis games were programmed in 68000 assembly (although some games used a mix of assembly and C, like Ecco). In earlier Genesis games, the Z80 only handled sound samples through the DAC, while the 68k handled the FM synth. Later games used the Z80 for both FM and DAC.
There are several dumpers floating around that can handle Genesis games, but many of the oldschool grey market copiers can be a bit hard to find (for example, I just bought a 16Mbit Super Magic Drive, and I'd been looking for one for about four years now). Examples of Genesis-capable dumpers include Super Magic Drive, Multi Game Hunter (which I hear is shit), Multi Game Doctor, Double Pro Fighter, and others. There is also a dumping method that connects a cable between the PC parallel port and controller port 2. It requires a Sega CD and custom software burned to CD. This method can dump all licensed carts, even Super Street Fighter II (which is 40Mbit, and uses bankswitching, due to the fact that the Genesis can only see 32Mbit of ROM without banking). It can also dump SMS carts as an aside, you must have an SMS adaptor with pin B30 taped over or disconnected.
They're a bit expensive, but Tototek has 32Mbit and 64Mbit flash carts (the 64Mbit one can support SSF2, as well as 32X games if you have a 32X). They're a bit expensive to use as distribution carts, but they should be handy for running ROMs and testing your own homebrew code.
I'm wondering why nobody's made an FCEU version that has a 'secure' mode that does heavy CRC checking, disallows ANY ROM modification, encrypts the input movie to prevent tampering, and that stores data about the emulated NES in the movie (for example, PAL/NTSC, CPU speed), disallows frame advance/slowdown, and makes the movie completely incompatible with the FCEu that we use. That way, it would help ensure that the video output is legitimate and that it was not tampered with in any way, else the movie won't even play. Require it to output a dialog or 10 seconds of video stating the parameters of the movie, to make sure that everything is in order. Perhaps, if an emulator could be secured fairly well against using input movies with hacked ROMs, then places like SDA and TG might begin to allow only those specific emulators, as long as they could tell with near 100% certainty that the run is fully legitimate.
What little bit I've tried to convert FMV to FCM (basically just a crap SMB1 run that I did just to fool around), I found that the desyncs were usually due to lag that FCEU exhibits but Famtasia doesn't. Basically, you have to find every point in the game where it lags in FCEU, and add that many dummy frames, preferably with no buttons pressed (although you'd have to figure that out on a case-by-case basis). I also remember adding two dummy frames before the Start press or it wouldn't even get past the title screen in FCEU.
Those exact values really came in handy for me. It allowed me to finally completely fix my audio sync issues when trying to make DVD video of FCEU output. Thanks a whole bunch, Bisqwit.
I've run into this same problem too. I'm using an SMB2 run as my test footage for developing my method for making "perfect" DVD-compliant video with Avisynth. Even watching the raw AVI recorded from FCEU, as I get further through the video I notice a loss of sync. I noticed in another thread that Bisqwit posted the exact FCEU framerates, and I'm wondering if that's it. The skew doesn't seem to be that bad to me, so I'm going to try to correct it with Avisynth.
Edit: Yes, it's easily fixable with Avisynth. Merely stick this line in your script:
Well, there are two types of 'soft resets'.
The first type is that accessed with a controller key combo, such that it's programmed into the game. The second type is the reset button on the console itself. It's still a soft reset because the memory retains it's previous contents. A hard reset implies that the system loses power long enough to cause the memory to lose it's contents. If the terms are more familiar, you can also refer to it as "warm boot" instead of "soft reset" and "cold boot" instead of "hard reset".
Base for derivatives: we've got a lot of material on this site, more than enough to create impressive showreels of the best work that we've done (although it's too bad nobody has done so yet). Other examples are given, such as visuals in dance clubs, or clips in movies, possibly for commercial ends;
That's actually been one of my backburner projects, to produce a "best of" DVD series. I am currently working on a method to generate DVD-compliant video from emulator output. Of course, the best quality comes from FCEU movies, as it is a more accurate emulator than Famtasia. The basic gist is to take the 256x224 video output, do a horizontal bilinear resize to proper aspect and add borders to get 720x240, and then treat the video as fields and weave them together to get 720x480 video. I haven't worked on this in a while, and last time I did it, I experienced audio sync issues. This will generate "perfect" quality video, and should work on both NTSC and PAL (as long as you have a PAL60 capable set). I won't be making any PAL50 discs, seeing as I don't think there are any PAL50 runs.
I do have a DVD-DL burner now, so I can produce professional-quality DVD9 discs (although I'm still in the learning stages with Adobe Encore DVD). If I do this, I will make the selection of which runs to use a community project, so as to ensure that the best of the best are included. I'd probably start out by releasing a few system-specific (NES, SNES, Genesis) DVD5 discs with no big frills - basically menus and video. Once I see how well they're received, I'd probably release a "best of the best" DVD9 disc. On the latter, I'd probably offer "commentary" soundtracks to all people whose runs are featured (which basically consists of watching your run, record you talking about it, and send me the audio). If anyone could think of other extras that would be feasible to do, I'd entertain suggestions.
However, before I start any serious work on this, I'd like to gauge the interest in such an item. Would you buy one? How much would you be willing to pay for the DVD5 discs? What about the DVD9 discs? I'll say that the finished DVD9 disc would probably cost $20-$25, due to the high cost of DVD9 blanks. The DVD5 ones would be more reasonable.
Also, it goes without saying that, although it might be legal to use the runs without asking, as a show of good faith, I will ensure that I do have permission from the person who made the run, before using it. Which basically means, if any run author has qualms about the inclusion of their run, then it'll be replaced with another run.
Another idea for the DVD5s - perhaps it could be a yearly release, including the best of the new runs created within that time. So, for example, at the beginning of 2006, I could begin work on the "Best of 2005" disc, and release it after two or three months of good work.
I will say this - right now, since I don't know the interest in such a project, I'm not totally dedicated to doing it. However, if interest is largely positive, then I will probably do it. As of now, however, there is absolutely no work done on such a project, and it would probably be at least six months to a year before the first discs are done, as I'm quite anal-retentive when it comes to perfection with a video project.
Interlacing is the difference between early consoles and regular TV. The earlier consoles (everything up until the Playstation era, IIRC, with the exception of the Genesis, where interlacing was only used on Sonic 2 2-player mode) would output 60 frames of 262.5 lines (in the case of NTSC), instead of 60 fields of the same, offset such that the odd lines are in-between the even ones, but still displayed at 60 fields per second. Some newer devices can't handle a non-interlaced signal (my Pyro A/V Link doesn't seem to want to lock to a non-interlaced signal), hence the mention of maybe needing a TBC (which will turn the non-interlaced frames into interlaced fields).
I would imagine DV would be a good idea for newer systems that output interlaced signals, you can get fairly low-cost cameras that can accept analog video input and record to the small DV tapes (90 minutes max?). Depending on the camera/deck, you might have to buy a time-base corrector to record the output of any system that outputs noninterlaced video. If you're willing to spend a fairly good amount of money, you could get 'professional DV', which uses tapes that are the same size as the professional DVCPRO format, but can store something like four hours of video.
Alternately, with the same caveat about noninterlaced video, one could merely get one of those small external DVD-DL writers that have analog video inputs (although you'd get much better quality out of the DV method, there would also be more work in putting it on a DVD, if that's your goal).
The only problem with reusing a VHS tape a large number of times is that the magnetic coating can wear down, resulting in dropout (although you get dropout on new tapes too, specifically the first 5-10 minutes). The image quality shouldn't degrade too much other than for dropout (in other words, you won't lose any horizontal 'resolution' on an old tape as opposed to a new tape).
(About the screams, I think VBA unfortunately forgets to emulate one of the sound channels in SGB games, which I've noticed is also used for the explosion sounds in Bomberman games. I'll look into it, but I don't think I'm likely to figure it out unless it's something really obvious in the code.)
I'm pretty sure that the SGB allows access to the SNES sound channels - the entire credits music on SGB is much better than standard GB, and it also doesn't play correctly on VBA. True SGB emulation is really SNES+SGB emulation (with the enhanced sound offering and even the capability to run native 65816 code, as seen in Space Invaders).
Why?
Why would it be a signed byte, though? If it was unsigned, a player could get 256 men before dying and getting the game over. You can't have negative men. Why did the programmers make that variables signed?
I'd say it was shorter code for the game to use a do a BMI every time after you die, rather than explicitly checking for $FF. In the first instance, it's merely adding a BMI gameover right after the death routine. In the second instance, you'd have CMP #$FF : BEQ gameover which takes two more bytes and a few extra CPU cycles (and back then, two bytes was useful).
The only way to know would be to extensively play a game with an overclocked emulator, and compare the game physics to the original non-OC'd system.
As I said, slowdown is merely the system not having enough cycles to complete all it's calculation for that frame. Unlike modern games, when this happens on the NES, the game code generally waits for the sprite 0 hit (or IRQ with some newer mappers). This means that actual gameplay STOPS for those frames of lag, unlike modern PC games, which just drop frames without impacting the actual game logic.
There might be games that would have issues with overclocking, but I see it no different as when we document which games' movies desync on certain emulators. There will be some games that just wouldn't be allowed because the game changes too much. But I would imagine the vast majority of games would have no problems with an overclocked CPU.
Also, about the sound issue, this is an issue with hardware. I'm sure that an emulator could output audio with the proper pitch, because the CPU and sound generator could be artificially separated, while they share the same clock on hardware.
Slowdown is caused by the game not having enough cycles in one frame to do what it has to do in one frame. The only thing overclocking the CPU does is give you more cycles per frame (and, in the case of the NES, increases the sound pitch, since sound generation is on the CPU). The core game logic runs exactly the same.
As I said before, emulators that do this should store the clock rate used in the movie. That way, they can be classified by clock rate. I'm not saying that overclocked runs should supercede standard ones, I'm saying they should be accepted separately from standard ones. Plus, especially in games like Metroid, this should decrease times by a decent margin, due to the heavy slowdown at times.
Anything that doesn't actually modify the game code or data should be usable.
And by overclocking, it does that.
No, it does not. The same instructions are executed in the same order. The core game logic is untouched, since the game runs on a frame-by-frame basis anyway.
You're missing the point. The point is that only the input should be manipulated.
If that's the case, what about savestates? You're not only manipulating input, you're essentially jumping around in time, from a game perspective.
Anything that doesn't actually modify the game code or data should be usable. Of course, Bisqwit makes the final call, but that's why I support it.
Also because it was fast as hell, and free. I remember running it at full speed on my old P133, and I'm sure people ran it on slower Pentiums and even fast 486s. Same reason Genecyst and Callus were popular - they ran fast on the hardware around at the time. FCEU takes a much faster machine because it's more accurate, plus NESticle had a lot of asm.
I don't know anyone who claims NESticle to be the best emulator, currently.