• Dear Cerberus X User!

    As we prepare to transition the forum ownership from Mike to Phil (TripleHead GmbH), we need your explicit consent to transfer your user data in accordance with our amended Terms and Rules in order to be compliant with data protection laws.

    Important: If you accept the amended Terms and Rules, you agree to the transfer of your user data to the future forum owner!

    Please read the new Terms and Rules below, check the box to agree, and click "Accept" to continue enjoying your Cerberus X Forum experience. The deadline for consent is April 5, 2024.

    Do not accept the amended Terms and Rules if you do not wish your personal data to be transferred to the future forum owner!

    Accepting ensures:

    - Continued access to your account with a short break for the actual transfer.

    - Retention of your data under the same terms.

    Without consent:

    - You don't have further access to your forum user account.

    - Your account and personal data will be deleted after April 5, 2024.

    - Public posts remain, but usernames indicating real identity will be anonymized. If you disagree with a fictitious name you have the option to contact us so we can find a name that is acceptable to you.

    We hope to keep you in our community and see you on the forum soon!

    All the best

    Your Cerberus X Team

Fixed Mac Desktop builds rendering at 1/4 of window

olive

Member
3rd Party Module Dev
Tutorial Author
Patreon Bronze
Joined
Jul 17, 2017
Messages
76
Hi again!

I'm trying to make a desktop build for mac (Catalina 10.15.3) and using most recent cxs mac release (v2020-05-09)... only renders to the bottom-left quadrant of the screen? If I resize the window, the rendered section resizes with it & remains at 1/4 the size of the window (and the black background turns solid red).

It's only a problem with rendering; if I put a mouse-responsive thing at (0,0), I have to put my mouse in the top-left of the actual window to click it.

Bouncy aliens screenshot (v2020-05-09):
Screen Shot 2020-10-28 at 10.27.16 PM.png


For comparison, it was working with my previous cxs version (v2019-10-13):
Screen Shot 2020-10-28 at 10.29.16 PM.png


I don't know if this is another thing that's fixed in development builds 'cause I don't know how to compile them from the github source.
 
I've been told the same thing by Mac users from Mojave on I think when they tried to use my latest Mojo1/Ignition X commercial project
 
Mmh, we had that problem related to retina displays fix i thought. And then we have @Jimmy who doesn't report that? Mmmh.
@Phil does your machine have a retina display? Cause i have a normal screen and so can't check this myself.

Wick and pierrou, please post what hardware you use.
 
Wick and pierrou, please post what hardware you use.
I can ask about the test machines I don't know exactly. Mine is a late-2011 MacBook Pro with High Sierra and everything is working fine on that machine.
 
I encounter the same problem on my MacBook 2020 with retina. But I have to admit there is V2020-05-09 CX installed.
Maybe I can try it with the recent version of CX later today.


Edit: @Pierrou With mojo it worked fine here. Just the mojo2 examples rendered too small. But I will have a look. If you have a small test project showing the bug using mojo it would be great if uploaded it.
 
Last edited:
I'm using a MacBook Pro (16-inch, 2019) with a retina display (3072 x 1920).
 
I know this is a old bug, but I wasn't involved fixing it because I had no device. If someone could give a heads up here and post some links to the old discussions or resouces, I could get into this a bit faster.
 
I've never owned a Retina machine so that's why I havn't reported it. I think I was worried though that it could happen while looking through some source-code when I was trying to understand the opengl-y-flip of ReadPixels of Mojo2.

There's a related resolution-problem with Android but is fixable (I think) by simply adding the Android DPI-attribute of "Any" into the existing Android template.
 
Last edited:
I made some notes while going through everything and I wrote down some personal notes and links that I was 'bout to check up :


nt width = 1360*2; // screen width (this means to say how important it it to use native or half native resolution instead of e.g .640 x 480)
int height = 768*2; // screen height
GLFWwindow* window = glfwCreateWindow(width/2, height/2, "Hello OpenGL", NULL, NULL); // create window

(Touch/mouse resolution need to be 1 pixel and not 2x2 pixels)"

All in all, It' might probably be about framebuffer size vs window size so the solution might be this :

 
This could be the case, but for mojo this is already in the latest version on github.
In mojo2, I just couldn't find the spot yet.

C++:
#ifdef _glfw3_h_
    //glfwGetWindowSize( BBGlfwGame::GlfwGame()->GetGLFWwindow(),&width,&height );
    glfwGetFramebufferSize( BBGlfwGame::GlfwGame()->GetGLFWwindow(),&width, &height );
#else
    glfwGetWindowSize( &width,&height );
#endif

#if CFG_OPENGL_GLES20_ENABLED
    return 0;
#else

    glViewport( 0,0,width,height );
    //glViewport( 0,0,newWidth,newHeight );

Edit: My best guess so far is that mojo2 is using devicewidth when initializing the canvas in graphics.cxs. And devicewidth is just taking the windowsize and not the framebuffersize in glfw target file glfwgame.cpp
 
Last edited:
Edit: @Pierrou With mojo it worked fine here. Just the mojo2 examples rendered too small. But I will have a look. If you have a small test project showing the bug using mojo it would be great if uploaded it.
I haven't tried the fix on GitHub I'll try to compile using that version maybe it's OK?
 
AFAI There is no need for a compilation. Just replace the mojo folder in your current installation.
 
Yes, but it is not used in glViewPort() because of CFG_OPENGL_GLES20_ENABLED is True with mojo2, right?

What about changing GetDeviceWidth, to return the frameBufferWidth, because this is where the rendering takes place, right?
I just don't know if the real window width is used somewhere else.
 
@Phil7 I think you are correct. In mojo2 the value are not transfered. But that still doesn't explain why it seems to work for
@wick with the older version. If I am not blind, I saw no differences in that area in v20191013 and v20200509.

Gosh I love how these bugs pop up after quite some time.
 
Edit: My best guess so far is that mojo2 is using devicewidth when initializing the canvas in graphics.cxs. And devicewidth is just taking the windowsize and not the framebuffersize in glfw target file glfwgame.cpp


Does that mean that DesktopWidth will become identical withs DeviceWidth after the change, if it happens to be right?
 
DesktopWidth will become identical withs DeviceWidth
Without looking it up how it is calculated I would say the values are the same if the window is maximized or in Fullscreen. But it might be better if the relation (framebuffer to desktop) is just the same as with framebufferwidth and windowWidth, which is twice the value on my retina display.

Overall I see it like this: DeviceWidth and DeviceHeight should give you the practically useable resolution you have to deal with in your game and not some fraction of it. I can imagine to introduce a function called DeviceWindowWidth to get the Window size to create the same window size impression no matter if retina or not.
 
It seems like I have a fix for it and both mojo and mojo2 Apps are running, but it has some conceptual quirks to it:
First, I have to scale the MouseX and MouseY because they are returned as Window coords and not FrameBuffer coords.
Second, only Apps that are consistently written with different screensizes in mind run normally. Apps with absolute positions are rendered in the top left quarter of the Window. And Apps with a mixture of fixed pixel values and relative ones to deviceWidth are doing funny thing, i.e. they are messed up. One solution could be to have some kind of fallback, if an App is not made for different screensizes, making it scale to the whole window and ignoring the higher resolution.

Apps that are already made for multiple resolutions like for Android phones and tablets using something like autofit (virtual resolution and scaling automatically) should run fine.
 
Last edited:
Well, I was tinkering with this bug some time now and it looks like it is mostly fixed. I made a pull request on GitHub.
I guess there are some things I missed and that result in some unexpected behavior, but at least it could be a start for a discussion.

For the fallback I introduced a config constant #GLFW_HIGH_DPI_ENABLED that is 0 (false) by default and should enable apps with absolute pixel values to run on retina displays like on other displays. If you set it to 1 you can make use of the whole resolution with DeviceWidth()
 
Back
Top Bottom