[macOS] loading a mod causes rendering with wrong screen size

[Friggigatto]

When activating mods in 0 A.D. alpha 23 in OS X 10.11.6, graphic glitches appear. I've attached a screenshot.

The top part of the screen is repeated, and also the mouse position is off (the pointer is not visible in the screenshot, but it is hovering above the "learn to play" button).

My machine is a MacBook Pro mid-2012.

---

EDIT:

• similar issue described in #5938

reproducible

• this bug is reproducible from the current git version all the way to Alpha XX ​Timosthenes [17965], after which I stopped testing further
• the only thing that has changed over the years is the size of the "black" box at the top in A23, it was quite large as seen in the first picture of this description
• with A24 the size of the black box became smaller as seen in the 2nd picture in the description

[elexis]

Which mods? It sounds like it might be an issue with the mod.

[Krinkle]

I've experienced something similar. Happens every time after pressing "Start mods", e.g. when enabling or disabling fgod (I have no other mods currently).

• macOS 10.14.6
• MacBook Pro 15" Retina
• Resolution 2880x1800 (2 dppx, as 1440x900)
• Graphics card: AMD Radeon R9 M370X 2 GB; and Intel Iris Pro 1536 MB. I have the macOS "Automatic graphics switching" setting disabled, which means it is (should be) using the AMD Radeon always.

On A23, and on trunk until "recently", what happened for me is that the top 150px (154px?) is red, and the actual game is pushed down (partly off-screen). The mouse iterations are all wrong at that point (based on where the pixels should be, not where they currently are).

Last week I did a full rebuild of my trunk install, and since then the bug changed. It's now getting stretched out. The game is 150px less tall, but then stretched back out. Again, the mouse is still "correct" that is, it is acting on where the pixels should be.

After this, I quit the game and restart, at which point everything is fine until the next time I toggle a mod.

[Krinkle]

Per elexis, I instrumented the before-last line of CVideoMode::SetVideoMode as follows:

debug_printf("window size (xres, yres): %d %d\n", g_xres, g_yres);
debug_printf("window position (winX, winY): %d %d\n", m_WindowedX, m_WindowedY);

Upon triggering the bug by pressing "Start mods", the automated relaunch that triggers the bug, logs the following:

…
TIMER| InitVfs: 1.847 ms
Writing the mainlog at …/0ad/logs/mainlog.html
TIMER| CONFIG_Init: 4.879 ms
Sound: AlcInit success, using Built-in Output
window size (xres, yres): 1440 746
window position (winX, winY): 805240832 805240832
UserReport written to …/0ad/logs/userreport_hwdetect.txt
TIMER| RunHardwareDetection: 3.836 ms
…

Notice that the reported yres is 154px short of the actual height (900px).

[elexis]

In the report Stan attached to #5599, we can see that CVideoMode::m_CurrentW and other members are not initialized.

Given that one has the code at hand and found a place where the according window size is off, it should be possible by reading the code and adding more printf to locate the call that produces the wrong result.

[Langbart]

• a closely related ticket mentioned in the description (#5938)

[Stan]

Any chance you could try the suggestions on #6649? Thanks in advance.

[Langbart]

The problem persists even after applying the patch from: comment:7:ticket:6649

source/ps/VideoMode.cpp

@@ -397 +397 @@
             flags |= SDL_WINDOW_OPENGL;
         else if (m_Backend == Renderer::Backend::Backend::VULKAN)
             flags |= SDL_WINDOW_VULKAN;
-        m_WindowedX = m_WindowedY = SDL_WINDOWPOS_CENTERED_DISPLAY(m_ConfigDisplay);
+        if (fullscreen)
+            m_WindowedX = m_WindowedY = SDL_WINDOWPOS_UNDEFINED_DISPLAY(m_ConfigDisplay);
+        else
+            m_WindowedX = m_WindowedY = SDL_WINDOWPOS_CENTERED_DISPLAY(m_ConfigDisplay);
 
 #if OS_MACOSX && SDL_VERSION_ATLEAST(2, 0, 6)
         if (m_Backend == Renderer::Backend::Backend::VULKAN)

---

Debug

• setting a debug message like this:

  source/ps/VideoMode.cpp

  @@ -511 +511 @@
           }
       }
   
  +    LOGWARNING("before SDL_GetWindowSize Width:%d Height:%d", m_CurrentW, m_CurrentH);
       // Grab the current video settings
       SDL_GetWindowSize(m_Window, &m_CurrentW, &m_CurrentH);
       m_CurrentBPP = bpp;
  +    LOGWARNING("after SDL_GetWindowSize Width:%d Height:%d", m_CurrentW, m_CurrentH);
   
       if (fullscreen)
           SDL_SetWindowGrab(m_Window, SDL_TRUE);

• after triggering the issue, this was the outcome

  # notice the height changed
  WARNING: before SDL_GetWindowSize Width:1680 Height:1050
  WARNING: after SDL_GetWindowSize Width:1680 Height:1028
  

• making the following change:

  source/ps/VideoMode.cpp

  @@ -512 +512 @@
       }
   
       // Grab the current video settings
  -    SDL_GetWindowSize(m_Window, &m_CurrentW, &m_CurrentH);
  +    SDL_GL_GetDrawableSize(m_Window, &m_CurrentW, &m_CurrentH);
       m_CurrentBPP = bpp;
   
       if (fullscreen)

• the problem becomes "less bad" for Vulkan, the window gets cut off from the bottom and the cursor works correctly when hovering over an element, for OpenGL it remains the same as described in the ticket

[Langbart]

reproducible section