The Guitar Hero and Rock Band series.
Not just for the 100%/FC'ing, since that's already being done by humans (even on absolutely insane custom songs). There are people who have calculated optimal scores based on star power placement and engine "abuse" like squeezing. These optimal scores are not always 100% true though (as several people have beaten the so-called optimal scores on some songs). I would think that TAS'ing GH charts would confirm or disprove those optimal scores, and might even be able to wig the engine out a bit depending on which game is being TAS'd. The only real problem with these games would be the inherent licensing issues brought on by the underlying music tracks (but this would only apply to videos of the runs themselves, and not the actual input log itself).
TAS'ing Trogdor on the NTSC version of GH2 would also prove or disprove once and for all whether it's technically possible to FC, or if the orange streak in the solo is too fast for the engine to accept the input. It's been done on PAL systems, so we know there's something strange going on with the relationship between the framerate, the strumming speed, and the note windows.
Plus, it'd be cool to see a one-man-band-TAS on a full-band game like RB or the newer GH games :P
Most programmers use the high-address vectors (think $FFxx) that jump to other addresses within the Kernal, if they use the Kernal at all. This usually reduces the chance that a new/custom Kernal would interfere. Basic ROM hasn't changed much at all, and people seem to be a lot more willing to use these addresses directly.
Agreed. While there were three main revisions to the KERNAL ROM, there was only ever one BASIC ROM in the C64 (and thus, in the C128's C64 mode as well). Even the C65's C64 mode used the same BASIC ROM (but with the fill byte changed from $AA to $FF). There was also a different KERNAL for both the SX-64 and the PET64/4064 (although neither one of these are likely targets for a TAS, as software that runs on those systems will generally run on a standard C64, good to be aware though, just on the off chance that someone encounters a game that only runs properly on either of those systems).
Here is a list of known C64 KERNAL differences.Here's another list, with an easier to read breakdown of the exact changes between the R2 and R3 KERNALs.
There is apparently also a difference in the RS-232 timing table, which would only apply if a game uses the KERNAL to handle serial communications through a user-port modem. Any game that bit-bangs for such communication would be immune to these changes.
I wasn't necessarily saying that these would be major issues, just wanted to make sure you were aware of them on the off-chance that a game requires the "old" KERNAL (which is usually R2, although the earliest US NTSC C64s had R1) to prevent color bugs. It wouldn't be an issue of KERNAL code moving around and games using the KERNAL without the jump table, but it's an issue of different KERNAL revisions using different values when writing to color RAM while clearing the screen with a LDA #$93 : JSR $FFD2 type combination. Any game that manually clears screen and color RAM is once again immune to these differences (as is likely to be most of the C64's game library outside of the first couple of years of the C64's life).
Better to ensure that these won't be problems now, before people are able to start making C64 TAS runs :P
Robocop 3 required some firmware. What file do I need?
FW is required for all games. The ones I am testing with are from the VICE 2.4 emulator (which can be found online) however any firmware for the C64 should work. The four that are required are: basic, kernal, chargen, and dos1541. They should be placed in C64\Firmwares.
Something to consider - there are slight differences in the original KERNAL ROMs available, and earlier games may have issues if they assume a specific KERNAL. I forget the specifics off-hand, but the different KERNALs handle color RAM differently when clearing the screen. That's why I say earlier games, because many games handle this themselves instead of relying on the KERNAL, and any game that handles color RAM on its own will not have issues on any KERNAL that I'm aware of.
I don't have an answer for the pops, but I do remember back in the FCEU days here, I was experimenting with making DVD encodes of runs for my own personal viewing. I had found, with Bisqwit's input, that the framerate was ever so slightly less than 60fps, yet due to the nature of AVI (or at least due to the emulator, I never figured out which was the case), the video was playing back at exactly 60fps, causing the video to lead the audio, IIRC. The solution I came up with was to determine the exact frame rate that the emulator was actually running at and calculate the proper sample rate to make the audio play back synched, use Avisynth to make the audio play at that sample rate, then resample to 48KHz. Perhaps something similar could be done with your PNG output technique to ensure the audio and video stay in sync without dropping/duping frames? Certainly a minimal pitch change from the forced sample rate and minimal quality drop from the 48KHz resample will be less jarring than even a single dropped/duped frame.
Slightly off-topic: I've not watched a lot of long Gameboy runs, but I would assume if that had been an issue for standard video dumping, that there would already be a solution. The reason I ask this here is because I'm planning on doing a non-TAS versus run with my girlfriend soon using VBA-rr as my emulator of choice (and including our live commentary as we play), and I want to make sure that I won't be having any sync issues with a 30-35 minute segment length.
Those who are massive Amiga fans as well as TAS enthusiasts may get one of their dreams in the coming days/weeks/months/however long the feature takes to solidify.
WinUAE 2.3.1 public beta thread:
http://www.winuae.net/files/b/winuae_2310b1.zip
Beta 1
!!!!!! NOTE: Re-recorder thread will be opened later. All posts related to new input recorder in this thread will disappear. !!!!!
*snip*
- "re-recorder" implemented (completely rewritten combined input/state recorder). More information coming later.
- many statefile related changes for input/state recorder compatibility, may break something else..
* WARNING: statefiles created with betas may not be compatible with future versions!
* save current track's data and density in statefile if disk drive motor was active (regenerated
raw track data/density after state restore may not be identical if using ipf or fdi images)
* state save/restore while disk DMA is active is now fully supported
* save strings in utf8 (should have been done long time ago during unicode updates..)
* useless DMAC chunk was saved in non-CDTV configurations (2.3.0)
* CD state chunks were saved even if selected configuration didn't have any CD drives (2.3.0)
* 68020 cache and prefetch pipeline saved and restored
* debugger memory watchpoints saved and restored
* save active (very rare) interrupt delays (interrupts that have been triggered but have not yet been noticed by Paula)
* mid-instruction CPU state save support, restored state CPU state is now exactly same as when state was saved (68000 CE only, 68020 CE later), previously current instruction was simply restarted (this was really complex and non-trivial task, it is only easy if you accept much higher CPU usage. Which isn't good idea...)
* full blitter statefile support in cycle exact mode, state capture/input recorder only currently. This saves blitter emulation variables, not real hardware state (internal statemachine state, latches, counters etc..) because internal structure is unknown. State capture only because it requires 100% identical state after restore (normal blitter state forces current blit to finish). This is not enabled in normal state saving because it is very difficult to keep state saving compatibility between versions when state is hardcoded to current emulation implementation.
I posted that quote about the thread, as I wouldn't want anyone going over there and posting in the normal beta thread just now, yet everyone here would be the best team to beta-test rerecording features for WinUAE, as this is pretty much the home of modern TAS development. I've also notified the EAB forum that I've informed you guys about the rerecorder, so that interested parties can assist with the beta process.
Note: I have not looked at this build of the emulator, so I know absolutely nothing about the rerecording features, other than what I quoted above.
Edit: Of course, since the new version of WinUAE is in beta testing, I would suggest holding off on using it to make actual, published runs - the input recorder and savestate functionality seem to have been recoded from the ground up. Feel free to use it for POC runs or in developing a route for an Amiga game, however. A500 cycle-exact emulation is fairly rock-solid nowadays - Toni fixes a few bugs here and there but I think the focus nowadays is more on A1200 compatibility (at least in terms of the cycle-exact emulation). Needless to say, for reasons obvious to anyone who has any knowledge about the TAS process besides than "load emulator, load ROM, load movie file" or "click YouTube video link", the rerecorder will require cycle-exact mode. Suffice it to say, trying to TAS games running under JIT mode with Picasso96 and immediate blitter enabled will probably not work yet, if ever =P
Edit: Quick statement from Toni (you have to understand, there have been lots of bad, useless bug reports in the past with the emulator as a whole, and so Toni likes to keep things a bit more organized):
There is very good reason why no talk about rerecorder yet: it is too early for public testing. It still in private testing (it already works, looking for last few glitches)
Any so called "bug report" I see will only make me annoyed. Especially if I see even one so called "recording" without using very specific methods to record it. It has very strict requirements which will be explained soon.
Don't do it if you want to see finished rerecorder.
So, basically, this is just a heads up that it's coming, DO NOT use the current version of the emulator to do any non-BS rerecording.
I know the similar glitch in 8-4, where you backtrack slightly and enter the pipe instead of jumping the pit and entering the other pipe, works just fine. I'm doing a full warpless non-assisted run, unsure if I should post the links here, it's 42:44 total and segments 3, 4, and 5 are uploading as I write this.
Doesn't seem to be, so far. I don't think it's done at the moment, so I wouldn't expect any TAS to be published just yet, but it might be interesting to see an accomplished SMB TAS'er tackle an informal run of it, to see if the more esoteric and frame-exact tricks are present (so far, the simple ones work, hatstomping, jumping from a powerup, and one time I was able to walljump in realtime). Cheep-cheep behavior in 2-3/7-3 is a little off (their vertical speed seems to slowly oscillate), and there is an issue in some places (notable 5-4 and 6-4) where parts of the firebars disappear.
Heh, I'd rather see Rock Band than Guitar Hero. But both would do just fine.
Agreed, especially since it's the same game engine (remember, I did say earlier Guitar Hero games, not III+). It'd especially be interesting to see it done with trackspeed hacks (although then they would not likely be accepted here unless it could be absolutely verified to be unhacked other than the trackspeed). My 0.1x autoplay trackspeed hacks have been fairly popular on YouTube (my GH2 Jordan 0.1x vid has over 110k views, which isn't too shabby).
Phallosvogel: You think that's impressive? Check this out:
http://www.youtube.com/watch?v=AdBcQZsnlg4
That was the 5th time he'd ever done it too. Mind-boggling.
It'd be interesting to see PS2 rerecording used to test optimal scores on the earlier Guitar Hero games (since you would then have control over squeezing at the frame level, as well as the ability to eke the maximum amount of star power from a star sustain).
As far as subtitles go, there is a DirectShow filter called DirectVobSub that can use subtitle files (sub, srt formats). This way, you would just distribute the subtitle file with the AVI, and then the user has control over them without having to download a separate subtitled AVI.
Copyright infringement doesn't have anything to do with whether or not it's free - although one might be infringing on the copyright of the person who made the run itself.
Something like this would best be distributed for free as a torrent, or for cost of postage+blank DVDs through the post. It's not so easy to do because you have to essentially massage the raw emulator AVI output into NTSC video, and then you have to account for the aspect ratio of the real console. Just merely slapping NES video at 256x224 into a 352x240 29.97fps video does not suffice.
Since SDA accepts videos recorded from a VCR, capture card, or DVD recroder, the color/frames are going to be different.
At least for NES games, that's not so certain. There is at least one NES emulator that actually emulates the composite signal, and I've done direct comparisons with captured NES video - it is almost impossible to tell which one is real and which one is emulated. I guarantee that you're going to start seeing emulated realtime NES runs showing up at some point.
Besides, the whole thing about not accepting emulated runs is purportedly to ensure that the game being played hasn't been hacked - although this is sort of misguided, given that they accept direct video output of the console, and it would be fairly simple to use a Game Genie but edit out the part where you enter the codes. I think it's about time that emulators are legitimized for realtime runs as well - perhaps one might want a checksom of the ROM used for comparison to known-clean dumps.
Thanks for the tips.
As for Sega CD, and Sonic CD in particular, desyncing on replay, my theory is that Gens continues to generate frames while performing CD seeks & reads. And those times aren't always constant.
I believe that's the way the hardware works, as a Sega CD setup is really two consoles - the Genesis and the Sega CD - running independently, and communicating with each other. Which means you may potentially break some games if you make that a blocking operation - but it really depends on practical compatibility and not hardware accuracy, in this case.
Yeah, that trick pretty much works the same in SMB2j, not at all in SMB2USA (that I know of), and it works less often in SMB3 (but nonetheles it is possible to walljump in SMB3).
Well, think of this - a coin block is one such 16x16 tile, so the boundary is either the line above the block, or the last line of the block. It shouldn't be too hard to build an accurate grid from that - it may help you to get a pixel-accurate map and build a grid on top of it. The animation on Bisqwit's site is accurate.
Here are a few examples - the extra lines I've drawn show the extended "floor" that you have to aim for. You also have to be fully hugging the wall - if you're one pixel away, you will miss the wall.
Not all of these floors are technically possible to reach, but I marked them anyway because were one somehow able to get Mario to hit the wall there, a walljump would still be possible.
I've often toyed with the idea of modifying the SMB graphics to remove the actual graphics, replacing them with markers so that one can more easily determine exactly where to hit the wall. It has to be on a 16 pixel boundary, however.
TASing isn't teachable because outside of the basic concepts, each one is completely different, and what works on one game may fail on any other game.
For example, to wall jump in SMB1/2j, you have to hit the wall exactly at a 16x16 tile boundary, and you only have like one frame to hit A and jump from there (else you will just fall down). This is really one of the more simple tricks, as I can do it about 25-30% of the time when playing a realtime game. That's the same trick that leads to the easy way to get to world 36 (as Super Mario at the end of 1-2, duck and jump, aiming to hit the bottom of the brick directly below the ceiling, and if you did it right, Mario will think he's standing on the ground for a frame, and since he automatically stands up from his duck, the wall-ejection code then pulls him in).
As others have said, Bisqwit doesn't accept hacks that make the game easier, unless it's to remove tedious repetition (for example, the SMB2j patch to enable worlds A-D without having to beat the game 8 times). Hacks that increase difficulty (look at Air, for example) or which otherwise make the hack a unique gameplay experience in its' own right (see Mario Adventure or Super Demo World) may be allowed, on a case by case basis.
Not to say that the concept of a cheated TAS run is an inherently bad one, just that it doesn't go well with what Bisqwit has consistently said is the vision behind this site. If anyone does such a run, I implore you to make it abundantly clear that, in addition to being a TAS, it uses cheats or actual game modifications on top of that.
The problem with playing TAS runs on real hardware is that you have to sync with the vblank, such that you can be absolutely sure that the controller input comes at the same time each frame, else you'll have skew that could eventually desync. Plus, you have to account for systems where the hardware lags in places the emulators don't (Sonic 1 and 2 both are great examples of this, try playing S1 Labyrinth Zone on an emulator, then play it on a real Genesis).
I'm of the opinion that it might be more feasible to hack the individual games such that, instead of reading from the joypad, your added code would stuff the proper values into the memory address that the game uses for reading the joypad - basically, replacing the input handler. This is not a trivial job in most cases, and the TAS run would have to be converted to the raw format used by the game to represent the controller input.
Not all of these floors are technically possible to reach, but I marked them anyway because were one somehow able to get Mario to hit the wall there, a walljump would still be possible.