Project

General

Profile

Actions

Emulator Issues #11897

closed

Sonic Colors fails to render 2D elements on OpenGL ES only

Added by JosJuice over 4 years ago. Updated about 3 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
% Done:

0%

Operating system:
N/A
Issue type:
Bug
Milestone:
Current
Regression:
No
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
5.0-502
Fixed in:
5.0-13963

Description

Game Name?

Sonic Colors

What's the problem? Describe what went wrong.

According to https://forums.dolphin-emu.org/Thread-sonic-colors-gui-elements-missing, 2D elements in Sonic Colors are not visible when using OpenGL ES. OpenGL and Vulkan work correctly.

What steps will reproduce the problem?

Looking at the title screen is probably the easiest way to reproduce the problem.

Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.

Yes, 5.0-11227.

If the issue isn't present in the latest stable version, which is the first broken version? (You can find the first broken version by bisecting. Windows users can use the tool https://forums.dolphin-emu.org/Thread-green-notice-development-thread-unofficial-dolphin-bisection-tool-for-finding-broken-builds and anyone who is building Dolphin on their own can use git bisect.)

5.0-502 (https://github.com/dolphin-emu/dolphin/pull/4164)

If your issue is a graphical issue, please attach screenshots and record a three frame fifolog of the issue if possible. Screenshots showing what it is supposed to look like from either console or older builds of Dolphin will help too. For more information on how to use the fifoplayer, please check here: https://wiki.dolphin-emu.org/index.php?title=FifoPlayer

I don't have the game myself, so I can't create a FIFO log or screenshots, but they happen to already exist from back when this was broken on more than OpenGL ES: https://fifoci.dolphin-emu.org/dff/soniccolors-mm/

What are your PC specifications? (CPU, GPU, Operating System, more)

The reporter specified that it happens both on Linux (with PreferGLES = True) and Android (Adreno).

Actions #1

Updated by JosJuice over 4 years ago

  • Milestone set to Current
  • Regression start set to 5.0-502
Actions #2

Updated by blaahaj about 3 years ago

If bSupportsClipControl = false and bSupportsDepthClamp = false, the behavior is matched for OpenGL.

Pull request 4164 moved the "sonic epsilon hack" to shader code. However, it was only done for targets with depth clamping. It seems this coincides with clip control.

If the "sonic epsilon hack" is added to the code for no clip control, it seems fixed:

--- a/Source/Core/VideoCommon/VertexShaderGen.cpp
+++ b/Source/Core/VideoCommon/VertexShaderGen.cpp
@@ -516,11 +516,11 @@ ShaderCode GenerateVertexShaderCode(APIType api_type, const ShaderHostConfig& ho
   if (!host_config.backend_clip_control)
   {
     // If the graphics API doesn't support a depth range of 0..1, then we need to map z to
     // the -1..1 range. Unfortunately we have to use a substraction, which is a lossy floating-point
     // operation that can introduce a round-trip error.
-    out.Write("o.pos.z = o.pos.z * 2.0 - o.pos.w;\n");
+    out.Write("o.pos.z = (o.pos.z * (1.0 - 1e-7)) * 2.0 - o.pos.w;\n");
   }
Actions #4

Updated by blaahaj about 3 years ago

It seems this coincides with clip control.

Please disregard this.

Actions #5

Updated by JosJuice about 3 years ago

  • Status changed from New to Fixed
  • Fixed in set to 5.0-13963
Actions

Also available in: Atom PDF