Coder Social home page Coder Social logo

dolphin-emu's Introduction

ARCHIVED

You are probably looking for https://github.com/dolphin-emu/dolphin to contribute to this project

The contents of this archive is a large number of discussions about pending merges. There is no time limit for this but I really want something like the command line timedemo commands I created. I like to track performance over the years with a standard demo loop that measures frame drawing time. Slow drawing is a notorious problem in emulators and a contentious issue over shortcuts. In Sweden we say a shortcut (genväg) becomes a longcut (senväg)

Repo history

This project was hosted at https://code.google.com/p/dolphin-emu for many years. Fans of this lab mirrored it here in 2013. It was eventually moved from Google to https://github.com/dolphin-emu/dolphin in 2013 and this project was archived for old discussion's sake. For ten years we have wanted to transfer the ownership but this lab doesn't allow that without bothering the engineers or admins. The message is

john-peterson already has a repository in the mirror/dolphin-emu network

And the decision was to keep it here and direct everyone that might land here to the right URL

Discussions archive

Some of the discussions contained here might still be relevant today:

  • an homage to the legendary timedemo command in a ground breaking real-time renderer from 1996. The command would run recorded inputs without time synchronization. Essentially measuring how well your machine can render frames. The interested can read more under /issues/26

  • changes related to live code editing (sometimes called "trainers" in the context of games)

  • an herculean effort to reverse engineer the Wiimote especially for emulating the gyro. It is kept in one small patch that is still fun to read. And a much larger patch for the related debugging function Spy() that would spy on the hardware traffic. And finally a gigantic patch to actually use it with normal PC controls mouse and keyboard

dolphin-emu's People

Contributors

john-peterson avatar mxebot avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

dolphin-emu's Issues

No documentation in EmuSubroutines for WiimoteEmu::Spy()'s #if 0 block

Hey there John P. You had this code committed to Dolphin a while ago (in 2013 actually): https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/Core/HW/WiimoteEmu/EmuSubroutines.cpp#L36

This is evidenced the following commit here. There's no documentation on whether or not this is purely a function for logging, or if it's genuinely broken code that never had gotten fixed. I was just wondering if you could tell me, so it can be noted and make maintainability of that code much easier in the future.

Metroid Prime 2 black bar

Metroid Prime 2 black bar

Reference

Problem

Metroid Prime 2 has a (approximately 10% of height) black bar at the bottom of its display

Metroid Prime and Metroid Prime 2 will both work with Synchronise GPU, if the GameCube BIOS is not skipped

Prime 2 with Synchronise GPU has significant problems

  • on some boots there's frequent slowdowns (1 fps for several seconds)
  • the fps is frequently at 40 or 50 instead of 60 (with a i7-3770)

What's the latest version where Prime 2 doesn't have a black bar (with dual core, without sync GPU, without XFB) or where virtual XFB doesn't flicker?

[email protected] reply

diff --git a/Source/Core/Core/Src/PowerPC/Jit64/Jit_SystemRegisters.cpp b/Source/Core/Core/Src/PowerPC/Jit64/Jit_SystemRegisters.cpp
index 9475be9..77927a8 100644
--- a/Source/Core/Core/Src/PowerPC/Jit64/Jit_SystemRegisters.cpp
+++ b/Source/Core/Core/Src/PowerPC/Jit64/Jit_SystemRegisters.cpp
@@ -121,13 +121,13 @@ void Jit64::mtmsr(UGeckoInstruction inst)
   FixupBranch noExceptionsPending = J_CC(CC_Z);

   // Check if a CP interrupt is waiting and keep the GPU emulation in sync (issue 4336)
-  TEST(32, M((void *)&ProcessorInterface::m_InterruptCause), Imm32(ProcessorInterface::INT_CAUSE_CP));
-  FixupBranch cpInt = J_CC(CC_NZ);
+  // TEST(32, M((void *)&ProcessorInterface::m_InterruptCause), Imm32(ProcessorInterface::INT_CAUSE_CP));
+  // FixupBranch cpInt = J_CC(CC_NZ);

   MOV(32, M(&PC), Imm32(js.compilerPC + 4));
   WriteExternalExceptionExit();

-  SetJumpTarget(cpInt);
+  // SetJumpTarget(cpInt);
   SetJumpTarget(noExceptionsPending);
   SetJumpTarget(eeDisabled);

This doesn't remove the black bar

Repo workflow

I'm keeping this issue open because the existence of this mirror for metadata housekeeping. Is contentious. I looked again in 2023 for a way to extract all or save all metadata of this repo and I can't see it maybe I'm blind

Deadlock

Deadlock

Files

The builds in dolphin/test folder are from the branch

  • Dolphin: john-peterson/master
  • DolphinD: john-peterson/master
  • Dolphin-input: john-peterson/input

Problem

Run DolphinD and Wii Sports NTSC and observe this deadlock message

The wait time 10 s is adequate to detect a deadlock (it also exist at longer wait times f.e. 60 s)

08:27:889 Src\Thread.cpp:82 N[CONSOLE]: Joining "GPU" 17436
08:27:892 Src\Thread.cpp:82 N[CONSOLE]: Joining "CPU" 23676
08:27:897 Src\Thread.cpp:91 N[CONSOLE]: Joined "CPU"
08:27:934 Src\Thread.cpp:82 N[CONSOLE]: Joining "Audio - OpenAL" 14772
08:37:891 Src\Thread.cpp:85 E[CONSOLE]: Deadlock in "GPU" 17436
08:37:891 Src\Thread.cpp:91 N[CONSOLE]: Joined "GPU"
08:37:936 Src\Thread.cpp:85 E[CONSOLE]: Deadlock in "Audio - OpenAL" 14772
08:37:937 Src\Thread.cpp:91 N[CONSOLE]: Joined "Audio - OpenAL"

run Dolphin and Wii Sports NTSC and observe this output without a deadlock

07:42:420 Src\Thread.cpp:82 N[CONSOLE]: Joining "GPU" 22476
07:42:422 Src\Thread.cpp:82 N[CONSOLE]: Joining "CPU" 23528
07:42:422 Src\Thread.cpp:91 N[CONSOLE]: Joined "CPU"
07:42:438 Src\Thread.cpp:82 N[CONSOLE]: Joining "Audio - OpenAL" 14776
07:42:439 Src\Thread.cpp:91 N[CONSOLE]: Joined "Audio - OpenAL"
07:42:676 Src\Thread.cpp:91 N[CONSOLE]: Joined "GPU"

if audio join is placed after GPU join the message is

18:28:570 Src\Thread.cpp:82 N[CONSOLE]: Joining "GPU" 23072
18:28:572 Src\Thread.cpp:82 N[CONSOLE]: Joining "CPU" 19660
18:28:573 Src\Thread.cpp:91 N[CONSOLE]: Joined "CPU"
18:28:581 Src\Thread.cpp:91 N[CONSOLE]: Joined "GPU"
18:28:612 Src\Thread.cpp:82 N[CONSOLE]: Joining "Audio - OpenAL" 23224
18:38:613 Src\Thread.cpp:85 E[CONSOLE]: Deadlock in "Audio - OpenAL" 23224
18:38:613 Src\Thread.cpp:91 N[CONSOLE]: Joined "Audio - OpenAL"

The problem isn't a deadlock

The thread is at

                        for (u32 i = 0; i < nSamples; ++i)
00000000019AD518  mov         dword ptr [i],0  
00000000019AD523  jmp         00000000019AD535  
00000000019AD525  mov         eax,dword ptr [i]  
00000000019AD52C  inc         eax  
00000000019AD52E  mov         dword ptr [i],eax  
00000000019AD535  mov         eax,dword ptr [nSamples]  
00000000019AD53C  cmp         dword ptr [i],eax  
00000000019AD543  jae         00000000019AD5C4  
                        {
                            stereo[i * 2 + 0] = (short)((float)sampleBuffer[i * 2 + 0] * (1 << 16));
00000000019AD545  mov         eax,dword ptr [i]  
00000000019AD54C  add         eax,eax  
00000000019AD54E  mov         eax,eax  
00000000019AD550  mov         rcx,qword ptr [rsp+0F0220h]  
00000000019AD558  movss       xmm0,dword ptr [rcx+rax*4+498h]  
00000000019AD561  mulss       xmm0,dword ptr [__real@47800000 (2572A8Ch)]  
00000000019AD569  cvttss2si   eax,xmm0  
00000000019AD56D  mov         ecx,dword ptr [i]  
00000000019AD574  add         ecx,ecx  
00000000019AD576  mov         ecx,ecx  
00000000019AD578  mov         word ptr stereo[rcx*2],ax  
                            stereo[i * 2 + 1] = (short)((float)sampleBuffer[i * 2 + 1] * (1 << 16));
00000000019AD580  mov         eax,dword ptr [i]  
00000000019AD587  lea         eax,[rax+rax+1]  
00000000019AD58B  mov         eax,eax  
00000000019AD58D  mov         rcx,qword ptr [rsp+0F0220h]  
00000000019AD595  movss       xmm0,dword ptr [rcx+rax*4+498h]  
00000000019AD59E  mulss       xmm0,dword ptr [__real@47800000 (2572A8Ch)]  
00000000019AD5A6  cvttss2si   eax,xmm0  
00000000019AD5AA  mov         ecx,dword ptr [i]  
00000000019AD5B1  lea         ecx,[rcx+rcx+1]  
00000000019AD5B5  mov         ecx,ecx  
00000000019AD5B7  mov         word ptr stereo[rcx*2],ax  
                        }

where i is increasing at 20/s and nSamples is 32768 accorrding to this TracePoint

Function: $FUNCTION, Thread: $TID $TNAME {i} {nSamples}

i is changed to 1 after 16385 (0x4001 i.o.w. 14 bit) because that's a buffer overflow, so that the loop doesn't end

Function: OpenALStream::SoundLoop(void), Thread: 0x4424 _threadstartex 16385 32768
Function: OpenALStream::SoundLoop(void), Thread: 0x4424 _threadstartex 1 32768

the Process Hacker output show that the thread is throttled to 0,02% CPU use

17444, 0,02, 4 810 614, DolphinD.exe!_threadstartex, Normal
22508, 0,01, 3 257 979, dsound.dll!DirectSoundCreate8+0x4f40, -3
7848, , 2 631 670, winmm.dll!timeEndPeriod+0xe8, Time Critical
25148, , 1 845 271, dinput8.dll!DirectInput8Create+0xa3bc, Highest
18932, , 765 022, dsound.dll+0x2040, Time Critical
23872, , 751 386, soft_oal.dll!alcMakeContextCurrent+0xd390, Normal

It can print a message

Unhandled exception at 0x019ad549 in DolphinD.exe: 0xC0000005: Access violation writing location 0x000000000000bb80.

                            stereo[i * 2 + 0] = (short)((float)sampleBuffer[i * 2 + 0] * (1 << 16));
00000000019AD545  int         3  
00000000019AD546  test        byte ptr [rsp],ah  
00000000019AD549  add         dword ptr [rdi],ecx  

The reasoning below is outdated because the information above was not present when it was written

This indicate that

the audio and GUI (rather than GPU) thread is waiting for each other because

  • 2/4 (including GUI) thread joins time out
  • a common cause of deadlock is circular wait
  • the GPU thread is already joined
  • when one of the thread in a circular wait pair is joined (after timeout) that allow the other thread to immediately join instead of continue to wait for timeout

a deadlock is conditional on a race because

  • the only difference between the two processes is speed
  • especially delete is slower in Debug with the result that shutdown take around 12 s instead of around 1 s

Lock schedule

  • the interface thread wait for GPU join
  • the GPU thread wait for CPU join
  • the GPU thread wait for audio join

Threads

The process thread count is

  • emulation: around 23
  • no emulation: 1 to around 9

The thread count at different states is is

run process

Unflagged   >   21464   0   Main Thread Main Thread GetMessage  Normal

run emulation

Unflagged       19836   0   Worker Thread   TppWorkerThread NtWaitForWorkViaWorkerFactory   Normal
Unflagged       5816    0   Worker Thread   CThread::ThreadStartRoutine ZwWaitForMultipleObjects    Time Critical
Unflagged       9864    0   Worker Thread   Audio - OpenAL  std::condition_variable::wait   Normal
Unflagged       10128   0   Worker Thread   Win64 Thread    ZwWaitForSingleObject   Normal
Unflagged       10728   0   Worker Thread   CThreadBase::StaticThreadProc   ZwWaitForMultipleObjects    -3
Unflagged       17988   0   Worker Thread   Win64 Thread    ZwWaitForKeyedEvent Normal
Unflagged       18040   0   Worker Thread   CDeviceEnumerator::PnpNotificationThreadWrapper ZwWaitForMultipleObjects    Normal
Unflagged       19048   0   RPC Thread  RPC Callback Thread NtDelayExecution    Normal
Unflagged       19444   0   Worker Thread   Win64 Thread    NtUserGetMessage    Normal
Unflagged       20020   0   Worker Thread   TppWorkerThread NtWaitForWorkViaWorkerFactory   Normal
Unflagged       20588   0   Worker Thread   TppWaiterpThread    ZwWaitForMultipleObjects    Normal
Unflagged       21020   0   Worker Thread   GPU DX11::D3D::AutoState<ID3D11BlendState>::~AutoState<ID3D11BlendState>    Normal
Unflagged       21364   0   Worker Thread   joyMonitorThread    NtDelayExecution    Lowest
Unflagged   >   21464   0   Main Thread Main Thread wxEvtHandler::ProcessEventLocally   Normal
Unflagged       22664   0   Worker Thread   CEm_LL_ThreadProc   ZwWaitForMultipleObjects    Highest
Unflagged       22800   0   Worker Thread   TppWorkerThread NtWaitForWorkViaWorkerFactory   Normal
Unflagged       23044   0   Worker Thread   EtwpNotificationThread  ZwTraceControl  Normal
Unflagged       23460   0   Worker Thread   timeThread  ZwWaitForMultipleObjects    Time Critical
Unflagged       24056   0   Worker Thread   TppWorkerThread NtWaitForWorkViaWorkerFactory   Normal
Unflagged       24128   0   Worker Thread   CPU CoreTiming::MoveEvents  Normal
Unflagged       24516   0   Worker Thread   Win64 Thread    ZwWaitForKeyedEvent Normal
Unflagged       24544   0   Worker Thread   CThread::ThreadStartRoutine ZwWaitForMultipleObjects    Time Critical

stop emulation

Unflagged       19836   0   Worker Thread   TppWorkerThread NtWaitForWorkViaWorkerFactory   Normal
Unflagged       9864    0   Worker Thread   Audio - OpenAL      Normal
Unflagged       19048   0   RPC Thread  RPC Callback Thread NtDelayExecution    Normal
Unflagged       19444   0   Worker Thread   Win64 Thread    NtUserGetMessage    Normal
Unflagged       20020   0   Worker Thread   TppWorkerThread NtWaitForWorkViaWorkerFactory   Normal
Unflagged       20588   0   Worker Thread   TppWaiterpThread    ZwWaitForMultipleObjects    Normal
Unflagged       21364   0   Worker Thread   joyMonitorThread    NtDelayExecution    Lowest
Unflagged   >   21464   0   Main Thread Main Thread GetMessage  Normal
Unflagged       22800   0   Worker Thread   TppWorkerThread NtWaitForWorkViaWorkerFactory   Normal
Unflagged       23044   0   Worker Thread   EtwpNotificationThread  ZwTraceControl  Normal
Unflagged       23460   0   Worker Thread   timeThread  ZwWaitForMultipleObjects    Time Critical
Unflagged       24056   0   Worker Thread   TppWorkerThread NtWaitForWorkViaWorkerFactory   Normal

wait around 10 s

Unflagged       21464   0   Main Thread Main Thread wxIdleWakeUpModule::MsgHookProc Normal
Unflagged   >   9864    0   Worker Thread   Audio - OpenAL      Normal
Unflagged       19048   0   RPC Thread  RPC Callback Thread NtDelayExecution    Normal
Unflagged       19444   0   Worker Thread   Win64 Thread    NtUserGetMessage    Normal
Unflagged       20020   0   Worker Thread   TppWorkerThread NtWaitForWorkViaWorkerFactory   Normal
Unflagged       20588   0   Worker Thread   TppWaiterpThread    ZwWaitForMultipleObjects    Normal
Unflagged       23044   0   Worker Thread   EtwpNotificationThread  ZwTraceControl  Normal
Unflagged       23460   0   Worker Thread   timeThread  ZwWaitForMultipleObjects    Time Critical
Unflagged       24056   0   Worker Thread   TppWorkerThread NtWaitForWorkViaWorkerFactory   Normal

Solution

How is the deadlock potential removed?

Discussion

Should "Joining "Audio - OpenAL" 14772" be placed after "Joined "GPU""? i.o.w. should one thread be joined at a time

[05:34] @skid_au not necessarily

Why is the audio thread created despite "DSPThread = False"?

[05:46] @skid_au yeh, there is an "audio thread" where audio = XAudio2 or DSound or OpenAL
[05:46] @skid_au and then there is a "dsp thread" where dsp = DSP HLE or DSP LLE
[05:46] @skid_au two different things..
[05:47] @skid_au No Audio output backend does not have an audio thread

skid_au: #35 is updated with information that GPU deadlock is removed if audio is joined in GUI. This indicate that it's a circular wait between audio and GUI rather than GPU

is this true? is there a fifth thread that I've not considered that might be in a circular wait with the audio thread? I mean a thread not created explicitly f.e. those called "TppWorkerThread"

07:06] @Sonicadvance1 JP, have fun with me running Windows binaries :/

Audio

Empty call stack

Problem

The call stack of the preceding code with symbols is removed if a crash occur in OpenAL32.dll or wrap_oal.dll

Unflagged   >   23352   0   Worker Thread   Audio - OpenAL      Normal
wrap_oal.dll    C:\document\source\dolphin\repo\Binary\x64\wrap_oal.dll N/A N/A Cannot find or open the PDB file        95  2.01.8.1    2007-07-09 19:47    00000000275D0000-0000000027815000*  [20196] DolphinDF.exe: Native   
message in icon column  "the module did not load at the default load address"
No disassembly available.
Call Stack      empty

The message "the module did not load at the default load address" is present when it operates as intended too

The crash occur

  • before OpenALStream::SoundLoop execution (determined because the thread doesn't pause on breakpoints)
  • around 1 s after these messages
19:51:482 Src\OpenALStream.cpp:26 W[Audio]: Found device
19:51:483 Src\OpenALStream.cpp:28 W[Audio]:     OpenAL Soft
19:51:483 Src\OpenALStream.cpp:28 W[Audio]:     Generic Software
19:51:483 Src\OpenALStream.cpp:32 N[Audio]: Select device Generic Software
19:51:545 Src\Thread.cpp:118 N[COMMON]: Created "Audio - OpenAL" 8168

The problem also occur with

  • open OpenAL, dynamic build
  • open OpenAL, static build
  • non-open OpenAL, dynamic build

Solution

If a crash on function entry is caused by a stack size overflow the solution is

  • move arrays from stack to heap

The call stack isn't removed if a crash occur in a module without symbols

Malfunctioning state

Problem

The problem in the topic "Empty call stack" occur on consecutive runs

  • after the OpenALStream object has been removed before OpenALStream::SoundLoop has exited, because of a deadlock that's a result of an endless loop that's a result of an inadequate buffer size
  • when run from VS
  • not when VS is attached after the process is started
  • not when VS isn't attached
  • not when run from VS when using the 32 instead of 64 bit build
  • regardless of
    • build configuration
    • the setting Fastmem, DSPThread

for around 50 runs, of wich around 10 are consecutive with the problem

i.o.w. an environment state related to f.e. sound device allocation that it's sensitive to has changed

this state is without apparent reason undone so that the crash doesn't occur

The state that cause the problem isn't easily located because

  • the problem occur before the first breakpoint in OpenALStream::SoundLoop
  • the call stack is empty as described in the topic "Empty call stack"
  • it occur with the open OpenAL too

The most likely cause is a OpenAL build setting that affect debugging. However, OpenAl build settings related to debugging information have been altered without solving the problem

Solution

The solution isn't clear because it has occured with these OpenAL combinations

  • open OpenAL, dynamic build
  • open OpenAL, static build
  • non-open OpenAL, dynamic build

Step problem

Problem

At one observation, breaking at

memset(uiBuffers, 0, numBuffers * sizeof(ALuint));

and pressing step (F11) open the dialog "Find source: memset.asm"

f:\dd\vctools\crt_bld\SELF_64_amd64\crt\src\amd64\memset.asm

At two observations (in DebugFast and Debug), step (F11)

  • step past 200 lines from the the top to the lower code

    for (u32 i = 0; i < numSamples * STEREO_CHANNELS; ++i)
        dest[i] = (float)realtimeBuffer[i] / (1 << 16);
    
    for (u32 i = 0; i < nSamples * STEREO_CHANNELS; ++i)
        stereo[i] = (short)((float)sampleBuffer[i] * (1 << 16));
    

TracePoint problem

A TracePoint (of f.e. {i} {float32_capable} {surround_capable}) in OpenALStream::SoundLoop return messages similar to

Function: OpenALStream::SoundLoop(void), Thread: 0x5D50 Audio - OpenAL CXX0017: Error: symbol "i" not found
Function: OpenALStream::SoundLoop(void), Thread: 0x5E0 Audio - OpenAL CXX0017: Error: symbol "float32_capable" not found CXX0017: Error: symbol "surround_capable" not found 

This occur in

  • VS 10
  • VS 11

gyro emulation

gyro emulation

files

file/dolphin and image/dolphin contain

  • file/dolphin/input_*.zip: builds of input@john-peterson
  • file/dolphin/test/user/Config/Profiles/Wiimot: Zelda SS gyro input profiles in "Zelda SS*.ini"
  • image/dolphin/m+: pictures

gyro log

the gyro log output

            IR              wm acc              n acc               gyro            
41:46:028  0.00 -0.00  |  0.03  0.00  1.00 |  0.00  0.00  1.00 |  0.00 -0.00 -0.00 ***

emulated input

gyroscope and accelerometer input

https://github.com/john-peterson/dolphin-emu/blob/input/Source/Core/Core/Src/HW/WiimoteEmu/WiimoteEmu.cpp

in the input settings

  • "swing" is a force in the X, Y, Z directions that affect the accelerometer
  • "tilt" is a force in the pitch, roll, yaw directions that affect the accelerometer and gyro

Settings

Axis mouse input

Relative mouse input (called "Axis" in the mouse input configuration) should be used because that allow mouse movement input regardless of where the system cursor is compared to absolute input (called "Cursor" in the input configuration) who's input won't change when the cursor is at the screen edge

Range

Range, Gyro Range and Acc Range multiply the output by 0.01 x to 10 x (by setting its range 1 to 1000). The fast modifier activates the gyro fast mode for all three rotation directions, the fast and slow mode is explained here

gyro settle

https://github.com/john-peterson/dolphin-emu/blob/input/Source/Core/InputCommon/Src/ControllerEmu.h#L491

gyro settle determine after how many frames the gyro will return to zero after the wiimote stop moving (the wiimote is constant but not necessarily nonzero)

a high setting, for example 9999, will keep the gyro in constant motion if input is nonzero

Mouse and keyboard

Gyro Sensitivity: 200 works with a standard sensitivity mouse

IR sensitivity: 20 to move the vertical accelerometer position relatively slowly.

Gamepad

Gyro Range: 0.1 provide smooth aiming and a smooth cursor, the range modifier is set at 1000 (10x)

If the Gyro Range is 0.2 the Range modifier should be 500 (5x) to reach 1.0 with max input

Zelda SS

Moves

Swing sword left/right: yaw left/right

Swing sword up/down: pitch up/down

Stab attack: thrust forward + show IR

Spin attack left/right: yaw left/right + nunchuk thrust in any direction

Land/water spin attack up/down: pitch up/down + nunchuk thrust in any direction (or wiimote thrust forward/backward + nunchuk thrust in any direction)

Skyward charge: pitch accelerometer back (gyro range must be lowered enough that it doesn't trigger a swing)

Fatal blow: lock on enemy + wiimote thrust forward + nunchuk thrust forward
Shield: nunchuk thrust in any direction

Roll: dash and nunchuk thrust in any direction

Leap on vine: Nunchuk stick left/right + tilt fast left/right

Balance on the tightrope: Strong yaw input (slow 0.5+ or fast 0.1+)

Key binding

Have the Gyro Range low by default, for example 0.1, to control the cursor and view, and assign a 10 x (range 1000) Gyro Range modifier to a gamepad trigger (or keyboard button or analog stick button) and hold it to perform fast moves; slash sword, leap on vines, swing on rope, shake rope etc.

On the gamepad, bind roll and yaw to the same axis, roll and yaw is used independently in rare occasions only (the boss key for example) so it doesn't hurt, and lets you control the bird or the beetle that use roll.

Use the | OR option with the modifier keys and moves that require multiple input. For example assigning A|B to yaw left and B to Nunchuk thrust makes A yaw left and B do the spin attack.

"Hide IR" should be enabled (and Thrust forward and B should be bound to IR→ Show) because IR restrict horizojntal cursor movement and doesn't have rotation use besides resetting the gyro rotation matrix forward direction

FAQ

Q: Why's the aiming or cursor sensitive
A: Lower the sensitivity setting

Q: Why's the aiming or cursor jumpy
A: Disable Tilt accelerometer input with "Acc. Range"

Q: The cursor is locked along the horizontal axis
A: It's because the cursor can't go to the edge of the screen if IR is visible, turning off IR solve that. Without IR data, 45° yaw move the cursor from one edge of the screen to the other, if additional yaw is applied to cursor move along the screen border

Q: The cursor drift vertically to the center (doesn't affect aiming mode)
A: Too little accelerometer pitch is applied because the IR pointer position is not at the end of the screen, possibly because of too low IR sensitivity, the IR implied pitch code is here, as the IR is pointing at the end of the screen (mouse input -1 or 1) the pitch is pi/4 rad (45°).

Q: Why is the item selection cursor difficult to control?
A: Bind "Thumb R" or B to "Gyro Range 1" that's set to 1000 (10× multiplier) so that adequate gyro range is applied when selecting item. Because the item selection cursor work the same way as the map cursor so that good IR position data control it. Without IR data a 360° degree pitch rotate the cursor past the whole item circle. In the example gamepad configuration and bound to

Q: Why's the Bird, the Beetle and Swimming hard to control? Sometimes the unit moves sideways on its own.
A: Showing IR (that you may have set to the stab attack key) makes these controls easier, just showing IR for for a moment (at the center of the screen position) will reset the gyro rotation matrix so that the unit swim or fly straight again. To gain altitude with the Bird repeatedly dive and immediately call the Bird.

Q: Why is it hard to rotate the sword to enable the Skyview Temple Eye Switch?
A: A perfect circle can be created without IR data but IR data is important to reset the gyro rotation matrix forward direction

Q: How do I reset the sword neutral position (gyro rotation matrix)?
A: Show IR for a moment

Q: How do I pull the Goddess Sword out of the stone in the Goddess Statue?
A. Tilt 90° (full tilt input at 100 acc. range) downward and thrust backward

Red Steel 2

Moves

Swing sword left/right: yaw left/right
Swing sword up/down: pitch up/down

Benchmark

Benchmark

Files

The benchmark files are in

Dropbox

  • benchmark.txt
  • benchmark_summary.txt

SkyDrive

  • benchmark.xlsx

Configuration

normal

GFXBackend = DX11
EFBScale = 6
MaxAnisotropy = 3
EFBAccessEnable = True
DSPHLE = False

normal_athread

DSPThread = False

fast

GFXBackend = DX11
EFBScale = 2
MaxAnisotropy = 3
EFBAccessEnable = False
EFBCopyEnable = False
DSPHLE = False

fast_hle

DSPHLE = True

Movies

Length

The target length is

  • fixed because that makes the LLE and HLE movie comparable (because it draws the same geometry and audio)
  • one lap or 2 000 frames because that's adequate

Deterministicity

Producing dual thread benchmarks to

  • measure performance during play rather than when input synchronisation isn't important f.e. during an intro
  • compare LLE and HLE when video is threaded

is made difficult for some games because of desynchronisation described in this post that cause f.e. the controlled object to hit a wall repeatedly

Audio

Why's

  • HLE compared to LLE despite audio threading: 1,13

Video

Why's

  • DX9 compared to DX11: 1,08

GFZE01

Why's

  • HLE compared to LLE: 1,16
  • dx9 compared to dx11: 1,03
  • unthreaded LLE compared to threaded: not less than 0,95

GTEE01

Why's

  • HLE compared to LLE: 1,29
  • dx9 compared to dx11: 1,25
  • unthreaded LLE compared to threaded: not less than 0,96

SMNE01

Why's

  • OpenMP compared to non-OpenMP: ,65

Dolphin Relicensing

Hey there again. Just wondering if I could get a yes or no from you on the topic of re-licensing Dolphin from "GPLv2" over to "GPLv2 or later".

Here's the two spreadsheets related to this. One for those who have agreed/disagreed to it already, and one on the details of why this would be occurring.

If anything else is needed, I suppose you could just pop into the dolphin-dev channel on freenode and things can be clarified.

Click Right Button on Games not work

I use the version of Dolphin 4.0.1 on Windows 7 64-bit

When I go to press the right mouse button on a video game that was recorded in DVD the properties window does not appear, instead appears in its place the word as image.
Error
While the same disc / game that was present in ISO format on my hard-disk did not give me any problems.

Sorry for my bad English I'm using google translator

Don't restart commit numbering at tags

Don't restart commit numbering at tags

The commit number at http://dolphin-emu.org/download should be

# numbered commit list
git rev-list --reverse HEAD|nl
# find hash from number
git rev-list --reverse HEAD|nl|grep 9000

rather than restarted at tagged commits because

  • the restarted list is a complex command (what's the command?), the non-restarted list is a simple command
  • a count restart at tags makes it harder to determine a commit's ordinal position (f.e. the number of commits between 1,0-1 and 2,0-1 is unknown from that information)

Examples of programs that don't restart commit numbering at tags

  • VMware® Workstation 9.0.2 build-1031769

GameCube widescreen geometry missing

GameCube widescreen geometry missing

Problem

With the widescreen hack

on-screen geometry is frequently missing (at the edge of the screen) in Metroid Prime and Metroid Prime 2

Solution

How is the geometry occlusion limit increased so that on-screen geometry is less likely to be missing?

Memory

Memory

Problem

In the Debug build

  • memory isn't freed
  • memory use grow by 0,05 MB/s from process start

because

_CRTDBG_DELAY_FREE_MEM_DF (added in e4785df) keep freed heap to allow detection of read/write to it

Log

This is the output from closing a Crazy Taxi NTSC emulation twice for

the Debug build

50:42:490 Src\Core.cpp:491 I[CONSOLE]: Stop [Video Thread 24932]    504 616 K  Shutting down HW
50:42:653 Src\Core.cpp:493 I[CONSOLE]: Stop [Video Thread 24932]    441 020 K  HW shutdown
50:42:747 Src\Core.cpp:266 I[CONSOLE]: Stop [Main Thread 4480]  404 232 K  Main Emu thread stopped

51:03:993 Src\Core.cpp:491 I[CONSOLE]: Stop [Video Thread 18156]    812 644 K  Shutting down HW
51:04:163 Src\Core.cpp:493 I[CONSOLE]: Stop [Video Thread 18156]    749 084 K  HW shutdown
51:04:248 Src\Core.cpp:266 I[CONSOLE]: Stop [Main Thread 4480]  713 228 K  Main Emu thread stopped

the DebugFast build

48:24:582 Src\Core.cpp:491 I[CONSOLE]: Stop [Video Thread 20200]    334 960 K  Shutting down HW
48:27:126 Src\Core.cpp:493 I[CONSOLE]: Stop [Video Thread 20200]    126 264 K  HW shutdown
48:27:218 Src\Core.cpp:266 I[CONSOLE]: Stop [Main Thread 16532]  69 620 K  Main Emu thread stopped

48:47:768 Src\Core.cpp:491 I[CONSOLE]: Stop [Video Thread 7332] 333 444 K  Shutting down HW
48:51:567 Src\Core.cpp:493 I[CONSOLE]: Stop [Video Thread 7332] 127 692 K  HW shutdown
48:51:654 Src\Core.cpp:266 I[CONSOLE]: Stop [Main Thread 16532]  71 012 K  Main Emu thread stopped

Solution

_CRTDBG_DELAY_FREE_MEM_DF should be disabled because

  • memory allocation is significnatly lower
  • it can esasily be enabled if a heap corruption is suspected

Place dependencies in submodule

Place dependencies in submodule

Library builds in submodule

Problem

Library builds should be in a submodule because

  • compared to source libraries it's faster to change to the right version when checking out an old version

Solution

Placing library builds in a submodule repo

Library code in submodule

Problem

The dependencies aren't in a submodule

The folder "Externals" is

  • in 4% (441) of commits
  • 64% (89 MB) of the size
  • can be reduced to 13 MB
git clone git://github.com/mirror/dolphin-emu.git .
git rev-list --all|wc -l
10793
git rev-list --all -- Externals/|wc -l
441
du -h -d1
140M   ./.git
55M    ./Externals
217M   .

# remove "Externals"
git filter-branch -f --tag-name-filter cat --prune-empty --tree-filter "rm -rf Externals/" -- --all
git filter-branch -f --tag-name-filter cat --prune-empty --index-filter "git rm -rf --cached --ignore-unmatch Externals/" -- --all
git reflog expire --verbose --expire=now --all
git gc --prune=now
git rev-list --all|wc -l
10591
git rev-list --all -- Externals/|wc -l
0
du -h -d1
51M    ./.git
72M    .

# estimate compressed squashed "Externals" size
tar vczf test.gz Externals/
du -h test.gz
13M    test.gz

Solution

  • remove dependencies from history
  • place dependencies in a submodule

because

  • no dependency changes in history (because the submodule history is separate)
  • the dependency history use much space and has little meaning
  • the dependency history can be squashed to reduce its size: from 89 to 13 MB
  • smaller non-dependency repo: 51 instead of 140 MB
  • allow accurate statistics regarding repo size and activity
  • other popular repos do this, f.e. https://github.com/mpc-hc/mpc-hc

The submodule history shouldn't be squashed if

  • it makes it harder to build an old version because the right submodule version doesn't exist

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.