Add bxt_tas_studio_replay_views #99
Conversation
khanghugo
changed the title
|
Maybe this could be renamed to |
| // It is also funny how vieworg is calculated here, | ||
| // but viewangles is passed from BXT. |
There was a problem hiding this comment.
I was gonna ask why this is necessary but I guess bxt-strafe just doesn't handle angle overrides yet?
Ideally it would handle overrides (then they will also work without simulation), but I guess that's effort?
There was a problem hiding this comment.
Yea I'd say bxt-strafe is not aware of the viewangles / rendered angle data so you might call this precursor to that. This is just half of the work if the simulation wants the overrides. However, this one is specifically just the rendered yaw, not the actual player yaw.
| @@ -2376,6 +2398,7 @@ pub mod exported { | |||
| let marker = MainThreadMarker::new(); | |||
|
|
|||
| campath::override_view(marker); | |||
| tas_studio::tas_playback_rendered_views(marker); | |||
There was a problem hiding this comment.
Should this be before or after campath?
There was a problem hiding this comment.
I cannot think of how this would matter. The only time both of these are called is when someone loads a campath and then play a campath while they also are playing back TAS views. Talking about stretch.
src/modules/tas_studio/mod.rs
Outdated
| // bxt_tas_norefresh_until_last_frames = 0 means 1 frame being played. Heh. | ||
| let start_frame = norefresh_until_stop_frame_frame_idx(marker, &editor); | ||
|
|
||
| engine::prepend_command(marker, "bxt_hud 0; hud_draw 0\n"); |
There was a problem hiding this comment.
It was fairly subjective because I did make it that way. My reasoning is that since we only change the player's views, none of the stats actually get changed, so none of the HUD info would matter.
src/modules/tas_studio/mod.rs
Outdated
| @@ -1560,7 +1638,82 @@ pub unsafe fn maybe_receive_messages_from_remote_server(marker: MainThreadMarker | |||
| editor.recompute_extra_camera_frame_data_if_needed(); | |||
| } | |||
| State::PreparingToPlayToEditor(_, _, _) => unreachable!(), | |||
| _ => (), | |||
There was a problem hiding this comment.
Shouldn't the playing views state be added to the PlayingToEditor and Editing arm above?
There was a problem hiding this comment.
Playing views doesn't depend on the simulated game or change the TAS in anyway. It receives frames from simulated game then just playback views. I am not very sure what you want to do with playing views states.
There was a problem hiding this comment.
I was thinking that the other game might be doing some simulation while we run playback views, but thinking about it I guess it won't because we already need all accurate frames to play back. Or maybe it can still happen while on a branch?
If that is the reasoning, then replace this blanked match with an explicit PlayingViews to 1. mention in the comment the reasoning, and 2. to not miss if another state is added in the future.
| @@ -141,6 +141,7 @@ pub struct OnTasPlaybackFrameData { | |||
| pub strafe_cycle_frame_count: u32, | |||
| pub prev_predicted_trace_fractions: [f32; 4], | |||
| pub prev_predicted_trace_normal_zs: [f32; 4], | |||
| pub rendered_viewangles: [f32; 3], | |||
There was a problem hiding this comment.
Does this need a _v2 function name and a change on bxt side?
There was a problem hiding this comment.
Yea we need to change the on_tas_playback_frame() function to match. #101 also makes changes to the playback frame data so this PR (a lot shorter) needs merging first to avoid weird conflicts.
src/modules/tas_studio/mod.rs
Outdated
| @@ -1560,7 +1638,82 @@ pub unsafe fn maybe_receive_messages_from_remote_server(marker: MainThreadMarker | |||
| editor.recompute_extra_camera_frame_data_if_needed(); | |||
| } | |||
| State::PreparingToPlayToEditor(_, _, _) => unreachable!(), | |||
| _ => (), | |||
There was a problem hiding this comment.
I was thinking that the other game might be doing some simulation while we run playback views, but thinking about it I guess it won't because we already need all accurate frames to play back. Or maybe it can still happen while on a branch?
If that is the reasoning, then replace this blanked match with an explicit PlayingViews to 1. mention in the comment the reasoning, and 2. to not miss if another state is added in the future.
|
Thanks |
Closes #97
Intended to work with yaw (and pitch) override and also without.
Seems pretty okay.
I don't want to figure out how to keep the same position after replay but if it is needed then I shall.
If no second game and no tas playback first time then viewangles replay won't work (not a problem and no one would encounter it but can be fixed very easy or not depending on the simulated run would override the values or not).
And
If that needs changing then sure. I don't want to complicate all of the logic too much.