OSX Axmol / Cocos differences when going full screen

[IcemarkUK]

My game runs in fullscreen, or three window sizes of the same aspect ratio of the desktop. The windows sizes are calculated based on a % of the desktop size. I have the ability to toggles these in game. I always run the game in ResolutionPolicy::EXACT_FIT

My iMac screen size is 5120 × 2880 but is running at a resolution of 2880x1620

If I start the app and go in to full screen with GLViewImpl::createWithFullScreen and then call Director::getInstance()->getGLView()->getFrameSize() on Cocos I get 2880x1620 and in Axmol I get 2880x1620

If I then call glView->setWindowed using my large window size of 2160x1215 and then call
Director::getInstance()->getGLView()->getFrameSize() on Cocos I get 2880x1620 and in Axmol I get 4320x2430

If I start the app and go in to windows with GLViewImpl::createWithRect using my large window size of 2160x1215
then call Director::getInstance()->getGLView()->getFrameSize() on Cocos I get 2880x1620 and in Axmol I get 2880x1620

If I then call glView->setFullscreen() and Director::getInstance()->getGLView()->getFrameSize() on Cocos I get 2880x1620 and in Axmol I get 5120 × 2880

It's clear than Axmol's change methods are creating a x2 view and then adjusting accordingly, which cocos wasn't. If this is correct behaviour now, how do I know this is happened. Where do I get that scale from.

I use exactly the same code of Windows but haven't yet checked if the behaviour is the same or different as I don't run windows.

[rh101]

I use exactly the same code of Windows but haven't yet checked if the behaviour is the same or different as I don't run windows.

I tried to build the Windows version, and ran into a few issues. I've posted them up in the PR at your repo: ChilliHugger/The-Lords-Of-Midnight#229 (comment)

[IcemarkUK]

Hopefully all there now.

[IcemarkUK]

I suspect it's to do with the retina stuff... and when it's enabled and or the frame size is recalculated. If I debug
GLViewImpl::updateFrameSize() the only thing that obviously changes is _isInRetinaMonitor this is not true at startup (after create functions) but is true after calling (set functions) to swap between fullscreen/windowed. But other than that, nothing obvious so far.

[IcemarkUK]

I've tried following the code through, and the only thing I can see is that at some point the internal framebuffer size is increased.

If I start the app full screen GLViewImpl::createWithFullScreen when my desktop resolution is 2880x1620 then director->getGLView()->getFrameSize() all ways returns the size 2880x1620

As soon as I drop from Fullscreen to windowed during runtime, then it changes.

auto size1 = director->getGLView()->getFrameSize(); 
// size1 == 2880,1620
    
glView->setWindowed(2160, 1215);
    
auto size2 = director->getGLView()->getFrameSize();
// size2 == 4320,2430

If I start the app windowed GLViewImpl::createWithRect when my desktop resolution is 2880x1620 and my window is 2160, 1215 then director->getGLView()->getFrameSize() all ways returns the size 2160, 1215

As soon as I increase from Window to Fullscreen during runtime, then it changes.

auto size1 = director->getGLView()->getFrameSize(); 
// size1 == 2160, 1215

glView->setFullscreen();

auto size2 = director->getGLView()->getFrameSize(); 
// size2 == 5120, 2880

So it seems to me that both setWindowed and setFullscreen do not take in to account the original desktop size compared to actual screen resolution unlike to the way that createWithFullScreen and createWithRect appear to.

I thought I might be able to at least fudge the Window to Fullscreen switch by setting the actual Desktop Size in the setFullScreen command. But it made no difference.

auto size1 = director->getGLView()->getFrameSize(); 
// size1 == 2160, 1215

glView->setFullscreen(2880,1620,-1);

auto size2 = director->getGLView()->getFrameSize(); 
// size2 == 5120, 2880

[IcemarkUK]

@rh101 Were you thinking that the refresh rate fix would also fix this?

This is my last blocker for migration (osx). I'm about to start checking all the other builds now.

I'll try and spend some time later this week debugging both axmol and cocos and see if I can find any obvious differences caused during setFullscreen being called.

[IcemarkUK]

Yes, I pulled in latest dev and everything else is fixed, but it didn't change this.

Steps - using my repos. (I will see if I can reproduce on a smaller test maybe tomorrow)

1. Launch
2. If the app starts full screen -

• Select options from the main menu
• Select Screen Mode
• toggle through to window large
• select main menu
• say yes to change resolution

3. If starts in a window -

• Select options from the main menu
• Select Screen Mode
• toggle through to full screen
• select main menu
• say yes to change resolution

What you will see is that the content of the window now doesn't fit properly. This is because the frame buffer is now twice the resolution it was before the change.

For comparison. After changing modes (and it's now all messy BTW: Press ESC then G to quit if you can't use the mouse) launch the app again which will start in the intended mode, but this time the graphics will be correct. This is because the frame buffer is now at the correct size.

[rh101]

OK, those steps are helpful. I'll take a look at it over the next day or so on the Mac.

[rh101]

I've just quickly tested this with a Windows build, and I can't reproduce the issue. Besides the difference in the platform, the native resolution of the monitor is 2560x1440, as I don't have a 5120x2880 to test on. Would the monitor resolution affect my ability to reproduce it?

[IcemarkUK]

I suspect it's Mac thing and with the way that the Retina display works. Essentially if I stick a break point on the line
glView->setFullscreen(2880,1620,-1); And stop over it, then the whole screen actually changes to 5120x2880 resolution. I think for a moment the buffers are be calculated as if it actual is 5120 but then don't drop back to 2880 for the actual resolution.

[rh101]

Starting the app on a 2560x1440 screen connected to a Mac Mini M1, full screen mode, then switching it to window mode "Large", the resolution changed to 1920x1080. Everything appeared normal.

Starting it in windowed mode, then switching to full screen, resulted in a resolution of 2560x1440, which is correct. Everything appeared normal.

[rh101]

@IcemarkUK When going from full-screen mode to windowed-mode, different code paths are taken depending on certain conditions. This may be the reason why things aren't working correctly:

Taking a look at GLViewImpl::setWindowed:

void GLViewImpl::setWindowed(int width, int height)
{
    if (!this->isFullscreen())
    {
        if (glfwGetWindowAttrib(_mainWindow, GLFW_MAXIMIZED))
            glfwRestoreWindow(_mainWindow);
        this->setFrameSize((float)width, (float)height);
    }
    else
    {
        const GLFWvidmode* videoMode = glfwGetVideoMode(_monitor);
        int xpos = 0, ypos = 0;
        glfwGetMonitorPos(_monitor, &xpos, &ypos);
        xpos += (int)((videoMode->width - width) * 0.5f);
        ypos += (int)((videoMode->height - height) * 0.5f);
        _monitor = nullptr;
        glfwSetWindowMonitor(_mainWindow, nullptr, xpos, ypos, width, height, GLFW_DONT_CARE);
#if (AX_TARGET_PLATFORM == AX_PLATFORM_MAC)
        // on mac window will sometimes lose title when windowed
        glfwSetWindowTitle(_mainWindow, _viewName.c_str());
#endif

        updateWindowSize();
    }
}

If it is not already in full screen mode, then all it does is set the frame size. No problem there. If it's already in full screen mode, then the end result is updateWindowSize(), which does the following:

void GLViewImpl::updateWindowSize()
{
    int w = 0, h = 0;
    glfwGetFramebufferSize(_mainWindow, &w, &h);
    int frameWidth  = w / _frameZoomFactor;
    int frameHeight = h / _frameZoomFactor;
    setFrameSize(frameWidth, frameHeight);
    updateDesignResolutionSize();
    Director::getInstance()->getEventDispatcher()->dispatchCustomEvent(GLViewImpl::EVENT_WINDOW_RESIZED, nullptr);
}

This completely ignores the window size that you pass in, and instead uses some other calculation to set the frame size. At a guess, this is not the expected functionality. It really should be setting the frame size to what is passed in earlier. There is no method named updateWindowSize in Cocos2d-x, and that functionality in it didn't exist either, so it's a new addition, and perhaps the current implementation is the source of the problems you are experiencing.

Just out of curiosity, comment out the calls to updateWindowSize, and see what happens. If it works, then at least that narrows down the issue to what needs to be fixed.

[IcemarkUK]

It seems to be in here that goes wrong...

axmol/core/platform/GLViewImpl.cpp

Lines 1245 to 1278 in bee2d62

	void GLViewImpl::onGLFWWindowSizeCallback(GLFWwindow* /*window*/, int w, int h)
	{
	if (w && h && _resolutionPolicy != ResolutionPolicy::UNKNOWN)
	{
	/* Invoke `GLView::setFrameSize` to sync screen size immediately,
	this->setFrameSize will invoke `glfwSetWindowSize` which is unnecessary.
	*/
	GLView::setFrameSize(w, h);
	/*
	x-studio spec, fix view size incorrect when window size changed.
	The original code behavior:
	1. first time enter full screen: w,h=1920,1080
	2. second or later enter full screen: will trigger 2 times WindowSizeCallback
	1). w,h=976,679
	2). w,h=1024,768
	@remark:
	1. we should use glfwSetWindowMonitor to control the window size in full screen mode
	@see also: updateWindowSize (call after enter/exit full screen mode)
	*/
	updateDesignResolutionSize();
	#if defined(AX_USE_METAL)
	// update metal attachment texture size.
	int fbWidth, fbHeight;
	glfwGetFramebufferSize(_mainWindow, &fbWidth, &fbHeight);
	backend::UtilsMTL::resizeDefaultAttachmentTexture(fbWidth, fbHeight);
	#endif
	Size size(w, h);
	Director::getInstance()->getEventDispatcher()->dispatchCustomEvent(GLViewImpl::EVENT_WINDOW_RESIZED, &size);
	}
	}

The call to glfwGetFramebufferSize returns the FULL desktop size and not the current resolution.

axmol/core/platform/GLViewImpl.cpp

Lines 1268 to 1273 in bee2d62

	#if defined(AX_USE_METAL)
	// update metal attachment texture size.
	int fbWidth, fbHeight;
	glfwGetFramebufferSize(_mainWindow, &fbWidth, &fbHeight);
	backend::UtilsMTL::resizeDefaultAttachmentTexture(fbWidth, fbHeight);
	#endif

[rh101]

That makes sense.

Please log this as a bug, and add link to this discussion too. I'm not entirely sure what the best fix would be, since I'm not too familiar with that section of code, but hopefully you and @halx99 can come up with a solution to this.

[halx99]

checked: the glfwGetFramebufferSize always return double of window resolution size, and the onGLFWWindowSizeCallback will invoked 2-times when go to full screen mode

• first time: trigger by setFullscreen --> glfwSetWindowMonitor, it's correct
• second time: trigger by setFullscreen --> updateWindowSize, it's incorrect, try to set window size by framebuffersize, which is double of window size in macos retina display

[halx99]

please track this PR: #1692

[IcemarkUK]

Thank you! That's done the job.