ENIGMA Development Environment

I have tested and the setting seems to be a suitable fix pro tempore. I have sent a new pull request. This is also a nice setting even if the user just wants to compile projects faster because they can skip this phase entirely. Therefore I agree with Harri that this is a smart way of teaching users that by coding properly they can write faster and more efficient software.
https://github.com/enigma-dev/enigma-dev/pull/919

I am like 99% certain without testing that the MinGW errors should show in LGM's console, I am like, almost certain. Though our syntax checking itself would not catch the error. To reiterate those may not be very user friendly but again this setting would be for advanced users, like Harri, who know C++.

We will get there egofree, so many issues, so little time, we need to fix some more LGM stuff and get the icons vectorized first.

Another quick update here as well, I have fixed the syntax checking output, room/instance creation will no longer silently fail it will show the output and line numbers. Script syntax checking will also properly show line numbers now as well. Update as usual.
https://github.com/enigma-dev/enigma-dev/pull/913

What? That isn't the case at all, all the matrix_functions I prototyped are showing in the function list.

matrix_build : gs_scalar *matrix_build(gs_scalar x, gs_scalar y, gs_scalar z, gs_scalar xrotation, gs_scalar yrotation, gs_scalar zrotation, gs_scalar xscale, gs_scalar yscale, gs_scalar zscale);
matrix_get : gs_scalar *matrix_get(int type);
matrix_multiply : gs_scalar *matrix_multiply(gs_scalar *matrix1, gs_scalar *matrix2);
matrix_set : void matrix_set(int type, gs_scalar *matrix);


I still need to cast the var array as floats, which I don't know how effective will be. Right now I just assume they are floats and do a memcpy:

That sounds fine to me for now, having it work is better than nothing at all. Josh can weigh in if you like.

Well I've got some good news, I decided to try porting GMOgre again and was met with relative success. You can download the original examples from the GMC for now, I have not made a special ENIGMA release yet.
http://gmc.yoyogames.com/index.php?showtopic=455439

To start off I had to do similar fixes that were required for Ultimate3D, the window flags fix from a while back that has been added in the latest Portable ZIP is also needed.
http://enigma-dev.org/forums/index.php?topic=1248.0

Here are the problems:
1) Global variable exists function used to check if OGRE is initialized this, I just replaced this with global.ogre_initialized == true
2) Local variable exists functions used to initialize z values for objects, replaced this with a local flag and enabled "Treat unitialized variables as 0" in Game Settings->Errors
3) ENIGMA has not implemented temp_directory for the settings.ini to be stored, so I replaced it with working_directory, which is where the dll also must be kept
https://github.com/enigma-dev/enigma-dev/issues/141
4) The GMOgre project files are totally corrupt, I had to import into Studio and then use LGM to convert the GMX back into GMK. The problem is the resources have their names but the part of the GMK storing the tree has them with the wrong names, just garbage. The GMK's also have problems in GM8.1
5) There's a conflict with the script named CreateFont, so I had to rename it to CreateFontA
https://github.com/enigma-dev/enigma-dev/issues/915
6) There's a bug with default script arguments in obj_skybox create event. It calls EnableSkybox passing only argument1 skipping argument0 and 2-3. This is in fact a mistake in GMOgre, not an issue with ENIGMA, I tested GM8.1 and it does not allow skipping arguments, and neither does ISO C.
https://github.com/enigma-dev/enigma-dev/issues/489
7) The OGRE log reports several shaders not being compiled, if we add the following code:
AddResourceLocation("./media/materials/programs");
To the create event of obj_engine then different errors occur. I created these logs after changing the renderer to GL from DX9
Before: http://pastebin.com/AZvxbbfY
After: http://pastebin.com/uEuk7YEf
8) We have no way of supporting GMAPI, this is why the RenderFrame script crashes, it is trying to call GML functions using GMAPI which Studio no longer supports either.
http://gmc.yoyogames.com/index.php?showtopic=429267

After fixing those problems I managed to get the GMOgre FPS example built but it crashes right after starting and throws debug messages about undefined vars.


This is the backtrace from GDB, if anybody has any ideas let me know.
(gdb) bt
#0  0x100d9f76 in ?? ()
#1  0x008c04c3 in ffi_call (cif=<optimized out>, fn=<optimized out>,
    rvalue=<optimized out>, avalue=<optimized out>)
    at /root/enigger_libs/mingw-w64-libffi/src/libffi-3.0.13/src/x86/ffi.c:405
#2  0x007b1a08 in enigma_user::external_call (id=497, a1=..., a2=..., a3=...,
    a4=..., a5=..., a6=..., a7=..., a8=..., a9=..., a10=..., a11=...,
    a12=..., a13=..., a14=..., a15=..., a16=...)
    at Platforms/Win32/WINDOWSexternals.cpp:176
#3  0x005f0a9e in _SCR_RenderFrame (argument0=..., argument1=...,
    argument2=..., argument3=..., argument4=..., argument5=...,
    argument6=..., argument7=..., argument8=..., argument9=...,
    argument10=..., argument11=..., argument12=..., argument13=...,
    argument14=..., argument15=...)
    at C:/ProgramData/ENIGMA/Preprocessor_Environment_Editable/IDE_EDIT_objectfu
nctionality.h:6326
#4  0x0077c724 in enigma::OBJ_obj_engine::myevent_endstep (this=0x3c26140)
    at C:/ProgramData/ENIGMA/Preprocessor_Environment_Editable/IDE_EDIT_objectfu
nctionality.h:13326
#5  0x00424ae6 in enigma::ENIGMA_events ()
    at C:/ProgramData/ENIGMA/Preprocessor_Environment_Editable/IDE_EDIT_events.h
:118
#6  0x007a89a1 in WinMain@16 (hInstance=0x400000, hPrevInstance=0x0,
    lpCmdLine=0x238479f "", iCmdShow=10)
    at Platforms/Win32/WINDOWSmain.cpp:356
#7  0x00b2871d in main ()


Run in debug mode, then close it and run it with gdb.

gdb path/to/game.exe

And paste a backtrace from gdb when it segfaults.

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

        glClipControl(GL_UPPER_LEFT, GL_ZERO_TO_ONE);

    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.

GL_ARB_clip_control:                                           MISSING
--------------------
  glClipControl:                                               MISSING

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 ANGLE
https://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.