[core] BeginScissorMode() fails on macOS

[Bambofy]

Issue description

Using BeginScissorMode() on OS X results in nothing being drawn on the screen in the scissored area.

Environment

OS X 10.15.5
Raylib 3.0

INFO: Initializing raylib 3.0
2020-06-17 21:14:38.934240+0100 Clank[49571:395045] Metal API Validation Enabled
2020-06-17 21:14:38.969738+0100 Clank[49571:395426] flock failed to lock maps file: errno = 35
2020-06-17 21:14:38.970661+0100 Clank[49571:395426] flock failed to lock maps file: errno = 35
INFO: DISPLAY: Device initialized successfully
INFO: > Display size: 1680 x 1050
INFO: > Render size: 800 x 600
INFO: > Screen size: 800 x 600
INFO: > Viewport offsets: 0, 0
INFO: GL: OpenGL device information:
INFO: > Vendor: Intel Inc.
INFO: > Renderer: Intel(R) UHD Graphics 617
INFO: > Version: 4.1 INTEL-14.6.18
INFO: > GLSL: 4.10
INFO: GL: Supported extensions count: 45
INFO: GL: DXT compressed textures supported
INFO: GL: Anisotropic textures filtering supported (max: 16X)
INFO: GL: Debug Marker supported
INFO: TEXTURE: [ID 1] Texture created successfully (1x1 - 1 mipmaps)
INFO: TEXTURE: [ID 1] Default texture loaded successfully
INFO: SHADER: [ID 1] Compiled successfully
INFO: SHADER: [ID 2] Compiled successfully
INFO: SHADER: [ID 3] Program loaded successfully
INFO: SHADER: [ID 3] Default shader loaded successfully
INFO: RLGL: Internal vertex buffers initialized successfully in RAM (CPU)
INFO: RLGL: Internal vertex buffers uploaded successfully to VRAM (GPU)
INFO: RLGL: Default state initialized successfully
INFO: TEXTURE: [ID 2] Texture created successfully (128x128 - 1 mipmaps)
INFO: FONT: Default font loaded successfully
INFO: TIMER: Target time per frame: 33.333 milliseconds

Issue Screenshot

I'm drawing a 200x200 black square at 0,0. These images are with and without scissor at (0,0,800,600)

Without scissor:

With scissor:

Code Example

It can be reproduced with a blank raylib project and these 3 lines:

BeginScissorMode(0,0,800,600);
DrawRectangle(0, 0, 200, 200, BLACK);
EndScissorMode();

[raysan5]

@Bambofy Oh, this is weird... I tried on Windows and it works ok.

Maybe it could be related to HighDPI display, there are some related issues on macOS... are you using a retina/highDPI display?

[Bambofy]

@Bambofy Oh, this is weird... I tried on Windows and it works ok.

Maybe it could be related to HighDPI display, there are some related issues on macOS... are you using a retina/highDPI display?

yep it is a HighDPI display

[raysan5]

I'm closing this issue, already #1086 open regarding HighDPI on macOS... actually it requires a full review...

[tomc1998]

I'm getting similar problems - i don't have access to a highdpi display, but users of my code with highdpi displays are reporting similar issues.

Could you clarify what you think the problem with highdpi displays is here? I can't just multiply by the DPI - even without multiplying by the DPI, you'd still expect a 200x200 rectangle to be rendered.

Are the scissor screen coords different on osx maybe?

[tomc1998]

Hmm, after a long bit of trial and error, i have this 'fix' - i have a feeling it won't work on all systems though

proc raylibScissor*(x: int, y: int, w: int, h: int) =
  ## Do a raylib scissor, but scissor differently on osx, since the raylib
  ## scissor coordinate system is different on osx (???)

  let dpi = GetWindowScaleDPI()
  when defined(macosx):
    BeginScissorMode(dpi.x.int * x, dpi.y.int * y - int(dpi.y *
        screenH.float/2), w * dpi.x.int, h * dpi.y.int)
  else:
    BeginScissorMode(dpi.x.int * x, dpi.y.int * y, w * dpi.x.int, h * dpi.y.int)

This is in nim, but you get the idea

Looks like the OSX scissor coordinate system starts from (0, screen_height/2) (although this isn't just a bottom left coord system, since positive y = further down). Scissor coords also need to be DPI scaled...

If anyone with a macbook could dig deeper i'd be grateful ;_;

[raysan5]

@tomc1998 probably related: #1987

[tomc1998]

@raysan5 No it's not related to window resizing, the window is kept at the same size

But i think i figured out the issue after sleeping on it:

The internal scissoring method raylib uses has bottom-left coordinates (unsure if you use glScissor, but that uses bottom-left coords). Raylib transforms the coordinates you pass into it by negating + adding the screen height - but it doesn't factor in DPI at this stage.

This is why it seemed like the OSX coordinate system started 'half way up' the screen, because I was viewing this error on a screen with DPI 2.

It's also why the x coordinate wasn't translated, because you don't need to do any transforms on the X coord to make it work with glScissor!

Unfortunately i don't currently have the freedom to use a non-prebuilt raylib, so i'll just be patching this in my application's code rather than submitting a patch :p

EDIT:

When do raylib prebuilts on homebrew get updated?

[ArnaudValensi]

It should be fixed with this pending PR #1987

[tomc1998]

ok! seems strange that this is related to fbo size, how does raylib do scissoring? I did think that glscissor would be quite slow for many scissors ¯_(ツ)_/¯

Also i'm not resizing the window at all, unless raylib initializes the window with a default size and then resizes when you startup