Emulator Issues #267

Sonic Heroes graphical problems (EFB scaling issue)

Added by superempra over 10 years ago. Updated about 3 years ago.

% Done:


Operating system:
Issue type:
Relates to usability:
Relates to performance:
Relates to maintainability:
Regression start:
Fixed in:


What steps will reproduce the problem?
1. Use OGL plugin
2. Dual Core enabled
3. Play Sonic heroes

What is the expected output? What do you see instead?
The ground is the wrong colour and whenever you move forward that graphical
glitch moves with you.

What version of the product are you using? On what operating system?
Dolphin 32 bit Rev 1029

Please provide any additional information below.
Intel Core 2 Duo 2.40GHz
ATI Radeon HD2600 XT 256MB of VRAM

G9SP8P-2.png (2.27 MB) G9SP8P-2.png seapancake, 12/29/2015 01:26 PM
G9SP8P-4.png (2.28 MB) G9SP8P-4.png seapancake, 12/29/2015 01:26 PM
G9SP8P.dff (4.63 MB) G9SP8P.dff seapancake, 12/29/2015 01:34 PM

Related issues

Has duplicate Emulator - Emulator Issues #3888: Sonic Heroes black areas ingameDuplicate

Has duplicate Emulator - Emulator Issues #5346: sonic heroes ground glichDuplicate


#1 Updated by Sonicadvance1 over 10 years ago

Try again with a rev above 1048 and see if this problem still persists.

#3 Updated by superempra over 10 years ago

It still happens with R1097

#4 Updated by marcus almost 10 years ago

  • Status changed from New to Fixed

Fixed now.

#5 Updated by knuckles500 about 9 years ago

Sorry for the bump, but even though it's fixed for the OpenGL plugin - it isn't for
the DX9 plugin. But other than this bug, it should be a fully playable game.

As of R4878, the bug is still present in the DX9 plugin:

I don't know the revision number that fixed this problem with the OGL plugin, though. :(

#6 Updated by PeterAndre666 about 9 years ago

I only get that in DX9 if i check the widescreen hack, so i don't. :p

#7 Updated by knuckles500 about 9 years ago

What's your revision? Maybe I should update my copy of Dolphin, heh.

Also - 32bit or 64bit? Need some details. :\

#8 Updated by jayork42 about 9 years ago

I did see this recently, but I can't remember the plugin that was used. It has to do
with EFB copy reading from junk data in RAM and mapping random pixels I believe. I
also think that the reason why it stretches out everywhere might be because those
pixels would otherwise be transprent if EFB copy were handling the character shadows
correctly. But I'm not sure, that's just my guess.

#9 Updated by jayork42 almost 9 years ago

This issue still remains in the latest revisions. I've come to find out that
disabling EFB copy, enabling native, enabling EFB copy, and disabling native in that
order fix the problem until I get to a certain part of the level where the issue
happens all over again. Native fixes the problem.

#10 Updated by pascal.jouy almost 9 years ago

+1 to crashda..., expect that I have the same problem with OpenGL.
(Issue #2392)

#11 Updated by knuckles500 over 8 years ago

Hmm, I checked the Software Video Plugin, and the problem isn't there.

It's still there in every plugin besides the Software one.

#12 Updated by knuckles500 about 8 years ago

Just FYI, I finally figured out the fix for this issue, but with a catch.

You need to use the DirectX11 plugin.

The fix itself is very simple, and it's the only way to fix it (no other settings or video plugin besides the software one or maybe the OpenGL plugin will correct it).

What you have to do is set the EFB Scale to 1x. That's all you have to do.

#13 Updated by DimitriPilot3 about 8 years ago

  • Status changed from Fixed to Accepted

I'm reopening this issue, as it still exists. I guess this might be an issue with EFB scaling which results into the main character's shadow's texture having non-transparent edges, causing that texture to be "extended" beyond its edges...

According to my experiments, I can say the following:
- It apparently occurs all the time in DX9 (meaning that no option can make the glitch disappear)
- In DX11 and OGL, it doesn't occur all the time - it mainly depends on the EFB scale option (example from DX11 which may vary in OGL):
- no problem using values lower or equal to 1 (0.375x, 0.5x, 0.75x, or 1x)
- when using values greater than 1 (2x or 3x), the problem appears (2 edges of the shadow texture are affected)
- when using Integral or Fractional scaling, the problem appears whenever the renderer window's width and/or height are greater than the native EFB resolution (640x574 - the affected edges depend on the width and the height)

Other notable things (example from DX11 which may vary in OGL):
- When the problem occurs (horizontally, "vertically" or both), some lines on the left/top borders of the screen look like they aren't drawn/refreshed correctly
(see and and
- The problem disappears for about one frame when the renderer is resized, which effectively refreshes the buggy lines I mentioned above...

I suspect the issue in DX9 to be different (worse?) from the one in DX11/OGL... But that's only a guess :P

#14 Updated by DimitriPilot3 about 8 years ago

FWIW, this video showing the effects of randomly changing options was posted in issue 3888:

The SSAA option in the DX11 plugin appears to be greyed out using my NVIDIA GeForce 8800 GTS 512. I assume it's because that GPU supports DX10 but not DX11...

#15 Updated by DimitriPilot3 about 8 years ago

issue 3888 has been merged into this issue.

#16 Updated by jayork42 about 7 years ago

Excellent demo Dimitri!

#17 Updated by NeoBrainX about 7 years ago

Is this still an issue?

If it is, could anyone upload a fifo player file for a frame where the problem is visible? (preferably at a place where it's VERY obvious)
To create one, follow these steps:
1. Start Dolphin
2. Select "Tools->Fifo Player" from the menu
3. Select the "Record" tab in the dialog that pops up.
4. Set the number of "frames to record" to 1.
5. Start the game (do NOT close the dialog) and get to the place where the problem occurs
6. When you've reached a place in the game where the problem is obvious, press the "Record" button in the Fifo Player dialog.
7. Wait a bit until the "Save" button isn't grayed out anymore.
8. Press the Save button and pick a location to store the fifo log.
9. Post the fifo log here; do NOT attach it to this bug report, upload it to an external host instead and just put a link here.

Please create multiple log files of the same scene:
1. With DX11, native internal resolution, EFB to texture (the problem should NOT be visible in this case)
2. With DX9 (problem should be visible)
2. With any configuration where it happens in both OGL and DX9 (problem should be visible)

#18 Updated by jayork42 about 7 years ago

This is still a problem with the latest binary, 3.0-415. This still slways happens with DX9. Same behavior with OpenGL, issue only appears if setting the EFB resolution is greater than 1x or enabling AA. I'm unable to test DX11 because I'm running Windows XP. Can someone test this with the 3.0-415 32-bit build?

Here are the 2 fifo snapshots. DX9.dff is DX9 with EFB resolution set to 1x and no AA. OGL_15.dff is OpenGL using 1.5x and no AA. I would've tested AA between plugins but these settings differ, so we should ignore AA for the moment to keep variables to a minimum.

I may have a hypothesis as to what's going on here. I think we can agree by now that the edges of the mapped texture are nontransparent when this problem appears. Let's also assume the game engine is always stretching this texture to infnity in all directions. My guess for this is when upscaling EFB copies to 1.5x and above, the area of the actual image of the shadow exceeds the area of the bounding box used by the game engine to map the shadow to the terrain. I'm thinking the size of this bounding box doesn't change, yet the engine has no way of detecting that there are nontransparent pixels out of bounds of the box (because all of these settings are hacks). Because AA also upscales everything, this must be why AA breaks this too (but should AA really effect EFB copies other than the main frame buffer?) The images below explain this; the first being 1x and the second 1.5x.

These are EFB copies ripped using "Dump EFB to texture." With 1x the frame size is 128x128, with 1.5x it's 192x192, as expected. The image of the shadow is scaling with the frame.

#19 Updated by NeoBrainX about 7 years ago

Thanks so far; Could you create another fifo log of the same scene with opengl but where the problem is not visible?

#20 Updated by jayork42 about 7 years ago

Hmm. That's not the case. According to Dimitri's screenshots the shadows are clearly NOT going out of bounds. Something else is going on here. If you move around you'll notice the streaks change colors, even when you're not moving. My next guess is that something in memory is overflowing into the space used for the current shadow frame. Maybe a texture that's being upscaled next to this buffer. The interesting thing is these pixels appear to be garbage. Perhaps a nearby texture of a different format? If you move around you will eventually notice the lower right skew is flashing in a predictable pattern. This appears to be reflecting the current memory space used for the animated coin on screen as the flashing pattern is spot on with the coin's looping animation. If someone takes the time to debug VRAM this should explain what's happening.

#21 Updated by jayork42 about 7 years ago

Ok, OpenGL with 1x internal res:

#22 Updated by jayork42 about 7 years ago

Wow, the fifo logs don't show this at all. All 3 snapshots are normal. :\

#23 Updated by NeoBrainX about 7 years ago

Funnily enough, all three fifo logs show the reported issue for me.. :P

#24 Updated by jayork42 about 7 years ago

Well, better you than me. :P

#25 Updated by skidau almost 7 years ago

issue 5346 has been merged into this issue.

#26 Updated by copperstone123 almost 7 years ago

I tried using Direct311 and the black grapchis went awy but the game went slow I am using dolphin 3.0win64.

#27 Updated by pascal.jouy almost 7 years ago

Issue is fixed, but only in D3D9/11 for now.
Indeed, the game seems slower than before (since the 2.0 builds), even if SPEED shows 100% or around. Don't know why.

#28 Updated by almost 7 years ago

Just tried Dolphin 3.0-600 build and it is NOT fixed for me in Direct3D9 UNLESS the Internal Resolution is set to 1x.

#29 Updated by godisgovernment over 6 years ago

The issue doesn't seem to be related to the specific IR value. For me, the game looks correct in two circumstances:
2.5x IR with EFB scaled copy disabled
auto (window size) IR with EFB scaled copy disabled, and i randomly change window size

perhaps it is related to some discrepancy between "window size" and the actual rendering size not being linearly related.

#30 Updated by godisgovernment over 6 years ago

The above comment was with ogl. with dx9 the issue still exists, and can be triggered by just opening the graphics options dialog...
fun... :p

#31 Updated by Billiard26 almost 6 years ago

  • Issue type set to Bug

#32 Updated by NeoBrainX over 5 years ago

Oddly enough, the issue shows up in the native dff player (commit 43f2c9d92be293c712686213311ca187f9c40aa9), too.

Maybe some texture cache issue with preloading or something?

#33 Updated by NeoBrainX over 5 years ago

Can you create a new 2-frame fifo log using a revision later than revision 198d60c56964fc8a9c679cdf9ab9805c684146ef ?

#34 Updated by JMC4789 about 5 years ago

I found out the one surefire way to make the problem go away at higher resolutions IS... to keep dragging the window size as you play. The game's effects still draw properly, but the game runs at 30 fps/60 VPS and it's kinda hard to see. But still, it's something? I think?

#35 Updated by NeoBrainX about 5 years ago

Poking again for a 2-frame fifo log using a revision later than revision ed67d1ae2f96 .

#37 Updated by magumagu9 almost 5 years ago

Comment 18 is on the right track. The game is trying to be a bit clever and skip some register updates, so there are four textures active when it draws the whole road: the road texture, and textures for the shadows of each of the three characters. The problem is, we aren't computing these textures accurately: . Note in particular the top line of the texture. That color tints the road, leading to the discoloration.

For comparison: it currently looks like , and it should look like .

I still need to look into how exactly the texture gets corrupted.

#38 Updated by magumagu9 almost 5 years ago

Oh, and one other thing that might be important. The shadows textures are dynamically computed: the game draws a model of Sonic on top of a black background, then composites the texture on top of itself to blur the shadow.

#39 Updated by JMC4789 almost 5 years ago

Excellent work deducing it; but is there any explanation why certain IRs + Window Sizes manages to avoid the error?

#40 Updated by magumagu9 almost 5 years ago

I think comment #13 actually provides the answer to that: the problem with the shadows only happens when the top line of the screen has garbage pixels. The game draws the shadow texture in the top left corner of the screen. So the problem with shadows is actually the same issue as the garbage pixels at the top of the screen (which basically boils down to us using floating-point math to compute the top-left corner of the EFB, and rounding the result inconsistently).

#41 Updated by NeoBrainX almost 5 years ago

Note: The fifo log provided in comment #39 is unsuitable for debugging.

I uploaded a good fifo log at . Indeed, the software renderer does not suffer from the issue pointed out here.

#42 Updated by magumagu9 almost 5 years ago

There was a bunch of discussion on IRC about this today. Quick summary:

  1. This game clears the screen by drawing a black rectangle where the top left corner is something like (0.50007, 0.50009) in screen coordinates.
  2. Due to the way the console does rasterization, this coordinate covers the pixel at (0,0).
  3. There's a bug in the OpenGL backend which means we don't rasterize the black rectangle correctly at 1xIR. This doesn't affect the D3D backend for reasons which we haven't figured out yet. neobrain is looking into it.
  4. Anything other than 1xIR not working is a consequence of the fact that higher IR levels aren't accurate emulation: if we pretend the resolution is twice as high, the top left corner of the rectangle is at (1, 1), and that simply doesn't cover the corner of the screen. It might be possible to enhance 2xIR mode to deal with cases like this more gracefully, or we could use something game-specific like a cheat code, but it's a separate issue.

#43 Updated by NeoBrainX almost 5 years ago

More updates:
- we now know for sure that each pixel is divided into a 12x12 grid with one grid point per subsample.
- hence it seems logical to have (fixed-point) screen coordinates as multiples of 1/12th.
- in the default configuration, multisampling is disabled, hence all subsamples are concentrated in the center of the subsampling grid.
- As tested in hwtests ( ), the screen coordinate of the center of the subsampling grid is roughly 7/12th (i.e. 0.58333333). However, the tests currently indicate that it's somewhat less than that, but I'm not sure if that's really true or just because the test suffers from rounding errors.
- the point is: the screen coordinate of (what we can consider to be) the pixel center is not at 0.5 as is the case normally*, but slightly shifted further to the bottom-right.
- hence, the current hw renderers put the black rectangle mentioned in point 1 of comment #49 at (1,1) instead of (0,0). I'm not completely sure why D3D works fine with 1xIR, and it really shouldn't.

As far as I can tell, a perfectly fine approximation of this behavior would be to shift all of our screen space coordinates by 0.08333333 (as a hardcoded value). Given that the reason for this offset is well-understood but the actual fix (namely to emulate limited screen space coordinate precision) is needlessly complicated and probably won't yield any better emulation, I'd say we should indeed go with that hardcoded solution. Note that I don't see any good way to fix this for non-native rendering resolutions.

Any other opinions for this?

  • As far as I could tell, both D3D and OpenGL guarantee the pixel center to be located at (0.5,0.5).

#44 Updated by NeoBrainX almost 5 years ago

P.S.: With a ridiculous amount of effort and care, it would be possible to fix this game even for higher internal resolutions. What you basically need to do at the end of the vertex shader stage is to preliminary convert the output coordinates to the theoretical screen space of 1xIR and then transform it back to clipspace such that the output is the same. Note that I'm intentionally being vague here because I'm not even sure myself how it would look in detail, nevertheless it will likely be quite the mess.

#45 Updated by JMC4789 almost 5 years ago

  • Status changed from Accepted to Fixed

#47 Updated by varalakshmi0806 almost 4 years ago

my I get to know the code to show movements of dolphin and the dolphins playing with a ball

#48 Updated by seapancake about 3 years ago


This issue is still present both in 4.0-8459 as well as 4.0-1474 which was supposed to have fixed this issue. Present on both ends whenever AA is enabled regardless of IR. 3-frame FIFI log attached as well.

Initial issue describes this is a general issue however later on there is a series of comments relating to AA so figure best to re-open this, if not happy to log a new bug.

#49 Updated by seapancake about 3 years ago

Nevermind, didn't read this is a known issue at when using AA.

Also available in: Atom PDF