Title

TAS Editor 1.01

Welcome to the TAS Editor Manual!

Taseditor is an Integrated development environment dedicated to TASing.

Playing videogames in Taseditor resembles both interactive programming and drawing notes by mouse in a music editor.

Beginner's Guide | Reference | TAS Editor Inside
If you're seeing the Manual for the first time, please study this whole course | Look here when you need to know comprehensive specifications about limits and possibilities of TAS Editor | Read these docs when you wish to learn details of the system
Introduction Program Interface TASing Process TASing Methodology Program Customization Advanced Features | Glossary Controls Navigation Operations Lua API FAQ Speedrunning Synopsis | Ideas Implementation Mistake-proofing FM3 format

Author of TAS Editor v1.01: AnS

Assistance in testing: feos

Author of this Manual: AnS

English translation: AnS, feos

Created with the Personal Edition of HelpNDoc: Free HTML Help documentation generator

© 2011-2013 AnS


Beginner's Guide

Beginner's Guide

This part of the documentation is presented in the form of a textbook on TASing.

It explains the practice of using Taseditor and describes the mechanism of conventional TASing methods.

The course will be useful both to people who wish to learn TASing and to already experienced TASers who are open to new trends and wish to improve their knowledge.

Introduction

General overview of TAS Editor's goals and features

Program Interface

Learning the fundamentals of the program usage

TASing Process

The author's vision of the competent working process

TASing Methodology

Dissection of the Input improvement methods

Program customization

Detailed review of all settings

Advanced Features

Describing the additional possibilities

Created with the Personal Edition of HelpNDoc: Full-featured Kindle eBooks generator


1. Introduction

Beginner's Guide ››

Introduction

TASing – the process of creating an extraordinary game playthrough. For a true TASer, just simply beating the game is not enough. You must do something unique, something that would justify the use of tools.

And that requires a non-standard way of thinking. During a regular playing, almost entire flow of our thoughts is determined by the gameplay rules, and those who try to question the rules are quickly fined with a game over and other means. These trivial psychological methods help the game to direct player's fantasy to an intended path, giving him a credible atmosphere of integral world and keeping him within a craftily devised comfort zone.

So, to create an extraordinary playthrough, TASer needs to both use emulator tools masterfully and be able to mentally abstract from the original game rules, while still obeying them physically (because TASing is not cheating, we won't influence the game other way than by joypad input).

Early TASing, just as regular speedrunning, was not too far away from the "normal" gaming process. TASer simply launched an emulator, switched on buttons logging and played a game, saving and loading often enough to fix the most obvious mistakes, slowing down the gameplay at the most intense moments, thus compensating for the slow reaction of the human organism.

The ability to fix mistakes emancipates man's imagination and incites him to experiment. Illusions of the game realm now confine his mind much less than before. But real-world stereotypes still affect his thinking. For instance, if a harmful object usually kills you, it's only natural to assume it always kills. But in truth it may appear to be killing only at even frame numbers, or when the subpixel value is equal to zero. But how would you guess it using only savestates and slowdown?

You have to stop being a gamer and become a researcher. And there are tools made exactly for this mental transformation.

A huge breakthrough in the TASing history was the introduction of Frame Advance – a frame-by-frame emulation. Now when you're TASing, the game is constantly being held paused, thus allowing to analyze every in-game aspect separately. Before, even with a strong slowdown the game still appeared as a coherent stream of events. The stream that the player had to perceive as a complex emotional cocktail. And now with frame-by-frame play TASer can mentally isolate any given event of the current frame. This drastically changes the principles of consuming an in-game information. Material world stereotypes don't dictate how to act in the virtual world anymore, and you see the game more objectively, thus finding imperfections and loopholes in its rules.

Of course the game still keeps trying to impose typical behavior templates, and they are harder to resist when you're newbie rather than experienced TASer. That's the main reason why a skilled TASer can beat someone's speedrun (even his own old TAS) – not because of handling the tools better, but because of "Déformation professionnelle" that helps to notice vulnerabilities in games.

Many more TASing tools were invented since then, but the very way of interaction between a TASer and a game remained the same. Using rerecords, TASer edits Input in the same succession as the flow of in-game time. This linearity of TASing process builds certain limits in TASer's thinking. When you get used to receiving the game reaction on each button press, you involuntarily associate yourself with a game character. This makes it harder to look at the events from an outsider's viewpoint. And yet a TASer is expected to have the most objective point of view possible. Thus we need further transformation of TASer's way of perception.

The development of the toolset named "TAS Editor" aims for 2 main goals:

  1. to lower the threshold of joining TASing
  2. to raise the objectivity of gameplay analysis

The first goal is achieved by detailed visualization of all major aspects of TASing.

The second goal is achieved by switching from linear recording of movie segments to non-linear Input editing. The higher level of abstracting from in-game rules is reached by giving the TASer the following new abilities:

  • changing Input in any arbitrary order (not just in the order the events flow in the game) – thanks to Piano Roll interface
  • watching game events in an arbitrary order (not just frame by frame) – thanks to Greenzone
  • emphasizing the Cause-Effect relation between Input and its remote consequences (not just the nearest ones) – thanks to Turbo-seeking
  • enforcing custom logic of the movie segmentation (not just dividing into TV frames or into in-game levels) – thanks to Markers

In addition, TAS Editor 1.0 developed some old TASing tools up to a new level:

  • Lag log – evolved from Lag counter
  • Input log – evolved from Input Display
  • step-by-step undo – in addition to movie state reloads
  • inbuilt editor – in place of hex-editors and a Notepad
  • auto-identification of current logical segment – in addition to current frame number display
  • Selection counter (ruler) – in addition to frame counter
  • patterns – in place of Autofire settings
  • Superimpose – in place of Auto-hold

When launching Taseditor, get ready to control the game from bird's eye view. The following chapters of this tutorial will explain you almost everything a prolific TASer needs to know. If you already have an experience in traditional TASing, some learning aspects should come easier, but some may appear more difficult to you than to a newcomer. Either way, try to finish the whole Guide, and you will likely learn a thing or two about TASing in general.

One of the most unconventional features of TASing with Taseditor is the stress on mouse control. Mouse allows high speed of Input editing and unparalleled convenience of Playback navigation. Even though most of Taseditor functions also have keyboard shortcuts, the comfortable work would be impossible without a mouse.

The gamepad is useful when you need to quickly record an Input without caring about accuracy. But most of his time TASer spends on various manipulations with once created Input. And here the mouse or keyboard becomes much more handy than gamepad. For example, using a key combination you can move any part of Input one frame back or forth. And when you need to adjust the jump height (the duration of holding the A button), it's easier to do it with single click, than to switch Recording on and retype the whole range of frames.

Nevertheless, it's still possible to work in Taseditor the same way people were TASing before. The program interface supports all essential aspects of the traditional TASing method. If you were to use the TAS Editor window only as an informational panel left in a corner of the desktop, you probably would not even notice any difference from usual flow of TASing. It can be good reason to smoothly move from the old method of TASing to the new one. At first you may only like some accessory features of Taseditor, such as the Lag visualization or the Branches Tree. Then you'll need some Input copy/paste, and Taseditor is better alternative to an external editor. After some time you'll notice that direct Input editing turns out faster than rerecording.

Advantages of the new method reveal themselves quicker when you're making a TAS controlling 2 and more players simultaneously. In old times people invented plenty of hacks and workarounds to make such kind of TASing easier, e.g. binding several buttons to one key, using "Auto-hold", macros and custom multitracking scripts. Now all of this is irrelevant with Taseditor, because here TASer does not play the role of a gamer that associates himself with the controlled character. Now you are not playing the game, you are meditating over the decomposed continuum of the game, while creating a scenario of events via Input. And thus it's does not matter whether you control 1 character, or 2, or many.

Taseditor was also designed to reduce the rut. There are always lots of tedious recurring activities in TASing. Surely, the program won't save you from the necessity to test all possible branches of gameplay development, but it automates some actions and increases the efficiency in many little things, allowing TASer to keep patience longer than during raw TASing.

Interesting facts:

  • During the development of TAS Editor the actual programming took less time than was spent on figuring out the ways to improve the TASing process.
  • Most of the actions in Taseditor can be done multiple ways.
  • Any operation can be undone and redone.
  • You can totally ignore any part of Taseditor's functionality, using only the features you actually like.

Special attention was paid to user interface. When you gain enough experience, you'll be able to do most of things mechanically, staying focused on the in-game situation analysis.

If you happen to get a nice idea how to reduce the rut some more, feel free to post on TASVideos forums. Many ideas implemented in TAS Editor were first voiced on these forums as "dream tools".

Besides the new approach to TASing, Taseditor offers simple means for organization of your working process. Because of unsystematic approach to TASing many newcomers waste their time ineffectively, dissipate the effort and get tired quickly, then start to save the energy by reducing the amount of tests. As a result, they end up with a very suboptimal TAS. Then, as the time goes, they acquire a set of methods and habits, become experienced TASers. But every newbie had to learn by his own mistakes. In this Guide we will try to formulate a clear notion on a methodical TASing (both traditional and new), so that newcomers can realize the essence of the process faster.

Working with Taseditor is pretty similar to an interactive programming using an interpreted language. You just edit the code and instantly see the result of its execution on the screen. TASer can either immediately observe the effect of his interim actions, or he can get carried away by the construction of a code section and watch the result only after the section is finished.

Programmers have the valuable ability to increase the code readability with comments. It allows to keep more clear picture of the project in mind, and proceed without constant re-inspection of results, because in most cases the result is rather predictable, when the context is known. Also, good code readability allows to quickly refresh all necessary memories when you return to a project delayed long ago. Granted that this project was well documented.

Taseditor encourages documenting of TAS projects on the fly – you can write comments, assign clear names to structures (patterns and Input sections), test different code versions in separate branches of the repository (see "Branches Tree") and efficiently work in co-authorship. And no, there's no strict conventions to follow. You set your own rules for when and how to shape your project. For example, if you didn't hesitate to describe a trick used in the first level, in next levels you'll be able to quickly duplicate the trick's Input by several key strokes. If you didn't – you'll have to search the trick location manually. In simple TASes you can disregard comments and any long-term plans, but in complicated projects this program functionality should be very appropriate.

TASVideos.org site supports uploading and publishing Taseditor projects (.fm3 files), so you can publish not just the TAS movie, but your groundwork as well, encouraging the spirit of openness and mutual aid. If you don't want to share, export the data to .fm2 format and upload that.

FM3 files are played back by FCEUX emulator since version 2.2.0 the same way as FM2 files. Older versions of FCEUX can also play such files if you change the extension to fm2.

Next chapter: learning the basics of the program usage .

Created with the Personal Edition of HelpNDoc: Easily create iPhone documentation


2. Program Interface

Beginner's Guide ››

Program Interface

This chapter describes the program interface and ways of interacting with it.

The description uses many specific terms, so make sure you know the Glossary before starting the read. Also, it's advisable to run Taseditor right now, to be able to check everything you read in practice.

To enter Taseditor do the following:

  1. launch FCEUX emulator
  2. load any game ROM (File -> Open ROM)
  3. open Taseditor window (Tools -> TAS Editor)

When you engage Taseditor, the game is reset, and the emulator pauses. It shall stay paused as you TAS, to prevent the game from urging you on and distracting from analysis of information.

While TASing in Taseditor, a considerable part of the desktop is covered by the very Taseditor window. Emulator window is used for picture output, and you'd better scale it up to 2x size, so you won't miss a tiny detail even at a cursory glance. During your work you'll have to move eyes between emulator window and Taseditor window (mostly contents of the Piano Roll). So put those windows close to each other. The remaining space of the desktop can be populated with RAM Watch window, Lua console, etc.

You can adjust the size of TAS Editor window by dragging its edges with the mouse. The size and position are automatically saved and restored at next launch.

The window caption displays the program name ("TAS Editor") and the name of current project. If there are any unsaved changes, an asterisk is added to the end of the text. Besides, when the Input Recording mode is on, the word "Recording" appears in the window caption.

The main menu of the program is similar to one found in text editors like Notepad.

The File item is responsible for all file operations – creating a new TAS project, opening an existing file, saving, data importing and exporting. There's also a "Recent" sub-menu that stores direct paths to recently used projects.

The Edit item contains functions that let you edit TAS movie like a simple text file or a table file. Most of those functions can be accessed through standard key combinations, such as Ctrl + C, Ctrl + V and others. They will be reviewed later.

The View item allows to adjust the program appearance. Besides, here you can open the "Find Note" window, used to search text in Marker Notes. All of that will be described later. Until you study the Chapter 5 of this Guide, it's recommended to keep default preferences.

The Config item stores the rest settings, e.g. project auto-saving timer, the number of undo levels and other features that will be described during the learning flow. Don't change those settings for now.

Finally, the Help item contains the link to local copy of this Guide and the "About" window. Here you can also switch on/off hints (tooltips).

To the right of the main menu there is the Pattern item, displaying the name of current pattern. Patterns are just templates for speeding up the Input creation. They will be described in Chapter 6 .

Contents of the TAS Editor window can be divided into 2 parts – the workspace (Piano Roll) to the left and the Toolbox to the right.

Proceed to the Piano Roll description

Created with the Personal Edition of HelpNDoc: Free PDF documentation generator


2.1. Piano Roll

Beginner's Guide ›› 2. Program Interface ››

Piano Roll

Taseditor's workspace is similar to the interface found in many music-sequencing programs. Piano Roll is a table containing the most necessary data about the edited project. Users can both observe that data and edit it by mouse clicks on various cells of the table.

If you just opened the Taseditor window you will most likely see an empty project that contains only the starting (zeroth) frame of the movie. So, before you begin any experiments, you should temporarily unpause the emulator to let the movie reach at least the title screen of the game, the point where players can already affect the game with buttons Input. By default the hotkey to pause/unpause emulator is the Pause key on the keyboard, but in Taseditor you can use middle mouse button (the wheel) instead. Try watching the running game for a couple of seconds, then again press the Pause key or make the middle-click (anywhere) to stop emulation.

During the emulation, Piano Roll contents become filled with the information about the processed frames. Each line in the Piano Roll list is responsible for a single frame. The index number of the frame is shown at the beginning of the line, the numeration goes top-down. When the window size is not enough to display all the frames, the list gets a vertical scrollbar.

By the color of each line you can tell the following data about the corresponding frame:

  • Pale (almost white) lines stand for frames that are outside of the Greenzone. This means that the emulator haven't processed these frames yet and thus it knows nothing about them. For example, if you import some finished movie into Taseditor, at first Piano Roll will display all frames in whitish colors, before running through them. In the above picture such lines begin from the frame 21, because the Greenzone ends at the frame 20.
  • Green and red lines mean that those frames are contained in the Greenzone, the emulator has already played back that part of the movie, and you've already seen on the FCEUX screen what happens with the game during these frames. Lag frames are marked red, otherwise there's no difference between red and green lines.
  • The light-blue line (frame 18 on the picture) shows the currently emulated frame. Events of the frame are displayed on the FCEUX screen at the moment. This is always a sole line. In this Manual we will call it the Playback cursor. When emulator is paused, the Playback cursor stays at the same frame, and while emulation the cursor runs down, leaving the trail of green and red Greenzone frames behind. You can put the Playback cursor at any frame of the movie to see the game events of that frame. To do that, click the very left column of the Piano Roll (the column where the blue triangle pointer travels down) in the line you wish to observe – the blue pointer will jump to the chosen line along with the Playback cursor, and the FCEUX window will update accordingly, showing the in-game state of the frame. Now, if you don't let go of the left mouse button, you can drag the light-blue cursor up and down.
  • The dark-blue line highlights the selected movie segment. The actual color may differ depending on your Windows settings (the Visual theme chosen). Piano Roll lines become selected as you left-click on them. In the above picture the single frame 27 is selected, but you can select any number of frames. To select a range of frames, click on the number of the first frame and stretch the selection by dragging the mouse up or down. Note: Piano Roll lines will also be selected by clicking on the Input (i.e. almost any other column), but the column with frame numbers is specifically dedicated to working with the Selection. In this Manual we will call all dark-blue lines the Selection, and a single selected line will be called the Selection cursor. Unlike the Playback cursor, the Selection cursor isn't tied to the game state. To totally remove the Selection you could right-click the number of a selected frame and choose "Deselect" in the context menu, but usually there's no need to remove the Selection left from previous operations with the movie, because the next operation will automatically bring the Selection cursor to a new place.
  • A purple line appears for a brief moment when you use the Undo feature. This way the program shows you the exact place of the reverted changes. A huge convenience of Taseditor is that absolutely any change can be reverted with the standard key combination Ctrl + Z, so don't be afraid to experiment.

To start adding and changing the movie Input, click cells of those columns to the right from the column with frame numbers. If you click an empty cell, a symbol corresponding to the real joypad button will appear there.

A – A button

B – B button

S – Select button

T – Start button

U – D-pad Up

D – D-pad Down

L – D-pad Left

R – D-pad Right

If you click on an occupied cell, it will become cleared, and the corresponding button will be considered released on that frame. There is no other button states except these two: either pressed or released.

At first it might not be very trivial to correlate these 8 symbols with plastic buttons of a real joypad, but try pressing the first player input keys (set in your emulator) while you are in Taseditor. As you tap the buttons, the corresponding letters will flash in the Piano Roll Header, and you can easily associate the columns with buttons.

When working in Taseditor, the most of time is spent on that very process of setting and removing buttons at different frames. This way you form the sequence of button states, which is then fed to the game and reflected by actions of the game character(s). For example, if you put the letter "A" to a chosen Piano Roll cell at the middle of Super Mario Bros gameplay, Mario will perform a low jump, because a short A button press occurred in the movie. And if you set several "A" symbols in a row (vertically), Mario will do a high jump, because A was held longer.

Every time you change the Input above the line with the Playback cursor, the light-blue cursor steps back (up in the Piano Roll) also clearing some part of the Greenzone. This happens because the change of Input leads to a change in the game events, so the game data memorized inside the Greenzone becomes irrelevant. Thus after you change Input you need to replay some frames of the movie again – either by unpausing the emulator, or by manually dragging the Playback cursor to the frame of interest – and you will see results of the latest Input changes on FCEUX screen (and also restore a part of the Greenzone).

Besides, you can hold the right mouse button and roll the mouse wheel down to move the Playback cursor to the needed frame manually. Wheel-based navigation is the most responsive way to observe a little segment of the movie. You may use a single hand, and the mouse pointer may be anywhere, e.g. it may be left over the edited Input cells. Try this method, it's a very effective way to rewind back and forth. Just hold the right mouse button with one finger and roll the wheel with another finger while looking at the FCEUX window.

In addition to single cell clicks, you can also change button states in many frames at once. For instance, if you want the R button (Right) to be pressed for 20 straight frames, you don't have to click all 20 cells. You can just click on one of them, hold the left mouse button and move the mouse cursor up or down – it will leave a trail of symbols, thus you will draw a vertical row of buttonpresses. Similarly, you can quickly erase a row of symbols by clicking the first one and moving the eraser up or down. As you may notice, erasing starts when you click an occupied cell, and drawing starts when you click an empty cell.

Moreover, you can hold the Shift key before clicking on the Input to spread the effect of the click across all frames between the point of click and the Selection cursor. For example, you can set "R" in the first frame, then scroll the Piano Roll to the end, hold Shift and set "R" in the last frame – the R button press will appear in all frames.

There's one more way to mass set or mass remove buttonpresses. First, select several frames, for example, the 5th, the 10th and the 20th (to do it you have to hold Ctrl while clicking on numbers 0000005, 0000010 and 0000020). Then click on the "L" letter in the Piano Roll Header. If the selected frames didn't have the Left button symbols, they will get it. And if all of the frames had the Left button already pressed, the click will clear it.

Later you will find a few other ways to edit the Input, but these were the main ones. At first it might look unnatural to draw buttonpresses with the mouse instead of simulating them using keyboard keys. But this discomfort feeling will disappear soon after you devote a few days to Taseditor.

When drawing the Input you've probably noticed that previously drawn letters have different color, and as you add new buttonpresses the old letters change their color from orange to violet and blue, eventually becoming standard black. This is one of experimental features of Taseditor, called "Hot Changes". It was invented to unobtrusively increase TASer's awareness about recent changes. Every time you modify the Input, the latest buttonpresses receive the hottest color (bright orange), and all the previous edits cool down by one level, becoming less bright.

Because of the coloring, even a cursory glance on the Piano Roll is enough to get the idea which buttonpresses were added just recently and which were set long ago. Also, you can see which of them were recently removed (they are replaced with a dash).

If you don't like this feature, you can disable it, but within this Guide we'll imply that you have the "Hot Changes" enabled.

The narrow column to the left from the column with frame numbers is not just for dragging the Playback cursor. It also displays various informational icons. The blue arrow pointer always points to the frame where the Playback cursor is now. The green arrow pointer shows where the Playback cursor was before the Input above it has changed. And the digit cards in this column indicate Bookmarks, they will be described later.

The yellow marks on the numbers of some frames (frames 12 and 22 on the above picture) are called Markers. Besides the yellow color, they can be recognized by the wide font of the frame number.

Markers are meant to facilitate the movie navigation and improve TASer's self-organization. You decide how to use them on your own: whether to put them at the beginning of each level or to mark every jump, shot or any in-game event. Essentially, by setting Markers you logically break your movie down into sections, and then you can cross the movie not just by jumping from frame to frame, but from section to section. This allows you to interpret the movie on a higher level of abstraction.

Such structuring helps to keep a precise image of the entire movie in mind. That kind of an image exists in each TASer's mind, but usually it's rather fuzzy – we remember a rough sequence of the evens, but omit the details (because most of time they are insignificant). When TASer turns emulator off, the image starts to gradually become vague and forgotten. Thus at the next session one needs to re-watch his own movie from the beginning in order to refresh memories, figure key events, arrange priorities and, in general, mentally prepare for resumption of TASing. Sometimes this is needed even more often – depending on the complexity of the TAS. That's why it's recommended to consolidate that image by setting real Markers, not just in your mind but in actual movie.

A Marker can be set at any frame. Unlike the Input, Markers don't affect the game events. There are several ways to set Markers:

Example 1. Double-click on a frame number. If there was no Marker at this frame, it will appear there. If the Marker already exists, you can drag it while the left button is still held after the double-click. This way you can move any Marker to a different frame or simply dump it outside the Piano Roll, thus removing it from the movie.

Example 2. Select one or several frames by clicking the frame number(s), then click the "Frame#" label in the Piano Roll Header. If some of the selected frames didn't have Markers, they will all become marked. If all of them were already marked, all the Markers will be removed. This way you may mass set or mass remove Markers the same way as Input.

Example 3. Select one or several frames in the Piano Roll, right-click on any of the selected frame numbers and choose "Set Markers" or "Remove Markers" in the context menu. This is the slowest way, so the other two are more preferred.

Any Marker operation may be undone (Ctrl + Z) anytime, just like any Input operation.

Markers are automatically numbered by the order they are located in the movie – top-down from first to last. In the upper left corner of TAS Editor window you can see the number of the Marker that is located just above the Playback cursor in the movie (light-blue "Marker #" label). This label both informs you and serves as a button for auto-scrolling. E.g. if you left the Playback cursor in one part of the movie and scrolled the Piano Roll far from that point, you can immediately return to the light-blue cursor anytime by clicking the "Marker" label (or tapping the Shift key twice). You are definitely going to need this feature when editing large movies.

A similar button can be found in the lower left corner of Taseditor. The "Marker #" label of a dark blue color (the same color as the Selection cursor) displays the number of the Marker located just above the Selection. If you click this label, the Piano Roll will automatically jump to Selection. This button is going to be used as often as the upper one. Its keyboard alternative is tapping the Ctrl key twice.

It should be easy to remember that the Shift key is almost always used to control the Playback cursor, while the Ctrl key is to control the Selection cursor.

If both Playback and Selection cursors are under the same Marker, the numbers in both corners will obviously be the same.

Markers can do more than just divide the movie into logical parts. They may also contain text records (comments and work notes). The Marker Note is displayed right near its number. The upper edit field contains the Note of the Marker above the Playback Cursor, and the lower field shows the Note of the Marker above the Selection cursor.

By default, every new Marker contains an empty Note. When you create a new Marker by double-click, the lower edit field automatically becomes active, because the Selection cursor points to the just marked frame. So you may quickly type any text for the Note of that Marker and then resume your work with the movie. Text changes are saved automatically.

You can edit an old Marker Note in any of the following ways:

  • Put the Selection cursor to that frame and click the lower edit field to activate it.
  • Simply double-click on the Marker, and the lower edit field will activate automatically.
  • Put the Playback cursor to that frame and click the upper edit field to activate it.

When typing a Note, press Enter or just click any unrelated element of TAS Editor window to finish editing. If you changed your mind, press Esc to cancel the editing. All the controls when editing Notes are listed in the Reference .

It is recommended to enter Notes when creating Markers, so you won't forget why the Marker was set there. This won't take much time if you set Markers by double-clicks and type laconic messages at the same second.

Proceed to the Toolbox description

Created with the Personal Edition of HelpNDoc: Full-featured Documentation generator


2.2. Toolbox

Beginner's Guide ›› 2. Program Interface ››

Toolbox

The Toolbox consists of 7 sections:

  • Playback
  • Recorder
  • Splicer
  • Lua
  • Bookmarks
  • History
  • Selection cursor navigation buttons

The top section is allotted to the Playback controls. The Playback is the component of Taseditor dedicated to handle game emulation: keep it paused, replay in any direction, rewind to desired frame and so on. It allows to treat video games as straightforwardly as if they were regular video recordings, disregarding the interactivity element inherent to them.

There are 5 buttons at the top of the window.

The "||" button (pause/resume) is simple graphical analog of the Pause Emulation hotkey. When you click it, the game emulation either pauses or resumes. However, if your mouse has a middle button, it's easier to press it instead of clicking the "||" button, in this case you won't need to move the mouse cursor to the Playback section.

The ">" button (step forward / advance 1 frame) moves the light-blue cursor 1 frame down, forcing FCEUX to emulate one frame if necessary. You can either click that button or click and hold it to make several steps forward. This button's keyboard analog is Shift + Down. If your mouse has a wheel, it's easier to hold the right mouse button and scroll the wheel 1 step down instead of using the ">" button.

The "<" button (step back / rewind 1 frame) moves the Playback cursor 1 frame up, displaying the previous frame's events in the FCEUX window. You can hold the button as well, when you wish to go several frames back. This button has its hotkey Frame Rewind (mapped to Backspace key by default), and has a keyboard analog: Shift + Up. If your mouse has a wheel, it's easier to hold the right mouse button and scroll the wheel 1 step up instead of using "<" button.

The "<<" button (fast rewind) also moves the Playback cursor back, just not by 1 frame but by multiple frames at once. This button moves the light-blue cursor to the frame where the nearest upper Marker is located. In the above picture, if you press the "<<", the light-blue cursor will jump to frame 12 (where the Marker 1 is set). Using this button you may quickly go back to the beginning of the edited segment or to any other past moment of the movie. The keyboard analog for this button is Shift + Page Up. You can also hold it – the light-blue cursor will rapidly jump on Markers up in the Piano Roll, and in the meantime you can look for the desired fragment of the movie by watching FCEUX screen.

The ">>" button (fast forward) jumps on Markers forward. In the above picture, if you press the ">>", the light-blue cursor will jump to frame 22 (where the Marker 2 is located). With this button you can rapidly skip to the game events forward in the movie. But in case the next Marker is out of the Greenzone range, emulator would need some time to process the unknown frames, so such jump may take some time. This button's keyboard analog is Shift + Page Down. You can click and hold this button as well.

As an experiment, try to make a test movie of about 1000 frames in size and set a dozen of Markers, one per every 30-50 frames. Then hold Shift and tap some Page Up / Page Down keys to feel the convenience of the fast scrolling. Alternatively you can roll the mouse wheel while holding the Shift key.

Below these 5 buttons you can see a progress bar and three checkboxes.

The Progress bar helps to estimate the time needed for Playback seeking. Immediate jumps to any frame are only possible after FCEUX emulated the game up to the target frame by applying your movie as a game Input to get the actual game state for the frame. After the actual game state was rendered at least once, it is saved into the Greenzone, so next time the emulator can instantly jump to that frame, granted that Input above the frame didn't change. If the Input was changed, a new emulation attempt is required, because even the smallest change in buttonpresses may cause serious changes in the gameplay chronology. Thus after every such change the Greenzone is automatically truncated, removing the data of all those frames that might be affected by the new Input. These frames must be emulated again, and it takes some time.

So, when you send the Playback cursor to a frame far from the Greenzone, instead of immediate jump the light-blue cursor starts seeking to that frame. A shadow of the light-blue cursor will be blinking at the target line of the Piano Roll, and the game images on the FCEUX screen will rapidly change as the Playback cursor runs to the target.

In this case you'll have to wait. The seek time depends on the distance between the target frame and the end of the Greenzone, on your computer power and a few other factors. The progress bar helps to estimate the waiting time. If you don't want to wait, left-click on the progress bar (in addition to being an indicator, it's also a button) or use the Cancel Seeking hotkey (Esc by default). Then the target frame will quit blinking, the light-blue cursor will stop and the emulation will be paused.

While Playback is seeking you may change the target by clicking on the desired frame row in the icons column of the Piano Roll. If you pause the emulator during seeking, the light-blue cursor will freeze and the target frame blinking will slow down, but the seeking won't be cancelled – when you unpause, the Playback cursor will continue running to the target and stop automatically after hitting it.

This Progress bar is also used when loading and saving Taseditor project files to disk.

The "Turbo seek" checkbox allows to change the seeking speed. When the Turbo is on, FCEUX emulates the game on the highest speed possible, reducing the seeking time tenfold. So, if you seek to a distant frame, check that option. But during the TASing process its often necessary to see all the intermediate frames, not just the last one. In such cases you should uncheck the checkbox and maybe even slow down the emulation with the - and = hotkeys to ensure you're not missing any important detail of the gameplay.

The "Follow cursor" checkbox forces the Piano Roll to follow the movement of the Playback cursor and autoscroll the view so that the light-blue cursor is always visible. This allows you to observe the Input played back when the emulator is unpaused. But when you edit the movie you should uncheck this option to prevent the Piano Roll from running away from the edited spot.

The "Auto-restore last position" checkbox makes the Playback automatically start seeking when the Playback cursor was moved back by the Greenzone. Every time you change an Input, the Greenzone is truncated after the first changed frame, forgetting old events that became irrelevant after that change. The Playback cursor must always be inside the Greenzone, so it steps back along with it. With the auto-restore checkbox you can instantly see new events on these frames. When the checkbox is checked, any Input modification triggers the replaying of the changed segment, helping you to compare different scenarios of the game events.

Thanks to auto-restore, TASers can focus on Input editing and rapidly go over many approaches to playing current segment of the movie. This method of TASing will be described later.

Below the Playback you can find the Recorder section. The Recorder is used to record buttons Input from keyboard (or gamepad) into the movie, just like in regular playing using any emulator.

The "Recording" checkbox turns the Recording mode on and off. Before you start recording any physical keypresses, make sure the Playback cursor is on the frame you want to record from. Then either press the "Toggle Read-only" hotkey (Q key by default), or click the Recording checkbox. The word "Recording" will appear in the TAS Editor window caption, and the message "Movie is now Read+Write" will appear on the FCEUX screen. Now you can either unpause the emulator and play the game normally, or type the buttons frame-by-frame using the Frame Advance hotkey. As the playback goes forward, the movie will fill with the data on the buttons you press.

You may rerecord the same segment of the movie multiple times, overwriting the old button log with new buttonpresses data. If you don't like how a segment was played (e.g. the character fell into a pit), put the Playback cursor before the frame where you made wrong buttonpresses (e.g. the A button was pressed too late) and resume Recording, this time pressing buttons properly.

When the segment is ready, turn the Recording mode off to prevent accidental erasing of the Input when replaying the movie. Uncheck the checkbox by mouse click or via the hotkey. When TASing in Taseditor, the Recording checkbox is usually unchecked, because direct Input editing is preferred to Recording.

It's recommended to rationally combine the Recorder features with those of the Piano Roll. For long and easy segments of the game it may be convenient to record buttonpresses from the keyboard or a handy USB-gamepad, but for small dislocated edits the mouse is way better.

The "Superimpose" checkbox in the Recorder section allows to combine the existing Input with the newly recorded data on the same segment of the movie. For example, you can draw the R buttonpresses on rather long segment with a single mouse stroke, to make the character run right. Then you can enable the "Superimpose" option, turn on Recording and play the game by pressing only jump and shoot buttons, without the need to hold Right. The character in the game will still run right, jumping and shooting on command.

Unlike other checkboxes, the "Superimpose" option has three possible states. In addition to "enabled" and "disabled" it can also be in an interim state between these two. The third state works like this: when the player presses some gamepad buttons during Recording, these buttons are recorded in place of old Input. But if the player presses no buttons during Recording, the old Input on these frames is not overwritten.

The "Use pattern" checkbox applies current pattern to the process of buttons Recording. The name of the current pattern can be seen in the upper right corner of TAS Editor window (the last item of the main menu). If you click this menu item, a pop-down menu will appear, allowing you to choose another pattern from the list.

Patterns are used to speed up the process of entering monotonous buttonpresses and releases. For example, when you need to shoot at maximum rate (that is, alternate 1 frame of pressing B and 1 frame when B is released), you can just choose the "Alternating (1010...)" pattern and hold the B button without caring about manual mashing. Thanks to the pattern, the B buttonpresses will be recorded only for every other frame.

Besides the checkboxes the Recorder section also contains radio buttons that implement the multitracking feature.

Multitrack Recording greatly simplifies the traditional method of TASing games made for 2 or more players. Instead of pressing buttons of both gamepads at once, you can record a short segment of controlling the Player 1 and then record actions of Player 2 on the same segment of the movie.

By default the Recorder is set to recording "All" pads. You can choose a single pad by clicking the respective radio button ("1P", "2P", etc – the number of available gamepads depends on your project type). You can also use the "Switch current Multitracking mode" hotkey (W key by default). Now during the Recording the emulator will accept only the chosen player's buttonpresses, and the Piano Roll columns for other pads won't change even if you accidentally press another player's buttons.

The Splicer section comes after the Recorder. It's dedicated to displaying the most necessary data used in non-linear editing of the movie.

Despite the similar sounding, editing TASes is totally different from using a non-linear video editing software, because Taseditor only allows you to edit Input, not the finished video footage (Output). The resulting video stream is built by the game itself.

In this section you can see the information on current Selection size: how many rows and columns are covered. With this info you can use the Selection as a measuring scale (ruler). E.g. to find the temporal distance between two in-game events, click the frame of the first event and stretch the Selection to the frame of another – all those frames will be selected, and in the Splicer section the message "Selection: N rows, M columns" will tell you the number of frames in question.

Also, here is the info about the Clipboard contents: whether it contains an Input that could be pasted to any place in the movie. When an Input is copied to the Clipboard, this line displays total amount of frames copied. The Clipboard data is stored independently of Taseditor, and it's kept there even after you close FCEUX, until some other application copies its own data to the Clipboard.

The "Splicer" section has no controls, because all Input splicing commands are kept in the Edit menu item and are assigned with accelerator keys. In actual TASing process it's recommended to use the keyboard combinations, because they're easy to remember and the working speed increases immensely.

The list of all Editing functions

Basically, these are the standard functions of any text editor, but in Taseditor they can be applied to Input in the middle of emulation, which allows to analyze the results on the fly and flexibly tune your plans.

  • Copy (Ctrl + C) – copies the Input of all selected frames to the Clipboard.
  • Paste (Ctrl + V) – pastes the Clipboard contents into the movie, starting from the position of the Selection cursor. Old Input data on the frames is replaced by the new data, or combined together if the "Superimpose" option in Recorder section is checked.
  • Paste Insert (Ctrl + Shift + V) – expands the movie and inserts the Clipboard content at the position of the Selection cursor. Old movie data is shifted down.
  • Clear (Delete) – clears selected frames, removing all buttonpresses from them.
  • Cut (Ctrl + X) = Copy + Clear – copies Input from the selected movie segment and clears the segment.
  • Delete (Ctrl + Delete) – removes selected frames from the movie, shifting all the following frames up in their place. A handy way to move Input up.
  • Insert (Ctrl + Shift + Insert) – inserts blank frame into the movie before every selected frame, shifting existing Input down. A handy way to move Input down.
  • Clone (Ctrl + Insert) – similar to Insert, but instead of blank frames it inserts a copy of selected frames. Usually this is the preferred way of moving Input down.
  • Insert number of frames (Insert) – allows to insert any number of frames at the position of the Selection cursor. When you press the Insert key, a small window pops up and prompts you to enter the number of frames to insert. Type the number and click OK. If you change your mind, press Cancel (Esc) to hide the window.
  • Truncate – removes all frames of the movie, starting from the frame next to the Selection cursor. It's a rarely used function, so it has no hotkey, it's only available through the main menu or by the right-click.

When TASing in Taseditor you're going to most often use Ctrl + Delete (Delete Frames) and Ctrl + Insert (Clone Frames) to quickly move edited segments up/down in the frame list, thus performing certain in-game actions sooner or later.

Unlike FCEUX hotkeys, these key combinations can't be changed, so if you have some other emulator functions assigned to Ctrl, Insert or Delete, you'll have to change emulator settings.

Under the Splicer you can see a small Lua section.

There is one inactive button and one checkbox here, their purpose will be described later. While you're not familiar with Lua scripting, you won't need this section.

The Lua scripting language allows to automate some part of TASers' work and to create your own plug-ins for Taseditor.

Then goes the Bookmarks/Branches section. We should speak of Bookmarks at a greater length here.

Bookmarks are the evolution of emulator savestates. Before Taseditor the savestates were the main way to navigate the movie, with their help TASers return back to the place of a mistake and fix it. In Taseditor there are better navigation methods, but this one was left too.

You have 10 slots for Bookmarks in your disposal. These are numbered with digits from 0 to 9. You can set any of 10 Bookmarks to any movie frame, pointing to that frame with the Playback cursor beforehand.

Example 1. Set the light-blue cursor to the frame you want a Bookmark at, and make an emulator savestate (Shift + F1-F10 by default). For example, press Shift + F1 to set the first Bookmark. It will appear in the Bookmarks List, flashing one time with the red light.

Example 2. Set the light-blue cursor to the needed frame and right-click on any line in the Bookmarks List. For example, right-click on the line 2 to create the Bookmark in slot 2.

You can undo the Bookmark set operations with Ctrl + Z.

The Bookmarks List displays the frame number where each Bookmark is sat, and the real time of setting the Bookmark. If you hover the mouse cursor over a Bookmark's time (the right column in the List), you'll see the screenshot from the game.

When setting a Bookmark, Taseditor saves to the chosen slot the data about the Playback cursor position and entire movie contents. Now at any time you can either make a "spatial jump to the Bookmark" (simply returning the Playback cursor to the bookmarked place), or make a "temporal jump to the Bookmark", returning the whole movie to the state saved in the Bookmark slot.

To jump to a Bookmark in space, left-click on the left half of the needed Bookmark (the pale-colored half of the Bookmarks List where the frame number is displayed). Or use the keyboard – press the corresponding number key (numeric keys 0-9 are under the F1-F10 keys). You can notice the jump by seeing the light-blue cursor movement in the Piano Roll and by green flash in the Bookmarks List.

To jump to a Bookmark in time, left-click on the right half of the needed Bookmark (the brighter-colored half of the Bookmark List where the time is displayed). Or load the corresponding emulator savestate (keys F1-F10 by default). If any Input was changed during this jump in time (since it returns to its state at the time of creating the Bookmark), the Bookmark flashes with blue color, otherwise it flashes green, like in a simple Playback cursor jump. As usual, when an Input changes, the Greenzone truncates automatically. And of course you can undo the change using Ctrl + Z to revert the movie to its state before the time jump to the Bookmark.

So, part of the Bookmarks may be used to speed up your movie navigation. For example, set a Bookmark at the beginning of current game level to be able to return the Playback cursor to that frame and replay the level events anytime. You could use a Marker for the same purpose, but the advantage of the Bookmarks is that you can instantly jump to a Bookmark from any remote segment of the movie, no matter how many Markers are set in between, while to reach the desired Marker you would have to jump on the neighbor Markers.

Another part of the Bookmarks can be used to store alternative approaches to playing the same game segment. When TASing complex games we can't always immediately evaluate the optimality of a playing strategy. Sometimes TASer needs to record several different versions of playing the same segment and then carefully compare the resulting movies, choosing the most appropriate one to be left in the final TAS.

In traditional TASing every such movie is kept in separate file, so to switch between the alternative movies (or rather between alternative branches of your main movie) you need to load corresponding savestates created when recording these playthroughs.

In Taseditor all saved branches of the movie are held together, forming the hierarchy called the Branches Tree. To switch between the alternative branches you need to load the corresponding Bookmark, thus returning the working movie to one of the prepared versions. Basically, it's the same as before. But now we can visualize all alternative playthroughs in a graph scheme to facilitate TASer's comprehension of the multitude of options.

When you test a couple of approaches to playing the 2nd level of the game, the 1st level playthrough remains the same in both branches, so the discrepancy of the Input starts not from the beginning, but from the 2nd level. So, if you left the Bookmark 1 before the beginning of the 2nd level, you'll see the fork in the graph starting from the card 1.

As an experiment, create a new project and make a very short movie. Then set the Playback cursor to the end of existing Input and save a Bookmark into the first slot (Shift + F1). Advance a few frames after that Bookmark and draw some buttonpresses, then play this new Input and save to Bookmark 2 (Shift + F2). Now return the movie to the first Bookmark state (press F1) and add some buttonpresses after the bookmarked frame again, but make sure they are different from the last time. Play this new Input to the end and save the 3rd Bookmark (Shift + F3) or any other.

Now click on the header of the Bookmarks section ("Bookmarks/Branches" label). The Bookmarks List view will change to the Branches Tree view. If the third Bookmark movie differs from the second Bookmark movie, and the difference starts after the first Bookmark frame, you'll see the picture similar to the above. The cloudlet symbolizes the beginning of the movie (the root of the hierarchy). Bookmarks are presented with cards of corresponding numbers. The blue-colored number stands for the current Bookmark containing the branch that corresponds to working movie (currently displayed in the Piano Roll). If the working movie was changed after saving/loading this Bookmark, you'll see the fireball descending from the current Bookmark.

Red lines connect those Bookmarks that are compatible with the chronology of current working movie. For example, if you set one Bookmark at the end of every level, all such Bookmarks will be sitting on one red line, because the movie of every next Bookmark is actually composed from the movie of previous Bookmark plus an additional level playthrough.

The Branches Tree also displays current Playback cursor position. Try dragging the cursor in the Piano Roll up and down, or just play the whole movie back (press Shift + Home and unpause the emulator). You will see how the light-blue arrow pointer rides on red lines that connect all Bookmarks of the current timeline. E.g. if the current branch is the Bookmark 2, the pointer will ride that route: "cloudlet -> Bookmark 1 -> Bookmark 2". And the other Bookmarks will be left aside, because they represent an alternative timeline, conflicting with the currently played movie.

The Branches Tree is automatically rebuilt each time you create a new Bookmark or change an existing Bookmark's contents. Depending on how complex your project is, the graph may appear differently.

You can hover the mouse cursor over any Bookmark number to see some info about it.

Also you can make a single left-click on any Bookmark card to send the Playback cursor to the bookmarked frame (spatial jump). By clicking the cloudlet you send the Playback cursor to the beginning of the movie (equal to pressing Shift + Home), and by clicking the fireball you send the Playback cursor to the end of the movie (equal to Shift + End).

Besides, you can double-click a Bookmark by the left mouse button to jump to the Bookmark in time. The working movie reverts to the Bookmark's state, the Bookmark becomes current branch and the Playback cursor moves to the Bookmark frame.

Finally, you can right-click any card to save the current movie state and the Playback cursor position to the chosen Bookmark.

As you see, the Branches Tree view supports the same functionality as the Bookmarks List view does. Thus it's recommended for advanced users to stick to the Branch Tree view, because it provides more info for a TASer. When you want to switch back to the Bookmarks List view, click the section header again (the "Branches" label).

Now try using all 10 available slots. Each time slightly change the current movie Input and watch the changes on the FCEUX screen before saving them to a Bookmark. The position of each card on the Tree is defined by the Input preceding the bookmarked frame. It's implied that TASer always watches the edited Input segment in the emulator, and only then saves the tested work into a Bookmark.

In hands of an experienced TASer Bookmarks become very powerful tool, allowing to greatly simplify the TASing process and implement ideas that look impossible. Usually, an idea is labeled "impossible" only due to its monstrous unbounded complexity. But lower the complexity a hundred times (with the help of tools and a smart process organization), and the achievement moves from the "impossible" category to just "hard" one.

The History section is located below the Bookmarks.

Taseditor keeps strict accounting of all operations in the current project. Every user's action that changes an Input, Markers or Bookmarks is recorded to the log displayed in this section.

The current item of the History Log is highlighted blue. Other items have white background if they aren't related to the current item, or purple background if they represent the changes made in the same place as the current item. For example, if current History Log item was created by changing the Input of frame 27, all other items affecting that frame will be highlighted purple.

To undo logged operations you can either use the Ctrl + Z and Ctrl + Y keys, or simply click any line in the History Log with the left mouse button, thus returning the movie to the time when the clicked item was created.

You may notice the purple cursor line appearing in the Piano Roll for a short moment. It's supposed to stress your attention on the place of the undone changes.

The maximum number of undo levels can be set in the Config menu, that value defines the maximum size of the History Log and therefore the amount of used memory.

The full list of all possible records in the History Log can be found in the Reference .

At the very bottom of the Toolbox there are 4 buttons controlling the Selection cursor.

The meaning of the "<<" and ">>" buttons can be easily guessed by analogy with the upper "<<" and ">>" buttons in the Playback section. The upper part of TAS Editor window contains the Playback cursor-related elements, and the lower window part contains Selection cursor-related elements.

The "<<" button (jump back) moves the Selection cursor to the frame where the nearest upper Marker is located. In the above picture it will jump from frame 27 to frame 22 where the Marker 2 is set. Using this button you can quickly return the selection to the beginning of the edited segment or to any marked segment. This button has its keyboard analog: Ctrl + Page Up. You can hold this button to let the dark-blue cursor rapidly jump on Markers up in the Piano Roll.

The ">>" button (jump forward) moves the Selection cursor to the nearest marked frame below it. In the above picture it will jump from frame 27 to a frame outside the visible area (where the next Marker is set), and Piano Roll will automatically scroll after the Selection cursor. Using this button you can quickly navigate down through the movie. This button has its keyboard analog: Ctrl + Page Down. You can hold this button as well.

Since the Selection cursor isn't tied to the game emulation, its jumps on Markers always happen instantly, regardless of the Greenzone presence on the target frame. So it's useful to read the Marker Notes one by one this way, watching them in the lower edit field and pressing Ctrl + Page Down to make an instant jump to the next Note. Besides Page Up / Page Down keys you can roll the mouse wheel while holding the Ctrl key.

The buttons "Similar" and "More" are used for searching similar Notes. This is another experimental feature of Taseditor, and it will be described later.

Now you are familiar with fundamental principles of the program usage.

In the next chapter: systematic approach to TASing .

PRACTICE: Beat the World 1-1 in Super Mario Bros (or any other game) using only the mouse, without Recording.

No need to do a speedrun, just make yourself familiar with the routine of Input drawing / erasing and watching the results using the mouse wheel / middle mouse button.

Estimated time: 20-30 minutes.

Created with the Personal Edition of HelpNDoc: Easily create Help documents


3. TASing Process

Beginner's Guide ››

TASing Process

TASing is about striving for an absolute perfectness. For TASers, a game is more than just an amusement, it's an interesting and complex task.

People enjoy solving creative tasks, because it allows them to express their individuality and improve various skills. However, complicated tasks require both inventiveness and methodicalness. This Manual describes dry and methodical side of TASing, as for inventiveness – you'll have to show it yourself in real setting.

In general, to create a perfect (or very close to perfect) playthrough of the game you have to record an imperfect walkthrough and then work on consecutive improvements of its separate parts. When every fragment of the movie is perfect, we may consider the whole TAS to be perfect as well.

The concentration of efforts on small segments of the movie is the key to success. Every working segment has to be large enough to represent an adequate subtask, but small enough to make the task simple.

Without such structuring an effective and comfortable TASing would not be possible. There's too many factors affecting the final result of the game, and some of those factors append or contradict each other. Human memory is not enough to keep and calculate all interconnections of the game factors within a large segment of the playthrough. Therefore, when TASers deal with long play sessions, they aren't different from regular players who are carried by the temptation to use the first observations as a base for making decisions. But regular players can get away with such carefree approach, while TASers would end up with a clearly imperfect walkthrough.

Thus real TASing implies that segments are small. Much smaller than a single level of a typical videogame. The whole process of TASing may be portrayed like this: a man watches the recording of his own unfinished playthrough of the game, selects a small piece of the movie and throws all forces into improving it, then selects another piece and so on until the end of the game.

Of course, it's an incomplete picture, because besides the movie editing TASers also research and experiment with the game (to expose hidden factors) and do many other things. But that's beyond the scope of this Guide.

The skill of choosing adequate segments comes with experience. Many TASers don't even think what makes them spontaneously focus on a segment of the game and unconsciously limit the beginning and the end of current work. Some believe that they simply record the movie frame-by-frame in succession, but if you watch it from outside you can note that those repeated rerecords occur within a window of 20-200 frames, and the window goes forward the movie by making jumps (the end of previous segment becomes the beginning of next segment). Consider watching live stream videos of TASing, and you'll see certain regularities in handling savestates.

Here we'll try to analyze the behavior, in order to learn how to define current segment limits sensibly. And then practical TASing will make you do it mechanically.

An adequate segment (subtask) is supposed to give TASer a consistent goal and simple means to reach it.

The goal of a segment playthrough is usually to achieve certain in-game event. For example, the goal of playing through the whole game is the event when "THE END" text appears on the screen. The goal of one level can be such event as "the value of the level counter in RAM was increased" or simply "the screen faded at the end of current level". And the goal of a small segment may be something like "the character successfully landed on the other side of the pit". These intermediate goals are defined by the context.

Based on the goal, TASer defines the optimality criterion in mind. The criterion is the rule which lets you compare any two versions of playing through the current segment of the game. When you're TASing, it's not enough to simply reach the goal, you have to try many approaches to reaching it, and then choose the best approach of all. For example, in a speedrun the best approach to playing a segment is usually the one in which the target event occurs as early as possible. E.g. if the 1st approach to playing the segment made the event occur at frame 350, and the 2nd approach made it appear at frame 340, then the 2nd approach is better than the 1st, and the final movie should contain exactly the 2nd approach.

There's a lot of means for reaching the target event. In theory, any gameplay aspect (including those not planned by developers) may help or impede the progress in some way. So, to cope with this vague multitude of possibilities you should regard all aspects of the game as optimality factors.

An optimality factor is an aspect of the game that directly affects optimality of playing current segment. The word "directly" implies a monotonous dependence of outcome from applying the factor. For example, on this picture there's no monotonous dependence between the distance to finish and the duration of holding Right. Pressing the same R button either makes Mario be closer to the finish, or moves him away, depending on his position.

When people perceive such segment in a whole, it's difficult to guess the best moment to release the R button, when to press the L button and so on. So, in order to simplify the understanding of complex dependencies (and thus reveal factors), such segments should be broken into several subsegments.

Correct statement of question usually cuts off many irrelevant possibilities. For example, regular player could wait until the difficult enemy character walks away, but in a speedrun such tactic is not considered.

Thus even in an open-world game TASer is left with a limited set of useful actions and in-game indicators that must be followed while polishing one segment. And the less the segment is, the more limited is this set, so it's easier to find an ideal sequence of actions by going over combinations of factors.

On the other hand, the less the segment is, the less its goal intersects with the final goal of the TAS. The final goal is to make perfect walkthrough, e.g. the fastest in the world (which means the frame counter at the end of the movie should be as low as possible). But in terms of every specific segment the goal may be completely different, sometimes even opposite (for example, to stay in bonus stage as long as possible, which then grants time saving at another point of the game). That's why in very small segments the optimality criterion is not used, and playing such micro-segment is only evaluated as a part of a full-fledged segment.

For example, when your character is jumping over a pit and shooting enemies at the same time, every bullet release can be considered a separate subsegment (so it becomes easy to isolate such factors as "recharge timer", "max 3 bullets on screen" and so on). But then, when comparing approaches, you should compare different versions of jumping over the pit. Even if the 1st approach to jumping (which ends at the frame 350) allowed you to shoot two enemies and the 2nd approach (which ends at frame 340) allowed to shoot only single enemy, you are supposed to choose the 2nd approach, because the optimality criterion of the unbroken segment fits the final goal of the speedrun better.

While TASing you have to maintain an optimal balance between the necessity to decrease segments in order to grasp factors and the need to increase them in order to use a relevant criterion. This skill comes with time, so don't sweat it and just rely on your intuition.

Let's have an example when the segment is too large. In a Super Mario Bros speedrun you are expected to reach the end of World 1-1 as fast as possible, which means you have to maximize the X coordinate of the character moving from left to right. The basic premise is that at the beginning of the level the X value equals zero and at the end of the level it is one thousand. Using gamepad buttons you can influence the coordinate in various ways.

If we take the whole level from the moment X = 0 to the event X = 1000 as our working segment, we can immediately see the optimality criterion (the best approach will be the one with minimal value of the frame counter when X >= 1000), but we can't see definite factors. How exactly we're supposed to press buttons to get the X = 1000 within minimal number of frames? Well, we can apply a regular player's logic and intuition. When we press the R button, the X coordinate usually increases, and with the L button it decreases. So the most obvious decision is to hold the R button and see how many frames is needed to grow the value of X to one thousand. When testing such approach in emulator, it appears that Mario is hampered by obstacles and the X coordinate does not grow, even though the R button is held. This way a new factor comes to light – the need to jump over obstacles and pits. Using the A button Mario eventually reaches the X = 1000 event, and the optimality criterion can eliminate all alternative playthroughs where the A button presses were ill-timed (e.g. where Mario stumbled over edges of pipes, the frame counter at the end of the segment was higher).

Now the player (or rather, TASer who is stuck in player's mindset) may think that all factors are applied and the segment is perfect. But it isn't. Super Mario Bros has somewhat complex physics engine. The X coordinate is influenced by current horizontal speed, and speed is influenced by acceleration. Acceleration is affected by the B button, skidding, Mario's direction and air-ground state. There are also teleporter pipes and useful glitches like the "flagpole glitch" and so on. A lot of things to bear in mind. But, according to certain research, human working memory can only store about 7 objects , thus some factors inevitably slip away when you're editing Input on large segment. You'd better shrink the segment to such a scale which reveals factors individually or in a small group.

If we focus on the segment from X = 0 to X = 100, the optimality criterion will be the same, but now it also becomes obvious that in the first half of the segment Mario runs slower, and in the second half he runs with constant speed which can be considered maximum. This way you begin to appreciate the acceleration factor, so you add the RAM address to Memory Watch and start analyzing possible ways to influence the acceleration. After some experiments with turning and jumping you can discover more factors. As a result, you're going to find an intricate combination of R, L, B and A buttonpresses that makes the event X = 100 occur faster than simply holding R and B. And even if the new playthrough of the segment is only several frames faster than old, it's much closer to perfectness.

Now let's take a look at another extreme. When segment is too small, its optimality criterion may contradict the final goal of the TAS.

First, if you get carried away by maximizing speed and acceleration in equal intervals between every next hundred of pixels, you may forget about the shortcut pipe, because diving into pipes resets speed value to zero, which contradicts with the goal of current segment. In short term the diving factor is disadvantageous for a speedrunner, and its long-term profit may be overlooked when you're busy with habitual actions.

In this case the segment was chosen without much foresight, and as a consequence it sprouted wrong criterion of optimality ("the frame counter at the event X = 200 must be minimal"). Instead, the segment should end at the moment when any Down button press starts diving animation.

Of course such mistakes are often noticed when replaying finished movie on a fresh mind, but sometimes the situation is less obvious and is only revealed after publishing.

Second, in the same SMB game after diving into the pipe (World 1-1) you have to reach the exit to the right. It may seem necessary to start maximizing speed from the very beginning. But as you may see in the picture, within first dozen of frames it's better to hold the L button instead of R, so that Mario lands slightly aloof from the wall that needs to be jumped over. If you hold R too early, Mario will land close to the wall and will have to jump vertically, thus losing gathered speed.

This peculiarity is not so obvious when you choose optimizing the segment from the event Mario appears to the Mario lands event. The optimality criterion of such small segment will direct you to wrong sequence of buttonpresses.

Here you should choose the segment from the frame when Mario appears to the moment of overcoming the corner of the wall.

Unfortunately, even experienced TASers not always choose correct limits right away. Sometimes you have to rethink and redo, throw away results of many tests and change the scale of the segment, play the same part of the game many times again.

As you might have noticed, this document avoids measuring segments in real frames of the movie. Because actual size of segment varies from game to game and from stage to stage. Some parts of the game contain so little possibilities that they can last for more than a thousand of frames and still be easy to play and replay. By the way, some segments don't even need to be played more than once, since they are so simple that any successful playthrough is optimal (for instance, watching unskippable cutscenes between levels). And on the contrary, some stages of the game are supersaturated with events and factors, so you are going to sweat even over a dozen of frames.

Experienced TASers regard every segment individually (although they don't think too much about it). It's bad idea to choose the next segment by the same principle as previous, this would only work well in extremely repetitive games.

If you want, you can limit the end of current segment by a fixed frame number (e.g. set the goal to maximize the X coordinate value when the frame counter = 200). But usually it's more convenient to associate the end with some small frontier of the game (like passing over a trap or defeating another enemy) – then the goal itself is going to suggest you basic means for reaching it. The task "touch a flower as fast as possible" sounds more natural (for a gamer) than the task "at the frame 300 become as close to the flower as possible".

In the vast majority of video games the gameplay divides into "rooms", "enemy waves" and "traps", which are always separated by short periods of relaxation. Even in constantly scrolling and open-world games the level design ensures that there are intense moments and filler intervals between them. The truth is, game designers also structure player's task into subtasks, and in some cases TASer can even borrow the prepared segmentation. Just don't forget to critically assess it and subdivide into more subsegments when needed. Though, such subdivision will naturally take place in the process of editing Input on a excessively large segment. So TASing doesn't always require intense intellectual efforts. If you're skillful and smart, most of time you can just go with the flow and enjoy TASing no less than conventional gaming.

All this can be compared to how writers divide their books into chapters (game levels), and chapters into paragraphs and sentences (segments) in order to aid with comfortable reading and comprehending author's ideas. A regular reader (player) is satisfied with the author's subdivision, but a literary critic (TASer) needs to be able to "read between lines" by dividing text his own way.

For example, in Super Mario Bros every group of enemies is separated by a quiet space which doesn't require any skills, and it can be light-heartedly ran over or jumped over while holding Right (granted that Mario speed is already at maximum). So you don't even need TAS tools to be perfect at these moments. These intervals are the most suitable place to set a goal – if you mark an end of the segment at such place, the optimality criterion won't contradict with final goal of TAS for sure. And usually these moments occur often enough so the segment between them is of an acceptable size.

The division to segments was always present in TASing, but Taseditor allows to accentuate the process visually. Here you can mark the beginning and the end of a segment using Markers or Bookmarks. Thanks to the visible boundaries you won't be distracted onto adjacent Input and can focus on analyzing only closest factors.

The frame of current segment beginning is usually chosen when watching a test playthrough of the current segment. When recording or watching such playthrough you already pick one or two key factors of optimality. So it's only logical to start the segment at the moment when these factors join into force or dramatically change the behavior. For example, at the beginning of every level you usually start a new segment, because that's the point where you regain the ability to move forward (after the cutscene between levels ends). So it's wise to set a Marker or a Bookmark at the beginning of every level, thus marking both the level boundary and the beginning of current work segment.

And if in the process of optimizing the segment you reveal some factors that join into force earlier than current beginning of the segment, you can always adjust the chosen boundaries of the segment, or break it in two subsegments.

The ending frame of current segment is more mobile than the frame of beginning. When you define your goal (e.g. to make the X coordinate reach the value of 50) you can mark the end of current segment by setting a Marker/Bookmark to the frame where current imperfect playthrough accomplishes this goal. Then by polishing the Input you try to reach the goal (X = 50) at an earlier frame. And if in the process of modifying and testing a new Input you discover that the goal indeed can be reached earlier, you move the closing Marker/Bookmark up (to the frame of the improved end). After that you continue testing new approaches, searching for even better one until you don't feel any more potential. In traditional TASing this is exactly how the main Bookmark (storing current best playthrough of the segment) gradually moves up.

Well, sometimes you can indulge in laziness and avoid marking the end of current segment, instead you just keep the goal in mind and remember the number of the frame where the target event occurs in the best case so far. Such behavior is reasonable when the segment is very simple and you don't plan to redo it many times.

Moreover, in many platformer games where the player character has constant running speed most of segments can be played optimally from the first try (you just have to hold the Right button and maybe jump over trivial obstacles). So if you don't see any obvious mistakes and don't intend to search for hidden flaws, you may as well skip the segment shaping, just proceed to next segment right away. Such simple games are especially suitable for newbie TASers, because TASing them is very similar to casual playing through videogames using savestates (when you only revise the most obvious mistakes, like falling into a pit, and ignore non-fatal roughness).

But in complex TASes, where the mind is occupied with many optimality factors, you shouldn't hurry. To make your thought process more precise, you'd better be perfectly aware of current segment boundaries. So mark the beginning of any difficult segment with a Marker, and mark the end by setting a Bookmark every time you find an improvement (use one and the same slot). Since it's not easy to find an improvement when dealing with difficult tasks, don't expect you'll have to re-set the Bookmark too often.

When you're confident you've found perfect solution of the segment, move to the next segment. Don't remove old Markers, since they may be useful in future, in case you begin doubting the perfectness of your decisions (e.g. after finding a new trick). The logic of movie dividing will most likely remain the same even after finding the new factor (the trick).

Also, if in the middle of optimization process you become confident you've found perfect Input for the first half (or a third) of current segment, you can divide the segment in two and focus on optimizing the remaining section. Such situations often rise when the initially chosen segment was too large and its logical parts naturally emerged in the process of editing the Input.

So, if you don't like to keep things organized, you can avoid Markers and Bookmarks whatsoever, working mostly in terms of fuzzy in-game concepts and imagining segments as some emotional sequences of events. Unfortunately, the data about fuzzy goals also occupies part of human working memory, and as a result you won't have enough resources to keep all optimality factors in mind. And you won't even notice how you've overlooked a multitude of possibilities.

On the contrary, if you like to keep an order, it's recommended to accompany Markers with text Notes, either before, or during, or after the optimization of the current segment. For example, make up a name for the segment or put a tag. This way you document the development of the TAS during actual TASing, give an objective meaning to the Input appearing in the process. This is especially useful when TASing in co-authorship. But even when working alone, you may notice the documentation from previous levels motivates you to carry on. It only takes seconds to type that kind of texts, and then it helps not to abandon the project.

Notes also help to better unlock the potential of tricks and bugs of the game. By writing the text you actually formalize your knowledge about the described phenomenon. When the essence of the trick is kept in your mind, you may think that you already know everything about it, and that your current TAS uses the trick the best way possible. But when you construct an objective model (a verbal description of the trick) you often find its new sides.

It's not uncommon for TASVideos.org to see how one TASer read the description of a trick in the submission text written by another TASer and found a way to use the trick better than original author. There were also cases when author himself reads his recent submission, facepalms and urgently records an improvement.

Making a perfect TAS can take anything from several days to several years, depending on complexity of the chosen game. Most of that time is spent on finding an ideal sequence of buttonpresses for every segment.

Often it seems right away that current Input is already the best possible. But usually it's not so, especially if you make the conclusion judging by the external image of the emulated game instead of its internal state (Memory Watch). So it's always reasonable to suppose that current result is not perfect. If you don't see any mistakes or potential improvements at the moment, try to watch the segment together with several previous segments (e.g. watch the last half a minute of your movie), because it's possible that previous segments contain some unregistered optimality factors that have an effect on current segment. And if you still don't get any ideas, consider moving to next segment, but don't completely refuse further attempts to criticize and improve finished segments.

Rewatch the finished part of your movie from time to time – either from the very beginning, or from the beginning of current level – and try to notice imperfections. Taseditor allows to edit Input in any part of the movie while the movie is still playing, so you can quickly test any spontaneous idea right when it comes to your mind. If the new idea appears to be unsuccessful, just undo latest changes or load the Bookmark containing the last stable state of the movie.

And if the new idea in fact improves you TAS, after a joyful anticipation you have to ensure that all the following segments of Input sync to the game (because implementing the idea has changed the flow of the game). Most of time it's not necessary to redo all the following Input. Usually you only have to delete or insert a few frames (thus shifting all following segments up or down), or modify several segments between the place of implementing the new idea and the nearest checkpoint (the end of current level, etc). Checkpoints usually reset many in-game properties to default value (e.g. they require you to walk over specific platform, thus equalizing the Y coordinate), so after the checkpoint you old Input will sync with new timeline of the game once you adjust it to match the flow of game events.

Anyway, even in cases when you have to redo considerable parts of the movie, resyincing is much easier than TASing from zero ground, because now you know the best approach for each segment and only have to match your previous results. And sometimes you can even excel them, because, when you're doing these forced modifications in order to resync old Input, you still possess TASer's critical thinking, so you may notice another mistake or unimplemented idea by the way.

Sometimes it's like a snowslide – as the trouble grows, so grows the thrill of all the discoveries. Many ingenious speedrun overtakes were made because of noticing a small improvement in the middle of the movie, which then forced TASer to re-record the remaining half of the movie (in order to resync it using traditional method) and stumble upon new discoveries in the process. And then these new tricks appear to be useful in the first level of the game! Since the game has single engine, a trick that works in one level may be applied in another, where the similar conditions are met. Even if some conditions aren't met, sometimes you can create them by losing something less important... So, in the end, as the movie gets rewritten many times, the initial small improvement turns into large-scale progress.

You should learn not to feel sorry when you have to throw away results of your hard work. In TASing you're expected to reconsider even polished parts of the movie from time to time. The traditional method of TASing quickly makes you accustomed to inevitable losses of time, because any inattention or slipped finger requires you to rerecord part of current segment. Taseditor averts such minor losses, but doesn't change the fact that you have to retry new approaches after finding new optimality factors.

For example, when polishing the Input near the end of World 1-3, you've suddenly found a new trick allowing you to get a mushroom, and it also appears to work in the World 1-1. Now you have to redo both 1-1, 1-3 and even 1-2, because you now play World 1-2 with big Mario. Of course, TASing the same levels second time is easier, but the fact of wasted time may dispirit you at first. Sometimes it may seem that fixing the old mistake is not worth spending additional time. At this point you'd better stop thinking too much and just choose one of the two options – either immediately start fixing, or postpone it for an indefinite period (and leave the Marker with a note describing the issue). If at the end of the project you accumulate a critical mass of such postponed plans, the movie should be called a "test run" and probably also published, at least as a WIP (work in progress). Then take some considerable rest until you feel like redoing the TAS (making an improvement).

Despite all the difficulties, TASing can bring enjoyment both to viewers and authors. TASes are made by people who consider this kind of work to be balanced (paid off) by the excitement from intermediate and final results. In many senses TASing is similar to a special meta-videogame with a unique gameplay mechanic. And until games bring fun, people play them no matter how hardcore they are.

In the next chapter: descriptions of Input optimization methods .

PRACTICE: Watch the imperfect playthrough of the 1st level that you made in previous chapter, and divide it into segments using Markers and your own discretion. If the movie is rather long, no need to structure it all, you just have to feel the principles.

Estimated time: 5-10 minutes.

Created with the Personal Edition of HelpNDoc: Free help authoring environment


4. TASing Methodology

Beginner's Guide ››

TASing Methodology

This chapter is dedicated to the principal activity in TASing – the way of creating an optimal Input for any given segment of the movie. TASes look so shiny exactly because of persistent manual polishing of Input. The size of working segment can be anything, criteria and factors of optimality can vary, but the method is basically one and the same: retry all sorts of approaches and choose the best one. The only question is how to do it with minimum time and effort.

  • Gamers erroneously think that to make a TAS you only have to complete the game once, using savestates when you make some fatal mistakes (those resulting in inability to complete current segment, for example, death of the character).
  • Newbie TASers understand that to make a beautiful TAS you have to revert and fix all noticed mistakes (e.g. even such minor flaws as stumbling over a threshold). They also complete each segment only once, but spend more time than regular players, because of saving and loading savestates much more often. For TASing simple games this can be sufficient.
  • Experienced TASers know that to make a perfect TAS it's not enough to fix all noticed mistakes. You also have to fix unnoticed mistakes. Consider unknown factors. Approach the task from an unobvious side. To do all this they play through the same segment several times, both fixing all noticed mistakes and trying to somehow avert unnoticeable mistakes.

It's rather difficult to convince yourself to spend time on alternative ways to play through the segment once it's already completed and all obvious mistakes are already fixed. After achieving the current in-game goal people usually want to set another in-game goal. But you must remember that TASer's goal is different from player's goals. So try to abstract away from the game rules and not to retreat from the segment until you complete real goal, not just player's small goal.

That's actually the most difficult part – to invent new approaches to solving one and the same task. TASers mainly consider the same approach a regular player would have used in this place of the game. That's why people mostly use evolutionary way instead of revolutionary. You keep modifying the existing basic approach, both fixing its mistakes and conducting experiments. In the process of these thoughtful modifications you enrich your knowledge base about the game, and as a result you produce an Input that isn't immediately obvious.

Of course, sometimes you have a flash of inspiration, when a revolutionary idea leads to tremendous improvements that surpass all polishing gains. People love TASing exactly for these emotional moments. Yet it doesn't exempt you from the need to polish this new revolutionary approach using the same methods to bring it even closer to an ideal.

Instead of reading the techniques described here you can just immediately start real TASing, so in a course of several projects you would work out your own methods. But most likely after a year of TASing you'll come to the described scheme of work.

So, the process of creating the best Input for the segment of optimization can be basically described as a loop of fixing mistakes in previous versions of Input of the segment. A mistake is any kind of divergence from the perfect yet unknown Input. Such statement of question is very advantageous, because it means that you can gradually approach the perfect Input by making small steps that you can elaborate even without being a genius. The majority of mistakes can be successfully fixed by repeated examination and modification. That is, even when you don't have any original ideas, you can achieve a success by persistence. The successful progress motivates you to continue the work and thus prepare the ground for breakthrough ideas.

To correct a mistake in the Input of a movie you have to:

  1. Become aware of the mistake.
  2. Conjecture a solution.
  3. Navigate to the place.
  4. Apply changes.
  5. Verify the outcome.

1. Realizing a mistake happens either when watching the movie in Read-Only mode or right when recording/editing the Input.

Comment: Instead of detecting a tangible mistake TASers often just assume that current segment is still improvable. It's always wise to doubt the perfectness of current result and try experimenting with the Input – sometimes you indeed find unused possibilities.

2. The means of solving the mistake are either immediately obvious or are found experimentally. In rare cases you have to resort to calculations and comparisons. A correctly chosen segment usually encompasses all key factors of optimality. The information from previous or next segments is rarely needed.

Comment: Sometimes while fixing one mistake we unwittingly create another mistake. In this case the optimization process would go in wrong direction, but fortunately such situations are extremely rare in TASing, because videogames are much more straightforward than real life, so player can find all factors and an unambiguous criterion of optimality. Taseditor additionally simplifies the process by data visualization.

3. The ability to navigate to the place of making the mistake is the essential distinction between TASing and normal speedrunning. Regular players can detect the mistake post factum, but it's TASers who always return back to correct it.

In traditional method of TASing the navigation may take noticeable amount of time and effort. Taseditor makes the navigation much faster.

Comment: Sometimes the place of making the mistake is located long before the segment where it is revealed. In this case you have to find the segment affecting the mistake and edit it according to the information given by the played segment. And in this case the speed of navigation between those two segments is even more important.

4. Applying modifications to Input is how you make your thoughts real. The less the delay between an idea and its implementation is, the better.

In the traditional method of TASing the Input modification generally takes longer, because in addition to rewriting erroneous frames you also have to rewrite adjacent frames In Taseditor this is often not necessary.

Comment: Since any Input modification entails a change in the game flow, sometimes even in Taseditor you have to resync the old Input that follows the place of fixing mistake.

5. To see the outcome you need to resume playing the movie from the beginning of current segment of right from the frame of fixing the mistake. There's no need to re-check previous segments of the movie, because the mistake fixing affects only subsequent events.

Comment: Although, when you're making an entertaining playthrough instead of a pure speedrun, after fixing a mistake (e.g. making the movement trajectory more smooth) you should ensure that this correction fits with the general sequence of in-game events, so it's recommended to rewatch some previous events together with the current segment.

You almost always have to watch the current segment up to its end, that is, to the moment when the target event occurs, so that you can confidently apply the optimality criterion. Because the correction may seem profitable at first but appear worse in the end.

After evaluating the outcome, the mistake is either considered to be fixed/non-existent, or you have to return to step 2 and rethink the situation.

Before Taseditor, all mistakes (both explicit and supposed) were being fixed by creating and reloading savestates. If you're not familiar with the traditional method of TASing, here's its basic principles:

  • The game emulation is almost always paused. You only unpause it to rewatch finished segments.
  • TASer sequentially types the Input into frames pointed by the Playback cursor. You see the outcome of the committed Input next frame (or sometimes in several frames). Experienced TASers create a new savestate after each hard-to-reproduce action, so they are able to return back without the need to replay the whole segment from the beginning.
  • To correct a mistake, TASer returns to the supposed place of making the mistake and rerecords the whole Input, starting from the frame that needs to be changed. If there was a savestate created at this frame, you can instantly load the savestate in Read+Write mode and begin typing buttonpresses right away. But if you only have a savestate created at some distance before the frame, there are two options. Option 1: load the nearest savestate in Read-Only mode and replay the movie up to the needed frame, then switch back to Read+Write mode and start the correction, thus not touching the Input in the interval from the savestate frame to the mistake frame. Option 2: just load the nearest savestate in Read+Write mode and repeat the old Input by memory, thus rewriting it up to the needed frame, and then start the correction. The 2nd way is used more often, because after the nearest savestate there's usually an easy-to-reproduce Input (e.g. simply holding R + B). Also, upon arriving to the supposed frame of the mistake, an experienced TASer mechanically creates a savestate (just in case!), so next time he will be able to return directly to the frame, without wasting time on navigation. Such a prudence makes sense, because mistakes are seldom fixed at the first attempt, usually you need to repeatedly rerecord the same section of Input, starting from about the same frame.
  • The disadvantages of the traditional method clearly reveal when you need to see a distant result of your Input (for example, you press the button now, but the roulette only stops in several seconds). In such cases TASer makes a savestate before entering the Input, records the decisive Input and makes a savestate after it, then unpauses the emulator and carelessly (suboptimally) plays through the game up to the point of seeing the result. If the result is satisfactory, TASer loads the savestate made after the decisive Input and records an optimal playthrough, already being sure in successful outcome. And if the result is unsatisfactory, TASer loads the initial savestate, changes the decisive Input and repeats previous actions (creates a savestate after the Input and hastily plays up to the result). And this process may go for a long while.
  • In order to copy an old Input (for example, the complex acceleration of Mario at the beginning of every level), TASer either learns the button combination by heart or copies it in parts by making several jumps between the source and the destination. First the game is sent to the place of old Input (by loading the savestate prepared at that frame) to watch the replay in Read-Only mode and memorize a few buttonpresses, then it's sent to the current segment (by loading the latest savestate in Read+Write mode) to lay out the buttonpresses. This way sounds tiresome, but if you keep moving both savestates a bit forward after every jump, the navigation between source and destination becomes rather quick. Still, when TASers need to copy a long sequence of buttonpresses, they use an external editor of Input, allowing to copy/paste. But the downside is that switching contexts is very distracting, so often it's less troublesome to just copy the Input manually.
  • To examine the current progress, TASer makes a savestate, turns off the Recording and loads the savestate left at the beginning of current level (usually it's the slot assigned to a rarely used key, such as F10). Then he unpaused the emulator and watches the movie like an outsider. To continue the recording, he switches to Read+Write mode and returns directly to the latest recorded frame by loading the latest savestate (usually it's the most often used slot, like F1). If while watching TASer decides to modify the old Input, he makes a savestate at this point, switches to Read+Write and loads the just created savestate. Beforehand, you should make sure the last state of the movie is saved to both F1 and another slot that won't be used in your experiments with the old Input. This is necessary in case your experiments fail, so you could restore the old movie even if the F1 slot becomes overwritten in the course of the experiments.
  • So, the majority of the 10 available slots is used for navigation between different moments of the game. Or, using Taseditor's terms, they are used for Playback cursor navigation along the movie. The 10 slots are more than enough to teleport back and forth among all places of interest, even when current segment is very large. Usually 3-5 slots are enough. Experienced TASers juggle these slots with astounding speed.
  • A couple of another slots are used to store alternative strategies of playing. When you don't know which approach to playing a large segment (e.g. a whole level of the game) will be better, you first polish the 1st approach and save it into a separate slot (say, F8), then you polish the 2nd approach and save it into an adjacent slot (e.g. F7). After that you can alternately load these slots (or even alternately watch the two branches of the movie) and choose the best one, save it to F1 and continue TASing in this branch.

As you see, almost everything in the traditional method of TASing is done using savestates (Bookmarks). In Taseditor some of their functions are replaced by the Greenzone and the History Log, yet Bookmarks still play important role, allowing to keep alternative branches of the movie in a single project. The Playback cursor navigation now can be done faster by either drag'n'drop or mouse wheel. In fact, now you don't need to put Playback cursor to the frame of modification, you can just scroll the Piano Roll to the place and change the Input by mouse.

Since the Recording is less effective than direct editing, there's no more need to constantly switch modes. Now the emulator is always in Read-Only mode.

The game is always paused, as before. But now you are seeing the outcome of your Input only when you actually want to see it. At first this may seem inconvenient (as you don't feel the habitual feedback from your keypresses), but it's actually very advantageous, because it means the higher level of independence from the game. Instead of the standard mechanism of "involvement into the gameplay" there are other mechanisms of data transmission. So in any case you will receive all needed information on how the game interprets your Input, it's just that this data stream won't continually flow into your mind, it will be delivered on command.

And when it's really necessary, you can have an intensified feedback by switching to the third method of TASing in Taseditor.

Let's review pros and cons of all three methods, one by one.

The three methods of TASing in Taseditor:

  • Traditional method
  • navigating the Input using the Playback cursor by jumping to Bookmarks
  • recording sequences of Input using the keyboard/joypad
  • watching interim results of the Input automatically

  • Nonlinear method
  • navigating the Input using the mouse
  • editing the Input using the mouse/keyboard/joypad
  • watching interim or final results of the Input by user command

  • Semiautomatic method
  • navigating the Input using the mouse
  • editing the Input using the mouse/keyboard/joypad
  • watching interim or final results of the Input automatically

Created with the Personal Edition of HelpNDoc: Easily create Web Help sites


4.1. Traditional TASing

Beginner's Guide ›› 4. TASing Methodology ››

Traditional TASing

This method is similar in form to normal videogames playing, however it is completely different in content and requires different way of thinking.

Editing Input is done here by recording a new Input over existing Input.

To switch between movie watching and editing you have to turn the Recording mode off and on (default hotkey is Q). It's recommended to enable the "Follow cursor" checkbox, in order to observe the recorded Input in the Piano Roll.

General activity:

  1. Put the Playback cursor at the beginning of the edited segment, create a Bookmark, define the goal.
  2. Suppose there's a mistake in the segment, weigh known factors of optimality and figure out the way to fix the mistake.
  3. Navigate to the place of fixing the mistake (e.g. load a Bookmark and, if necessary, quickly repeat the existing Input up to the needed frame).
  4. Play the game in Read+Write mode up to the moment when the target event occurs. The newly recorded Input should be different from old Input in this segment. While recording, create Bookmarks in free slots from time to time to speed up navigation.
  5. If you make a mistake while typing the Input, return to step 3. If you fail to reach the target event using the chosen approach, you can retreat and go to step 8.
  6. [optional step] Save the finished approach to a temporary Bookmark, e.g. to slot 8 or 7.
  7. If this isn't the first approach to the segment, compare the new result to the best old result, using the optimality criterion. If the new approach is better (or it's the first approach), save the result to the Bookmark 9. The slot 9 will be used for keeping the best result of polishing the segment.
  8. If you still want to try different approaches, return to step 2, until you run out of ideas.
  9. [optional step] If you need more ideas, you can get some information from the past by replaying the old segments of the movie (e.g. load the Bookmark 0 left at the beginning of current level). Also you can get some food for the mind from the future, by playing with the game events happening after the current segment.
  10. When there's no more ideas, restore the best approach from the Bookmark 9 into the current movie and proceed to the next segment.

When you're making a test playthrough of the game (i.e. playing with savestates, but without polishing), you only do steps 3 – 5. And you are satisfied with any successful accomplishment of a segment, so after reaching the target for the first time you proceed to the next segment right away. In this kind of playing you only use savestates to speed up navigation in case you make a fatal mistake (e.g. didn't press the A button in time and fell into the pit), only because you don't want to rewrite existing Input from the very beginning of the game.

But when you're seriously TASing the game, you need to try many different approaches in order to find the best one. So you have to repeat steps 2 – 8 many times, until you think the segment is played perfectly. The steps 6 – 9 are what distinguishes real TASing from casual playing with savestates.

The process of Input Recording (step 4) means that you're editing the Input right while watching the results. That is, when watching the paused game state at the frame 200 you prepare the Input for the frame 201 (lay fingers on necessary buttons) and then pass the Input to the game using Frame Advance, and immediately see the outcome – the game state at the frame 201 (granted that you look at the Memory Watch, because the game screen rendering is one frame behind). Usually this outcome is only an intermediate result, which means you can use it to estimate your progress (step 5) but should not use it to compare current and previous approaches of playing the segment (step 7). So you shouldn't apply the optimality criterion after every frame. Even if at the beginning of the segment you outrun the previous approach, you may fall behind somewhere in the middle. Only when you reach the end of the segment (step 6) you get an objective base for comparing.

Steps 3 and 4 take the most of time in this cycle. Often before reaching the target event you have to repeat steps 3, 5 and 5 several times in a row, recording and discarding decisions that are obviously wrong even without comparing them to old approaches. For example, if in the middle of acceleration Mario gets killed by an enemy, there's no point in entering the remaining buttons needed for acceleration. You have to return back and rewrite the Input in such a way that the enemy misses. In a tough situation it's even better to break current segment into two subsegments (before and after the interaction with the enemy), in order to optimize them separately. If you don't do so, you will probably become tired after finishing the first approach, and you'll decide to leave the segment as it is. See, you've got to manage your effort optimally as well!

Since the Input editing in this method is done using the Playback cursor (and not the mouse cursor), for an effective work you must learn to quickly deliver the light-blue cursor to any frame necessary. Upon gaining an experience, TASers accustom themselves to "juggle" with Bookmarks using the motor memory. They mechanically create intermediate and auxiliary Bookmarks while recording the Input, and find the necessary Bookmark slot without looking.

This virtuosity comes with time, usually after having finished a couple of TASes. You cultivate certain habits, one finger adheres to Frame Advance key, Bookmark slots become logically distributed according to their duties, so that fingers press right keys at right moments on their own. For example, that's how some TASers distribute 10 slots:

  • F10 points to the beginning of current level of the game, so you can see recent segments without rewatching the whole movie. Used for navigation.
  • F9 is responsible for keeping the best result of current segment. Used for storing.
  • F2-F6 serve as Bookmarks left after every hard-to-reproduce action of the current approach to the segment. These Bookmarks are needed for a quick navigation along the current segment. One of them points to the beginning of the segment, and other are used when necessary (may be left unused, if the segment is short and simple). These Bookmarks are created mechanically while successfully progressing with Input Recording. Used for navigation.
  • F1 stores a backup copy of the movie at the last successful frame. Current movie state is saved to this slot with paranoid frequency, so you could always return to this stable state from any situation (e.g. after loading some other Bookmarks, or after recording an experiment). This is how the traditional method implements simple undo feature. Sometimes in addition to the F1 people use F2 to provide two levels of undo, but this complicates the logic of backups (as you'd have to alternate the slots), and usually one slot is sufficient. Used for storing.
  • F7-F8 may store results of alternative strategies that aren't better than the contents of the F9, yet they are of some interest. Also, one of these slots (or one of F2-F6) is used during step 6 to temporarily save the result of the newly finished approach, in order to compare it to the old best result more precisely (by quickly switching between F8 and F9). Used for storing.
  • When creating an improvement for someone else's TAS, slots F5-F7 may be allotted for various points of the old movie. For example, F5 is responsible for the beginning of current level in old movie, F6 – for the beginning of current segment in old movie, F7 – for the end of the current segment in old movie. Used for storing and navigating the old movie contents.

This skill is very similar to the skill of playing a musical instrument. The quicker you work it out, the better, because until you master it you will think the traditional TASing is too tiresome. That's why many people consider the bar to be too high. But once you master the technique of rapid savestates usage, other intricacies of TASing will come easier.

However, now there is Taseditor. It revokes the need to train fingers, allowing to quickly navigate the movie without using Bookmarks. Also, you don't need to accustom to constant backups into F1, since there is the History Log. So technically you can forget about the traditional method and right away start editing the movie and testing approaches using the nonlinear method of TASing .

Anyway, Taseditor slightly expands possibilities of the traditional method:

  • New ways to navigate with the Playback cursor, allowing to get to the needed place faster and create savestates less often.
  • When loading a Bookmark, the movie doesn't truncate after the bookmarked frame. This allows, for example, to record the segment of frames 900-1000 and then rerecord the segment 700-900 without losing the data from 900-1000.
  • All possibilities of an external Input editor (copy/paste, etc).
  • Visualization of Bookmarks, Input, lag and so on.
  • Additional tools: multitracking, superimposing, auto-adjustment of Input, etc.

Pros of the method:

+ The process is intuitive for any gamer.

+ Constant feedback allows to adapt to the game while editing the Input, adjust your decisions and discard incorrect approaches prematurely.

+ The boundaries of current segment are always marked with Bookmarks (for navigation), thus training TASer to be orderly (which will pay off).

Cons of the method:

– The insistent game feedback provokes TASer to discard some illogical but potentially advantageous approaches.

– Slow navigation may distract and increase fatigability.

– Since the number of Bookmarks is limited, the markings of previous segments are lost when creating a new segment, so you have to write down some things in a text file.

When the method is recommended to use: never. You can use the Recording to make the first test playthrough of a segment (or the whole game), i.e. when you don't need precision. But for polishing a segment this method is inferior. Yet it's reasonable to learn it, because many modern emulators have sufficient tools for applying the method, while Taseditor is only in FCEUX as yet.

The next method is more effective, but it even less resembles a normal gaming.

Created with the Personal Edition of HelpNDoc: Easily create CHM Help documents


4.2. Nonlinear TASing

Beginner's Guide ›› 4. TASing Methodology ››

Nonlinear TASing

This is the main method when working with Taseditor. At first it may seem rather different from the traditional TASing, however, they are essentially very similar.

When using this method, the Recording mode should always be off. The "Auto-restore last position" checkbox should be disabled. The "Turbo seek" and "Follow cursor" checkboxes are usually disabled, but may be enabled when necessary.

General activity:

  1. Scroll the Piano Roll to the beginning of the edited segment, put the Playback cursor here, define the goal. It's also recommended to mark the beginning with a Marker.
  2. Suppose there's a mistake in the segment, weigh known factors of optimality and figure out the way to fix the mistake.
  3. The mouse cursor navigation to any frame of the current segment is practically instant.
  4. Edit the segment with the mouse. You can either change the Input blindly, or move the Playback cursor from time to time in order to check with the game. The steps 3 and 4 are constantly alternating until you consider the editing complete.
  5. Detect the end of the segment by putting the Playback cursor at the target event.
  6. [optional step] Save the finished approach to any free Bookmark, e.g. to slot 8 or 7.
  7. If this isn't the first approach to the segment, compare the new result to the best old result, using the optimality criterion. If the new approach is better (or it's the first approach), save the result to the Bookmark 9. The slot 9 will be used for keeping the best result of polishing the segment.
  8. If you still want to try different approaches, return to step 2, until you run out of ideas.
  9. [optional step] If you need more ideas, you can get some information from the past or the future by moving the Playback cursor to different segments of the movie or unpausing the emulator. When necessary, you can quickly draw a rough Input for watching the upcoming events of the game.
  10. When there's no more ideas, restore the best approach from the History Log or the Bookmark 9 into the current movie and proceed to the next segment.

Since all created approaches to playing the segment are automatically saved in the History Log, you could follow the temptation to rely on the Log and not save the approaches to Bookmarks (steps 6 and 7), instead just reach the target event once and then experiment with this Input, gradually improving it (and simply undoing all the changes that are for the worse). Such perfunctory way of TASing is technically possible, but not recommended, because it doesn't let you think far outside the terms of the first approach (because you subconsciously fear to lose the old best approach by leaving it too far away).

Even if the outcome of the latest modification of the Input made the game behave worse, you should not immediately forget it and revert to the previous state of the movie, better try to examine the cause of the worsening and continue the modification to turn it into an improvement. And in order to never be afraid to lose the previous successful playthrough in the depths of the History Log, you should do exactly like they do in the traditional TASing – allot a special slot for storing the best result and set this Bookmark to the end of the segment every time you improve the result.

And you can do the same with those promising approaches that are somewhat better, but somewhat worse than the current best result. When you're saving all alternative approaches to separate Bookmarks, you can safely remove their Input from the working movie or change it beyond recognition, because you can return to any of them with a single key press, and no need to search within the History Log.

Unlike the traditional TASing method, here you may lose sight of dividing the movie into logical segments, because now you don't have to mark the beginning and the end of the current segment with Bookmarks. However, it's still recommended to keep an order and mark the beginning of every important segment with Markers, in order to limit the number of optimality factors.

The beginning and the end of a segment are usually associated with certain events of the game, and not with a soulless frame number. But since the starting event of the segment is not affected by modifying the Input of the segment, this event will always occur at the same frame, so you can lock the frame with a Marker.

The ending event of the segment may occur in various points of time, depending on the Input in the segment. So if you mark the end with a Marker, you will need to move the Marker up or down every time you change the target event by modifying the Input. Often it's impractical to spend time on dragging Markers, so instead of the trailing Marker you can use the aforementioned Bookmark which stores the best approach and its icon serves as a mark of the end of current segment.

As for simple segments, you can polish them without marking the ending frame at all, by simply relying on your own memory and on the green arrow provided by Taseditor. With this green arrow the Taseditor hints you the frame where you've stopped watching the segment the last time (before you started modifying the Input of the segment). Usually this is the frame where the target event was detected in previous approach. So you may as well replay the updated segment up to the frame and compare the new result with the old one. For example, if the target event is now detected 2 frames above the green arrow, it means you've outran previous result by 2 frames, so the new Input is better (if your criterion is speed). This entire logical chain pops in your mind once you glance at the Piano Roll after watching the outcome of the recent Input modification.

The process of polishing the Input in the nonlinear method is a constant alternation of editing and watching the segment. You analyze the situation during the watching and right after stopping the watching.

Possible ways to watch the outcome of Input:

  • unpause the emulator by pressing the Pause hotkey or the middle mouse button. After the segment ends, you have to pause emulator manually (and no problem if you stop it a bit later, since you can always rewind up)
  • start seeking to the green arrow by pressing the Restore Playback hotkey or the middle mouse button (when the green arrow is outside the Greenzone).
  • start seeking to the nearest Marker by holding Shift and pressing the middle mouse button
  • start seeking to the Selection cursor by holding Ctrl and pressing the middle mouse button, granted that the Selection cursor is below the Playback cursor
  • rewatch the segment from the Selection cursor position to the Playback cursor position by by holding Ctrl and pressing the middle mouse button, granted that the Selection cursor is above the Playback cursor
  • just drag the Playback cursor manually, using the mouse cursor
  • move the Playback cursor by holding the right mouse button and rolling the mouse wheel
  • shift the Playback cursor frame-by-frame using Frame Rewind and Frame Advance hotkeys or < and > buttons or Shift + Up и Shift + Down keys
  • and there are other ways of navigation with the Playback cursor .

Most often you are going to either click the middle mouse button or move the Playback cursor by scrolling the mouse wheel. Don't attach yourself to a single one of the ways, learn to use them depending on the situation.

The ratio between the time spent on editing and on watching depends on the complexity of the current segment and on the volume of your knowledge about the game. The more you TAS a single game, the better you are aware of its regularities. So near the end of your project you'll be able to foresee the outcome of your Input modifications before even attempting to edit them in. Then you'll only need to watch the segment in order to confirm your guess.

In some cases you can judge about the optimality of an Input by seeing its interim results and not even watching the segment to the end. For example, if the character bumps into a wall and nullifies his speed in the middle of the segment, you can immediately guess that he is going to reach the target event later than previous time. So sometimes you want to only watch a few frames and continue the editing. However, such a hurry may lead you to reject a solution that is suboptimal at first glance but has a potential to be very successful in another segment. For example, after bumping the wall Mario may accidentally enter inside and go through it. That's why it's recommended to never hurry when TASing, and to watch the current segment to the end, where you can be sure the optimality criterion won't let you down.

Technically you can watch and edit the Input simultaneously. When the "Follow cursor" checkbox is disabled, the Piano Roll stays still, while the movie is played, so you can draw buttonpresses right when they are executed (replayed). For example, when Mario jumps over an obstacle, try to change the height of the jump by drawing and erasing the A button presses without pausing the emulation. You can slow the emulation down by the - and = hotkeys, in order to have more time for clicking while watching.

But when you need to have enough time not just for clicking, but also for thinking, better pause the emulator and TAS properly.

The emulation speed can be both decreased and increased. Before Taseditor, speeding up the emulation was used only for quick replay of the finished part of the movie. But now the turbo emulation also serves as an original way of TASing. With an extremely fast emulation you can feel the interconnection between a buttonpress and its distant outcome.

A good example would be the process of luck manipulation.

Normally, when shooting you can see the connection between pressing the B button and a bullet appearing on screen at the next frame. Applying this association (B = shot) to an in-game situation makes you think "the later I press B, the later the bullet will appear".

But with turbo-seeking you effectively skip all irrelevant steps of the movie (shooting, bullet flying, collision, enemy death, etc), so right after making the B buttonpress you immediately see which item was dropped by the enemy. This new association (B = possibility of a bonus item) makes you think about this in-game situation more like "the type of the item drop depends on when I press B".

This way turbo allows to automatically filter useless information that is produced by the game in the middle of the segment, and only consume the necessary data that appears at the end of the segment.

Here's how you do it:

  • Switch on the "Turbo seek" checkbox. Switch off the "Follow cursor".
  • Set a trial buttonpress of the B at the beginning of the segment where you can shoot the enemy.
  • Watch how the bullet hits the enemy and leave the Playback cursor at the frame where the item is supposedly laying on the ground for a second or two. That will be the end of current segment.
  • So we assume that the first try didn't bring you the needed item, but you know that killing the enemy a bit later may change the outcome. Move the B buttonpress forward one frame (just insert a blank frame before the old position of the buttonpress).
  • This action makes Taseditor rewind the game back, and on FCEUX screen you can see the moment before shooting.
  • Press the middle mouse button or Spacebar (the key assigned to the Restore Playback hotkey). The game events will replay like a flash, and you'll almost immediately see which item the enemy drops now.
  • If the result is not satisfying, press Ctrl + Shift + Insert again, thus inserting another frame before the existing B buttonpress. The shot is delayed by one more frame. Restore Playback again to see the new result.
  • Continue until you find the frame where shooting the enemy brings you the needed item. This way you can test a hundred of options within a minute, by simply pressing the hotkeys and only watching the FCEUX screen.

Pros of the method:

+ Instant navigation.

+ Possibility to skip useless scenes.

+ Detachment from the game flow increases the objectivity of analysis.

Cons of the method:

– Lack of the feedback inherent to normal game-player interaction.

– Emphasis on the mouse controls.

When the method is recommended to use: most of time. Combine this method with the next method in order to construct the full picture of the in-game possibilities.

The next method fixes the main disadvantage of this method.

Created with the Personal Edition of HelpNDoc: Easily create EBooks


4.3. Semiautomatic TASing

Beginner's Guide ›› 4. TASing Methodology ››

Semiautomatic TASing

This method further develops the ideas of the nonlinear TASing method.

In many cases TASer needs to see the result of the Input modification immediately. Ideally, he should realize all the consequences of his decision right at the moment of making the decision. But in reality he has to spend precious time on inputting the decision and navigating with the Playback cursor to the end of the segment.

In these cases you can leave the Playback navigation to Taseditor and just focus on editing. Taseditor will immediately react on any Input modification and display the new result.by bringing the Playback cursor to the end of the current segment.

When you feel the influence of every click, you build very high level of interconnection between TASer and the game. In such close interaction both TASer controls the game and the game urges TASer's actions into right direction. Of course, such high level of interdependency is not always useful, because it narrows your spectrum of thoughts, not allowing to look down on the game and apply a logic from different games and other fields of life.

However, when the current segment is simple and all optimality factors are already known (and you only need to find the perfect combination of them), it's useful to abstract from everything else and devote full attention to going over the possible options. This way you can test a lot of approaches before you become bored with the current segment.

The Recording mode should be off. The "Auto-restore last position" checkbox should be on. The "Turbo seek" and "Follow cursor" checkboxes are usually disabled, but may be enabled when necessary.

General activity:

  1. Scroll the Piano Roll to the beginning of the edited segment, put the Playback cursor here, define the goal.
  2. Detect the end of the segment and leave the Playback cursor there.
  3. Suppose there's a mistake in the segment, weigh known factors of optimality and figure out the way to fix the mistake.
  4. The mouse cursor navigation to any frame of the current segment is practically instant.
  5. Edit the segment with the mouse. After every Input modification the Playback cursor will automatically replay the segment and stop at the frame that was considered to be the end of the segment. If necessary, you can shift the end of the segment by moving the Playback cursor manually (e.g. using the mouse wheel). The steps 4 and 5 are constantly alternating until you consider the editing complete, according to the optimality criterion.
  6. [optional step] Save the finished approach to any free Bookmark, e.g. to slot 8 or 7.
  7. If this isn't the first approach to the segment, compare the new result to the best old result, using the optimality criterion. If the new approach is better (or it's the first approach), save the result to the Bookmark 9. The slot 9 will be used for keeping the best result of polishing the segment.
  8. If you still want to try different series of approaches, return to step 3, until you run out of ideas.
  9. [optional step] If you need more ideas, you can get some information from the past or the future by moving the Playback cursor to different segments of the movie or unpausing the emulator. When necessary, you can quickly draw a rough Input for watching the upcoming events of the game. But when returning to the segment modification you have to return the Playback cursor to the frame of the target event.
  10. When there's no more ideas, restore the best approach from the History Log or the Bookmark 9 into the current movie and proceed to the next segment.

The main difference between this and previous method is that here the Playback cursor is generally located at the end of the current segment, and not at the beginning. Every time the Greenzone truncates, the Playback cursor seeks to the end of the segment, or rather to the frame where the segment end was before you modified the Input. If the Input modification also changed the frame of the target event, you can additionally move the light-blue cursor by mouse wheel if needed. But often there's no need for precise positioning, because you may only need to know the sequence of events occurring in the segment due to the Input modification.

The replay of the current segment is automatically launched after every interim step of the Input modifications, even when you haven't finished the thought yet and are not ready to compare the current result to the result of the previous approach. Fortunately, when TASer is carried away by the editing process, he doesn't look at FCEUX screen and only clicks the Piano Roll, until his idea is implemented in the form of a full-fledged button combination. And when the Input is starting to become interesting, TASer pays attention to the emulator screen or the Memory Watch window.

For example, when you need to create a jump over a pit, you first draw a long row of the R button presses, and you don't care that at the same time the FCEUX screen displays how Mario runs and falls into the pit. You just draw some A buttonpresses, then look at the emulator window and erase or draw additional A buttonpresses, thus changing the beginning and the duration of the jump while watching the trajectory of Mario sprite.

So, the process of polishing the Input in this method is a simultaneous editing and watching the segment. TASer gets in close informational contact with the game and soon starts to think synchronously with its responses. The game starts to help you filter and accept decisions. As a result, you may lose impartiality of your mind and stick to obvious decisions encouraged by the game. That's why you shouldn't use this method all the time, it's recommended to alternate it with the previous one.

Like with the simple nonlinear method, you can change the speed of emulation and get different variations of the semiautomatic method:

  1. editing and watching the changes in real time
  2. editing and watching the changes in slow motion
  3. editing and instantly seeing the final result (turbo)

Turbo-seeking creates an association between two distant events (the beginning and the end of the segment). Here the association is even more efficient, because there's even less intermediaries – the seeking starts before you even release the mouse button when drawing the Input. So you see the distant result almost at the same time you change the decisive Input, even if the game normally only shows the result in a several seconds.

A good example would be the process of searching for the first possible frame of pressing the Start button. Some games actually allow to press the button before there's even any graphics on screen. Besides, after the Start button is activated, games often meditate for some time, not giving you any information if the button worked or not. Only after a second or two you can see the changes in the scenery, thus learning the buttonpress was successful.

In the traditional method of TASing you would need to spend 5-10 minutes on examination of approaches (searching for the very first frame), but the semiautomatic method allows to go over all the approaches much faster:

  • Switch on the "Auto-restore last position" and "Turbo seek" checkboxes. Switch off the "Follow cursor" checkbox.
  • Set a trial Start button press at the frame where it definitely works, e.g. at the frame 100.
  • Watch the game up to the frame where you can already tell by the picture that the Start was successful (e.g. the screen changed to "World 1-1" text). For example, it's the frame 150. Leave the Playback cursor at this frame – this will be the end of the segment.
  • Now remove the trial buttonpress (the FCEUX window will flash and the "World 1-1" will disappear, leaving only the title screen, since there's no more Start button press).
  • Set the Start buttonpress to the beginning of the segment, which is the place where you know it's too early for the buttonpress to be registered. For example, set it to the first frame of the movie. The image in the FCEUX window will flash but then still show the title screen, because the Start didn't work.
  • Hold Ctrl + Shift by one hand and begin pressing Insert key once per a second or so (that really depends on your computer performance). After every Ctrl + Shift + Insert combination the Start buttonpress moves one frame forward, and the FCEUX window shows you if the buttonpress changed the state of the game at frame 150 or not.
  • Until the Start doesn't reach the moment when the game is ready to accept the Input, the FCEUX window will show you the title screen. But when another press of Ctrl + Shift + Insert moves the Start to a suitable frame, the emulator will display the "World 1-1" screen.
  • This way you've found the very first frame to press the Start button. Most likely the frame number will be much less than 100.

In the same way you can search for an optimal duration of holding the A button, trying to land at certain point. Also consider using this method for quick luck manipulation in many games. The automatic turbo-seeking works best when you deal with a single factor of optimality and need to quickly test a hundred of similar approaches.

In general, the semiautomatic method induces you to think less and experiment more. Sure, many videogames allow this way of solving tasks, but TASing requires more from you, so try not to take a fancy to the comfort of this method.

Pros of the method:

+ Instant navigation and high speed of the working process incites to conduct more tests.

+ Constant feedback allows to adapt to the game while editing the Input, adjust your decisions and discard incorrect approaches prematurely.

+ Possibility to skip useless scenes.

Cons of the method:

– The insistent game feedback provokes TASer to discard some illogical but potentially advantageous approaches.

– Emphasis on the mouse controls.

When the method is recommended to use: when you need to polish the segment already knowing all of its optimality factors. E.g. for quick resyncing of the old Input this method is better than previous. Also it may be better for making an initial playthrough of a segment.

Now that you know the main principles of working in Taseditor, you can begin TASing your game of interest. Practice is the best teacher, so you'll only learn all intricacies of the activity by engaging in a real development of your own TAS.

After several weeks of practical TASing it's recommended to reread the 3rd and 4th chapters of this Guide, in order to understand the text on a deeper level.

In the next chapter: tweaking the program .

PRACTICE: Thoroughly polish the Input in the segments of your test movie. If the initial dividing appears to be wrong – just redo it on the fly.

Use only the 2nd and the 3rd method of TASing, because traditional method is obsolete. Also try using turbo when suitable.

Estimated time: 30-60 minutes.

Created with the Personal Edition of HelpNDoc: Produce Kindle eBooks easily


5. Program customization

Beginner's Guide ››

Program customization

Certain useful features of Taseditor are disabled by default, because using them requires understanding of their working principles. This chapter describes all Taseditor options and settings, as well as FCEUX settings that affect your work in Taseditor.

Settings are kept in the fceux.cfg file in the emulator's main folder. If you delete this file, all settings will reset to default values when you launch FCEUX.

First, if you've already read the chapter 2 and understood the purpose of all GUI elements, you should disable pop-up tooltips (intended for newbies only). Go to the "Help" submenu of Taseditor main menu and uncheck the option "Enable Tooltips". Before doing it you may want to actually read all the tooltips by pointing the mouse cursor at different elements of TAS Editor window, and thus consolidate your knowledge of the GUI.

Now open the "View" submenu.

The "Find Note window" brings up the window dedicated to searching text in Marker Notes. This function is useful when you're documenting your movie with Notes. It's described in the next chapter.

Then there are several checkboxes allowing to customize the program interface. To try the customization possibilities, create a test project and experiment with it.

View -> Display Branch Screenshots

Displays pop-up screenshots when you point mouse cursor over Bookmarks. The screenshot helps you to recall movie events saved to the Bookmark, which simplifies searching for the needed branch of the movie, as you don't have to actually load the Bookmark when you need to have an idea on its contents. This way you can also quickly compare results of several alternative approaches.

This option is enabled by default. If disabled, no screenshots will pop up on mouse hover.

It's recommended to have it enabled, unless you're annoyed with pop-up pictures partially obstructing the view on the Piano Roll.

View -> Display Branch Descriptions

Displays pop-up descriptions when you point mouse cursor over Bookmarks. The text, as well as the screenshot, gives you additional information about the contents of the Bookmark, helping to decide whether this branch should be loaded or not.

The description text is taken from the Marker above the frame of that Bookmark. The Marker itself may be actually removed from the working movie long ago, but if the Bookmark was created while the Marked existed, then this Marker still exists in the branch of this Bookmark. And if you load this Bookmark, the Marker will reappear on its place.

So, when trying alternative strategies of playing through a large segment (e.g. whole level of the game), before saving every approach to a separate branch, you can make a name for the approach by setting a Marker at the Playback cursor position and typing a text message like "here I chose upper way" or just "upper way". After that, save a Bookmark on that frame. Then you can remove the Marker together with the Input of the old approach and create next approach by applying another strategy of playing the segment. When the new approach if finished and replayed, you can again create a Marker with a Note like "here I chose lower way" and save all that to another Bookmark. After that you can save the project and, say, close Taseditor. Next day you can easily recall all pros and cons of the two strategies you tried. Each Bookmark will show you the screenshot of the bookmarked frame and the text you wrote for that Bookmark. While it can be hard to distinguish the strategies by screenshots (since both approaches end at the same event of the game), but text descriptions will make them easy to recognize.

This option is enabled by default. If disabled, no descriptions will pop up on mouse hover.

It's recommended to have it enabled, unless you're annoyed with pop-up text fields.

View -> Enable Hot Changes

Switches the Hot Changes feature on and off.

Enabled by default. If disabled, all buttonpress symbols will be displayed in a standard black color. Otherwise, each symbol will have its own level of "hotness", depending on how long ago the corresponding Piano Roll cell was edited. Recently modified buttonpresses are more hot, so they are displayed by more intense shade of red. As the hotness decreases, the symbol colors become darker (more cold) and finally turn into standard black.

In total, Taseditor supports 15 shades of hotness + zeroth black color. When you change the state of an Input cell, it receives maximum hotness value (15), and all the previously edited cells cool down by 1. Thereby you only need a quick look at the Piano Roll to get an idea which edits were done just recently and which were done before, or long ago.

Also, with Hot Changes you can see which buttonpresses were recently removed – instead of an empty cell there will be a dash of the corresponding color. The dash also changes its color while cooling down, and after 15 levels it finally disappears.

The same dashes appear when you insert new frames in the movie.

It's recommended to enable this feature to increase the usability of Taseditor. In theory it should even increase your working speed, because this way you never have to recall which actions you did a minute ago. Of course even without Hot Changes you can always remind the sequence of last actions by reverting History (making several Ctrl + Z keypresses) and then returning the movie to normal state again (making as many Ctrl + Y keypresses). But in this case you will also truncate the Greenzone. So better just leave the Hot Changes enabled.

The only downside of this feature is that Hot Changes data will be stored in the History Log and in FM3 project file, thus increasing the amount of occupied memory.

View -> Follow undo context

Scrolls the Piano Roll to relevant place every time you make an undo or redo. A purple pointer appears on the modified frame for a brief moment, thus drawing your attention to the movie changes.

This option is enabled by default. If disabled, the Piano Roll won't automatically scroll to the purple pointer.

It's recommended to have it enabled, in order to be able to backtrack undos. Usually, right after you revert an operation you want to make another edit on the same frame or nearby, so the autoscrolling is useful.

View -> Follow Marker Note context

Scrolls the Piano Roll to relevant Marker when you start editing its Note. For example, when you click the upper edit field to start editing the Note of the Marker above the Playback cursor, Piano Roll jumps to that Marker, allowing you to see its context (neighbor Markers and Input). And when you click the lower edit field (a Note above the Selection cursor), Piano Roll scrolls to the Marker above the Selection. This way you can observe the surroundings of the relevant Marker while editing its Note.

This option is enabled by default. If disabled, the Piano Roll won't automatically scroll to the Markers.

It's recommended to have it enabled.

And the View settings are over. During your future work you likely won't need to change these checkboxes.

Now open the "Config" submenu. Options listed in this menu affect Taseditor workflow more significantly. You may need reconfiguring some of them more than once.

Config -> Project file saving options

Opens the dialog window where you can configure the autosave function and select which aspects should be saved to FM3 files.

Taseditor has the feature of automatically saving current project to disk when user doesn't save it manually (Ctrl + S) for too long. Before Taseditor, TASers saved their movie to disk every time they saved a savestate. But Taseditor projects store much more data, and saving FM3 files can take several seconds, so it's not reasonable to resave them too often.

The default autosave period is 15 minutes. This means, if you've made some substantial changes to the project (e.g. you edited Input, and an asterisk appeared in the TAS Editor window caption), and then didn't save project for 15 minutes, Taseditor will remind you about that or just execute saving itself, depending on the state of the "silently" checkbox. If the checkbox is enabled, Taseditor silently saves the project to disk under the same filename. If it is disabled, Taseditor brings up the "Save As" dialog, where you can confirm the saving or cancel it. In the latter case Taseditor will wait another period of time until reminding you about the unsaved data.

The autosave function only works when current project already has a filename.

Maximum possible value of the period is 1440 minutes (24 hours). You can disable this function by switching off the "Autosave project" checkbox, but that's not recommended.

Config -> Set max undo levels

Specifies the maximum number of undo steps, how many times you can restore previous state of the project by pressing Ctrl + Z.

The History Log needs a lot of computer memory and takes some disk space to save FM3 files. The whole Log is stored in project files in compressed state. The compression is done in background – when the emulator is idle, Taseditor gradually compresses new items of the History Log. Thanks to this behavior, the History Log size doesn't affect FM3 saving time much.

With this setting you can adjust the amount of memory occupied by History Log. By default you have 100 undo levels, which means you can revert up to hundred of recent movie edits. It's not very much, because during real TASing you make lots of various edits within a small time span, as the time runs imperceptibly. If your computer has enough RAM, you can increase the "max undo levels" value up to the maximum possible number – 1000.

Config -> Set Greenzone capacity

Defines the maximum size of the Greenzone. The Greenzone is used for easier Playback cursor navigation, allowing to instantly return to any frame that has been emulated. It needs a lot of computer memory to store emulator's information and a lot of disk space for saving FM3 projects.

The more of green and red frames there are in the Piano Roll, the more memory the Greenzone occupies. For most NES games 1 frame costs about 10 kilobytes (compressed data). So, big movie projects may take hundreds of megabytes. It affects the project loading and saving time.

To decrease the amount of needed memory, Taseditor regularly cleans the Greenzone tail, forgetting the info about segments that are too far from the Playback cursor.

This cleaning doesn't mean the Greenzone becomes inaccessible (white) on those frames. That would be very inconvenient, because to replay these frames you would need to wait until the emulation runs from the beginning of the movie. To avoid such inconvenience and still free some memory from old Greenzone sections, Taseditor uses gradual rarefication of the Greenzone tail.

This process works like shown on the picture to the right. The light-blue cursor runs down along the Piano Roll. The cursor is the head of the Greenzone. It leaves green/red lines behind, but far above it some of the lines become pale again. At first, every odd frame is cleared, then 3 of every 4, then 7 of 8, and finally 15 of 16.

Thus the Greenzone tail contains many hollow sections. And if you decide to send emulator to a frame inside such hollow section, you'll need to wait while emulation runs to it from the nearest bright Greenzone frame. But since bright frames alternate every 2 or 4 frames, the waiting will only last a split second, so you won't likely notice the difference between jumping to a regular Greenzone frame (instant jump) and jumping to a cleared tail (instant seeking).

By adjusting the "Set greenzone capacity" setting you can specify how many Greenzone frames (starting from its head) must stay untouched. On the picture to the right this number is 8.

For an experiment, choose the "Set greenzone capacity" item, a dialog window will appear asking you to enter a number, type 100 and press OK. This will mean that first hundred of frames above the Playback cursor should not be cleaned. Any cursor navigation along this area will be instant, so you may drag the light-blue cursor and use rewind with maximum comfort. After the first hundred of frames the cleaning will be removing every other frame – you'll see alternation of bright and pale lines in the Piano Roll. This alternation will last for about 200 frames. The Playback cursor navigation along the area of 200 frames will also be almost instant.

This way the Greenzone covers 100 + 200 = 300 frames, while only 100 + 100 = 200 frames are stored in memory. Then, during next 400 frames, every filled line will alternate with 3 cleared lines, and so on. In total, the Greenzone will only occupy memory needed for storing the data of 500 frames (about 5 MB), while the accessible area will be 3100 frames (about a minute).

By default, the Greenzone capacity is 10000 frames. This should be enough for most TASes. It's recommended to TAS with no less than 1000 frames of Greenzone capacity, because the further economy would be impractical.

The maximum number for that parameter is 50000.

Config -> Enable Greenzoning

Controls the process of collecting data to the Greenzone.

If the option is enabled, every new frame is saved into the Greenzone right after it has been emulated. This is intended behavior of Taseditor, so the option is enabled by default.

Disabling this option may be useful in rare cases, for example, when running bots which need high performance. But in normal situations it's recommended to have this function enabled.

Config -> Autofire Pattern skips Lag

Accounts for lag when you're using patterns (Alt + clicks on Input).

If the option is disabled, patterns appear in the Piano Roll exactly like they were coded (e.g. for the pattern "Alternating (1010...)" the new buttonpresses will indeed alternate one after another).

If the option is enabled, the resulting sequence of buttonpresses may differ from original pattern (lag frames will have additional gaps not present in the pattern).

Since lag frames aren't accounted by most games, you have to skip red lines of the Piano Roll to correctly calculate the gaps between presses. For instance, if there must be exactly 3 blank frames between every buttonpress (pattern "10001000"), but there's also one lag frame in the middle of current segment, you have to add 1 more blank frame (100001000).

This option is enabled by default. It's recommended to leave it enabled, because in vast majority of cases you'll need to skip lag frames, in order to adapt buttonpresses to how the game interprets Input.

Config -> Auto-adjust Input according to Lag

Enables automatic adjustment of Input according to changes of lag data.

Basically, games only care about Input at green lines of the Piano Roll. It's pointless to draw any Input on red lines, because during lag frames the game doesn't poll Input. Those frames simply don't exist from the point of view of the game engine.

When you edit Input, you change the flow of game events, and lag may appear on different frames too. If those frames previously had a meaningful Input, this Input must be shifted to the frames without lag, to allow it to affect the game.

If this checkbox is enabled, you won't have to adjust the Input manually every time the Lag appears on different frames. Taseditor will insert an extra line at every new lag frame, thus shifting Input 1 frame down. And when an old lag frame disappears, Taseditor will remove respective frames from the movie, thus shifting Input up. As a result, you can be sure that the game will always perceive your old Input correctly, no matter any Lag changes.

Auto-adjustment operations are done by Taseditor only when you're watching (emulating) a segment, i.e. when Playback cursor runs through pale Piano Roll lines. The result of these operations is saved into the current History Log item.

This feature is enabled by default, and it's recommended to always work with the function enabled. It significantly increases the comfort of TASing, especially when dealing with lag-heavy games.

Config -> Draw Input by dragging

Allows to literally draw Input by holding the left mouse button and moving the mouse cursor over the Piano Roll.

This option is enabled by default, so you can quickly draw or erase a long line of buttonpresses.

Drawing/erasing is usually constrained by single column, which allows user to do sweeping motions with the mouse. But if you hold the Shift key while drawing, you will be able to draw/erase Input freely (it's rather impractical, but fun).

If you disable this option, your clicks will only set/unset single buttonpresses. It may be necessary, for example, if you have trembling hands. But otherwise enabling this feature is recommended.

Config -> Combine consecutive Recordings/Draws

Combines consecutive operations of Input Recording into single item of the History Log. Also combines all Input drawn with the same press of mouse button.

This feature is disabled by default. So when you're recording Input, every recorded frame will create a separate item in the History Log, and you can undo changes for any frame. Also, when you're drawing Input, every new stroke will create a new History Log item, and you can undo each of them separately.

However, in real TASing you don't need such precision of the undo. In fact, it may even become irritating when you have to undo every buttonpress separately. So, to save considerable amount of space in History Log, it's recommended to enable this option.

Config -> Use 1P keys for all single Recordings

Allows to record any joypad Input using only the first gamepad (1P). This function is used when you record Input traditional way using multitracking method to take turns for different players, e.g. first you record a short segment of Input for player one (1P), then record the Input for 2P and so on.

Thanks to multitracking, you don't have to press buttons on both controllers at once. And with the "Use 1P keys for all single Recordings" option you don't even have to configure 2P controls, because the same keys used for 1P can be used for all the rest joypads too.

The option is enabled by default. If you disable it, emulator will use the second controller keys for recording 2P.

It's recommended to have it enabled, in order to save the space on the keyboard.

Config -> Use Input keys for Column Set

Allows editing Input in selected frames by pressing corresponding joypad keys.

This feature is intended to speed up the Input editing process. To mass-set/mass-unset buttonpresses in a given segment, you usually either draw with mouse, or select a range of frames and click the necessary symbol in the Piano Roll Header – the symbol flashes and the respective Input changes in all the selected frames.

With the "Use Input keys for Column Set" option you can press real keys (assigned to joypads) instead of clicking the Piano Roll Header. The result will be the same.

The option is disabled by default. Turn it on if you mostly use the new TASing methods and don't record Input traditional way. But when you're using Recording, either disable it or just remove the Selection to avoid Input changes on the selected frames when pressing joypad buttons.

With this feature you can record joypad buttons even when Recording is off. Put the Selection cursor to the frame you want to apply Input to, and press the needed joypad buttons.

Multitracking mode in this case works the same way as with regular Recording. For example, if the "2P" radiobutton is chosen at the moment, pressing the key assigned to the A button will only record Input for the "A" column of the 2nd player.

Config -> Bind Markers to Input

Attaches Markers to Input. If the option is enabled, various Input editing functions will also affect Markers. For example, inserting blank frames into the movie will shift down both Input and Markers.

Usually Markers are set to frames where certain in-game events occur. And when you improve previous result and reach the given place earlier than before, the corresponding Marker (set there after previous attempt) should point to an earlier frame now. Sometimes you have to drag such Markers manually. But thanks to the binding feature, Markers will shift themselves during Input modifications, so the manual adjustment of Markers is rarely needed.

Detaching Markers may be necessary when you need to edit Input without shifting Markers. For example, when you need to remove a part of Input, leaving Markers intact.

The option is on by default. It's recommended to work with attached Markers most of the time, temporarily detaching them when necessary.

For clarification, Taseditor highlights attached Markers with a pale yellow color, and detached Markers with more bright yellow.

Config -> Empty new Marker Notes

Defines the default Notes text. If the option is set, each newly created Marker will have an empty Note. If not set, the new Marker will copy the above Marker's Note text.

The option is enabled by default. It's recommended to left it on and type original Notes for important Markers, thus not leaving all Notes blank.

Config -> Old control scheme for Branching

Imitates certain limitations of the traditional TASing method, particularly related to handling the Bookmarks (savestates).

The option is disabled by default, so hotkeys F1-F10 are used to load branch of the the corresponding Bookmarks, and the numeric keys 1-10 are used for simple jumps to bookmarked frames without changing the movie.

Also, Input Recording is switched on with a simple press of the Toggle Read-Only hotkey.

But if you enable this option, the controls scheme will be the same as in old emulators. Pressing F1-F10 will work depending on the Recording mode. When the Recording is off, functional keys jump to respective Bookmark frame, and when Recording is on, F1-F10 keys load the branch of the Bookmark.

Also, Input Recording won't work until you load some Bookmark. This behavior allows you to press the Toggle Read-Only hotkey in the middle of watching the movie, without overwriting old Input until you actually load a savestate.

Plus, there will be a red frame around the "current slot" number in the Bookmarks List. Press numeric keys 1-10 to switch the current slot.

This option is only left here to help old TASers move to Taseditor. But it's recommended to use the new controls scheme, because it fits the specifics of TASing process in Taseditor much better.

Config -> Branches restore entire Movie

Defines the way a branch is restored when you load its Bookmark.

The option is enabled by default, so when you're loading a Bookmark, you replace the current movie with the movie state stored in that Bookmark.

If this option is disabled, when you're loading a Bookmark, the current movie is replaced with a truncated version of the bookmarked movie state. The movie will be truncated at the bookmarked frame, thus imitating the traditional behavior of loading a savestate: savestates only recover the part of the movie before the Playback cursor, and the rest frames (from the light-blue cursor to the movie end) aren't loaded. This makes sense when TASing traditional way, because after loading a savestate TASer usually records a new Input starting from the position of the Playback cursor, so there's no need to load the data that is going to be be overwritten anyway. But in Taseditor the movie is edited independently from the Playback cursor position, so you can load the entire movie state from Bookmarks, without caring if the Playback cursor is in the end of the movie or it is in the middle.

It's recommended to leave this option enabled.

Config -> HUD in Branch screenshots

Defines the way to capture screenshots when creating Bookmarks.

If the option is on, it takes a snapshot of the whole emulator window, including icons and emulator messages, Lua output and other data placed over the game picture. If the option is disabled, Bookmarks will only capture the game output.

The option is enabled by default. It's recommended to leave it on, in order to use Lua output and frame counter when comparing alternate approaches to playing through a segment.

Config -> Autopause at the end of Movie

Automatically stops movie playback at the last frame, unless it started playing from the last frame.

When replaying a finished (or partially finished) movie, you usually don't want to pass over the boundary of its Input. That's why the "Autopause at the end of Movie" option is enabled by default. If you disable it, the emulator will play infinitely after the current movie Input ended, expanding the movie size until you press Pause or the middle mouse button.

It's recommended to leave this option enabled.

Now you are aware of all Taseditor settings, the remaining part of the chapter describes FCEUX emulator settings that may be useful for a TASer.

If you are going to TAS traditional way, it's obligatory to set the first controller buttons to such keys that would be easy to press together with the Frame Advance hotkey. While FCEUX supports binding the virtual NES joypad to a real PC gamepad, it's recommended to use the keyboard for recording Input, in order to have fast access to Frame Advance, Frame Rewind, Pause, and to all 10 savestate slots.

However, if you use Taseditor as intended, you won't need to use Recording too much, and even in cases when you use it (for example, when recording a test playthrough of a level), an access to functional keys isn't critical. So, you can reassign the game controls to a USB gamepad, if you have one.

Virtual controller buttons are configured in FCEUX the following way. Choose Config -> Input in emulator main menu. In the appeared dialog, select the "Gamepad" item from the leftmost drop-down listbox (usually it's already selected). Click the left Configure button (since you need to configure the first gamepad). In the new window click the Up button, then a small window will appear, now press the keyboard key you want to set for the virtual Up button. Press that key 2nd time to confirms your choice, or just click Close. Then you need to do the same for the rest buttons of NES gamepad – Down, Left, Right, Select, Start, B, A. After you're done with the first controller buttons (Virtual Gamepad 1), you may close both windows: Gamepad and Input Configuration.

You can check the assigned buttons while playing the game or while Taseditor is engaged – as you press them, the corresponding symbols in the Piano Roll Header will shine with green color. Besides, if you enable Input display (FCEUX: Config -> Display -> Input Display -> 2 player), FCEUX screen will show you the pressed buttons too.

In addition to recording the regular gaming session, virtual gamepad buttons may be used to quickly set Input when editing movie (see Config -> Use Input keys for Column Set ). Select a range of frames where you want to change Input and press the key you assigned to a button of the virtual gamepad.

When you map the virtual buttons to keyboard keys, make sure none of the emulator or Taseditor hotkeys are already assigned to those keys. The full list of default hotkeys can be found in the Reference .

Some FCEUX hotkeys don't have default mapping (they're not mapped to any key yet). You can configure them the following way. In the emulator main menu choose Config -> Map Hotkeys. A window listing all possible emulator hotkeys will appear. Choose the necessary hotkey, double-click it and then press the desired keyboard key.

First of all, find the item called "Open TAS Editor" and double-click it. In the appeared window press the key that you will always use to quickly launch Taseditor.

Second, find the item "Reload ROM or TAS Editor Project" and either remap it or remember the default combination (Ctrl + F1). This hotkey will help you quickly return to your interrupted work – just launch FCEUX, press the Reload ROM hotkey, then press the aforementioned Open TAS Editor hotkey, and then again Reload ROM (this time it will work as Reload TAS Editor Project). This way you'll return to the state of your paused work in a split second.

Now look at the hotkeys "Frame Advance" и "Frame Rewind". They are used for Playback cursor navigation. By default they are mapped to "\" and "Backspace". You can reconfigure them to more handy keys or just use the mouse wheel for the Playback cursor frame-by-frame navigation.

Also see the "Speed Down" and "Speed Up" hotkeys. You may consider remapping them to Numpad keys "+" and "-".

The "Pause" и "Restore Playback" hotkeys are set to "Pause/Break" and "Spacebar" keys by default, but in most cases it's easier to use the middle mouse button instead of these hotkeys, so you can even reassign the "Spacebar" for something else if you wish.

Finally, there is the "Cancel Seeking" hotkey ("Esc" key by default). Pressing it is the same as clicking the Taseditor progressbar – if the Playback was seeking to a target frame, the seeking will be aborted.

Some FCEUX hotkeys don't work when Taseditor is engaged. For example, the "Open ROM" won't work – you have to load ROM before running Taseditor. This is done for mistake-proofing .

The next chapter describes additional features of Taseditor . You may postpone reading it until you are used to main features. Anyway, now you're ready enough for productive work in Taseditor.

Created with the Personal Edition of HelpNDoc: Write EPub books for the iPad


6. Advanced Features

Beginner's Guide ››

Advanced Features

1. How to share projects.

2. Patterns usage.

3. Effective usage of Markers.

4. Lua usage.

1. How to share projects.

A Taseditor project is saved to disk as an .fm3 file. All essential aspects of the work process are saved into this file, making it possible to restore the postponed work in its exact state. The size of such "instant snapshot" may be pretty huge (depending on the Greenzone size, it may take hundreds of megabytes).

When you want to publish your project in the Internet (for example, as a TASVideos submission), it's better to share only the most important information, but not the whole snapshot of your working process. To do that, choose File -> Save Compact in Taseditor's main menu. The "Save Compact" window will appear, prompting you to select which aspects you want to save to the new FM3 file.

Binary format of Input – save movie Input in binary form. This option is related to fm2 format, which is the base of the fm3 format. If you uncheck it, Input will be saved to the fm3 file in text format, which will increase file size but leave the possibility to edit it in any text editor. However, Taseditor is much better suited for editing movies, so it's recommended to keep that checkbox set, and avoid changing FM3 projects outside Taseditor. Anyway, in non-compact fm3 projects (saved regular way) Input is always stored in binary.

Markers – save Markers to the file. The movie Input is always saved to fm3 file, because without it emulator won't be able to open fm3 files. But without Markers the movie replay is still possible, so you can uncheck the checkbox if you don't want to share them. Although this way your fm3 won't differ much from an fm2 movie, so it's recommended to leave that checkbox checked, to share all current Markers and their Notes in the compact project. The file size will increase insignificantly.

Bookmarks – save all Bookmarks and their branches data to the file. It's recommended to leave this option checked. The file size will increase insignificantly.

History – save History Log to the file. The file size will increase by several megabytes. Usually there's no need to publish the data. So it's recommended to uncheck this option. When you open an fm3 project with no History Log, Taseditor creates a new History automatically.

Piano Roll – save current position of vertical scrolling of the Piano Roll, in order to see the exact segment of the movie after loading the compact fm3 file. The file size will increase insignificantly, so you may keep that option checked.

Selection – save all Selection data to the file. Both current Selection and whole Selection History is saved. The file size will increase insignificantly, but usually there's no need to publish the data. So it's recommended to uncheck this option.

Greenzone saving options – here you can choose how the Greenzone should be saved. Greenzone is the main factor causing huge project file size. So it's recommended to choose partial saving or not save the Greenzone at all.

  • all frames – save entire Greenzone. The file size will increase dramatically!
  • every 16th frame – save only every 16th frame. The file size will increase dramatically.
  • marked frames – save only marked frames. The file size will increase depending on the number of Markers in your project.
  • don't save – the Greenzone will not be saved. If during the compact saving the Playback cursor is at the very first frame of the movie, there will be no single Greenzone savestate in the fm3 project. But if the cursor was left at some frame in the middle of the movie, the compact fm3 will contain one Greenzone savestate, allowing to restore the emulator state on the Playback cursor frame when you open the project. Since one savestate uses very little disk space, the file is still compact.

Using compact saving you can get an fm3 project being less than 500KB in size, while still sharing all essential data the recipient may need. For example, if you are working in co-authorship with another TASer(s), you will need to share not only Input, but also Markers and Bookmarks. As for the Greenzone, the recipient can recreate it by replaying the project movie in Taseditor.

On compact saving, your project name receives the "-compact" suffix. Compact saving doesn't replace normal project saving, so if you have any unsaved changes in the project, the asterisk in the window caption will not disappear after Save Compact.

Besides saving a compact fm3 you can also export movie data to fm2 format, accepted at TASVideos before Taseditor even existed. But in such files you will share only Input. To do that, choose File -> Export to FM2 in Taseditor's main menu. The "Export to FM2" window will appear, prompting you to choose target movie type (1P, 2P, Fourscore).

Since FM2 format also supports text subtitles, you can use existing Marker Notes as a source for generating movie subtitles. For that, enable the "Convert Marker Notes to Movie Subtitles" checkbox. Then while watching the fm2 file the viewers will see text messages appearing when passing certain frames (the frames where your project had Markers at). If necessary, you can then convert those fm2 subtitles into the commonly used .srt format to post the TAS on Youtube. To do that, right-click the FCEUX window while replaying the subtitled movie and choose "Dump Subtitles to SRT file" command.

FM2 files can be opened in Taseditor similarly to loading fm3 projects. In the "Open TAS Editor Project" window (File -> Open) switch to the filter "All Files (*.*)" and then choose your fm2 movie file. Taseditor will bring the message box saying that this is not a project file, and will ask confirmation. After you click "Yes" it will create new project using Input and settings from the fm2 file.

Also, you can import Input from any fm2 or fm3 file using File -> Import Input. This time no new project will be created, but Input of current project will be replaced with Input from the file. This operation is very similar to pasting Input from the Clipboard, it is registered in History Log and can be undone by Ctrl + Z.

2. Patterns usage.

When editing Input, TASer actually creates a unique sequence of presses and releases for every button of joypad. But, despite the uniqueness, this large sequence still contains many typical segments, which are are short sequences of presses and releases that repeat many times in succession, or appear many times in different places of the movie.

To speed up the work, you can remember the most typical or frequent sequences as patterns, to be able to put them with a couple of clicks, not drawing every single buttonpress manually each time.

Patterns are useful in several cases:

  • when one sequence is frequently used in the movie (for example, an accurate alternation of pressing and releasing the B button)
  • when you need the same sequence for several buttons (for example, alternating L and R)
  • when a certain sequence needs to be drawn (or redrawn) many times (for example, making a running start by tapping R twice)

Some of the most obvious patterns are already added by author. To add your own pattern you need to edit the taseditor_patterns.txt file in any text editor (like Notepad), this file is stored in /tools subfolder of FCEUX main folder. Every second line in this file constitutes an encoded sequence of button states. The code is straightforward: "button pressed" is encoded by 1, "button released" – by 0.

Every pattern is looped, which means, when a long sequence of Input is created using a short pattern, the pattern is repeated the necessary amount of times to fill the whole given interval.

After adding or editing the patterns file, restart Taseditor to reread the file changes. The list of all available patterns is always in the upper right corner of the TAS Editor window. To change the current pattern, enter that menu and click the needed pattern name. For easy orientation in patterns it's recommended to call each pattern by a distinct name that reflects its in-game meaning.

To apply current pattern, Taseditor needs to know the beginning and the end of the interval where the chosen button is going to be pressed and released according to the rule. There are 3 different ways to apply a pattern:

Example 1. Point and click the start frame (click in any Piano Roll column except the icons column), thus selecting that frame. Then hold the Alt key and left-click the end frame in the column of the button you are editing. In the interval between those two frames you will get the needed sequence of the chosen button presses. This method is rather handy when the start frame is already selected by previous clicks in Piano Roll, and you only need to to hold down Alt and click the end frame.

Example 2. Left-click the start frame in the column of the button you are editing, and hold the mouse button to start drawing. Hold Alt and move the mouse cursor up or down. This way you will be drawing the pattern sequence of buttonpresses.

Example 3. Select a range of frames, then hold Alt and left-click on the edited button symbol in the Piano Roll Header. The pattern will be applied to the selected area.

When using traditional method of TASing you are also able to apply patterns to recorded sequences, although in a less convenient manner. To do that you should set the " Use pattern " checkbox on Recorder panel. Before that you may want to record the buttons you don't need to alternate (record them without using patterns), and then record the needed button(s) with pattern, using the "Superimpose" function for the segment.

For example, you need to record a burst of fire while jumping over the pit. At first, record that jump without shooting, then return the Playback cursor to the beginning of the segment (by jumping to the Bookmark left here), check "Superimpose" and "Use pattern", hold the B button and unpause the emulation. You'll see how the shooting Input superimposes over jump Input.

Before Taseditor there was the "Autofire" concept similar to patterns. But due to inconveniences of the Recording method that feature was rarely used, because when you are typing Input it's usually easier to press and release the needed buttons manually. So if you stick to traditional method of TASing, you won't likely use patterns. But in the non-linear or semi-automatic TASing, patterns are drawn as quickly as regular buttonpresses, so that's where they can really speed up the work.

Patterns are used when creating sequences for a single button. But when you want to use a typical macro involving several buttons, use Copy/Paste.

3. Effective usage of Markers.

Markers exist to simplify complicated situations by structurizing the problem. When the game requires you to perform (or think over) several complex actions, you should break the large segment into separate intervals, in order to understand clearly where one action stops and another one starts. Even if the initial subdividing appears to be wrong, it still helps you to get thoughts in order.

Obviously, you are not expected to set Markers on commonplace segments, most of which aren't even polished (e.g. where it's enough to hold R to win). But key moments and memorable situations of the movie should be marked and commented with Notes. It will help you to keep the whole picture of the project in mind and navigate the movie by text.

No need to write works of literature inside the Notes. You may just confine yourself with simple label words, numbers, tags. Invent the words on the fly, but try to keep systematic approach. As in, if at the beginning of the first level (on the transition screen) you've set a Marker with the Note "level 1 start", you should also write "level 2 start" at the beginning of the second level, and not "act II begin" or something. During the creation of TAS you naturally form a unique glossary in your mind using various terms that are topical for that specific game. And the more systematic approach you apply to writing the Notes, the easier it will be to describe another (similar) segment and understand its task. The easier it'll be to find similar Input segments, recalling only their vague in-game appearance.

The tasks you meet in video games are often repeatable. Details and environment may be different, but player actions remain more or less the same. In some cases you can just copy the Input (solution of the similar task) from the previous level, and it will successfully sync with the new in-game situation (probably after a little adjustment). Though, after the copy/paste it's recommended to diversify the Input to prevent the TAS viewers from noticing the repetition and getting bored.

For example, at the beginning of many levels in Super Mario Bros you need to use the same button sequence to accelerate to maximum speed optimally. Let's imagine, you are honestly commenting Input during TASing. Then in World 1-1 in the acceleration section you probably left a Note with words like "acceleration" or similar. Now, when you start creating Input for a segment with that task again, in a new level you put a Marker at the beginning of the segment and write a Note, describing your current task. Obviously enough, you are going to use the word "acceleration" there as well, because you need to accelerate.

And that's where you can use Taseditor's function of automatic searching for similar Notes. Leave the Playback cursor inside the current segment and press the "Similar" button at the bottom of the Toolbox. The Selection cursor will instantly jump to the Marker that contains the most resembling Note, in Taseditor's opinion. Most likely, it will be the Marker left at the beginning of the acceleration segment in the World 1-1. Therefore you can instantly select all Input in that segment by pressing Ctrl + A, then copy the Input to the Clipboard (Ctrl + C), return to the current segment (press Shift twice) and paste from the Clipboard (Ctrl + V).

If the first search result doesn't bring you to the intended segment, you can press the "More" button to try next result of the search. Usually the right segment is among the first offered finds, granted that you marked the segment with a sensible Note.

Interesting fact: while writing the Note for the second appearance of the acceleration segment, you use the word "acceleration" without an intent to correlate to previous cases, but only according to the in-game situation. So you are not expected to actually remember the text of old Notes. The right words will come to your mind in the right time.

This way, right during the TASing process you form a library of useful Input combinations, not unlike the pattern list described above, except that you don't have to purposely prepare the button sequences – they appear natural way during the segments shaping and optimization, and they are stored inside the movie, not in an external file. And when you improve a combination for some segment (e.g. find a faster way to accelerate), you can easily find and fix all related segments with similar button sequence. Also, here you don't have to remember the exact description or the name of the needed sequence, because, if you use systematic approach to describe tasks, the words will partially match (and a perfect match is not required, since the searching algorithm is rather smart).

The auto-search is also useful when you need to jump between two (or more) related segments, located far from each other in the movie. Scrolling the Piano Roll with the mouse wheel or jumping through dozens of Markers from one segment to another is not as handy as clicking the "Similar" or "More" button. To let the algorithm instantly find the twin segment (or the source segment and the destination segment), consider using some unique word in their Notes, one that isn't used in other places of the movie.

For example, in the "Megaman" game each robot master must be beaten twice (second time it's in the end of the game). It's logical to suppose that both battles will be entitled by Marker Notes containing the name of the robot and the word "boss" or "fight", or something like that. As a result, when the Playback cursor is in one of those 2 places, pressing the "Similar" button will get you to another one.

In this example the proper words for the Notes text are no-brainer, yet they are unique enough not to repeat in other places (at least not in that combination), so the auto-search will work perfectly. In a different case you may have to invent a unique label, but usually the first description you think of is enough.

You can also use standard search for Note text. For example, it's common to leave a Note beginning with the "TODO" word at some places where you are not sure the best solution is found (the segment Input is optimal). So, when you have mood to make fixes, you could skim through all Markers with that tag by bringing the "Find Note" window (Ctrl + F) and typing the word "TODO" to search for.

If you don't like all these big ideas with Markers, you can TAS without them. After all, many games provide rather simple tasks for a TASer, they don't require a highly organized approach to the solving process. If the problem can be solved on impulse, don't spend time on preparation and fortification. Markers provide advantages only in long-term goals.

So, just like in programming, in most cases you can successfully write the so-called "dirty code" (here it would be a project without Markers and Notes) that is fast to create, but hard to maintain and extend. Or you can make a lovingly formatted project which is nice to watch and modify. Since TASers have to modify their movies very often (in order to beat previous records), the today's time costs for the project formatting are likely to be repaid by the fact that the looks of the project motivate to continue the work on it.

4. Lua usage.

With the Lua language you can write scripts that can be executed by FCEUX along with game emulation. Writing scripts requires minimal programming skill, while the range of possibilities is pretty huge. You can create your own TAS tools, modify the game at the time of execution, have access to images and sound on the fly, send data via network or record it to disk, etc. And you can make custom extensions for TAS Editor.

To master the Lua language completely you would need to read its documentation and gain actual experience, but for making simple scripts it should be enough to read this Manual and the Lua chapter in FCEUX docs . At first, try to run scripts created for FCEUX by various people. They are stored in the /luaScripts subfolder. Each script is a text file with .lua extension, such file may be created and modified in any text editor. Before running scripts you need to open some game ROM in FCEUX. To run a script, open the Lua console (File -> Lua -> New Lua Script Window), in this window press the "Browse" button and load the script file, then press "Run". If emulator is paused, either unpause it or advance a frame to activate the script. As for the Lua console, the window may be hidden or minimized.

Program code in Lua scripts for FCEUX usually consists of 2 parts: the first part is executed once the script is activated, another part runs on certain emulation events, such as the end of a frame emulation, loading a savestate and so on.

The first part, which runs on script activation, is usually executed only once (unless you made an infinite loop in it). The code is executed line by line, from top to down. Usually the task of that part is to initialize global variables and register functions to be launched by FCEUX when certain events occur.

In most of cases the main code of the script is contained in the single function that is automatically executed at the end of every frame. For example, this is how Mario hitbox drawing code for SMB may look:

marioWidth = 16

marioHeight = 32

function everyframe()

marioX = memory.readbyte(0x3AD)

marioY = memory.readbyte(0xCE)

gui.drawbox(marioX, marioY, marioX + marioWidth, marioY + marioHeight)

end

emu.registerafter(everyframe)

When activating this script, FCEUX creates and initializes two variables ("marioWidth" and "marioHeight"), then registers the function called everyframe() to the "frame end" event (registerafter). After that the text ends and the script finishes its execution, but the registered function remains in emulator memory, and if you unpause it or press Frame Advance, after every frame it will run the code stored within the everyframe() function. That code consists of 3 lines. The first two create variables for the hitbox position and initialize them with current values from RAM of the emulated console. The third line draws graphics over the game picture output.

Actual RAM addresses can be found in public resources (like http://tasvideos.org/GameResources/NES/SuperMarioBros.html ) or found on your own using the Cheat Search tool or the RAM Search tool built in FCEUX. In this case we know that Mario's X position is stored in memory address 0x3AD, and his Y position is in 0xCE. So, the script just takes their current values and draws the rectangle in the corresponding screen position. Sometimes there's need to recalculate the values to translate the in-game world coordinates into on-screen coordinates, but in this case they match.

The standard functions readbyte(), drawbox() and other useful functions are described in the FCEUX documentation . It also describes how to use mathematical expressions and make loops and conditions.

The standard functions available only when Taseditor is engaged are listed in the Reference . Using all this knowledge you can not only draw and write messages over the emulator screen, but also control Playback and Selection, and most importantly, modify the movie Input and Markers.

For example, this code copies one joypad Input to the second one's place:

function doCopy()

selection_table = taseditor.getselection()

if (selection_table ~= nil) then

for i = 1, #selection_table do

selected_frame = selection_table[i]

joypad1data = taseditor.getinput(selected_frame, 1)

taseditor.submitinputchange(selected_frame, 2, joypad1data)

end

taseditor.applyinputchanges("Copy 1P->2P")

end

end

taseditor.registermanual(doCopy, "Copy 1P to 2P")

When launching this script, FCEUX registers the doCopy() function to the event of pressing the "Run function" button (registermanual). Now any click on the button will run the code of that function, consisting of 9 lines. At first, the function gets information about Selection from Taseditor, and if it's not blank (i.e. at least one frame is selected in the Piano Roll) it runs the FOR loop, going through all the selected frames from the first to the last. For each selected frame the function requests the Input of the first player from Taseditor (and stores this data to the "joypad1data" variable), then it submits the claim to change the second player Input for that frame. All these submissions are accumulated in Taseditor memory until the FOR loop ends, after that they all are applied by calling the applyinputchanges(). As a result, the second joypad in the selected range of frames contains the same Input as the first joypad.

This simple script is already a useful mini-tool that may be needed when making a TAS for 2 or more players. Launch it, and while TASing you will be able to select a range of frames in the Piano Roll and click the "Copy 1P to 2P" button (or press the "Run Manual Lua function" hotkey) to synchronize both players. Every time the script work results in an Input change, the Greenzone is automatically truncated, and a new item is added to the History Log, allowing you to undo the changes done by the script. This way you've got a feature completely integrated into Taseditor, and you've programmed the behavior of the feature yourself.

Even though you can successfully TAS without Lua knowledge, its support can save you much time and even hint on a less obvious solutions during the Input optimization (or more exactly, during the game Output analysis).

Videogames often hide important details of the situation, and TASer has to watch memory state directly in order to know for sure what's going on and to precisely perceive the optimality factors while polishing segments.

For example, many games don't show boss HP on screen. So, to know exactly the damage you inflict, you need to watch the numeric value of the corresponding RAM address in the Memory Watch window. And when there is a plenty of hidden factors (for example, several timers of invulnerability and boss attack, and some special counters of the player character), TASer needs to watch and analyze many memory addresses as they change according to different rules. In this case an on-screen visualization of some data would be huge helper. For example, boss HP can be displayed as a bar or a number above his head, and a red color can indicate the damage frames or other events. As a result, your mind is relieved by moving from deciphering an abstract data format to the format that instantly delivers the main idea (e.g. "the boss was damaged", "good/bad").

So it's recommended to learn Lua at least to the level of being able to sensibly modify others' scripts. For the long time FCEUX existed, people wrote and published a lot of scripts serving for various purposes, and you'll probably only need to change some RAM addresses to adjust a script to your game. Oftentimes it also makes sense to ask for help at TASVideos forums .

The Taseditor guide is over. If you were reading carefully, you should now know everything necessary to make a TAS up to the high standards of TASVideos. The only thing left is to gain an experience in real work, master some actions to automatism in order to feel no trace of routine and have fun from the process of armed playthrough and investigation of games.

Created with the Personal Edition of HelpNDoc: Single source CHM, PDF, DOC and HTML Help creation


Reference

Reference

Glossary

Terms that are used throughout this documentation

Controls

Exhaustive review of controls

Navigation

The summary of all ways to navigate a movie

Operations

The list and mini-reviews of all possible operations with a movie

Lua API

Specifications of "taseditor" library of Lua functions

FAQ

Answers to some expected questions

Speedrunning synopsis

Abstract classification of typical issues arising when optimizing a segment for fastest time

Created with the Personal Edition of HelpNDoc: Write eBooks for the Kindle


Glossary

Reference ››

Glossary

Here you can find definitions for many terms that are used throughout this Manual. Most of them were used in the context of TASing before TAS Editor was created. Some of those terms are described more thoroughly in the Beginner's Guide .

It's recommended to read the Glossary at once, because many terms are interconnected.

Input

Data about player's actions, that can be received by a game.

TASing became feasible because of general assumption that behavior of a game is always determined by its initial state and player's input, and nothing else (see Determinism).

Examples of Input: pressing a button on a gamepad, pushing analog stick, touching by stylus, shouting into a microphone, etc.

Taseditor works with Input in the form of "sequence of buttons states".

Note: the fact of player not pressing any button is also considered an Input.

Output

Data sent from a game as a result of processing player's Input.

The process of playing a game can be depicted as a loop of interaction between a subject (player) and an object (game).

Examples of Output: displaying an image, producing a sound, vibrating gamepad, changing the value of an observed RAM address, providing an information about lag, etc.

Playthrough / Walkthrough (Solution)

A sequence of player's actions needed for successful completion of the game.

This sequence is inputted into the game using an input device (e.g. gamepad). The sequence can be either performed live (created in real-time) or constructed in advance in a form of reproducible recording (e.g. log of button presses). The latter form allows editing of the sequence.

Speedrun

A walkthrough aimed on fastest completion of the game.

Some games have build-in "Speedrun" or "Time Attack" mode, where the game counts the time spent while playing. For other games it's possible to use external timer, measuring time in seconds or TV frames.

TAS (Tool-Assisted Superplay / Tool-Assisted Speedrun)

A walkthrough made with use of tools for editing the sequence of player's actions.

The process of creating TASes is called "TASing", authors are usually called "TASers".

The Input editing exempts TASers from certain human limitations (e.g. slow reflexes), allowing to spend full energy on making extraordinary walkthroughs. It can be either speedruns or entertainment videos (playarounds).

TASes can be distributed:

  • in the form of finished videos containing Output (youtube, AVI files and so on) – easy to watch
  • in the form of source files containing Input (FM2 movies and so on) – easy to edit

Movie (replay)

Container for storing Input and associated data.

Unlike video containers, the TAS movies don't contain Output (game footage). The Output appears only when user applies the movie Input to an appropriate game file.

Lag

The term used when the delay between Input and Output is greater than normally.

The loop of interaction between player and game usually establishes some fixed amount of time between polling Input and updating Output, for example 60 times per second.

A computer processor can only make fixed amount of operations in this fixed amount of time. But videogames try to mimic the unboundedness of real life, so the quantity of in-game objects may vary greatly. Thus it's possible that processing all objects will take more time than allotted. In such cases the Output update will be delayed, and next Input polling will be delayed too.

Speedrunners try to avoid excessive delays, and the lag is often considered as a factor when TASing. Usually TASers try to minimize the number of "frames containing lag".

Emulators can detect lag in a frame right after finishing the frame emulation. The criterion is simple: if the game didn't poll Input during the frame then it's the lag frame. If it did poll Input then this is normal frame. Taseditor highlights lag frames with red color, and it's useless to draw any Input on these frames.

Desync

Discrepancy between expected and received Output, which results in player's Input not syncing with the logic of the game.

Desync may appear when the Input made for one game is applied to another game, or using different emulator version or different settings. Also, desyncs appear when emulator doesn't support deterministic emulation.

Segment

A part of the movie, representing the period of time between two in-game events.

Breaking the movie into segments is used to decompose big tasks to smaller subtasks.

The size of a segment can be measured in frames, but the limits of a segment are usually defined by in-game events. The beginning event cuts all previous tasks and concentrates TASer's attention on the nearest set of conditions. The ending event serves as an optimality criterion for all possible approaches to the current task solution.

More: TASing Process

Optimization

The process of searching for the optimal (the best) solution of the task in current segment.

Almost any task in videogames can be solved in a variety of ways. Every way has its own pros and cons. When starting a project, TASer chooses his goal (e.g. pacifist speedrun), thus assigning priorities to those pros and cons, therefore all the ways of solving a task can be evaluated and compared to each other to determine which one is better.

Actual process of TAS optimization consists of editing Input and evaluating resulting Output. When TASer gets better result, he marks current Input as the best, until he finds an even more optimal Input. The final product (TAS movie) contains the best solution for every subtask.

More: TASing Methodology

Improvement

A way to solve the task better (closer to optimum).

Examples of improvements in speedruns: removing inaccuracy, applying unused timesaver, increasing the usefulness of an old timesaver, adding entertainment without losing speed.

Timesaver

Any in-game trick that can save time.

When making a speedrun, TASer is supposed to use every unprohibited opportunity to make the walkthrough become as fast as possible. One thing is polishing the Input to find the best outcome from current knowledge about the game. Another important activity is expanding this knowledge base – finding and applying tricks. True TASer strives to gather the maximum information about the game and use all known tricks to full extent, so that his record wouldn't be easily beaten.

Examples of timesavers: features of the game, bugs of the game, luck manipulation.

Note: sometimes TASers deliberately refuse certain timesavers, in this case the TAS aims for extra category. Examples: Super Mario Bros TAS without using B button (denying certain feature of the game), Sonic the Hedgehog TAS without zipping (denying certain bug of the game).

Feature

An intended aspect of the game.

Some features are unimportant (or even unnoticeable) for an ordinary player, but substantial for a TASer. So, before optimizing Input it's recommended to research the game engine.

Examples of such features: damage boost, forced waiting for score countdown, coordinate subpixels, AI peculiarities, etc...

Bug / Glitch

An unintended aspect of the game.

Bugs abused by TASer should be reproducible on real console (at least theoretically). Bugs caused by emulation are not permitted.

Many bugs are discovered during real-time play. Some of them require thorough research and disassembly of the game code.

Examples of bugs: simplistic collision detection system, not checking save data corruption, race conditions, mistake in the order of checks, etc...

Luck Manipulation

Unrestricted exploiting of certain game features, which are normally limited by the shortage of player's knowledge.

Although any experiments with Input modification are manipulations of game features, but some aspects of games appear especially unpredictable for an ordinary player. Developers intentionally entangle algorithms of those features, so that for a naked eye they seem completely random and uncontrollable.

However, in deterministic world all aspects of videogames are predictable (defined by Input). Using tools and careful analysis you can reveal those hidden laws and dependencies, and then use the knowledge when creating the Input. And sometimes you don't even have to dissect algorithms, when you can use trial-and-error method.

More: Nonlinear TASing (example of luck manipulation)

Subpixels

The term used when in-game objects have coordinates with fractional parts.

Generally, there's difference between on-screen coordinates of a sprite and in-game coordinates of the object this sprite represents. In some games those coordinates have the same scale and their values coincide, but usually on-screen images represent a rough outline of the real state of things. So, to get max precision TASers observe the memory of emulated console, using Memory Watch tool or custom Lua HUD. This way also allows to see hidden variables of the game, those that aren't displayed on screen normally.

Recording

One of possible ways to create Input for a movie.

It consists of appending new Input sequentially to the end of current movie, while watching interim results of the Input.

Another way would be drawing Input directly in the movie.

More: Toolbox , TASing Methodology , Traditional TASing

Rerecording

One of possible ways to edit Input in a movie.

It consists of rewriting old Input sequentially from starting frame to ending frame, while watching interim results of the Input changes.

Another way would be direct modification of existing Input in the movie.

More: TASing Methodology , Traditional TASing , Rerecords counter

Multitracking (multi-track recording)

One of ways to record Input for a walkthrough of the game in multi-player mode.

It consists of recording Input for a segment of the movie by taking turns for every player separately.

Another way would be recording Input for all players simultaneously.

More: Toolbox

Frame Advance

Step-by-step emulation of a game using the minimum units of measuring time – frames.

Used for manual control of progression of time. Considered to be more effective replacement to "slow motion".

Turbo (turbo speed)

The feature of speeding up emulation to the maximum possible speed.

Used for skipping meaningless in-game events and reducing waiting time when the emulator is seeking.

Most emulators allow to customize emulation speed, slowing it down or speeding up when needed. Turbo speed means the fastest speed possible, which is only limited by your computer speed.

More: Toolbox , Nonlinear TASing , Semiautomatic TASing

Savestate

A snapshot of the emulated system's state at that current moment.

Unlike in-game saves, a savestate contains all the comprehensive data on the state of emulated hardware.

Piano Roll

A medium for visual representation of data, similar to table or grid view.

The interface is used in many music editing programs (MIDI sequencers and MOD trackers). Its name and basic concept was derived from existing storage medium used to operate a mechanic piano (paper rolls).

Taseditor's Piano Roll displays current movie data (Input and Markers) and allows to edit the data by mouse clicks. It also displays auxiliary information like pointers, Bookmarks, Lag log, etc.

Every row of the Piano Roll corresponds to one frame of the movie.

More: Piano Roll , Piano Roll specs

Playback cursor

Pointer to currently played frame of the movie.

Events of this frame are displayed in emulator's main window as current screenshot. Piano Roll marks respective row with light-blue color and the "Play" symbol (light-blue arrow).

Only one frame of the movie can be seen at any given moment. To see the screenshot of upcoming events you'll have to move the Playback cursor forward (down in the Piano Roll). To see the screenshot of previous events you'll have to move the Playback cursor backward (up in the Piano Roll).

More: Piano Roll , Playback cursor Navigation

Greenzone (access zone)

The storage designed for speeding up Playback cursor navigation.

This storage automatically collects savestates for all emulated frames of the movie, and when it's necessary to rewind or jump forward to a frame, Taseditor loads respective savestate from Greenzone.

More: Toolbox , Program Customization , Greenzone specs

Selection

Set of rows in the Piano Roll that are highlighted by special color (usually dark-blue).

Any row of the Piano Roll (and thus any frame of the movie) can be either selected or not selected.

Selection allows to operate with many frames at once, for example, delete a whole section of the movie at once instead of deleting every single frame in it.

The upper row of the Selection is called "Selection cursor".

The Selection cursor automatically follows the process of Input editing.

More: Piano Roll , Selection cursor Navigation

Marker

Yellow mark for a row in Piano Roll that emphasizes the frame among its neighbors.

Any row in the Piano Roll can be marked. Markers allow to improve the distinctness of movie data.

Markers can be used to:

  • organize the Input
  • formalize knowledge (using text Notes)
  • speed up navigation
  • speed up selection of segments (Ctrl + A)

More: Piano Roll , Markers specs

Note

A single line of text accompanying every Marker.

More: Piano Roll , Controls , Advanced Features

Bookmark

A numbered mark for a frame of the movie.

Taseditor has 10 slots for Bookmarks.

A Bookmark stores all necessary data about the frame it was placed on. Including the movie branch that contains an Input that definitely leads the game to the events of this frame.

Bookmarks can be used for Playback cursor navigation, but their main purpose is to store branches.

More: Toolbox , Bookmarks specs

Branch

A full copy of the movie, storing its state at the moment of creating the Bookmark.

The current movie can be replaced by the branch when necessary, thus restoring saved state of the movie.

With branches you can have many different movies in one project, and you can instantly switch among them:

  • to compare alternative strategies of walkthrough
  • to store current best approach when testing different solutions in a segment
  • to store examples of unused tricks that could be useful in future
  • to compare your own movie with somebody else's movie (e.g. when making an improvement)

More: Toolbox , Program Customization , Branches specs

Project

Container for storing working data in Taseditor.

More: Advanced Features

Lua

Programming language used in many TAS-friendly emulators.

Useful for making custom tools and for data visualization.

More: Advanced Features , Lua, Lua API

Bot (robot)

A program made for automation of a specific task.

Bots are created to free humans from tedious work that doesn't require high intelligence. Unlike humans, bots don't invent the solution, they just methodically test all possible approaches within given limits, following an algorithm made by the programmer.

Nowadays bots are only practical for running exhaustive search within a very small segment of the movie. Most of time it's faster to search for best solution manually, using human intuition to eliminate dead ends without unnecessary tests.

Making bots requires programming skills. TASing bots are either written in Lua or built-in into emulators by modifying an open source code.

Pattern

A predefined sequence of Input values for a button.

More: Advanced Features , Patterns specs

Created with the Personal Edition of HelpNDoc: Free EBook and documentation generator


Controls

Reference ››

Controls

Taseditor is controlled by mouse and keyboard .

Every operation can be done in several alternative ways (via menu, hotkey or GUI element).

Any action can be done using mouse, but some are faster to do with keyboard. The Manual assumes that one hand of user is holding the mouse and other hand is placed on a side of the keyboard, occasionally holding Shift/Ctrl/Alt or pressing a key combination.

Some actions (e.g. switching the "Follow cursor") can be done by mouse only.

Mouse controls

  • pointing with mouse
  • left mouse button
  • right mouse button
  • middle mouse button
  • mouse wheel

Pointing with mouse

A. Displaying Bookmarks screenshots and descriptions

Hover mouse cursor over the right half of Bookmarks List to see the game screenshot of the bookmarked frame in the movie branch you're pointing at. Optionally there can be a description of the branch under the screenshot.

B. Displaying information of the Bookmark

Hover mouse cursor over an icon of any Bookmark in the Branches Tree to see the information about the Bookmark (real time of creation, bookmarked frame, full timeline, screenshot and description). When you point at a Bookmark that doesn't belong to the timeline of current movie branch, the mouse cursor changes to "arrow with question mark".

C. Illuminating button symbols in the Piano Roll Header

Hover mouse cursor over a button symbol in the Piano Roll Header to see if you can change the movie by clicking this symbol. When some rows of Piano Roll are selected, symbols in the Header will illuminate on mouse hover.

Left mouse button

The main button.

A. Standard Windows actions

Most of GUI elements of TAS Editor window are controlled the same way as in other Windows applications.

  • press a button by left-click (also works with the progressbar, "Bookmarks/Branches" caption and "Marker #" labels) – fires on button press
  • check/uncheck checkboxes and radiobuttons – fires on button release
  • open the window menu, choose menu item, set/remove ticks from menu items
  • scroll Piano Roll or History Log using scrollbars
  • move or resize TAS Editor window

B. Moving the Playback cursor

Click on any row in the "Icons" column of the Piano Roll to send the Playback cursor to the frame pointed. If you hold the left mouse button, you can drag the Playback cursor up and down. This way you can also move the Playback cursor to frames outside the currently visible area of the movie – drag the cursor below or above the Piano Roll, the farther you lead the mouse, the faster will be scrolling and Playback rewinding.

C. Selecting rows in the Piano Roll

Click on a frame number in the "Frame#" column of the Piano Roll to select this frame and remove selection from other frames (if there was any selection before). If you hold the left mouse button, you can stretch the selection by moving mouse up or down.

If you need to append new selection to the already existing selection, hold Ctrl while clicking on a frame number. This way you can select several non-overlapping segments. Also this way you can remove some parts of existing Selection, by holding Ctrl while clicking on a selected frame.

If you hold Shift instead of Ctrl, the click will select a region of frames starting from the beginning of previous Selection.

If you hold Alt, the click will select rows using current Pattern.

D. Setting/unsetting Input in the Piano Roll

Point mouse cursor at needed cell of Input (find crossing point of the needed frame row and the needed button column) and press left mouse button. The Input in this cell changes at the moment you press the button. Empty cell will become occupied and vice versa.

The row containing this cell will also become selected, and other rows of the Piano Roll will become unselected. This feature ensures that Selection cursor always appears in the context of Input editing.

If you hold the left mouse button, you can draw or erase Input in other cells of the Piano Roll by moving mouse cursor over them. Drawing starts when you click on an empty cell, erasing starts by clicking on an occupied cell.

If you hold Shift while clicking on a cell, the Input change will apply to all frames from the Selection cursor to the row containing the cell.

If you hold Alt instead of Shift. the click will set Input (from the Selection cursor to the row containing the cell) using current Pattern.

E. Setting/unsetting Input using the Header of the Piano Roll

Click on a button symbol in the Piano Roll Header to change Input of this button in selected frames. If no frames are selected, nothing will happen. If in some of the selected frames the button in not set, your click will set the button in all selected frames, otherwise the click will unset the button in all selected frames.

If you hold Alt while clicking on a button symbol, the click will set the button in selected frames using current Pattern.

If you click on the "Frame#" label, the click will apply to Markers instead of Input.

F. Creating and moving Markers

Double-click on a frame number in the Piano Roll to set a Marker to this frame. If you hold the left mouse button, you can drag the Marker freely. Release the button to leave the Marker at the frame number it was held over. This way you can move Markers from place to place. If you release the Marker over Input columns, the dragging will be cancelled, and the Marker will return to the frame it was picked from. If you release the Marker over another Marker, those two Markers will switch places.

If you release the Marker outside the Piano Roll, this Marker will be dumped. Thus, to remove a Marker, double-click on it and drag it somewhere outside TAS Editor window.

G. Entering/exiting Note editing mode

Click on the upper or the lower edit field to start editing Note text displayed in this field at the moment.

To finish editing (and save changes) click on anything outside the edit field.

H. Controlling the Bookmarks List

Click on a frame number in the Bookmarks List (on the left side of the list) to send the Playback cursor to the bookmarked frame.

Click on a timestamp in the Bookmarks List (on the right side of the list) to restore movie state saved into the Bookmark and send the Playback cursor to the bookmarked frame.

Those operations fire on the button release.

I. Controlling the Branches Tree

Click on icon of a Bookmark to send the Playback cursor to the bookmarked frame.

Double-click on icon of a Bookmark to restore movie state saved into the Bookmark and send the Playback cursor to the bookmarked frame.

Those operations fire on the button press.

J. Controlling the History Log

Click on any row of the History Log to restore movie state to the point of time registered in the Log record.

Right mouse button

Auxiliary button.

A. Moving the Playback cursor with mouse wheel

Hold the right button and roll the mouse wheel up or down to move the Playback cursor respectively.

The mouse cursor can be anywhere over the TAS Editor window or emulator main window.

B. Scrolling the Piano Roll

Place mouse cursor over the Piano Roll, hold right button and move mouse cursor anywhere outside the Piano Roll to scroll visible area to that side. This is especially useful for horizontal scrolling, because using scrollbar would be too slow.

C. Setting a Bookmark

Right-click on a row of the Bookmarks List to set the Bookmark to the frame where the Playback cursor currently is.

Alternatively, right-click on icon of a Bookmark in the Branches Tree to set the Bookmark to the frame where the Playback cursor currently is.

Those operations fire on the button release.

D. Context menu

Right-click on a frame number of any selected frame in the Piano Roll to bring the context menu containing the following items:

  • Set Markers
  • Remove Markers
  • Deselect
  • Select between Markers
  • Ungreenzone
  • Clear
  • Delete
  • Insert
  • Insert # of Frames
  • Clone
  • Truncate movie

Scrollbars and Note editing fields also have their own context menus.

Middle mouse button

The middle mouse button serves one major role – to pause and unpause emulator, no matter where mouse cursor is The button fires on button press.

When the emulator is paused, pressing the middle mouse button will unpause it (same was as pressing Pause hotkey). Moreover, if there is the green arrow outside the Greenzone in the Piano Roll, the middle-click will launch seeking to the frame of the green arrow (same way as pressing Restore Playback hotkey).

If you hold Shift while mid-clicking, this will launch seeking to the nearest Marker.

If you hold Ctrl while mid-clicking, this will either launch seeking to the Selection cursor (if it's below the Playback cursor) or re-watch the movie segment starting from the Selection cursor (if it's above the Playback cursor).

When the emulator is unpaused, pressing the middle mouse button will pause it (same way as pressing Pause hotkey).

Usually the middle mouse button is the mouse wheel.

Mouse wheel

The wheel can be rolled up and down with different speed. When you need precision, roll the wheel slowly. When you need speed, roll the wheel quickly.

A. Scrolling the Piano Roll or the History Log

When mouse cursor is over the History Log, roll the mouse wheel to scroll visible area of the History Log.

When mouse cursor is anywhere else, roll the mouse wheel to scroll visible area of the Piano Roll.

B. Moving the Playback cursor

Hold right mouse button and roll the mouse wheel up or down to move the Playback cursor respectively.

If you want to always see the Playback cursor position in the Piano Roll, check the "Follow cursor" checkbox in the Playback section of TAS Editor window.

C. Jumping on Markers

This is similar to pressing << and >> buttons or using Ctrl/Shift + Page Up/Page Down hotkeys.

Hold Shift and roll the wheel to make jumps with the Playback cursor. The Piano Roll will follow it if the "Follow cursor" checkbox is checked.

Hold Ctrl and roll the wheel to make jumps with the Selection cursor. The Piano Roll will follow it automatically.

D. Crossing gaps

Point mouse cursor to any member of a long column of buttonpresses or to an empty cell among other empty cells in its neighborhood, then hold the Alt key and roll the wheel up or down to scroll the Piano Roll in such a manner that mouse cursor immediately points at the upper end or the lower end of the column / emptiness.

This allows you to quickly navigate among long sequences of Input.

The same approach can be used to find previous/next Markers (when mouse cursor is over the column with frame numbers) and Bookmarks (when it's over the icons column).

Keyboard controls

  • modifiers (Shift, Ctrl, Alt)
  • accelerator hotkeys
  • FCEUX hotkeys
  • virtual gamepad

Modifiers (Shift, Ctrl, Alt)

When you hold one of these keys, the functions of left mouse button and mouse wheel are modified.

  • Shift is responsible for the Playback cursor navigation and for selecting whole region of frames.
  • Ctrl is responsible for the Selection cursor navigation and for appending frames to current Selection.
  • Alt is responsible for Patterns and for crossing gaps using mouse wheel.

If you tap the Shift key twice in a row, the Piano Roll will automatically scroll to the Playback cursor.

If you tap the Ctrl key twice in a row, the Piano Roll will automatically scroll to the Selection cursor.

When you're drawing/erasing Input, hold Shift key to remove the "single-column" confinement.

Accelerator hotkeys

These are key combinations typical for many Windows applications. You cannot redefine those combinations. In this documentation they are highlighted with red color.

Ctrl + S = save project to disk

Ctrl + Z = undo (step back in History Log)

Ctrl + Y = redo (step forward in History Log)

Ctrl + Q = restore previous Selection (Selection undo)

Ctrl + W = restore next Selection (Selection redo)

Ctrl + A = select all frames between two Markers surrounding the Selection cursor

Ctrl + B = reselect frames that contain Input that was copied to the Clipboard

Ctrl + C = copy selected Input to the Clipboard (Copy)

Ctrl + X = copy selected Input to the Clipboard and then clear selected frames (Cut)

Ctrl + V = paste Input from the Clipboard to Selection cursor (Paste)

Ctrl + Shift + V = insert Input from the Clipboard to the Selection cursor (PasteInsert)

Delete = clear selected frames

Ctrl + Delete = remove selected frames from the movie

Insert = insert given number of blank frames before the Selection cursor

Ctrl + Insert = clone selected frames

Ctrl + Shift + Insert = insert blank frames before selected frames

Ctrl + F = bring the "Find Note" dialog

Ctrl + PageUp / Ctrl + PageDown = jump on Markers with the Selection cursor

Ctrl + Home / Ctrl + End = move current Selection to the beginning / to the end of the movie

Ctrl + Up / Ctrl + Down = transpose current Selection 1 frame up / down

Ctrl + Right / Ctrl + Left = scroll the Piano Roll right / left

Shift + PageUp / Shift + PageDown = jump on Markers with the Playback cursor

Shift + Home / Shift + End = send the Playback cursor to the beginning / to the end of the movie

Shift + Up / Shift + Down = move the Playback cursor 1 frame up / down

Shift + Right / Shift + Left = scroll the Piano Roll right / left

PageUp / PageDown = scroll the Piano Roll up / down

Home / End = scroll the Piano Roll to the beginning / to the end of the movie

FCEUX hotkeys

Emulator allows to map keyboard keys to different functions, see the Program Customization chapter. Keys that are already mapped by default are highlighted by light-blue color in this documentation.

Ctrl + F1 = reload last project

Pause = pause/unpause emulator

Esc = cancel seeking

Spacebar = restore Playback cursor position (launch seeking to the green arrow)

Ctrl + Spacebar = toggle "Auto-restore last position" checkbox

\ (backslash) = Frame Advance (emulate 1 frame)

Backspace = Frame Rewind (move Playback cursor 1 frame up)

Shift + R = play movie from the beginning

- (white "minus") = decrease emulation speed

= (white "plus") = increase emulation speed

Tab = Turbo speed (applies as long as the key is being held)

F1-F10 = load movie branch from the respective Bookmark slot (1-10)

1-0 = jump to the frame of the Bookmark (1-10)

Shift + F1-F10 = set Bookmark (1-10)

I = set currently selected Bookmark

P = load movie branch from currently selected Bookmark

M = show/hide rerecord counter

, (comma) = switch Input display

. (dot) = show/hide frame counter

/ (slash) = show/hide lag counter

Shift + L = reload current Lua script

Q = toggle Recording mode

W = switch current multitracking mode

Ctrl + R = invoke Reset command

Full list of FCEUX hotkeys that can be used when Taseditor is engaged:

  • Power
  • Reset
  • Pause
  • Frame Advance
  • Screenshot
  • Exit
  • Slowest Speed
  • Speed Down
  • Normal Speed
  • Speed Up
  • Turbo
  • Turbo Toggle
  • Savestate Slot 0
  • Savestate Slot 1
  • Savestate Slot 2
  • Savestate Slot 3
  • Savestate Slot 4
  • Savestate Slot 5
  • Savestate Slot 6
  • Savestate Slot 7
  • Savestate Slot 8
  • Savestate Slot 9
  • Next Savestate Slot
  • Previous Savestate Slot
  • Save State
  • Save State to Slot 0
  • Save State to Slot 1
  • Save State to Slot 2
  • Save State to Slot 3
  • Save State to Slot 4
  • Save State to Slot 5
  • Save State to Slot 6
  • Save State to Slot 7
  • Save State to Slot 8
  • Save State to Slot 9
  • Load State
  • Load State from Slot 0
  • Load State from Slot 1
  • Load State from Slot 2
  • Load State from Slot 3
  • Load State from Slot 4
  • Load State from Slot 5
  • Load State from Slot 6
  • Load State from Slot 7
  • Load State from Slot 8
  • Load State from Slot 9
  • Play Movie From Beginning
  • Toggle Read-Only
  • Toggle Frame Display
  • Toggle Input Display
  • Toggle Status Icon
  • Reload current Lua script
  • Sound Mute Toggle
  • Sound Volume Up
  • Sound Volume Down
  • Sound Volume Normal
  • Record AVI As...
  • Stop AVI
  • Eject or Insert FDS Disk
  • Switch FDS Disk Side
  • Insert Coin
  • Use Input Preset 1
  • Use Input Preset 2
  • Use Input Preset 3
  • Toggle Background Display
  • Toggle Object Display
  • Lag Counter Toggle
  • Open TAS Editor
  • Open Memory Watch
  • Open Cheats
  • Open Debugger
  • Open Hex Editor
  • Open PPU Viewer
  • Open Name Table Viewer
  • Open Trace Logger
  • Open Code/Data Logger
  • Frame Adv.-Skip Lag
  • Reload ROM or TAS Editor Project
  • Toggle Movie Subtitles
  • Open Ram Watch
  • Open Ram Search
  • Toggle Rerecord Display
  • Frame Rewind
  • Restore Playback
  • Cancel Seeking
  • Switch Auto-restore last position
  • Switch current Multitracking mode
  • Run Manual Lua function
  • Toggle FPS Display

Other FCEUX hotkeys will not work when Taseditor is running, for more details see Mistake-proofing .

Virtual gamepad

Emulator also allows to map keyboard keys to buttons of emulated console. You can use these keys for Input Recording and for Changing Input in Selection chapter.

By default, the following keys are mapped to the Player 1 buttons:

D – B

F – A

Enter – Start

S – Select

Keypad up – Up

Keypad left – Left

Keypad down – Down

Keypad right – Right

When you need to input hardware commands, use FCEUX menu or hotkeys:

  • NES -> Reset or "Reset" hotkey (Ctrl + R by default) – to invoke the "Reset" command
  • NES -> Power or "Power" hotkey – to invoke the "Power switch" command (not used in practical TASing)
  • NES -> Eject/Insert Disk or "Eject or Insert FDS Disk" hotkey – to invoke the disk command (only useful for a Famicom Disk System game)
  • NES -> Switch Disk Side or "Switch FDS Disk Side" hotkey – to invoke the disk command (only useful for a Famicom Disk System game)
  • NES -> Insert Coin or "Insert Coin" hotkey – to invoke the arcade machine command (only useful for a VS System game)

These commands work only when Recording mode is on. After invoking a command you need to advance at least 1 frame to actually activate the command and insert it into the movie.

Since in TAS Editor 1.0 the Piano Roll doesn't have columns for displaying hardware commands (they are rarely used), it's recommended to set Markers to frames where a command was inserted.

Controls in Note editing mode

When you enter Note editing mode, the keyboard is used for typing the text.

1. Accelerator hotkeys do not work.

Ctrl + A – select all text of the Note

Ctrl + Z – undo/redo the last change in the text

Ctrl + X, Ctrl + C, Ctrl + V – text copy/cut/paste

2. FCEUX hotkeys do not work.

Backspace – delete previous symbol

Esc – exit Note editing mode without saving any changes

Tab – toggle between upper and lower Note editing field

3. Virtual gamepad keys do not work. Note: they will work if you check the Config -> Enable -> Background Input in FCEUX menu, so it's not recommended to enable the feature.

4. Mouse controls are the same as usual. Any click outside the text edit field (except for mid-clicks) will exit Note editing mode and save text changes. Also, if the Playback cursor or the Selection cursor move away from the Marker while you're editing its Note, the text changes will be saved and you'll begin editing another Marker's Note. So it's recommended to only edit Notes when the emulator is paused.

Created with the Personal Edition of HelpNDoc: Full-featured Kindle eBooks generator


Navigation

Reference ››

Navigation

Emulator's main window can only display data of a single frame of the movie at any given moment.

The Piano Roll can cover data for tens of frames at the same time.

But an average movie has tens of thousands of frames. So TASer must often scroll the Piano Roll up and down to see the data about needed segment, and rewind emulator playback to see the data about needed frame.

Throughout the documentation this behavior is called "movie navigation". It takes major part of TASing, and Taseditor introduces many new ways of navigation, striving to make it as fast as possible. Depending on the situation some of them are better then others, so it's not recommended to stick to a single method.

Ideally, the navigation skills should move to your muscle memory, allowing you to always appear at the necessary place of the movie without interrupting the mental analysis of the current task.

All ways of navigating a movie:

  • Scrolling the Piano Roll
  1. Using vertical scrollbar
  2. Rolling mouse wheel
  3. Crossing gaps
  4. Paging through
  5. Jumping to the beginning / to the end of the movie
  6. Jumping to the Playback cursor
  7. Jumping to the Selection cursor
  8. Jumping to the Marker above Playback cursor
  9. Jumping to the Marker above Selection cursor
  • Playback cursor navigation
  1. Frame-by-frame shift
  2. Rewinding by mouse wheel
  3. Dragging with mouse
  4. Jumping on Markers
  5. Jumping to Bookmarks
  6. Jumping to the beginning / to the end of the movie
  • Selection cursor navigation
  1. Frame-by-frame shift
  2. Moving Selection to the beginning / to the end of the movie
  3. Jumping on Markers
  4. Tracking the Selection History
  5. Returning to the origin of Clipboard data
  • Special
  1. Finding Markers with a given text
  2. Jumping to segment with similar description

Scrolling the Piano Roll

1. Using vertical scrollbar

Click on the scrollbar or drag its thumb to scroll the Piano Roll like any other list.

Playback cursor and Selection cursor positions are not affected by the Piano Roll scrolling.

When to use:

  • when you need to get to a far away section of the movie. The scrollbar allows to traverse thousands of frames at once
  • when you're searching for a segment which can be anywhere in the movie

2. Rolling mouse wheel

Roll mouse wheel up or down to scroll the Piano Roll like any other list.

The mouse cursor can be pointing anywhere, except History Log window.

When to use:

  • when you're observing a segment that doesn't fit into the Piano Roll visible area
  • when you're searching for a nearby segment

3. Crossing gaps

Point mouse cursor to any cell in Input/Markers/icons, hold Alt and roll the mouse wheel up or down to scroll the Piano Roll to the closest cell that contains a data different from the data of adjacent cell.

When to use:

  • when you see an emptiness in specific button column and you want to find the nearest frame where the button becomes pressed
  • when you see the specific button is held for many frames and you want to find exactly the first frame where the button was pressed, or the frame where it will be released
  • when you need to find previous/next Marker
  • when you need to find previous/next buttonpress
  • when you need to find the Bookmark above/below (in the icons column)

4. Paging through

Press Page Up or Page Down key to scroll the Piano Roll like any other list. The amount of scrolling depends on the size of the Piano Roll visible area.

When to use:

  • when you're searching for a segment which is likely somewhere nearby

5. Jumping to the beginning / to the end of the movie

Press Home or End to scroll Piano Roll to the beginning or to the end of the movie.

When to use:

  • when you need to observe the beginning or the end of the movie

6. Jumping to the Playback cursor

Click on the upper "Marker #" label (colored light-blue) to immediately scroll the Piano Roll to the Playback cursor position. Alternative way to do it is to press Shift key twice within a short amount of time.

When to use:

  • when you need to see the context of currently played frame of the movie
  • when you wish to return to the currently played segment from any other place

7. Jumping to the Selection cursor

Click on the lower "Marker #" label to immediately scroll the Piano Roll to the Selection cursor position. Alternative way to do it is to press Ctrl key twice within a short amount of time.

When to use:

  • when you wish to return to the currently edited segment from any other place

8. Jumping to the Marker above Playback cursor

Click on the upper edit field to immediately scroll the Piano Roll to the Marker which Note is going to be edited.

Works only when the View -> Follow Marker Note context option is enabled.

When to use:

  • when you need to see the beginning of the currently played segment

9. Jumping to the Marker above Selection cursor

Click on the lower edit field to immediately scroll the Piano Roll to the Marker which Note is going to be edited.

Works only when the View -> Follow Marker Note context option is enabled.

When to use:

  • when you need to see the beginning of the currently edited segment

Playback cursor navigation

The Playback cursor is always bound to current state of emulated game. This means that emulator affects this cursor when emulating the game, and vice versa, when you move this cursor, you affect the emulator.

There's one limitation in the controlling of the cursor: sometimes it can't immediately move to the desired frame, seeking takes some time.

When the "Follow cursor" checkbox in the Playback panel is checked, the Piano Roll automatically scrolls after the Playback cursor (except when seeking).

1. Frame-by-frame shift

Click on < or > button in the Playback panel, or press Shift + Up or Shift + Down, or use Frame Rewind or Frame Advance hotkey to move the Playback cursor 1 frame back of forward.

When to use:

  • when you need to explore events of current segment carefully

2. Rewinding by mouse wheel

Hold the right mouse button and roll mouse wheel up or down to move the Playback cursor.

The mouse cursor can be pointing anywhere.

When to use:

  • when you need to explore events of current segment carefully/quickly

3. Dragging with mouse

Click on any cell in the leftmost column of the Piano Roll ("Icons" column) to send the Playback cursor to the frame. Also, click on any cell of the column and hold the left mouse button to drag the Playback cursor by moving the mouse. This method also allows to scroll the Piano Roll by dragging the Playback cursor outside (above or below the Piano Roll).

When to use:

  • when you're searching for an in-game event of the movie

4. Jumping on Markers

Click on << or >> button in the Playback panel, or press Shift + Page Up or Shift + Page Down, or hold Shift and roll the mouse wheel to move the Playback cursor to previous or next Marker.

When to use:

  • when you need to set the Playback cursor to the beginning of currently played segment (provided that the frame of the beginning is marked)
  • when you want to see events of previous/next segments

5. Jumping to Bookmarks

Press the hotkey (0-9) corresponding to the number of desired Bookmark, or click on a frame number in Bookmarks List, or click on a Bookmark icon in the Branches Tree to send the Playback cursor to the bookmarked frame.

When to use:

  • when you need to re-watch events of the movie starting from a bookmarked frame (e.g. watch the movie from the beginning of Level 2)
  • when you changed Input before the bookmarked frame and want to see new events at the frame

6. Jumping to the beginning / to the end of the movie

Press Shift + Home or Shift + End, or click the cloudlet or the fireball in the Branches Tree to move the Playback cursor to the beginning or to the end of the movie.

You can also press the Play movie from the beginning hotkey (Shift + R by default) to move the Playback cursor to the beginning of the movie.

When to use:

  • when you want to watch the movie from the very beginning
  • when you need to fill all movie frames with Greenzone data

Selection cursor navigation

Selection cursor is usually located on the frame where the most recent changes of Input were made, but you can also move the cursor to any other frame when needed.

The Piano Roll automatically scrolls after the Selection.

1. Frame-by-frame shift

Press Ctrl + Up or Ctrl + Down to move current Selection 1 frame up or down.

When to use:

  • when you need to transpose Selection up or down

2. Moving Selection to the beginning / to the end of the movie

Press Ctrl + Home or Ctrl + End to move current Selection to the beginning or to the end of the movie.

When to use:

  • when you need to select the same set of frames at the beginning or at the end of the movie

3. Jumping on Markers

Click on << or >> button at the bottom of the Toolbox, or press Ctrl + Page Up or Ctrl + Page Down, or hold Ctrl and roll the mouse wheel to move Selection cursor to previous or next Marker.

When to use:

  • when you need to set the Selection cursor to the beginning of currently edited segment (provided that the frame of the beginning is marked)
  • when you want to move to previous/next segments

4. Tracking the Selection History

Press Ctrl + Q or Ctrl + W to revert Selection to its previous or next state.

This method of navigation allows to return to previously edited segments and quickly recollect the sequence of recent changes.

When to use:

  • when you need to return to previously edited segment
  • when you need to select the same set of frames as before

5. Returning to the origin of Clipboard data

Press Ctrl + B to revert Selection to its state at the moment of the last "Copy to Clipboard" operation.

When to use:

  • when you need to remember where the Input was copied from

Special

1. Finding Markers with a given text

Open the Find Note window, enter the text to search and click Find next or press Enter key to set the Selection cursor to the closest Marker which Note contains the text. The Piano Roll automatically scrolls after the Selection. You can search up or down from the current position of the Selection cursor.

When to use:

  • when you need to find the segment, knowing some of the exact text it is labeled with

2. Jumping to the segment with similar description

Leave the Playback cursor in the current segment and click the Similar or More button to set the Selection cursor to the Marker containing the most relevant Note. The Piano Roll automatically scrolls after the Selection.

This method is described in the Advanced Features chapter.

When to use:

  • when you need to find the segment with a description similar to currently played segment.

Created with the Personal Edition of HelpNDoc: Write EPub books for the iPad


Operations

Reference ››

Operations

All modifications of the movie are registered in History Log. Every record of the Log contains the time when the modification was done and the keyframe (or starting and ending frames of the section) to which the modification was applied.

Here you can find the list of all possible types of History Log records and corresponding operations with the movie.

Input change | Markers change | Other
Set | Marker Set | Initialization
Unset | Marker Remove | Undefined
Pattern | Marker Pattern |
Clear |
Cut
Paste
PasteInsert
Clone
Insert
Insert#
Delete
Truncate
Record |
Import
Branch |  | Bookmark
 | Marker Branch |
 | Marker Rename
 | Marker Drag
 | Marker Swap
 | Marker Shift
 | LUA Marker Set
 | LUA Marker Remove
 | LUA Marker Rename
LUA Change

Initialization

Category: other

The record is created automatically when a new History Log is created.

Examples:

  • when creating a new project
  • when loading a compactly saved project that has no History Log

20:24:53 Initialization

Used: very rarely

Greenzone is truncated after zeroth frame.

Undefined

Category: other

Undefined modification. The record should not appear in TAS Editor 1.0.

Used: never

Set

Category: Input change

The record is created when one or more buttonpresses appear in one or several frames.

Examples:

  • click on an empty Input cell of the Piano Roll
  • draw a new stroke by dragging the mouse after clicking on an empty Input cell
  • Shift + click on an empty Input cell
  • select some frames and then click on a button symbol in the Header of the Piano Roll
  • select some frames and then press a key assigned to a virtual gamepad button

20:25:18 Set 15-21

Used: very often

Greenzone is truncated after the first frame where Input was changed.

Unset

Category: Input change

The record is created when one or more buttonpresses disappear from one or several frames.

Examples:

  • click on an occupied Input cell of the Piano Roll
  • erase some Input by dragging the mouse after clicking on an occupied Input cell
  • Shift + click on an occupied Input cell
  • select some frames and then click on a button symbol in the Header of the Piano Roll
  • select some frames and then press a key assigned to a virtual gamepad button

20:25:22 Unset 21

Used: very often

Greenzone is truncated after the first frame where Input was changed.

Pattern

Category: Input change

The record is created when a sequence of buttonpresses changes to currently chosen pattern.

The name of the pattern is added to the text of the record.

Examples:

  • Alt + click on an Input cell of the Piano Roll
  • Alt + dragging the mouse after clicking on an Input cell
  • select some frames and then Alt + click on a button symbol in the Header of the Piano Roll
  • select some frames and then Alt + press a key assigned to a virtual gamepad button

20:25:40 Pattern 21-30 Alternating (1010...)

Used: rarely

Greenzone is truncated after the first frame where Input was changed.

Clear

Category: Input change

The record is created when all buttonpresses disappear from one or several frames.

Examples:

  • select some frames and then press Delete
  • select some frames and then choose Edit -> Clear in TAS Editor menu
  • right-click on a selected frame number and choose Clear in the context menu

20:26:51 Clear 15-20

Used: moderately

Greenzone is truncated after the first frame where Input was changed.

Cut

Category: Input change

The record is created when all buttonpresses disappear from one or several frames, caused by "Cut" operation.

This is identical to the Clear operation, except that buttonpresses are copied to the Clipboard before deleting them.

Note: although you can undo this operation, the Clipboard contents won't revert.

Examples:

  • select some frames and then press Ctrl + X
  • select some frames and then choose Edit -> Cut in TAS Editor menu

20:27:05 Cut 21-23

Used: rarely

Greenzone is truncated after the first frame where Input was changed.

Paste

Category: Input change

The record is created when a Clipboard data is pasted into the movie.

Depending on the "Superimpose" checkbox, the old Input on those frames is either erased or combined with the new Input. The Piano Roll Header briefly flashes symbols of those buttons that were added in the Paste process.

Examples:

  • select some frames and then press Ctrl + V
  • select some frames and then choose Edit -> Paste in TAS Editor menu

20:27:11 Paste 21

Used: moderately/rarely

Greenzone is truncated after the first frame where Input was changed.

PasteInsert

Category: Input change, Markers change

The record is created when a Clipboard data is inserted into the movie.

Old Input and Markers are shifted down to make place for the Input from Clipboard.

Examples:

  • select some frames and then press Ctrl + Shift + V
  • select some frames and then choose Edit -> PasteInsert in TAS Editor menu

20:27:16 PasteInsert 21

Used: rarely

Greenzone is truncated after the first frame where Input or Lag was changed.

Clone

Category: Input change, Markers change

The record is created when copies of one or several frames are inserted into the movie, shifting the following Input and Markers down.

Examples:

  • select some frames and then press Ctrl + Insert
  • select some frames and then choose Edit -> Clone in TAS Editor menu
  • right-click on a selected frame number and choose Clone in the context menu

20:27:34 Clone 23

Used: often

Greenzone is truncated after the first frame where Input or Lag was changed.

Insert

Category: Input change, Markers change

The record is created when one or several blank frames are inserted into the movie, shifting the following Input and Markers down.

Examples:

  • select some frames and then press Ctrl + Shift + Insert
  • select some frames and then choose Edit -> Insert in TAS Editor menu
  • right-click on a selected frame number and choose Insert in the context menu

20:25:58 Insert 21

Used: moderately

Greenzone is truncated after the first frame where Input or Lag was changed.

Insert#

Category: Input change, Markers change

The record is created when a specific number of blank frames is inserted into the movie, shifting the following Input and Markers down.

If there's Selection in the Piano Roll, this operation inserts frames before the Selection, otherwise it inserts frames before the Playback cursor.

The number of inserted frames is added to the text of the record.

Examples:

  • press Insert and enter the number of frames to insert
  • choose Edit -> Insert # of Frames in TAS Editor menu
  • right-click on a selected frame number and choose Insert # of Frames in the context menu

20:26:09 Insert#4 29

Used: rarely

Greenzone is truncated after the first frame where Input or Lag was changed.

Delete

Category: Input change, Markers change

The record is created when one or several frames are deleted from the movie, shifting the following Input and Markers up.

Examples:

  • select some frames and then press Ctrl + Delete
  • select some frames and then choose Edit -> Delete in TAS Editor menu
  • right-click on a selected frame number and choose Delete in the context menu

20:26:12 Delete 33

Used: often

Greenzone is truncated after the first frame where Input or Lag was changed.

Truncate

Category: Input change, Markers change

The record is created when the tail of the movie is truncated, deleting all Input (and Markers) starting from either the Selection cursor or the Playback cursor (when there's no Selection).

Examples:

  • choose Edit -> Truncate movie in TAS Editor menu
  • right-click on a selected frame number and choose Truncate movie in the context menu

20:26:28 Truncate 42

Used: very rarely

Greenzone is truncated after the frame of movie truncation.

Record

Category: Input change

The record is created when the emulator is recording Input using gamepads.

The new Input appears at the Playback cursor frame. Depending on the "Superimpose" checkbox, the old Input of the frame is either overwritten or combined with the new Input. The Piano Roll Header briefly flashes symbols of those buttons that were added in the Recording process.

IDs of gamepads whose Input was changed are added to the text of the record.

Examples:

  • switch Recording mode on, unpause the emulator and press any keys assigned to buttons of gamepads
  • when emulator is paused, switch Recording mode on, hold any keys assigned to buttons of virtual pads and press Frame Advance

20:28:01 Record(1P) 18-24

Used: moderately

Greenzone is truncated after the Playback cursor position.

Import

Category: Input change

The record is created when an Input from another FM2/FM3 movie is imported into the current project.

Current movie Input is substituted by the Input of imported file. Markers are not changed.

The filename of the Input source is added to the text of the record.

Examples:

  • choose File -> Import Input in TAS Editor menu and open the file which should be the source of Input

20:28:53 Import Battletoads-WIP1.fm2

Used: very rarely

Greenzone is truncated after the first frame where Input was changed.

Bookmark0

Bookmark1

Bookmark2

Bookmark3

Bookmark4

Bookmark5

Bookmark6

Bookmark7

Bookmark8

Bookmark9

Category: other

The record is created when the data of a Bookmark slot is changed.

Note: re-saving a Bookmark into the same slot only works when the new Bookmark data differs from the data stored in the slot, e.g. when the Bookmark is placed to another frame or when the current movie Input differs from the Input stored in the slot.

When a Bookmark is successfully saved, its Branch becomes "the current branch of the movie", and the emulator shows the message "Branch # saved."

Examples:

  • press a "Save state" hotkey: Shift + key in the row from F1 to F10
  • right-click anywhere inside the Bookmarks List
  • right-click on a Bookmark icon in the Branches Tree

20:28:53 Bookmark1 10

Used: often

Greenzone is not truncated.

Branch0 to

Branch1 to

Branch2 to

Branch3 to

Branch4 to

Branch5 to

Branch6 to

Branch7 to

Branch8 to

Branch9 to

Category: Input change, Markers change

The record is created when the current movie is substituted with the data of a Bookmark slot. Both Input and Markers are substituted.

The time of the Bookmark creation is added to the text of the record, because the movie is actually reverted to its own state at that time.

When a Bookmark is successfully loaded, its Branch becomes "the current branch of the movie", and the emulator shows the message "Branch # loaded."

Examples:

  • press a "Load state" hotkey: Shift + key in the row from F1 to F10
  • click on the right half of the Bookmarks List
  • double-click on a Bookmark icon in the Branches Tree

20:29:02 Branch1 to 20:28:15

Used: moderately

Greenzone is truncated after the first frame where Input or Lag was changed.

Marker Branch0 to

Marker Branch1 to

Marker Branch2 to

Marker Branch3 to

Marker Branch4 to

Marker Branch5 to

Marker Branch6 to

Marker Branch7 to

Marker Branch8 to

Marker Branch9 to

Category: Markers change

The record is created when current movie is substituted with the data of a Bookmark slot, but the new Input was identical to the old Input, and only Markers were different.

Examples:

  • press a "Load state" hotkey: Shift + key in the row from F1 to F10
  • click on the right half of the Bookmarks List
  • double-click on the a Bookmark icon in the Branches Tree

20:29:33 Marker Branch1 to 20:28:15

Used: very rarely

Greenzone is not truncated.

Marker Set

Category: Markers change

The record is created when a Marker appears on one or several frames.

Examples:

  • double-click on a non-marked frame number in the Piano Roll
  • select some frames and then click on the "Frame#" in the Header of the Piano Roll
  • right-click on a selected frame number and choose Set Markers in the context menu

20:29:47 Marker Set 15-18

Used: often

Greenzone is not truncated.

Marker Remove

Category: Markers change

The record is created when Markers disappear from one or several frames.

Examples:

  • double-click on a marked frame number in the Piano Roll, drag the Marker outside the Piano Roll and release it
  • select some frames and then click on the "Frame#" in the Header of the Piano Roll
  • right-click on a selected frame number and choose Remove Markers in the context menu

20:29:52 Marker Remove 16-18

Used: moderately

Greenzone is not truncated.

Marker Pattern

Category: Markers change

The record is created when a sequence of Markers is created using currently chosen pattern.

The name of the pattern is added to the text of the record.

Examples:

  • select some frames and then Alt + click on the "Frame#" in the Header of the Piano Roll

20:30:11 Marker Pattern 20-30 One Quarter (10001000...)

Used: very rarely

Greenzone is not truncated.

Marker Rename

Category: Markers change

The record is created when Note of a Marker is changed.

The new text of the Note is added to the text of the record.

Examples:

  • type the text of the Note right after creating the new Marker by double-click
  • click on the upper edit field, erase old text and type new, then press Enter or click anywhere outside the edit field
  • click on the lower edit field, erase old text and type new, then press Enter or click anywhere outside the edit field

20:31:01 Marker Rename 20 Testing...

Used: often

Greenzone is not truncated.

Marker Drag

Category: Markers change

The record is created after moving a Marker from one frame to another.

The old and new frame number, as well as the Note of the Marker, are added to the text of the record.

Examples:

  • double-click on a marked frame number in the Piano Roll, drag the Marker to a non-marked frame number and release

20:31:08 Marker Drag 20=>15 Testing...

Used: moderately

Greenzone is not truncated.

Marker Swap

Category: Markers change

The record is created when two Markers switch places.

The old and new frame number of the dragged Marker, as well as its Note, are added to the text of the record.

Examples:

  • double-click on a marked frame number in the Piano Roll, drag the Marker to another marked frame number and release

20:31:14 Marker Swap 24<=>28

Used: rarely

Greenzone is not truncated.

Marker Shift

Category: Markers change

The record is created when a splicing operation didn't change Input but still shifted some Markers up or down.

Examples:

  • insert blank frame near the end of the movie (granted that there's no buttonpresses after the frame, yet there is at least one Marker)
  • clone a blank frame near the end of the movie (granted that there's no buttonpresses after the frame, yet there is at least one Marker)
  • copy a blank frame to the Clipboard and PasteInsert it somewhere near the end of the movie (granted that there's no buttonpresses, yet there is at least one Marker)

20:31:44 Marker Shift 21

Used: very rarely

Greenzone is not truncated.

LUA Marker Set

Category: Markers change

The record is created when a Marker appears on a frame as a result of using taseditor.setmarker() function.

Examples:

  • run a Lua script with a taseditor.setmarker(framenum) line

20:35:14 LUA Marker Set 0

Used: rarely

Greenzone is not truncated.

LUA Marker Remove

Category: Markers change

The record is created when a Marker disappears from one frame as a result of using taseditor.removemarker() function.

Examples:

  • run a Lua script with a taseditor.removemarker(framenum) line

20:36:12 LUA Marker Remove 0

Used: rarely

Greenzone is not truncated.

LUA Marker Rename

Category: Markers change

The record is created when Note of a Marker is changed as a result of using taseditor.setnote() function.

The new text of the Note is added to the text of the record.

Examples:

  • run a Lua script with a taseditor.setnote(markernum, newtext) line

20:37:03 LUA Marker Rename 0 Hello from Lua!

Used: rarely

Greenzone is not truncated.

LUA Change

Category: Input change, Markers change

The record is created when Input or Markers were changed as a result of using taseditor.applyinputchanges() function.

Instead of the word "Change" the operation can be named with any other text provided by the parameter of taseditor.applyinputchanges() function.

Examples:

  • run a Lua script containing such lines as taseditor.submitinputchange(frame, joypad, input) and taseditor.applyinputchanges(name)
  • run a Lua script containing such lines as taseditor.submitinsertframes(frame, number) or taseditor.submitdeleteframes(frame, number) and taseditor.applyinputchanges(name)

20:39:56 LUA Corruptor 10

Used: rarely

Greenzone is truncated after the first frame where Input or Lag was changed.

Created with the Personal Edition of HelpNDoc: Free Kindle producer


Lua API

Reference ››

Lua API

TAS Editor v1.0 comes with the library of 24 functions available for Lua scripts running in FCEUX emulator. With Lua scripts you can automate some aspects of TASing and even create your own tools for movie editing.

In FCEUX folder there's /luaScripts folder with /taseditor subfolder in it. There you can find examples of scripts using functions of this library.

If you don't know how to make and run Lua scripts in emulators, read Advanced Features and also refer to FCEUX Help .

Full list of functions:

taseditor.registerauto(function func)

taseditor.registermanual(function func, [string name])

bool taseditor.engaged()

bool taseditor.markedframe(int frame)

int taseditor.getmarker(int frame)

int taseditor.setmarker(int frame)

taseditor.removemarker(int frame)

string taseditor.getnote(int index)

taseditor.setnote(int index, string newtext)

int taseditor.getcurrentbranch()

string taseditor.getrecordermode()

int taseditor.getsuperimpose()

int taseditor.getlostplayback()

int taseditor.getplaybacktarget()

taseditor.setplayback(int frame)

taseditor.stopseeking()

table taseditor.getselection()

taseditor.setselection(table new_set)

int taseditor.getinput(int frame, int joypad)

taseditor.submitinputchange(int frame, int joypad, int input)

taseditor.submitinsertframes(int frame, int number)

taseditor.submitdeleteframes(int frame, int number)

int taseditor.applyinputchanges([string name])

taseditor.clearinputchanges()

taseditor.registerauto(function func)

Registers a callback function ("Auto Function") that runs periodically. The Auto Function can be registered and will be called even when TAS Editor isn't engaged.

When FCEUX is unpaused, your function will be called at the end of every frame (running 60 times per second on NTSC and 50 times per second on PAL).

When FCEUX is paused, your function will be called 20 times per second.

User can switch on/off auto-calling by checking "Auto function" checkbox in TAS Editor GUI.

Like other callback-registering functions provided by FCEUX, there is only one registered callback at a time per registering function per script. If you register two callbacks, the second one will replace the first, and the call to taseditor.registerauto() will return the old callback. You may register nil instead of a function to clear a previously-registered callback.

If a script returns while it still has registered callbacks, FCEUX will keep it alive to call those callbacks when appropriate, until either the script is stopped by the user or all of the callbacks are de-registered.

taseditor.registermanual(function func, [string name])

Registers a callback function ("Manual Function") that can be called manually by TAS Editor user. The function can be registered even when TAS Editor isn't engaged.

The Manual function doesn't depend on paused or unpaused FCEUX status. It will be called once every time user presses Run function button in TAS Editor GUI.

You can provide a new name for this button.

The Manual function cannot be run more often than TAS Editor window updates (60/50 FPS or 20FPS when emulator is paused).

In FCEUX code Manual function runs right after Auto Function.

You can use this feature to create new tools for TAS Editor. For example, you can write a script that reverses currently selected input, so user will be able to reverse input by selecting a range and clicking Run function button.

Like other callback-registering functions provided by FCEUX, there is only one registered callback at a time per registering function per script. If you register two callbacks, the second one will replace the first, and the call to taseditor.registermanual() will return the old callback. You may call taseditor.registermanual(nil) to clear a previously-registered callback.

If a script returns while it still has registered callbacks, FCEUX will keep it alive to call those callbacks when appropriate, until either the script is stopped by the user or all of the callbacks are de-registered.

bool taseditor.engaged()

Returns true if TAS Editor is currently engaged, false if otherwise.

Also when TAS Editor is engaged, movie.mode() returns "taseditor" string.

bool taseditor.markedframe(int frame)

Returns true if given frame is marked in TAS Editor, false if not marked.

If TAS Editor is not engaged, returns false.

int taseditor.getmarker(int frame)

Returns index number of the Marker under which given frame is located.

Returns -1 if TAS Editor is not engaged.

int taseditor.setmarker(int frame)

Sets Marker on given frame. Returns index number of the Marker created.

If that frame is already marked, no changes will be made, and the function will return the index number of existing Marker.

You can set markers even outside input range.

If TAS Editor is not engaged, returns -1.

taseditor.removemarker(int frame)

Removes marker from given frame. If that frame was not marked, no changes will be made.

If TAS Editor is not engaged, no changes will be made.

string taseditor.getnote(int index)

Returns string representing the Note of given Marker.

Returns nil if TAS Editor is not engaged.

If given index is invalid (if Marker with this index number doesn't exist), returns note of the zeroth marker.

taseditor.setnote(int index, string newtext)

Sets text of the Note of given Marker.

If given index is invalid (if Marker with this index number doesn't exist), no changes will be made.

If TAS Editor is not engaged, no changes will be made.

int taseditor.getcurrentbranch()

Returns number from 0 to 9 representing current Branch.

Returns -1 if there's no Branches or if TAS Editor is not engaged.

string taseditor.getrecordermode()

Returns string representing current recorder mode.

  • "All"
  • "1P"
  • "2P"
  • "3P"
  • "4P"

Returns nil if TAS Editor is not engaged.

When you want to check Recorder's read-only state, use emu.readonly().

int taseditor.getsuperimpose()

Returns number representing current state of Superimpose checkbox in TAS Editor GUI.

0 – unchecked

1 – checked

2 – indeterminate (you can interpret is as half-checked)

If TAS Editor is not engaged, returns -1.

int taseditor.getlostplayback()

Returns the number of the frame where Playback cursor was before input was changed.

If Playback didn't lose position during Greenzone invalidation, returns -1.

If TAS Editor is not engaged, returns -1.

int taseditor.getplaybacktarget()

If TAS Editor's Playback is currently seeking, returns number of target frame.

If Playback is not seeking or if TAS Editor is not engaged, returns -1.

taseditor.setplayback(int frame)

Sends Playback cursor (current frame counter) to given frame.

If given frame wasn't found in TAS Editor Greenzone, starts seeking to the frame.

If TAS Editor is not engaged, nothing will be done.

taseditor.stopseeking()

Stops Playback seeking and pauses emulation.

If Playback wasn't seeking, this function only pauses emulation.

If TAS Editor is not engaged, nothing will be done.

table taseditor.getselection()

Returns a table (array) containing numbers of currently selected frames. These numbers are sorted in ascending order.

If no frames are selected at the moment, returns nil.

If TAS Editor is not engaged, returns nil.

taseditor.setselection(table new_set)

Changes current selection to the given set of frames. Frame number in your table don't have to be sorted.

Call taseditor.setselection(nil) to clear selection.

If TAS Editor is not engaged, nothing will be done.

int taseditor.getinput(int frame, int joypad)

Returns a number representing input of given joypad stored in current movie at given frame.

If given frame is negative, returns -1.

If given frame is outside current input range, returns 0, which can be interpreted as a blank frame (no buttons pressed at this frame yet).

Joypad value must be one of the following:

0 – to get hardware commands (bit 0 = reset, bit 1 = poweron, bit 2 = FDS insert disk, bit 3 = FDS switch side)

1 – to get 1P buttons (bit 0 = A, bit 1 = B, bit 2 = Select, bit 3 = Start, bit 4 = Up, bit 5 = Down, bit 6 = Left, bit 7 = Right)

2 – to get 2P buttons

3 – to get 3P buttons

4 – to get 4P buttons

You should handle returned number (if it's not equal to -1) as a byte, each bit corresponds to one button (e.g. if bit 1 is set that means A button is pressed). Use Bitwise Operations to retrieve the state of specific buttons.

If given joypad is outside [0-4] range, returns -1.

If TAS Editor is not engaged, returns -1.

taseditor.submitinputchange(int frame, int joypad, int input)

Sends request to TAS Editor asking to change input of given joypad at given frame.

Actual movie input won't be changed until the moment you call taseditor.applyinputchanges().

Using several consecutive requests and then calling applyinputchanges() at the end, you can change several frames of current movie in one moment.

When applying the pile of requests, TAS Editor will execute them in consecutive order.

If given frame is negative, TAS Editor will ignore such request.

If given frame is outside current input range, TAS Editor will expand movie during applyinputchanges() to fit the frame.

If given joypad is outside [0-4] range, TAS Editor will ignore such request.

Given input will be treated by TAS Editor as a sequence of bits representing state of each button of given joypad (bit 0 = A, bit 1 = B, bit 2 = Select, bit 3 = Start, bit 4 = Up, bit 5 = Down, bit 6 = Left, bit 7 = Right).

If TAS Editor is not engaged, nothing will be done.

taseditor.submitinsertframes(int frame, int number)

Sends request to TAS Editor asking to insert given number of blank frames before given frame.

Actual movie won't be changed until the moment you call taseditor.applyinputchanges().

Insertion can move down some old input and Markers (if " Bind Markers to Input " option is checked by user).

If given number is less or equal to zero, TAS Editor will ignore such request.

If given frame is negative, TAS Editor will ignore such request.

If given frame is outside current input range, TAS Editor will expand movie during applyinputchanges() to fit the frame.

If TAS Editor is not engaged, nothing will be done.

taseditor.submitdeleteframes(int frame, int number)

Sends request to TAS Editor asking to delete given number of frames starting from given frame.

Actual movie won't be changed until the moment you call taseditor.applyinputchanges().

Deletion can move up some old input and Markers (if " Bind Markers to Input " option is checked by user).

If given number is less or equal to zero, TAS Editor will ignore such request.

If given frame is negative, TAS Editor will ignore such request.

If given frame is outside current input range, TAS Editor will expand movie during applyinputchanges() to fit the frame.

If TAS Editor is not engaged, nothing will be done.

int taseditor.applyinputchanges([string name])

Instantly applies the list of previously requested changes to current movie. If these requests actually modified movie data, new item will appear in History Log (so user can undo these changes), and Greenzone may become truncated, Playback cursor may lose its position, auto-seeking may be triggered.

Returns number of frame where first actual changes occurred.

If no actual changes were found (for example, you asked TAS Editor to set buttons that were already pressed), returns -1.

If pending list of changes is empty, returns -1.

You can provide a name that will be assigned to this change. This name will be shown in History Log. If you don't provide a name, TAS Editor will use default name ("Change").

After applying all requests TAS Editor clears the list of requests.

If TAS Editor is not engaged, nothing will be done.

taseditor.clearinputchanges()

Clears the list of previously requested changes, making TAS Editor forget about them before you call applyinputchanges(). Use this function to discard previously submitted input changes.

It's also recommended to call this function before making several requests in a row, so that you'll be sure that only your new changes will apply.

If TAS Editor is not engaged, nothing will be done.

Created with the Personal Edition of HelpNDoc: Full-featured Documentation generator


FAQ

Reference ››

FAQ

If after reading the Manual you still have any questions on the topic, feel free to ask them at TASVideos forum.

I think I've found a bug in the program, what should I do?

Post a message in the FCEUX subforum of TASVideos. Try to explain the issue precisely, to help author reproduce the situation. Attach a screenshot if you think it reflects the essence of the problem.

Is it possible to use Taseditor with other emulators?

No. Even though the program code of Taseditor is mostly isolated from the emulator code, it is by no means a plug-in. So it's necessary to manually port its source code and modify it according to specifications of target platform.

How can I TAS the traditional way, yet with Taseditor interface?

Basically, you can start traditional TASing right away, no additional settings are required. But if you must keep some old habits intact, you can fine-tune the program. Try the following options:

  • switch on the Config -> Old control scheme for Branching option
  • switch off the Config -> Branches restore entire Movie option
  • switch on the Config -> Combine consecutive Recordings/Draws option
  • switch off the Config -> Use Input keys for Column Set option

Also, it's recommended to switch the Bookmarks List to the "Branches Tree" view.

Why the right-click on the FCEUX window doesn't prompt the usual context menu?

It's done to facilitate the Playback cursor navigation with the mouse wheel .

Usually users move the mouse cursor in such a manner that it's in sight. Thus when TASer is watching the game events the cursor will often be inside the FCEUX window. Context menus would obstruct the view when you want to rewind the Playback by holding the right mouse button and rolling the mouse wheel. So, since there's no important items in the menu while TAS Editor is engaged, the menu was removed.

Why the right-click on the Piano Roll sometimes prompts a context menu and sometimes doesn't?

Taseditor's context menu only appears when you right-click on the number of a selected frame. If you right-click on a frame that is not selected, or you right-click on the Input of a selected frame, the menu won't appear.

It's done to facilitate the Piano Roll scrolling by right-clicking and dragging.

Generally, it's recommended to use keyboard shortcuts and other means of accessing Taseditor features instead of using context menu.

How do I insert a Reset command into the movie?

You should use Input Recording here. Place the Playback cursor to the target frame, switch on Recording, then choose NES -> Reset in FCEUX main menu and press Frame Advance. Also, it's recommended to set a Marker to this frame, since there's no other way to mark a Reset/Power switch in the Piano Roll (there's no columns for commands, only for buttons).

Then you can switch Recording off and continue usual movie editing. The frame with the Reset command can be transposed up or down by inserting or deleting frames above it.

Other hardware commands are invoked the same way, see Controls .

How do I change the order of columns in the Piano Roll?

Unfortunately, this feature is not supported in TAS Editor 1.0. This will be fixed in next versions.

How do I change the number of players (joypads) in my movie?

You should create a new project, copying the Input and Markers from the current one.

Choose File -> New in TAS Editor main menu. In the "Create New Project" window: choose the needed Input type, check "Copy current Input" and "Copy current Markers" checkboxes and click "OK".

Old project's Bookmarks won't be copied to the new project this way. But you can recreate them using Input export/import features.

How can I quickly compare two movies?

  1. Make sure that Hot Changes are enabled.
  2. Create an empty project, import the first movie into it (using File -> Import Input), replay the movie to the end and save it to Bookmark 1.
  3. Import the second movie over the existing Input and save the result to Bookmark 2.

The import operation will truncate the Greenzone after the frame where the first difference between Input of the two movies was found. Other places of discrepancy can be detected by observing the Input in the Piano Roll:

  • buttonpresses that match in both movies are colored black
  • new buttonpresses (added by the 2nd movie) are colored bright-red
  • deleted buttonpresses are marked by dash

For extra convenience it's recommended to name both Bookmarks, for example, copy/paste the filename of the imported movie into the upper Marker Note just before creating a Bookmark.

Why are those fm3 files so large?

An FM3 file usually contains full snapshot of the working process, including the Greenzone data (which takes the most part of the file). See Advanced Features for details. You can customize this in the Config .

Why is the Manual so long?

Because besides the program specifications the Manual contains a comprehensive tutorial (the Beginner's Guide ) which systematizes known principles of effective TASing. Since there was no similar endeavors before, the author decided that lengthy explanations are the lesser evil than possible inexactitude.

Created with the Personal Edition of HelpNDoc: Full-featured Help generator


Speedrunning synopsis

Reference ››

Speedrunning synopsis

Thanks to having a definite goal, creating tool-assisted speedruns is the easiest application of TASing, and all relevant techniques are examined pretty well. Here you can find the summary of generic tasks emerging in the process of polishing the Input for a speedrun. Before reading this, make sure you've learned the materials in TASing Process and TASing Methodology .

Speedrunners have to search for the shortest way of completing every segment of the game. This process of searching consists of testing a multitude of approaches for playing the segment and finally choosing the best approach. Here we will discuss only the problem of choice.

To simplify the problem, TASers usually compare only two approaches: the new working approach and the old best approach; all other old approaches are promptly forgotten (although the interesting ones can always be saved in the Bookmarks).

The best of all old (previously tested) approaches can be stored:

  • in Bookmarks – recommended
  • in the History Log – automatically but temporary
  • in TASer's own memory – not recommended

When the new working approach is considered to be better (more optimal) than the old best approach, it's naturally assumed that it's also better than any of the old approaches, so this working approach instantly becomes the best. In the case of using Bookmarks you should re-save the new approach to the slot where the old best approach was stored. At the end of the search the contents of this Bookmark slot are loaded into the final movie.

Optimality criteria in speedruns:

  • presence/absence of the specific event in the new and old approach (bool)
  • the time of occurrence of the target event in the new and old approach (int)
  • the state of the game at the same frame in the new and old movie (string)

Respectively, when you're comparing any pair of approaches you are doing one of the three possible actions:

1. Comparing presence/absence of the event.

A. By memory

B. Using Bookmarks

2. Comparing the time of occurrence.

A. By memory

B. Using the green arrow

C. Using a Marker

D. Using Bookmarks

3. Comparing the state of the game at one and the same frame.

A. By memory

B. Using Bookmarks

1. Comparing presence/absence of the event.

Choose the approach where the needed event happens / unneeded event doesn't happen. The occurrence of the event is only the first (and often easy) step in creating the Input for current segment, and next step is to try speeding up the time of the occurrence.

The search for approaches goes on until the first successful approach is found, or until you're tired (then the event is considered to be unfeasible).

Programming analogy: comparing two Booleans, comparing two arrays of Booleans.

A. Most of time it's enough to simply keep in mind the fact that target event didn't occur in previous approaches. Example: finding the Start buttonpress .

B. When the target event is complex (e.g. you plan to shoot 3 enemies simultaneously), it's recommended to save the most promising approaches into Bookmarks (e.g. an approach where you shot 2 enemies simultaneously and 3rd one shortly after), because if the target event is unfeasible, you might be satisfied with such partial success.

2. Comparing the time of occurrence.

Choose the approach where the target event occurs earlier. The time of occurrence is defined by the frame in which the event can be detected, while in previous frame it cannot be detected. The number of this frame is found by bringing the Playback cursor to the frame and watching the FCEUX screen (or Memory Watch) for confirming.

The search for approaches goes on until you're tired, or until all possible types of approaches are exhausted (then the current best approach is considered to be frame perfect, until new factors are found).

Programming analogy: comparing two Integer Numbers.

A. For simplest segments and small subsegments it may be enough to just keep in mind the current fastest frame number and compare results of all new approaches with this number. But in general it's not recommended to rely on human memory. Details: TASing Process .

B. On simple segments you can refer to the green arrow of Taseditor. When using it, you're supposed to always leave the Playback cursor at the frame of target event (which is only natural). Thus if the new frame of target event is located above the green arrow, it means the new approach is faster than previous approach. Details: TASing Methodology .

C. On complex segments use an unbound Marker that always points at the current fastest frame number in the Piano Roll. Every time you beat the old result you're supposed to manually move the Marker higher. Thus if the new frame of target event is located above the Marker, it means the new approach is faster than the old best approach.

D. On segments of any level of complexity it's recommended to use Bookmarks that are displayed in the icons column of the Piano Roll. Every time you beat the old result you're supposed to manually save the current approach to the same Bookmark slot, replacing the old best approach stored there. Thus if the new frame of target event is located above the Bookmark icon, it means the new approach is faster than the old best approach.

3. Comparing the state of the game at the same frame.

Choose the approach where properties of the game are more advantageous in a whole. This type of comparison is useful when you need to evaluate compound in-game situations. For example, in Formula 1 racing you have to care both about being as fast as possible and wearing tyres as little as possible, so you need to find an optimal balance on each segment of the track instead of simply rushing.

Here our segment has defined end frame, and every new test is supposed to replay the segment up to that frame. Taseditor stores this frame number in the form of the green arrow, which automatically pauses emulation when you watch new approaches. So TASer only needs to edit Input (creating new approaches), launch replaying, wait for the stopping and evaluate the result (judging by FCEUX screen or Memory Watch).

The search of approaches goes on until you're tired, or until all possible types of approaches are exhausted (then the current best approach is considered to be perfect, until new factors are found).

Programming analogy: comparing two Strings, comparing two arrays of Integer Numbers.

A. For simple segments it may be enough to just keep in mind the value of the most important property of the game state achieved in the old best approach. Every time you watch the replaying of a new approach, you can compare results of the new approach with this value. If you decide the new value is better, you have to memorize it in place of old value. Example: luck manipulation .

When there's more than one important property, it's not recommended to rely on human memory.

B. On complex segments and especially on gigantic segments (e.g. with the size of a whole level of the game) use Bookmarks that store alternative branches of the movie. The best approach for playing the segment is saved into one Bookmark slot and the new approach is saved into another slot. Then you can easily switch between these slots and compare values of each property of the game state. In addition, you can point the mouse cursor to respective Bookmarks to see screenshots of the game state and visually compare their properties with current image on FCEUX screen.

To display important RAM data on screenshots you should use Lua graphical output, then Memory Watch window won't be required to judge about hidden properties, and you will be able to successfully judge by screenshots only. Details: Program Customization .

In the situation when some properties in the new approach are better and some others are worse you'll have to thoroughly weigh all of them (either in your mind or using a Lua-powered aggregate formula) and then decide which state of the game is better.

Every time you beat the old result you're supposed to manually save the new approach to the same Bookmark slot, replacing the old best approach stored there.

After finding the fastest approach of playing the segment, a good TASer is expected to improve the entertainment value of the play through the segment. The optimality criteria in such activity may be very diverse, but the general requirement is to keep the same time of playing through the segment.

Alternatively, you can postpone the entertainment improvement of the segment and proceed to the next.

Created with the Personal Edition of HelpNDoc: Single source CHM, PDF, DOC and HTML Help creation


TAS Editor Inside

TAS Editor Inside

This section of the documentation describes all ideas put into the Taseditor and reveals major details of the final implementation of TAS Editor 1.0. For more details check the source code of the program (in C++).

Taseditor is an open source program and is distributed under the MIT license which allows unrestricted use. The license was chosen to encourage modification and porting to another platforms.

You can download the source code of the FCEUX emulator with built-in Taseditor from the official SVN repository: http://sourceforge.net/p/fceultra/code/

To work with SVN you'll need some SVN client program, like TortoiseSVN .

The source code of Taseditor is well-commented, and to understand the code you only need basic skills of programming in C++ under Win32 API.

Ideas

The intended functionality of the program

Implementation

The actual program architecture

Mistake-proofing

The list of unobvious nuances

FM3 format

Taseditor project file specifications

Created with the Personal Edition of HelpNDoc: Full-featured multi-format Help generator


Ideas

TAS Editor Inside ››

Ideas

Taseditor combines multiple experimental ideas into single system. Many of these ideas appeared long ago (see topics on the forum, like " dream tool ", etc.), but it took a long time to implement them in terms of a consistent system.

The underlying idea of Taseditor is the Piano Roll interface that allows user to interact with the movie in a very intuitive from. The first mention of the need for a Piano Roll-based TAS tool sounded back in 2005 , perhaps even earlier. A prototype called TASEdit was made in 2008. The final vision of Taseditor was formed in September 2011 and was improved during the course of development until the summer of 2012. In addition to the ideas implemented at that time, many promising but minor or hard-to-implement ideas were invented and postponed for the future.

Implemented in 1.0 | Planned for 2.0
Piano Roll Selection Markers Hot Changes Greenzone Playback Green arrow Auto-restore last position Multitrack Recorder Lua automation Bookmarks and branches Pop-up windows History Log Rerecord counter Modifier keys system Patterns Crossing gaps Compact saving Autosave | Output Log Minimap Virtual Joypad Selection improvement Columns tweaking Rerecords heatmap Other stuff Supporting platforms other than NES

Implemented ideas

Piano Roll

The basis of Taseditor, all other ideas were developed around this one.

  • It is a significantly redesigned List (ListView) or Table (GridView) component. Columns of the List correspond to Input buttons, rows of the List correspond to movie frames. The number of rows (lines) in the List is regularly updated automatically to match the number of frames in the current movie. The lines are numbered from top to bottom, starting from zero. The line number is equal to the number of frame associated with this line. The number of columns depends on the movie type (on the number of joypads and the number of buttons).
  • To the left from the Input columns there are two additional columns in the List. The first column (width ~17 pixels) is responsible for displaying icons and controlling the Playback cursor. Current Playback cursor position is displayed with a light-blue arrow icon. When you left-click on that column, the Playback cursor is sent to the appropriate frame, and then you can drag the cursor by moving the mouse, until you release the left button.
  • The second column (75 pixels wide) is responsible for displaying frame numbers and Markers, and for controlling the Selection and Markers. A single left-click on the column changes the Selection (and then you can stretch it by dragging). A double-click on a frame number puts a Marker there and starts dragging this Marker until you release the left mouse button.
  • The List Header displays names of the columns. The first column (icons column) does not have a name, the second column is called "Frame #" (frame number), the remaining columns are named with corresponding joypad button symbols. The same symbol appears in the cells of the column on the rows where the button is pressed. The user can click any cell of the List Header in order to change the appropriate button Input in the selected frames. Click the "Frame #" to change Markers in the selected frames.
  • In addition, the Header serves as an indicator of the pressed joypad buttons. And during Input Recording, the recorded symbols flash in the Header.
  • Input columns show the state of every joypad button for each frame of the movie. To see the state of the button of interest, you need to visually find the point of intersection of the frame row and the button column. If this cell contains a button symbol, then the button is pressed in this frame. If that cell is empty or has a dash, then the button is released. By left-clicking on any Input cell you can invert the state of the corresponding button. Also, if you hold the left mouse button, you can draw or erase Input in neighboring frames by moving your mouse up or down.
  • Piano Roll lines are colored with different pastel colors, so the frame numbers (black symbols) and the buttonpress symbols (dark-colored symbols) are always clearly visible on the pastel background. By the color of a Piano Roll line you can immediately determine if this movie frame is inside the Greenzone, whether there is lag in that frame, whether the given frame is currently displayed in the emulator window, and is the frame selected or not. Also, additional colors can focus the user's attention on specific frames, for example, on the target frame of seeking (flashing light-blue line) or the undo keyframe (purple line). In addition, by the background color of the frame numbers the user can see if there is Marker on the frame (yellow color).
  • The coloring of the Piano Roll cells also depends on the column (although to a lesser extent). Icon column always appears in white. Frame numbers column is displayed with pale shade of the current line color. The columns of the 1st (and 3rd) joypad buttons appear in normal shade of the current line color (green, red, blue, etc.), and the columns of the 2nd (and 4th) joypad buttons are displayed in a slightly tinted shade of this line color.
  • The visible area of the Piano Roll can be scrolled with the mouse wheel or by using the scrollbar, or a variety of other navigation methods . Such multitude of methods is meant to speed up the navigation to any desired segment of the movie, since only a limited number of lines can be displayed on screen at any given moment. This number depends on the current Piano Roll height in pixels, which depends on the current TAS Editor window height.

Selection

As in any other editor, in Taseditor the Selection is used to apply an operation to multiple frames at once. But in addition, here the Selection also serves as a pointer (cursor) to the last edited Input location.

  • The Selection is stored as a list of numbers of frames that are considered selected.
  • Taseditor also stores the Selections Log in memory, as an array of lists. The array size is equal to the the History Log size. You can return to the previous selections with Ctrl + Q and Ctrl + W. This is useful for tracking the recent history of clicks on the Piano Roll.
  • The Piano Roll column of frame numbers is used to control the Selection. If you hold the left button after you click on the frame number, you can stretch the Selection to adjacent frames. If you hold down the Ctrl key before clicking on a frame number, the previously selected frames remain highlighted, but if you make a simple click on a frame number or on Input, the current selection disappears (moves into the Selection history), and a new selection is created instead, consisting of one frame (which was clicked). If you hold down Shift before clicking on a frame number, you will select all the frames starting from the old Selection to the clicked frame. If you hold down Alt before clicking on a frame number, a pattern-based Selection will appear. Selection also changes when you click on Input cells, but only if the modifier keys are not held.
  • The topmost selected frame is called Selection cursor. If currently not a single frame is selected, it is implied that the Selection cursor points to the frame -1. This is necessary in some situations, for example, when there's no Selection, the bottom edit field displays the Note of the zeroth Marker.
  • The Selection Log (including the current Selection) is saved and loaded from the project file. When you change the "max undo levels" setting, it will change both the size of the History Log and the Selection Log.
  • While inserting and removing frames, the current Selection is automatically shifted up or down by a corresponding number of lines, in order to remain in the same position (relative to Input).
  • Current Selection can be moved (Ctrl + Up / Ctrl + Down / Ctrl + Home / Ctrl + End). If some part of the Selection goes beyond Piano Roll, this part disappears. That is, the user can not select any frame beyond the current movie.
  • The Selection cursor can jump on Markers (Ctrl + Page Up / Ctrl + Page Down), with each jump the current Selection goes to History and a newly selected frame appears at the next Marker.
  • The visible area of the Piano Roll always follows the Selection. If the selection does not fit the screen, Piano Roll scrolls in such a way that the Selection cursor is in the middle, but if the selection fits, the Piano Roll shows all selected frames.
  • The bottom text edit field displays the Note of the nearest Marker above the Selection cursor. This text is updated every time the Selection changes or you change Markers.
  • When you press Ctrl + A, the current Selection goes to History, and instead it selects the frames starting with the nearest Marker above the Selection cursor and ending with the next Marker (not including that Marker). This way you can select the whole segment. At the second Ctrl + A press, the Selection changes to a set of frames between the Markers, not including the upper and lower Markers. On the third Ctrl + A press, the Selection will change to a set of frames between the Markers, excluding the upper but including the lower Marker. Finally, the fourth Ctrl + A pressing modifies the Selection into a set of frames between the Markers, including both Markers. All the next Ctrl + A presses will repeat these four versions of the selection.

Markers

When editing large movies, the user may need to set some marks on the Piano Roll lines, in order to distinct these lines visually from their neighbors. After a series of improvements, that simple idea evolved into a versatile feature.

  • Any frame of the movie can be marked. If necessary, the user can even mark all movie frames. Also, you can leave a mark, say, on a frame 1200, and then truncate the Input after frame 1000, leaving the Input-detached Marker outside the movie boundary. This Marker will remain in the project. To see it, you would need to emulate the game up to frame 1200 again, so the Piano Roll displays the marked line.
  • Unmarked Piano Roll lines are displayed in normal colors, but in the marked lines the frame number cell is colored yellow. This color is chosen because Markers are intended to attract user's attention. Also the numbers of marked frames are written using special font, so that the Marker presence can be guessed even when the yellow background is covered by the blue Selection color.
  • Markers can be attached to the Input (then they are displayed by pale yellow), or can be detached (displayed by more saturated yellow). When the Markers are attached, they are affected by all operations that move Input up/down, and affected by Input truncation.
  • A Marker can be set by double-clicking (with the left mouse button) on the desired frame number. If you double-click on an already existing Marker, you will start dragging it until you release the left button. So you can move the Marker to another frame, or remove a Marker by throwing it away from the Piano Roll. When you drag it, a Marker image is hanging under the mouse cursor, looking like a yellow rectangle with the number of the frame it was taken from. To cancel the dragging, either drop the Marker on the same cell, or drop it on any Input cell.
  • Markers can also be created and removed using the context menu or by clicking on the "Frame#" caption.
  • Usually Markers are placed far from each other, so there are intervals of unmarked frames between them. Therefore, Markers can be used not only as color highlighting for special frames, but also as border marks for movie segments. The following terminology is used: each Marker corresponds to the movie segment that starts with the marked frame and ends with the last unmarked frame. For example, if Markers are set at the frames 10 and 20, we are calling the range of frames 10-19 as a "segment of the first Marker", and the segment of the second Marker consists of all the frames from the frame 20 to the last movie frame.
  • The intervals between the Markers can be crossed by jumping from the current Marker to the next one (or previous). This allows to speed up the navigation through the movie in some cases.
  • With the Select between Markers function (Ctrl + A) the user can quickly select all frames in the current Marker segment. Thus Markers can accelerate not only navigation, but also editing.
  • Each Marker has a text Note. After Marker creation it is empty. The user can view and edit the Note using any of the two text edit fields. In the upper edit field you can see the Note of the Marker above the current Playback cursor. The lower edit field displays the Note of the Marker above the Selection cursor. So, to edit the desired Note, you must first put one of the two cursors below desired Marker or right into the Marker. In theory it sounds awkward, but in Taseditor the general workflow ensures that one of the cursors is usually located under the needed Marker.
  • The Note size is limited by one hundred of characters, because Notes are not intended to store long texts, they are for short comments, tags and similar kinds of napkin notes. In an extreme case you can always place multiple Markers in a row and break the long text into several adjacent Notes.
  • You can make a regular search through Notes text (Find Note) or fuzzy search (Similar/More). See more in Advanced Features .
  • Markers are saved and restored from the Bookmark branches along with Input. Each Marker operation is recorded to History Log the same way as Input operations. Also, the current state of Markers is saved into the project file, right after saving the Input data.

Hot Changes

Taseditor paints text symbols in the Input cells by different colors, depending on the time of editing the cell. For details, see Program Interface and Program Customization .

  • Taseditor stores the hotness value for all the Input cells, despite the fact that majority of them has zero hotness. It is necessary for the rare occasions when almost all movie cells become mass-changed (e.g, Import or Paste operations). Thus the array of Hot Changes takes a lot of memory, but it is well compressed and takes little space on the disk.
  • Using 16 shades of color, so that one byte can fit the data about hotness of 2 cells. Also, it makes no sense to add more grades, since the human eye will hardly distinguish them, while the value of the Hot Changes is in the ability to quickly estimate Input without long deliberation.
  • The state of the current Hot Changes map changes only when a new item is added to the History Log (and during History undos).
  • when changing Input, all old cells lose one level of hotness, and changed cells gain maximum level
  • when removing frames, old cells lose one hotness level
  • when inserting frames, old cells lose one hotness level, and all the inserted frames cells appear with maximum level
  • when editing Markers or Bookmarks, and when truncating the movie, Hot Changes do not change
  • when loading a Bookmark, the current Hot Changes are replaced by the Hot Changes from the Bookmark branch
  • when importing Input, the old cells are reset to zero hotness, and changed cells gain maximum level

Greenzone

Since the Piano Roll interface provides the user with almost instant editing of the Input of any frame, it is also desirable to provide the ability to instantly view the game state at any given frame. This is accomplished by caching the data on all emulated game states.

  • The Greenzone is an array of data about the Output of the game, retrieved at the beginning of each frame. That is, the item #0 stores the game state before any emulation started, the item #1 stores the game state before emulating the second frame (the frame with number 000001), and so on. Besides the savestates the Greenzone stores the Lag Log that corresponds to the Input of the current movie. It's also theoretically possible to store other information.
  • The Greenzone starts with zeroth frame and has a lower boundary (head) – the frame number after which the Greenzone has no information about future game states (however, there may still be some information about the Lag of those frames).
  • The game data is collected into the Greenzone at the beginning of each frame (before emulation) in the following way: if the Greenzone array item with the number equal to the current frame is empty, or the position of the Greenzone head is smaller than the current frame number, then the array item is filled with information about the current game state (from emulator), and the Greenzone head moves forward if necessary.
  • To save some memory, the Greenzone is rarefied periodically, removing the savestates (but not the Lag Log data) of some early frames that are left too far from the Playback cursor. For details, see Program Customization .
  • All the Greenzone data together with the Lag Log is saved and loaded from the project file. After loading the project, Taseditor restores the Playback cursor state using the Greenzone.
  • Any change of the current movie Input forces the Greenzone remove the savestates of all frames after the first edited frame, not including the frame. This is accomplished by reducing the position of the Greenzone head and removing the outdated information from an array of savestates (but without freeing the memory, because the place of the old savestates will soon be taken by the new data of about the same size).
  • The Playback cursor must always be is inside the Greenzone, in order to avoid displaying the irrelevant game states on the FCEUX screen. So the Greenzone truncation may also move the Playback cursor.
  • When creating a Bookmark, the savestate of the bookmarked frame and the whole Lag Log are copied into it. When loading this Bookmark, the Greenzone is first truncated (because of the Input change), but then the bookmarked savestate and the relevant part of the bookmarked Lag Log are restored, and the Greenzone head position is moved, if necessary.
  • The Greenzone data is used for coloring the Piano Roll lines and the Bookmarks List items. The Lag Log stores information independently from savestates stored in the Greenzone. Every item of the Lag Log can have one of the three possible values: LAG=YES, LAG=NO, LAG=DONTKNOW.
  • The lag information for the Lag Log is collected at the same time when collecting the current game state to the Greenzone. That is, before emulating the current frame. At this point the emulator has knowledge about the previous frame lag, so at the frame 000020 we can store the lag data to the cell 19. Also, during this time the AdjustLag operation can fire off and shift the entire following Input up or down. The Input is shifted up, if in the previous frame the Lag Log has LAG=YES, and the emulator says there was no lag in previous frame. The Input moves down if the Lag Log has LAG=NO in the previous frame, and the emulator says there was lag. Together with the Input this operation shifts all subsequent items of the Lag Log get, so that the red lines of the Piano Roll are still consistent with the shifted Input gaps.

Playback

The Playback is a meeting of all functions used for watching the game Output (the game state).

  • The main attribute of the Playback is the "currently played movie frame", the frame whose screenshot is displayed at the emulator window at the moment. This frame corresponds to the light-blue line in the Piano Roll, which is called Playback cursor. Since the Playback cursor is tied to the state of the emulated game, you can use it not only as an indicator, but as a control too. E.g. to see the frame of interest on the FCEUX screen, you need to put the Playback cursor to the line with that frame number. There are many ways to do this.
  • When the user sends the Playback cursor on a frame contained in the Greenzone, the emulated game state is recovered from the corresponding savestate. Since there was no emulation in this case, Taseditor has to simulate the events "frame boundary" and "frame begin"/"frame end", so that the respective Lua functions could fire off.
  • When the user sends the Playback cursor on a frame outside the Greenzone, Taseditor restores the game state from the nearest preceding frame that has the Greenzone savestate, and then starts seeking to the desired frame. "Seeking" is the emulation which automatically stops when the target frame is reached. When the Playback is seeking, a copy of the light-blue cursor flashes at the target frame in the Piano Roll.
  • Seeking is based on the following assumption. Since the emulator provides determinism, the game state for any frame is guaranteed to be obtained by using the initial game state (the movie beginning state) and the Input of the movie. Moreover, you can get the required state using the state for any previous frame (any Greenzone savestate) and the Input of the movie.
  • The seeking process is indicated by the progressbar, in order to let the user estimate the waiting time if seeking takes too long. When there is no seeking, the progressbar is full during pause and empty during emulation.
  • The seeking can be done at the highest possible emulation speed. In this case the seeking will be finished instantly (for relatively small segments).
  • In many cases it is useful to automatically stop emulation at the last frame of the movie Input. The Autopause at the end of Movie option serves for this. When the emulator is paused, if the Playback cursor is not on the last movie frame, the Playback sets the "automatic stop" flag. And if the user releases the pause, the Playback automatically stops when it reaches the last movie frame. Thanks to it, the Playback cursor will not run away when the pause is released.
  • In most cases the user does not want to automatically scroll the Piano Roll after the Playback cursor when the cursor moves itself. But for the cases when it is needed, there is the "Follow cursor" checkbox.

Green arrow

When making speedruns, TASer is trying to beat his record on each segment. In most cases the optimality criterion is the number of frame where the target event of the segment occurs. To detect the frame, TASer moves the Playback cursor while watching the FCEUX screen, and stops this manual search when he detects the beginning of the event of interest. Then the Playback cursor is usually left at this frame, and the TASer starts to change the Input on the segment (above the Playback cursor), hoping to improve the old approach and get the same event at an earlier frame.

While changing Input, the Greenzone becomes truncated and the Playback cursor jumps up. When the TASer believes that the Input was changed enough, he starts checking the game Output in order to determine at which frame the target event occurs now. For this, he moves the Playback cursor again while watching the FCEUX screen.

To conclude an improvement, the TASer needs to compare the old frame number (detected last time) and the new number, detected just recently. Taseditor visualizes this data to the user, so that he doesn't need to keep the numbers in mind. The new number is indicated by the Playback cursor, the old number is shown by the green arrow.

  • Thus the actual name of the green arrow is "last position of the Playback cursor".
  • The more universal replacement of the green arrow would be Bookmarks and Markers that can be set manually.
  • The icon of the green arrow appears in the icons column of the Piano Roll. When drawing icons in Piano Roll, the green arrow has priority over the blue arrow (the Playback cursor icon), since the position of the blue cursor can be defined by the other columns.
  • The green arrow appears on the frame of the Playback cursor at the moment of Greenzone truncation. And it remains on that frame until the user performs the following sequence of actions:
  1. emulate at least one frame (the user started viewing the segment)
  2. truncate the Greenzone and jump up with the Playback cursor again
  • Thus the green arrow will not change its position when the Greenzone is truncated twice in a row without an emulation between (e. g. the TASer changed Input on the frame 90 and then on the frame 80, but the green arrow remains on the frame 100).
  • Also, the green arrow does not change its position when the Greenzone is truncated during seeking, granted that the emulator is unpaused at the moment.
  • The green arrow does not change its position during operations AdjustLag , Branch , Record .
  • When you press the middle mouse button, the Playback starts seeking to the green arrow, if the arrow is outside the Greenzone. But if the arrow is inside the Greenzone, it means the current segment has been already watched, and the automatic pause on the green arrow is not needed anymore.

Auto-restore last position

When making any TAS, the optimality criterion may be either the game state on a certain frame, or the sequence of events on the segment. TASer watches the segment and leaves the Playback cursor on the last frame of the segment, then he changes the segment Input and watches the segment again, stopping the Playback cursor on the same frame as last time. TASer makes the conclusion about the improvement either while watching the segment events, or after stopping the emulation and evaluating the properties of the final frame.

That process can be automated by auto-starting the seeking to the green arrow after every Greenzone truncation. The "Auto-restore last position" checkbox serves for this purpose.

  • When the checkbox is enabled, the Playback starts seeking to the green arrow right after the Greenzone truncation.
  • If the Greenzone was truncated during seeking, the original seeking will be resumed without changing the target frame. But if the seeking was paused at the moment of the Greenzone truncation, the original seeking is canceled and a new seeking will start, targeting the green arrow. The implication is that if TASer did not wait for the finish of seeking, and instead he paused the emulator and started to change the Input on the current segment, then TASer has focused on a subsegment, so the further auto-restore should run only for this subsegment.
  • Auto-restoring does not start during operations AdjustLag , Branch , Record . When the AdjustLag operation fires off, the movie playing is not affected.

Multitrack Recorder

The Recorder is a meeting of all functions for editing Input on the frame pointed by the Playback cursor. The Recorder provides TASer with the second way to edit Input – by recording.

  • Multitracking allows TASer to change the data of only one selected joypad in Recording mode, leaving the other joypads data on the same frames intact. For details, see Toolbox .
  • When Recording mode is on, at the beginning of every frame the emulator polls virtual joypads and writes the data to the current movie. Then it immediately passes control to the Recorder.
  • Recorder:
  • uses the data from the movie (from the frame under the Playback cursor) as newly recorded data, or (if recording the pattern, and "no presses" need to be recorded now) uses nil as the newly recorded data
  • compares the newly recorded data to the old data stored in the History Log
  • imposes the filter over the changes, according to the currently selected multitracking mode
  • selectively combines old and new data, according to the "Superimpose" checkbox
  • saves the resultant changes to the current movie
  • calls the History Log to let it create a new item and then truncates the Greenzone
  • returns control to the emulator
  • Emulator returns the current movie data (from the frame under the Playback cursor) to virtual joypads, in order to use the data for the frame emulation. Also, at this moment the emulator executes the recorded commands (reset, etc.).
  • Each frame, the Recorder gets information from the emulator about the currently pressed buttons of virtual joypads and prepares certain information for the Piano Roll, the information about which columns in the Piano Roll Header should glow green. For example, if you have selected the "2P" radiobutton and checked the " Use 1P keys for all single Recordings ", that means when you press A on the first joypad, the Piano Roll Header will highlight the "A" symbol of the second joypad. And if the A button wasn't held in previous frame, the Recorder considers this in accordance with the " Use Input keys for Column Set" checkbox.

Lua automation

Lua allows the user to expand Taseditor capabilities, in particular, it provides the TASer with the third way to edit Input – by automatic generation.

  • Lua interpreter calls the appropriate Taseditor function not directly but through Taseditor's gateway (taseditor_lua).
  • When some function from the "taseditor" library fires off, Lua interpreter takes the arguments data from the stack, converts it to a format accepted by Taseditor's gateway, and sends it to the appropriate function of the Lua gateway of Taseditor.
  • The gateway calls the appropriate functions of Taseditor and sends the result back to the Lua interpreter.
  • Lua interpreter puts the returned data to the stack, converting the data to a format accepted by Lua code if necessary.
  • The functions submitinputchange(), submitinsertframes() and submitdeleteframes() do not cause immediate change of the movie data, but only create an entry in the array of the postponed jobs, stored in Taseditor's Lua gateway. All the postponed jobs are executed when the applyinputchanges() function is called. Thanks to this, a Lua script can apply many changes to the movie at once, creating only one item in the History Log.

Bookmarks and branches

Bookmarks are a specialized alternative to Markers. And branches are needed to store several movies in a single project. So, to simplify the creation and navigation through branches, they are assigned to Bookmarks, by analogy with the traditional savestates.

  • A project can store up to 10 Bookmarks. This limitation is due to the number of the numeric keys on the keyboard. Also, such a restriction allows Taseditor to display basic information about all the Bookmarks at once, with no need for scrolling. In addition, the long-term experience of traditional TASing confirms that this number of slots for Bookmarks is enough for productive TASing.
  • A Bookmark can be set at any frame of the movie. Bookmarks will not disappear even when the movie is truncated. For example, if you set a Bookmark to the frame 1200 and then truncate the Input after frame 1000, a Bookmark will remain beyond the movie boundary, and if you jump to the Bookmark, the movie will expand to frame 1200.
  • Bookmarks are displayed in the Piano Roll as icons with corresponding digits (slot numbers). A Bookmark that corresponds the current movie branch is shown by the blue-colored digit, other Bookmarks are displayed by green digits.
  • A Bookmark can be set by pressing the corresponding hotkey (each slot has a dedicated hotkey for saving) or by right-click on the Bookmark slot. The Bookmark is set to the frame where the Playback cursor currently is. This frame number is stored in the Bookmark, and in the future you can always send the Playback cursor on that frame by clicking with the left mouse button over the Bookmark slot, or pressing the hotkey (each slot has a dedicated hotkey for jumping). "Jump to Bookmark" is not an operation, because no change is made to the movie.
  • When setting a Bookmark, Taseditor checks whether the newly saved data differs from the data already contained in this Bookmark slot. If there's no difference, the Bookmark operation is not performed.
  • In addition to storing the frame number, all movie data is also stored in the Bookmark slot (Input type, Input, Hot Changes, Markers). In future, the current movie may be changed many times, but you can always return back to the state of the movie stored in this Bookmark.
  • In addition, each Bookmark also stores the screenshot of the FCEUX screen at the time of bookmarking, allowing you to quickly see the contents of the Bookmark without loading it. Also it stores a copy of one savestate from the Greenzone (on the bookmarked frame), allowing to immediately put the Playback cursor on the Bookmark frame after loading the branch.
  • After setting a Bookmark, the Bookmark becomes current (shown with a blue-colored digit), because its branch is closer to the current movie than the other branches.
  • Whenever the current movie is changed to a bookmarked branch, the Input change occurs, so the Greenzone is truncated after the first different frame. But thanks to the savestate stored inside the Bookmark, one savestate returns back to the Greenzone on the bookmarked frame. Therefore, when loading a Bookmark you always immediately move the Playback cursor to the bookmarked frame, while jumping to a Bookmark (without changing the movie) may require seeking.
  • All Bookmark operations (setting, jumping, loading) are executed only after the emulation of the current frame, even if the signal from the user comes in the middle of the frame.
  • To display the basic Bookmark data, Taseditor uses the Listview with disabled scrolling. The List contains 10 rows and 3 columns. When creating a new project, all 10 Bookmarks are empty, so the 2nd and the 3rd columns in the Bookmark List are empty.
  • The 1st column of the Bookmarks List displays the slot number that corresponds to the given line. The number is displayed the same way it is displayed in the Piano Roll – i.e. with digit icons of green or blue color. The numbering of slots goes in this order: 1, 2, 3, 4, 5, 6, 7, 8, 9, 0. This order is necessary, so that user doesn't lose the association with the numeric keys on the keyboard.
  • The 2nd column of the Bookmarks List displays the bookmarked frame number.
  • The 3rd column of the Bookmarks List displays the real time when the Bookmark was created.
  • The Bookmarks List is divided in half with a vertical bar. The left side (which contains the 1st and the 2nd column of the List) is associated with bookmarking functionality of the Bookmarks. The right side (the 3rd column) is associated with branching functionality of the Bookmarks. The left side is displayed in a lighter shade, the right one – in the darker. Left-clicking on the left side means a jump to the Bookmark, and left-click on the right side is loading the branch of the Bookmark.
  • Bookmarks List lines are painted in colors, matching the bookmarked Piano Roll lines. For example, if the Bookmark is set on the frame 1000, and the Playback cursor is currently on that frame, this line will be drawn in light-blue color in the the Bookmarks List. This feature gives the user some additional information about the Bookmarks location in the movie.
  • Instead of constant viewing of the Bookmarks List, the user can switch to the Branches Tree. Switching is done by clicking on the caption above the Bookmarks List.
  • Branches Tree is a graphical representation of the relationship between the branches of all Bookmarks in the project. Bookmarks are usually set during the movie creation, so the later Bookmarks contain the branch the initial part of which coincides with earlier Bookmarks branches. For each Bookmark you can find the "parent" Bookmark, whose movie likely gave birth to this Bookmark movie. As a result, Bookmarks can be arranged in a hierarchical structure, the beginning of which is the root (shown as a cloudlet), that is a parent for Bookmarks that have no parent. Searching for Bookmarks parents re-occurs after every change in Bookmarks. The search is guided by numbers of the bookmarked frames, so the beginning of the hierarchy will contain the Bookmarks with the lowest frame number.
  • Markers contained in the Bookmarks do not affect the algorithm of searching for parents. The parent is found by comparing the Input.
  • When you set a Bookmark, it becomes current, and its contents are no different from the current movie. But after some editing of the movie it will become different from the current Bookmark, so the Branches Tree will show the fireball to report the difference. The fireball symbolizes the current movie, and the current Bookmark is always considered to be its parent. There's no real search for the best parent of the fireball, because such search would need to be done after every movie modification, and it would require comparing the current movie to the Input of each Bookmark, that is too resource-intensive.
  • Bookmarks in the Branches tree are displayed as digit icons (like in the Piano Roll). Current Bookmark is displayed as a blue-colored digit. Bookmarks relation is shown in thin lines. For the current Bookmark there is a sequence of the red lines that connect all the Bookmarks which will not change the current movie Input if you load the Bookmark (because at least up to the bookmarked frame the loaded Input will be the same as the Input stored in the current Bookmark). These red lines go from the cloudlet to the current Bookmark or even further – to the heirs of the current Bookmark (if the current Bookmark contains the same Input as these successors).
  • Due to how the Bookmarks are located in ascending order of bookmarked frame numbers, the sequence of the red lines can be interpreted as a timeline of the current movie. The cloudlet is the beginning of this timeline, by clicking on it the Playback cursor is sent to the beginning of the movie. The Bookmarks sitting on the red thread are the intermediate stages of that timeline, by clicking on them the Playback cursor is sent to the bookmarked frames. The fireball (if exists) is considered to be the end of the timeline, and when you click on it the Playback cursor is sent to the end of the movie.
  • Thus, any position of the Playback cursor can be projected onto this timeline by finding the two Bookmarks which contain the Playback cursor in between, and then converting the distance from frames to pixels. As a result, the current Playback cursor position is always displayed in the Branches Tree as a small blue triangle (similar to the Playback cursor icon in Piano Roll).
  • If you need to see the alternative timeline of any Bookmark. hover the mouse cursor over it (the timeline will be displayed by blue lines).
  • All Bookmarks data is saved and loaded from the project file. As for the Branches Tree, Taseditor only saves the cached data about the number of the first frame of difference in the Input for each pair of Bookmarks. Based on this data, Taseditor easily restores the hierarchy of parent relation between the Bookmarks. And if this data is not available, Taseditor will have to redo the comparison of Input.

Pop-up windows

They are used to display the context-sensitive information that is needed only at certain moments of time.

  • TAS Editor 1.0 has only two types of pop-ups: screenshots for Bookmarks and text descriptions for Bookmarks. Both windows pop up when the user is hovering the mouse cursor either over the right side of the Bookmarks List or over any Bookmark icon in the Branches Tree.
  • Both windows appear (with translucency) within about half a second after the mouse cursor was pointed to an active element. They disappear in the similar fashion after moving the cursor off the item.
  • You can turn off one or the other type of pop-ups in the settings .
  • The screenshot pop-up window displays a copy of the FCEUX screen made at the time of bookmarking. Depending on the HUD in Branch screenshots option, the image will be either raw emulated console screen or the console screen with the superimposed emulator on-screen display. Screenshots are used to quickly check the Bookmarks contents and to compare alternative strategies.
  • The description pop-up window displays a text field with the width equal to the width of the upper and lower edit fields. That text field shows the Marker Note text taken from the pointed Bookmark branch. The Marker is determined by the bookmarked frame number.
  • The screenshot window is displayed to the left from the Bookmarks section, the description window appears under the screenshot window.
  • When you drag the TAS Editor window, the pop-ups move along with it.
  • If the contents of the displayed Bookmark change while pop-up windows still display the old contents, the pop-up windows will be instantly updated.

History Log

The logging of all significant changes of the project serves mainly for undo, as well as for visual tracking of the history.

  • Each item of the History Log stores a full copy of current Input, Lag and Markers at the time of the item creation. Also, any item can store a backup copy of a Bookmark, if the item was created because of the Bookmark operation.
  • The data of each item is stored in memory in both compressed and uncompressed state. Uncompressed data is used during work, and its compressed version is saved in fm3 file. When creating a new item in History Log, the data of the item is only stored in an uncompressed form, but every half-second Taseditor goes through the History Log and creates a compressed version of the first found item without a compressed version. Thus, at the time of saving the project to disk, almost all History items already have compressed versions, and those that don't have it will be compressed during saving (which slows down the process of saving). When loading an fm3 file, the History Log is loaded in a compressed form, and is decompressed.
  • Using the History Log, Taseditor implements searching for the first changed frame after which the Greenzone should be truncated. Most operations work as follows:
  • Edit the current movie data.
  • Remember the minimum and maximum number of changed frame.
  • Call the History to register changes, passing the minimum and maximum frame as parameters, together with the operation code and other parameters.
  • The History compares the contents of the current movie with the contents of the last item of the History Log. If the minimum frame is provided, the search begins from that frame, ignoring the previous movie contents (in order to speed up the work). Otherwise everything from the movie beginning is checked. If the maximum frame is set, then the search ends on that frame (but most operations do not pass the maximum frame, since, for example, an insertion of a blank frame shifts all subsequent Input, and we need to check everything up to the end of the movie).
  • Once the History detects the first difference between the Input/Markers of the current movie and the Input/Markers of the previous movie snapshot, it creates a new new item in the History Log and fills all its attributes.
  • If the differences were not found, it is believed that the operation did not affect the movie, and no change in the project is registered. For example, if you record the same buttonpresses over existing ones, the Record operation will not be registered.
  • Even if an operation didn't change Input/Markers, it could still shift Lag, so the History also compares Lag Logs and returns the first frame of difference.
  • For the Record operation, the History registers not only the frame number of the changed Input, but also the number of the joypad whose buttons were changed.
  • Consecutively added items for operations AdjustLag , Record , Set or Unset can be combined into one item of the History Log, to make it easier to roll back when necessary. The combining is done when the History is filling the attributes of the new History Log item. Instead of appending the item to the end of the Log, it replaces the last item by the new one.
  • After the registration of a new item, the History sends a signal to the Branches Tree (to spawn the fireball) and to the project manager (to add an asterisk to the window caption), and then exits, returning the number of the frame of the first difference found. If no difference was found, it returns -1.
  • Truncate the Greenzone after the first different frame. This number can be greater than the minimum number of the frame of the changes made by the operation. For example, if you set buttonpresses in all selected frames, the minimum frame will be the first selected frame, but the Greenzone will be truncated only after the frame where the button wasn't pressed before.
  • The History can be rolled back by jumping from the current History Log item to the previous one. It's possible to directly jump to any item of the History Log. Current movie and current Markers are recovered from the data contained in this item, and the item becomes current.
  • One of the attributes of each History item is the "key frame number". For most operations it's the frame number of the first difference. But for operations that shift Input it will be the number of the minimum frame.
  • When jumping through History Items, a purple pointer appears in the Piano Roll for half a second, focusing the user's attention on the keyframe. When you roll back (undo), the purple cursor points to the keyframe of the next item in History (relative to the current), when you redo, this cursor points to the keyframe of the current History item.

Rerecord counter

By tradition, all TAS emulators keep track of rerecords used during the creation of a TAS. This number can be used to estimate the labor.

  • The Rerecord counter is stored in the movie (and hence in an fm3 project file too). When creating a new movie (or a new project in Taseditor) the counter is reset to 0.
  • When TASing outside of Taseditor: the counter increments every time the TASer loads a savestate in the Recording mode, since he wants to change the Input on the previously watched segment of the movie. The counter does not increase when the TASer records Input for frames whose events he does not know.
  • When TASing in Taseditor: the counter increments every time the TASer changes the Input of a previously greenzoned segment of the movie. The counter does not increase when the TASer changes Input for frames that are beyond the Greenzone head.
  • Thus in both cases the emulator keeps track of how many times the TASer changed the known future. The counter does not increase when the TASer changes the future blindly, i.e. before watching the game events occurring at the frames he edits.
  • In old emulators the counter increases immediately when loading the savestate in the Recording mode, even before the TASer changes Input. Because of this, it is possible that the user repeatedly presses a load savestate hotkey (e.g. F1), and each time the counter will increase. In Taseditor the counter increments only when truncating the Greenzone, regardless of the navigation method. Therefore, at the first press of the F1 the counter will increase only if the branch of this Bookmark is different from the current movie, and the difference begins from a greenzoned frame. And the second press of the F1 will not increase the counter, because now the Bookmark branch does not differ from the current movie, and no Input change is happening.

Modifier keys system

For a more intuitive keyboard control, Taseditor enforces a strict separation of modifier keys functions:

  • Shift is associated with the movie Output , and specifically with the Playback cursor. Key combinations involving this key usually control the Playback cursor. If you quickly press Shift twice, the Piano Roll will automatically scroll to the Playback cursor.
  • Ctrl is associated with the movie Input , and specifically with the Selection cursor. Key combinations involving this key usually control the Selection. If you quickly press Ctrl twice, the Piano Roll will automatically scroll to the Selection cursor.
  • Alt is associated with patterns and alternating sequences, in particular, with gaps in these sequences.

Patterns

Prepared sequence of button states for a single button. See more in Advanced Features .

  • Patterns are stored in an external text file in a format that can be edited in Notepad. The file format should be described in the file itself.
  • Each pattern must have its name, which will appear in the list of patterns.
  • Patterns are loaded from the file at the time of launching the TAS Editor.
  • TAS Editor 1.0 has no built-in Pattern editing, as the format is very simple and that feature is not too much in demand.
  • Input, Markers and even Selection can be set by pattern.
  • When you set a pattern, the current lag log can be taken into account or disregarded. More: Program Customization .

Crossing gaps

This is an additional method of quick navigation through the Piano Roll contents. It helps to visually track long sequences of a single button or Markers. Also it allows to move from a Bookmark to another Bookmark.

  • Crossing gaps is the process of scrolling the Piano Roll vertically, triggered by rolling the mouse wheel while holding down Alt. The speed of rolling the wheel is irrelevant here, because the actual amount of scrolling is calculated individually based on the state of the Piano Roll cell near the mouse cursor. So only the direction of the wheel rolling is relevant (up or down).
  • Crossing gaps implies that the user wants to find the cell at a distance of more than one frame from the cell under the mouse cursor (otherwise there is no reason to use this feature, because you could simply move your mouse right above).
  • Thus, when the mouse wheel is scrolled up, this feature memorizes the value of the cell above the cell under the mouse cursor. Then it searches for a cell whose value is not equal to a given value. Search goes upwards from the cell above the cell under the mouse. If such a cell is successfully found, the Piano Roll scrolls up so that the mouse cursor is now pointing to the found cell. If the search reached the movie beginning, and the cell was not found, the Piano Roll does not scroll.
  • Similarly, when the mouse wheel is rolled down, this feature memorizes the value of the cell following the cell under the mouse. Then it searches for a cell whose value is not equal to the value. Search goes down from the cell following the cell under the mouse.
  • The memorized value is of a boolean type. E.g. the search considers all icons to have the same value (true), and all empty cells also have the same value (false).

Compact saving

The Taseditor project file is primarily designed to save the exact snapshot of the workflow.

In order to use the same format for file sharing, the user should be able to selectively save data to the file. When you open such an fm3 file, the missing data is be replaced with default data.

For details, see Advanced Features and FM3 Format .

Autosave

As any office document, Taseditor project should to be saved to disk from time to time, even if you do not plan to exit the program. However, TASers are not accustomed to such habits, so it makes sense to save the project automatically, allowing the user to customize or disable this feature.

For details, see Program Customization .

Planned ideas

Output Log

This is the next stage of evolution of the Memory Watch tool. It's intended to watch the game data in a dynamic way, not just static. Similarly to the Lag Log, this feature will make analyzing the game Output easier and more accurate.

  • It is a significantly redesigned ListView, whose vertical scrolling is synchronized with the Piano Roll scrolling. Its height is equal to the height of the Piano Roll, and the number of rows is always equal to the number of Piano Roll lines. The number of columns depends on the needs of the user.
  • The user can flexibly change the width of the List by dragging the narrow border between it and the Piano Roll, thus changing the Piano Roll width as well, so their total width is always the same. You can also swap the List and the Piano Roll, or even completely disable the display of the Output Log. When you disable the Log display, the Piano Roll extends to take up the free up space, just as in TAS Editor 1.0. Note that hiding the Log does not disable logging of data.
  • The List Header displays the names of logged cells. You can add and remove columns, change names, change places and change the columns width. When you create a new project, the Output Log has no columns, and, accordingly, nothing is logged.
  • The rows of the List display the values of the cells. The values are saved from the game state on the appropriate movie frame. The List lines are painted with the same colors as the corresponding Piano Roll lines. When you select a line in the Piano Roll, the respective Log lines are selected too.
  • In addition to the RAM cells, it's necessary to implement Lua variables logging. For example, to provide Lua-scripts with a read/write-access to a dozen of Taseditor's int-variables and allow the user to log any variable from the dozen.
  • In addition, in the future a column with screenshots of the game (or selected rectangular area of the game screen) should be added. The displayed size of the screenshots will depend on the current width of the screenshots column, and as a result, the screenshots will not appear on each line of the Log, but on every few lines, even though the screenshot capturing is done every frame.
  • All logged data is stored in the Greenzone, along with the Lag Log. When adding a RAM cell, an automatic filling of the entire column is possible (Taseditor runs through all Greenzone savestates, unpacks them and takes the value of the saved copy of RAM). When you add a Lua variable, the cell values are unknown (blank cells in the list), and to fill them you need to re-emulate the movie with the Lua-script running.
  • When truncating the Greenzone, the old data that has become outdated will not be removed, but will appear in less bright color, until the new data takes its place. Also, when savestates are removed from the Greenzone tail, the Log data remains intact and is shown in the normal color.
  • It should allow flexible coloring of cells, for example, highlighting the same values in the Selection, highlighting the desired values, automatic color change when the value changes, automatic indication when certain value is hit, etc.
  • Lua scripts may read any Greenzone data using Taseditor API.
  • The accelerators Shift + Right / Shift + Left will now scroll horizontally not the Piano Roll, but the Output Log. Scrolling is done by whole columns.
  • It is also necessary to implement the new methods of navigation through the movie, depending on the cells values. For example, by using the Alt key and the wheel you can cross gaps in the List to find the nearest unequal or equal value.

Minimap

Graphically displays the entire movie in TAS Editor window – Greenzone, Lag, Playback cursor, Selection, Markers, Bookmarks, Hot Changes, highlighted Output Log values, etc. Provides the user with an instant image of the current project, which lacks details but completely fits on the screen. Also improves navigation.

  • The Minimap is a rectangular bitmap canvas, whose height is equal to the height of the Piano Roll, and the width is 30 pixels (plus 10px for Bookmark icons). Can be positioned to the left or right from the Piano Roll and the Output Log.
  • The "View" menu item allows the user to customize the elements displayed on Minimap (set a tick near the desired items). You can also entirely disable the display of Minimap.
  • The Minimap does not store any data of the project. It is automatically redrawn in the specified interval of time (by default, once per second).
  • Markers are displayed as horizontal yellow lines on the left half of the Minimap. Each Marker line has the height of at least one pixel, so the Markers are not lost even on a small-scale Minimap (when the movie has a lot more frames than the height of the Minimap in pixels). The line width is 9px.
  • Hot Changes are displayed as horizontal lines of the corresponding color on the right side of the Minimap. Each line has the height of at least one pixel. The line width is 9px.
  • Bookmarks are displayed by corresponding icons to the left from the Minimap, and they take additional 10px. You can click these icons with left or right mouse button, the effect will be similar to clicking on the icon in the Branches Tree.
  • When the mouse cursor hovers over the Minimap, it displays the rectangular magnifying glass.
  • Left-click on the Minimap = instant scrolling of visible area of the Piano Roll to that place. You can then drag the visible area up/down by holding the right button.
  • Shift + left-click, or just right-click on the Minimap = Playback cursor navigation. You can then drag the Playback cursor by holding the right button.

Virtual Joypad

An alternative way to enter Input. Very similar to modifying Input by clicking the Piano Roll Header, but is more visual and intuitive.

  • The Virtual Joypad is a non-modal pop-up resizable window. Contents of the window are automatically resized when the window is resized.
  • The Virtual Joypad window appears under the mouse cursor when you right-click in the Piano Roll on the selected Input or on Input under the Playback cursor. In the settings you can disable the appearance of the Virtual Joypad under the cursor when you right click. Then you can leave the window in a convenient place on the desktop and move the mouse cursor back and forth from the Piano Roll to the Virtual Joypad.
  • By the window background color you can determine whether the Virtual Joypad currently displays the Input state in the Selection (dark blue), or under the Playback cursor (light-blue).
  • When the mouse cursor is moved out of the Virtual Joypad window, this window is either hidden automatically (if the "Hide on mouse leave" is checked) or left in place.
  • When you press the left mouse button over the inactive area of the window, the window dragging starts.
  • When you right-click anywhere in the window, it hides.
  • Various controls can be located inside the window – e.g. the buttons that correspond to the real joypad buttons. The buttons layout corresponds to the real prototype. By the buttons look you can determine whether the corresponding button in the Selection is pressed, released or partially pressed (this is for cases when more than one frame is Selected).
  • The window contents are automatically updated every time the Input is changed, or Selection is changed and the Virtual Joypad shows the Input in the Selection.
  • The Virtual Joypad reflects only the state of the single controller – the current controller, selected by a radiobutton in the Recorder section.
  • When you click on a button, it changes the Input of the current joypad. Pressed button becomes released, and released or partially pressed becomes pressed. The Input of all the selected frames or the frame under the Playback cursor changes accordingly.
  • In addition to the normal Input buttons, the Virtual Joypad may contain several macro-buttons. A click on a macro button will be similar to a few clicks on different normal buttons. This will allow to change the Input in the Selection even faster than before, for example, instead of three clicks on Up, Right, and B buttons, you can do one click on Macro1.
  • If you hold down Alt before clicking a Virtual Joypad button or a macro button, the Input will be set by pattern.
  • After implementing the Virtual Joypad we can change the principle of clicking on the Piano Roll Header. Instead of changing the Input, the click on the Header will select the appropriate columns in the Piano Roll.

Selection improvement

TAS Editor 1.0 architecture is not designed to support the selection of Piano Roll columns, but in some situations it may be useful in TASing. For example, to clear the Input of the first joypad without clearing the second joypad Input. Or to shift the Input for one buttons without moving the rest buttons.

Besides, it's necessary to improve the process of painting the Selection, so that users will see the Piano Roll line color under the translucent Selection.

  • Selecting columns should be done like selecting rows – when you left-click on the Header of the corresponding Piano Roll column, the column is selected, and all other columns are deselected. If you hold down Ctrl before clicking the button, Selection of the rest columns will not disappear. If you hold down Shift, you will select the range of columns from the previous click place. If you hold down Alt, the columns selection will be set by pattern. And of course after clicking you can hold the left mouse button and stretch the selection horizontally.
  • Only Input columns can be selected. The Markers depend on the "Bind Markers to Input" setting.
  • Selected columns are colored in the Header by blue background in the appropriate cells.
  • The absence of selected columns is equivalent of "all columns are selected".
  • When the selected lines are displayed, the Input cells of unselected columns are drawn with alpha ~0.4, whereas the cells of the selected columns have alpha ~0.7.
  • In the column of frame numbers, the selected lines have alpha ~0.4, when the Markers are detached, and ~0.7, when the Markers are attached.
  • Splicer section displays not only the number of the selected lines (rows), but the number of selected columns (columns).
  • When you Copy, only the Input from the selected columns is copied to the Clipboard, and it appears there as a rectangular table with no gaps between columns. This allows the user to change the selected columns and insert some buttons in place of the other buttons.
  • When the SELECTION object is initialized (i.e. at Taseditor startup or project creation), Selection is reset to "no selection of columns".
  • If you change the order of columns or hide/disclose them, the Selection is reset to "no selection of columns".
  • When recording, the Input is filtered to match columns selection. Unselected columns will not change, even if the user records a different button state for the column.
  • Columns selection is also saved in the project file.
  • This innovation does not affect the Selection History. Changing the Selection of columns is not saved in the Selection History, because there's no need to navigate through column selections history.

Columns tweaking

In TAS Editor 1.0 the Piano Roll columns have fixed width. The number and order of the columns are also fixed. There's also no columns dedicated to hardware commands (reset, insert disk, etc.), because these commands are rarely used. However, porting Taseditor to another emulator will increase the number of columns (e.g. PSX needs to display columns for 14 buttons), so it's necessary to give the user the ability to customize them.

  • Since this setting is typically done only once (when you start using the program), it does not have to be done directly in the Piano Roll, it should be configured in a separate window called from the "Config" menu.
  • The ability to display any Input columns, including the command columns.
  • Ability to hide any columns. However, each joypad must be represented by at least one button column (but if the user has configured project to 1P mode, the second joypad columns in any case will not be displayed).
  • The ability to change the order of the columns.
  • When you Copy to the Clipboard, only the abstract values like true/false are copied. So if after copying you reorder the columns and insert the Input from the Clipboard to the same place, the real movie Input may change (because button columns are swapped).
  • The ability to change the width of columns. For platforms with many buttons (like PC) it's useful to shrink the width of columns down to a few pixels, so that a lot of columns can fit the screen.
  • The possibility to restore the default settings (those recommended by the author) by one click.
  • All settings are saved in config.
  • Все настройки сохраняются при выходе.

Rerecords heatmap

Stores and displays the statistics about "changes done after watching" (rerecords). It may be useful to identify the difficult places in the movie.

  • Stores an array of int, one entry for each movie frame (including the frames beyond the current Input). The value corresponds to the number of Greenzone truncations at the frame.
  • Saves and loads the data from the project file.
  • As a canvas for displaying the Heatmap we can use the Minimap canvas. There's no point to constantly see the Heatmap during TASing, so you can just occasionally (e.g. at the end of every day) toggle the Minimap to the Heatmap display mode and evaluate the work.
  • Since this feature is not as much operational as aesthetic, we'll need to think over the Heatmap drawing algorithm, so that it is not only informative but also beautiful.

Other stuff

  • Separate History Log for the Bookmark Set operations (Alt + Z and Alt + Y), so the user will be able to undo the Input/Markers changes without undoing Bookmarks and vice versa.
  • Work with movies starting from savestate.
  • Work with multiple emulated games simultaneously (for Multi-TAS projects).
  • Lua API improvements.
  • Support for multi-touch controls.
  • Think out the concept of the background greenzoning (how exactly it corresponds to TASing specifics).

Supporting platforms other than NES

If Taseditor gains popularity among TASers, its availability needs to be expanded to all emulated platforms.

  • Think about the ways to display and change an analog Input using the Piano Roll. The Virtual Joypad partially solves this problem, but the user should also be able to quickly and easily create an analog Input with the mouse. For example, set the "stick tilt" value for one frame and then stretch it to many frames. Also, remember the value of the newly cleared cell and offer it when drawing by mouse. The cells should be able to display not only a single character, but a fixed-point number from -1.0 to +1.0. By double-clicking on a cell you can type the exact value of this number with the keyboard. While holding Ctrl, you can stretch the value of the cell by holding the left button and moving the mouse left/right or up/down. A single column can correlate to only single coordinate axis (thus the analog stick requires two columns in Piano Roll).
  • The Virtual Joypad should provide the ability to draw an envelope for a frame range. It is also necessary to remake the format of patterns file, so that they can represent the sequence of "voltage levels", including relative values (for example, increase in a parabola, where the initial and final values are taken from the initial and final frame of the selected range).
  • Transition to a 64-bit platform is highly desirable, because the Greenzone size is going to increase dramatically when storing savestates for more advanced consoles. 2GB of RAM will not be enough for Taseditor 2.0.

Created with the Personal Edition of HelpNDoc: Produce Kindle eBooks easily


Implementation

TAS Editor Inside ››

Implementation

At first the TAS Editor was based on the codebase of experimental tool named TASEdit, using FCEUX 2.1.5 as a kick-start.

The premise of TASEdit was to build an input editor (like TAS Movie Editor) into emulator, so that the delay between editing and checking results would greatly shrink. Since there was no research done on typical behaviors in TASing process, the concept was vague and the code wasn't scalable. Thus, soon after formulating the new vision of the editing tool the code of TAS Editor was fully rewritten to make adding new features easier.

The premise of TAS Editor is to create a tool that is more handy than traditional rerecording tools, not just for Input editing/splicing, but also for Input creation and, most importantly, polishing (optimizing).

The following architecture of TAS Editor was designed according to author's notion of a methodical TASing and of features needed for such TASing.

TAS Editor modules (classes)

taseditor.cpp

Main – Main gate between emulator and Taseditor

[single instance]

  • the point of launching TAS Editor from emulator
  • the point of quitting from TAS Editor
  • regularly (at the end of every frame) updates all modules that need regular update
  • implements operations of the "File" menu: creating New project, opening a file, saving, compact saving, import, export
  • handles some FCEUX hotkeys

taseditor_window.cpp

Window – User Interface

[single instance]

  • implements all operations with TAS Editor window: creating, redrawing, resizing, moving, tooltips, clicks
  • subclasses all buttons and checkboxes in TAS Editor window GUI in order to disable Spacebar key and process Middle clicks
  • processes OS messages and sends signals from user to TAS Editor modules (also implements some minor commands on-site, like Greenzone capacity dialog and such)
  • switches off/on emulator's keyboard input when the window loses/gains focus
  • on demand: updates the window caption; updates mouse cursor icon
  • updates all checkboxes and menu items when some settings change
  • stores info about 10 last projects (File->Recent) and updates it when saving/loading files
  • stores resources: window caption, help filename, size and other properties of all GUI items

bookmarks.cpp

Bookmarks – Manager of Bookmarks

[single instance]

  • stores 10 Bookmarks
  • implements all operations with Bookmarks: initialization, setting Bookmarks, jumping to Bookmarks, deploying Branches
  • saves and loads the data from a project file. On error: resets all Bookmarks and Branches
  • implements the working of Bookmarks List: creating, redrawing, mouseover, clicks
  • regularly updates flashings in Bookmarks List
  • on demand: updates colors of rows in Bookmarks List, reflecting conditions of respective Piano Roll rows
  • stores resources: save id, ids of commands, labels for panel, gradients for flashings, id of default slot

branches.cpp

Branches – Manager of Branches

[single instance]

  • stores info about Branches (relations of Bookmarks) and the id of current Branch
  • also stores the time of the last modification (see fireball) and the time of project beginning (see cloudlet)
  • also caches data used in calculations (cached_first_difference, cached_timelines)
  • saves and loads the data from a project file. On error: sends warning to caller
  • implements the working of Branches Tree: creating, recalculating relations, animating, redrawing, mouseover, clicks
  • on demand: reacts on Bookmarks/current Movie changes and recalculates the Branches Tree
  • regularly updates animations in Branches Tree and calculates Playback cursor position on the Tree
  • stores resources: coordinates for building Branches Tree, animation timings

bookmark.cpp

Bookmark – Single Bookmark data

  • stores all info of one specific Bookmark: movie snapshot, a savestate of 1 frame, a screenshot of the frame, a state of flashing for this Bookmark's row
  • saves and loads the data from a project file. On error: sends warning to caller
  • implements procedure of "Bookmark set": creating movie snapshot, setting key frame on current Playback position, copying savestate from Greenzone, making and compressing screenshot, launching flashing animation
  • launches respective flashings for "Bookmark jump" and "Branch deploy"

snapshot.cpp

Snapshot – Snapshot of all edited data

  • stores the data of specific snapshot of the movie: InputLog, LagLog, Markers at the moment of creating the snapshot, keyframe, start and end frame of operation, type of operation and description of the snapshot (including the time of creation)
  • also stores info about sequential recording/drawing of input
  • streamlines snapshot creation: copying Input from movie data, copying LagLog from Greenzone, copying Markers from Markers Manager, setting time of creation
  • streamlines restoring Markers data from snapshot
  • saves and loads the data from a project file. On error: sends warning to caller

inputlog.cpp

InputLog – Log of Input

  • stores the data about Input state: size, type of Input, Input Log data (commands and joysticks)
  • optionally can store map of Hot Changes
  • implements InputLog creation: copying Input, copying Hot Changes
  • implements full/partial restoring of data from InputLog: Input, Hot Changes
  • implements compression and decompression of stored data
  • saves and loads the data from a project file. On error: sends warning to caller
  • implements searching of first mismatch comparing two InputLogs or comparing this InputLog to a movie
  • provides interface for reading specific data: reading Input of any given frame, reading value at any point of Hot Changes map
  • implements all operations with Hot Changes maps: copying (full/partial), updating/fading, setting new hot places by comparing two InputLogs

laglog.cpp

LagLog – Log of Lag occurrence

  • stores the frame-by-frame log of lag occurrence
  • implements compression and decompression of stored data
  • saves and loads the data from a project file. On error: sends warning to caller
  • provides interface for reading and writing log data

markers.cpp

Markers – Snapshot of Markers state

  • stores the data about Markers state: array of distributing Markers among movie frames, and array of Notes
  • implements compression and decompression of stored data
  • saves and loads the data from a project file. On error: sends warning to caller
  • stores resources: max length of a Note

popup_display.cpp

Popup display – Manager of popup windows

[single instance]

  • implements all operations with popup windows: initialization, redrawing, centering, screenshot decompression and conversion
  • regularly inspects changes of Bookmarks Manager and shows/updates/hides popup windows
  • on demand: updates contents of popup windows
  • stores resources: coordinates and appearance of popup windows, timings of fade in/out

history.cpp

History – History of movie modifications

[single instance]

  • stores array of History items (snapshots, backup_bookmarks, backup_current_branch) and pointer to current snapshot
  • saves and loads the data from a project file. On error: clears the array and starts new history by making snapshot of current movie data
  • on demand: checks the difference between the last snapshot and current movie, and makes a decision to create new point of rollback. In special cases it can create a point of rollback without checking the difference, assuming that caller already checked it
  • implements all restoring operations: undo, redo, revert to any snapshot from the array
  • also stores the state of "undo pointer"
  • regularly updates the state of "undo pointer"
  • regularly (when emulator is paused) searches for uncompressed items in the History Log and compresses first found item
  • implements the working of History List: creating, redrawing, clicks, auto-scrolling
  • stores resources: save id, ids and names of all possible types of modification, timings of "undo pointer"

piano_roll.cpp

Piano Roll – Piano Roll interface

[single instance]

  • implements the working of Piano Roll List: creating, redrawing, scrolling, mouseover, clicks, drag
  • regularly updates the size of the List according to current movie input
  • on demand: scrolls visible area of the List to any given item: to Playback Cursor, to Selection Cursor, to "undo pointer", to a Marker
  • saves and loads current position of vertical scrolling from a project file. On error: scrolls the List to the beginning
  • implements the working of Piano Roll List Header: creating, redrawing, animating, mouseover, clicks
  • regularly updates lights in the Header according to button presses data from Recorder and Alt key state
  • on demand: launches flashes in the Header
  • implements the working of mouse wheel: List scrolling, Playback cursor movement, Selection cursor movement, scrolling across gaps
  • implements context menu on Right-click
  • stores resources: save id, ids of columns, widths of columns, tables of colors, gradient of Hot Changes, gradient of Header flashings, timings of flashes, all fonts used in TAS Editor, images

selection.cpp

Selection – Manager of selections

[single instance]

  • contains definition of the type "Set of selected frames"
  • stores array of Sets of selected frames (History of selections)
  • saves and loads the data from a project file. On error: clears the array and starts new history by making empty selection
  • constantly tracks changes in selected rows of Piano Roll List, and makes a decision to create new point of selection rollback
  • implements all selection restoring operations: undo, redo
  • on demand: changes current selection: remove selection, jump to a frame with Selection cursor, select region, select all, select between Markers, reselect clipboard
  • regularly ensures that selection doesn't go beyond curent Piano Roll limits, detects if selection moved to another Marker and updates Note in the lower text field
  • implements the working of lower buttons << and >> (jumping on Markers)
  • also here's the code of lower text field (for editing Marker Notes)
  • stores resource: save id, lower text field prefix

editor.cpp

Editor – Tool for editing

[single instance]

  • implements operations of changing Input: toggle input in region, set input by pattern, toggle selected region, apply pattern to input selection
  • implements operations of changing Markers: toggle Markers in selection, apply patern to Markers in selection, mark/unmark all selected frames
  • stores Autofire Patterns data and their loading/generating code
  • stores resources: patterns filename, id of buttonpresses in patterns

splicer.cpp

Splicer – Tool for montage

[single instance]

  • implements operations of mass-changing input: copy/paste, cloning, clearing region, insertion and deletion of frames, truncating
  • stores data about the selection used in last "Copy to Clipboard" operation
  • regularly checks the state of current selection and displays info on GUI, also displays info about input in Clipboard
  • when launching TAS Editor, it checks Clipboard contents
  • stores resources: mnemonics of buttons, texts for selection/clipboard info on GUI

taseditor_config.cpp

Config – Current settings

[single instance]

  • stores current state of all TAS Editor settings
  • all TAS Editor modules can get or set any data within Config
  • when launching FCEUX, the emulator writes data from fceux.cfg file to the Config, when exiting it reads the data back to fceux.cfg
  • stores resources: default values of all settings, min/max values of settings

playback.cpp

Playback – Player of emulation states

[single instance]

  • implements the working of movie player: show any frame (jump), run/cancel seekng. pause, rewinding
  • regularly tracks and controls emulation process, prompts redrawing of Piano Roll List rows, finishes seeking when reaching target frame, animates target frame, makes Piano Roll follow Playback cursor, detects if Playback cursor moved to another Marker and updates Note in the upper text field
  • implements the working of upper buttons << and >> (jumping on Markers)
  • implements the working of buttons < and > (frame-by-frame movement)
  • implements the working of button || (pause) and middle mouse button, also reacts on external changes of emulation pause
  • implements the working of progressbar: init, reset, set value, click (cancel seeking)
  • also here's the code of upper text field (for editing Marker Notes)
  • stores resources: upper text field prefix, timings of target frame animation, response times of GUI buttons, progressbar scale

greenzone.cpp

Greenzone – Access zone

[single instance]

  • stores array of savestates, used for faster movie navigation by Playback cursor
  • also stores LagLog of current movie Input
  • saves and loads the data from a project file. On error: truncates Greenzone to last successfully read savestate
  • regularly checks if there's a savestate of current emulation state, if there's no such savestate in array then creates one and updates lag info for previous frame
  • implements the working of "Auto-adjust Input according to lag" feature
  • regularly runs gradual cleaning of the savestates array (for memory saving), deleting oldest savestates
  • on demand: (when movie input was changed) truncates the size of Greenzone, deleting savestates that became irrelevant because of new input. After truncating it may also move Playback cursor (which must always reside within Greenzone) and may launch Playback seeking
  • stores resources: save id, properties of gradual cleaning, timing of cleaning

recorder.cpp

Recorder – Tool for input recording

[single instance]

  • at the moment of recording movie input (at the very end of a frame) by emulator's call the Recorder intercepts input data and applies its filters (multitracking/etc), then reflects input changes into History and Greenzone
  • regularly tracks virtual joypad buttonpresses and provides data for Piano Roll List Header lights. Also reacts on external changes of Recording status, and updates GUI (Recorder panel and Bookmarks/Branches caption)
  • implements input editing in Read-only mode (ColumnSet by pressing buttons on virtual joypad)
  • stores resources: ids and names of multitracking modes, suffixes for TAS Editor window caption

markers_manager.cpp

Markers_manager – Manager of Markers

[single instance]

  • stores one snapshot of Markers, representing current state of Markers in the project
  • saves and loads the data from a project file. On error: clears the data
  • regularly ensures that the size of current Markers array is not less than the number of frames in current input
  • implements all operations with Markers: setting Marker to a frame, removing Marker, inserting/deleting frames between Markers, truncating Markers array, changing Notes, finding frame for any given Marker, access to the data of Snapshot of Markers state
  • implements full/partial copying of data between two Snapshots of Markers state, and searching for first difference between two Snapshots of Markers state
  • also here's the code of searching for "similar" Notes
  • also here's the code of editing Marker Notes
  • also here's the code of Find Note dialog
  • stores resources: save id, properties of searching for similar Notes

taseditor_lua.cpp

Lua – Manager of Lua features

[single instance]

  • implements logic of all functions of "taseditor" Lua library
  • stores the list of pending input changes
  • on demand: (from FCEUX Lua engine) updates "Run function" button
  • stores resources: ids of joypads for input changes, max length of a name for applychanges(), default caption for the "Run function" button

taseditor_project.cpp

Project – Manager of working project

[single instance]

  • stores the info about current project filename and about having unsaved changes
  • implements saving and loading project files from filesystem
  • implements autosave function
  • stores resources: autosave period scale, default filename, fm3 format offsets

Emulator modifications

Taseditor needs the following modifications to be applied to an emulator code.

Main/Window:

  • call Taseditor's update() function after every emulated frame and when emulation is paused, no less than 20 times per second (necessary for smooth animations and controls in TAS Editor window)
  • dispatch OS messages to Taseditor window, including accelerator table commands
  • if emulator doesn't make use of mouse wheel, it should resend WM_MOUSEWHEEL to Taseditor, same with middle mouse clicks on emulator's own window
  • on exit: emulator should ask Taseditor, so it can check unsaved changes in current project and allow user to save before quitting. If the askSave() function returns false, the exit should be cancelled (means that user chose "Cancel")

Movie:

  • there should be an interface for full control over the current movie data (creating/reading/writing/any modification). The movie should be the last layer between user's input and emulated game, which means that the game should not take input from virtual pads, only from movie data. An alternative (FCEUX example) would be to always sync changes into virtual pads every time the movie data changes. Either way, Taseditor interacts with the game by reading and modifying movie data and doesn't poll virtual pads. The Piano Roll displays current movie data and edits Input of current movie data only
  • in Recording mode: at the very beginning of a frame (right after the Input for the frame is written into current movie data) emulator should call Taseditor's Recorder function (and Recorder may change the movie data)

Input:

  • provide an interface for knowing which buttons are currently held (it's necessary for the Piano Roll Header)
  • hardware commands (Reset/Power/etc) should not be executed immediately after user invokes them, they should work as well as buttons input from virtual pads, meaning that when Taseditor is engaged it may either allow or prohibit the commands. In fact, when Taseditor is engaged and is not Recording, user should not be able to even invoke hardware commands

Output:

  • provide read access to current state of lag indicator (needed at the end of every frame)
  • have public function for storing current screenshot in RAM (also screenshot with Lua HUD)

SaveStates:

  • have public function for making a savestate in RAM and function for loading the state from RAM array
  • savestates must restore the game state precisely
  • saving and loading should not take too much time, because the Greenzone automatically creates a new savestate for every frame, which should be transparent for user
  • savestates should be stored in compressed form, so that they don't take too much space, because for a comfortable work in Taseditor the Greenzone should have at least 1000 savestates for nearby frames
  • Greenzone savestates should not store current movie data (that would be a waste of space)

Config:

  • on emulator start: emulator should load taseditor_config data from the common settings file. If the file is not found, no changes should be made to taseditor_config (it will have its default settings)
  • on emulator exit: save taseditor_config data to the common settings file

Lua engine:

  • add support for taseditor library. The core of each function is implemented by Taseditor, but emulator should take parameters from Lua stack and send them to respective function of Taseditor's Lua gate, then receive returned data and push it into Lua stack
  • add support for Manual function and Auto function
  • notify Taseditor about changing the Manual function status (registered/re-registered/empty) so that it can change the appearance of the "Run function" button

Replay:

  • emulator should be able to replay Taseditor project files as usual movie files, ignoring the additional data at the end of the file
  • since Taseditor project file can be huge, emulator shouldn't load it into memory when opening
  • emulator should be able to distinguish between a normal movie and a Taseditor project file. If it's a project file: when user tries to rerecord, emulator should refuse and suggest launching TAS Editor instead. If user agrees, emulator should send Taseditor the reference to the project file

Other:

  • emulator must be stable and deterministic. Desyncs will totally break Playback cursor navigation and make TASing unfeasible
  • it's recommended to implement all the points mentioned in Mistake-proofing that are related to emulator modification. In particular, Taseditor should be able to change certain settings, and user shouldn't be able to change them while Taseditor is engaged
  • good emulation speed is necessary for adequate Turbo seeking feature. Also there should be an option to mute sound when turbo is on.

Created with the Personal Edition of HelpNDoc: Single source CHM, PDF, DOC and HTML Help creation


Mistake-proofing

TAS Editor Inside ››

Mistake-proofing

This page lists many small details of implementation that improve interaction between user and the program. All these points must be considered when porting Taseditor to other platforms.

  • When the user closes the emulator, emulator sends a request to Taseditor in order to allow it to close the project first. If the project contains unsaved data, Taseditor shows the Yes/No/Cancel dialog. The user can either save the changes, or save none of them, or cancel the attempt to close the emulator.
  • When playing back an fm3 project outside Taseditor (like a regular movie), the user can switch the emulator to Recording mode and try rerecording. In this case, the emulator tells the user that current movie is a Taseditor project, and suggests to start editing it. In case of refuse, emulator disables the Recording mode and resumes playing back the project movie. In case of agreement, emulator sends a signal to Taseditor, and at the end of the current frame Taseditor will launch and load the currently played project.
  • When a ROM is loaded into emulator, the user can launch Taseditor at any moment. If he opens the Taseditor window while playing or recording a movie, Taseditor will automatically create a nameless project containing this movie Input. But if the movie is starting from a savestate, Taseditor will display a warning about not supporting such movies and then create a blank project.
  • While the project has no name, autosave function doesn't work.
  • When saving a nameless project, Taseditor suggests the current ROM name as a name for the fm3 project, with the extension changed to .fm3.
  • Since the FM3 format is a superstructure over the FM2 format, the user can open fm2 files just like Taseditor projects, using the "Open TAS Editor Project" dialog and choosing the filter "All Files (*.*)". When opening fm2 files, Taseditor additionally informs the user about it with the Yes/No dialog. The user can either load the fm2 file as a new project or cancel the loading.
  • After opening an fm2 file or a corrupted fm3 file, the project is considered nameless, even though the TAS Editor window caption displays the name of the loaded file. At the first saving attempt (Ctrl + S) Taseditor will bring the SaveAs dialog, where the loaded fm2/fm3 file name will be suggested as a name for the project. The user can either save the project with this name or change the name. This way Taseditor draws your attention to the fact that the new project significantly differs from the file that exists on the disk under the same name.
  • FM3 projects store the version number of the FM3 format used when saving the file. Different versions can be totally or partially incompatible with each other. If the loaded project version doesn't match the currently supported one, Taseditor shows the Yes/No/Cancel dialog. The user can either resume his attempt to load the whole project (not recommended), or load only the Input from the FM2 data (recommended), or cancel loading.
  • FM2 format (and therefore fm3 too) stores the MD5 checksum of the ROM used when creating the movie/project. When loading a project, Taseditor compares the current ROM checksum with the project's one, and if they don't match, brings the Yes/No dialog, displaying the original and the current ROM names. The user can resume loading or cancel it. Later, when saving this project, Taseditor will notice the checksum mismatch again and suggest replacing the ROM name and the checksum in the file before saving. The user can either approve the replacing, or save the project with the old name and checksum, or cancel the saving.
  • When loading a corrupted project file, Taseditor tries the best of its ability to prevent emulator crash. If an error is found in the middle of loading, the further loading stops and the rest data is replaced with the default data. Particularly, if the error occurred while loading the Greenzone, the project is left with only the Greenzone frames that were successfully pulled out of the file, the rest frames will be pale. Project loading error messages are logged into the FCEUX Message Log.
  • When loading a project, Taseditor respects current settings of "Greenzone capacity" and "Undo levels". For example, if while saving a project the Greenzone capacity was 5000, but when loading the project the Greenzone capacity is 3000, some frames will be skipped when loading. It's necessary so that a project saved on a more powerful computer can be opened on a less powerful one, that doesn't have enough memory.
  • When launching, Taseditor loads the data about patterns from the taseditor_patterns.txt file. If this file cannot be opened (fer example, it was removed), Taseditor creates a small set of default patterns, in order to keep the Patterns menu filled.
  • Savestates used by the Greenzone differ from regular savestates a bit. They don't contain movie data, because it's useless information for the Greenzone purposes. Besides, they are always compressed, in order to save memory.
  • If after a Delete or Lua Change operation the user effectively removes all Input from the movie, Taseditor will create one blank frame in the movie beginning.
  • When user is selecting a range of frames by stretching, it's still possible to use hotkeys with the other hand. To avoid conflict, during DRAG_MODE_SELECTION and DRAG_MODE_DESELECTION some functions related to changing the Selection will not work:
  • clearSelection()
  • selectAll()
  • selectBetweenMarkers() – Ctrl + A
  • selection.undo() – Ctrl + Q
  • selection.redo() – Ctrl + W
  • reselectClipboard() – Ctrl + B
  • selection.Transpose() – Ctrl + Up, Ctrl + Down, Ctrl + Home, Ctrl + End
  • selection.JumpPrevMarker() – Ctrl + Page Up
  • selection.JumpNextMarker() – Ctrl + Page Down
  • Since the icon column is rather narrow, the user may accidentally miss clicking it. So when you click the left border of the Piano Roll or a bit to the left from it, Taseditor assumes that was a click on the icons column. As a result, the user doesn't have to precisely aim when he needs to move the Playback cursor or start dragging it.
  • When emulator is paused, the middle mouse button works only under condition that the right button is released. Since the middle button is usually a wheel, the user can accidentally push it while rolling the wheel with the right button held (Playback cursor navigation). As for rolling the wheel with modifier keys held, this is used much less often, so they don't need such protection.
  • Any middleclick over the FCEUX window is sent to Taseditor window. Similarly, the wheel rolling message is sent to Taseditor, when the focus is on the FCEUX window. And the rightclick on the FCEUX window doesn't work at all. Thanks to that, you can use the middle button (the wheel) even when the mouse cursor is over the FCEUX window.
  • Even when the Recording mode is on, Taseditor won't rerecord Input while seeking. Thanks to that, you can safely drag the Playback cursor without disabling the Recording mode.
  • When Taseditor is engaged, the following menu commands are available only when the Recording mode if on and the Playback is not seeking:
  • NES -> Reset
  • NES -> Power
  • NES -> Eject/insert Disk
  • NES -> Switch Disk Side
  • NES -> Insert Coin
  • When Taseditor is engaged, the following FCEUX menu commands are unavailable:
  • File -> Open ROM
  • File -> Close
  • File -> Recent
  • File -> Savestate -> Load State
  • File -> Savestate -> Save State
  • File -> Savestate -> Load State From
  • File -> Savestate -> Save State As
  • File -> Savestate -> Next save slot
  • File -> Savestate -> Previous save slot
  • File -> Savestate -> View save slots
  • File -> Movie -> Recent
  • File -> Movie -> Record Movie
  • File -> Movie -> Play Movie
  • File -> Movie -> Stop Movie
  • Config -> Enable -> Auto-savestates (always off when Taseditor is engaged)
  • Config -> Enable -> Backup Savestates (always off when Taseditor is engaged)
  • Config -> Enable -> Compress Savestates (always on when Taseditor is engaged)
  • Config -> PAL Emulation (set up this before launching Taseditor)
  • Config -> PPU -> New PPU / Old PPU (set up this before launching Taseditor)
  • It's also necessary to ensure that the user can not change the movie synchronization settings while editing the project. So when Taseditor is engaged, the following GUI elements in the "Input Configuration" window are locked:
  • the "Attach four-score" checkbox
  • the "Replace port 2 Start With Microphone" checkbox
  • ListBox for port0
  • ListBox for port1
  • ListBox for port2
  • When Taseditor is engaged, the following hotkeys are not working:
  • Hide Menu Toggle
  • Fastest Speed
  • Save State As...
  • Load State From...
  • Record Movie To...
  • Play Movie From...
  • Stop Movie
  • Toggle Dipswitch – because these commands are not supported by the FM2 format yet
  • Load Last Auto-save
  • View save slots
  • Open ROM
  • Close ROM
  • Undo/Redo Savestate
  • Toggle Fullscreen
  • Hotkeys that change their behavior when Taseditor is engaged:
  • Power
  • Reset
  • Eject or Insert FDS Disk
  • Switch FDS Disk Side
  • Insert Coin
  • Savestate Slot 0 – Savestate Slot 9
  • Save State
  • Save State to Slot 0 – Save State to Slot 9
  • Load State
  • Load State from Slot 0 – Load State from Slot 9
  • Play Movie From Beginning
  • Reload ROM or TAS Editor Project
  • Open TAS Editor
  • Since the Alt and F10 keys are actively used in Taseditor work, their standard behavior (open main menu) is disabled.
  • Since the Spacebar key is used as a hotkey by default, its standard behavior (simulate the click on the currently focused GUI element) is disabled. Also, all GUI elements of the TAS Editor window handle the middleclick message and send it to the Playback, thus the middleclick works independently of the mouse cursor position.
  • Since the context menu on the rightclick at the Piano Roll is not often used, it appears only if the user clicks the selected line in the frame number column (Frame#). In all the rest cases the context menu doesn't appear, instead the rightclick-and-hold at the Piano Roll allows to drag its contents in any direction.
  • Since the right button is often used for the Playback cursor navigation with the wheel, the user is encouraged to click it without caring about the current mouse cursor position. In theory it's possible that the user accidentally rightclicks a Bookmark. To avoid such unintended commands, the Bookmark List and the Branches Tree both require to press and release the right button over the same Bookmark. Also, if between pressing and releasing the user rotated the wheel, the Bookmark won't be changed.
  • The user can jump to a Bookmark with a single click on the desired icon in the Branches Tree. Doing so he expects that after the click the light-blue triangle (the Playback cursor icon) will also jump to the place in the Branches Tree. It is indeed so for Bookmarks that don't contradict with the current timeline, but it's not so for Bookmarks representing alternative strategies. After jumping to the frame of such Bookmark, the Playback cursor will appear on another branch (even though it's on the same frame of the movie). To notify the user about possible misconception, the mouse cursor turns into an arrow with a question mark when the user points to such Bookmarks.
  • While the Branches Tree is transforming, hovering the mouse cursor over its elements doesn't work, because the active element area is constantly moving and running away from the mouse cursor.

Created with the Personal Edition of HelpNDoc: Full-featured Documentation generator


FM3 format

TAS Editor Inside ››

FM3 format

The FM3 format is a simple extension of the FM2 format. FM2 files contain data which is needed for replaying the movie, and FM3 just adds Taseditor's working data to the end of FM2 file.

You can read full specifications of FM2 format in the FCEUX Help and on official site .

Every FM3 consists of 3 parts:

  • Header (as in fm2)
  • Input Log (as in fm2)
  • Taseditor data

Header

The Header is always in ASCII plain text format.

It consists of several key-value pairs (lines of text where all symbols before the first space separator are considered to be the keyword and all symbols after this separator are considered to be the text representation of the value).

Newlines may be \r\n or \n.

If a line starts from "|" (pipe), it means the end of Header and the beginning of Input Log.

The key-value pairs may be in any order, except that the first key must be version.

Value text is always terminated by a newline, which the value text does not include.

The value text is parsed differently depending on the keyword, it can be either integer or string.

Keys with integer value:

(also used for booleans, with a 1 for true and 0 for false)

(the value can be stored as int32)

  • version (required) – the version of the movie file format; for now it is always 3
  • emuVersion (required) – the version of the emulator used to produce the file (e.g. 21060)
  • rerecordCount (optional) – the rerecord count
  • palFlag (bool) (optional) – true if the movie uses PAL timing
  • NewPPU (bool) (optional) – true if the movie uses New PPU
  • FDS (bool) (optional) – true if the movie was recorded on a Famicom Disk System (FDS) game
  • fourscore (bool) – true if a fourscore was used. If fourscore is not used, then port0 and port1 are required
  • port0 – the type of input device attached to the port 0. Supported values are:
  • SI_NONE = 0
  • SI_GAMEPAD = 1
  • SI_ZAPPER = 2
  • port1 – the type of input device attached to the port 1. Supported values are:
  • SI_NONE = 0
  • SI_GAMEPAD = 1
  • SI_ZAPPER = 2
  • port2 (required) – the type of the FCExp port device which was attached. Supported values are:
  • SIFC_NONE = 0
  • binary (bool) (optional) – true if Input Log is stored in binary format. FM2 files usually contain Input in text format, for easy editing and splicing. FM3 files usually contain Input in binary format, to save disk space
  • length (required in FM3) – movie size (number of frames in the input log). If this key is specified and the number is >= 0, the Input Log ends after specified number of records, and any remaining data should not be parsed (because it's Taseditor data). The Header of FM3s always has this keyword, the Header of FM2s doesn't have it.

Keys with string value:

(their values cannot contain newlines)

romFilename (required) – the name of the file used to record the movie

romChecksum (required) – the base64 of the hexified MD5 hash of the ROM which was used to record the movie

comment (optional) – simply a memo. By convention, the author of the movie should be stored in a comment with the subject "author". Example: "comment author AnS"

subtitle (optional) – a message that will be displayed on screen when movie is played back (unless Subtitles are turned off). Right after the word "subtitle" and following space separator there must be an integer value indicating the frame that the subtitle will be displayed. Any remaining text after the integer and following space separator is considered to be the string displayed. Example: "subtitle 100 Level Two" – at frame 100 the words "Level Two" will be displayed on the screen

guid (required) – a unique identifier for a movie, generated when the movie is created. Meaningless in FM3, because all there's no external savestates associated with the project file.

Input Log

The Input Log section consists of movie records either in the form of text lines or in the form of binary data.

Text format:

Every frame of the movie is represented by line of text beginning and ending with a "|" (pipe).

If fourscore is not used, the fields in the line are as follows:

|commands|port0|port1|port2|

Field commands is a variable length decimal integer which is interpreted as a bit field corresponding to miscellaneous input states which are valid at the start of the frame. Current values for this are:

  • bit 0 (number = 1) – Soft Reset
  • bit 1 (number = 2) – Power
  • bit 2 (number = 4) – Eject/Insert Disk
  • bit 3 (number = 8) – Switch Disk Side

The format of port0, port1, port2 depends on which types of devices were attached.

  • SI_NONE: the field must be empty
  • SI_GAMEPAD: the field consists of eight characters which constitute a bit field. Any character other than ' ' (spacebar) or '.' (dot) means that the button was pressed. By convention, the following mnemonics are used in a column to remind us of which button corresponds to which column: RLDUTSBA (Right, Left, Down, Up, Start, Select, B, A)
  • SI_ZAPPER: the field consists of several characters in the following pattern XXX YYY B Q Z
  • XXX: %03d – the X position of the mouse
  • YYY: %03d – the Y position of the mouse
  • B: %01d – 1 if the mouse button is pressed; 0 if not
  • Q: %01d – an internal value used by the emulator's zapper code
  • Z: %d – a variable-length decimal integer; an internal value used by the emulator's zapper code

If fourscore is used, then port0 and port1 are irrelevant and ignored. The input types must all be gamepads, and each input log record must be in the following format:

|commands|RLDUTSBA|RLDUTSBA|RLDUTSBA|RLDUTSBA|port2|

(commands, player 1, player 2, player 3, player 4, port2)

Binary format:

Input Log section starts with a | (pipe).

Every frame of the movie is represented by a record of a fixed length. The length can be determined by the devices on port0 and port1.

The first byte of each record stores "commands" bit field:

  • bit 0 – Soft Reset
  • bit 1 – Power
  • bit 2 – Eject/Insert Disk
  • bit 3 – Switch Disk Side

If fourscore is not used, the remaining bytes in the record depend on which types of devices are attached to port0 and port1:

  • SI_NONE: 0 bytes added to the size of record
  • SI_GAMEPAD: 1 byte added to the size of record. Bits of the byte represent the state of buttons (bit0 = A, bit1 = B, bit2 = Select, bit3 = SStart, bit4 = Up, bit5 = Down, bit6 = Left, bit7 = Right). If the bit is set, respective button is considered to be pressed, if the bit is clear, the button is not pressed
  • SI_ZAPPER: 12 bytes added to the size of record:
  • 1st byte – the X position of the mouse
  • 2nd byte – the Y position of the mouse
  • 3rd byte – 1 if the mouse button is pressed; 0 if not
  • 4th byte – an internal value used by the emulator's zapper code
  • bytes 5-12 (uint64) – an internal value used by the emulator's zapper code

If fourscore is used, then port0 and port1 are irrelevant and ignored. 4 bytes are added to the size of record. The bits of the 1st byte represent the state of buttons of the 1st joypad (bit0 = A, bit1 = B, bit2 = Select, bit3 = Start, bit4 = Up, bit5 = Down, bit6 = Left, bit7 = Right); bits of the 2nd byte represent the state of buttons of the 2nd joypad, and so on.

Taseditor Data

4 bytes | unsigned int32 | FM3 version
4 bytes | unsigned int32 | Saved modules
4 bytes | unsigned int32 | Number of offsets (N = 6)
4 * 6 bytes | pointers | Offsets
??? | stream | MARKERS DATA
??? | stream | BOOKMARKS DATA
??? | stream | GREENZONE DATA
??? | stream | HISTORY DATA
??? | stream | PIANO ROLL DATA
??? | stream | SELECTION DATA

The data starts right after the last record of the Input Log. If there's EOF after the last record, TAS Editor will interpret the file as an FM2 file.

First 4 bytes of Taseditor Data contain the version of the project file format. The first release version of TAS Editor 1.0 saves projects with version = 3.

Next 4 bytes contain bit field that can be used for determining which modules of Taseditor were saved to the FM3 file:

  • bit 0 – Markers were saved
  • bit 1 – Bookmarks were saved
  • bit 2 – entire Greenzone was saved
  • bit 3 – History Log was saved
  • bit 4 – Piano Roll position was saved
  • bit 5 – Selection History was saved

Next 4 bytes contain the total number of modules, in the version 3 this number must be 6.

Then there are six offsets (4 bytes each) pointing at the data of each module. The offsets are counted from the beginning of the file.

When Taseditor saves the project, it calls all 6 modules that need saving. Each of them saves current writing offset and then serializes its own data into the file stream and moves current write position forward. The order of calling modules is always the same (Markers, Bookmarks, Greenzone, History, Piano Roll, Selection). When loading a project Taseditor calls those modules in the same order and they seek to the given offset and load / deserialize the data from the file.

To check the integrity of the data loaded, every module writes its own ID (string) into the file stream before writing the data. When loading the data it expects the ID to match, if it doesn't match then the module refuses to load following data, creates default state and reports "loading error" to Taseditor.

When using Save Compact settings, modules either save all their data as usual or write dummy ID which indicates that this module didn't save its data into the file. When loading the file a module that detects dummy ID refuses to load following data, creates default state but then reports "loading success" to Taseditor.

Module | ID when saved | ID when not saved
Markers | MARKERS | MARKERX
Bookmarks | BOOKMARKS | BOOKMARKX
Greenzone | GREENZONE | GREENZONX
History | HISTORY | HISTORX
Piano Roll | PIANO_ROLL | PIANO_ROLX
Selection | SELECTION | SELECTIOX

Created with the Personal Edition of HelpNDoc: Single source CHM, PDF, DOC and HTML Help creation