Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Goombert

Programming Help / Re: Matrix Math extension?
« on: December 29, 2014, 08:12:46 AM »
Because array names are just const pointers essentially they can be passed to functions in ENIGMA. You just can't get the size, but that doesn't matter because they are a prefixed size. Second I think the functions should actually take a var array because it can be double or float like drawing functions, and var arrays can tell us their size. I don't know about returning arrays, but I have already outlined the functions. I encourage you to at least take a crack at it Harri and let us know of any parsing bugs and I may be able to help fix them.

Third Party / Porting GMOgre
« on: December 29, 2014, 06:14:05 AM »
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.

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.

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
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
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.
7) The OGRE log reports several shaders not being compiled, if we add the following code:
Code: (GML) [Select]
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
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.

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.
Code: [Select]
(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
#4  0x0077c724 in enigma::OBJ_obj_engine::myevent_endstep (this=0x3c26140)
    at C:/ProgramData/ENIGMA/Preprocessor_Environment_Editable/IDE_EDIT_objectfu
#5  0x00424ae6 in enigma::ENIGMA_events ()
    at C:/ProgramData/ENIGMA/Preprocessor_Environment_Editable/IDE_EDIT_events.h
#6  0x007a89a1 in WinMain@16 (hInstance=0x400000, hPrevInstance=0x0,
    lpCmdLine=0x238479f "", iCmdShow=10)
    at Platforms/Win32/WINDOWSmain.cpp:356
#7  0x00b2871d in main ()

Issues Help Desk / Re: Compiling for windows in linux problem
« on: December 29, 2014, 06:06:38 AM »
No no no, first you have to build it in debug mode in ENIGMA so it has debugging symbols, otherwise I have no idea what the function addresses point to, you also still need "bt" for a full backtrace.

Issues Help Desk / Re: Compiling for windows in linux problem
« on: December 29, 2014, 04:42:47 AM »
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.

Issues Help Desk / Re: Compiling for windows in linux problem
« on: December 29, 2014, 03:25:23 AM »
Hello gra, can you please paste us enigma-dev/output_log.txt at or and give us the link?

Works in Progress / Re: [OGL3] Shader Test
« on: December 29, 2014, 12:33:23 AM »
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.

Quote from: OpenGL Spec
    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.

Sadly, I don't even have this extension.
Quote from: GLEW Info
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"

Here's the specific commit where they fixed FBO flipping in ANGLE

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.

Works in Progress / Re: [OGL3] Shader Test
« on: December 28, 2014, 02:33:18 PM »
Quote from: TheExDeus
We had numerous discussions about this and we didn't come to a real conclusion (as it seemed I was the only one interested on fixing it).
I am very interested in this as well, I just hate the problem because it shouldn't exist. You can choose the order the pixels are read when you blit a framebuffer but not when you use it as a texture, in addition the default main framebuffer isn't set up like this. It's such an annoying bug, you should be able to flip the thing left to right or vertically without any performance cost.

1) gross
2) We could just keep track of whether a surface is bound and check that in the projection functions, but this method is still inefficient
3) texture_matrix is deprecated GL, we'd have to do it manually ourselves and know in the default shaders for GL3 whether a surface is bound to invert the texture matrix, but this is only a little more efficient ostensibly than doing the same for the projection matrix

It would be nice to know how ANGLE handles this.

General ENIGMA / Re: Improving rooms editor
« on: December 28, 2014, 01:25:44 PM »
egofree, wow that's is very nice, I didn't expect you to document it that well, I just wanted the keyboard shortcuts listed really lol, but you did an awesome job! I love it  (Y)

Developing ENIGMA / New Portable
« on: December 28, 2014, 12:10:58 AM »
We've had some really awesome compiler fixes lately and I wanted to get these fixes out to everyone for testing. I have not updated LateralGM or the plugin since the last Portable ZIP, this was just a quick releases for these compiler fixes.

You can update by downloading the new ZIP.

You can also get these changes by entering the following in a terminal or using git-bash.exe
Code: [Select]
cd enigma-dev
git fetch
git pull

1) Nested macros have been fixed, this is basically nested string() calls, they will now work.
2) Fixed primitive arrays adding full multi-dimensional primitive array functionality.
3) Finished implementing the modulus assignment (%=) operator and overloaded it for var
4) Fixed alarm inheritance, though alarms may still fire out of order, they are supposed to be fired 0,1,2,3,etc. but currently ENIGMA fires the parents then the childs, this will be fixed in the future, but it is unlikely to cause a bug and it still works better than before. I can't really think of an example where someone would rely on alarm 1 to fire after alarm 0.
5) Instance activation/deactivation when used with inheritance fixed by sorlok
6) Enabled Unicode RC files, so you can enter the copyright symbol into LGM's platform settings now and it will properly encode it in your game executable
7) Fixes syntax checking output, fixes the line numbers and also actually formats the output for script, instance and room creation scope where it did not before.

General ENIGMA / Re: Who fixed arrays?
« on: December 27, 2014, 05:43:06 PM »
You are welcome Harri, and it looks like that is the next thing to fix while I am in here.

Code: (EDL) [Select]
int d[5][5];
d[5][5] = 3;

Gives me...
Code: [Select]
C:/ProgramData/ENIGMA/Preprocessor_Environment_Editable/IDE_EDIT_objectfunctionality.h:54:17: error: expression cannot be used as a function
     d[int(5)] (5)= 3;
C:/ProgramData/ENIGMA/Preprocessor_Environment_Editable/IDE_EDIT_objectfunctionality.h:55:39: error: expression cannot be used as a function
     show_message(toString(d[int(5)] (5) ));

So I still have some work to do, I'll try and see if I can get it fixed.

Edit: I fixed the multi-dimensional arrays as well in the following commit.

Code: (EDL) [Select]
int d[5][5][5];
d[5][5][5] = 4;

Will now properly parse into the following.
Code: (C++) [Select]
int d[5] [5] [5];
d[int(5)] [int(5)] [int(5)]= 4;
show_message(toString(d[int(5)] [int(5)] [int(5)] ));

Edit: Fixes tested and merged.

Issues Help Desk / Re: Font character range behaviour
« on: December 27, 2014, 05:14:08 PM »
I'm not going to do that, I'm just going to populate it with one the first time it is created Harri.

General ENIGMA / Re: Who fixed arrays?
« on: December 27, 2014, 05:11:30 PM »
I'd like to add to this post that I've recently sent a patch for some additional array fixes, specifically those which use primitives like int[] or double[]

I believe Harri was complaining about these bugs, it was broken by fundies just before the new JDI was merged back in 2012. The code for coercing the type was destroyed however because secondary parse is supposed to use an AST, but I temporarily hacked around that using a map. I would appreciate if the pull request could be regression tested by everyone to ensure I haven't broken anything else in the process.

General ENIGMA / Re: Improving rooms editor
« on: December 27, 2014, 05:09:29 PM »
Ok great, don't worry there's a few places where some keyboard modifiers are not stored there yet, I'll figure it out when I can.

Developing ENIGMA / Re: LateralGM
« on: December 27, 2014, 08:10:29 AM »
I was waiting until we reach 1.8.7 to announce it on the home page, like I have for every release in the past. This version we've gone with slower version increments, which is more proper, we don't want LateralGM 11 coming out after a month of development.

Issues Help Desk / Re: Font character range behaviour
« on: December 27, 2014, 08:09:08 AM »
That was partially my doing and the code somewhat existed in the plugin for it, because it was assumed that no character range was a corrupt font. I see now that has changed, maybe we should stop doing that and no character ranges means no character ranges, but then, why would anyone want a font with no character ranges? It would be unusable, for anything.

So anyway, let me get this straight, you guys think that the range should be added when the font is created also? I can see doing that, it is necessary to click '+' for the initial range, though it won't change much because you likely have to use the preview button to generate the ranges anyway. But sure we can do that, if I remember I originally wanted that anyway but just got to lazy to make it add one.