Move Immediate XFB down in DTM header #6207
Conversation
|
cc @iwubcode – is not syncing this setting fine? |
JosJuice
force-pushed
the
dtm-immediate-xfb
branch
from
79a36c2
to
a6fccbd
Compare
|
Stenzek and I reached the conclusion that while changing the setting doesn't affect the sync of the emulated system, it affects the frame and lag counters in Movie.cpp, which can lead to some unwanted consequences for TASing. So this PR now just moves the setting instead of deleting it from the header. |
JosJuice
changed the title
JosJuice
force-pushed
the
dtm-immediate-xfb
branch
from
a6fccbd
to
78c41f7
Compare
|
Wait a little... The XFB to RAM setting is wrong too >.< |
|
@JosJuice - thanks, sorry I didn't know the ordering of this stuff mattered...maybe we need a comment? (or maybe I missed it!) |
JosJuice
force-pushed
the
dtm-immediate-xfb
branch
from
78c41f7
to
38c458c
Compare
|
It should all be fixed now. I've added a comment too. Fortunately, the number of non-XFB settings that were affected was actually much smaller than I thought it was after only seeing the immediate mode commit. |
7f0834c moved the locations of the Real XFB (now XFB to RAM) and Disabled XFB (now Immediate Mode) settings. There are programs other than Dolphin that parse DTM headers, so this is not good. Note that Immediate XFB actually is the inversion of Disabled XFB. I hope that's not too much of a problem...
JosJuice
force-pushed
the
dtm-immediate-xfb
branch
from
38c458c
to
d0b9923
Compare
| @@ -52,6 +52,8 @@ struct ControllerState | |||
| static_assert(sizeof(ControllerState) == 8, "ControllerState should be 8 bytes"); | |||
| #pragma pack(pop) | |||
|
|
|||
| // When making changes to the DTM format, keep in mind that there are programs other | |||
| // than Dolphin that parse DTM files. The format is expected to be relatively stable. | |||
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
7f0834c, which added the Immediate DTM setting, also added a byte to DTM headers for Immediate DTM. There are two problems with this:
The byte was added in the middle of the header, throwing off the offsets of several other settings. There are programs other than Dolphin itself that parse DTM files, so this is not acceptable.
If I'm not mistaken, Immediate XFB doesn't affect sync. Putting it in the DTM header unnecessarily prevents people from using a different value for that setting than what the movie author used.
I would appreciate if this could get reviewed quickly so that TASers don't have time to create DTMs with broken headers.