Emulator

Another problem (r7634): DX9/Virtual -> Mario Kart Double Dash (seen ingame)

3. GFX are not being scaled properly in DX11. With the same settings in DX9, models/textures are hi-res. This can be observed in numerous games, most notably in DKCR.

About DKCR: The game appears to be modifying the texture on the CPU, but I don't know what for. Does the scaling problem go away if you disable EFB-to-RAM and keep Virtual on?

Ok, sorry it has nothing to do with DX9 vs. DX11 - 9 was set to EFB>Virtual and 11 was set to EFB>Ram. Using Virtual, games are now rendered hi-def, BUT not in the case of DKCR. I don't remember EFB>ram have this hi-def issue before in these games, but I'm not sure.

Also, what is the new "Virtual" option, I thought it was like "texture", but it can be on at the same time as "Ram"? It's a little confusing. So what results should the following yeild?

Virtual = ?
Ram = ?
Virtual+Ram = ?

I only get black sceen with all of my games in OpenGl now,
music plays in the background...

MP3 + OpenGL : no text as of rev 7365
MP3 + DX9 / Virtual+Ram : Looks perfect but VERY slow. Also, kind of systematic crash where it did not use to be
Grand Slam Tennis + DX9 / Virtual + Ram : text perfect (this is a great improvement) but colours destroyed

I found the option causing black screen,
it´s the antialiasing feature in Ogl !

And to my question above, is there another "per-rom" option to toggle between the 3 settings? Before it was just a boolean for EFBTextureEnable. That "texture" willneed to get changed to "Virtual" also. Do we need a tracking bug for all this or something?

When a game performs a render-to-texture effect, it sends a command to the GP to export a portion of framebuffer to RAM. Later, it can reference that area of RAM as a texture.

Here are the options for emulating this:

RAM: Dolphin performs the actual framebuffer-to-RAM transfer. Some games require this.
Virtual: Improves the quality of the effects by storing a high-resolution copy of the framebuffer. When the RAM area is used as a texture, load the high-resolution copy instead.

You can enable both simultaneously. Dolphin detects if the copied RAM was modified by the CPU before being used as a texture again. If so, the high-res copy is discarded and the texture is reloaded from RAM. This causes the scaling problem in DXCR. I'm not sure what the game is doing to the texture.

I have never seen the texture corruption that many users are reporting. Fixing that bug will be an uphill battle.

Ok, got it. Thanks for the explanation. Sorry for getting off topic, but hey, it's my topic. :) So would this be correct then?

Ram: Pure, slowest but seems unneccessary. Slowest speed.
Ram+Virtual: Best of both worlds - full accuracy plus hi-res textures most of the time. Medium speed.
Virtual: Always hi-res, but may cause glitches in some games. Fastest speed.

@Neo or Nolan:
Wouldn't it make more sense to have 3 options in the UI now:
"Virtual", "Ram" and something like "Mixed", "Virtual+Ram", "Both", "Combo", or "Full".

And then we'll need something for the inis to differenciate between the 3 and set this per game. Currently we can only toggle on/off the "Virtual" option.

That's a good way to describe it. Right now we have three checkboxes: Enable, Virtual, RAM. The "Enable" option is redundant.

(4)
SMG1 - DX9 w/Virtual: Mario shadow is a square and the lighting overall is dim.

And forget what I said about DCKR. Sorry. Now that I understand the system, I ran full "virtual" and the scaling on characters is full. With "Mixed" or "Ram", Donkey and others are low-res.

The "Enable" option is redundant? If you uncheck it, EFB copies are disabled, I think that's a pretty important option.

You can get the same result by unchecking Virtual and RAM.

(5)
RE Darkside Chronicles gun reticle glows when you have a prime head shot, but now these squares appear instead. Occurs with all EFB settings and this game makes heavy use of EFB>Ram & STC I believe. This worked fine a couple week ago in around r7600. Screenshot:
http://imageshack.us/photo/my-images/696/unlednk.jpg/

Issue 4636 has been merged into this issue.

Since I've started testing this branch and now in the official one, Mario Kart Wii freezes (with music continuing) after 15-30 seconds of starting a race with pretty much any combo of plugins/settings.

Configs tested: Open GL, DX11, DX9, JIT, JITIL, x64,x86 (EFB disabled and enabled)
Isos: Mario Kart Wii PAL and USA.

My specs: I7 @ 4Ghz, GTX 570 SLI, Windows 7 64b, 6GB RAM

Video: http://www.youtube.com/watch?v=x3VzvaZ9UJs

• 007 GOLDENEYE (Wii) at the beginning the lights effect on the reflecting floor (lamp reflected) are wrong (green color with Virtual+RAM or only RAM - almost right color with only virtual but all messed up on the screen);

• FINAL FANTASY CRYSTAL CHRONICLES (GC) messed up colors in the menu with every EFB combination (violet/green colors - it's the same effect as without safe texture cache on standard version).

The other type of issue, UI inconsistency.

Since the texcache-rewrite merge you cannot tell users to "uncheck all checkboxes in the hacks tab for maximum accuracy" since, as far as I understand, "RAM + NOT virtual" is the most accurate setting in this case.
I intentionally designed the new dialog UI to use this behavior, it would be nice if you somehow fixed it accordingly. Change RAM to "Do not track RAM updates" (or CPU updates or whatever) or sth ;)

Mario Super Sluggers baseball shows texture errors reminiscent of using a revision before r7625 with ATC off. Some textures that had trouble before are fine, the ones that seem to have errors now are the ones which rely heavily on alpha transparencies.

• NEW SUPER MARIO BROS WII is very slow even using only EFB to texture and furthermore with EFB copy to RAM option enabled you don't see anymore the brown platforms.

I can confirm the nsmb big slowdown as well.

When "TexCache Rewrite" is complete, can we get more speed or more accurate graphics ?

Wii Sports Bowling and other games I see a huge slowdown and the Mii's render worse, black elements. i7 2.0Ghz with ATI Radeon 11.6 drivers (turbo goes to 2.7Ghz on two of the cores for Dolphin).

Where I would see 64 FPS in Bowling, I now am lucky to get 48.

Found a graphical corruption on No More Heroes 2 with r7625 & later revision (Compared with r7623 & previous rev). All rev used same setting, except The EFB Copies...

r7623 used EFB Copy to Texture
r7625 used EFB Copies to Virtual only (Not mixed).

Some Screenshot Comparison :

r7623
https://lh4.googleusercontent.com/-9QCb4VSrWzA/ThUlKS3RvWI/AAAAAAAAANI/RCjfph4kuSc/s1600/r7623.jpg
https://lh5.googleusercontent.com/-yEH3rX7Ar1o/ThUkhNMfEmI/AAAAAAAAAM4/R2Q7m0T_dH4/s1600/r7623_2.jpg

r7625
https://lh3.googleusercontent.com/-qxcF79_mDoQ/ThUkvrcfxmI/AAAAAAAAAM8/WeExMerkhzw/s1600/r7625.jpg
https://lh5.googleusercontent.com/-us28haZ56Tk/ThUk1AiLoVI/AAAAAAAAANA/sjp6nu0ZKNk/s1600/7625_2.jpg
https://lh6.googleusercontent.com/-hwetR1kv5h4/ThUlCehX5BI/AAAAAAAAANE/ak6oTcH0ycA/s1600/r7625_3.jpg

with r7625 there are duplicate transparant graphic on all scene.

Of course this problem can be solved if EFB Copies to RAM ia checked...but it decreased FPS a lot (unlike previous rev with no graphical corruption only set to texture)

other problematic games:

Warioworld (GC) -> DX9 (efb c.: virtual/ram), OGL (efb c.: ram) -> intro,etc...
Muramasa (WII) -> DX9/DX11/OGL (efb c.: virtual/ram) -> intro,etc...

problems with MKDD(DX9/virtual) i reported earlier are fixed

more problematic games:

• Crazy Taxi (dx9/dx11/ogl - virtual/real) - intro not visible
• Super Monkey Ball 2 (dx9/virtual... - challenge/beginner/stage5 - gfx probs)
  ( http://www.shrani.si/t/M/WU/21AJh7hA/gm2e8p-5.jpg )
• problems with real XFB
  • Vievtiful Joe (GC)/Bomberman Jetters (GC)/Tube Slider (GC)/...:
    • DX9 - broken
    • DX11 - working ok
    • OGL - partially working

Trauma center games with efb virtual and/or ram behave as if safe texture cache is off before the rewrite branch was committed to trunk, with all incorrect colors for textures.

• DEAD RISING CHOP TILL YOU DROP (Wii) graphical gliches on some icons (for example yes - no icons and some button icons) and what's more important, a black square on the circle targeting pointer when aiming with the gun.

With DX9 External frame buffer on real doesn't work, it works only with OpenGL

• NBA LIVE 2003 (GC) the parquet is almost white (DX9 and OpenGL) while it has to be light brown (as it it displayed correctly in Dolphin 3.0); also there are other graphical gliches with the letters in the menù (some black borders around them) and since this is not the first game with this problem, I think that the texcache rewrite version has generally some problems in displaying them correctly.
  Furthermore using OpenGL you cannot see the body of the players (only face, arms and shoes are visible)

Issue 4762 has been merged into this issue.

In addition to my report earlier in Comment 27 - I am on a new laptop system.
Dell Latitude E6520 - Intel Core i7-2720QM (2.20GHz base, runs 3.0Ghz turbo in Dolphin); Nvidia NVS 4200M 512MB GPU.

For testing, I turn off FPS limit and Audio FPS limit.

On Dolphin 3.0 x64, Windows 7 x64, I get 85+ FPS in Wii Sports Bowling while getting ready to throw the bowling ball. With latest release, R7689 - I see only 58 FPS. This is a 50% slowdown! This started with the TexCache Rewrite.. and I can see this slowdown in many other places (menus, etc). I try both DirectX9 and DirectX11, same general slowdown with the latest builds.

Has there been any kind of statement as to settings or the general expectation of Dolphin performance with this rewrite? I see no improvement in the emulation behavior, and I like the other new changes in post 3.0 versions, but this slowdown is HUGE... is there some way I can assist to profile and identify why it is so different?

Cool! Well, then R7690 I tried - running better than ever! I turned off the EFB to RAM.

Just to make this post more useful ;) Here are screen shots of Wii Sports Bowling. Nvidia NVS 4200M 512MB on i7-2720QM running at 3.0Ghz Turbo. On this screen... on same settings (FPS turned on, 640x480 internal res)...
DirectX11 gets around 75FPS peak: http://sites.google.com/site/stephengutknecht/Home/WiiSports_r7690_x64_DirectX11.png - RENDERS Mii Perfect!
DirectX9 gets slower, around 60FPS peak: https://sites.google.com/site/stephengutknecht/Home/WiiSports_r7690_x64_DirectX9.png - Mii renders with corruption
OpenGL is about inbetween speed, 68FPS peak: https://sites.google.com/site/stephengutknecht/Home/WiiSports_r7690_x64_OpenGL.png

So, on my hardware, DirectX 11 is far outperforming DirectX 9 - and it is rendering the Mii attributes correctly on 11 :)

New texture code makes homebrew apps that reuse textures (mainly in emulators where the emulated game gets drawn on one single texture) now only show the first frame that gets rendered, and the texture never gets updated.

baby.lueshi: That sounds like something that could happen if the game doesn't send a tmem invalidation command to the GP before using the modified texture. That means the homebrew apps are buggy, and it's only by chance that they work on real hardware.

Currently we skip the texture hash-checking if the tmem has not been invalidated, so the data could change and we wouldn't reload the texture until an invalidation command is received.

We could ignore tmem validation and just hash-check every single time the texture is used, but that might be slow. Maybe we could compromise by forcing tmem to invalidate on every frame.

"We could ignore tmem validation and just hash-check every single time the texture is used"
That's what we had been doing until the texcache-rewrite branch had been merged, why aren't we doing that now anyway?

This might be caused by this problem as well http://code.google.com/p/dolphin-emu/issues/detail?id=4654
@comment 28: As you can see in the last comment of my linked issue the problem appears with r7625 as well.
Also, this might be related:
http://code.google.com/p/dolphin-emu/issues/detail?id=4769

Issue 4772 has been merged into this issue.

Issue 4769 has been merged into this issue.

Issue 4763 has been merged into this issue.

Issue 4760 has been merged into this issue.

Issue 4780 has been merged into this issue.

Issue 4758 has been merged into this issue.

Issue 4744 has been merged into this issue.

Issue 4741 has been merged into this issue.

I got a message from billiard26. I now think we should back out the texcache-rewrite merge since it's causing many problems and few people are noticing any improvements.

I noticed an improvement only in Disney Epic Mickey, instead in other games the rewrite brought some problems...so it is gonna be replaced soon by the default version?
Btw what happened to the revision numbers? I can't understand anything with that sort of alphabetical versions, not to tell the "invisible" revisions with missing links that don't even show on the changes log...are these dev-only revisions?

hatarumo...@hotmail.com @
It's already been reverted to the old implementation.

Really? But I haven't found anything about it on the changes log...

Just so people know, the texture cache rewrite somehow fixed the bloom offset problem in some games: http://oi56.tinypic.com/2qxp8ns.jpg

Um, that just looks completely broken

yeah : S

Issue 4654 has been merged into this issue.

Issue 4645 has been merged into this issue.

I liked of the texcache-rewrite, but was removed due to some bugs that was causing, but instead could add this method with the current, depending on the game that the User can choose what works better. Well that could give a 2nd chance, because in games with Miis, it works at full speed without losing face, I compared the r7719 EFB Virtual with GLSL-master_3.0-294 and the 3.0-306 with EFB to RAM, but the r7719 works up to 3x more fast than the others, without lose the faces of Miis or if the same speed with EFB to texture, the GLSL-master_3.0-294 and the 3.0-306 lose the faces of Miis or the shadows in Lost in Shadow, tested with the games Wii Sports, Wii Sports Resorts, Wii Play, Wii Music, Wii Party, Mario & Sonic at the Olympic Games, Mario Kart Wii, Lost in Shadow, etc.

Issue 4703 has been merged into this issue.