Emulator

Issue 427 has been merged into this issue.

Also, a drop-down box for compiler can replace the old Interpreter/JIT. This way we
can easily call the JIT WIP class in a different name (i.e. class JitIR64) and add a
combobox item to it for smooth testing/merging.

Or make the core a plugin as well (JIT, JIT WIP, Interpreter) ;)

yes in this way many game crashes problems will be solved

I can see this being handy in the debugger. I don't think a plethora of options
should be in the main app...it should just use what works. If block linking is
causing problems, fix it or disable/remove till it's fixed.

block linking is already disabled since r1596 because it is said to be an "unsafe"
optimization, but since then, some specific games run way slower than before (..)

making it a plugin sounds like an overkill if some specific option is important I
think it might be nice to have it as an optional method.
But do be aware that every option you add will add various ifs to the code
and that in turn will make things slower...

What about adding those options to an specific game and not all? Like, for example,
adding the speed hack for Pokemon Colosseum and Smash Bros Melee only. So the games
having issues with the speed hack won't be affected.

Adding the hacks is not adding more branches... They already exist but have to be
changed at compile time. What's more, people don't know they can activate these hacks.

I never said that the core is a plugin, it is a serious part of the emulator and its
core element (duh)... But: Interpreters are already divided into classes
(Interpreter, Jit64 and the Jit64 IR copy), just adding a combo-box to choose which
one to use (again, not during the run of a game but in the configuration menu) and it
will work smoothly. All it takes is to change the IR JIT class name and add the
corresponding drop down.

As for the hacks, it should be done by someone who knows all of them, safe and
unsafe. Those need to be enumerated for some other person to GUI code them. That's
why I CCed the specific people who might know the intricates of the JIT and others
who know how to code WX UI.

Team work, people! The building blocks of success are the developers and teamwork is
the cement!
:) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :)

I generally don't think adding more options is appropriate... instead of adding more options to the GUI,
we should really be fixing known-unsafe optimizations to be safe. If there are hugely beneficial
optimizations which are difficult to make safe, we can add them to the Core configuration, like the
current "Optimize Quantizers" option.

If we want to make it easier for non-developers to try and isolate JIT bugs, we can extend the "CPU
mode" menu in the debugger to expose more options.

Sure, that's an option as well. Though if you want to test for speed you might not
want to run the debugger, is there a slowdown there?

Having the debugger running in and of itself shouldn't be a slowdown as far as I
know. If you can see any difference, please file a bug; we want the debugger to be
usable without worrying about slowdowns.

Uhm, I've tried a debug version of Dolphin myself and it runs horribly slow. The JIT
operates no more than 130Mhz and sometimes it can bring 4 fps ingame.

If you don't NEED debug build, use debugfast

Montecrudo: I think you mean running the debugger, which is also compiled with
release. Just run "dolphin.exe /d" or "dolphin.exe -d".

Now this is something to try in Playground :P

You should have a 'reset to defaults' button if there are more than a few options.

Hmm, I should be getting on this one later on...