Show Posts
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.
46
I doubt anyone would disagree that ENIGMA needs arrays. What I'm proposing is that rather than inherit array syntax from C++, we take a page out of the JavaScript playbook and denote them with [].
I want to use [] for a couple reasons. First, of course, is that [1, 2, 3][1] looks neater than {1,2,3}[1]. That was a joke; I don't give a shit about that. What I want to allow is this sort of syntax:
Using {} for arrays, {x,y} would be ambiguous; it could be a new scope which uses x and y, or it could be our assignment array. There would be next to no way to distinguish the two, so it's out of the question if we want the assignment array.
As for the dynamics, when compiling to C, this is what it would look like:
In the [a,b,c]=array_func() case:
In the [a,b,c] = scalar_func() special case:
As for building an array, that's easy. Old ENIGMA can do that. [expression1, expression2, expression3] simply becomes this:
[snip=cpp](Array(3).put(0,expression1).put(1,expression2).put(2,expression3))[/snip]
Where [snip]Array(int N)[/snip] reserves N variants, and [snip]Array& Array::put(int, variant)[/snip] is the same as [snip]Array::operator[](int)::operator=(variant)[/snip].
I want to use [] for a couple reasons. First, of course, is that [1, 2, 3][1] looks neater than {1,2,3}[1]. That was a joke; I don't give a shit about that. What I want to allow is this sort of syntax:
Code: (EDL) [Select]
[x, y] = [y, x] // Switches the values of x and y
[x, y] = get_some_coordinates(); // Fetches a length-2 array of coordinates, assign
Using {} for arrays, {x,y} would be ambiguous; it could be a new scope which uses x and y, or it could be our assignment array. There would be next to no way to distinguish the two, so it's out of the question if we want the assignment array.
As for the dynamics, when compiling to C, this is what it would look like:
In the [a,b,c]=array_func() case:
Code: (cpp) [Select]
{
Array tmp = array_func(); // This is copied verbatim
switch (tmp.length) { default: // Array size is size_t; must be >= 0
case 3: c = tmp[3]; // Waterfall
case 2: b = tmp[2];
case 1: a = tmp[1];
case 0: ;
}
}
In the [a,b,c] = scalar_func() special case:
Code: (cpp) [Select]
c = b = a = scalar_func();
As for building an array, that's easy. Old ENIGMA can do that. [expression1, expression2, expression3] simply becomes this:
[snip=cpp](Array(3).put(0,expression1).put(1,expression2).put(2,expression3))[/snip]
Where [snip]Array(int N)[/snip] reserves N variants, and [snip]Array& Array::put(int, variant)[/snip] is the same as [snip]Array::operator[](int)::operator=(variant)[/snip].
47
Proposals / Preprocessors
« on: September 13, 2012, 11:13:41 am »
Since ENIGMA supports compilation on a wide variety of platforms, and soon, a small variety of languages, it is going to become necessary to give the user a way to deal with that.
Now, C++ gives a fine way of doing that: Preprocessors. The issue with C preprocessors is that they are ugly. They must be the first thing on a line, and must consume the entire line. In EDL, we'll want to fix that.
My proposal is that preprocessors be given by [snip]{{}}[/snip]. So, if you wanted a piece of code to run only on Mac, you'd use something like this:
That will bring up the game center on iOS, or something. Ask TGMG; I really have no clue about iOS.
Now, C++ gives a fine way of doing that: Preprocessors. The issue with C preprocessors is that they are ugly. They must be the first thing on a line, and must consume the entire line. In EDL, we'll want to fix that.
My proposal is that preprocessors be given by [snip]{{}}[/snip]. So, if you wanted a piece of code to run only on Mac, you'd use something like this:
Code: [Select]
{{if ENIGMA_Platform == "ios"}} gamecenter_initialize(); {{endif}} // Initialize the game center if we're on iOS
highscore_add(name, score);
That will bring up the game center on iOS, or something. Ask TGMG; I really have no clue about iOS.
48
Proposals / Definitions Resource
« on: September 13, 2012, 10:49:04 am »
LateralGM offers a script editor in ENIGMA settings which allows the user to specify C++ definitions. The issue is, there's only one instance, and it only supports C++. Later on, when ENIGMA supports other languages as the back end (which so far we only plan to be JavaScript), we will want another such resource. If this becomes a big part of ENIGMA, it may be frugal to offer definitions as a tabbed script resource which allows specifying definitions in each language. So one Definitions resource can contain a script full of C++, a script full of JavaScript, etc.
When you save a definitions script, a reparse will be run, and the definitions will become available to you from within EDL. It would be possible to export the definitions resource, and it would be saved with the EGM (as the existing definitions script is now).
When you save a definitions script, a reparse will be run, and the definitions will become available to you from within EDL. It would be possible to export the definitions resource, and it would be saved with the EGM (as the existing definitions script is now).
49
Proposals / Sprite sheets
« on: September 13, 2012, 10:43:25 am »
The way I see it, there are two good ways to do sprite sheets.
1) Have a sprite sheet resource, and have sprites optionally refer to a sprite sheet.
2) Re-use the directory system.
3) Let ENIGMA just cram them together based on which fit together the best; the user can tell ENIGMA not to put the sprite in a sheet.
4) Use option 1, but provide an "Automatic" in addition to a "None" which lets ENIGMA decide.
I'm undecided on this one. I don't think I need to elaborate very much on it, as the concept is very simple. For those who are unclear, a sprite sheet is a big texture containing all the sprites. It is useful in that it saves render time due to not having to bind a new texture every time a sprite is drawn (only when sprites are on a new sheet).
The question is, how do we want the user to be able to specify that? Is it prudent to keep sprite sheets as a separate resource, or would it be too much work on the user's part?
This needs handled eventually if we want ENIGMA to make happy on mobile devices which just don't have the memory for 32,000 little tiny PO2 textures.
1) Have a sprite sheet resource, and have sprites optionally refer to a sprite sheet.
2) Re-use the directory system.
3) Let ENIGMA just cram them together based on which fit together the best; the user can tell ENIGMA not to put the sprite in a sheet.
4) Use option 1, but provide an "Automatic" in addition to a "None" which lets ENIGMA decide.
I'm undecided on this one. I don't think I need to elaborate very much on it, as the concept is very simple. For those who are unclear, a sprite sheet is a big texture containing all the sprites. It is useful in that it saves render time due to not having to bind a new texture every time a sprite is drawn (only when sprites are on a new sheet).
The question is, how do we want the user to be able to specify that? Is it prudent to keep sprite sheets as a separate resource, or would it be too much work on the user's part?
This needs handled eventually if we want ENIGMA to make happy on mobile devices which just don't have the memory for 32,000 little tiny PO2 textures.
50
Announcements / Yet Another Renaissance
« on: September 13, 2012, 09:34:27 am »
I'm posting an announcement because people are really bad at finding buried topics on SMF. With JDI done and (mostly) working (I need to work out a problem on 32-bit machines), I am posting several proposals in the appropriate forum section.
One of them I posted early for the lulz. One of them's an old topic that still hasn't been dealt with; now might be a good time.
Dealing with nested statements: Named loops or numbered breaks?
Loading and unloading resources by name
Sprite sheets
Overworld resource
Definitions Resource
Preprocessors: {{}}
Arrays: [[1,2],[3,4]]
Static Sprites
Reintroduction of build mode
I don't have the time to post all these proposals at once. Check this topic frequently for more. (Or actually visit the Suggestions and Proposals board and see the list for yourself.)
One of them I posted early for the lulz. One of them's an old topic that still hasn't been dealt with; now might be a good time.
Dealing with nested statements: Named loops or numbered breaks?
Loading and unloading resources by name
Sprite sheets
Overworld resource
Definitions Resource
Preprocessors: {{}}
Arrays: [[1,2],[3,4]]
Static Sprites
Reintroduction of build mode
I don't have the time to post all these proposals at once. Check this topic frequently for more. (Or actually visit the Suggestions and Proposals board and see the list for yourself.)
51
Proposals / Resource group load/save functions
« on: September 13, 2012, 09:30:51 am »
The idea is simple in concept. GM/ENIGMA users often group objects which are related spatially or temporally in the resource tree. GM games are notorious for their huge RAM consumption, and ENIGMA games can only be so much better while operating in an arbitrary CPU/RAM use constraint. So, how do we propose a solution?
Simple. Allow selecting whether resource tree groups are preloaded or not, and give a method called [snip=EDL]resource_group_load("The name of the tree item")[/snip].
Basically, the resource group "Player" and "Enemies" — and don't lie, you've used groups by this name! — will be loaded up front, as will the resource group "Terrain" in simple games, or "Overworld 1" in more complicated games. When you need resources from the second overworld, you call [snip=EDL]resource_group_unload("Overworld 1"); resource_group_load("Overworld 2");[/snip].
Now, if you're afraid that will mean in-game load time, well, your fears are justified for extremely large games. But think of it this way—all that loading would be done at the same pace up front otherwise. You've just broken it into manageable segments at worst; no one is forcing you to call the unload() function.
To solidify the proposal, I am suggesting the following methods:
Perhaps later we will want to offer functions which narrow the search to individual resource tree items.
Along with tree storage, I would like to offer a function to fetch the ID of a resource by its name, and vice-versa, then allow loading or unloading an individual resource manually by ID. Those will follow later, and are not really the concern of this proposal.
What I need from Java: A way to mark groups as preloaded.
Simple. Allow selecting whether resource tree groups are preloaded or not, and give a method called [snip=EDL]resource_group_load("The name of the tree item")[/snip].
Basically, the resource group "Player" and "Enemies" — and don't lie, you've used groups by this name! — will be loaded up front, as will the resource group "Terrain" in simple games, or "Overworld 1" in more complicated games. When you need resources from the second overworld, you call [snip=EDL]resource_group_unload("Overworld 1"); resource_group_load("Overworld 2");[/snip].
Now, if you're afraid that will mean in-game load time, well, your fears are justified for extremely large games. But think of it this way—all that loading would be done at the same pace up front otherwise. You've just broken it into manageable segments at worst; no one is forcing you to call the unload() function.
To solidify the proposal, I am suggesting the following methods:
Code: (EDL) [Select]
/** Load groups of resources with the given name in the resource tree into memory.
The group id can be from any resource folder; all matching groups will be loaded.
To narrow the ID, the forward slash "/" can be used to denote nested groups.
Hence, the string "Overworld 1" will load all resources found in any group called
Overworld 1, while the string "Enemies/Overworld 1" will load only such a group
contained in a group called Enemies.
If a resource in the group is already loaded, no action is taken for it.
The function returns only when all resources in the group are loaded.
At that time, the function returns the number of matching groups loaded. */
void resource_group_load(string group_id);
/** Unload groups of resources with the given name in the resource tree from memory.
The resource matching dynamic is identical to that of resource_group_load.
Returns the number of groups unloaded. */
void resource_group_unload(string group_id);
/** Load groups of resources with the given name in the resource tree into memory.
Very similar to resource_group_load, except it performs all loading operations in a
new thread, returning immediately. */
void resource_group_load_thread(string group_id);
Perhaps later we will want to offer functions which narrow the search to individual resource tree items.
Along with tree storage, I would like to offer a function to fetch the ID of a resource by its name, and vice-versa, then allow loading or unloading an individual resource manually by ID. Those will follow later, and are not really the concern of this proposal.
What I need from Java: A way to mark groups as preloaded.
52
Proposals / Named loops vs numbered breaks
« on: September 08, 2012, 04:47:37 pm »Code: (EDL) [Select]
for (int i = 0; i < 10; ++i) {
for (int j = 0; j < 10; ++j) {
if (target[i][j])
break; // FUCK!
}
}Named Loops:
Code: (EDL) [Select]
HOLYFUCKIDONTKNOWWHATTONAMETHISLOOP: for (int i = 0; i < 10; ++i) {
for (int j = 0; j < 10; ++j) {
if (target[i][j])
break HOLYFUCKIDONTKNOWWHATTONAMETHISLOOP; // yay?
}
}Numbered breaks:
Code: (EDL) [Select]
for (int i = 0; i < 10; ++i) {
for (int j = 0; j < 10; ++j) {
if (target[i][j])
break 2; // (Y)
}
}
53
Announcements / What needs said
« on: August 08, 2012, 01:21:01 pm »
Okay, I think it's about time to answer the obvious question: Why are you so interested in a new parser?
The C parser needed fixed to get the project working again on Linux, due to changed headers. I decided that it would be a good time to do some re-thinking of the parser system in general.
A lot has changed since the project began, and not just with my views on what ENIGMA should be. I wanted ENIGMA to be free, fast, capable, and cross-platform from the start. In the time since then, Yoyo has set similar goals. They have proven to—as far as commercial organizations go—not be very capable of attaining those goals. However, one of the achievements they have made is getting Game Maker to work on every platform ENIGMA does. In fact, they've gone a step further and made it easy to get GM working on those platforms; presently, ENIGMA takes some finagling. In addition to working on those platforms, GM can export to JavaScript. This changes the rules of the game in itself.
With that turn of events, it is time to take Rusky's advice from two years ago. Well, not all of it. Some of it still makes me want to puke (and he no longer defends it, either). Unfortunately, I went ahead and threw the baby out with the bathwater on that one.
While originally, the plan for ENIGMA was to leave the bulk of interpretation to the host language (ie, C++), doing so has closed the doors to a number of language features.
I have designed JDI in such a way that ENIGMA will be able to reuse the vast majority of its code (in addition to using all of it to being the C++ backend).
What that means is the availability of this feature set:
The C parser needed fixed to get the project working again on Linux, due to changed headers. I decided that it would be a good time to do some re-thinking of the parser system in general.
A lot has changed since the project began, and not just with my views on what ENIGMA should be. I wanted ENIGMA to be free, fast, capable, and cross-platform from the start. In the time since then, Yoyo has set similar goals. They have proven to—as far as commercial organizations go—not be very capable of attaining those goals. However, one of the achievements they have made is getting Game Maker to work on every platform ENIGMA does. In fact, they've gone a step further and made it easy to get GM working on those platforms; presently, ENIGMA takes some finagling. In addition to working on those platforms, GM can export to JavaScript. This changes the rules of the game in itself.
With that turn of events, it is time to take Rusky's advice from two years ago. Well, not all of it. Some of it still makes me want to puke (and he no longer defends it, either). Unfortunately, I went ahead and threw the baby out with the bathwater on that one.
While originally, the plan for ENIGMA was to leave the bulk of interpretation to the host language (ie, C++), doing so has closed the doors to a number of language features.
I have designed JDI in such a way that ENIGMA will be able to reuse the vast majority of its code (in addition to using all of it to being the C++ backend).
What that means is the availability of this feature set:
- A unified language and corresponding AST whose backend language does not matter.
- Ability to export to any language from the backend.
- Ability to accept definitions from any language capable of reflection (and C++) as the frontend.
- Ability to declare getters and setters on certain variables
- The possibility of adding quad trees to collision systems by placing setters on x and y.
- The ability to assign a getter for variables such as bbox_left, object_count, etc.
- Ability to replace operators with methods
- No more div/mod class. Simple to cast division operands to double.
- Simple to implement boolean xor, [snip]^^[/snip].
- Ability to determine the type of any expression used in code.
- Full control of instance or class access through the dot operator.
- Ability to decide whether or not to cast operands to division (eg, determine whether the class has a division operator overloaded).
- Ability to regulate the ternary operator to ensure against ambiguity (eg, [snip=edl]var a = string_mode? "" : 0;[/snip]).
- Ability to resolve overloads of functions
- Ability to use a more efficient overload for varargs functions.
- Ability to pass additional arguments to certain functions.
- Ability to pass information about the current instance and other instance to functions implicitly.
- Replacement system for the central iterator system, which is founded on globals.
- Ability to call instance modifying functions from threads.
- Ability to pass information about the current instance and other instance to functions implicitly.
54
Announcements / k done
« on: July 21, 2012, 07:39:57 pm »
After some grueling moments of agony, I have the new system working—as far as I can tell—on Linux. TGMG is testing it for Mac, and then I guess I'll make it work on Windows and merge it in to the main branch.
I'm more concerned about Mac because, number one, its headers are older and very different, and number two, TGMG has a massive testing platform running on it which we can use for automated regression testing.
In other news, I fixed depth, too.
I'm more concerned about Mac because, number one, its headers are older and very different, and number two, TGMG has a massive testing platform running on it which we can use for automated regression testing.
In other news, I fixed depth, too.
55
Announcements / wtf am I doing
« on: July 15, 2012, 11:34:53 pm »
So I'm tearing up the compiler and installing JDI. In between it and ENIGMA will be a new class called language_adapter, which is basically an interface to let any language capable of reflection be exported by ENIGMA. That includes our friend, JavaScript, so TGMG can merge in whatever changes he's made to EGMJS all official-like.
For the time being, I am setting the understood type of all expressions to "int." I have no idea what this is going to do to the compilation sequence, but you straight GML users probably won't notice (Expression evaluation was not a huge part of general EDL).
Also, :: is dead until further notice, since no one used it and keeping it working would be a pain before I start integrating the heavy features that JDI presently lacks.
Moreover, most ironically, due to a hitch in the otherwise very strong similarity between JDI and the old C parser (API-wise), function pointer calls will still not work until then. But varargs should actually be fixed without me recoding any part of ENIGMA, which is neat.
For those who are interested, the following are notable differences:
Stunning compatibilities include the following:
When this all blows over, it'll either work magically or fail catastrophically. We shall see which! I'm looking forward to it.
Anyway, I have me my sledgehammer. I think it and I will have a nap, and then we'll be back to work.
For the time being, I am setting the understood type of all expressions to "int." I have no idea what this is going to do to the compilation sequence, but you straight GML users probably won't notice (Expression evaluation was not a huge part of general EDL).
Also, :: is dead until further notice, since no one used it and keeping it working would be a pain before I start integrating the heavy features that JDI presently lacks.
Moreover, most ironically, due to a hitch in the otherwise very strong similarity between JDI and the old C parser (API-wise), function pointer calls will still not work until then. But varargs should actually be fixed without me recoding any part of ENIGMA, which is neat.
For those who are interested, the following are notable differences:
- The main definition class no longer contains ENIGMA-tailored utility functions. These include the functions to get parameter count bounds and varargs positions. I have already recoded these at the global scope.
- JDI does not have a default context in which items can be looked up. I have created one locally in ENIGMA for the time being.
- The old parser used a central lookup system; one variable controlled which scope operations were performed in, and another variable controlled which scope :: access was done in (the latter having precedence when non-NULL). JDI does not use any such system.
Stunning compatibilities include the following:
- [snip]if (find_extname(name,0xFFFFFFFF))[/snip] ->[snip]else if ((d = main_context.get_global()->look_up(name)))[/snip]
- [snip]if (ext_retriever_var->flags & EXTFLAG_TYPENAME)[/snip] ->[snip]if (d->flags & jdi::DEF_TYPENAME)[/snip]
- [snip]macitr itm = macros.find(name)[/snip] ->[snip]jdi::macro_iter itm = main_context.get_macros().find(name)[/snip]
- [snip]itm->second.argc != -1[/snip] ->[snip]itm->second->argc != -1[/snip]
- All I had to do to integrate the new macro system was replace a block of shit with two function calls.
When this all blows over, it'll either work magically or fail catastrophically. We shall see which! I'm looking forward to it.
Anyway, I have me my sledgehammer. I think it and I will have a nap, and then we'll be back to work.
56
Announcements / Screw it
« on: July 13, 2012, 11:22:32 pm »
As I announced on the IRC, I resolved several issues with the parser and now the entirety of the STL will "parse" — "parse," in the sense that the parser successfully makes it from one end of the file to another without crashing, burning, or leaking. On that note, I have decided that the parser will be plugged into ENIGMA "as-is," in an effort to get the system working on new Linux distributions (and apparently on really new Windows systems).
This will begin tomorrow, after I make a few more attempts at correcting the existing errors.
In case you are worried, let me elaborate on the status of the parser. Its C support is flawless—I do not own a C header that it has, in testing, not successfully completed. It is easily capable enough to define all of ENIGMA's functions, types, and globals.
The parser does NOT have what it takes to give complicated template definitions. It has a good start, but nothing more. Its typename keyword handling is entirely broken because I was foolish enough to believe that I could handle partial specializations inline; I need to lex the shit and handle it at instantiation time. Also, it actually lacks support for overloading cast operators and operators (), [], new, delete, new[], and delete[]. Those are simple things I might fix before plugging it in.
You may gather that it has no definition for vector, or for string, save that it's a typedef of some basic_string instance; that basic_string is abstract, and that map is missing some three dozen members. This is probably related to the 6600 errors that are thrown as those headers parse. Probably.
Don't fret, though; that's a good thing. When I said "this parser won't break every time a new GCC is released," I said that seriously; not because this parser is perfect, but because this parser can take a beating. A huge beating.
For those who are interested in the actual error count, it was 6625.
http://dl.dropbox.com/u/1052740/enigma/demos/JDI/valgrind-2012-07-14.txt
The only worry I have right now—the above considered—is its performance on windows, where each console print costs 25 milliseconds. I'll probably have to pass in a custom error handler that doesn't print anything. No biggie, theoretically. I also need to get its file reading mechanism working on Windows.
Damn, I hate Windows.
This will begin tomorrow, after I make a few more attempts at correcting the existing errors.
In case you are worried, let me elaborate on the status of the parser. Its C support is flawless—I do not own a C header that it has, in testing, not successfully completed. It is easily capable enough to define all of ENIGMA's functions, types, and globals.
Code: [Select]
> d
Enter the item to define:
>> sin
double sin(double __x);
> d
Enter the item to define:
>> strstr
char *strstr(char *__haystack, const char *__needle);
> d
Enter the item to define:
>> malloc
void *malloc(size_t __size);
> d
Enter the item to define:
>> sprintf
int sprintf(char *__s, const char *__format, ...);
> d
Enter the item to define:
>> fwrite
size_t fwrite(const void *__ptr, size_t __size, size_t __n, FILE *__s);The parser does NOT have what it takes to give complicated template definitions. It has a good start, but nothing more. Its typename keyword handling is entirely broken because I was foolish enough to believe that I could handle partial specializations inline; I need to lex the shit and handle it at instantiation time. Also, it actually lacks support for overloading cast operators and operators (), [], new, delete, new[], and delete[]. Those are simple things I might fix before plugging it in.
Code: [Select]
> d
Enter the item to define:
>> std::vector
No `vector' found in scope `std'
> d
Enter the item to define:
>> std::string
typedef basic_string string;
> d
Enter the item to define:
>> std::basic_string
template<typename _CharT, typename _Traits = char_traits, typename _Alloc = allocator> class basic_string;
> d
Enter the item to define:
>> std::map
template<typename _Key, typename _Tp, typename _Compare = less, typename _Alloc = allocator> class map
{
value_compare _Alloc;
typedef value_type _Alloc_value_type;
value_compare _Compare;
value_compare _Key;
value_compare _Tp;
typedef _Alloc allocator_type;
typedef _Compare key_compare;
typedef _Key key_type;
typedef _Tp mapped_type;
class value_comparepublic binary_function
{
}
typedef pair value_type;
}You may gather that it has no definition for vector, or for string, save that it's a typedef of some basic_string instance; that basic_string is abstract, and that map is missing some three dozen members. This is probably related to the 6600 errors that are thrown as those headers parse. Probably.
Don't fret, though; that's a good thing. When I said "this parser won't break every time a new GCC is released," I said that seriously; not because this parser is perfect, but because this parser can take a beating. A huge beating.
For those who are interested in the actual error count, it was 6625.
http://dl.dropbox.com/u/1052740/enigma/demos/JDI/valgrind-2012-07-14.txt
The only worry I have right now—the above considered—is its performance on windows, where each console print costs 25 milliseconds. I'll probably have to pass in a custom error handler that doesn't print anything. No biggie, theoretically. I also need to get its file reading mechanism working on Windows.
Damn, I hate Windows.
57
Announcements / Das Newspost
« on: July 11, 2012, 12:10:16 am »
I'm beginning to realize I'm keeping you people in the dark about what's going on with my progress, aside from the ticker at the top that shows commits.
People ask me to put a number to things; I can't give a date, but I can tell you that I'm on the last section of my to-do list, as far as I know, and this is how it stands:
I am [bubble=red]
650/8587
[/bubble] done with the last segment of the new parser.
That is [bubble]
7.57%
[/bubble].
I will update this newspost as that number changes.
Archive:
2012/07/12 11:18:19 - 566
2012/07/12 03:04:14 - 590
People ask me to put a number to things; I can't give a date, but I can tell you that I'm on the last section of my to-do list, as far as I know, and this is how it stands:
I am [bubble=red]
650/8587
[/bubble] done with the last segment of the new parser.
That is [bubble]
7.57%
[/bubble].
I will update this newspost as that number changes.
Archive:
2012/07/12 11:18:19 - 566
2012/07/12 03:04:14 - 590
58
Announcements / Parser Progress
« on: June 16, 2012, 06:14:10 pm »
I've been out of school now for a week, and have finally been able to work on ENIGMA again. In that time, I have made some significant progress on the upgraded C parser.
Given the following input code:
Pretty great, right? No. Not pretty great. That's 34 seconds, you ding-dong.
The good news is, without Valgrind (a very awesome debugger) attached, it runs a bit faster: Parse finished in 325934 microseconds.
So, about 300 milliseconds. Not bad, really. Better news is, without rendering all parsed trees to SVG files, it operates faster still:
Parse finished in 219077 microseconds.
So about 219 milliseconds. Basically happy with that? Well, if not, you can use the parser in release mode without it tossing around debug information and with optimizations turned on: Parse finished in 97204 microseconds.
Just under 100 milliseconds. Which is where I call it "Good enough." Maybe I'll do some profiling later.
Anyway, all this is pretty good news; you might be asking, where's the bad news? Bad news is, only one of those headers had any C++ in it, and that'd be pthread.h. The parser's C++ support is only just now being filled in, and I don't have a reasonably accurate ETA on that functionality. I'm thinking it'll be working sooner than later, but only time (and further work) will tell. Fortunately, only Linux users are affected by bugs in the old parser (which would probably cause parse to fail on some of the above headers).
Anyway, I'm going to get back to work. Just a heads-up, and an "I'm still alive" deal.
PS: Millisecond times are estimates, only. Given varying processors, YMMV, not to mention that times fluctuate to ±5 milliseconds even locally on consecutive runs. The release mode time actually varies from about 93 milliseconds to 102 milliseconds here.
IsmAvatar also has some less happy news (in her words):
When one door closes, another door opens. In this case, there's a bit of reversal.
I have started a full-time programming job (I enjoy it, in case you were wondering). I will not be able to spend nearly as much time with LateralGM and the Plugin as I have in the past, and am taking a major step back away from this project. I will still be watching intently and giving my feedback, and periodically helping out with various projects (like some refactoring of the channel bots), and I will continue to fulfill my administrative duties and oversee the LateralGM side of the project (and gladly assisting anyone wishing to learn the internals or develop for it), but I will scarcely be developing. My major roles are complete at this point. I've given you a working product. Now it's time for other people to step in and polish it off.
Again, I'll be glad to help anyone who's trying to learn the internals or develop for it or whatever. Catch me on IRC, email me, or whatever.
Also, in about a month's time, my boyfriend and I will be moving in together. This will add another clamp on my free time, as I understandably like spending time with him.
I would say that I wish you guys good luck, but unfortunately you can't shake me that easily. I'm still sticking around and will continue to serve as the administrative cheerleader and GM Format gatekeeper. So I guess I'll just say: carry on.
Given the following input code:
Code: (CPP) [Select]
#include <GL/gl.h>
#include <GL/glu.h>
#include <ncurses.h>
#include <X11/Xlib.h>
#include <AL/al.h>
#include <zlib.h>
#include <stdio.h> //printf, NULL
#include <stdlib.h> //malloc
#include <unistd.h> //usleep
#include <time.h> //clock
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <float.h>
#include <iso646.h>
#include <math.h>
#include <locale.h>
#include <stdarg.h>
#include <wchar.h>
#include <string.h>
#include <stdbool.h>
#include <stddef.h>
#include <malloc.h>
#include <cpio.h>
#include <dirent.h>
#include <grp.h>
#include <pwd.h>
#include <sys/ipc.h>
#include <sys/msg.h>
#include <tar.h>
#include <termios.h>
#include <utime.h>
#include <unistd.h>
#include <stdint.h>
#include <time.h>
#include <fcntl.h>
#include <sys/sem.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <signal.h>
#include <setjmp.h>
#include <inttypes.h>
#include <sys/utsname.h>
// Once affected by lack of '?' operator token
#include <ctype.h>
#include <wctype.h>
#include <limits.h>
#include <assert.h>
// Once affected by lack of support for public/private/protected, and by lack of support for constructors.
#include <pthread.h>
#include <sys/stat.h>
#include <sys/time.h>
#include <fenv.h>
#include <tgmath.h>
#include <complex.h>
The parse finished in 34348101 microseconds, 0 errors, 0 warnings.Pretty great, right? No. Not pretty great. That's 34 seconds, you ding-dong.
The good news is, without Valgrind (a very awesome debugger) attached, it runs a bit faster: Parse finished in 325934 microseconds.
So, about 300 milliseconds. Not bad, really. Better news is, without rendering all parsed trees to SVG files, it operates faster still:
Parse finished in 219077 microseconds.
So about 219 milliseconds. Basically happy with that? Well, if not, you can use the parser in release mode without it tossing around debug information and with optimizations turned on: Parse finished in 97204 microseconds.
Just under 100 milliseconds. Which is where I call it "Good enough." Maybe I'll do some profiling later.
Anyway, all this is pretty good news; you might be asking, where's the bad news? Bad news is, only one of those headers had any C++ in it, and that'd be pthread.h. The parser's C++ support is only just now being filled in, and I don't have a reasonably accurate ETA on that functionality. I'm thinking it'll be working sooner than later, but only time (and further work) will tell. Fortunately, only Linux users are affected by bugs in the old parser (which would probably cause parse to fail on some of the above headers).
Anyway, I'm going to get back to work. Just a heads-up, and an "I'm still alive" deal.
PS: Millisecond times are estimates, only. Given varying processors, YMMV, not to mention that times fluctuate to ±5 milliseconds even locally on consecutive runs. The release mode time actually varies from about 93 milliseconds to 102 milliseconds here.
IsmAvatar also has some less happy news (in her words):
When one door closes, another door opens. In this case, there's a bit of reversal.
I have started a full-time programming job (I enjoy it, in case you were wondering). I will not be able to spend nearly as much time with LateralGM and the Plugin as I have in the past, and am taking a major step back away from this project. I will still be watching intently and giving my feedback, and periodically helping out with various projects (like some refactoring of the channel bots), and I will continue to fulfill my administrative duties and oversee the LateralGM side of the project (and gladly assisting anyone wishing to learn the internals or develop for it), but I will scarcely be developing. My major roles are complete at this point. I've given you a working product. Now it's time for other people to step in and polish it off.
Again, I'll be glad to help anyone who's trying to learn the internals or develop for it or whatever. Catch me on IRC, email me, or whatever.
Also, in about a month's time, my boyfriend and I will be moving in together. This will add another clamp on my free time, as I understandably like spending time with him.
I would say that I wish you guys good luck, but unfortunately you can't shake me that easily. I'm still sticking around and will continue to serve as the administrative cheerleader and GM Format gatekeeper. So I guess I'll just say: carry on.
59
Announcements / Windows GIT patch
« on: May 14, 2012, 02:35:56 am »
Since polygone is decidedly a whiny bitch, and TGMG goes AWOL every time I hint at this idea, I have gone and compiled a patch file which can be extracted over the git repository on Windows to make everything run as it did before the migration--almost.
The patch can be downloaded here:
http://dl.dropbox.com/u/1052740/WinPatch.7z
You can download the git repository as a zip archive from the GitHub page. It is the button that has a picture of a cloud with an arrow pointing down out of it, that says "ZIP" next to it. You would have to be polygone to miss it.
Anyway, this patch archive is by no means complete. It contains the following:
This means that the following must still be done at some point by somebody:
Anyway, I'm tired. So I think I'll take the next three minutes to rant about polygone.
You see, the reason I wnt ahead and did this is because polygone was pissing and moaning about how someone needs to "fix" the git repository. What no one here seems to understand is that the git repository is not broken.. Nor was it before I assembled this patch. There were three reasons I modified the git repository while making this patch:
That said, let me reiterate: The Git repository is not broken. The reason we are having these release issues is because no one can come up with a good place to put binary files, so everyone just cries and throws a tizzy instead of obtaining them for themselves. In actuality, the problem was so minuscule that even cheeseboy could solve it with his installer zip.
Now, that zip of cheeseboy's did have an issue that Rusky introduced when he decided there was no reason we would ever need a custom ALURE build. You see, Rusky lives in this ideal world where every software component on the internet is specially tailored to fit every possible need. Back in the real world, however, people like dazappa just want their game to be self-contained, and ALURE/AL are not conducive to that. So provisions had to be made. I have added to this patch a detailed set of steps followed to get from the latest version of ALURE distributed on KittyCat's website to the version you see shipped with ENIGMA. If anyone deletes that again, I will track him or her down and break every bone in every finger he or she possesses individually, using two spoons.
The moral of this story is, being a whiny bitch might actually annoy Josh into doing something.
inb4 polygone/HaRRi have some stupid problem with the patch.
The patch can be downloaded here:
http://dl.dropbox.com/u/1052740/WinPatch.7z
You can download the git repository as a zip archive from the GitHub page. It is the button that has a picture of a cloud with an arrow pointing down out of it, that says "ZIP" next to it. You would have to be polygone to miss it.
Anyway, this patch archive is by no means complete. It contains the following:
- The ENIGMA.exe binary.
- The LateralGM binary.
- The ENIGMA plugin and JNA helper plugin.
- The ALURE source, and the necessary configuration files to build it alongside ENIGMA and patch OpenAL into the EXEs.
- Pre-built static libraries for libdumb, libvorbisfile, libvorbis, libogg, libzlib, and libffi.
This means that the following must still be done at some point by somebody:
- Modify ALURE's makefile rule to rebuild on file update (I kind of just threw it together)
- Modify the codecs to once again build alongside ENIGMA, as ALURE does.
- Modify zlib and libffi to build alongside ENIGMA, or include their 64bit equivalents.
- Tend that special something I forgot to do that will ever elude developers and bite users in the ass.
Anyway, I'm tired. So I think I'll take the next three minutes to rant about polygone.
You see, the reason I wnt ahead and did this is because polygone was pissing and moaning about how someone needs to "fix" the git repository. What no one here seems to understand is that the git repository is not broken.. Nor was it before I assembled this patch. There were three reasons I modified the git repository while making this patch:
- That idiot cheeseboy committed the Windows GCC.ey, which varies from computer to computer. I needed to change two lines in it.
- The newest ALURE calls its init statically, before main() starts, and was causing a segfault, so I needed to debug.
- CXXFLAGS weren't getting set in debug mode, a problem that affects Git, SVN, Windows, and Linux alike.
That said, let me reiterate: The Git repository is not broken. The reason we are having these release issues is because no one can come up with a good place to put binary files, so everyone just cries and throws a tizzy instead of obtaining them for themselves. In actuality, the problem was so minuscule that even cheeseboy could solve it with his installer zip.
Now, that zip of cheeseboy's did have an issue that Rusky introduced when he decided there was no reason we would ever need a custom ALURE build. You see, Rusky lives in this ideal world where every software component on the internet is specially tailored to fit every possible need. Back in the real world, however, people like dazappa just want their game to be self-contained, and ALURE/AL are not conducive to that. So provisions had to be made. I have added to this patch a detailed set of steps followed to get from the latest version of ALURE distributed on KittyCat's website to the version you see shipped with ENIGMA. If anyone deletes that again, I will track him or her down and break every bone in every finger he or she possesses individually, using two spoons.
The moral of this story is, being a whiny bitch might actually annoy Josh into doing something.
inb4 polygone/HaRRi have some stupid problem with the patch.
60
Announcements / New members
« on: March 23, 2012, 09:33:01 am »
Thanks to the efforts of polygone, our little forum has recently acquired three new members!
If you have tried creating an account recently, see the notice at the bottom of this message.
Two of them are disgusting spam bots.
[bubble]Username: RisMilo1984
Posts: 0 (N/A per day)
Email: chardricky2012@gmail.com
Age: N/A
Date Registered: Today at 05:23:24 AM
IP: 180.234.242.14
Hostname: AWBL242-14.qubee.com.bd
Last Active: Today at 05:23:28 AM
[/bubble]
[bubble]Username: actonpoul113
Posts: 0 (0 per day)
Email: actonpoul113@live.com
Age: N/A
Date Registered: March 21, 2012, 09:32:55 AM
IP: 182.178.163.177
Hostname:
Last Active: March 21, 2012, 09:36:51 AM
[/bubble]
The other one's legitimate. You may know him as fresnobob or, on the IRC, as mrboduma. Welcome to ENIGMA, fresnobob.
Now, you may be asking, how did we manage to acquire two spam bots? Didn't Josh spam proof the forum a year ago?
To answer the latter, yes! He did! Now, how to answer the former?
Well, it seems that while our good friend polyfuck was disabling the email verification, which I don't give a damn about, he also decided that my verification questions are too hard. You see, they actually require a brain to answer! (Rather than a 1"×1"×1/16" collection of tin, zinc, copper, gold, and silicon, I mean.)
Unfortunately, it turns out—and, get this—it turns out, if your questions don't require a fucking brain to answer, then—and pay attention to this part—things which do not have brains will be able to answer them.
So I've went and made another executive decision here—and I do hope you'll forgive me—and I went and put the old questions back.
For your further enlightenment, these were the questions that do not require a brain to answer:
These are questions that do require a brain to answer:
(I throw in the yellow fruit one too so registrants can feel creative; it accepts fifty answers, all of which have thus far been "banana")
SO. If anyone here feels they are incapable of answering the above questions, please leave a reply and I will personally ban you from the forum for all eternity.
Why does this piss me off? Because commercialism is one thing. Spamming links everywhere to steal rank from people who deserve it—DESERVE it, in the capitalistic sense, based on REPUTATION, the concept by which capitalism FUNCTIONS—is, in my book, a pretty serious crime.
Further, I don't even like the fucking pizza ads people stick under my windshield wipers. I make it a point not to visit any restaurant that does that. If you want to stand outside your restaurant and hold up a sign about how great your pizza is, that's great! If you want to do that in a public place, that's fine too! If I am uninterested, I will simply ignore your sign, or maybe I'll decide I'm rather in the mood for pizza after all, and that your effort won me over. If you tie a note to a brick about your pizza and smash it through my window, I will probably by pissed at you for it.
Of course, I also made it so registrants who have not made a post cannot set signatures, avatars, or anything else that could subtly be used to suck page rank out of everything. So in reality, no harm was done by these bots joining. Save for some kilobyte of extra crap in the database, which is negligible. I just happen to like yelling at polyfuck in public.
muahahahahaha
Notice to those who have recently attempted to register:
I found some 20 accounts "awaiting activation" from the past month or so. I just went ahead and activated them all, including duplicates. That said, if you have attempted to register here recently and were unable to activate, I have manually activated all outstanding accounts from within the past year. If you registered multiple, go ahead and use whichever account you like. We'll delete the unused ones in five years or so.
(Admins are not notified by the forum software when a member requests activation; it gets added to a queue somewhere that no one can see until we stumble upon it. When no one is on the queue, it is invisible to admins.)
If you have tried creating an account recently, see the notice at the bottom of this message.
Two of them are disgusting spam bots.
[bubble]Username: RisMilo1984
Posts: 0 (N/A per day)
Email: chardricky2012@gmail.com
Age: N/A
Date Registered: Today at 05:23:24 AM
IP: 180.234.242.14
Hostname: AWBL242-14.qubee.com.bd
Last Active: Today at 05:23:28 AM
[/bubble]
[bubble]Username: actonpoul113
Posts: 0 (0 per day)
Email: actonpoul113@live.com
Age: N/A
Date Registered: March 21, 2012, 09:32:55 AM
IP: 182.178.163.177
Hostname:
Last Active: March 21, 2012, 09:36:51 AM
[/bubble]
The other one's legitimate. You may know him as fresnobob or, on the IRC, as mrboduma. Welcome to ENIGMA, fresnobob.
Now, you may be asking, how did we manage to acquire two spam bots? Didn't Josh spam proof the forum a year ago?
To answer the latter, yes! He did! Now, how to answer the former?
Well, it seems that while our good friend polyfuck was disabling the email verification, which I don't give a damn about, he also decided that my verification questions are too hard. You see, they actually require a brain to answer! (Rather than a 1"×1"×1/16" collection of tin, zinc, copper, gold, and silicon, I mean.)
Unfortunately, it turns out—and, get this—it turns out, if your questions don't require a fucking brain to answer, then—and pay attention to this part—things which do not have brains will be able to answer them.
So I've went and made another executive decision here—and I do hope you'll forgive me—and I went and put the old questions back.
For your further enlightenment, these were the questions that do not require a brain to answer:
- What is 5 + 3? :
- Name a yellow fruit:
These are questions that do require a brain to answer:
- Name one of the project leaders here (if you read the last page, you should know this):
- Type the name of the forum backwards (Six letters):
(I throw in the yellow fruit one too so registrants can feel creative; it accepts fifty answers, all of which have thus far been "banana")
SO. If anyone here feels they are incapable of answering the above questions, please leave a reply and I will personally ban you from the forum for all eternity.
Why does this piss me off? Because commercialism is one thing. Spamming links everywhere to steal rank from people who deserve it—DESERVE it, in the capitalistic sense, based on REPUTATION, the concept by which capitalism FUNCTIONS—is, in my book, a pretty serious crime.
Further, I don't even like the fucking pizza ads people stick under my windshield wipers. I make it a point not to visit any restaurant that does that. If you want to stand outside your restaurant and hold up a sign about how great your pizza is, that's great! If you want to do that in a public place, that's fine too! If I am uninterested, I will simply ignore your sign, or maybe I'll decide I'm rather in the mood for pizza after all, and that your effort won me over. If you tie a note to a brick about your pizza and smash it through my window, I will probably by pissed at you for it.
Of course, I also made it so registrants who have not made a post cannot set signatures, avatars, or anything else that could subtly be used to suck page rank out of everything. So in reality, no harm was done by these bots joining. Save for some kilobyte of extra crap in the database, which is negligible. I just happen to like yelling at polyfuck in public.
muahahahahaha
Notice to those who have recently attempted to register:
I found some 20 accounts "awaiting activation" from the past month or so. I just went ahead and activated them all, including duplicates. That said, if you have attempted to register here recently and were unable to activate, I have manually activated all outstanding accounts from within the past year. If you registered multiple, go ahead and use whichever account you like. We'll delete the unused ones in five years or so.
(Admins are not notified by the forum software when a member requests activation; it gets added to a queue somewhere that no one can see until we stumble upon it. When no one is on the queue, it is invisible to admins.)