CLI mode, benchmark from movie etc. #1
Conversation
Same reason i left out all of your cli fixes: i didn't feel like going through your commits, and remaking them without all the other unrelated changes. Make a single patch that does this, and only this, and maybe it can be committed. These changes are completely unrelated to wiimote savestate fixes |
|
not sure if you saw this: http://code.google.com/p/dolphin-emu/source/detail?r=470a4eee8b9c75d231c2f6840b0b8559325b1375 |
|
I don't see the flaw, i just know it still happens (rarely, but it does). Regardless of that, it still doesn't save in the proper order when using it too quickly. When trying it, more than half of my saves end up being to slot 8, often 5+ in a row, if i just hold it down. And that guy who said it was crashing is using a real wiimote. my guess is that's the problem. I don't have one to test with, so i can't reproduce it. |
CoreTiming state functionProblemRunning benchmarks return a "Access violation reading location" in VS from f.e. these events (printed in CoreTiming::EventDoState) with the pointer >= 518958768 because ev->type is undefined for these events SolutionRead ev->type when it definitely exists, when |
Skipping
|
Cheat managerWhy did you remove this from 983d5d1?
|
LogLogManagerThe benefit with log to the launching console (in Windows too)
log to OutputDebugString when the process is not debugged too
log OSD messages to LogManager too because that make the message (f.e. about state version)
Loading log settings for CLIThe benefit with loading log settings for CLI is
The code is run regardless of IsDebuggerPresent() because it's possible that debugging has been released since was run Discussion@NeoBrainX
Because
|
More deterministic dual thread movie inputProblemDual thread recording desync, sometimes because the recorded frame differ from the played frame The problem is important for a benchmark when it causes the lap completion percentage to be low because the movie isn't representative of play that draw a whole lap The movies have frame desync messages similar to this SolutionUpdating dual thread input directly after frame draw because
The change is conditional on dual threading because
There's no frame mismatch in any of the movies but some still desync This doesn't solve the problem that GC and Wii input order isn't deterministic from boot, but result in the message ComparisonThe test builds are
The tested commands are f.e. for the movie The "movie" column is the movie name without the suffix ".dtm", "_sync.dtm" The "lap" column is lap completion percentage for the test programs in the order: The "fps" column is target FPS (no value mean 60) The "frame" column is frame mismatch information (the "cur - rec" value in parentheses) The "problem" column describe the column for the movie that has less than 100% lap completion Discussion
Run the movies in the topic "Problem" because they create frame desync warnings
It desyncs less than with a tick interval input update as described by the different lap completion percentage
The cost of losing dual thread intra-frame input is lower than the utility of the synchronisation improvement because
Why should the synchronisation be perfect to outweigh the loss of intra-frame movie input? considering that a desynchronized movie has little value despite intra-frame input update
If a perfect sync is required to give a dual thread movie a value, the example movies with 100% lap completion indicate a perfect sync i.o.w. a value It's not correct that the < 100% lap completion example movies are without value because a benchmark movie's value increase with increased lap completion
It doesn't reduce the motivation for improving the dual thread movie sync because it's still a problem that some dual threaded example movies desync Create a dual thread movie that doesn't desync significantly and benefit from intra-frame input because it's not clear that it exists |
Movie synchronisation dataProblemThere's no movie desynchronisation detection SolutionThe frame count is a measure of synchronisation The tick count isn't a good measure of synchronisation because it's different in a single thread movie (despote having deterministic input) The frame log print this message when the recorded tick is different from the current Size is moved from the Wii data to a input packet header (i.o.w. store for GC input to despite that always being 8) because that's better organisation because it's easier to read The wrong type end the movie because
Discussion
Tick appear to be a flawed way to determine synchronisation because both with "CPUThread = True" and "CPUThread = False" is there
but
The frame sync is no frame desynchronisation two frame desynchronisation (one frame per desynchronisation) all frames are desynchronised <_RachelB> gc never desyncs, so that seems entirely unnecessary GC input desyncs when dual threading is used, i.o.w. when "CPUThread = True" and "SyncGPU = False"
It's worth additonal size because data is needed to determine synchronisation which is important
It's not impossible because the data column width can be changed from 8 to 9 + 8 to show the data and data header in separate columns
In 010 Editor the column width is changed with "View → Line Width → Custom Width" The movie header can be removed with this command to show data in the first cell
A GC desync can be created by recording F-Zero with the files in the topic "File" in benchmark This file has desync that's noticed because the controlled object hit a wall repeatedly
This can be seen in benchmark.txt in the topic "File" in benchmark |
Wii input shakeProblemA peak Wiimote g-force of 3 is almost too low in Pucca's Kisses Game at the end of level 1-2 (where shake is used to run to catch up with another character) with the result that the character
because the maximum theoretical accelerometer value is Wiimote accelerometer max Nunchuk accelerometer max this output (from first party hardware) of maximum accelerometer values show that the Wiimote reach a maxium value in one direction and the Nunchuk in both directions, meaning that it's likely that software is designed to expect that maximum values can be reached Wiimote accelerometer min, max [ 0, 238] Nunchuk accelerometer min, max [ 0, 255] SolutionUsing the the maximum force from calibration rather than a constant because
Discussion
If it's desirable to make shake more efficient it should be considered that the most efficient shake pattern can be different for different games depending on how they read shake intensity, i.o.w. that there might not be one pattern that's the best pattern in all games it might be better to reduce |
Unsaved Wii input state valuePatchThe commit in this branch with the same title as this post ProblemIn a (deterministic) single thread emulation there's a ( the frame and GC and Wii input order (if the GC pad is enabled ("SIDevice0 = 6")) is unsynchronized, resulting in the message SolutionResultMaking the Wii input equally deterministic as the GC input by
because that
Why not save
|
Dual thread GC and Wii input orderProblemPlaying a Wii movie with
and these settings that increase the probability of the occurence
play Wii input from GC input and vice versa with the message because
f.e. the unevenly divisible frequencies
result in a GC and Wii recording eventually being inside the tick uncertainty region with the result that the played SolutionKeeping the Wii and GC input update GC outside the tick uncertainty region by updating them at the same rate (at a large tick distance) because that allow recording GC and Wii input simultaneously in the same array Changing the emulated Wii input update frequency from 200 Hz to This is the only even Wii input update frequency because the IPC_HLE update frequency is If the multiplier is changed from 25 to 30 there are two even update frequencies, because
Removing
The alternative solution
is less good because a deterministic Wii input is better because it's necessary for an exact movie Even when IPC_HLE and SI update has the same tick interval a dual threaded movie recorded from boot won't be deterministic because the tick when Wiimote connection occur varies, with this message as result TestIt's tested with benchmark these ISOs in order of sensitivity for Wiimote disconnect when the Wiimote update is wrong
Discussion@_RachelB
Despite that, you should place the build, configuration and movie that desync in Dropbox because
That's what I understand to mean desync. What do you mean with desync
You should
because the emulated Wiimote update is changed from 200 Hz to
The real Wiimote should be read at 200 Hz rather than 60 Hz because
What's the source for the information that the Wii read the Wiimote at 200 Hz?
How do i call WPADGetRadioSensitivity from libogc (f.e. in TestSuite WPAD)? @skid_au
The Wiimote connection isn't affected for NTSC because
probably not affected for PAL because
@rdragoon
Yes.
Fixed.
I agree. I'm guessing there's an unzeroed buffer recorded from the gc pad that result in unwanted input during playback. @NeoBrainX
It's necessary for a Wii movie f.e. |
Saving real Wiimote stateCommitThe commit in this branch with the same title as this post ProblemReconnect after state load isn't functionalReconnecting when loading a state create an unhandled Wiimote state where The code doesn't reconnect the Wiimote as it's used
Hang when reconnecting oftenThe code is unreliable when run often as observed by
and observing that "Video Thread" is at No meaning with reconnectingThere's no meaning with reconnecting the real Wiimote after state load
SolutionSaving the real Wiimote state because that's simpler than reconnecting The Wiimote state is saved in If this means an issue compared to not using the hybrid Wiimote function that's because of a bug in this functions that it's beneficial to locate With this patch, the only difference betwen WIIMOTE_SRC_REAL and WIIMOTE_SRC_HYBRID is that emulated Wiimote input is disabled for the previous The loaded state is channel and reporting mode because that's adequate ConnectionNot changedThis doesn't affect the real Wiimote operation because a difference in the real Wiimote operation between the real and hybrid operation isn't observed in
after resetting the Wiimote state with
Removing reading of the emulated Wiimote state in the real Wiimote mode
This is solved in the commit with the same name as the title of this topic by
i.o.w. by making the emulated Wiimote object write only rather than read and write Problem descriptionThe hybrid Wiimote read the emulated Wiimote object with the intention of
This doesn't have meaning for the real Wiimote mode because the emulated Wiimote isn't used The problem was created in the commit "Saving real Wiimote state" because it doesn't solve the problem as described in this topic Adding read data reply to the real WiimoteThis solution is an inadequate version of the solution in the topic "Removing read emulated Wiimote data from real Wiimote" This problem is solved in the commit with the title "Adding read data reply to the real Wiimote" by
There's a link to a branch that contain this commit in the topic "More information" There's a link to a folder that contain a build of this branch (in the file The read data acknowledgement was unintentionally disabled for the real Wiimote in the commit with the title "Saving real Wiimote state" Merge status
Problem descriptionThe problem that the emulated program detect input (f.e. the B button in the NSMB level start screen) but still report that the Wiimote is disconnected can be a result of missing or unsynchronised
because
Removing wait for real Wiimote connection
This is solved in the commit "Removing wait for real Wiimote connection" by not waiting for
because
Reason for waitThe commit "Saving real Wiimote state" add a wait function to
Merge status
Hybrid IR
The hybrid IR isn't implemented because of a challenge in combining the emulated and real IR input Connecting more than one Wiimote
Do you mean that the log write the message when you expect it to also write because there's more than one Wiimote in the Bluetooth range? This problem isn't caused by the commit "Saving real Wiimote state" because
SettingsCommunicate the Connection time
This isn't a result of the commit with the title "Saving real Wiimote state" because
ReproducePlace the Dolphin folder in Dropbox (and paste the link to the Dropbox folder) because that can make it easier to reproduce the problem because it allow
LogRun because
StateRun the states from the folder linked in the topic "Log" with command or with the GUI in "File > Open" and
Real compared to hybridCommunicate if the real Wiimote operation in hybrid mode that's enabled with the is different because
Frame rateCommunicate if there's a difference in how the real Wiimote operates between the because
More informationThere's more information about this patch at #1 (comment) that can be useful to analyse the problem State reliabilityRead reply state not savedThe real Wiimote states are potentially unreliable because
This problem is mitigate because
Pausing data reportingDisabling Wiimote data reporting during
Bit comparison
The expression State version
The state version shouldnt be changed because the state isn't changed Merge status
TestIt's tested with a real Wiimote in
with the settings
in
with the settings
in
with the settings
with RefactorMoving swap24 to Common because
LogAdding a
This is useful because
It's appropriate to merge this with this patch because
This is described in this topic |
Removing muted Wiimote audioPatchThe commit in this branch with the same title as this post Problem
DKCR continuously send audio reports at 41.1 [21.6 41.4] Hz (this information is in the topic "Unsaved Wii input state value") that delay WM_ACK_DATA so that the game detect a disconnect around 8 s after it's connected with the message Just Dance 4 disconnect after around 7 s with the message SolutionRemoving muted audio because
It's possible that the Wii hardware doesn't send muted audio TestThe patch is tested in
With settings Normal play in DKCR often doesn't disconnect the Wiimote because the audio often isn't continuous for a long period Sending audio data continuously by changing frequently between the "New Game" options
Merge statusThese commits should be merged at the same time
because
Billiard's approval is appropriate because
Discussion
This means that There isn't meaningful indication of that in the games in the topic "Test" because audio isn't perceived to be altered or missing
This is the first muted WM_WRITE_SPEAKER_DATA from DKCR after boot
No because it's solved in |
Moving thread name function to a classProblemThese features are missing
Solution
because
The reason that Thread don't allow running a thread without a name is
don't allow running a thread from its creator
Joining one thread at a time because
std::thread::idThe std::thread::id type is
|
Creating a namespace for memory utilitiesPatchThe commit in this branch with the same title as this post ProblemThe memory utilities doesn't use a namespace SolutionCreating a namespace for memory utilities because f.e. is better organisation than Memory messageProblemA lack of memory messages during start and stop
SolutionAdding memory messages |
Copying fork to origin branchPurpose
I've copied this branch to origin/cli because
Origin branch removedI've removed origin/cli because
|
Adding CLI mode to GUI build etc.The benefits with CLI mode in GUI build
running without GUI
booting from a movie or state
benchmark
check state version before boot because
|
Changing Wiimote logging from logging all to logging changed data reportsCommit messagesbecause unchanged data reports
Logging all communicationProblemAll Wiimote communication isn't logged in WiimoteEmu::Spy Not logging all data reportsProblemLogging all data reports is a problem because
SolutionLogging data reports that are
|
Adding IR to hybrid WiimoteProblemIR isn't enabled for the hybrid Wiimote This is a problem because
|
because a build test reduce commits with build errors
because that information sometimes not meaningful
because uncommon letters can result in an empty string in the existing function
Adding wait for real Wiimote connectionCommit messagewhen
because
ProblemThe problem is
The Wiimote connection sohuld be enabled on boot because
Real Wiimote modeThe real Wiimote mode wait for a Wiimote connection before booting to because despite that the connection works (without a manual disconnect/connect)
AnalysisThe last connection messages when booting to a non-functional hybrid connection is It's not clear from this which report is missing The missing report can be 0x21 or 0x22 messages is missing because
TestTested by booting
at the FPS
with the CPU |
because it's useful to save the state
Open Adding option to open a state or movie. (A movie could previously be started but not through open) When opening a state or movie the ISO is selected by ID rather than last used because that's more accurate Disable the Play and Start Recording options if no ISO is set instead of showing the BrowseForDirectory dialog because that's less confusing The BootManager is changed to try the default and last iso if an empty string is provided If a file isn't found the ISO library is searched because that allow a relative path Benchmark Adding option to play a movie as a benchmark by running it without a frame limit and measure the frame rate
because that allow determining * type: GC and Wii input order * frame: synchronisation
from 200 Hz to `VideoInterface::TargetRefreshRate` because that allow recording GC and Wii input simultaneously in the same array
… tick interval because that make recording more deterministic
because it use much memory
Adding option to disable Wiimote connection motor notificationCommit messageby disabling motor because
Problem
SolutionAdding an option to disable the motor notification by disabling the motor |
Synchronising the hybrid Wiimote calibrationCommit messagebecause
ProblemThe emulated Wiimote don't use the same calibration as the real Wiimote in hybrid mode This is a problem because
Extension calibrationIt's a problem that the emulated rather than real calibration is used because this emulated calibration that's sent to the emulated program makes data reports from a Nunchuk with f.e. this calibration (from a RVL-004 Nunchuk) less accurate TestThis commit can be tested with
the WPAD test Missing calibrationWhen the Nunchuk return 0xff as calibration, as f.e.
that output the emulated calibration is used for the real Nunchuk stick Dynamic calibrationThis implementation should be considered devkitPro solve this by using a dynamic calibration that set
Start valuesA problem in the implementation is the start values
because
|
Synchronising the hybrid Wiimote extensionCommit messageby controlling the extension from the real rather than emulated Wiimote in hybrid mode because
Connected extensionIt's possible to control the extension from the emulated Wiimote because
But there are problems because
Frozen extension dataThe extension data is sometimes 0xff and sometimes frozen at the last value f.e. Data report ceaseThere's a problem when changing the real extension because the Wiimote cease reporting when changing extension until receiving WM_REPORT_MODE this can be done at but the problem is
Removing emulated non-data input reports in hybrid modeThis commit remove non-data input reports in hybrid mode before the commit a non-data input reply to these output reports is created Sending emulated non-data input reports in hybrid mode has the advantage
not sending emulated has the advantage
|
by scrolling to another line than the last because * automatic scrolling is disruptive when observing previous messages
Adding option to disable log window automatic scrollingCommit messagesby scrolling to another line than the last because
|
Changing the Nunchuk stick axis from center to center + 1MessageThis message is at #1 (comment) CommitIn this branch with the same title as this post DependencyThis commit depend on the commit
Commit messageif the other axis isn't at center because
ReferenceThis is discussed in
that mention ProblemProduce the problem in A Boy and His Blob
Problem descriptionThe selection direction (← red jellybean, ↑ blue, → black) isn't changed if the other axis is at center f.e. the red or black jellybean isn't selected if
SolutionChanging the Nunchuk stick axis from center if the other axis isn't at center More informationThe black jellybean is selected at
with calibration
Discussion
No because
the message mean that the commit "Changing the Nunchuk stick radius" doesn't solve the problem
No because
TestRun from this folder jellybean selection is available in the state select a red, blue and black jellybean as described in the topic "Problem" |
Input configuration problemNon-default input not detectedProduce use this profile press A on the keyboard input device the input A isn't detected (doesn't change "A" in the "Buttons" bitmap from a white to a red background) "| OR" append to the left instead of to the rightProduce open the "Dolphin Emulated Wiimote Configuration" dialog
right click input configuration to open the "Configure Control" dialog
|
Adding Nunchuk stick calibrationProblemThe Nunchuk stick doesn't consider its calibration This is a problem in the hybrid mode that's described in the topic "Synchronising the hybrid Wiimote calibration" SolutionAdding calibration consideration to the Nunchuk stick ImplementationThe attachment is given access to its registry with
because compared to copying it to the existing Attachment::reg
Merge status
|
because * color makes it faster to identify elements of a log message
because the knowledge can be useful
because * that's better organisation
because * that's better organisation
when * booting from the emulated program entry point because * the hybrid Wiimote connection isn't established automatically if the real Wiimote connection isn't present on boot
by disabling motor because * it makes a noise
because * the purpose of the emulated Wiimote state in the real Wiimote mode is to store the real Wiimote state rather than synchronise with an emulated Wiimote
Deterministic multi-Wiimote movie
Yes I should analyse that |
it used to be just gray
because * it makes it easier to change between emulated and real IR
because * it makes it easier to change between the emulated and real Nunchuk
because it's useful for the hybrid Wiimote mode
…orts because unchanged data reports * don't contain meaningful information * use space in the log history
because * it makes control more accurate
by controlling the extension from the real rather than emulated Wiimote in hybrid mode because * the real Wiimote extension can control the emulated * the opposite isn't true because it involve physical attachment
if the other axis isn't at center because * it's expected by some emulated programs
No description provided.