Fix: MacOS fullscreen brl.glmax2d issues (setup and inverted mouse-y)

[GWRon]

Old code:

Seems the code is no longer supported and needs to be done a bit different now.

also in fullscreen the mouse was inverted on the y-axis. This is becaus on macOS "displays" are bottom-left oriented, "views" are "top, left". So in the case of capturing the complete display we need to flip the mouse axis too

[GWRon]

I was only able to test these things on my old mac mini running Monterey (old code failed already with Catalina which run on the machine (early 2009...) till yesterday).

Would be nice if others could reply to here if it works.

Regarding the window-setup-code changes: I experienced that sometimes the window did not "respond" because after creation something else seems to have gotten the "focus". This especially is the case with "debug builds" when running things from MaxIDE - this is because it then print debug messages to their output pane (I guess) and this somehow lead to the focus loss (so randomly an "alt-tab" brought back the ability to exit a simple graphics app).

Btw: Simple test:

SuperStrict

Framework Brl.StandardIO
Import Brl.GLMax2D

Graphics 800, 600, 32


Repeat
	Cls
	DrawRect(MouseX()-5, MouseY()-5, 10,10)	
	
	Flip
Until KeyHit(KEY_ESCAPE) Or AppTerminate()

[GWRon]

Midimaster reported, that on his 2018 Mac Mini the mouse cursor is offset by "100px" ... I assume this is because of some menu or the dock.

I extended my code to auto-detect wether to use "frame" or "visibleFrame" ...

static int mouseViewPos( NSView *view,int *x,int *y ){
    // if now view is defined and the complete display is captured
    // then we need to invert y as in macOS the origin is "bottom, left"
    // for displays, but "top, left" for NSView elements.
    if( displayCaptured || !view ){
        static int useVisibleFrame = -1;  // -1 = not detected yet, 0 = only frame, 1 = visibleframe
    
        NSPoint point = [NSEvent mouseLocation];
        NSScreen *screen = [NSScreen mainScreen];

        CGFloat screenHeight = screen.frame.size.height;
        CGFloat visibleHeight = screen.visibleFrame.size.height;
        CGFloat offset = screenHeight - visibleHeight;  // height of menu or dock

        *x = point.x;

        // detect on first run
        if (useVisibleFrame == -1) {
            int y1 = screenHeight - point.y;
            int y2 = visibleHeight - point.y;

            // assume it is the menu/dock if there is a difference > 50px
            if (abs(y1 - y2) > 50) {
                useVisibleFrame = 1;
            } else {
                useVisibleFrame = 0;
            }
            NSLog(@"Screen Frame: %.2f x %.2f", screen.frame.size.width, screen.frame.size.height);
            NSLog(@"Visible Frame: %.2f x %.2f", screen.visibleFrame.size.width, screen.visibleFrame.size.height);
            NSLog(@"Auto-Detected useVisibleFrame = %d", useVisibleFrame);
        }

        if (useVisibleFrame) {
            *y = visibleHeight - point.y;
        } else {
            *y = screenHeight - point.y;
        }
        return 1;
    } else {

please report back which one is choosen on your computer, for me it is "useVisibleFrame = 0" and visible frame is 800x575 while screen frame is 800x600.

Midimaster also reported a kind of "title bar" being visible now.

And important: He was using BlitzMax NG 1.38 (so the "old stable") and had these inverted mouse but a working fullscreen. When I asked him to update to the latest weekly build it started to fail similar to mine: no rectangle drawn at all, not closeable with Escape key ...

There were not many changes to glgraphics and systemdefault for mac since then ... but this one here - the hacky fix...
c491f49

This one also introduced that parameter which I repair in this PR.

@MidimasterSoft
Feel free to add your remarks here too

[MidimasterSoft]

...Midimaster reported, that on his 2018 Mac Mini the mouse cursor is offset by "100px" ...

I cancel this report, because I added GWRon's improvement to an old BlitzMax NG 1.38. Now I updated to BlitzMax (Mac...X64) 1.46 and the offset has gone. But now I have more problems with FULLSCREEN than before.

Using BlitzMax 1.38 (official download from BlitzMax.Org) we had a perfect FULLSCREEN and only the returned value of MouseY() was in inversed. We also had no problems with exiting a FULLSCREEN app.

With the current weekly build 1.48 we see no Rectangle (DrawRect...) and we cannot leave the app with ESC. Only a (mac taskmanager) keycombination MAC+ALT+TAB we are able to kill the app. After this we need also to restart BlitzMax-IDE.

With GWRon's update the Rectangle appears at the expected position and MouseY() works perfect. But now I can see something like a "disabled" menu bar in the middle of the screen. It looks like a 800x600 "fullscreen" is centered in a 1920x1080 display. Leaving the app with ESC works.
My computer: MAC MINI (2018) with Monterey

[woollybah]

Is there a reason not to use SDL max2d renderer?

[GWRon]

Is there a reason not to use SDL max2d renderer?

Most prominent reason is: beginners cannot use it "simple enough" for now.
If you want to use the SDL-part you need to use the framework command - and this will break a lot of code these people will use - as they did not have to import things in the past but "now they do have to find out what they use".

So yes, I would enourage to use the max2d renderers of SDL ... but (as I have DMed you via discord) this for now at least requires some meta module we can use as "framework" (framework frameworks.sdlapp).
OR we deprecate the brl.stuff (graphics backend, timer and system stuff) and move it into a new "legacy" module, bring in SDL as default ... yeah.

[GWRon]

With GWRon's update the Rectangle appears at the expected position and MouseY() works perfect. But now I can see something like a "disabled" menu bar in the middle of the screen. It looks like a 800x600 "fullscreen" is centered in a 1920x1080 display.

This btw is not happening on my Monterey using mac mini - so I guess "behind the scenes" there would be even more adjustments required (to find the best resolution to use ... the commands we use are deprecated since 10.6 ...)

@MidimasterSoft
The only "relevant" change for you between 1.38 and 1.4x are there: c491f49
(and the borderless-mode addition in 96c7205)

You can have a look if the original weekly build code (so not using my patch here - except maybe the system-stuff for mouse inversion repair) and undo the changes (done in the two commits I just linked) to see if you get back your "flawlessly working fullscreen".
(I am sure Brucey added them for a reason - so someoneelse's fullscreen was not working properly before the changes :D).

Newer macOS want to animate the fullscreen transition ... and I guess this is what creates the trouble here (I even fixed the application to finish transition instantly etc) ... any changes I tried felt kinda "dirty/hacky/not-properly-done".

[woollybah]

Formatting. New code appears to use a mix of spaces and tabs. Should probably be tabs, like the existing code here.