Any of the compilers want to compile a build with fircresk8's new patch?
ok so really dum off topic question but how do you place the patch within dolphin...never done it before
(07-20-2010, 06:09 PM)fircrestsk8 Wrote: [ -> ]I'm assuming that this process is close to as expensive on the actual Wii, which leads me to believe that the Zelda programmers wrote it expecting it to only occur in the first frame in a new area. So I believe that for some reason the test that the game performs in order to check whether or not the map needs to be redrawn again is not working with dolphin for whatever reason.
While reading your reply earlier, I came to a similar conclusion. I don't know enough about those parts of Dolphin, but it doesn't sound far-fetched that Nintendo might have stored the map image in memory and keeps copying it.
Wasn't there a similar issue where Safe Texture Cache was required to see the map correctly?
(07-21-2010, 02:25 AM)Jack Frost Wrote: [ -> ] (07-20-2010, 06:09 PM)fircrestsk8 Wrote: [ -> ]I'm assuming that this process is close to as expensive on the actual Wii, which leads me to believe that the Zelda programmers wrote it expecting it to only occur in the first frame in a new area. So I believe that for some reason the test that the game performs in order to check whether or not the map needs to be redrawn again is not working with dolphin for whatever reason.
While reading your reply earlier, I came to a similar conclusion. I don't know enough about those parts of Dolphin, but it doesn't sound far-fetched that Nintendo might have stored the map image in memory and keeps copying it.
Wasn't there a similar issue where Safe Texture Cache was required to see the map correctly?
That would be Copy EFB to Ram, safe texture cache kills the mini-map just like the projection hack do except safe texture cache replaces the mini-map with a big ugly square.
Just tested your new patch and it is slower compared to your old one.
Obscured, that is odd, considering that i didn't make any changes that should affect the speed... Did you revert JIT_Integer? (I don't know whether or not that is necessary with r5925, the reason i don't do it myself is because i want to commit this patch eventually and reverting JIT_integer causes compatibility issues with Macs ).
If this is not the cause, it is possible that the wrong texture is being found. Check that the ZTP texture is being found by turning on the log window and changing the verbosity to warning. A message should pop up at some point (usually right after loading a game that is outdoors) saying which address was identified. If possible, you could compare this to the address that you get when using an earlier version of my hack. If they are different, something is definitely wrong.
I tested SVN 5889 with the old patch and SVN 5926 with the new patch from Lectrodes builds. I didn't catch any warnings from the logs.
Any way to speed this up a bit more without affecting graphics? Just needs about another 5 FPS - 10 FPS squeezed out of it if that is even possible.
I might try to make the option in the Opengl plugin a bit neater, like it is in the DX9 and DX11 plugin configuration.
I bought a new motherboard and upped my Q6600 from 3ghz to 3.6ghz, Zelda Field is the only game that didnt speed up, Patch or no patch.
3ghz w/patch - 25fps
3.6ghz w/patch - 25fps
Just incase that helps any. I dont think CPU speed is the bottle neck.
Mario Galaxy:
3ghz - 45-50fps
3.6ghz - 59-65fps
(07-22-2010, 09:39 AM)obscured Wrote: [ -> ]I tested SVN 5889 with the old patch and SVN 5926 with the new patch from Lectrodes builds. I didn't catch any warnings from the logs.
I actually forgot to revert JIT_Integer in R5926. I am working on an updated build with both the new patch and the reversion of JIT_Integer (as a patch I call it "SFX64" If it doesn't have that beneath the revision number on my site, then that revision still has "StoreFromX64" in JIT_Integer).