-
Notifications
You must be signed in to change notification settings - Fork 77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue opening game on macOS 3/4 of window is red #1621
Comments
I'm intending to git bisect this, and try and work out where it breaks. The only version I can get to build is v0.9.5, trying to build anything before that (even v0.9.4) gives me the following errors (I can't seem to workout where to set the -Wno-deprecated-copy flag to avoid this (I'm not a C/C++ developer): ` In file included from /Users/dan/rttr/s25client/libs/common/include/Rect.h:7: I don't want to fix the code, just work out what I need to get it to build, so I can git bisect through and see if I can find the bug that's causing this. |
I've found -DRTTR_ENABLE_WERROR=ON, setting this to -DRTTR_ENABLE_WERROR=OFF seems to do the trick :) Although I'm now running into
It then repeats for all the settings such as getValueI("submit_debug_data") etc... Which feels like an actual code issue, and I'm sorry I don't know how to solve that one. |
When you checkout different commits (e.g. when bisecting) you need to also checkout the submodules used at that version, i.e. |
Hi, I can run it on MacOS 13.0.1 via s25client. Whole window is used. So no problems at all. After using s25update, the bug appears. So I think it has to do with the update procedure |
I recommend not to start the s25client.app but the s25client in s25client.app/Contents/MacOS/ hold command key and right-click on the s25client.app to open it inFinder and navigate to the path. |
I'll try and test it tomorrow on macOS 14.1 latest. What version were you using? |
I used the stable version 0.9.5 |
I updated now to MacOS 14.1 and RTTR continues working. How did you start the program? If you used the s25client.app then the update was executed automatically. |
Other Workaround. More convenient (if you are able to run the s25client.app (the App with the S2 Logo. I was not able to use this on MacOS 13.0.1: I assume you installed it in your Applications folder. After installing, so before the first launch of the app do the following. Go to /Applications/s25client.app/Contents/MacOS and rename s25update. I used s25update_rename as new name. The important thing is, it needs a new name such that it cannot be found. Deleting should also work, but I did not test it. start the app. |
This issue still persists with latest source from |
That is the big question. @diwilli did you found anything by bisecting? @Ekliptor or who else wants to try bisecting the issue (we can't do that due to missing bare metal Mac) here a short guide:
|
UPDATE 2: working til including v0.9.5 from source (and from binaries if i remove the updater). It's working correctly with the latest Update: Aside from audio driver not working, which I'll figure out
|
@Ekliptor You can pass |
I found the commit that broke the red screen:
UPDATE: and I can confirm reverting the change in that commit fixed the issue on latest master commit:
|
Uff, ok. This was introduced in #1594 by @falbrechtskirchinger who might be more familiar with this part. Possibly the logic using that to get a GuiScaleRange is the cause: https://github.com/Return-To-The-Roots/s25client/pull/1594/files#diff-b5b38a3930a1a7e323ee58aa4e287c55f4f8d4a69be4680f39976237295540b7R111-R121 Also suspicous to me is the use of the window sizes for the viewport at https://github.com/Return-To-The-Roots/s25client/pull/1594/files#diff-4859828a67bfa671f97fdc7ecd34979fb84152f9f681aa4369788eddc5701c3dR312-R313 Maybe this should have been the unscaled render size. @Ekliptor Can you check&post your values of
const Extent renderSize = getGuiScale().screenToView<Extent>(videodriver->GetRenderSize()); . This is just an idea which might work but I guess it is more complicated than that.
Thinking about it I have doubts about how #1594 is supposed to work, especially for |
Thx for the quick feedback over the holidays. Changing The sizes with ALLOW_HIGHDPI (buggy red screen):
And the working screen:
|
I have nearly the same issue on Mac OS 13.6.3 (22G436) on a Macbook Pro 14" 2021. Any news / findings in this Mac issue? I |
Hi,
Does my workaround solve the problem?
See one of the comments above…
Thomas Lidy ***@***.***> schrieb am So. 18. Feb. 2024 um
23:41:
… I have nearly the same issue on Mac OS 13.6.3 (22G436) on a Macbook Pro
14" 2021.
Only the lower left quarter of the screen is populated with the S2
graphics / main screen. The rest of the screen is black (not red). Moreover
the mouse can only move in the upper half of that quarter area. That means
I can enter the Settings screen but cannot reach the graphics setting as
the button Graphics cannot be reached by the mouse.
Any news / findings in this Mac issue? I
t practically renders RTTR unusable on newer Macs.
—
Reply to this email directly, view it on GitHub
<#1621 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHFXO7N2KQJJQTX3NHRY2MTYUJ7TPAVCNFSM6AAAAAA33NS6KKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJRGQ3DSNZWHA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
same here. |
Hi, wasn‘t asked, but just wanted to chime in that I have the exact same issue @audiofeature described and that the workaround (temporarily killing the updater) worked for me on 0.9.5. Am on a MacBook Pro 2019 running Sonoma 14.3.1. |
EDIT: Sorry, I missed that |
Okay, I have a fix for the viewport: diff --git c/libs/s25main/drivers/VideoDriverWrapper.cpp i/libs/s25main/drivers/VideoDriverWrapper.cpp
index 7daa4801c..15d19d2e5 100644
--- c/libs/s25main/drivers/VideoDriverWrapper.cpp
+++ i/libs/s25main/drivers/VideoDriverWrapper.cpp
@@ -305,19 +305,19 @@ void VideoDriverWrapper::RenewViewport()
if(!videodriver->IsOpenGL() || !renderer_)
return;
- const Extent renderSize = videodriver->GetRenderSize();
+ const Extent renderSize = getGuiScale().viewToScreen<Extent>(videodriver->GetRenderSize());
const VideoMode windowSize = videodriver->GetWindowSize();
// Set the viewport and scissor area to the entire window
- glViewport(0, 0, windowSize.width, windowSize.height);
- glScissor(0, 0, windowSize.width, windowSize.height);
+ glViewport(0, 0, renderSize.x, renderSize.y);
+ glScissor(0, 0, renderSize.x, renderSize.y);
// Orthogonale Matrix erstellen
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
// 0,0 should be top left corner
- glOrtho(0, renderSize.x, renderSize.y, 0, -100, 100);
+ glOrtho(0, windowSize.width, windowSize.height, 0, -100, 100);
glMatrixMode(GL_MODELVIEW);
glLoadIdentity(); That makes the rendering appear correctly (only testing the menu at the moment). The mouse bounding box is still out of whack though. I'm guessing it needs to have the dpi scale applied to it, as I only have access to the top-right quarter of the screen before I hit the actual screen bottom/right and get clamped there. |
Okay folks, until this will be resolved, the beforementioned workaround clearly works, thanks! Don't forget to rename that file before the first run :) Macbook Pro 2020 (13-inch), macOS Sonoma Version 14.2 (23C64) |
The author of the Visual Pinball Standalone Player had the same problem. He added the option "HighDPI = 0 / 1" to the ini file. Maybe you can use his code. His repository can be found here: https://github.com/jsm174/vpinball/actions |
Tried this, unfortunately did not help in my case. 16-inch 2021 Apple M1 Max, OS 14.6 (23G80) |
I've solved this on my end by changing the screen resolution to 1920x1200, now the mouse tracks within the whole window. This resolution results in a screen where the text is a bit blurry, but I'll simply change it back to the default 1728x1117 after I'm done playing. I didn't need to touch the CONFIG.INI file (located here /Users/[YourUsername]/Library/Application Support/Return To The Roots) in this case, looks like this by default:
So if all else fails try starting the game using different sets of screen resolution until you find something that works for you. Remember to toggle "Show all resolutions" to show all resolution sets. Eg. these made the game work for me: |
Last update from me here: I got it working without having to change the macOS screen resolution each time I want to play the game:
|
Thanks for the update. I wanted to tackle this but got side-tracked by other issues. While I don't have a Mac (which makes it hard to reproduce exactly) I found a way to reproduce this on Windows using the screen scaling option of the display settings. |
Nice to hear that there is a fix on the way. Thanks a lot for your time and work. I still love this game after all those years |
the workaround above from here works for me too, but sadly this one from here doesn't:
I'm on a 2020 M1 MacBook Pro. Let me know if I can do anything to help resolve the issue. |
I'm glad to see that I'm not the only one having this issue. For me, it doesn't occur for the latest stable build (as mentioned here). Running a 2019 MBP with an 4k monitor (if it helps). Can I support you solving this issue? And btw.: Thank you for bringing back my childhood and improving the game :) |
I have the same issue on my 2015 MacBook Pro , none of the suggested solutions works for me on my MacMini M1, it runs fine without this problem |
Any news on this ? |
Not yet. Fix is in the works as time permits |
Not a real fix obviously, but until it is ready, could we just disable the HiDPI feature on macOS for the time being? diff --git a/extras/videoDrivers/SDL2/VideoSDL2.cpp b/extras/videoDrivers/SDL2/VideoSDL2.cpp
index 4fa0b49aa..8a40e9100 100644
--- a/extras/videoDrivers/SDL2/VideoSDL2.cpp
+++ b/extras/videoDrivers/SDL2/VideoSDL2.cpp
@@ -134,7 +134,7 @@ bool VideoSDL2::CreateScreen(const std::string& title, const VideoMode& size, bo
const auto requestedSize = fullscreen ? FindClosestVideoMode(size) : size;
unsigned commonFlags = SDL_WINDOW_OPENGL;
-#if SDL_VERSION_ATLEAST(2, 0, 1)
+#if SDL_VERSION_ATLEAST(2, 0, 1) && !defined(__MACOSX__)
commonFlags |= SDL_WINDOW_ALLOW_HIGHDPI;
#endif This "fixes" the issue for me (at the cost of upscaling instead of proper HiDPI rendering evidently). |
Disable High DPI support/request for now until the GUI scaling is adjusted to support it. See Return-To-The-Roots#1621
Good idea. As it is not only related to MacOS but any HighDPI system I disable that for now until I got enough time to finish the real fix: #1724 |
under a fully updated macOS 13.5
This happens on both latest stable 0.9.5 and latest nightly s25rttr_20230814-e37a322209cffb00fda4afd50c87b8f7e8261083-darwin.x86_64.tar.bz2
Version 0.8.1 doesn't have this issue and launches correctly.
Happy to test updates as they're available.
The text was updated successfully, but these errors were encountered: