Fixed Mac Desktop builds rendering at 1/4 of window

wick

Member
3rd Party Module Dev
Tutorial Author
Patreon Bronze
Joined
Jul 17, 2017
Messages
71
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.
 

Pierrou

Active member
Joined
Jul 6, 2017
Messages
186
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
 

MikeHart

Administrator
Joined
Jun 19, 2017
Messages
2,845
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.
 

Pierrou

Active member
Joined
Jul 6, 2017
Messages
186
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.
 

Phil7

Administrator
CX Code Contributor
3rd Party Tool Dev
Joined
Jun 26, 2017
Messages
550
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:

wick

Member
3rd Party Module Dev
Tutorial Author
Patreon Bronze
Joined
Jul 17, 2017
Messages
71
I'm using a MacBook Pro (16-inch, 2019) with a retina display (3072 x 1920).
 

Phil7

Administrator
CX Code Contributor
3rd Party Tool Dev
Joined
Jun 26, 2017
Messages
550
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.
 

Jimmy

Active member
3rd Party Module Dev
Tutorial Author
Joined
Jan 2, 2020
Messages
578
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:

Jimmy

Active member
3rd Party Module Dev
Tutorial Author
Joined
Jan 2, 2020
Messages
578
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 :

 

Phil7

Administrator
CX Code Contributor
3rd Party Tool Dev
Joined
Jun 26, 2017
Messages
550
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:

Pierrou

Active member
Joined
Jul 6, 2017
Messages
186
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?
 

Phil7

Administrator
CX Code Contributor
3rd Party Tool Dev
Joined
Jun 26, 2017
Messages
550
AFAI There is no need for a compilation. Just replace the mojo folder in your current installation.
 

Phil7

Administrator
CX Code Contributor
3rd Party Tool Dev
Joined
Jun 26, 2017
Messages
550
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.
 

MikeHart

Administrator
Joined
Jun 19, 2017
Messages
2,845
@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.
 

Jimmy

Active member
3rd Party Module Dev
Tutorial Author
Joined
Jan 2, 2020
Messages
578
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?
 

Phil7

Administrator
CX Code Contributor
3rd Party Tool Dev
Joined
Jun 26, 2017
Messages
550
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.
 

Phil7

Administrator
CX Code Contributor
3rd Party Tool Dev
Joined
Jun 26, 2017
Messages
550
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:

Phil7

Administrator
CX Code Contributor
3rd Party Tool Dev
Joined
Jun 26, 2017
Messages
550
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()
 
Top Bottom