Harri I still want to dig for lower level solutions to this. Mainly it seems that a lot of applications on the internet also just don't care, including some graphics abstraction API's. I am going to dig to see what ANGLE does about this, and see if I can figure out whether Studio has this issue if the user draws the surface themselves.
The first thing I'd like to roll out, is messing with the projection or matrices, I think me and you both hate that option, it's way too much math involved and it has too many caveats to work in all cases. I am open to the shader solution, if we provide a way to disable it. Another thing we could do is just flip the texture data the first time surface_get_texture is called on the surface after it was rendered to with surface_set_target, though I don't know what the cost of this is compared to doing it in the shader after upload, obviously more efficient for drawing the surface without changing it multiple times in a row which is the same concept applied to vertex buffers, a pixel buffer could be used to do this. This is actually similar to the correct way OpenGL would handle it, there should have been an extension to change the pixel upload origin since framebuffers were introduced. Take the following Nvidia extension which lets you specify this origin for blitting to the main window.https://www.opengl.org/registry/specs/ARB/clip_control.txt
When rendering Direct3D content into a framebuffer object in OpenGL, there
is one complication -- how to get a correct image *out* of the related
textures. Direct3D applications would expect a texture coordinate of
(0,0) to correspond to the upper-left corner of a rendered image, while
OpenGL FBO conventions would map (0,0) to the lower-left corner of the
rendered image. For applications wishing to use Direct3D content with
unmodified texture coordinates, the command
configures the OpenGL to invert geometry vertically inside the viewport.
Content at the top of the viewport for Direct3D will be rendered to the
bottom of the viewport from the point of view of OpenGL, but will have a
<t> texture coordinate of zero in both cases. When operating in this
mode, applications need not invert the programmed viewport rectangle as
recommended for windowed rendering above.
We would just call that function to flip the viewport when surface_set_target is called and then call the same function to undo that in surface_reset_target, it's only a two line fix. It looks like it's OpenGL 4.5 though.https://www.opengl.org/sdk/docs/man/html/glClipControl.xhtml
Sadly, I don't even have this extension.
ANGLE does it in the shader, so this is also how it is done in GM: Studio. Search PDF for "Direct3D inverts the"http://www.seas.upenn.edu/~pcozzi/OpenGLInsights/OpenGLInsights-ANGLE.pdf
Here's the specific commit where they fixed FBO flipping in ANGLEhttps://code.google.com/p/angleproject/source/detail?r=b31f532d7137039e73d5bbdcc0b54a9883718c58&path=/src/libGLESv2/mathutil.h
For the solution we find we should (if we can) offer a way to disable it, in which case all of our surface drawing functions draw with upside down coordinates and the user has to do the same when using the surface as a texture. But let me keep doing some additional research.