Google Summer of Code

= About GSoC = http://code.google.com/intl/de/soc/

= Suggested Projects = This is a list of suggested projects. If any of these is actually feasible for a GSoC project needs to be evaluated, but this list should give some hints at areas that still need work in Dolphin.

Automated Test Suite
TODO: Description

Finish Qt GUI
TODO: Description

Sound Stretcher
TODO: Description There's http://www.surina.net/soundtouch/, but that's not a perfect solution when the framerate is not known in advance.

Proper GPU synchronisation
TODO: Description

Speedup Software Renderer
The current GPU accelerated backends in Dolphin have a huge disadvantage compared to software renderers: API restrictions. Lots of GC/Wii hardware features (zcomploc, destination alpha, zfreeze, compressed Z) can only be emulated with huge work and some dirty tricks or cannot be emulated at all because the functionality is not exposed by PC GPU APIs like Direct3D and OpenGL. With a software renderer on the other hand, you get all of these "hard to emulate" features for free but end up sacrificing performance if not done with speed in mind.

The goal of this project is to enhance (not replace!) the currently quite well-functioning software renderer with "fast" code paths. How exactly these "fast" code paths are implemented is free to the student. Some approaches include, but aren't limited to:
 * using SSE wherever possible (the other backends already have an SSE texture decoder)
 * vectorizing the renderer pipeline
 * making use of GPU accelerationg where feasible and possible without sacrificing accuracy, possibly making use of modern GPU features like compute shaders and transform feedback. Keep in mind this stuff should be cross-platform compatible though and we don't want to end up with "sub-backends", i.e. this is tied to using OpenGL.
 * Just-in-Time recompilation of software renderer code paths, using LLVM (if it's suited for the task) or a tailor-made JIT

More Accurate DSP HLE Emulation
Dolphin has two ways to emulate the Gamecube/Wii DSP: LLE (emulating a DSP program instruction by instruction as accurately as possible, requiring a lot of CPU power) and HLE (rewriting the DSP program behavior in C++, which isn't as accurate and requires a fair bit of reverse engineering but is a lot faster).

Historically the DSP HLE backend was in a very sad state: lot of bugs and non implemented features, behavior which did not make sense and did not match what the DSP program should be doing, etc. delroth has been working since November 2012 on a new DSP HLE implementation for the Gamecube AX DSP program, which makes things a lot better for games relying on that particular DSP program.

The same work could be done for the two remanining DSP programs in use: Wii AX and Zelda/IPL UCodes. This will require some reverse engineering (both PowerPC and DSP assembly) to understand how these two programs communicate with the main CPU and what they should do exactly to mix data in the same way the real hardware does it. Ideally some documentation should be written explaining how these UCodes work as well.