Memory observing
Every game uses random access memory to compute everything that occurs in the game in time. Opposed to read-only memory (the game image itself that can only be read from, not written to), RAM is used as a temporary storage for all necessary variables the game processes on fly, its values are constantly changing.
By determining which address represents which in-game variable, and by observing its changes during play, you can get the exact idea of what actually is going on software-wise. This tool brings you to a higher level comparing to observing just the emulator window picture, because the latter won't let you know the exact values and their fractions, which really matter when it comes to intense optimization.
So, at first you got to find the addresses representing gameplay aspects you need: your character position, camera position, your and enemies hitpoints, objects speed, etc. Some games already have rather good sets of known addresses, others still need your effort.
- Addresses lists hosted on tastools googlecode:
- Games/List - Some games addresses are written on their particular pages
- Forum threads sometimes get posted with addresses, ask in game-specific threads, probably someone already has addresses you need
In none of those worked, you have to either ask someone to figure the addresses for you (unlikely to happen), or try finding them yourself (increases experience and provides new info).
We have huge guides about how to search addresses, and how to handle RAM Search tool in order to do that. There's an additional video-lesson to the right on how to do all that (if the sound desyncs, try watching it on Ustream). Here's also a nice tutorial on RAM mapping.
There are 2 types of dialogs designed for that, one is simpler, another is newer. Some emulators support both. For the newer dialog, refer to Emulator Resources / Ram Watch, it has a good usage guide. WCH files for it can be obtained from the links in the previous chapter.
The old-designed dialog is called Memory Watch. Here is a guide for it. It uses plain text files to store data, just with some special formatting.
See the use of frame advance and RAM adress to trigger a glitch in Super Mario World: demo by bobmario511.
Lua scripting
Lua scripting is an extremely useful tool when TASing. Although some programming knowledge is required, the user has power over things like game screen display, inputs, and memory. The following are some common applications, though the possibilities are endless.
- Displaying helpful information on screen.
- Eliminating tedious repetition.
- Creating specific circumstances for testing.
- Brute forcing a solution.
There is a good guide on Lua usage: Lua Scripting and its subpages. You would also want to see how already existing scripts work, which would require downloading the emulator you're interested in and examining it for a LuaScript folder of some kind. You can open a script with any text editor and read its description. Some scripts are game-specific others are emulator-specific, both types serve as good demonstrations of Lua powers.
Some scripts are stored at tastools project. Several emulators have Lua discussions on Forums:
Code disassembling
Old-school games we mostly play here were written on assembly language, and before compiling, the source codes used to be commented and interpretable for a developer. Then it was converted to a machine code and written on a ROM (read-only memory) to play via a console. We have no contact to developers, but we try to figure out what the original code was by reverse engineering it with the help of different debugging tools. Mostly ROM-hackers create and use them, but some TASeras are ROM-hackers as well.
As was mentioned above, you need to know what happens in the game, the more you know, the better you do, and how deep you dive is only a matter of skill and knowledge. Basically, you need to know or at least understand the language the game was written on, there are various types of assembly, for example NES is using 6502.
Debugger deciphers the executed machine code into an assembly program. It displays the result in a specific area as a plain text, you can copy it, figure out the address of the instruction just executed, see where it is in an actual ROM file, etc.
You can set breakpoints on read, write and execute by an address you want. Normally, emulation uses virtual frame borders (NMI) as a moment to generate the picture, and what happens within those frames is closed from a regular player. By setting a breakpoint to some mid-frame event, you make emulator pause between frames, displaying the commands it just ran.
There are such improvements in the debugging process as conditional debugging and symbolic debugging. The first allows to set various extra-conditions to break at, and the second uses an extra-file with names and comments manually assigned to addresses, and replaces the latter in the disassembly window with those names and comments, so that you see sane words instead of numbers.
This tool dumps all the code executed to a special field or to a file, while debugger shows only a limited part of deciphered code. You can then track how the actual events developed, trace how the values changed and why, especially if you turn on logging of memory registers and other side stuff.
You can log as much code as you want at one sitting, but it's advised to still limit it to be able to observe with no problems then. Trace-logger can also consider breakpoints and symbolic debugging.
Some emulators allow to register memory as the program runs, which means you can fire your own Lua commands not only on frame borders, but once the code you choose gets executed, read or written.
Memory library for Lua usually is implemented like is documented on these pages and a breakpoint code looks like this:
function CounterBreak()
ObjCtr = memory.getregister("y")
if ObjCtr > 0x16 then
gui.text(1, 9, string.format("%02X",ObjCtr))
emu.pause()
end
end
memory.registerexecute(0x863C, CounterBreak);
But remember, not all emulators are that powerful yet. For now, the best choice for such tasks is FCEUX. See its manuals on debugging, tracing, and a bunch of other ROM-hacking methods.
Input file editing
You can directly edit a movie input file. You can change things like header information, or you can change input directly. The idea is to change some input earlier in the movie without changing whatever comes after it.
Here's the catch: It doesn't always work. In fact, it usually doesn't work. Since games are often dependent on previous input or condition, changing something in the past may cause the rest of the movie to fail to sync. You can correct the desyncs case by case, but often there will be many and it is too time-consuming to do.
Input file formats differ, so do editing methods.
- Plain text (FM2) can be opened and edited in a quite intuitive way with Notepad++
- Binary files (VBM) require some work, since they were developed mostly to save on space, not to be edit-frinedly. Use hex editors like Xvi32.
- There is a tool that decodes binary and allows basic editing methods - exclusively designed for that, TAS Movie Editor. See a Forum thread for some information.
There is also a guide on this method.
High-level interface
Almost all concepts of the tools used by TASers were not originally created by them. TASers just took already existing tools and improved them all they could. That served TAS purposes for quite some years, but as tool-assisted speedrunners get more experienced, the whole community's level raises along with standards. Older tools can't provide enough efficiency to use new methods up to their maximum. And a moment comes when old-school TASing methods are considered obsolete, once there appears an interface originally developed by TASers for TASers.
High-level TAS interface is an interactive integrated development environment. It includes all basic tools constantly used by TASers, optimizes them, provides smart automation to get rid of primitive routine old tools require, adds new features and introduces new methods. Emulation and editing are done on fly, within one dialog.
Advantages of such interface being developed by TASers from scratch:
- Considers actual TASer's needs to begin with
- Allows deep testings by direct users (the fact that successful TASing implies being a perfectionist helps to test the hell out of all tools)
- Gets fast and abundant feedback
- Gets fixed and re-released constantly
- Newbie-friendly, in spite of its power
Reasons why would users need an all-in-one dialog are rather obvious:
- Low threshold of joining TASing
- Less routine
- Faster work
- Higher abstraction
- Release more mental resources
- Concentrate on gameplay
- Discover newer TAS aspects
EmulatorResources/TASEditor is an integrated set of tools developed for FCEUX in order to make TASing both easier and more efficient. This is achieved by switching from Input rerecording to direct Input editing, and by visualizing all important aspects of TASing process. Playing videogames in Taseditor resembles both interactive programming and drawing notes by mouse in a music editor.
The critical feature of TASEditor interface is ability to draw input presses by mouse clicking or dragging. This involves a table which cells represent those presses: frames and buttons. All current areas are greenzoned, which provides fast navigation in both directions. Extra sufficiency is granted by moving all basic navigation controls to the mouse wheel and middle button (scrolling, advance/rewind, pause/unpause).
Old-school tools evolved or improved:
- Savestates -> Branch tree with slot cards; separate Undo system
- Lag counter -> Red-colored lines in the table
- Autofire settings -> Editable and switchable input patterns
See a complete manual on TASEditor usage, with a TAS beginner's guide included. Search for "FCEUX TASEditor live session" on YouTube to see more examples of its work.