Dolphin, the GameCube and Wii emulator - Forums

(06-23-2010, 08:32 AM)Hiperzone Wrote: [ -> ]

(06-22-2010, 01:00 PM)kernel64 Wrote: [ -> ]Great, at least we have something to think about. In SMG or SMG2, a good cpu manages to achieve close to full speed frame rates, even on complex levels. Hyrule field is very slow even on this kind of cpus. Being a GC game, it might be handling Hyrule field in a different way. Maybe that's why Dolphin apparently loads and renders the entire Hyrule field.

the reason why hyrule field is slow is because dolphin is rendering over 128k triangles in that field wich slows everything down cause the cpu cant handle that kind of mount of data. Im in the post zora part of the game btw.

the big question still is: WHY does the game or Dolphin render all this stuff LATER in the game but not before?

(06-23-2010, 08:05 AM)NaturalViolence Wrote: [ -> ]

Quote:Hyrule field is very slow even on this kind of cpus. Being a GC game, it might be handling Hyrule field in a different way. Maybe that's why Dolphin apparently loads and renders the entire Hyrule field.

Not true. Many I7 users including one of my friends I can directly confirm, having seen it first hand, achieve full speed in hyrule fields WITHOUT the patch. I am still trying to figure out why, and why only some I7 users seem to be affected while others have the normal slowdown.

Now that is strange isn't it? I doubt that the cpu is the resposible for this though, since the core i5 has pretty much the same instruction set as far as I know, besides some other differences that I don't see how they would affect Dolphin, except maybe HT.

Maybe a specific system or video configuration rather than a CPU issue. In any case, it would help to know the specifics of this systems (the ones which are able to run hyrule at full speed).

How many FPS in HF on the Core i7 9xx?

(04-11-2010, 07:37 PM)nodchip Wrote: [ -> ]I'm investigating the problem and focusing on Frame Buffer Textures. Frame Buffer Textures is a basic technique for 3D game to realize many kind of effects. In this game, they are used to express water, make shadows and so on. The basis of Frame Buffer Texture is to render a scene and reuse the result as a texture. In Ordon Village, five Frame Buffer Textures are used to render a frame. Three of them were for making shadow, one for water effect and one for rendering scene. Basically Frame Buffer Texture is heavy. I guess it cause the Hyrule Field problem. Actually I have not reached to Hyrule Field. I will report the result after I reach Hyrule Field.

Abobe example actually uses nine frame buffer textures. Here are four of them.

Hey nodchip, any more information or progress on this? I suppose this might offer some explanation as to why some members (likely with powerful graphics hardware) are unaffected by this issue and would explain why Kiesel's patch works.

I've got an Intel Core i7 920, 6 GBs RAM, 64-bit OS, running with a 9800GT. Dolphin options as suggested in the wiki.

Game runs essentialy perfect (30-31 FPS) in almost any location, some cities go around 27 FPS, and the Hyrule Field runs at around 20 FPS (66% speed), past freeing the Zora section, thus removing the Twilight (for now; I Think). Some sound problems, seems sound's a little non-clear, but this is not the place to say that.

Just putting in input... I really want to achieve full speed at the Hyrule Field.

OK, I've been digging around in the dolphin code for a few days now, and I've made a little bit of progress in this area...

So Keissel's patch seemed to make the game playable, but it messed up certain features in the game (i.e. the minimap, the map menu, the select item menu, remaining bomb/arrow numbers). My initial solution for this was to swap between the hacked and unhacked plug-ins when going into dungeons, but that was pretty annoying, so i decided to dive in and see what i could fix.

I decided to just build on what keissel did, and began identifying what textures were being drawn during the flushes that he disabled. I Discovered that the same texture was being drawn during each of the flushes that he was intending to disable. This led me to an alternate method of disabling the flush command (instead of by never flushing after a tev combiner change), where i disable the flushes only when this particular texture is being drawn.

The result is a speed increase equal to about that of Keissel's (as far as i can tell), but with the textures all restored. What appears to still be messed up, however, is the mini-map. This makes sense, because i think the mass amount of flushes we were trying to disable occur while trying to draw the minimap (They have to be doing something ). What i didnt expect was for the minimap to actually be present, which it is, only it is horribly shaded.

I have barely tested this so feedback will be useful (as usual). I have also restored textures with a couple different methods (all similar but more cumbersome) but none appear as successful as this method. Here is what i did:

I replaced this line that Keissel-Stein changed in BPStructs.cpp:

if (bp.address < BPMEM_TX_SETMODE0 || bp.address >= BPMEM_TEV_ALPHA_ENV+32)
FlushPipeline();

with this line:

if ( ((bpmem.tex[0].texImage3[0].hex << 5) != 0x1124ee60) || !(bpmem.tevorders[0].getEnable(0)) )
FlushPipeline();

Notice the compare to a 32-bit address: This is the address of the texture i identifed being printed multiple times (The texture is a very small gray circle, I think the minimap is just a bunch of these circles drawn over and over again). I am worried that this address may not be consistent across all versions of the game, and thus this will not work for everyone (or maybe even anyone) else. I use the NTSC version of the game, so PAL users be wary. If this is the case, I'm pretty sure I could find some other way of identifying this texture in other versions of the game.

My next task is going to be to see how this changes the pattern of BPWrite Flushes during a frame, and seeing if anything else can be done to restore the minimap. I have not gained too much additional insight into what the actual cause of the hyrule field slowdown is, but I plan to look into how many additional vertices are flushed in hyrule field compared to else where (I think other people may have already done this).

Anywho, I'm not good with making and posting builds, but if you have any time Xtreme, i was hoping you could possibly try out this change and if it works, maybe post another build. Last note, I use EFB copy to Texture and scaled copy.

EDIT: I just attached a dump of the texture that i identified, note i changed texture dumps on my build so that the address of the texture is attached to the filename after the hash

EDIT: using the line:

if ( ((bpmem.tex[0].texImage3[0].hex << 5) != 0x1124ee60))

instead un-inverts the minimap, making it look a little clearer... unless you use EFB copy to RAM, in which the original line prints the map very well and in color. This line also uses less flushes, so it may be a little faster (probably less than 1 fps though)

(06-25-2010, 08:59 PM)fircrestsk8 Wrote: [ -> ]OK, I've been digging around in the dolphin code for a few days now, and I've made a little bit of progress in this area...

So Keissel's patch seemed to make the game playable, but it messed up certain features in the game (i.e. the minimap, the map menu, the select item menu, remaining bomb/arrow numbers). My initial solution for this was to swap between the hacked and unhacked plug-ins when going into dungeons, but that was pretty annoying, so i decided to dive in and see what i could fix.

I decided to just build on what keissel did, and began identifying what textures were being drawn during the flushes that he disabled. I Discovered that the same texture was being drawn during each of the flushes that he was intending to disable. This led me to an alternate method of disabling the flush command (instead of by never flushing after a tev combiner change), where i disable the flushes only when this particular texture is being drawn.

The result is a speed increase equal to about that of Keissel's (as far as i can tell), but with the textures all restored. What appears to still be messed up, however, is the mini-map. This makes sense, because i think the mass amount of flushes we were trying to disable occur while trying to draw the minimap (They have to be doing something ). What i didnt expect was for the minimap to actually be present, which it is, only it is horribly shaded.

I have barely tested this so feedback will be useful (as usual). I have also restored textures with a couple different methods (all similar but more cumbersome) but none appear as successful as this method. Here is what i did:

I replaced this line that Keissel-Stein changed in BPStructs.cpp:

if (bp.address < BPMEM_TX_SETMODE0 || bp.address >= BPMEM_TEV_ALPHA_ENV+32)
FlushPipeline();

with this line:

if ( ((bpmem.tex[0].texImage3[0].hex << 5) != 0x1124ee60) || !(bpmem.tevorders[0].getEnable(0)) )
FlushPipeline();

Notice the compare to a 32-bit address: This is the address of the texture i identifed being printed multiple times (The texture is a very small gray circle, I think the minimap is just a bunch of these circles drawn over and over again). I am worried that this address may not be consistent across all versions of the game, and thus this will not work for everyone (or maybe even anyone) else. I use the NTSC version of the game, so PAL users be wary. If this is the case, I'm pretty sure I could find some other way of identifying this texture in other versions of the game.

My next task is going to be to see how this changes the pattern of BPWrite Flushes during a frame, and seeing if anything else can be done to restore the minimap. I have not gained too much additional insight into what the actual cause of the hyrule field slowdown is, but I plan to look into how many additional vertices are flushed in hyrule field compared to else where (I think other people may have already done this).

Anywho, I'm not good with making and posting builds, but if you have any time Xtreme, i was hoping you could possibly try out this change and if it works, maybe post another build. Last note, I use EFB copy to Texture and scaled copy.

EDIT: I just attached a dump of the texture that i identified, note i changed texture dumps on my build so that the address of the texture is attached to the filename after the hash

EDIT: using the line:

if ( ((bpmem.tex[0].texImage3[0].hex << 5) != 0x1124ee60))

instead un-inverts the minimap, making it look a little clearer... unless you use EFB copy to RAM, in which the original line prints the map very well and in color. This line also uses less flushes, so it may be a little faster (probably less than 1 fps though)

over 128k post zora compared to the average 17k on the initial field. thats the reason of the slowdown ;p

@fircrestsk8, as far as I'm aware the current patch of kiesels has no issues with the Gamecube version of Twilight Princess at least. However what does seem to be messed up is the Wii version, the warp map is missing textures and is black except for the blue circles for the warp areas. Also in the Wii version some of the textures are missing or messed up throughout the game.

The minimap is always messed up unless Copy EFB -> Ram is selected and no projection hacks are being used, which aren't needed for this game anymore.

The issue that does need to be resolved is that Kiesels patch is causing issues with textures and certain effects in other games and the Wii version of Twilight Princess, the following games are affected with the patch as far as I know:

All Metroid Prime Games
Super Mario Galaxy 2, and possibly the first Super Mario Galaxy as well.
Zelda: Twilight Princess (Wii)

According to what Kiesel mentioned, a proper hack would need to be created to disable the pipeline flush only when necessary. Here is his quote from earlier in the thread:

Quote:

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.

He also mentioned the following:

Quote:The real fix, imho, needs to be done elsewhere, either by using a different path for the texture environment information or by reducing the cost of the pipeline flush.

It looks like the driver revalidates all its state on the machines with slowdowns, but for some reason does not do that on others. This is the reason for my suspicion that a newer directx may be faster in that regard, because, although dolphin talks to the dx9 interfaces, they are only (at worst) a thin wrapper around dx11, it is not talking to the old code in dx9 releases that only get bugfixes. Or, to put it another way: there is not much of dx9 code left in dx11 releases.

There was an updated patch posted by Kiesel later on that I seemed to miss, I'm going to test that and also test your changes.

I'm playing with a core2duo e8500 @ 3,16ghz. Which works pretty fine with almost everything, for zelda I oced the cpu to 3,8ghz(would love to try more but my cpu fan isn't really made for higher clocks) and have to say: hyrule field went up from about 10fps to 18-20fps now, so it's almost playable there ^^

I also noticed that strangely the scene where you have that escort quest with the zora prince to kakariko runs at fullspeed! Even though you travel through a large portion of hyrule field, perhaps that can help in some way...

ohh yea, i forgot that there is a gamecube version too... I'm pretty sure this line will not work on gamecube versions, unless the textures are addressed exactly the same across both versions (it could happen...). Either way, if the textures dont break in the gamecube version, it is not necassary. This patch simply fixes the minimap, warp map, and other texture problems caused by the original Kiessel patch in the Wii version. It should also fix the other games, unless of course they include a texture loaded at address 0x1124ee60.

Just for clarification, this is the line I'm using:

if ( ((bpmem.tex[0].texImage3[0].hex << 5) != 0x1124ee60) || !(bpmem.tevorders[0].getEnable(0)) || bp.address == BPMEM_TREF )

and here are some screens:

[attachment=3794]
[attachment=3795]

**Mini spoiler** don't open this unless you want to see a pretty full item list
[attachment=3793]