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 »
1816
Only on Windows and Macintosh, it seems. Other than that, intervention by myself or someone else versed in how ENIGMA handles platform differences may be required. I'm looking in to how they separate Mac from Windows. Perhaps it could be used to separate different Linux distributions as well. But yes, you should think of ENIGMA games as you would any other C++ project. No smoke, no mirrors, and no interpreters.
Okay, I've read over their stuff, and it's as if they're being deliberately uninformative until you contact them. Meaning they're wanting people to bite. But I will contact them here in the next week to see what they have to say.
Okay, I've read over their stuff, and it's as if they're being deliberately uninformative until you contact them. Meaning they're wanting people to bite. But I will contact them here in the next week to see what they have to say.
1817
General ENIGMA / Re: dependencies and updated install instructions needed
« on: August 03, 2010, 01:42:38 pm »
freezway: If they're as new to the OSS world as I imagine they are, have them wait six days.
1818
Proposals / Re: Code Formatting
« on: August 02, 2010, 06:18:09 pm »
A typical formatter can be written without a lex of any sort. I could do this with my style relatively easily. Different settings are plausible as well, without too much hassle, I mean. Currently, ENIGMA's output 'formatter' is a lazy piece of work that outputs it in "sort of legible" format. I keep very few variables, and no stack or anything, so it gets pretty ugly at times. Everything is given a space around it regardless, for example. So we see things like "; i ++ )". But I could pretty easily get the system in general to work for the sole purpose of beautification, if I wrote a new ending segment that simply put everything in a nice format.
Not right now, though. You and I still need to discuss getting that highlighter of yours to recognize my ever-changing function list...
Not right now, though. You and I still need to discuss getting that highlighter of yours to recognize my ever-changing function list...
1819
Proposals / Re: Just an appreciation
« on: July 30, 2010, 09:05:41 pm »
I don't believe I'll ever let it. A lot's changed since you've been here. Kinda makes me miss the old days. But, alas, progress is good. We're still in beta, if you want something to laugh about. But we're running out of reasons to be and things to blame on being in beta, so maybe we'll just call it a version after this. *shrug*
...Nah, this has always been the plan. Although that C parser I wrote took a bit longer than anticipated. Along with, well, pretty much all the other well-done components. I'm quite happy with the way things have been turning out... Bit more to organize, but yeah.
Anyway, how've you been?
*considers moving thread to off-topic, but doesn't care enough to*
...Nah, this has always been the plan. Although that C parser I wrote took a bit longer than anticipated. Along with, well, pretty much all the other well-done components. I'm quite happy with the way things have been turning out... Bit more to organize, but yeah.
Anyway, how've you been?
*considers moving thread to off-topic, but doesn't care enough to*
1820
Proposals / Re: Just an appreciation
« on: July 30, 2010, 07:13:55 pm »
I hadn't realized you were still alive, Dave. I haven't heard from you in 204 days, 9 hours, 19 minutes, and 43 seconds; but who's counting?
1821
Announcements / Re: Shortcuts
« on: July 30, 2010, 07:08:01 pm »
I used foreach for multiple reasons. One was so it didn't conflict with the 0x model. Frankly, C++ has had room for one for a while. If all the 0x model can do is const arrays (with explicit bounds, I mean), fuck it.
1822
Announcements / Re: Shortcuts
« on: July 29, 2010, 03:53:42 pm »
That actually made me laugh. I'm sorry. I'll do something interesting and easily understood when sounds work after revision 310.
1823
Announcements / Re: Shortcuts
« on: July 29, 2010, 12:25:19 pm »
This is not why I write intricate news posts.
1824
Announcements / Shortcuts
« on: July 28, 2010, 10:34:26 pm »
Long, long ago, in a land far-- actually, it was in this chair. Or some chair that looked similar. Be it as it may, a while back, I took a shortcut and thought, "If this ever comes back to bite me, it'll be after the rest of the project is stable and I can fix it without fear." Well, that mostly came true. There are no detrimental effects at this time, simply because the amount of skill required for the malefaction to manifest simply isn't being exhibited by ENIGMA users at this time. For those who wish to be weary, this is the issue:
When I designed the C++ parser, I did not implement a proper overloading system. Overloads were, instead of instantiated as children of a main instance as I considered doing, applied to the current copy by way of modifying the bounds for acceptable parameter numbers. For instance,
is stored only as a function returning double that takes either 1 or 2 parameters. Had the second function taken three parameters, the choices would be 1, 2, or 3, even though 3 was actually an invalid option. This makes for a blazingly inaccurate syntax check in rare situations (a GML user would never come close to noticing).
It also means a less pleasant inaccuracy on a more important system.
The following expressions were passed to a new type resolution system of mine:
room_speed
var
*var
room
room + room
room + 1
room - 1
var[5]
The results were, respectively, as follows:
Let's see if I can't waste some space and make a nicer table.
The more curious of you have a few questions. I'll do my best to answer those here:
room_speed and the like are being left integers. I see no point in wasting memory and speed so users can set some random array element in global scalars.
The type resolution system doesn't distinguish between cast and type at the moment (by choice, so I can debug without thinking of a global by that type. )
The type "roomv" is a special type with an overloaded operator= that calls room_goto(). It inherits from variant.
Because "roomv" is a special variant, room + room will return variant. This is correct. Room + anything will, in fact, so you can keep adding things such as strings.
However, room - 1 is double because subtraction only works on such. It wasn't worth it to avoid a warning on re-cast. Maybe I'll change my mind later, but in any case, the resolver was accurate.
Calls to [] on var are indeed variants.
So what's the problem? Look at item three, "*var". The parser can't distinguish between binary and unary *. Even though it knew it wanted the unary version, it couldn't get the accurate type, because I only store the type of the last declared overload, and so the parser was given `double`, the type returned by the multiplication operator.
When I need, I will store all overloads with argument counts and types, but that is a job for after the basics are all working. I want one more thing to work before I proceed, and it is indeed a trick; I would like for templated types to work, and if possible (by which I mean, it shall pass), templated casts. This way, if you have map<int,int> amap, you can say amap[whatever].x and have it behave correctly. That has been important to me since square one.
Another nice thing I can implement with the help of this system is the switch() optimization, as well as something brand new.
It befuddles me that neither C++ nor GML have a foreach construct. ENIGMA will be given one. It will work rather uniquely, since neither language was designed for it. Basically, it will have the following syntaxes:
foreach (array as element)
foreach (element in array)
foreach (element : array) //Java-esque
Trouble is getting it to work around this little issue: "in" and "as" are common variable names. So, I'm going to work around that thanks to how carefree my parser is when it operates.
will work fine.
To ease the sadistic and curious, that will look like this in intermediate parse:
Which makes it very easy to parse out. The first item, in (), is either what I'll be iterating, or the element name. The second, of form "nn;", will determine which; it should be "in" or "as". The third set, denoted easily by regexp /;(^;);/, is the corresponding element of the foreach.
So, how will that work from there? Simple. I determine which is the container to iterate. I then check for the following:
Depending on which of those I find, the foreach will be replaced with code to iterate each. The real trick is managing to proxy the "as" component in as a method of retrieving the element itself, and not the iterator type. Mind all of you, I'm not afraid to implement a macro if I must. But I imagine I can find a creative way to cram more instructions into the mix using operator, .
Anyway, I'll be busy. Thanks for your patience. I know this is taking a while, but the level of detail Ism and I've put into this goes far beyond the previous releases' quicker development time.
Peace.
When I designed the C++ parser, I did not implement a proper overloading system. Overloads were, instead of instantiated as children of a main instance as I considered doing, applied to the current copy by way of modifying the bounds for acceptable parameter numbers. For instance,
Code: (C++) [Select]
string func(int a) { return "test"; }
double func(int a, int b) { return "test2"; }
is stored only as a function returning double that takes either 1 or 2 parameters. Had the second function taken three parameters, the choices would be 1, 2, or 3, even though 3 was actually an invalid option. This makes for a blazingly inaccurate syntax check in rare situations (a GML user would never come close to noticing).
It also means a less pleasant inaccuracy on a more important system.
The following expressions were passed to a new type resolution system of mine:
room_speed
var
*var
room
room + room
room + 1
room - 1
var[5]
The results were, respectively, as follows:
Let's see if I can't waste some space and make a nicer table.
room_speed | => | int |
var | => | var |
*var | => | double |
room | => | roomv |
room + room | => | variant |
room + 1 | => | variant |
room - 1 | => | double |
var[5] | => | variant |
The more curious of you have a few questions. I'll do my best to answer those here:
room_speed and the like are being left integers. I see no point in wasting memory and speed so users can set some random array element in global scalars.
The type resolution system doesn't distinguish between cast and type at the moment (by choice, so I can debug without thinking of a global by that type. )
The type "roomv" is a special type with an overloaded operator= that calls room_goto(). It inherits from variant.
Because "roomv" is a special variant, room + room will return variant. This is correct. Room + anything will, in fact, so you can keep adding things such as strings.
However, room - 1 is double because subtraction only works on such. It wasn't worth it to avoid a warning on re-cast. Maybe I'll change my mind later, but in any case, the resolver was accurate.
Calls to [] on var are indeed variants.
So what's the problem? Look at item three, "*var". The parser can't distinguish between binary and unary *. Even though it knew it wanted the unary version, it couldn't get the accurate type, because I only store the type of the last declared overload, and so the parser was given `double`, the type returned by the multiplication operator.
When I need, I will store all overloads with argument counts and types, but that is a job for after the basics are all working. I want one more thing to work before I proceed, and it is indeed a trick; I would like for templated types to work, and if possible (by which I mean, it shall pass), templated casts. This way, if you have map<int,int> amap, you can say amap[whatever].x and have it behave correctly. That has been important to me since square one.
Another nice thing I can implement with the help of this system is the switch() optimization, as well as something brand new.
It befuddles me that neither C++ nor GML have a foreach construct. ENIGMA will be given one. It will work rather uniquely, since neither language was designed for it. Basically, it will have the following syntaxes:
foreach (array as element)
foreach (element in array)
foreach (element : array) //Java-esque
Trouble is getting it to work around this little issue: "in" and "as" are common variable names. So, I'm going to work around that thanks to how carefree my parser is when it operates.
Code: [Select]
foreach in in as
do_something()
will work fine.
To ease the sadistic and curious, that will look like this in intermediate parse:
foreach(in)in;as;do_something();
sssssss(nn)nn;nn;nnnnnnnnnnnn();
Which makes it very easy to parse out. The first item, in (), is either what I'll be iterating, or the element name. The second, of form "nn;", will determine which; it should be "in" or "as". The third set, denoted easily by regexp /;(^;);/, is the corresponding element of the foreach.
So, how will that work from there? Simple. I determine which is the container to iterate. I then check for the following:
- Typedef by name "iterator"; iterator container::begin(); iterator container::end(); iterator::operator++() or iterator::operator++(void)
- container::operator[](int); size_t container::size() or typeof(container::operator[](int))::operator bool()
Depending on which of those I find, the foreach will be replaced with code to iterate each. The real trick is managing to proxy the "as" component in as a method of retrieving the element itself, and not the iterator type. Mind all of you, I'm not afraid to implement a macro if I must. But I imagine I can find a creative way to cram more instructions into the mix using operator, .
Anyway, I'll be busy. Thanks for your patience. I know this is taking a while, but the level of detail Ism and I've put into this goes far beyond the previous releases' quicker development time.
Peace.
1826
Issues Help Desk / Re: GL Lighting
« on: July 25, 2010, 12:07:14 am »
I myself can't stand when you have snippets like this:
So, of course, I never put one-liners in braces
Most people don't. And I do my very best to cram things into one line, even if they end up getting pretty ugly themselves...
Operator, is nice, too...
And then there's those times I just totally ugly it up because continue and operator, don't agree.
And if I've got two things that really need done, I group them like Ism does.
I'm not afraid to put a continue; or the like after thing2(), either.
But when I'm navigating code flow, Ism's method makes my skin crawl, and I hate the rest of your proposals, too. Of course, that's just my opinion. It's one thing to waste space, it's another to cloud structure.
Code: (C++) [Select]
if (something)
{
something_minuscule();
continue;
}
So, of course, I never put one-liners in braces
Code: (C++) [Select]
if (something)
something_minor();
Most people don't. And I do my very best to cram things into one line, even if they end up getting pretty ugly themselves...
Code: (C++) [Select]
something ? something_unremarkable() : void();
Operator, is nice, too...
Code: (C++) [Select]
if (something)
a++, b++, c++, d=e=f;
And then there's those times I just totally ugly it up because continue and operator, don't agree.
Code: (C++) [Select]
if (something)
{ something_tedious(); continue; }
And if I've got two things that really need done, I group them like Ism does.
Code: (C++) [Select]
if (something) {
thing1();
thing2();
}
I'm not afraid to put a continue; or the like after thing2(), either.
But when I'm navigating code flow, Ism's method makes my skin crawl, and I hate the rest of your proposals, too. Of course, that's just my opinion. It's one thing to waste space, it's another to cloud structure.
1827
Off-Topic / Re: hi my name is kaylee!!!
« on: July 20, 2010, 06:42:17 pm »
First of all, the filters are infallible. I designed them myself. Our friend kaylee is just genuinely dumb. Picture a lifeless loser of a teenage drama queen who googles what she would look like if she weren't disgusting and posts pictures of herself on random message boards. Now picture a very bored Gary. kaylee is the latter.
Second off, as fate would have it, I'm grounded for an unspecified amount of time for crimes against the empire. I'll be back sometime in the near future. My father absconded with the more important of my outlet strips, so powering my computer will prove... well, unsafe in multiple respects.
This has not deterred planning on paper. Details will follow.
Second off, as fate would have it, I'm grounded for an unspecified amount of time for crimes against the empire. I'll be back sometime in the near future. My father absconded with the more important of my outlet strips, so powering my computer will prove... well, unsafe in multiple respects.
This has not deterred planning on paper. Details will follow.
1828
General ENIGMA / Re: APIs & Articles worth keeping in mind
« on: July 17, 2010, 12:05:09 pm »
...That's Luis, not Luda...
1829
General ENIGMA / Re: Pixel-Perfect Collision by default ? Box2D
« on: July 16, 2010, 08:10:07 am »
I don't believe Luda is going to go through with it, nor post what he's actually finished. I'm going to end up doing them myself.
...Yes, Retro beat me to it by five seconds.
...Yes, Retro beat me to it by five seconds.
1830
General ENIGMA / Re: Markdown
« on: July 11, 2010, 05:00:32 pm »
You've my support on the idea. It's about time people started merging the two anyway; markdown is a beautiful format.
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 »