Emulator

pretty known issue :)

Issue 2580 has been merged into this issue.

issue 720 can be merged into this

Issue 720 has been merged into this issue.

I think some fairly nice breakthroughs have been made in the process of figuring out
what is causing this issue as outlined in the following thread:

http://forums.dolphin-emu.com/thread-7495.html

I would think it's about time for developers to give this issue a bit more attention
than it is receiving now that there is a general idea what is actually causing it.

That would certainly be ok for now as a short term solution. Although I would prefer
the issue to be properly fixed and can wait, some are a bit anxious to try to get any
extra bit of speed they can out of this area. The game is pretty much playable from
start to finish, except for a few issues.

I've tried helping the best I could to narrow this issue down for the developers, but
I am not of much use due to my lack of coding knowledge.

18 - 20 FPS is quite bearable for myself at least, but even better if Hyrule Field
would be able to run full speed in the future on a reasonably spec'd machine.

Skids upcoming Fifo fixes might be the answer to this, but I don't know as this is
indeed quite the odd issue.

I'm just wondering if this was fixed, would other games benefit as well? If other
games could benefit and have a nice increase of performance then this issue might be
worth looking into and fixing. :)

I mentioned in http://code.google.com/p/dolphin-emu/issues/detail?id=720 that is sounds
like a missing feature in the GPU. Most likely it is view frustum culling or object
occlusion.

Btw acrion, the information provided in this thread seems to point to it being a fifo
issue, unless you can provide some information or test/debug results that would
determine otherwise:

http://forums.dolphin-emu.com/thread-7495.html

A quick note to developers, I think Kiesel-Stein is correct in saying that the
bpstructs/texture environment is causing most of the issues with slowdowns.

Using his patch and reverting Jit_Integer.cpp by removing the line StoreFromX64, I've
seen a tremendous speedup and am now getting around 25 - 30 FPS in the slowest Hyrule
Field.

Kiesel mentioned that most of the time was being spent in the Nvidia driver and the
gpu thread was consuming a full core, could it be possible this issue is Nvidia
specific or affects certain cards and/or driver versions?

The only problem with Kiesel's patch is that is messes up textures and effects in
some games, if a way can be found to give that extra speed without messing up
anything else that would be great.

Yeah, applying the same trick I got some glitch issue (very rare) but I get it run at
65-70% in hyrule field, where it was something like 30% before :D

Culling of offscreen and distant Geometry seems to be most of the issue, optimizing the pipeline flush could also benefit Zelda: Twilight Princess and other games. In addition to the former two, I think fixing the issues with the fifo and fifo optimizations could also help eliminate most of these performance issues in Dolphin.

It's not just Hyrule Field. The issue exists in Faron Woods as well.

It doesn't, your PC is probably just too crappy/underpowered to play the game full speed. It's already been verified that everywhere else in the game runs full speed except Hyrule Field.

That depends. Do you call a 2.4GHz Intel Core 2 Duo with 4GB of system RAM and an nVidia Quadro 770M with 256MB of dedicated graphics memory crappy??

@ thesecondM
Your CPU isn't the greatest.

It is one heck of a lot more powerful than the CPU in the Gamecube. With efficient emulation, it wouldn't have a problem.

You don't know what you're talking about.

hum, the hack is indeed helping a bit but I wouldn't consider the issue fixed.

I play Zelda TP on my msi laptop dual core 4gb ram, nvidia gf 8200mG, i get 17 fps when running in forest (not been to Hyrule jet). Can anyone post the best configs to set my dolphin so that it runs the fastest posible on my laptom pc ovo ono?

get a better computer

GPU is too weak ; and the CPU must be too old certainly (like the GPU).+1 Sonicadvance

Any progress on this issue?

I have very good speed in Hyrule field, but it's a bit less than anywhere else, 70-80% of normal speed. But it's okay, very playable, not a problem at all.

My specs:
Mainboard: Asus Crosshair IV Formula | Ram: G.Skill Flare 2x2GB CL7 DDR3-2000 (not OCed) | GFX: Nvidia GeForce GTX 260 (not OCed)
CPU+Cooler: AMD Phenom II X6 1090T BE @ 3,72 Ghz (Auto-OCed by Mainboard) + Prolimatech Megahalems Rev.B (+ 2x Enermax Everest 12cm)

My Dolphin settings:

Dolphin Configuration
http://img443.imageshack.us/img443/3889/dolphin01l.gif

Graphics Configuration
http://img819.imageshack.us/img819/5584/dolphin02.gif

Twilight Princess Configuration
http://img849.imageshack.us/img849/5548/dolphin03.gif

Yes, I don't use DirectX (sometimes the game freezes, not with OpenGL). And yes, I don't use MMU any time (it's not needed and slowdowns the whole game).

The only issue so far > the howl bug. My solutions:

1st Solution: Make a savestate before any howl stone. Now try to howl or load the savestate if it freezes. Sometimes it will work till the end of the whole sequence.

2nd Solution: Save the game at any howl stone (maybe savestate). Now exit Dolphin and open the DSP Settings. Change "DSP HLE emulation" to "DSP LLE interpreter". Now start the game again and load your save. It will be a bit laggy, but howl should work 100%. After the sequence, save again and change back the DSP setting. Done.

We should try to optimize here more, but I don't see many ways to do it.

In fact, dolphin usually do this for the mipmap:
for() {glUseProgram(a); glDraw(triangle); glDraw(points); glUseProgram(b); glDraw(triangle); glDraw(lines);}

imo we can optimize that we don't have this shader switches, but we still have to draw different primitive types. So there is no big chance :-(

What do you think about some AR codes to hack the mipmap of the game itself?

Degasus: Can other parts of Twilight Princess be optimized to counter act this? I go from 34 fps to 24 fps with and without the hack respectively. If we could free up a small percentage, anyone with good graphics cards should be able to handle it full speed on OGL at least. D3D seems to have too much overhead to pull it off right now.

It's more because of the cpu performance

Yeah, but my onboard card slows to a crawl anyway, so I don't have a good benchmark for what that needs to compare.

An AR hack should be able to get the same result as the ZTP hack did, "just" NOP out the things that lead to emitting one of the two the state changes. When i'm home again, i'll try to figure out exactly what addresses need to be dropped, but someone else would have to figure out an AR code to go along with that. Provided ZTP doesn't do any fancy memory mapping, that is.

pierre: good news, just press pause ingame and there is a huge chance that the game is in the minimap generation code.

@degasus: not that easy. Assuming TP uses the same engine as TWW, they have a multithreaded engine with several level of task queues for rendering.

Hmm. Could prove more challenging than i expected, then. I planned to backtrack from the ZTP hack itself, through the fifo(should be easy in single core mode) and then to the corresponding code, but it looks more likely i need to work with data breakpoints inside dolphin and savestates, then.

Results:
nop at these 8 locations lead to a similar result as the hack itself:
8003d63c 8003d658 8003d670 8003d68c 8003d6e8 8003d704 8003d71c 8003d738

actually, the whole areas at 8003d628-8003d68c and 8003d6d4-8003d738 could be dropped. the code there only sets up parameters to the function calls removed above.

If you are testing on WII, or US game, these locations probably are somewhere else. This was on GZ2P01. Also, one could just patch a branch at 8003d628 and 8003d6d4 to skip those areas.

pierre: nice. btw, nops are faster than branches as our jit skips nops.

pierre: What's the content of this area? Maybe it's the same on NTSC or Wii, so we can find it easier.

for RZDP01, the areas and addresses of the function calls are:
80040eb4-80040f04, 80040f48-80040fac. calls at 80040eb4, 80040ed0, 80040ee8, 80040f04, 80040f5c, 80040f78, 80040f90, 80040fac.
(i did not test this, but the code seems to be identical, ignoring the different address)

the actual code is:
(first part)
li r3,0
li r4,15
li r5,15
li r6,15
li r7,2
bl 8034a7f8
li r3,0
li r4,0
li r5,0
li r6,1
li r7,0
bl 8034a878
li r3,0
li r4,7
li r5,7
li r6,7
li r7,6
bl 8034a838
li r3,0
li r4,0
li r5,0
li r6,1
li r7,0
bl 8034a8d0
(second part)
li r3,0
li r4,15
li r5,14
li r6,8
li r7,4
bl 8034a7f8
li r3,0
li r4,0
li r5,0
li r6,1
li r7,0
bl 8034a878
li r3,0
li r4,7
li r5,7
li r6,7
li r7,4
bl 8034a838
li r3,0
li r4,0
li r5,0
li r6,1
li r7,0
bl 8034a8d0

these are the calls that produce the packets to program the TEV registers. after each set of these, a few vertices get emitted, then the thing loops back. it may be possible to separate these two sets of drawing operations while retaining the same(or similar) output, but that is a comparatively huge change.

This pull request: https://github.com/dolphin-emu/dolphin/pull/365 makes Hyrule Field go about 3 times faster (8 fps to 21 fps) in the D3D backend.

Figure it may be useful in the future for anyone who looks into this issue.

Yeah, the only way I know of is to speed up the video backends / videocommon. There is no broken design here

I have converted kiesel's nop patches into the Dolphin game.ini patch format and have found the offsets for the NTSC-U versions. Paste the appropriate version into the game ini to enable the speed hack in versions later than Dolphin 4.0-646.

GameCube NTSC-U
GZ2E01.ini
-----------------cut here--------------------------
[OnFrame]
$Hyrule Field Speed Hack
0x8003D50C:dword:0x60000000
0x8003D528:dword:0x60000000
0x8003D540:dword:0x60000000
0x8003D55C:dword:0x60000000
0x8003D5B8:dword:0x60000000
0x8003D5D4:dword:0x60000000
0x8003D5EC:dword:0x60000000
0x8003D608:dword:0x60000000
[OnFrame_Enabled]
$Hyrule Field Speed Hack
-----------------cut here--------------------------

Wii NTSC-U
RZDE01.ini
-----------------cut here--------------------------
[OnFrame]
$Hyrule Field Speed Hack
0x80040DE8:dword:0x60000000
0x80040E04:dword:0x60000000
0x80040E1C:dword:0x60000000
0x80040E38:dword:0x60000000
0x80040E90:dword:0x60000000
0x80040EAC:dword:0x60000000
0x80040EC4:dword:0x60000000
0x80040EE0:dword:0x60000000
[OnFrame_Enabled]
$Hyrule Field Speed Hack
-----------------cut here--------------------------

GameCube PAL
GZ2P01.ini
-----------------cut here--------------------------
[OnFrame]
$Hyrule Field Speed Hack
0x8003d63c:dword:0x60000000
0x8003d658:dword:0x60000000
0x8003d670:dword:0x60000000
0x8003d68c:dword:0x60000000
0x8003d6e8:dword:0x60000000
0x8003d704:dword:0x60000000
0x8003d71c:dword:0x60000000
0x8003d738:dword:0x60000000
[OnFrame_Enabled]
$Hyrule Field Speed Hack
-----------------cut here--------------------------

Wii PAL
RZDP01.ini
-----------------cut here--------------------------
[OnFrame]
$Hyrule Field Speed Hack
0x80040eb4:dword:0x60000000
0x80040ed0:dword:0x60000000
0x80040ee8:dword:0x60000000
0x80040f04:dword:0x60000000
0x80040f5c:dword:0x60000000
0x80040f78:dword:0x60000000
0x80040f90:dword:0x60000000
0x80040fac:dword:0x60000000
[OnFrame_Enabled]
$Hyrule Field Speed Hack
-----------------cut here--------------------------

thx @ skidau for writing AR codes

It seems that this AR codes only remove half of the affected minimap. The shadows are removed, but the points are still drawn.
pierre: Do you still care? Perhaps you still know where the game renders the points of the minimap?

That's actually all that is supposed to happen: shadows converted to map dots, the same as the original hack. The emission of the primitives happens in one of the later calls(bl), after the TEV has been set up, but i couldn't be bothered to find that. If anyone wants to figure out what other call needs to be "nop"'d to not draw the shadow dots, go ahead and try. Please post your results, so we can extend the patches.

Yeah, this is the same behavior as the old speedhack, but as we now flush the vertexmanager for primitive changes, we'd still do it by far too often :/

I've tried it as dolphin hack to just skip points and the flushes dropped from 10k to 1.8k and I was able to play fullspeed on my laptop ...

The offending primitive actually is emitted directly in that function; need to nop all instructions between 0x8003d68c and 0x8003d6e8 (the middle two in the above codes) to get rid of that.

pierre: so it's this one: http://pastie.org/9242795

The performance is fine on RZDP01.

it probably is safe the nop the whole range between $(first address)-7*4 to ($last address). Someone should check if omitting the read accesses to (rtoc) is a safe thing to do. otherwise, it should be sufficient to add address $(entry4)+4*4, +7*4, +9*4, +11*4, +13*4, +15*4, +17*4. In GZ2P01, those are 0x8003d69c, 0x8003d6a8, 0x8003d6b0, 0x8003d6b8, 0x8003d6c0, 0x8003d6c8, 0x8003d6d0.

Would using a branch or LR be neater?

My theory for the Hyrule Field slow down is that because its rendered in the game as one "room" rather than separate rooms. Early on in game I get about 25-27 FPS in Hyrule Field and then after the Goron Temple it slows down to about 14 FPS. Notice on the mini map that each area you go into, it becomes highlighted. Now if each of those areas loaded 'separately' as if you would go into a town or temple the FPS would be much better, but considering some of the quests you are to complete it would probably not work with the flow of the game. Its playable as is but I would rather have it run 22-30FPS like it does for the rest of the game, Hyrule Field is the only area where it slows significantly.

My Hardware: FX-4100 AMD 3.6 quad core processor, 6700HD Radeon 1Gb video card, and 8Gb RAM.

No. It's a result of the minimap rendering, and (I really don't know), but possibly some other factors, which would explain why the ZTP new hack is still slower than other areas.

Additionally, you're dead wrong that Hyrule Field is loaded as one area.

This isn't a place to discuss theories. Please take it to the forums.