search

TASEmulators / BizHawk

BizHawk is a multi-system emulator written in C#. BizHawk provides nice features for casual gamers such as full screen, and joypad support in addition to full rerecording and debugging tools for all system cores.
http://tasvideos.org/BizHawk.html
Other
2.2k stars 384 forks source link

(feature request) Relative analog inputs in TAStudio #3240

Open FitterSpace opened 2 years ago

FitterSpace commented 2 years ago

This would be a pretty niche feature but it would be great for TASing 3D games where you control the camera with an analog stick (first-person shooters come to mind).

Normally in TAStudio, you put in an absolute value for your analog inputs. Assuming the center of the analog stick is 128 (like it is in Dolphin), If you were TASing a first-person shooter and you wanted to turn the camera to the right, your analog X inputs might look like this on each frame of the turn:

analog x: 128 138 148 158 168 178 188 178 168 158 148 138 128

The reason I would turn the camera like this is so the final result looks smoother than just holding the analog stick all the way to the right for a few frames. The beginning of the turn is kind of slow then it accelerates and then it decelerates, which makes the camera movement look more natural. However, this means that every number would have to be typed in manually. There's no way I know of to simply tell TAStudio to "take the previous value and add 10 to it".

I'm proposing a system where you can tell TAStudio to have relative analog input for part of your TAS instead of absolute analog input everywhere. If that were a feature, my inputs might look like this instead:

analog x: 128 +10 +10 +10 +10 +10 +10 -10 -10 -10 -10 -10 -10 128

This would make it a breeze to TAS smooth camera turns because you could just tell TAStudio how much you want it to move the analog stick on each frame, instead of telling it exactly where you want it to be on any given frame. The +10 would just take the value from the previous frame and add 10 to it. So the first +10 would look earlier and see the 128, then add 10 to it, giving you 138. The next +10 would look at the previous row, and add another 10 to it, giving you 148, and so on.

An example of where a feature like this could have helped me in the past: https://youtu.be/wANwWtKBXNw Yes, I know this is a Wii game, which is not on BizHawk. But this is just an example of how camera movement can really affect a first-person shooter TAS. Those inputs where I turn the camera all had to be done manually because Dolphin LUA doesn't support Wii pointer inputs and there's no system like this in Dolphin. That short video took several hours to make. I'm not saying the feature has to be like Excel where you can type long formulas in the cell to calculate all kinds of things, but a simple addition and subtraction feature would help a lot.

vadosnaprimer commented 2 years ago

If you hit Shift+Up/Down while in analog editing mode, you can increment/decrement by 10.

Masterjun3 commented 1 year ago

If anyone ever thinks about implementing this, I'd personally implement it not as a separate input mode (where then the input files look different), but instead as a visual toggle in TAStudio. The cells show relative values, but the underlying inputs would still have absolute values.

However, an important functionality would be editing. It would make no sense to edit absolute values, so any click or edit on a frame would run through all the following inputs and adjust them accordingly. E.g.

displayed (internal)
145 (145)
+0  (145)
+10 (155)
+0  (155)
+0  (155)

and upon changing a frame (e.g setting the second one to +20)

145 (145)
+20 (165)
+10 (175)
+0  (175)
+0  (175)
YoshiRulz commented 1 year ago

There are several places where axes' values appear:

I don't think it's wise to have relative values in movie files. There's no need to show relative values in the input display. It's meant to be barebones, with Lua scripts providing additional visualisations. Virtual Pads behaviour is tracked separately as #1925.

So that leaves us with TAStudio and the underlying IMovie system. We have several options for how wide-scoped this feature could be.

1a) Purely visual, no-effort implementation

Nothing changes except the cell text query, which returns a different value if relative mode is enabled. All axes' values are displayed as absolute on frame 0 and relative on every other frame. Absolute values are shown when editing a cell. This would be a < 10 LOC change.

1b) Purely visual

As 1a) but the edit mode handling also checks whether relative mode is enabled. I'm not that familiar with the hydra that is TAStudio, but I'm guessing this is a < 100 LOC change, though it would be disseminated throughout the spaghetti code. These are in order of how hard they would be to implement, you get the idea.

2) Limited editing

(This matches Masterjun's request.) When relative mode is enabled, values are displayed as relative, and can be edited as relative. When a values is typed in or the slider is released, all following cells are updated in the movie such that their relative values remain the same. The values in memory remain absolute at all times. Two problems with this:

  1. That's a lot of damage values. We'd probably want to block or at least confirm edits that aren't near the end of the movie. Edits in the middle of the movie affect everything afterwards, which is rarely going to do what the user expected/wanted, so maybe the warning dialog could ask for a cutoff point for the propagation? I have no idea what to do about branches.
  2. When the change is propagated, the new value could fall outside the axis' range, and needs to be clipped. Should the clipped value be used for subsequent updates, or the unclipped value?

3) First-class support

(I believe this matches OP's request.) Each cell is either a keyframe or a non-keyframe (not to be confused with frames i.e. rows). Keyframes show an absolute value, non-keyframes show a relative value (probably still absolute in memory). Like with 2), editing a cell updates all following cells until the next keyframe, such that their relative value remains the same. Relative mode isn't enabled in the same sense as 1) or 2), rather, every newly appended or inserted frame is a keyframe, so there are no non-keyframes (relative-valued cells) until the user adds one.

  1. Managing keyframes vs non-keyframes will add yet another facet to the piano roll UX. Simplest design is right-click > Make relative to previous cell/Make absolute (keyframe), which I don't like.
  2. Not coincidentally, this will be the hardest to implement. And the hydra grows.
  3. Whether a cell is a keyframe would need to be displayed somehow (can't tell from just the values, -10 could be relative or absolute), and it's per-cell so we can't use a simple gutter icon.