Offer a co-ordinate normalisation function (invariant to core's display settings)

[YoshiRulz]

client.bufferheight() is a constant 384 regardless of screen gap, yet trying to draw on the bottom screen (EmuCore surface) with y values in 192..<384 draws that distance below the origin, not taking the screen gap into account.

If you were wondering why the bundled Lua script draws on the Client surface, this is why. If you were wondering why it reads the current rotation/gap settings only to force a preset I have no idea.

I bet this affects Citra too. If only we'd thought to write a robust multi-screen API instead of hacking stuff into the existing one. (This is where I'd say "I told you so," if I could find a link to that.)

[CasualPokePlayer]

NDS screen gap is implemented purely on client side; the video buffer is not altered here. This wouldn't affect Citra as it does its screen madness internally so you see it in buffer width/height.

Screen gap not being "accounted" for is less a fundamental issue here but more likely a screen layer just has some function done incorrectly or such; you don't see screen multiplier layers incorrectly misplacing lua emu surface coords so there's no reason why screen gap shouldn't work if it's implemented properly.

[CasualPokePlayer]

If you were wondering why the bundled Lua script draws on the Client surface, this is why.

It doesn't, it uses the emucore (default) surface

[CasualPokePlayer]

Calling this fixed with the recent changes to NDS rendering.

[YoshiRulz]

Drawings on the EmuCore surface should be agnostic to the screen gap. I don't know if other cores' non-sync settings affect the buffer size, but I believe this one shouldn't.

[CasualPokePlayer]

The video buffer has the screen gap now, and you can see this with the buffer width/height changing. This is due to the changes just being all screen control stuff being done core side (like Citra) using melonDS upstream's helper code. The most screen control does client side is adjust mouse inputs.

[YoshiRulz]

Yes, that's what I'm complaining about. While it wasn't working before unless the screen gap was 0, I still consider this a regression. Lua scripts should not have to draw at buffer_height - 100 or whatever—the choice of using the EmuCore surface signifies they want to use the emulated system's native co-ordinates, or something equivalent, and not have to worry about scaling, padding, rotation et cetera.

[CasualPokePlayer]

GL upscaling, layout, rotation, screen gap, screen invert, and screen gap will affect the emu core surface as the video buffer is directly affected. This is also the same as Citra. These cores have upstream helper code to handle screen controls, which have to be invoked in some capacity if OpenGL renderers are being used (and it's not hard to apply it to the software renderer in melon's case). So the screen control is handled core side, and that's what the frontend receives as is. If it's possible perhaps these points could just be transformed within the screen control class, somehow (not sure if that's fundamentally possible).

[YoshiRulz]

I still don't like this, though I'll concede that it has precedent in the "overscan" settings for the likes of the NES and Master System. Hence I'm re-opening this as a feature request.