View Page Source

!!! Memory observing

%%TAB What is RAM

Every game uses [http://en.wikipedia.org/wiki/Random-access_memory|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.

%%TAB RAM search

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.

[module:youtube|v=q02QSb1CgMU|align=right|w=360|h=210]
* Addresses lists hosted on tastools googlecode:
** [http://code.google.com/p/tastools/source/browse/trunk/FCEU-MemoryWatch|Memory Watch files]
** [http://code.google.com/p/tastools/source/browse/trunk/RamWatch|Ram Watch files]
* [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 [MemorySearch|how to search addresses], and [EmulatorResources/RamSearch|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 [http://www.ustream.tv/recorded/8547343|watching it on Ustream]). Here's also a nice tutorial on [http://www.fceux.com/web/help/fceux.html?NESRAMMappingFindingValues.html|RAM mapping].

%%TAB RAM watch

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. [http://www.fceux.com/web/help/fceux.html?MemoryWatch.html|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: [http://www.youtube.com/watch?v=U3aK-BATtJw|demo by bobmario511].

%%TAB_END%%

!!! Lua scripting

%%TAB Purpose

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.

%%TAB Usage

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 [EmulatorResources|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 [http://code.google.com/p/tastools/source/browse/trunk/Lua/|tastools project]. Several emulators have Lua discussions on Forums:
* [Forum/Topics/6970|NES]
* [Forum/Topics/6539|snes9x]
* [Forum/Topics/8875|Mupen64]
* [Forum/Subforum/25|Tool-assisted laboratory]

%%TAB_END%%

!!! Code disassembling

%%TAB Purpose

Old-school games we mostly play here were written on [http://en.wikipedia.org/wiki/Assembly_language|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 [http://www.6502.org/tutorials/6502opcodes.html|6502].

%%TAB Debugger

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 ([http://en.wikipedia.org/wiki/Non-maskable_interrupt|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.

%%TAB Trace-logger

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.

%%TAB Lua tips

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 [http://www.fceux.com/web/help/fceux.html?LuaFunctionsList.html|these] [LuaScripting/Registers|pages] and a breakpoint code looks like this:

%%SRC_EMBED c

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);

%%END_EMBED

%%TAB_END%%

But remember, not all emulators are that powerful yet. For now, the best choice for such tasks is [http://www.fceux.com/web/download.html|FCEUX]. See its manuals on [http://www.fceux.com/web/help/fceux.html?Debugger.html|debugging], [http://www.fceux.com/web/help/fceux.html?TraceLogger.html|tracing], and a bunch of other [http://www.fceux.com/web/help/fceux.html?Debug.html|ROM-hacking methods].

!!! Input file editing

%%TAB Purpose

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 [DesyncHelp|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.

%%TAB Specifics

Input file formats differ, so do editing methods.

* Plain text ([http://fceux.com/web/FM2.html|FM2]) can be opened and edited in a quite intuitive way with [http://sourceforge.net/projects/notepad-plus/|Notepad++]
* Binary files ([http://code.google.com/p/vba-rerecording/wiki/VBM|VBM]) require some work, since they were developed mostly to save on space, not to be edit-frinedly. Use hex editors like [http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm|Xvi32].
* There is a tool that decodes binary and allows basic editing methods - exclusively designed for that, [http://sourceforge.net/projects/tas-editor|TAS Movie Editor]. See a [/Forum/Topics/4448|Forum thread] for some information.
There is also [InputFileEditing|a guide on this method].

%%TAB_END%%

!!! High-level interface

%%TAB Purpose

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

%%TAB FCEUX TASEditor

[EmulatorResources/TASEditor] is an integrated set of tools developed for [http://www.fceux.com|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 [http://www.fceux.com/web/help/taseditor/|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.

[module:youtube|v=PZIG7HWlXG4|w=480|h=300]

%%TAB_END%%