Axxer Wrote:I believe it is the fact that the entirety of Hyrule Field gets loaded, which causes pretty major slowdowns. The ZTP hack tries to dynamically load things if I am understanding it right.
lolwut?
What do you mean by "loaded"? It certainly isn't rendered:
Xtreme2damax Wrote:It doesn't render all of Hyrule Field, only the immediate area you are in. This was confirmed by testing with Free Look and Wireframe mode.
Does nobody know how to use the search feature?
Kiesel-stein Wrote:The slowdown happens while the game draws the ingame map. it does this by renderering all of the ground triangles using differing texturing environments(hope i correctly interpreted texenv from the sources). Every time the texturing environment is changed, dolphin does a flush of the video pipeline, with is pretty costly.
Hyrule field consists over all of 127 000 triangles, which the game draws to the map in chunks of 9-10 triangles, leading to 12 700 video pipeline flushes per frame.
I made the relevant function not emit the pipeline flush on texture environment change, instantly increasing framerate by 200%(and making my lowly system limited by emulating the virtual cpu again), but i get some graphical glitches especially in text rendering, and the map is sometimes missing the walls. Otherwise, gameplay is not affected Smile.
I am not a dolphin developer, but from what i see, i think this problem will need some redesign in the gpu emulation, so fixing this will probably take some time.
skid Wrote:It's looking to me like this Hyrule Field problem is caused by Dolphin being just plain slow. Maybe synchronizing the threads a bit smarter or rethinking the timing system can speed the emulator up, but these are drastic changes.
Other suggestions to speed up the emulator include caching the vertices (has been suggested by more than one person) and a greater use of OpenCL to cache textures. Currently, it's all talk and no code.
Keisel-stein Wrote:This is not true. There is additional geometry being rendered: The new parts of the map, and Zelda TPs way of drawing the map is expensive in dolphin, probably not at all on the real hardware.
For an example of how expensive map drawing actually is, i captured an image of the framebuffer after each of the 2911 pipeline flushes in an earlier part of the game(just started to explore faron woods, the map shows the area up to the faron spring):
0-2253: draw small fragments for the walls of the map
2254-2317: draw the walkable ground of the map
2318-2319: draw the arrows for current and start position for the map
2320-2605: draw shadow map, visible geometry, add bloom
2606: add map
2607-2743: render area name heading
2744-2910: render rest of gui
Granted, the non-map geometry is very simple, but you can get similar in Hyrule Field. By the way, i am not claiming that there are no other problems with Hyrule Field, like it being extremely cpu hungry... (and in this case i mean the emulated cpu)
firecrestsk8 Wrote:Sorry I've been MIA, I got way sidetracked when digging into the dolphin code, and then had to deal with some school work...
It seems like some people have gotten back into discussing the cause of the slowdown, so i guess i'll give my 2 cents... I think it has something to do with how we handle textures. Basically, the game starts each in-game frame by going through the tedious process of drawing the minimap from scratch, which involves alot of vertices. Then it performs an EFB copy to Texture, meaning that this map is now stored somewhere in memory. Since the mini map is now available in memory, it makes no sense that the game redraws it again each frame. I believe that the game attempts to raise some sort of flag (To be used like a boolean variable) after drawing the minimap, but dolphin somehow misses or doesn't recognize it (The flag would also have to be lowered whenever the player moved to a different area, because a new map would need to be drawn). Since this flag never gets raised, the game believes it needs to redraw the map again and again, instead of accessing it from memory. The reason this would slow down hyrule field more than other areas is because of the great detail involved in drawing the giant hyrule field minimap (The fact that my hack works should support this statement).
If the failed "flag" was identified and fixed, then there would be a much greater increase in speed, that might even translate to other games...
Now I'm going to make it clear that my "missed flag" conjecture is merely speculation: I've noticed some odd behavior by the game (unnecessary map redrawing) and have proposed a possible explanation behind it. That said, i currently suspect that the BP Registers involved in Texture invalidation (Which dolphin ignores) may have something to do with the issue. I also think that the code implementing EFB Copy may be involved in some way...
Anyways, as far as the patch goes, I got way sidetracked and started looking for some way to identify the map texture directly as it is copied from the DVD, but i have failed so far, and i don't even know if it would increase speed at all. I'm going to go ahead and just brush that work aside and go back to writing the OpenGL and DX11 patches so that the patch can be committed. BTW, I was hoping to submit this patch for commit myself, does anyone know how i go about doing that (this is my first open source work).
firecrestsk8 Wrote:I'm actually talking about the minimap, the one that is in grayscale when using EFB Copy to Texture! Basically the first thing done each frame is that a very small gray circle (16pixels X 16 pixels) is drawn over and over again (by setting it as the active texture and flushing loads and loads of vertices) in order to shape the current minimap (actually, this only shapes the background of the map). Once this is complete, the EFB is copied to some location in memory and cleared. Then the rest of the frame begins drawing, and at some point later, the map is drawn back to the frame as a texture in its proper place. Right after this things like the location indicator, etc. are drawn to the map.
My point is that while in Hyrule field, this map is being drawn exactly the same way at the beginning of each frame, and being stored in the exact same memory location, which doesnt seem like normal behavior to me (I assume the map is being drawn the same way, I have no idea how to check the individual vertex values). I know that this map drawing process takes a significant amount of time because my hack works, and it only acts by disabling some of the flushes that occur during this map drawing period.
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.
firecrestsk8 Wrote:Yea, i was a little confused about that too when first started getting involved with this problem... I think Keissel was refering to the minimap now that i have done my own research on the issue. I just confirmed via another method that in fact all the speed gained from my hack is definitely from changing how the vertices are flushed while drawing the minimap.
Yes i believe ("Believe", definitely not "know") that there is a way to signal the game to stop drawing the map each frame, i just dont know how Smile Finding the answer will involve figuring out how the Zelda programmers are checking whether or not drawing the minimap is necassary (again, assuming that this check is even happening).
Axxer Wrote:I believe it is the fact that the entirety of Hyrule Field gets loaded, which causes pretty major slowdowns. The ZTP hack tries to dynamically load things if I am understanding it right.
lolwut?
What do you mean by "loaded"? It certainly isn't rendered:
Xtreme2damax Wrote:It doesn't render all of Hyrule Field, only the immediate area you are in. This was confirmed by testing with Free Look and Wireframe mode.
Does nobody know how to use the search feature?
Kiesel-stein Wrote:The slowdown happens while the game draws the ingame map. it does this by renderering all of the ground triangles using differing texturing environments(hope i correctly interpreted texenv from the sources). Every time the texturing environment is changed, dolphin does a flush of the video pipeline, with is pretty costly.
Hyrule field consists over all of 127 000 triangles, which the game draws to the map in chunks of 9-10 triangles, leading to 12 700 video pipeline flushes per frame.
I made the relevant function not emit the pipeline flush on texture environment change, instantly increasing framerate by 200%(and making my lowly system limited by emulating the virtual cpu again), but i get some graphical glitches especially in text rendering, and the map is sometimes missing the walls. Otherwise, gameplay is not affected Smile.
I am not a dolphin developer, but from what i see, i think this problem will need some redesign in the gpu emulation, so fixing this will probably take some time.
skid Wrote:It's looking to me like this Hyrule Field problem is caused by Dolphin being just plain slow. Maybe synchronizing the threads a bit smarter or rethinking the timing system can speed the emulator up, but these are drastic changes.
Other suggestions to speed up the emulator include caching the vertices (has been suggested by more than one person) and a greater use of OpenCL to cache textures. Currently, it's all talk and no code.
Keisel-stein Wrote:This is not true. There is additional geometry being rendered: The new parts of the map, and Zelda TPs way of drawing the map is expensive in dolphin, probably not at all on the real hardware.
For an example of how expensive map drawing actually is, i captured an image of the framebuffer after each of the 2911 pipeline flushes in an earlier part of the game(just started to explore faron woods, the map shows the area up to the faron spring):
0-2253: draw small fragments for the walls of the map
2254-2317: draw the walkable ground of the map
2318-2319: draw the arrows for current and start position for the map
2320-2605: draw shadow map, visible geometry, add bloom
2606: add map
2607-2743: render area name heading
2744-2910: render rest of gui
Granted, the non-map geometry is very simple, but you can get similar in Hyrule Field. By the way, i am not claiming that there are no other problems with Hyrule Field, like it being extremely cpu hungry... (and in this case i mean the emulated cpu)
firecrestsk8 Wrote:Sorry I've been MIA, I got way sidetracked when digging into the dolphin code, and then had to deal with some school work...
It seems like some people have gotten back into discussing the cause of the slowdown, so i guess i'll give my 2 cents... I think it has something to do with how we handle textures. Basically, the game starts each in-game frame by going through the tedious process of drawing the minimap from scratch, which involves alot of vertices. Then it performs an EFB copy to Texture, meaning that this map is now stored somewhere in memory. Since the mini map is now available in memory, it makes no sense that the game redraws it again each frame. I believe that the game attempts to raise some sort of flag (To be used like a boolean variable) after drawing the minimap, but dolphin somehow misses or doesn't recognize it (The flag would also have to be lowered whenever the player moved to a different area, because a new map would need to be drawn). Since this flag never gets raised, the game believes it needs to redraw the map again and again, instead of accessing it from memory. The reason this would slow down hyrule field more than other areas is because of the great detail involved in drawing the giant hyrule field minimap (The fact that my hack works should support this statement).
If the failed "flag" was identified and fixed, then there would be a much greater increase in speed, that might even translate to other games...
Now I'm going to make it clear that my "missed flag" conjecture is merely speculation: I've noticed some odd behavior by the game (unnecessary map redrawing) and have proposed a possible explanation behind it. That said, i currently suspect that the BP Registers involved in Texture invalidation (Which dolphin ignores) may have something to do with the issue. I also think that the code implementing EFB Copy may be involved in some way...
Anyways, as far as the patch goes, I got way sidetracked and started looking for some way to identify the map texture directly as it is copied from the DVD, but i have failed so far, and i don't even know if it would increase speed at all. I'm going to go ahead and just brush that work aside and go back to writing the OpenGL and DX11 patches so that the patch can be committed. BTW, I was hoping to submit this patch for commit myself, does anyone know how i go about doing that (this is my first open source work).
firecrestsk8 Wrote:I'm actually talking about the minimap, the one that is in grayscale when using EFB Copy to Texture! Basically the first thing done each frame is that a very small gray circle (16pixels X 16 pixels) is drawn over and over again (by setting it as the active texture and flushing loads and loads of vertices) in order to shape the current minimap (actually, this only shapes the background of the map). Once this is complete, the EFB is copied to some location in memory and cleared. Then the rest of the frame begins drawing, and at some point later, the map is drawn back to the frame as a texture in its proper place. Right after this things like the location indicator, etc. are drawn to the map.
My point is that while in Hyrule field, this map is being drawn exactly the same way at the beginning of each frame, and being stored in the exact same memory location, which doesnt seem like normal behavior to me (I assume the map is being drawn the same way, I have no idea how to check the individual vertex values). I know that this map drawing process takes a significant amount of time because my hack works, and it only acts by disabling some of the flushes that occur during this map drawing period.
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.
firecrestsk8 Wrote:Yea, i was a little confused about that too when first started getting involved with this problem... I think Keissel was refering to the minimap now that i have done my own research on the issue. I just confirmed via another method that in fact all the speed gained from my hack is definitely from changing how the vertices are flushed while drawing the minimap.
Yes i believe ("Believe", definitely not "know") that there is a way to signal the game to stop drawing the map each frame, i just dont know how Smile Finding the answer will involve figuring out how the Zelda programmers are checking whether or not drawing the minimap is necassary (again, assuming that this check is even happening).
Axxer Wrote:I believe it is the fact that the entirety of Hyrule Field gets loaded, which causes pretty major slowdowns. The ZTP hack tries to dynamically load things if I am understanding it right.
lolwut?
What do you mean by "loaded"? It certainly isn't rendered:
Xtreme2damax Wrote:It doesn't render all of Hyrule Field, only the immediate area you are in. This was confirmed by testing with Free Look and Wireframe mode.
Does nobody know how to use the search feature?
Kiesel-stein Wrote:The slowdown happens while the game draws the ingame map. it does this by renderering all of the ground triangles using differing texturing environments(hope i correctly interpreted texenv from the sources). Every time the texturing environment is changed, dolphin does a flush of the video pipeline, with is pretty costly.
Hyrule field consists over all of 127 000 triangles, which the game draws to the map in chunks of 9-10 triangles, leading to 12 700 video pipeline flushes per frame.
I made the relevant function not emit the pipeline flush on texture environment change, instantly increasing framerate by 200%(and making my lowly system limited by emulating the virtual cpu again), but i get some graphical glitches especially in text rendering, and the map is sometimes missing the walls. Otherwise, gameplay is not affected Smile.
I am not a dolphin developer, but from what i see, i think this problem will need some redesign in the gpu emulation, so fixing this will probably take some time.
skid Wrote:It's looking to me like this Hyrule Field problem is caused by Dolphin being just plain slow. Maybe synchronizing the threads a bit smarter or rethinking the timing system can speed the emulator up, but these are drastic changes.
Other suggestions to speed up the emulator include caching the vertices (has been suggested by more than one person) and a greater use of OpenCL to cache textures. Currently, it's all talk and no code.
Keisel-stein Wrote:This is not true. There is additional geometry being rendered: The new parts of the map, and Zelda TPs way of drawing the map is expensive in dolphin, probably not at all on the real hardware.
For an example of how expensive map drawing actually is, i captured an image of the framebuffer after each of the 2911 pipeline flushes in an earlier part of the game(just started to explore faron woods, the map shows the area up to the faron spring):
0-2253: draw small fragments for the walls of the map
2254-2317: draw the walkable ground of the map
2318-2319: draw the arrows for current and start position for the map
2320-2605: draw shadow map, visible geometry, add bloom
2606: add map
2607-2743: render area name heading
2744-2910: render rest of gui
Granted, the non-map geometry is very simple, but you can get similar in Hyrule Field. By the way, i am not claiming that there are no other problems with Hyrule Field, like it being extremely cpu hungry... (and in this case i mean the emulated cpu)
firecrestsk8 Wrote:Sorry I've been MIA, I got way sidetracked when digging into the dolphin code, and then had to deal with some school work...
It seems like some people have gotten back into discussing the cause of the slowdown, so i guess i'll give my 2 cents... I think it has something to do with how we handle textures. Basically, the game starts each in-game frame by going through the tedious process of drawing the minimap from scratch, which involves alot of vertices. Then it performs an EFB copy to Texture, meaning that this map is now stored somewhere in memory. Since the mini map is now available in memory, it makes no sense that the game redraws it again each frame. I believe that the game attempts to raise some sort of flag (To be used like a boolean variable) after drawing the minimap, but dolphin somehow misses or doesn't recognize it (The flag would also have to be lowered whenever the player moved to a different area, because a new map would need to be drawn). Since this flag never gets raised, the game believes it needs to redraw the map again and again, instead of accessing it from memory. The reason this would slow down hyrule field more than other areas is because of the great detail involved in drawing the giant hyrule field minimap (The fact that my hack works should support this statement).
If the failed "flag" was identified and fixed, then there would be a much greater increase in speed, that might even translate to other games...
Now I'm going to make it clear that my "missed flag" conjecture is merely speculation: I've noticed some odd behavior by the game (unnecessary map redrawing) and have proposed a possible explanation behind it. That said, i currently suspect that the BP Registers involved in Texture invalidation (Which dolphin ignores) may have something to do with the issue. I also think that the code implementing EFB Copy may be involved in some way...
Anyways, as far as the patch goes, I got way sidetracked and started looking for some way to identify the map texture directly as it is copied from the DVD, but i have failed so far, and i don't even know if it would increase speed at all. I'm going to go ahead and just brush that work aside and go back to writing the OpenGL and DX11 patches so that the patch can be committed. BTW, I was hoping to submit this patch for commit myself, does anyone know how i go about doing that (this is my first open source work).
firecrestsk8 Wrote:I'm actually talking about the minimap, the one that is in grayscale when using EFB Copy to Texture! Basically the first thing done each frame is that a very small gray circle (16pixels X 16 pixels) is drawn over and over again (by setting it as the active texture and flushing loads and loads of vertices) in order to shape the current minimap (actually, this only shapes the background of the map). Once this is complete, the EFB is copied to some location in memory and cleared. Then the rest of the frame begins drawing, and at some point later, the map is drawn back to the frame as a texture in its proper place. Right after this things like the location indicator, etc. are drawn to the map.
My point is that while in Hyrule field, this map is being drawn exactly the same way at the beginning of each frame, and being stored in the exact same memory location, which doesnt seem like normal behavior to me (I assume the map is being drawn the same way, I have no idea how to check the individual vertex values). I know that this map drawing process takes a significant amount of time because my hack works, and it only acts by disabling some of the flushes that occur during this map drawing period.
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.
firecrestsk8 Wrote:Yea, i was a little confused about that too when first started getting involved with this problem... I think Keissel was refering to the minimap now that i have done my own research on the issue. I just confirmed via another method that in fact all the speed gained from my hack is definitely from changing how the vertices are flushed while drawing the minimap.
Yes i believe ("Believe", definitely not "know") that there is a way to signal the game to stop drawing the map each frame, i just dont know how Smile Finding the answer will involve figuring out how the Zelda programmers are checking whether or not drawing the minimap is necassary (again, assuming that this check is even happening).
Axxer Wrote:I believe it is the fact that the entirety of Hyrule Field gets loaded, which causes pretty major slowdowns. The ZTP hack tries to dynamically load things if I am understanding it right.
lolwut?
What do you mean by "loaded"? It certainly isn't rendered:
Xtreme2damax Wrote:It doesn't render all of Hyrule Field, only the immediate area you are in. This was confirmed by testing with Free Look and Wireframe mode.
Does nobody know how to use the search feature?
Kiesel-stein Wrote:The slowdown happens while the game draws the ingame map. it does this by renderering all of the ground triangles using differing texturing environments(hope i correctly interpreted texenv from the sources). Every time the texturing environment is changed, dolphin does a flush of the video pipeline, with is pretty costly.
Hyrule field consists over all of 127 000 triangles, which the game draws to the map in chunks of 9-10 triangles, leading to 12 700 video pipeline flushes per frame.
I made the relevant function not emit the pipeline flush on texture environment change, instantly increasing framerate by 200%(and making my lowly system limited by emulating the virtual cpu again), but i get some graphical glitches especially in text rendering, and the map is sometimes missing the walls. Otherwise, gameplay is not affected Smile.
I am not a dolphin developer, but from what i see, i think this problem will need some redesign in the gpu emulation, so fixing this will probably take some time.
skid Wrote:It's looking to me like this Hyrule Field problem is caused by Dolphin being just plain slow. Maybe synchronizing the threads a bit smarter or rethinking the timing system can speed the emulator up, but these are drastic changes.
Other suggestions to speed up the emulator include caching the vertices (has been suggested by more than one person) and a greater use of OpenCL to cache textures. Currently, it's all talk and no code.
Keisel-stein Wrote:This is not true. There is additional geometry being rendered: The new parts of the map, and Zelda TPs way of drawing the map is expensive in dolphin, probably not at all on the real hardware.
For an example of how expensive map drawing actually is, i captured an image of the framebuffer after each of the 2911 pipeline flushes in an earlier part of the game(just started to explore faron woods, the map shows the area up to the faron spring):
0-2253: draw small fragments for the walls of the map
2254-2317: draw the walkable ground of the map
2318-2319: draw the arrows for current and start position for the map
2320-2605: draw shadow map, visible geometry, add bloom
2606: add map
2607-2743: render area name heading
2744-2910: render rest of gui
Granted, the non-map geometry is very simple, but you can get similar in Hyrule Field. By the way, i am not claiming that there are no other problems with Hyrule Field, like it being extremely cpu hungry... (and in this case i mean the emulated cpu)
firecrestsk8 Wrote:Sorry I've been MIA, I got way sidetracked when digging into the dolphin code, and then had to deal with some school work...
It seems like some people have gotten back into discussing the cause of the slowdown, so i guess i'll give my 2 cents... I think it has something to do with how we handle textures. Basically, the game starts each in-game frame by going through the tedious process of drawing the minimap from scratch, which involves alot of vertices. Then it performs an EFB copy to Texture, meaning that this map is now stored somewhere in memory. Since the mini map is now available in memory, it makes no sense that the game redraws it again each frame. I believe that the game attempts to raise some sort of flag (To be used like a boolean variable) after drawing the minimap, but dolphin somehow misses or doesn't recognize it (The flag would also have to be lowered whenever the player moved to a different area, because a new map would need to be drawn). Since this flag never gets raised, the game believes it needs to redraw the map again and again, instead of accessing it from memory. The reason this would slow down hyrule field more than other areas is because of the great detail involved in drawing the giant hyrule field minimap (The fact that my hack works should support this statement).
If the failed "flag" was identified and fixed, then there would be a much greater increase in speed, that might even translate to other games...
Now I'm going to make it clear that my "missed flag" conjecture is merely speculation: I've noticed some odd behavior by the game (unnecessary map redrawing) and have proposed a possible explanation behind it. That said, i currently suspect that the BP Registers involved in Texture invalidation (Which dolphin ignores) may have something to do with the issue. I also think that the code implementing EFB Copy may be involved in some way...
Anyways, as far as the patch goes, I got way sidetracked and started looking for some way to identify the map texture directly as it is copied from the DVD, but i have failed so far, and i don't even know if it would increase speed at all. I'm going to go ahead and just brush that work aside and go back to writing the OpenGL and DX11 patches so that the patch can be committed. BTW, I was hoping to submit this patch for commit myself, does anyone know how i go about doing that (this is my first open source work).
firecrestsk8 Wrote:I'm actually talking about the minimap, the one that is in grayscale when using EFB Copy to Texture! Basically the first thing done each frame is that a very small gray circle (16pixels X 16 pixels) is drawn over and over again (by setting it as the active texture and flushing loads and loads of vertices) in order to shape the current minimap (actually, this only shapes the background of the map). Once this is complete, the EFB is copied to some location in memory and cleared. Then the rest of the frame begins drawing, and at some point later, the map is drawn back to the frame as a texture in its proper place. Right after this things like the location indicator, etc. are drawn to the map.
My point is that while in Hyrule field, this map is being drawn exactly the same way at the beginning of each frame, and being stored in the exact same memory location, which doesnt seem like normal behavior to me (I assume the map is being drawn the same way, I have no idea how to check the individual vertex values). I know that this map drawing process takes a significant amount of time because my hack works, and it only acts by disabling some of the flushes that occur during this map drawing period.
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.
Axxer Wrote:I believe it is the fact that the entirety of Hyrule Field gets loaded, which causes pretty major slowdowns. The ZTP hack tries to dynamically load things if I am understanding it right.
lolwut?
What do you mean by "loaded"? It certainly isn't rendered:
Xtreme2damax Wrote:It doesn't render all of Hyrule Field, only the immediate area you are in. This was confirmed by testing with Free Look and Wireframe mode.
Does nobody know how to use the search feature?
Kiesel-stein Wrote:The slowdown happens while the game draws the ingame map. it does this by renderering all of the ground triangles using differing texturing environments(hope i correctly interpreted texenv from the sources). Every time the texturing environment is changed, dolphin does a flush of the video pipeline, with is pretty costly.
Hyrule field consists over all of 127 000 triangles, which the game draws to the map in chunks of 9-10 triangles, leading to 12 700 video pipeline flushes per frame.
I made the relevant function not emit the pipeline flush on texture environment change, instantly increasing framerate by 200%(and making my lowly system limited by emulating the virtual cpu again), but i get some graphical glitches especially in text rendering, and the map is sometimes missing the walls. Otherwise, gameplay is not affected Smile.
I am not a dolphin developer, but from what i see, i think this problem will need some redesign in the gpu emulation, so fixing this will probably take some time.
skid Wrote:It's looking to me like this Hyrule Field problem is caused by Dolphin being just plain slow. Maybe synchronizing the threads a bit smarter or rethinking the timing system can speed the emulator up, but these are drastic changes.
Other suggestions to speed up the emulator include caching the vertices (has been suggested by more than one person) and a greater use of OpenCL to cache textures. Currently, it's all talk and no code.
Keisel-stein Wrote:This is not true. There is additional geometry being rendered: The new parts of the map, and Zelda TPs way of drawing the map is expensive in dolphin, probably not at all on the real hardware.
For an example of how expensive map drawing actually is, i captured an image of the framebuffer after each of the 2911 pipeline flushes in an earlier part of the game(just started to explore faron woods, the map shows the area up to the faron spring):
0-2253: draw small fragments for the walls of the map
2254-2317: draw the walkable ground of the map
2318-2319: draw the arrows for current and start position for the map
2320-2605: draw shadow map, visible geometry, add bloom
2606: add map
2607-2743: render area name heading
2744-2910: render rest of gui
Granted, the non-map geometry is very simple, but you can get similar in Hyrule Field. By the way, i am not claiming that there are no other problems with Hyrule Field, like it being extremely cpu hungry... (and in this case i mean the emulated cpu)
firecrestsk8 Wrote:Sorry I've been MIA, I got way sidetracked when digging into the dolphin code, and then had to deal with some school work...
It seems like some people have gotten back into discussing the cause of the slowdown, so i guess i'll give my 2 cents... I think it has something to do with how we handle textures. Basically, the game starts each in-game frame by going through the tedious process of drawing the minimap from scratch, which involves alot of vertices. Then it performs an EFB copy to Texture, meaning that this map is now stored somewhere in memory. Since the mini map is now available in memory, it makes no sense that the game redraws it again each frame. I believe that the game attempts to raise some sort of flag (To be used like a boolean variable) after drawing the minimap, but dolphin somehow misses or doesn't recognize it (The flag would also have to be lowered whenever the player moved to a different area, because a new map would need to be drawn). Since this flag never gets raised, the game believes it needs to redraw the map again and again, instead of accessing it from memory. The reason this would slow down hyrule field more than other areas is because of the great detail involved in drawing the giant hyrule field minimap (The fact that my hack works should support this statement).
If the failed "flag" was identified and fixed, then there would be a much greater increase in speed, that might even translate to other games...
Now I'm going to make it clear that my "missed flag" conjecture is merely speculation: I've noticed some odd behavior by the game (unnecessary map redrawing) and have proposed a possible explanation behind it. That said, i currently suspect that the BP Registers involved in Texture invalidation (Which dolphin ignores) may have something to do with the issue. I also think that the code implementing EFB Copy may be involved in some way...
Anyways, as far as the patch goes, I got way sidetracked and started looking for some way to identify the map texture directly as it is copied from the DVD, but i have failed so far, and i don't even know if it would increase speed at all. I'm going to go ahead and just brush that work aside and go back to writing the OpenGL and DX11 patches so that the patch can be committed. BTW, I was hoping to submit this patch for commit myself, does anyone know how i go about doing that (this is my first open source work).
wtf is up with this thread bugging out on me?
"Normally if given a choice between doing something and nothing, I’d choose to do nothing. But I would do something if it helps someone else do nothing. I’d work all night if it meant nothing got done."
-Ron Swanson
"I shall be a good politician, even if it kills me. Or if it kills anyone else for that matter. "
-Mark Antony
-Ron Swanson
"I shall be a good politician, even if it kills me. Or if it kills anyone else for that matter. "
-Mark Antony