Hyrule Field Slowdown Observation

**StripTheSoul** · 07-05-2010, 05:32 PM **#451**

wouldn't it be easier to just open a new thread for this one? -_-

fircrestsk8 · (This post was last modified: 07-07-2010, 02:48 PM by fircrestsk8.)

Sorry, I went on a little July 4th vaca before i had a chance to do any more work on the plug in. Next thing on the list is to add the patch to openGL and the directx 11 plugins (Should i even bother with the software renderer?). This is going to be a little trickier than i thought, because the plugins all seem to be organized differently, particularly in their GUI code. This means I probably won't be able to just copy and paste the toggle code from the Direct X 9 plugin like i had hoped.

Next I will do some speed checking. Obscure has reported that my patch is a little slower than Kiessel-stein's. This is due either to the additional condition testing in my hack (code before flushpipeline() ) or the additional flushes that my hack allows through (which are the cost of restoring the textures). If the latter is the culprit, the hack can only be sped up changing the logic conditions that allow flushes through (which will likely break at least some of the textures again). If the slowdown is occuring only in the BPWrite() function (the conditional testing), then the implementation of my logic checking should be examined to see if a faster method exists (like Jack frost's method).

Where did my last post go?

**Xtreme2damax** · 07-07-2010, 02:58 PM **#453**

Lol it did it again..

I think we should just start a new thread. Tongue

**skid** · 07-08-2010, 09:57 AM **#454**

I tried to fix this thread by copying to another forum and back. Not sure if it worked. Didn't seem to help for me.

emu-muncher · 07-08-2010, 01:45 PM **#455**

i managed to read the hidden posts by clicking "view a printable version" at the bottom of the page....guess this wont help anyone if no1 can read it...

obscured · (This post was last modified: 07-08-2010, 02:04 PM by obscured.)

Actually the newest builds with your patch are faster now. I'm getting 81%-95% speed.

(07-07-2010, 02:47 PM)fircrestsk8 Wrote: Sorry, I went on a little July 4th vaca before i had a chance to do any more work on the plug in. Next thing on the list is to add the patch to openGL and the directx 11 plugins (Should i even bother with the software renderer?). This is going to be a little trickier than i thought, because the plugins all seem to be organized differently, particularly in their GUI code. This means I probably won't be able to just copy and paste the toggle code from the Direct X 9 plugin like i had hoped.

Next I will do some speed checking. Obscure has reported that my patch is a little slower than Kiessel-stein's. This is due either to the additional condition testing in my hack (code before flushpipeline() ) or the additional flushes that my hack allows through (which are the cost of restoring the textures). If the latter is the culprit, the hack can only be sped up changing the logic conditions that allow flushes through (which will likely break at least some of the textures again). If the slowdown is occuring only in the BPWrite() function (the conditional testing), then the implementation of my logic checking should be examined to see if a faster method exists (like Jack frost's method).
Where did my last post go?

**Xtreme2damax** · (This post was last modified: 07-08-2010, 02:26 PM by Xtreme2damax.)

(07-07-2010, 02:47 PM)fircrestsk8 Wrote: Sorry, I went on a little July 4th vaca before i had a chance to do any more work on the plug in. Next thing on the list is to add the patch to openGL and the directx 11 plugins (Should i even bother with the software renderer?). This is going to be a little trickier than i thought, because the plugins all seem to be organized differently, particularly in their GUI code. This means I probably won't be able to just copy and paste the toggle code from the Direct X 9 plugin like i had hoped.

Next I will do some speed checking. Obscure has reported that my patch is a little slower than Kiessel-stein's. This is due either to the additional condition testing in my hack (code before flushpipeline() ) or the additional flushes that my hack allows through (which are the cost of restoring the textures). If the latter is the culprit, the hack can only be sped up changing the logic conditions that allow flushes through (which will likely break at least some of the textures again). If the slowdown is occuring only in the BPWrite() function (the conditional testing), then the implementation of my logic checking should be examined to see if a faster method exists (like Jack frost's method).
Where did my last post go?

There is no point adding it to the software plugin. The software plugin is primarily for development and contains no configuration ui, it is also far too slow to benefit from this patch in any way.

I'm not sure what conditions Obscure was testing under, but for me your patch is as fast as Kiesel-Stein's patch without any of the side effects that Kiesel-Stein's patch has in other games.

obscured · 07-08-2010, 02:34 PM **#458**

My testing isn't all that accurate because it compared build 5030 with the old patch and multiple newer builds with his. I did it for comparisons sake and wouldn't be apples to apples unless I got the old patch put in a newer build.

**darkshadw** · 07-08-2010, 09:41 PM **#459**

Hit me if this is a stupid question but... Could it be possible to first load the hyrule field before showing the screen? (If you know what i mean :p).

**StripTheSoul** · (This post was last modified: 07-09-2010, 05:26 AM by StripTheSoul.)

you mean "preload" the whole field so that Dolphin doesn't have be working all the time?

@ Xtreme: Do you happen to have a new build (with Rodolfo's Hybrid system) ready with the Hyrule-Patch? :>

Aaah, nevermind, I just found it ^^