Hyrule Field Slowdown Observation

[shortzi]

Ok, another 2 builds, this time i compiled r5030 as it has always been faster for me. Also has the Zelda Audio Fix!!

X32 http://www.mediafire.com/?llmlz3wfmwo

X64 http://www.mediafire.com/?m4nlymzdzm4

So, Speed wish for me is this...

Patched R5030 - 27/28fps
Patched R5413 - 19/20fps
Unpatched Both - 12fps

BTW i am using a PAL Version of Zelda running in 60hz Mode

[blubb]

Speedup somehow doesn't work for me either, though I tested both EFB to RAM vs EFB to Texture and D3D vs OpenGL and I still get only 16fps (D3D)/ 14 fps (OpenGL) no matter what I do (x64 and Hyrule Field is completely discovered). Plus, like before, I get only 23fps in Faron Woods (also completely discovered).
I copied the folder "Users" from another build so that I didn't have to re-configure everything, but that shouldn't matter, or should it? BTW I get graphical glitches like distorted in-map warp portals and text issues ("Li" instead of "Link") too, but I don't care too much.
Can someone for whom the patch works post their settings?

EDIT: Tested the 5030 release, now it's at least 21-22 fps (Hyrule Field), however I still believe I did something wrong because there was no change at all with 5413 and for me it would have only jumped from 16 to 21-22 while it should have gone to 30 if I interpret the previous post correctly

[Jack Frost]

(04-27-2010, 07:04 AM)Xtreme2damax Wrote: This should fix the texture issues, should also work for Kiesel's patch as well:

Code:

if (((u32*)&bpmem)[bp.address] != bp.newvalue && ((bp.address & 0xF0) < BPMEM_TEV_COLOR_ENV+32 || (bp.address & 0xF0) > BPMEM_TEV_ALPHA_ENV+32))

Notice that I added a +32 after BPMEM_TEV_COLOR_ENV so the code looks like the above sample. It's still a bit random, but better than before.

---

Gah, never mind for now as adding that +32 seems to have made it just as slow as without the patch.

Speaking of random, your patch does this:

Code:

if (((u32*)&bpmem)[bp.address] != bp.newvalue && ((bp.address & 0xF0) != BPMEM_TEV_COLOR_ENV+32))

His patch flushed whenever its not part of the Texture Environment stuff (BPMEM_TEV_COLOR/ALPHA_ENV), while yours only flushes when its not the 16th Texture Environment Color.

[jakeslogan]

wow the new one(5030) is better than the old one, in Hyrule field, when i faced the castle i got 19-20fps if i turn the camera to the field direction, i got 16-18fps.

[Xtreme2damax]

(04-28-2010, 03:56 AM)Jack Frost Wrote:

(04-27-2010, 07:04 AM)Xtreme2damax Wrote: This should fix the texture issues, should also work for Kiesel's patch as well:

Code:

if (((u32*)&bpmem)[bp.address] != bp.newvalue && ((bp.address & 0xF0) < BPMEM_TEV_COLOR_ENV+32 || (bp.address & 0xF0) > BPMEM_TEV_ALPHA_ENV+32))

Notice that I added a +32 after BPMEM_TEV_COLOR_ENV so the code looks like the above sample. It's still a bit random, but better than before.

---

Gah, never mind for now as adding that +32 seems to have made it just as slow as without the patch.

Speaking of random, your patch does this:

Code:

if (((u32*)&bpmem)[bp.address] != bp.newvalue && ((bp.address & 0xF0) != BPMEM_TEV_COLOR_ENV+32))

His patch flushed whenever its not part of the Texture Environment stuff (BPMEM_TEV_COLOR/ALPHA_ENV), while yours only flushes when its not the 16th Texture Environment Color.

Any ideas how to give that extra bit of speed without messing up any textures?

[ZEROx]

This speed difference between 5030 and 5413 caused by last Jit changes, which was from 5180 to 5280, so i just reverted those changes to play on new rev wuth nice speed

[kiesel-stein]

Sorry, i didn't look at this forum in two days. I was working on getting dolphin to run on mesa/intel drivers (not for getting it to run at reasonable speed, but just getting it to run to find a few bugs in that driver).

(04-27-2010, 02:14 AM)Xtreme2damax Wrote: @Kiesel, are you still here? We would like to know how you came to this conclusion and what your experience with emulation and coding is.

I first tried various profilers on dolphin, but had no good results with that. The steps that led to this proof of concept patch were the realisation that the gpu thread used a full core while everything else was more or less idle, and that most of the time is spent in nvidia driver. Then i found the "Save Targets" video debug feature and wondered why dolphin stalled while only writing to a single file. A quick patch later, the dump directory instantly filled with thousands of files, every one differing just by a few pixels, and all of them from rendering the map. The rest was setting a breakpoint at the right place and identifying the BP write as the problem.

For my emulation/coding experience: i am privately improving a gameboy emulator written in pascal, but my other/newer projects are c/c++(mostly). I am currently working on my german Diplom(that is something in between bachelor and master) in computer science.

Code:

if (((u32*)&bpmem)[bp.address] != bp.newvalue && ((bp.address & 0xF0) < BPMEM_TEV_COLOR_ENV || (bp.address & 0xF0) > BPMEM_TEV_ALPHA_ENV+32))

The first compare of this is a leftover from an earlier test, the real trick is disabling the flush for bp.address == BPMEM_TEV_COLOR_ENV and bp.address == BPMEM_ALPHA_COLOR_ENV. The & 0xF0 is from a quick copy-and-paste from some lines later in that function.

Code:

if (bp.address < BPMEM_TEV_COLOR_ENV || bp.address > BPMEM_TEV_ALPHA_ENV+32)

would result in the same effect.

Normally, flushing after changing any bp.address is mandatory, but the side effects on the map are not too visible. Unfortunately, the other glitches are due to not flushing after these bp writes. A "proper" hack would identify whether the game is currently rendering the map and disable the flushing only then.

[Jack Frost]

(04-28-2010, 04:25 AM)Xtreme2damax Wrote: Any ideas how to give that extra bit of speed without messing up any textures?

Nope, sorry, I actually have no idea what that part of the code does or why textures break

[Xtreme2damax]

Damn, I guess this issue remains at a standstill and there isn't anything that can be done until a some developers can review the information that was posted so far and start working on fixing this issue.

I am almost certain that if this issue is fixed, there will be other games that will benefit. We might even see most if not all games be able to achieve full playable speeds providing specifications are adequate enough.

I really wish I could be of more help, unfortunately I don't know how to code and just tend to experiment to see if there is anything I can fix without breaking anything in the process.

[Jack Frost]

My guess it that skid's FIFO changes might be just what we need. Stuff blocks and hangs in there where it shouldnt have to.