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 »
1306
Announcements / Overdue Update
« on: July 25, 2011, 11:04:21 am »
All right, with nearly a hundred revisions since our last newspost (which was quite small), Polygone recommended that I make a new one. So here it is.
What's been done?
I implemented some of GM's syntax quirks. Assignment = to comparison ==, mostly, along with about 10 bug fixes for bugs discovered in TGMG's mass compilation sprees.
As part of this, I gutted the syntax checker, which was written before we had genuine intention of supporting C++ macros. Yeah, pretty ancient. The new one is in its early childhood (meaning half of it is written).
switch() has been implemented at the repeated request of kkg; at the moment, you can switch() anything that can be stored in "variant". Down the road, you'll be able to switch anything for which there is a switch_hash() overload. As you may have gathered from that previous statement, ENIGMA's switch() is hashed, unlike Game Maker's. This introduces an incompatibility: Putting the default: label first doesn't fuck everything over. <_< Other than that, you'll find that the only incompatibility is the massive increase in performance.
Polygone and HaRRiKiRi have been hard at work implementing functions and DND actions. Polygone, as practice while learning C++, has supplied an implementation of all data structure functions (ds_*), except ds_*_read/write() and ds_set_precision, "whatever the fuck that shit is." He also went on a DND-implementing spree; more trivial, but probably more likely to be noticed (it's surprising how many people fuss about really simple DND tiles missing, just because they threw them in random places).
As for HaRRi, he would like to just point out that C++ sucks, but that he has nonetheless (In addition, of course, to the huge number of font functions he has implemented) been working on an implementation of paths. For which, apparently, IsmAvatar has coded a writer to the EXE. You can expect to be seeing those sometime "in the next 42 years," even if I have to move them somewhere afterward.
Specifically, I would move them into the extensions directory. I spent a little bit establishing a modular system for incorporating underused variables and functions which will allow users to choose which ones they need, disabling the rest which would otherwise just be wasting memory and filesize. I have already moved alarm functions there (including action_set_alarm). With a little luck, Ism will hook that system up formally before I die of old age.
TGMG has been hard at work doing minor tweaks and function implementation to up compatibility further as well. He even wrote a quick, crude implementation of tiles (Don't worry; they're probably still faster than Game Maker's). I'll be replacing his present tile storage and drawing methods with more efficient ones down the road. Specifically, precompiled ones--there's no getting faster, assuming the ratio of fill to vertices is good (which it should be). We collaborated for a while to get some more GM quirks working, and actually made really good progress.
What does this mean for the state of the project?
Presently, our GM compatibility standings are as follows: 81 percent of GM examples harvested from 64Digits compile in ENIGMA when given fillers for missing functions. That means that the system is sound enough to manage all the dynamics of GML provided only that a few more functions are implemented in the backend. Why do nearly 20% fail? "Unforseen circumstances." Namely, they fail where GM's own syntax checker failed.
For example, take these codes:
That's right, instance_nearest(x,y,object0).x would cause a runtime error. Not a syntax error. GM's parser was so poor, it didn't know what to make of that code either. So it did it wrong, and people took advantage of that. But now ENIGMA's left with around 200 games that do that sort of shit. Not necessarily just those two; those two are just common ones that stuck with me. I have a whole laundry list of stupid shit like that to deal with.
As for the project's embrace for C++, with the syntax checker finally supporting macros, it's looking healthier than ever. I may soon add support for full-blown preprocessors.
Anyway, wish us luck. And enjoy the changes.
What's been done?
I implemented some of GM's syntax quirks. Assignment = to comparison ==, mostly, along with about 10 bug fixes for bugs discovered in TGMG's mass compilation sprees.
As part of this, I gutted the syntax checker, which was written before we had genuine intention of supporting C++ macros. Yeah, pretty ancient. The new one is in its early childhood (meaning half of it is written).
switch() has been implemented at the repeated request of kkg; at the moment, you can switch() anything that can be stored in "variant". Down the road, you'll be able to switch anything for which there is a switch_hash() overload. As you may have gathered from that previous statement, ENIGMA's switch() is hashed, unlike Game Maker's. This introduces an incompatibility: Putting the default: label first doesn't fuck everything over. <_< Other than that, you'll find that the only incompatibility is the massive increase in performance.
Polygone and HaRRiKiRi have been hard at work implementing functions and DND actions. Polygone, as practice while learning C++, has supplied an implementation of all data structure functions (ds_*), except ds_*_read/write() and ds_set_precision, "whatever the fuck that shit is." He also went on a DND-implementing spree; more trivial, but probably more likely to be noticed (it's surprising how many people fuss about really simple DND tiles missing, just because they threw them in random places).
As for HaRRi, he would like to just point out that C++ sucks, but that he has nonetheless (In addition, of course, to the huge number of font functions he has implemented) been working on an implementation of paths. For which, apparently, IsmAvatar has coded a writer to the EXE. You can expect to be seeing those sometime "in the next 42 years," even if I have to move them somewhere afterward.
Specifically, I would move them into the extensions directory. I spent a little bit establishing a modular system for incorporating underused variables and functions which will allow users to choose which ones they need, disabling the rest which would otherwise just be wasting memory and filesize. I have already moved alarm functions there (including action_set_alarm). With a little luck, Ism will hook that system up formally before I die of old age.
TGMG has been hard at work doing minor tweaks and function implementation to up compatibility further as well. He even wrote a quick, crude implementation of tiles (Don't worry; they're probably still faster than Game Maker's). I'll be replacing his present tile storage and drawing methods with more efficient ones down the road. Specifically, precompiled ones--there's no getting faster, assuming the ratio of fill to vertices is good (which it should be). We collaborated for a while to get some more GM quirks working, and actually made really good progress.
What does this mean for the state of the project?
Presently, our GM compatibility standings are as follows: 81 percent of GM examples harvested from 64Digits compile in ENIGMA when given fillers for missing functions. That means that the system is sound enough to manage all the dynamics of GML provided only that a few more functions are implemented in the backend. Why do nearly 20% fail? "Unforseen circumstances." Namely, they fail where GM's own syntax checker failed.
For example, take these codes:
Code: (GML) [Select]
for (;;;;;i = 0;;;; i < 10;; ;; ; ;i += 1;;; ) {}
// Game Maker doesn't care about semicolons in for(;;), so people got in the habit of doing this:
for (i = 0; i < 10; i += 1;) {}
// It's still wrong, but GM supports it.
if not_a_function
(100001).variable = true; // GM was okay with this, because instance_nearest(x,y,object0).x would cause a runtime error.
That's right, instance_nearest(x,y,object0).x would cause a runtime error. Not a syntax error. GM's parser was so poor, it didn't know what to make of that code either. So it did it wrong, and people took advantage of that. But now ENIGMA's left with around 200 games that do that sort of shit. Not necessarily just those two; those two are just common ones that stuck with me. I have a whole laundry list of stupid shit like that to deal with.
As for the project's embrace for C++, with the syntax checker finally supporting macros, it's looking healthier than ever. I may soon add support for full-blown preprocessors.
Anyway, wish us luck. And enjoy the changes.
1307
Issues Help Desk / Re: Failure to start Enigma from SVN on Ubuntu
« on: July 14, 2011, 09:55:23 am »
I forgot how long ago I made that fix. There's a possibility something else broke it in the meantime. Anyway, it's part of my testing suite now, so it's unlikely to go unnoticed if it breaks again.
1308
Issues Help Desk / Re: Hai halp me 2 fix mah gml plox.
« on: July 12, 2011, 03:53:38 pm »
[Warning: viewing the above game may cause cerebral infarction. View at your own risk.]
1309
General ENIGMA / Re: Questions on EDL and ENIGMA
« on: July 11, 2011, 08:42:47 pm »
I'll remove the parser for you after I finish pasting the audio system back on right-side-up.
1310
General ENIGMA / Re: Questions on EDL and ENIGMA
« on: July 11, 2011, 03:50:31 pm »
Using a PE header that I would normally not hesitate to strip? ...
Anyway, if that's the case, it seems you don't even need any cooperation on my part to get the engine hooked up to your fork. Even our definitions resource would work well with it.
Although I'm not seeing how LLVM would discern the contents of a C structure without being told.
Anyway, if that's the case, it seems you don't even need any cooperation on my part to get the engine hooked up to your fork. Even our definitions resource would work well with it.
Although I'm not seeing how LLVM would discern the contents of a C structure without being told.
1311
Issues Help Desk / Re: Failure to start Enigma from SVN on Ubuntu
« on: July 11, 2011, 02:18:26 pm »
How are you running the Jar? Last I checked, Ubuntu doesn't run jarfiles from within their own directories; you may want to try opening the terminal in that dir and invoking Java yourself.
1312
General ENIGMA / Re: Questions on EDL and ENIGMA
« on: July 11, 2011, 12:24:15 pm »
I don't much fancy the concept of making anything impossible in the language. I also don't fancy bounds checking. So if there's going to be any anti-segfault measure on this, it's going to be one that pulls a glibc and catches signals to inform the user of what blew up where, instead of preventing the explosion.
So, then, the engine and game codes would be separate. I suppose you want them dynamically linked, with the engine as the DLL. Or, knowing you, you want every piece of the engine as the DLL, and then some sort of go-between to be generated that lays out the functions, yes?
I have dedicated the last five minutes to thinking of the implications of using LLVM for the game and C++ for the engine. We'd miss out on structures for communicating between the C++ functions and the LLVM ones. There'd be a major segregation between the two. Getting arbitrary C functions defined to LLVM would be difficult and likely inconsistent.
So, then, the engine and game codes would be separate. I suppose you want them dynamically linked, with the engine as the DLL. Or, knowing you, you want every piece of the engine as the DLL, and then some sort of go-between to be generated that lays out the functions, yes?
I have dedicated the last five minutes to thinking of the implications of using LLVM for the game and C++ for the engine. We'd miss out on structures for communicating between the C++ functions and the LLVM ones. There'd be a major segregation between the two. Getting arbitrary C functions defined to LLVM would be difficult and likely inconsistent.
1313
General ENIGMA / Re: Questions on EDL and ENIGMA
« on: July 11, 2011, 12:00:47 pm »
The reason G++ is incapable of performing optimizations on var is because it does not recognize it as a plain datatype. The same optimizations cannot be made for variant as for double, because it doesn't understand to treat the class as a plain datatype. Implementing it in LLVM would fix that. Otherwise I'd have to do it myself.
As far as having C++ features without being tied to C++, I don't actually have a retort to that, even if you're trying to pass that off as a benefit.
I also like how you just pretend that C++ is this horribly unstable language while LLVM is the pinnacle of perfection. It reminds me of 4chan threads.
Let me ask; what would the engine be written in when we switched to LLVM? You're apparently implying it's not that bad, old C++.
As far as having C++ features without being tied to C++, I don't actually have a retort to that, even if you're trying to pass that off as a benefit.
I also like how you just pretend that C++ is this horribly unstable language while LLVM is the pinnacle of perfection. It reminds me of 4chan threads.
Let me ask; what would the engine be written in when we switched to LLVM? You're apparently implying it's not that bad, old C++.
1314
General ENIGMA / Re: Questions on EDL and ENIGMA
« on: July 11, 2011, 10:05:11 am »
You're always welcome to fork the project. Maybe the two of you could team up and work on an LLVM version.
Of course, we'd probably have to sacrifice our C++ features, or at very least the lexical optimization that would otherwise come with LLVM. And to utilize the full extent of those optimizations, we'd need to hard-code rules about var into our grammar as though it were a formal, POD type; how much code would we be discarding here, do you suppose?
Maybe you can implement this optimization I've been contemplating for a while using the current, compiler-independent configuration; I'd like to inline calls to small graphics functions such as draw_line and draw_point, and remove the if() for recurring calls to them. If you can get it to inline them, LLVM should be able to do this itself.
Of course, we'd probably have to sacrifice our C++ features, or at very least the lexical optimization that would otherwise come with LLVM. And to utilize the full extent of those optimizations, we'd need to hard-code rules about var into our grammar as though it were a formal, POD type; how much code would we be discarding here, do you suppose?
Maybe you can implement this optimization I've been contemplating for a while using the current, compiler-independent configuration; I'd like to inline calls to small graphics functions such as draw_line and draw_point, and remove the if() for recurring calls to them. If you can get it to inline them, LLVM should be able to do this itself.
1315
Function Peer Review / Re: GML: All draw_text functions +(string_width, _height, _width_ext, _height_ext)
« on: July 09, 2011, 08:46:59 pm »
How on earth does valign have any effect on draw_text? O_o
If it just centers the text around the given y coordinate, then there's no need to fork again. Just set the initial yy to valign == fa_top ? y : valign == fa_middle ? y - string_height(str)/2 : y - string_height(str).
And yeah, it's "though." But no one really cares if you abbreviate, even unintentionally.
If it just centers the text around the given y coordinate, then there's no need to fork again. Just set the initial yy to valign == fa_top ? y : valign == fa_middle ? y - string_height(str)/2 : y - string_height(str).
And yeah, it's "though." But no one really cares if you abbreviate, even unintentionally.
1316
Function Peer Review / Re: GML: All draw_text functions +(string_width, _height, _width_ext, _height_ext)
« on: July 09, 2011, 04:33:03 pm »
Yep. That way, string_width is never called for simple left-aligned text.
1317
Function Peer Review / Re: GML: All draw_text functions +(string_width, _height, _width_ext, _height_ext)
« on: July 09, 2011, 03:39:00 pm »Quote
Could you elaborate? You mean having separate drawing functions for all six alignments? Then how will that be backwards compatible with GM? Or how will draw_set_halign/valign actually work in that case?No, just put the original function in a big if for align being top-left, and then put the rest of the code in the else with whatever hackery is required, that way you don't have to iterate the string for draw_text() when the aligns are default.
Quote
Also, why do I need this: ...Otherwise, \r\n will put two newlines, or if you place ", u+= str[i]=='\n';" at the end of the proposed replacement, '\n\n' will be treated as one line.
1318
General ENIGMA / Re: Questions on EDL and ENIGMA
« on: July 09, 2011, 02:17:38 pm »
Not all of the DND functions are implemented, no. A good deal of them are; they're just not a major priority as we are trying to get the actual function base implemented first.
You certainly can use C++ functions in EDL, as well as its types and classes. At the moment, functions and classes must be declared in ENIGMA Settings->Definitions, but we will be adding a separate resource for that shortly.
We're trying to minimize differences while adding features. Most of the differences at the moment are just a matter of which features are missing from GML, and which are new to EDL. The biggest stumbling blocks at the moment are that in the latest 'stable' tag, = is exclusively an assignment, and == is the only comparison operator. We have modified the trunk to default to Game Maker's behavior, and made the settings panel actually work in it.
In the trunk, the biggest difference is the behavior of booleans. In GM, (-1) is considered false because it's not greater than zero; in EDL, (-1) is true because it is nonzero.
If you would like to just pick a set of functions we haven't implemented and write them, that would always be appreciated.
As far as compiling to C++ first, it is in our benefit to do so. By letting the GCC take care of compilation for us, we gain a large number of powerful optimizations. We also gain access to a source that we can examine to find lapses in the compiler's understanding of the code; it's much cleaner that way.
You certainly can use C++ functions in EDL, as well as its types and classes. At the moment, functions and classes must be declared in ENIGMA Settings->Definitions, but we will be adding a separate resource for that shortly.
We're trying to minimize differences while adding features. Most of the differences at the moment are just a matter of which features are missing from GML, and which are new to EDL. The biggest stumbling blocks at the moment are that in the latest 'stable' tag, = is exclusively an assignment, and == is the only comparison operator. We have modified the trunk to default to Game Maker's behavior, and made the settings panel actually work in it.
In the trunk, the biggest difference is the behavior of booleans. In GM, (-1) is considered false because it's not greater than zero; in EDL, (-1) is true because it is nonzero.
If you would like to just pick a set of functions we haven't implemented and write them, that would always be appreciated.
As far as compiling to C++ first, it is in our benefit to do so. By letting the GCC take care of compilation for us, we gain a large number of powerful optimizations. We also gain access to a source that we can examine to find lapses in the compiler's understanding of the code; it's much cleaner that way.
1319
Function Peer Review / Re: GML: All draw_text functions +(string_width, _height, _width_ext, _height_ext)
« on: July 09, 2011, 10:35:51 am »
That code doesn't consider newlines. Not having the code as fa_left fucks everything up, efficiency wise. You're best to fork up front.
1320
Function Peer Review / Re: "Choose" statement
« on: July 08, 2011, 03:16:40 pm »
Ah; you've stumbled on a way to make ENIGMA honor max() having unlimited parameters.
That's... typically kind of dangerous, but I guess it's as good a hack as any. For the time being, you can implement those functions like this:
You must declare and implement choose before defining it. In the source, you may be wise to #undef choose, then implement it. DO NOT implement choose(...); it's too segfault-prone. This way, worst-case scenario is link error, not random abort().
That's... typically kind of dangerous, but I guess it's as good a hack as any. For the time being, you can implement those functions like this:
Code: (C++) [Select]
variant choose(...);
int choose(const enigma::varargs& args) {
return args.get(rand() % args.argc);
}
#define choose(x...) choose((varargs(), x))
You must declare and implement choose before defining it. In the source, you may be wise to #undef choose, then implement it. DO NOT implement choose(...); it's too segfault-prone. This way, worst-case scenario is link error, not random abort().
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 »