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

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.

General ENIGMA / Re: Improving rooms editor
« on: December 27, 2014, 08:06:52 AM »
Yes because I don't plan on changing any of those shortcuts. I'm concerned with functional changes, my biggest irk is that you can't set the creation order that's all I really care to fix in the room editor besides bugs.

On a side note, have you been adding the keyboard shortcuts to the properties file I added? That was a change I made a while back, you should use KeyStroke.getKeyStroke(Messages.getKeyboardString(""))

Finished Games / Re: Christmas Run - Merry Chistmas to You!!!
« on: December 27, 2014, 12:04:48 AM »
Ahhh, I don't know try downloading your exe and see for yourself, space is creating blocks. Perhaps you have a different version than the one you compiled?

Developing ENIGMA / Re: LateralGM
« on: December 26, 2014, 09:08:52 PM »
Another quick update, I asked ego to add himself to the contributors list in case anyone may need to contact him in the future. I also added the new Calico room icons to Contrast until Josh gives us a proper SVG.

@egofree, just leave it for now, it's not that big of a deal, I can fix it some time in the future.

General ENIGMA / Re: Improving rooms editor
« on: December 26, 2014, 08:57:21 PM »
All of these caveats would best be documented on the Wiki page I linked you to. Instead of repeating the same instructions over and over again, just write them on the Wiki and then share the link to anybody who needs to know. Also so you don't forget either.

Programming Help / Re: Reading xml with Enigma?
« on: December 26, 2014, 08:54:54 PM »
Rapid XML is a cross-platform XML reader, pretty much the standard because of its light weight and efficiency. I used it to build a CLI, a CLI lets you build games from a terminal like command prompt without LateralGM or any IDE. Rapid XML is used to load the GMX format. Someone could write an XML extension for ENIGMA that uses Rapid XML and it would be available on all platforms because we use Rapid XML on all platforms for the CLI. It can't be much clearer than that.