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 »
886
ALLCAPS BOARD / Re: cheeseshit
« on: January 06, 2013, 05:24:54 pm »
Sometimes I wish more people would just
887
General ENIGMA / Re: ENIGMA losing ground to studio?
« on: January 06, 2013, 02:42:10 pm »
We communicate over IRC; network freenode, channel #enigma. There's a web interface on the forum index.
888
General ENIGMA / Re: ENIGMA losing ground to studio?
« on: January 06, 2013, 02:36:28 pm »
Correct. I do not think we have a Wiki page on the matter because interest in writing an IDE is low, but we could easily start one.
889
General ENIGMA / Re: ENIGMA losing ground to studio?
« on: January 06, 2013, 02:30:18 pm »
I don't do roadmaps; they change too easily.
890
General ENIGMA / Re: ENIGMA losing ground to studio?
« on: January 06, 2013, 02:28:03 pm »
We already compile our scripts natively. Their use of LLVM is simply not a threat to us.
As for shaders, those are still in the planning phase. We need to come up with a unified syntax that will work over DX, GLES, and GL. I am already laying out a method of importing scripting languages into ENIGMA, though, so using multiple shader languages is a really simple solution.
As for shaders, those are still in the planning phase. We need to come up with a unified syntax that will work over DX, GLES, and GL. I am already laying out a method of importing scripting languages into ENIGMA, though, so using multiple shader languages is a really simple solution.
891
General ENIGMA / Re: ENIGMA losing ground to studio?
« on: January 06, 2013, 02:18:51 pm »
LateralGM's development is at a low, yes, but it's still maintained. As for it looking like shit, I'll grant that.
Anyway, we'd be happy to support your IDE in the same way we support LGM; we just ship it with the compiler. All you have to do is implement the same methods you can see done in Enigma.jar, and you can load ENIGMA and call it in the same way LGM does. The two projects are very separate.
Anyway, we'd be happy to support your IDE in the same way we support LGM; we just ship it with the compiler. All you have to do is implement the same methods you can see done in Enigma.jar, and you can load ENIGMA and call it in the same way LGM does. The two projects are very separate.
892
General ENIGMA / Re: ENIGMA losing ground to studio?
« on: January 06, 2013, 02:06:53 pm »
Hiya,
I have been working on a new parser for a much more capable dialect of GML than the one employed by Yoyo. I am aware of their potential hike in speed from trying to compile their games, but I'm afraid that it will not do them any good when you compare the price tags. Even if they do match our speed, 100%, they will still not be competition for us ceteris paribus due to their incredible pricing scheme. That said, I don't see that we've lost any battle.
With the new parser I want to make ENIGMA at least as easy to use for mobile development as GM:S. At that point, it will come down to price and language features—ENIGMA will curb-stomp GM in both departments.
In addition to static typing, the new flavor of EDL I have written (and am still writing) will offer a lot of features that Dailly turned his nose up at, and a few more that he had expressed a desire to implement but did not believe he would find time for. Among these features are static typing (which we've always supported), much better support for arrays, support for closures, support for C++ operators, support for class/structure declarations, etc.
We also have a special surprise planned that we had introduced in R3, but that has since fallen into the history books. We'll be reintroducing it soon; ideally before Yoyo ever comes up with it. It's guaranteed to make development easier, especially for games like yours.
So yes, while Yoyo is catching up to us in performance, we'll still be in a league of our own in pricing and capability.
I have been working on a new parser for a much more capable dialect of GML than the one employed by Yoyo. I am aware of their potential hike in speed from trying to compile their games, but I'm afraid that it will not do them any good when you compare the price tags. Even if they do match our speed, 100%, they will still not be competition for us ceteris paribus due to their incredible pricing scheme. That said, I don't see that we've lost any battle.
With the new parser I want to make ENIGMA at least as easy to use for mobile development as GM:S. At that point, it will come down to price and language features—ENIGMA will curb-stomp GM in both departments.
In addition to static typing, the new flavor of EDL I have written (and am still writing) will offer a lot of features that Dailly turned his nose up at, and a few more that he had expressed a desire to implement but did not believe he would find time for. Among these features are static typing (which we've always supported), much better support for arrays, support for closures, support for C++ operators, support for class/structure declarations, etc.
We also have a special surprise planned that we had introduced in R3, but that has since fallen into the history books. We'll be reintroducing it soon; ideally before Yoyo ever comes up with it. It's guaranteed to make development easier, especially for games like yours.
So yes, while Yoyo is catching up to us in performance, we'll still be in a league of our own in pricing and capability.
893
Proposals / Re: Returning multiple variables
« on: January 06, 2013, 01:07:31 pm »
Yeah, return type and parameter types will default to variant.
894
Proposals / Re: Returning multiple variables
« on: January 05, 2013, 09:24:49 pm »
I'm hijacking this thread. This thread is now about determining a syntax for functions declarations.
My plan to allow doing what you are describing is to use the Definitions resource that's been on Ism's plate for six centuries to allow declaring EDL functions.
Do we stick to C++ syntax, or somehow incorporate a function keyword?
ENIGMA handles its declarations manually, so we can do basically anything.
The benefit to using the function keyword is that it makes closures syntactically unambiguous. Consider [snip=js]function() { return 1.337; }[/snip]. I could easily enough coerce that for a type, but that isn't the point. The alternative is [snip=edl]double() { return 1.337; }[/snip], but [snip=edl]double()[/snip] already means "the default value of a double," which is 0d.
The hybrid alternative is a little uglier, but completely unambiguous: [snip=edl]function double() { return 1.337; }[/snip], or [snip=edl]function double my_script() { return some_double; }[/snip].
If these functions can't have return types, then there's no point to having them over scripts. So the question is, which do we want more: closures, or not having to use the function keyword?
An array type for [snip=edl][a,b,c][/snip] is in progress, by the way, HaRRi.
My plan to allow doing what you are describing is to use the Definitions resource that's been on Ism's plate for six centuries to allow declaring EDL functions.
Do we stick to C++ syntax, or somehow incorporate a function keyword?
ENIGMA handles its declarations manually, so we can do basically anything.
The benefit to using the function keyword is that it makes closures syntactically unambiguous. Consider [snip=js]function() { return 1.337; }[/snip]. I could easily enough coerce that for a type, but that isn't the point. The alternative is [snip=edl]double() { return 1.337; }[/snip], but [snip=edl]double()[/snip] already means "the default value of a double," which is 0d.
The hybrid alternative is a little uglier, but completely unambiguous: [snip=edl]function double() { return 1.337; }[/snip], or [snip=edl]function double my_script() { return some_double; }[/snip].
If these functions can't have return types, then there's no point to having them over scripts. So the question is, which do we want more: closures, or not having to use the function keyword?
An array type for [snip=edl][a,b,c][/snip] is in progress, by the way, HaRRi.
895
Announcements / Re: Christmas Plans
« on: January 05, 2013, 06:01:09 pm »
The new parser's is important to me because it means we can finally have extensions and additional host languages (eg, JavaScript). I've made the compiler so modular locally that TGMG should have *zero* difficulty finally making the Android part work out of the box.
Moreover, the compiler was in need of some redesign—a lot of it was thrown together hastily, and in a scatterbrained manner. I can't expect other people to maintain it if I can't even cleanly describe its pieces. After this, it should be much easier to tell what is going on in the compiler code.
Moreover, the compiler was in need of some redesign—a lot of it was thrown together hastily, and in a scatterbrained manner. I can't expect other people to maintain it if I can't even cleanly describe its pieces. After this, it should be much easier to tell what is going on in the compiler code.
896
Announcements / Re: Christmas Plans
« on: January 03, 2013, 04:47:15 pm »
Quick update:
Sorry that this is taking so long. While the parser is basically plugged in, I did not even consider how much work is involved in the other major operation I am taking care of: abstracting the language being compiled to.
The compiler now knows literally nothing about the host language; I have to move tons of ancient code from the global scope to various subclasses to facilitate having multiple implementations for multiple languages. It is genuinely a pain.
I have no accurate ETA, but I'm going to be spending 90% of my waking time on it. It must be done before Sunday night.
Sorry that this is taking so long. While the parser is basically plugged in, I did not even consider how much work is involved in the other major operation I am taking care of: abstracting the language being compiled to.
The compiler now knows literally nothing about the host language; I have to move tons of ancient code from the global scope to various subclasses to facilitate having multiple implementations for multiple languages. It is genuinely a pain.
I have no accurate ETA, but I'm going to be spending 90% of my waking time on it. It must be done before Sunday night.
898
Proposals / Re: Weird stuff that works in GM but fails in ENIGMA
« on: January 02, 2013, 07:37:17 pm »
I haven't forgotten about you. But I want my response to be more thorough than I can give right now with the project in pieces before me. Give me a bit.
899
Announcements / Re: Christmas Plans
« on: January 02, 2013, 04:13:26 pm »
Because copypasta fail. Thanks. Fix'd.
The variable object0 is an object name, so it's an object_index.
The variable object0 is an object name, so it's an object_index.
900
Announcements / Re: Christmas Plans
« on: January 02, 2013, 02:40:59 pm »
Just so everyone knows, I am adding something to ENIGMA's specification after the parser is plugged in:
Humans can tell what that's doing, but a parser cannot necessarily make that call. Maybe if I spent a great lot of time on it, it could, but in general you should expect this output from the C++ printer:
The idea is that the switch statement used in varaccess_variable is removed, and does not even need to be generated if `variable' is never accessed in that way. It'll still be generated as needed for compatibility, of course.
Note as well that I may optimize it further and generate an inline function for each object as needed, or just access them inline (more likely the former for reasons of error checking and general prettiness). Still, you get the idea.
Code: (EDL) [Select]
object0.variable = 10;
int a = object0.id;
a.variable = 20;
object0[a].variable = 30;
Humans can tell what that's doing, but a parser cannot necessarily make that call. Maybe if I spent a great lot of time on it, it could, but in general you should expect this output from the C++ printer:
Code: (CPP) [Select]
((ENIGMA_OBJ_object0*)fetch_instance_by_objectid(object0))->variable = 10;
int a = enigma::fetch_instance_by_objectid(object0)->id;
enigma::varaccess_variable(a) = 20;
((ENIGMA_OBJ_object0*)fetch_instance_by_id(a))->variable = 30;
The idea is that the switch statement used in varaccess_variable is removed, and does not even need to be generated if `variable' is never accessed in that way. It'll still be generated as needed for compatibility, of course.
Note as well that I may optimize it further and generate an inline function for each object as needed, or just access them inline (more likely the former for reasons of error checking and general prettiness). Still, you get the idea.
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 »