Dolphin VS. Gecko OS

Started by Bully@Wiiplaza, December 06, 2012, 09:49:50 AM

Previous topic - Next topic

Bully@Wiiplaza

Things are weird!
I´ve made a code which works well on Gecko OS and everything (for me). But then there´s Dolphin and many people complained that it´s not working for them on the same game. How can that be? I don´t care myself, I wouldn´t use Dolphin anyways. However, the code only consists out of 04 ASM patches and gecko code type compares...
My Wii hacking site...
http://bullywiihacks.com/

My youtube account with a lot of hacking videos...
http://www.youtube.com/user/BullyWiiPlaza

~Bully

biolizard89

Quote from: Bully@Wiiplaza on December 06, 2012, 09:49:50 AM
Things are weird!
I´ve made a code which works well on Gecko OS and everything (for me). But then there´s Dolphin and many people complained that it´s not working for them on the same game. How can that be? I don´t care myself, I wouldn´t use Dolphin anyways. However, the code only consists out of 04 ASM patches and gecko code type compares...
Dolphin's code handler is identical to the latest GeckoOS, but as far as I can tell its hooking method is pretty weird.  GeckoOS hooks an SDK function e.g. PadRead or OSSleepThread, so that the code handler runs in the same context each frame.  I haven't checked the Dolphin source to verify, but based on how it was behaving with GeckoTunnel testing, it seems like it's not hooking functions at all -- Dolphin apparently just pauses the game ~60 times per second and branches to the code handler.  Needless to say, this will result in some dodgy behavior in many cases.  Also, Dolphin uses recompilation, which converts PowerPC opcodes to ASM opcodes in large batches.  It's plausible that this messes up ASM patch codes, although in theory a competently written recompiler would recompile whenever the ASM is written to.

Either of those issues could be the culprit... unfortunately I don't know of an easy solution.