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 »
2626
Announcements / Re: Subject
« on: July 25, 2009, 10:30:55 pm »
Luis-- score_under's a C programmer. If he has collisions, it's because what he's doing is so unforgivingly complicated that he needs that many variables.
score_under:
That's the less ugly way. There is an alternative, though, which is what I would have used instead in my example.
But overall, people consider that a gruesome mutilation of the language, I imagine.
As for progress, it's anyone's game. Meaning. I'm tossing some ideas back and forth with Ism, who will be gone this week anyway. But basically, what we've done now is isolated which groups of keywords will have to be uniquely tokenized. (This grouping is changing a lot since I'm now supporting C++. When it was just the C basics and some GML, there was no need for this kind of reordering. Now there is.)
score_under:
That's the less ugly way. There is an alternative, though, which is what I would have used instead in my example.
Code: [Select]
#ifndef DLL
#define filearg_if_not_a_dll, char*filename
#else
#define filearg_if_not_a_dll, char*filename
#endif
void DecodeProc2(FILE* fileM_,
unsigned int narc,
unsigned int FileZoomPos,
char*filename
filearg_if_not_a_dll)
{
But overall, people consider that a gruesome mutilation of the language, I imagine.
As for progress, it's anyone's game. Meaning. I'm tossing some ideas back and forth with Ism, who will be gone this week anyway. But basically, what we've done now is isolated which groups of keywords will have to be uniquely tokenized. (This grouping is changing a lot since I'm now supporting C++. When it was just the C basics and some GML, there was no need for this kind of reordering. Now there is.)
2627
Announcements / Re: Progress
« on: July 25, 2009, 12:28:40 am »
It won't take until next year. I would like it to be before October, but I hate giving dates.
Also, can we not bring old news posts to the top?
Also, can we not bring old news posts to the top?
2628
Announcements / Re: Subject
« on: July 24, 2009, 01:26:55 am »
Today's standings:
Getting ass raped by preprocessors.
Don't get me wrong, that's a SHITTY way to do ANYTHING. But because it CAN be done, I have to accommodate it. And that just sucks.
The question left by the above piece of code is, should they not use them, HOW DO I ADD SEMICOLONS TO THAT?
The only way to take care of it is to go all out on my expression evaluator and have it evaluate #if. That way, I don't rely on GCC for that part.
#pragma will result in a PEBKAC exception, or will be moved to the DESIGNATED resource for such bull.
#define will probably be #undefine'd after the piece of code they are used in. This is mostly to remove confusion in cheap hacks, by eliminating them entirely.
And this sort of rage is why I never post progress XD
The general public isn't used to the fact that when I am flaming something like that, it's because I'm enjoying myself and am intrigued by a problem.
Consider it a way of not only venting, but also recollecting based on what's known to not work, process-of-elimination style.
This is nothing I can't handle. (I hope. Just believe it.)
Getting ass raped by preprocessors.
Code: [Select]
var a =
#if somemacro
0;
#else
20;
#endif
Don't get me wrong, that's a SHITTY way to do ANYTHING. But because it CAN be done, I have to accommodate it. And that just sucks.
The question left by the above piece of code is, should they not use them, HOW DO I ADD SEMICOLONS TO THAT?
The only way to take care of it is to go all out on my expression evaluator and have it evaluate #if. That way, I don't rely on GCC for that part.
#pragma will result in a PEBKAC exception, or will be moved to the DESIGNATED resource for such bull.
#define will probably be #undefine'd after the piece of code they are used in. This is mostly to remove confusion in cheap hacks, by eliminating them entirely.
And this sort of rage is why I never post progress XD
The general public isn't used to the fact that when I am flaming something like that, it's because I'm enjoying myself and am intrigued by a problem.
Consider it a way of not only venting, but also recollecting based on what's known to not work, process-of-elimination style.
This is nothing I can't handle. (I hope. Just believe it.)
2629
Announcements / Re: Subject
« on: July 23, 2009, 05:38:53 pm »
*facepalm*
global int x = x;
local int x = x;
alternatively
global.x = x;
local.x = x;
But both of those will end up being var.
global int x = x;
local int x = x;
alternatively
global.x = x;
local.x = x;
But both of those will end up being var.
2630
Announcements / Re: Subject
« on: July 22, 2009, 09:45:44 pm »
Retro:
Debug mode will hopefully utilize that expression evaluator I made.
Currently debug mode will offer some additional error checking, such as adding strings to integers.
I don't understand how casting to the global scope would work, really.
As in GM7, you can declare a global by saying
Anyway.
Today's standings:
I've called this function basically every bad word in my vocabulary. It needs to keep track of scope for when you say "using", which totally fucks the simplistic find-replace structure of my parser in the ass.
Parser strips and stores strings now, and successfully removes all whitespace and comments. This was going to be the only major change, and it's proving to be just as big a pain as I thought it would.
The goal of what I'm doing right now is to set up what I call a syntax map, which is a copy of the code kept in a separate string, only where varnames, numbers, statements (such as if), declarators (such as var), etc, are each given a separate letter to represent them.
This is the same thing the original parser did, only I've condensed it, and am doing a couple things slightly different for improved efficiency.
The problem is figuring out whether the current name I've run into is just a name, or if it's a declarator like var. Checking if it is var is easy, but C++ brings classes to the table, so I need to be able to check if the user has declared a class by that name, too. Overall, it is a huge pain in the ass.
Debug mode will hopefully utilize that expression evaluator I made.
Currently debug mode will offer some additional error checking, such as adding strings to integers.
I don't understand how casting to the global scope would work, really.
As in GM7, you can declare a global by saying
Code: [Select]
global var a;
ENIGMA will just add local to that for things like this:Code: [Select]
global var a;
local int b;
global double c;
Anyway.
Today's standings:
I've called this function basically every bad word in my vocabulary. It needs to keep track of scope for when you say "using", which totally fucks the simplistic find-replace structure of my parser in the ass.
Parser strips and stores strings now, and successfully removes all whitespace and comments. This was going to be the only major change, and it's proving to be just as big a pain as I thought it would.
The goal of what I'm doing right now is to set up what I call a syntax map, which is a copy of the code kept in a separate string, only where varnames, numbers, statements (such as if), declarators (such as var), etc, are each given a separate letter to represent them.
This is the same thing the original parser did, only I've condensed it, and am doing a couple things slightly different for improved efficiency.
The problem is figuring out whether the current name I've run into is just a name, or if it's a declarator like var. Checking if it is var is easy, but C++ brings classes to the table, so I need to be able to check if the user has declared a class by that name, too. Overall, it is a huge pain in the ass.
2631
General ENIGMA / Re: Game Maker 8
« on: July 22, 2009, 01:19:53 pm »
Didn't think I'd see the day. Pixels over .5 alpha are used in collisions, I take it?
2632
Announcements / Re: Subject
« on: July 22, 2009, 10:47:21 am »
Next to no part of R3 was the same as R1. R3 didn't have a line of code in the same place as R1, but a diff would have shown that it wasn't more than 30% changed. R4, though... Probably not.
Rusky once called the RX releases 'Proof-of-concept', and I kind of like the term. And as I'm thinking of more concepts to prove, and fixing up the old things... Most of the code just isn't going to last.
ENIGMA used to be C, which means that some of the code still uses malloc() instead of new[]. (And then still fewer frees it with delete[] even after allocating with malloc XD). Things like that didn't make it to R3; only survived R2 because they worked. And I've thought of better ways to do certain things each progressing release (scripts in R1 probably didn't even work. R2's had some glitches, R3's didn't work in with()... R4's will be, so far as I can see right now, flawless).
ENIGMA's such a big project that it's impossible not to get better at things as you work on it. And as you get better, you notice how bad your old code was, you get a great feel for the big picture, and you think of ways to make even trivial things more efficient. I like being able to say I've paid attention to detail as far as efficiency goes. And even though no matter what I do wrong, it'll never be as slow as GM, I want to keep it as fast as possible.
Thinking back to the first release, how disoriented I was hooking everything together... There was so much that interacted with and depended upon so much else... I wanted to just lie down and quit. Couldn't follow it all in my head. I ended up blindly following the original plan without giving any question to what was going on, and it worked. Since then, I have no problem, as you can see, gutting the entire project and putting it all back together. It's even taking less time to do things.
Rusky once called the RX releases 'Proof-of-concept', and I kind of like the term. And as I'm thinking of more concepts to prove, and fixing up the old things... Most of the code just isn't going to last.
ENIGMA used to be C, which means that some of the code still uses malloc() instead of new[]. (And then still fewer frees it with delete[] even after allocating with malloc XD). Things like that didn't make it to R3; only survived R2 because they worked. And I've thought of better ways to do certain things each progressing release (scripts in R1 probably didn't even work. R2's had some glitches, R3's didn't work in with()... R4's will be, so far as I can see right now, flawless).
ENIGMA's such a big project that it's impossible not to get better at things as you work on it. And as you get better, you notice how bad your old code was, you get a great feel for the big picture, and you think of ways to make even trivial things more efficient. I like being able to say I've paid attention to detail as far as efficiency goes. And even though no matter what I do wrong, it'll never be as slow as GM, I want to keep it as fast as possible.
Thinking back to the first release, how disoriented I was hooking everything together... There was so much that interacted with and depended upon so much else... I wanted to just lie down and quit. Couldn't follow it all in my head. I ended up blindly following the original plan without giving any question to what was going on, and it worked. Since then, I have no problem, as you can see, gutting the entire project and putting it all back together. It's even taking less time to do things.
2633
General ENIGMA / Re: Game Maker 8
« on: July 21, 2009, 09:34:53 pm »
I just have to change random_integer to irandom. I'll also need to study their random_range function to see what it does. Shouldn't be difficult.
(Fun fact: seeds in ENIGMA produce the same results as the same seed in GM/Delphi)
If by alpha masks, they just mean you can specify which color is transparent, ENIGMA and LGM can already do that. We agreed on it for later extensibility.
I'd like someone to tell me how constants are defined now, though.
(Fun fact: seeds in ENIGMA produce the same results as the same seed in GM/Delphi)
If by alpha masks, they just mean you can specify which color is transparent, ENIGMA and LGM can already do that. We agreed on it for later extensibility.
I'd like someone to tell me how constants are defined now, though.
2634
Announcements / Subject
« on: July 21, 2009, 09:27:47 pm »
I told a2h to rag on me to post what I've done each day.
Don't get your hopes up though; I'm not updating the stupid 'completed functions' page.
Recent activities include collecting all my work from the last few months and organizing them into the same root directory.
What's basically happening is I'm hooking up the Expression evaluator, CFile Parser, Syntax Checker, and EDL Parser up to the Compiler, regardless of what's done and what's not.
This will, ideally, allow me to get them all working together and add on as I go.
I've also begun a large-part recode around the original EDL Parser. It has to be done at some point. Why? Well...
It's a somewhat-known fact that the EDL Parser is written in GML. A lot of you are thinking "wtf" right now. I wrote the parser, then exported it, and parsed it to C++ with itself. And it worked. (With the addition of function names around each script it parsed).
It instantly gained at least a tenfold speed increase, but that's not enough.
(Not to mention parsed GML is plug ugly; NO comments, which is 1% less than the 'desired' percentage of comments I normally leave, and no whitespace or structure)
Basically, the idea's brilliant, but the code's a bit sluggish and eww since it used to be GML. Was the ultimate benchmark, but now things need to be implemented that GML can't describe.
Please take the next couple minutes to get over the fact the parser is/was GML. Read on when you're ready.
Moving on, then, the new parser will not use < to indicate tokens in its stream. Instead, it will add a couple more letters for equally fast, less ambiguous indexing.
Scripts were scoped into each object that used them in R3. In R4, they will be defined in the global scope, and will be passed this. (The C++ loose-equivalent of id) This corrects a problem where with (a) scrname() doesn't work. You probably didn't notice.
Also, localv is being changed to local in light of Yoyo deciding that global var a; was a good idea. Now you can say local var a;, which is about as useless as saying self.varname, but is useful for saying local int a; or local double a; and not wasting all that space and time. (Though not much of either, really.)
Those who pay attention and have decent footing between these two languages know that you will now have the entirety of C++ at your disposal. If you really wanted, you could #include <iostream> and cout << "something";. Unless I decide that I'm going to maintain checking for assignment operator, in which case you'd have to say something stupid before it with an =. Haha.
There's another chunk of work I'm not looking forward to, which involves the new format. We've added basically every resource to the format, but this doesn't mean they all work yet. I'll derive background from sprite, but sound is gonna be a pain in the arse.
Another change, for those with good footing in C++, is that string() will not be a function anymore. GML fans, don't panic: Saying string() will still work. The difference is purely technical; string() will be a constructor of a new datatype.
I had a problem with var that prohibited me from taking int as an argument type, which hindered efficiency. The new string class should fix that problem. It will be derived from std::string, with some additional namespace magic to prevent screwups.
If anyone really needs me to explain the details of that, I can, but I'm not going to unless someone asks.
In other other news, I'll be continuing development on Linux. Most of you know ENIGMA works on Linux now. Since the OS is more picky with things--for instance, file name capitalization--I think it'd be a good idea to move to it. And file names aren't the extent of it; big GCC, as in, the GCC which is not minimalist or for Windows and likely has the majority of GNU devs on its case, offers more precise error checking and warns on more things. Which is nice, as it prevents errors down the road.
Anyway, I'ma get back to working on the compiler. I have to find my new instance system and put it in the shell folder. After it's at a good stop point, I'm wiping the SVN and reuploading everything. (Makes it easier switching back and forth between platforms).
No news on ENIGMA's LibOGC frontend.
Cheers. A2h will hopefully make me edit this tomorrow. Maybe even post new.
Don't get your hopes up though; I'm not updating the stupid 'completed functions' page.
Recent activities include collecting all my work from the last few months and organizing them into the same root directory.
What's basically happening is I'm hooking up the Expression evaluator, CFile Parser, Syntax Checker, and EDL Parser up to the Compiler, regardless of what's done and what's not.
This will, ideally, allow me to get them all working together and add on as I go.
I've also begun a large-part recode around the original EDL Parser. It has to be done at some point. Why? Well...
It's a somewhat-known fact that the EDL Parser is written in GML. A lot of you are thinking "wtf" right now. I wrote the parser, then exported it, and parsed it to C++ with itself. And it worked. (With the addition of function names around each script it parsed).
It instantly gained at least a tenfold speed increase, but that's not enough.
(Not to mention parsed GML is plug ugly; NO comments, which is 1% less than the 'desired' percentage of comments I normally leave, and no whitespace or structure)
Basically, the idea's brilliant, but the code's a bit sluggish and eww since it used to be GML. Was the ultimate benchmark, but now things need to be implemented that GML can't describe.
Please take the next couple minutes to get over the fact the parser is/was GML. Read on when you're ready.
Moving on, then, the new parser will not use < to indicate tokens in its stream. Instead, it will add a couple more letters for equally fast, less ambiguous indexing.
Scripts were scoped into each object that used them in R3. In R4, they will be defined in the global scope, and will be passed this. (The C++ loose-equivalent of id) This corrects a problem where with (a) scrname() doesn't work. You probably didn't notice.
Also, localv is being changed to local in light of Yoyo deciding that global var a; was a good idea. Now you can say local var a;, which is about as useless as saying self.varname, but is useful for saying local int a; or local double a; and not wasting all that space and time. (Though not much of either, really.)
Those who pay attention and have decent footing between these two languages know that you will now have the entirety of C++ at your disposal. If you really wanted, you could #include <iostream> and cout << "something";. Unless I decide that I'm going to maintain checking for assignment operator, in which case you'd have to say something stupid before it with an =. Haha.
There's another chunk of work I'm not looking forward to, which involves the new format. We've added basically every resource to the format, but this doesn't mean they all work yet. I'll derive background from sprite, but sound is gonna be a pain in the arse.
Another change, for those with good footing in C++, is that string() will not be a function anymore. GML fans, don't panic: Saying string() will still work. The difference is purely technical; string() will be a constructor of a new datatype.
I had a problem with var that prohibited me from taking int as an argument type, which hindered efficiency. The new string class should fix that problem. It will be derived from std::string, with some additional namespace magic to prevent screwups.
If anyone really needs me to explain the details of that, I can, but I'm not going to unless someone asks.
In other other news, I'll be continuing development on Linux. Most of you know ENIGMA works on Linux now. Since the OS is more picky with things--for instance, file name capitalization--I think it'd be a good idea to move to it. And file names aren't the extent of it; big GCC, as in, the GCC which is not minimalist or for Windows and likely has the majority of GNU devs on its case, offers more precise error checking and warns on more things. Which is nice, as it prevents errors down the road.
Anyway, I'ma get back to working on the compiler. I have to find my new instance system and put it in the shell folder. After it's at a good stop point, I'm wiping the SVN and reuploading everything. (Makes it easier switching back and forth between platforms).
No news on ENIGMA's LibOGC frontend.
Cheers. A2h will hopefully make me edit this tomorrow. Maybe even post new.
2635
SHUPAER123'S HOME / Re: I LOVE GA/WIMOMACON
« on: July 01, 2009, 01:37:29 am »
I couldn't agree more. Until it's been five or six days. Because I only love GA / WiMoMaCon 1,000,000 times.
2636
Announcements / Re: Expression Evaluator complete.
« on: June 21, 2009, 09:26:04 pm »
Yoyo's going to be making everything, just ask them.
2637
Announcements / Re: Expression Evaluator complete.
« on: June 18, 2009, 09:02:26 pm »
I only replace them in if()'s and the like.
I find that a=b=c=0 is too damn useful to dispose of. I'll probably end up option-izing it.
I find that a=b=c=0 is too damn useful to dispose of. I'll probably end up option-izing it.
2638
Announcements / Re: Expression Evaluator complete.
« on: June 17, 2009, 09:20:53 pm »
Yeah, I didn't really put much thought into converting it to GML. I just flipped a couple macro values.
Either way, nice catch. Noted for whenever this is applied to debug mode. And since this evaluates just the expression part, not the actual assignment operator, it'll be as simple as replacing that error with treating it as a comparison.
Either way, nice catch. Noted for whenever this is applied to debug mode. And since this evaluates just the expression part, not the actual assignment operator, it'll be as simple as replacing that error with treating it as a comparison.
2639
Announcements / Expression Evaluator complete.
« on: June 16, 2009, 02:26:59 pm »
I'm pleased to inform that the expression evaluator is working just as I'd hoped.
I'd like it to have a public test.
There are two versions. The C++ one, and the GML one. The C++ one is for macros, and so does not allow strings or floats. (Numbers that aren't integers.) Also as per preprocessors, it doesn't allow casts. (Though, there is a cast system implemented.)
This means that 5/2 = 2.
The GML one does allow strings and floats. It should work just like you're used to.
Note that functions and variables aren't in yet. It's an expression evaluator. It's designed for #if. Variables will be treated as zero. I just overkilled it a bit so I could more easily make a full fledged interpreter later on.
Other changes include that ternary exists, and there are more than two string comparison operators.
(("str"=="str")?"true":"false")+"zor" is my favorite string test.
Also, note that single quotes are treated as numbers in C++, and I think I left them that way in the GML one. So 'str' is a number, "str" is a string.
This means one less step on my todo list. One more item checked off.
Those who wish to try it out can download it here:
Both as 7z / as zip
C++ as 7z / as zip
GML as 7z / as zip
When the window pops up, you are immediately allowed to type. You can clear the screen by typing c or cls, and close it by typing x. (And pressing enter.)
Anyway, I'm going back to the CFile parser now, which I've been told by many is the impossible task for one person with no tools. But I don't care what they think. ^_^
Also, feel free to keep guessing at the secret from last topic.
I'll be working.
I'd like it to have a public test.
There are two versions. The C++ one, and the GML one. The C++ one is for macros, and so does not allow strings or floats. (Numbers that aren't integers.) Also as per preprocessors, it doesn't allow casts. (Though, there is a cast system implemented.)
This means that 5/2 = 2.
The GML one does allow strings and floats. It should work just like you're used to.
Note that functions and variables aren't in yet. It's an expression evaluator. It's designed for #if. Variables will be treated as zero. I just overkilled it a bit so I could more easily make a full fledged interpreter later on.
Other changes include that ternary exists, and there are more than two string comparison operators.
(("str"=="str")?"true":"false")+"zor" is my favorite string test.
Also, note that single quotes are treated as numbers in C++, and I think I left them that way in the GML one. So 'str' is a number, "str" is a string.
This means one less step on my todo list. One more item checked off.
Those who wish to try it out can download it here:
Both as 7z / as zip
C++ as 7z / as zip
GML as 7z / as zip
When the window pops up, you are immediately allowed to type. You can clear the screen by typing c or cls, and close it by typing x. (And pressing enter.)
Anyway, I'm going back to the CFile parser now, which I've been told by many is the impossible task for one person with no tools. But I don't care what they think. ^_^
Also, feel free to keep guessing at the secret from last topic.
I'll be working.
2640
Issues Help Desk / Re: *solved* execute_string
« on: June 10, 2009, 10:47:47 am »
Sure you can, it just won't be as fast as if it were compiled. Still, though, it will be real time.
It does bring out some vulnerabilities, though, as a list will need to be kept of variables in the game, even if they are hashed.
It does bring out some vulnerabilities, though, as a list will need to be kept of variables in the game, even if they are hashed.
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 »