Lol, I knew that was going to happen. Neobrain he doesn't know c++, that probably looks like Chinese to him. Here let me quote the part of the comments you need to read/
Quote: BEGIN ZTP SPEEDUP HACK CHANGES
This hunk of code disables the usual pipeline flush for certain BP Writes
that occur while the minimap is being drawn in Zelda: Twilight Princess.
This significantly increases speed while in hyrule field.
Quote: seem that if 100 consecutive BP writes are called to either of these addresses in ZTP,
then it is safe to assume the map texture address is currently loaded into the BP memory
Quote: Purpose: Writes to the BP registers
Called: At the end of every: OpcodeDecoding.cpp ExecuteDisplayList > Decode() > LoadBPReg
How It Works: First the pipeline is flushed then update the bpmem with the new value.
Some of the BP cases have to call certain functions while others just update the bpmem.
some bp cases check the changes variable, because they might not have to be updated all the time
NOTE: it seems not all bp cases like checking changes, so calling if (bp.changes == 0 ? false : true)
had to be ditched and the games seem to work fine with out it.
NOTE2: Yet Another Gamecube Documentation calls them Bypass Raster State Registers but possibly completely wrong
NOTE3: This controls the register groups: RAS1/2, SU, TF, TEV, C/Z, PEC
TODO: Turn into function table. The (future) DisplayList (DL) jit can then call the functions directly,
getting rid of dynamic dispatch. Unfortunately, few games use DLs properly - most\
just stuff geometry in them and don't put state changes there
The most important part being:
Quote:This hunk of code disables the usual pipeline flush for certain BP Writes that occur while the minimap is being drawn in Zelda: Twilight Princess.
(09-24-2011, 11:19 AM)NaturalViolence Wrote: [ -> ]Lol, I knew that was going to happen. Neobrain he doesn't know c++, that probably looks like Chinese to him. Here let me quote the part of the comments you need to read/
Quote: BEGIN ZTP SPEEDUP HACK CHANGES
This hunk of code disables the usual pipeline flush for certain BP Writes
that occur while the minimap is being drawn in Zelda: Twilight Princess.
This significantly increases speed while in hyrule field.
Quote: seem that if 100 consecutive BP writes are called to either of these addresses in ZTP,
then it is safe to assume the map texture address is currently loaded into the BP memory
Quote: Purpose: Writes to the BP registers
Called: At the end of every: OpcodeDecoding.cpp ExecuteDisplayList > Decode() > LoadBPReg
How It Works: First the pipeline is flushed then update the bpmem with the new value.
Some of the BP cases have to call certain functions while others just update the bpmem.
some bp cases check the changes variable, because they might not have to be updated all the time
NOTE: it seems not all bp cases like checking changes, so calling if (bp.changes == 0 ? false : true)
had to be ditched and the games seem to work fine with out it.
NOTE2: Yet Another Gamecube Documentation calls them Bypass Raster State Registers but possibly completely wrong
NOTE3: This controls the register groups: RAS1/2, SU, TF, TEV, C/Z, PEC
TODO: Turn into function table. The (future) DisplayList (DL) jit can then call the functions directly,
getting rid of dynamic dispatch. Unfortunately, few games use DLs properly - most\
just stuff geometry in them and don't put state changes there
The most important part being:
Quote:This hunk of code disables the usual pipeline flush for certain BP Writes that occur while the minimap is being drawn in Zelda: Twilight Princess.
Sooooo,it dosen't affect anything in the game?I thought the hack removed scenery and stuff to make the game run faster.
I think you need to reconsider your definition of "removed". Nothing is truly removed from the game, dolphin doesn't delete data on the gamedisc (.iso file) it only reads it. However dolphin has various options that control what is and is not emulated. For example if you disable lighting then the lighting functions don't get called and dolphin does not emulate the lighting.
Normally the GPU pipeline is flushed whenever the contents of the BP registers are changed. The ZTP hack disables flushing the pipeline during certain BP reg changes that have been associated with drawing the minimap in ZTP. Normally the pipeline is flushed constantly while updating the minimap which produces a significant reduction in performance. Hyrule field is very large and a lot of stuff is going on so I guess the BP registers get changed a lot which results in a particularly high number of pipeline flushes per second.
(09-25-2011, 07:03 AM)NaturalViolence Wrote: [ -> ]I think you need to reconsider your definition of "removed". Nothing is truly removed from the game, dolphin doesn't delete data on the gamedisc (.iso file) it only reads it. However dolphin has various options that control what is and is not emulated. For example if you disable lighting then the lighting functions don't get called and dolphin does not emulate the lighting.
Normally the GPU pipeline is flushed whenever the contents of the BP registers are changed. The ZTP hack disables flushing the pipeline during certain BP reg changes that have been associated with drawing the minimap in ZTP. Normally the pipeline is flushed constantly while updating the minimap which produces a significant reduction in performance. Hyrule field is very large and a lot of stuff is going on so I guess the BP registers get changed a lot which results in a particularly high number of pipeline flushes per second.
Oh,i see.Thanks for clearing this up!
I shouldn't think it would be a function of raw clock speed. After all, a Pentium 4 at 3.0 GHz is not even in the same ball park as an i5 at 2.8 GHz.
Besides, everything was running beautifully up until that point. I could have used the OpenGL plugin with all the slow, pretty graphics and it wouldn't have hiccuped at all.
Overclocking will still improve performance. As we said you need a very powerful cpu/gpu to run hyrule field late game at full speed. Hyrule field runs much slower than the rest of the game, the reasons for this were explained above.
And please quote the post that you are responding to when it's not the previous post.
(09-24-2011, 06:40 AM)NaturalViolence Wrote: [ -> ]@rpglord
Exactly how far into the game are you? Have you reached the mirror of twilight yet? Is efb copy set to ram, virtual (texture), or both? What revision are you using? What graphics card do you have (it's odd that you are reporting a speed increase from lowering resolution)? Which video backend are you using?
I'm getting 16-22fps with my Q6600 @ 3.2GHz. But that's certainly not fullspeed. And an E6600 @ 4.0GHz is very high end even for dolphin.
@C-Man
Do you have efb copy ram unchecked?
I have finished the game long ago
I just used late game save to answer your questions,and you were right,there is no perfomance difference at all when changing the resolution or AA.
Efb copy/ram affects the perfomance the most. With it on I get 22-23 with it of 28-30 fps.
The game doesnt seem to need this on anymore am I right ?
So thats a free perfomance boost
I am using 7719,dx9,460 gtx 1gb is my gpu
If C-Man is getting 10-12 its not slowdown problem,since he has decent cpu.
He has some other problem.
Well the IPC of a core 2 cpu is about 10% higher than a phenom II. You run your core 2 duo at 4.0GHz so that's basically equal to a phenom II running at 4.4GHz. His phenom II is probably running at 3.2GHz so I would expect your performance to be about 1/3 higher than his.
Until he tells us his settings we won't be able to figure out what's wrong.