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.
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 »
1966
Announcements / Re: Fixed those Makefiles
« on: May 16, 2010, 12:21:57 PM »
The splash screen doesn't display here; I assumed you'd removed it.
1967
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 09:31:15 PM »
Well, it's an irremovable part of ENIGMA's philosophy. And it's a bit late to fork the project over it. If you don't like it, you don't like ENIGMA, and you probably don't belong here.
1968
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 08:25:19 PM »
In the case that it is declared as "local int", "local string", or what have you, in a later event, which could be considered bad practice, but it seems asinine to disallow that over the minuscule amount of work taken to support it.
1969
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 06:55:06 PM »
COBOL did work fine, then we found something better.
Hey, go find something better.
Don't give me "lots and lots" bullshit; I can enumerate every inconsistency with the languages and what's been done about it. There are roughly five. Holding lexed code to determine what type an object is before acting on it isn't one of those inconsistencies.
Hey, go find something better.
Don't give me "lots and lots" bullshit; I can enumerate every inconsistency with the languages and what's been done about it. There are roughly five. Holding lexed code to determine what type an object is before acting on it isn't one of those inconsistencies.
1970
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 06:46:05 PM »
I recall no such people.
C++ isn't a problem with the architecture; clearly it's working fine. Just not with your proposal. This doesn't agree with your idea of what I should be doing, so you see it as a problem.
C++ isn't a problem with the architecture; clearly it's working fine. Just not with your proposal. This doesn't agree with your idea of what I should be doing, so you see it as a problem.
1971
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 06:42:43 PM »
Great ad hominem. Is there an argument to go with it?
1972
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 06:40:59 PM »
And to that I'm saying "Fuck you."
1973
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 06:39:41 PM »
That's impossible to do from a compiled language with integer-id access.
Furthermore, neither of us know that for certain.
Furthermore, neither of us know that for certain.
1974
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 06:36:46 PM »
There is no difference between what ENIGMA is doing and what Mark did with globalvar.
Also, if you're going to forward that ENIGMA should introduce no new functionality over its "ingredients," you destroy your component argument for systems that can actually use them later on. Or rather, your brother's; you never actually forwarded an argument.
Also, if you're going to forward that ENIGMA should introduce no new functionality over its "ingredients," you destroy your component argument for systems that can actually use them later on. Or rather, your brother's; you never actually forwarded an argument.
1975
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 06:33:41 PM »
Good argument. 
What ENIGMA does with its token string later on is essentially what C++ does while it links. It's also what Mark has to do to check if a variable was previously declared as globalvar.
What ENIGMA does with its token string later on is essentially what C++ does while it links. It's also what Mark has to do to check if a variable was previously declared as globalvar.
1976
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 06:09:40 PM »
Nah, I don't like that idea. 
Anyway, the tokens need to remain in memory so I can go back over them for another pass as more information becomes available, such as localized types and members by certain types.
For example, a.size would mean two different things based on the type of "a." If left undeclared, or declared scalar, the meaning is to access "a" as an object by id, then access implicit member "size." Otherwise, it should be left as-is.
Anyway, the tokens need to remain in memory so I can go back over them for another pass as more information becomes available, such as localized types and members by certain types.
For example, a.size would mean two different things based on the type of "a." If left undeclared, or declared scalar, the meaning is to access "a" as an object by id, then access implicit member "size." Otherwise, it should be left as-is.
1977
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 05:52:29 PM »
Except that each operator would require its own element in the list, with a forward and reverse pointer. Unless I'm missing some magical way to eliminate that, we'd be multiplying by either 9 or 17 the size of each operator.
1978
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 05:22:37 PM »
"Your only argument against using Rusky's parsing method besides that you created the one you're using yourself was that it uses too much memory. Having smashed that argument and you having dropped it, now we're back to how you keep choosing crappy methods just because you came up with them."
I acknowledged that replacing the second string with linear-linked structures would be more efficient and would probably be done at some point in the future. Now is not the time, as the only end of that system is to work. Furthermore, I had thought of that idea long, long ago; the method now employed was simply quicker to implement.
Moreover, it is unlikely that the newer method would save memory, but it would probably save insertion time. Because I don't know the gain and the gain is unnecessary, it's not high on my priority list.
I acknowledged that replacing the second string with linear-linked structures would be more efficient and would probably be done at some point in the future. Now is not the time, as the only end of that system is to work. Furthermore, I had thought of that idea long, long ago; the method now employed was simply quicker to implement.
Moreover, it is unlikely that the newer method would save memory, but it would probably save insertion time. Because I don't know the gain and the gain is unnecessary, it's not high on my priority list.
1979
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 11:48:03 AM »
That's actually just type; and yes, I'd considered doing something like that (using one char and a pointer instead of the full name) if only because it saves space, but then I realized that memory is cheap and that it's pretty much worse it for the ability to just cout << both strings to see if anything is the matter. It could probably be more efficient both in memory and in cycles, which is why I've been considering redoing it for a while with a linked list of such structs. It'll basically happen on a when-I-get-around-to-it basis, though, if it ever does happen. This method has proven quite convenient and simple to code for.
And don't use this as an axiom for why compiled games should be allowed to bloat; the compiler has no effect on the end end user.
And as a fun side note, this was posted through some miracle through the Wifi of a local restaurant or something; I'm in the car right now headed off to some race (against my will, I might add) and will return later.
And don't use this as an axiom for why compiled games should be allowed to bloat; the compiler has no effect on the end end user.
And as a fun side note, this was posted through some miracle through the Wifi of a local restaurant or something; I'm in the car right now headed off to some race (against my will, I might add) and will return later.
1980
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 11:02:04 AM »
I don't see anything wrong with what you've said about my parser--the good or the bad--; I also don't see any reason to bother using a lookup table to conserve so little space, especially compared to GCC's AST. I know I don't have the skill to write an AST better than Clang's; to forsake a method this simple in an attempt would be asinine.
Anyway, does this mean you are finished defending the component system? At this point, I see no gain in using it instead of tiers for up to the collision system; only loss.
Anyway, does this mean you are finished defending the component system? At this point, I see no gain in using it instead of tiers for up to the collision system; only loss.
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 »