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.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 »
481
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.
https://www.opengl.org/registry/specs/ARB/clip_control.txt
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 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.
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
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.
https://www.opengl.org/sdk/docs/man/html/glClipControl.xhtml
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"
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.
482
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.
483
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
484
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.
http://enigma-dev.org/docs/Wiki/Install:Windows
You can also get these changes by entering the following in a terminal or using git-bash.exe
1) Nested macros have been fixed, this is basically nested string() calls, they will now work.
https://github.com/enigma-dev/enigma-dev/pull/906
2) Fixed primitive arrays adding full multi-dimensional primitive array functionality.
https://github.com/enigma-dev/enigma-dev/pull/908
3) Finished implementing the modulus assignment (%=) operator and overloaded it for var
https://github.com/enigma-dev/enigma-dev/pull/902
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.
https://github.com/enigma-dev/enigma-dev/pull/894
https://github.com/enigma-dev/enigma-dev/issues/895
5) Instance activation/deactivation when used with inheritance fixed by sorlok
https://github.com/enigma-dev/enigma-dev/pull/898
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
https://github.com/enigma-dev/enigma-dev/pull/893
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.
https://github.com/enigma-dev/enigma-dev/pull/913
You can update by downloading the new ZIP.
http://enigma-dev.org/docs/Wiki/Install:Windows
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.
https://github.com/enigma-dev/enigma-dev/pull/906
2) Fixed primitive arrays adding full multi-dimensional primitive array functionality.
https://github.com/enigma-dev/enigma-dev/pull/908
3) Finished implementing the modulus assignment (%=) operator and overloaded it for var
https://github.com/enigma-dev/enigma-dev/pull/902
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.
https://github.com/enigma-dev/enigma-dev/pull/894
https://github.com/enigma-dev/enigma-dev/issues/895
5) Instance activation/deactivation when used with inheritance fixed by sorlok
https://github.com/enigma-dev/enigma-dev/pull/898
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
https://github.com/enigma-dev/enigma-dev/pull/893
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.
https://github.com/enigma-dev/enigma-dev/pull/913
485
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.
Gives me...
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.
https://github.com/enigma-dev/enigma-dev/pull/908
Will now properly parse into the following.
Edit: Fixes tested and merged.
https://github.com/enigma-dev/enigma-dev/pull/908
Code: (EDL) [Select]
int d[5][5];
d[5][5] = 3;
show_message(string(d[5][5]));
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.
https://github.com/enigma-dev/enigma-dev/pull/908
Code: (EDL) [Select]
int d[5][5][5];
d[5][5][5] = 4;
show_message(string(d[5][5][5]));
Will now properly parse into the following.
Code: (CPP) [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.
https://github.com/enigma-dev/enigma-dev/pull/908
486
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.
487
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[]
https://github.com/enigma-dev/enigma-dev/pull/905
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.
https://github.com/enigma-dev/enigma-dev/pull/905
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.
488
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.
489
Developing ENIGMA / Re: LateralGM 1.8.6.837
« 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.
490
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.
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.
491
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(""))
https://github.com/IsmAvatar/LateralGM/blob/master/org/lateralgm/messages/keyboard.properties
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(""))
https://github.com/IsmAvatar/LateralGM/blob/master/org/lateralgm/messages/keyboard.properties
492
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?
493
Developing ENIGMA / Re: LateralGM 1.8.6.837
« 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.
@egofree, just leave it for now, it's not that big of a deal, I can fix it some time in the future.
494
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.
http://enigma-dev.org/docs/Wiki/Room_Editor
http://enigma-dev.org/docs/Wiki/Working_with_LateralGM
http://enigma-dev.org/docs/Wiki/Room_Editor
http://enigma-dev.org/docs/Wiki/Working_with_LateralGM
495
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.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 »