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 »
1831
Issues Help Desk / Re: Stuff referencing each other.
« on: July 10, 2010, 11:33:31 pm »
Returning incomplete types seems sketchy to me. Try returning a pointer, that's guaranteed to never fail, however incomplete. But I'm not sure, since you're not implementing opposite() immediately, why it wouldn't work.
1832
Announcements / Re: Worth Mentioning
« on: July 10, 2010, 06:30:08 pm »
Correct. I intend to eventually deploy tricks like your precompiled headers, and it may require source files for each object in large games, meaning more existing object files to use. But that's later.
Right now, there is one main source file that includes many code-generated headers. Each of these implements a different chunk of user code; one for object events, one for event code, one for scripts, one for globally defined variables, one for room codes, one for room data (In array format; will actually need some rethinking for improved compile speed and possibly loading time)... the list goes on.
When ENIGMA allows for larger games, it may become necessary to compile objects in their own sources, as I mentioned, which will call for precompiled headers as well. We'll see then what's required. When that time comes, the majority of the main source file will be made into a header (precompiled, I hope) and included from each of the object sources. I'll probably always leave room creation code in the same source.
If and when I do separate them, there'll be some organizing and double checking to prevent linker errors. Otherwise, to make it flawless, I'd have to recompile them all anyway, which would be very inefficient. There'd also be the itty bitty problem of having to recompile them all anyway each time you switch games. Fortunately, the main system code never needs recompiled (unless you check out new versions, of course, in which case the makefile will take care of it automatically because it's cool like that).
Right now, there is one main source file that includes many code-generated headers. Each of these implements a different chunk of user code; one for object events, one for event code, one for scripts, one for globally defined variables, one for room codes, one for room data (In array format; will actually need some rethinking for improved compile speed and possibly loading time)... the list goes on.
When ENIGMA allows for larger games, it may become necessary to compile objects in their own sources, as I mentioned, which will call for precompiled headers as well. We'll see then what's required. When that time comes, the majority of the main source file will be made into a header (precompiled, I hope) and included from each of the object sources. I'll probably always leave room creation code in the same source.
If and when I do separate them, there'll be some organizing and double checking to prevent linker errors. Otherwise, to make it flawless, I'd have to recompile them all anyway, which would be very inefficient. There'd also be the itty bitty problem of having to recompile them all anyway each time you switch games. Fortunately, the main system code never needs recompiled (unless you check out new versions, of course, in which case the makefile will take care of it automatically because it's cool like that).
1833
Announcements / Re: Worth Mentioning
« on: July 10, 2010, 03:29:34 pm »
Luis: Yes, this is a simple particle drawing executable (Compile time increase is immeasurable compiling things like "Click the Clown"). Some object files were already compiled; they always will be. Most of ENIGMA's code is modular and independent of the main source file. More of it has been separated and is yet to be thanks to the new instance system and the tiered local system. This is the compile time users will be seeing. The important thing is that it's faster than GM can export and run its own executables. I intend to keep it that way.
1834
Announcements / Worth Mentioning
« on: July 10, 2010, 08:58:21 am »
As a by-the-way sort of deal, I've reduced ENIGMA's compile time to roughly two seconds on this old computer. Compile, link, and run took 2.75 seconds. This means I pressed "run," and in 2.75 seconds (minus my reflex time on the stopwatch), the game window was there.
On my laptop, a newish (less than two years) dual core with decent specs by today's standards, the process takes 1.4 seconds. Again not accounting for my reflexes.
So all-in-all, I'm pretty happy about that.
I've gotten a few bug reports via the tracker and have fixed most of them that were for me. More will follow, but I've been busy these last few days; today should be my last busy day. I'll be moving air conditioners around; don't ask. The most immediate thing I'll be working on is my type resolver. The only reason it's not finished is the amount of crap I've had to deal with lately.
So. Enjoy the new compile time. I believe it can later be reduced further; we'll see.
It's also worth mentioning that I could use someones to verify that all the math functions work properly (they are included directly from the C library, mostly; ambiguity is quite possible with var's many legal casts). The bessel_* functions may or may not work; I'll figure that out eventually. Logically, they shouldn't; I renamed the symbols in the header without renaming them in whatever library they are implemented in. But who knows? Also, if someone is feeling really bored, they could make sure that all the operators work on var. They are largely code-generated, so slight error can be catastrophic. For instance, division once returned zero consistently. And freezway found an ambiguity in variant += var. There's a lot of boring testing to do with those.
On my laptop, a newish (less than two years) dual core with decent specs by today's standards, the process takes 1.4 seconds. Again not accounting for my reflexes.
So all-in-all, I'm pretty happy about that.
I've gotten a few bug reports via the tracker and have fixed most of them that were for me. More will follow, but I've been busy these last few days; today should be my last busy day. I'll be moving air conditioners around; don't ask. The most immediate thing I'll be working on is my type resolver. The only reason it's not finished is the amount of crap I've had to deal with lately.
So. Enjoy the new compile time. I believe it can later be reduced further; we'll see.
It's also worth mentioning that I could use someones to verify that all the math functions work properly (they are included directly from the C library, mostly; ambiguity is quite possible with var's many legal casts). The bessel_* functions may or may not work; I'll figure that out eventually. Logically, they shouldn't; I renamed the symbols in the header without renaming them in whatever library they are implemented in. But who knows? Also, if someone is feeling really bored, they could make sure that all the operators work on var. They are largely code-generated, so slight error can be catastrophic. For instance, division once returned zero consistently. And freezway found an ambiguity in variant += var. There's a lot of boring testing to do with those.
1835
Announcements / Re: Progress
« on: July 08, 2010, 07:35:19 pm »
Screw you. You can have it when I'm 100% happy with the type resolver. Or I cuss it out and abandon it, then commit this part in disgust.
1836
Announcements / Progress
« on: July 08, 2010, 12:01:23 pm »
I'm so happy with a couple changes I've made and am making.
First off, I'm proud to announce that standard templates are now completely available to ENIGMA users.
That's right: ENIGMA now correctly defaults all non-defaulted template parameters (as in, template parameters that are not already optional according to the C++ library) to variant. That means that once Ism and I are finished coordinating our new "Definitions" resource (previously "WhiteSpace"... we're still working on a catchy name) you will be able to #include <map>, use it, and use codes like this:
That's right: with the implementation of var4, comparison operators are correctly implemented for all types and mirrored const. This makes them capable of complete interaction with the standard template library. GM's ds_* functions are officially toilet food in comparison.
Furthermore, map isn't exactly necessary for large numbers. Var4 also implements Lua's algorithm for fast, sparse arrays. This introduces a number of nice properties:
How can this be efficient? It's simple. a[0..127] operates in O(1), because that's how much space was allocated for the array. a[128] operates in either O(1) or O(n), depending on how your system resources are doing. a[256..INT_MAX] operates in O(log(N)), as it relies on a map for the lookup. (This will hopefully be replaced with a sparse hash map at some point).
Currently the system is functional, but not finished. Var4's lua_table<> needs to ensure that elements can hop data structure when the array part is resized. Templates need field tested, which will happen after my latest renovation: the dot operator.
Because C++ introduces structures and classes which I do not want to alienate, I have to take special care to ensure that the left-hand side of the dot is not an instance of a structure. This requires a type resolver, which I hope to complete inside 400 lines. We'll see. Basically, it will return the type of the expression that precedes the dot. I intend for the following to happen:
If it's an instance of a class, check for a member by name of the variable to the right hand side of the dot. If the member exists, ignore the dot. Possibly, if the class was actually a pointer, not a direct reference, replace the dot with ->. C++ should have done this from square one; I see no use for pointer.member. If no member was found, or if the type was scalar, replace the dot with an integer-based accessor function and record that the global was indeed accessed that way so optimizations can be done later. Also try to warn if it was a class without a member and without operator int() or some other scalar that can be cast easily. Perhaps it should be up to ENIGMA to find an appropriate cast path, such as int(var()).
Anyway, just something to think about.
Back to work, ciao for now.
First off, I'm proud to announce that standard templates are now completely available to ENIGMA users.
Code: (C++) [Select]
map a; // is the same as...
map<> a; // is the same as...
map <variant> a; // is the same as...
map <variant,variant> a;
That's right: ENIGMA now correctly defaults all non-defaulted template parameters (as in, template parameters that are not already optional according to the C++ library) to variant. That means that once Ism and I are finished coordinating our new "Definitions" resource (previously "WhiteSpace"... we're still working on a catchy name) you will be able to #include <map>, use it, and use codes like this:
Code: (EDL) [Select]
map a;
a[100] = "one hundred";
a[15625682900000000.0] = "lol, big float";
a[3.141592653589793238] = "pie";
a["pi"] = 3.14;
That's right: with the implementation of var4, comparison operators are correctly implemented for all types and mirrored const. This makes them capable of complete interaction with the standard template library. GM's ds_* functions are officially toilet food in comparison.
Furthermore, map isn't exactly necessary for large numbers. Var4 also implements Lua's algorithm for fast, sparse arrays. This introduces a number of nice properties:
Code: (EDL) [Select]
var a = 0;
for (int i=0; i<100; i++) a[i] = i;
a[1000000000] = "one billion";
How can this be efficient? It's simple. a[0..127] operates in O(1), because that's how much space was allocated for the array. a[128] operates in either O(1) or O(n), depending on how your system resources are doing. a[256..INT_MAX] operates in O(log(N)), as it relies on a map for the lookup. (This will hopefully be replaced with a sparse hash map at some point).
Currently the system is functional, but not finished. Var4's lua_table<> needs to ensure that elements can hop data structure when the array part is resized. Templates need field tested, which will happen after my latest renovation: the dot operator.
Because C++ introduces structures and classes which I do not want to alienate, I have to take special care to ensure that the left-hand side of the dot is not an instance of a structure. This requires a type resolver, which I hope to complete inside 400 lines. We'll see. Basically, it will return the type of the expression that precedes the dot. I intend for the following to happen:
If it's an instance of a class, check for a member by name of the variable to the right hand side of the dot. If the member exists, ignore the dot. Possibly, if the class was actually a pointer, not a direct reference, replace the dot with ->. C++ should have done this from square one; I see no use for pointer.member. If no member was found, or if the type was scalar, replace the dot with an integer-based accessor function and record that the global was indeed accessed that way so optimizations can be done later. Also try to warn if it was a class without a member and without operator int() or some other scalar that can be cast easily. Perhaps it should be up to ENIGMA to find an appropriate cast path, such as int(var()).
Anyway, just something to think about.
Back to work, ciao for now.
1837
Announcements / Re: Bugtracker trial
« on: July 08, 2010, 11:33:45 am »
General: I believe a2h has or was going to add categories, certainly. Perhaps some will want to have a separate category for suggestions. It'd probably be good if he let the intermediate user (as in, whatever we are to Simple Machines: not the creator, not the end-end-user) change the labels of each severity. That's just if he wants to put it out there for the public, as I know is his intention.
1: Vote for bugs. I assume you mean "This affects me, too!", in which case, yeah. Good idea.
3: There is an Assigned to: field.
6: That's kind of silly; why not just paste any concerned URLs into the body of the bug report?
I like the idea of and have no further comment on suggestions 2, 4, 5, and 7.
But personally, I'm happy with it right now. So he can take his sweet time on that extra glittery stuff. As long as I can mark a bug "solved," which I've not yet been given a chance to test.
1: Vote for bugs. I assume you mean "This affects me, too!", in which case, yeah. Good idea.
3: There is an Assigned to: field.
6: That's kind of silly; why not just paste any concerned URLs into the body of the bug report?
I like the idea of and have no further comment on suggestions 2, 4, 5, and 7.
But personally, I'm happy with it right now. So he can take his sweet time on that extra glittery stuff. As long as I can mark a bug "solved," which I've not yet been given a chance to test.
1838
Announcements / Re: Bugtracker trial
« on: July 08, 2010, 08:44:02 am »
Suggestions are given very low priority. I like the recommended tags idea. Maybe in a large cluster or something like a lot of sites do, with more frequent tags in larger typeset. The template thing only really applies to bugs. A trend seems to be the ability of people in general to propose a solution. Canonical and several others I've observed lately seem to have an answer proposal box at the bottom of each bug report (at least those given attention).
a2h, I'm amazed at how well this all works together. Great job!
a2h, I'm amazed at how well this all works together. Great job!
1839
Off-Topic / Re: Sandy Duncan and clan
« on: July 08, 2010, 12:50:08 am »
Sigh. What a2h said.
This is the real image of that... that.
Admit it. My recreation was oddly hotter.
Though I must wonder, then. Who is that in the incorrect picture?
This is the real image of that... that.
Admit it. My recreation was oddly hotter.
Though I must wonder, then. Who is that in the incorrect picture?
1840
Announcements / Re: Bugtracker trial
« on: July 07, 2010, 01:45:05 pm »
Not anymore...? How odd.
1841
Announcements / Re: Bugtracker trial
« on: July 06, 2010, 11:30:08 pm »
I am so happy with you right now. I was just remarking to my brother. Thanks for this, this is insane.
1842
Announcements / Re: Bugtracker trial
« on: July 06, 2010, 01:50:00 am »
I know you can't tell, but I'm smiling right now. Nice work. Now maybe I can get more notice than "Oh, it's too bad ENIGMA segfaults on load..." a month later.
1843
Announcements / Re: Happy Independence Day
« on: July 06, 2010, 01:49:10 am »
Retep: Who's this "we" we're going to get to focus? If you mean Americans, don't count on it. They'll remain, as a majority, in oblivia until it becomes absolutely necessary for them to think for themselves. Ism would make that sooner than later, but I insist that nutrition facts on water and directions on poptart and cereal boxes are a good sign that no thought will be put into life by any of them for a long time.
Gary: Noted: has calendar date at disposal. Can resolve meaning thereof if invoked.
Gary: Noted: has calendar date at disposal. Can resolve meaning thereof if invoked.
1844
Announcements / Re: Happy Independence Day
« on: July 05, 2010, 09:27:19 am »
I've asked some British people if they were still sore about it. But yeah, Americans aren't, as a collective, shining jewels of intellect...
1845
Announcements / Happy Independence Day
« on: July 04, 2010, 06:54:20 pm »
Since a2h is Australian (and asleep anyway, I guess), Ism is actually a Russian spy, and none of the other administrators know what the hell day it is, happy fourth to all you Americans.
I'm going to go set something on fire and blow some other things up in good American spirit. ...The old spirit. Well. I mean.
Explanations later.
Peace.
I'm going to go set something on fire and blow some other things up in good American spirit. ...The old spirit. Well. I mean.
Explanations later.
Peace.
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 »