TODO List

This page is kind of a TODO list for the Dolphin project: project members add interesting ideas they don't have time to implement here. If you are a developer looking to contribute to Dolphin, picking one of these ideas might be a good way to start! Join us on IRC to ask for more informations if needed: #dolphin-dev @ Libera.

Hardware Errors Detection

 * Proposed by: delroth
 * Difficulty: average

A lot of people overclock their CPU and/or memory to run Dolphin at full speed. This could potentially cause stability issues misdiagnosed as bugs in Dolphin. I'm not sure if there is an easy way to check for this kind of issues because they are very random (compared to issues due to bad memory), but having this kind of feature might be a good way to avoid invalid issues.

Generate Crash Information on JIT Segfault

 * Proposed by: delroth
 * Difficulty: easy/average

When JIT-ed PPC code crashes because of an invalid memory access, the curent behavior is to display a cryptic message box to the user ("BackPatch - no support for operand size 1", or "Unhandled disasm case in write handler") and/or kill the whole program. This makes it hard to debug these issues after the crash happened because no debug information has been left behind.

Writing a crash dump file with the PPC backtrace, state of all the PPC registers, code of the JIT block that caused the crash + exact instruction causing the crash, and maybe information about the user hardware would be very nice.

Implement More Fastmem Methods

 * Proposed by: Sonicadvance1
 * Difficulty: average/hard

Fastmem/backpatch has long been a method in Dolphin to gain additional(5-15%) speed out of a game due to slow memory accesses. Currently this is only being done for 32bit loads. Memory accesses can be further sped up by supporting 32bit stores and then even moving down to the 16bit and 8bit loads and stores.

Fix CPUCompare

 * Proposed by: Sonicadvance1
 * Difficulty: average/hard

CPUCompare should be a very nice and easy way to directly compare the results between two CPU cores and see where they differ. A broken implementation has been in the source since open source birthing but nothing has been done with it. This could be gone about in a couple ways. Be it running two CPU cores side by side in the same program instance or two processes running and comparing real time.

Janitorial Tasks

 * Search for "Todo" in the source and try to work out how complete the todo.
 * Make it compile with no warnings. Make sure to use warning flags when compiling! * Do not fix warnings in code that you don't understand! * It's not worth the risk of breaking things.
 * Fix the easy issues or any of the other issues on our tracker.

Implement Post-Processing Shaders in D3D11

 * Proposed by: Sonicadvance1
 * Difficulty: average

The OpenGL back-end already supports post-processing shaders while the D3D11 back-end doesn't. Implementing this feature should allow persons to use the same shaders for both the D3D and OGL back-end by abstracting portions of the shaders out.

Add cURL Support

 * Proposed by: Parlane
 * Difficulty: average
 * Blocked by: Replace OpenSSL in wii-network

cURL is needed for the WC24 side of things and would also be beneficial to the "Check for updates" task below. We need to make sure we can have curl work with PolarSSL.

"Check for updates" Feature

 * Proposed by: Parlane
 * Difficulty: easy

Will require some changes on the website side, ping delroth if you want to work on that.

Qt GUI

 * Proposed by: neobrain
 * Difficulty: easy/average

There are lots of advantages of Qt over wxWidgets, and if you ever had to use one or the other you probably know why Qt rocks and why wxWidgets often is kind of "meh" to work with. The initial Qt GUI living in the dolphin-qt branch has been written by neobrain and recently brought up to date with recent master changes. Things left to do until a merge to master can happen include but aren't limited to:
 * Windows build files
 * Proper theming
 * Implementation of enough basic functionality so that daily usage is possible
 * Switching from Qt to wxWidgets and vice-versa needs to be possible without requiring a full rebuild.

Better Handling of MMIO Reads/Writes
Currently MMIO reads/writes go through Memory::{Read_Write}_U{8,16,32} even if we know the destination address. It should be possible to dispatch directly to the hardware module write function and avoid a call+dispatch at run time, but it requires a lot of refactoring in the HW MMIO interfaces to do nicely.
 * Proposed by: delroth

Ideally, HW modules should be able to provide ASM routines for some of their memory reads/writes and make things even faster for basic cases of "just read a global variable".

Macroblocks
Our Jit compiles PPC code block per block, with each block defined as a list of sequential instructions up to the next conditional or indirect jump. Including conditional jumps here would be extremely useful because larger blocks == less time spent spilling registers. However, having conditional jumps means having forks and joins, which aren't handled by our regcache at all. It also means some slight JitCache modifications.
 * Proposed by: delroth

Overall, that should give a nice performance boost but will also be fairly difficult: needs a new regcache, needs to think of a way to handle interrupt checking/downcount (we might need to leave in the middle of a macroblock and come back later - so the regcache might need to generate "resume trampolines").

Finally Implementing Floats/Paired Singles Properly
If someone could get a good test coverage with an homebrew program and work on a mostly JITed floats/paired singles implementation, it would reduce CPU usage by at least 5% in most games.
 * Proposed by: delroth

Separate single and double floats in the register cache
Because of the crazy paired singles design (one double and one single register), we do lots of expensive (checkout ppc_fp branch), redundant format conversions. Almost all of them could be avoided by converting on use, but the register cache would need a bit of redesign.
 * Proposed by: delroth

Busy Wait Loop Detection
If we could detect loops that exit only depending on some memory value, and this memory value is not written to in the body of the loop, we should know that it will never leave the loop unless an interrupt is raised. We can then stop scheduling the Jit until we get an interrupt.
 * Proposed by: delroth

Write new Guides

 * Postprocessing shaders (and remove Data/Sys/Shaders/README.txt from the source repository once that's written)
 * BBA guide
 * Developer workflow documentation