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 »
2206
Proposals / Re: execute_string via Google V8
« on: March 29, 2010, 11:24:53 pm »
I can see it being helpful; I can't see me using it.
2207
Proposals / Re: Tierable Systems
« on: March 29, 2010, 11:22:27 pm »
That's a bit bold a statement on all counts. Your missing the point; you just suggested that I reduce the speed of the lookup of needed locals by >75%. The few cycles it once took to look up X are now repeated more than three additional times to successfully make a call to that un-inlined function. We're quadrupling the work that needs done. And now you're justifying it with "a cycle is small, therefore all the cycles you will be throwing out the window with this method are small" (That's the fallacy of composition, just as a fun side-note. And it doesn't apply to mathematically distributing a 4x cycle factor to all processes, by the by).
All I need to do is take advice like that on a dozen or so more systems, and I can successfully reduce the speed of the project by a quarter, and then I can render those lined-flames like GM8 does. At seven frames per second for some 250 of them (That was a slippery slope fallacy. It's pretty commonly used in court cases).
I'm not even starting down that road. I don't care how relatively small the change is compared to the rest of the project; this isn't the first such change you've suggested and I highly doubt it will be the last.
All I need to do is take advice like that on a dozen or so more systems, and I can successfully reduce the speed of the project by a quarter, and then I can render those lined-flames like GM8 does. At seven frames per second for some 250 of them (That was a slippery slope fallacy. It's pretty commonly used in court cases).
I'm not even starting down that road. I don't care how relatively small the change is compared to the rest of the project; this isn't the first such change you've suggested and I highly doubt it will be the last.
2208
Proposals / Re: Tierable Systems
« on: March 29, 2010, 11:00:25 pm »
*shrug* I don't see that as a problem.
2209
Announcements / Re: Update
« on: March 29, 2010, 10:56:02 pm »
Best. Grammar. Mistake. Ever.
...Nah, mediocre, but I'm leaving it.
...Nah, mediocre, but I'm leaving it.
2210
Announcements / Update
« on: March 29, 2010, 10:48:55 pm »
Ism is presently dealing with "real-life" things. She'll be around; hopefully enough so to wrap this up quickly.
I've implemented the tier system, reducing the compile time to about four seconds on this computer, which apparently is about average in comparison to some of other ENIGMA members' computers, assuming those are what you'd call "good". Basically, it's what you'd get out of a GM game, except the compile's a one-time deal and accounts for 95% of the time at least.
So yeah, ENIGMA's up to speed. Much better than R3's 30 second compile jobs.
Eh...
ENIGMA is a DLL now. The ENIGMA plug-in fails to pass it the resources, though, due to some major JNA failure. Ism has successfully segfaulted Java on multiple occasions today.
I'm not sure what I will do tomorrow, other than go to school, which will be weird since it's Spring Break for high school but not college. I'll try to get something in this household running Linux again and make sure the engine works for it, too. Oh, by the way, I'm making sure that the new tiering system comes with even better organization than in the repo. It's going to be a fun time committing all these moves and deletes. -.-"
I prepared a small todo list of revisions for the engine. Really, I need Ism to get JNA working so I can test the damn compiler part already. >_<
If anyone has the patients of a saint and the Java skills of, er,... a patient gopher, I could use a hand.
Ciao for now; going to do any homework I may still be putting off.
I've implemented the tier system, reducing the compile time to about four seconds on this computer, which apparently is about average in comparison to some of other ENIGMA members' computers, assuming those are what you'd call "good". Basically, it's what you'd get out of a GM game, except the compile's a one-time deal and accounts for 95% of the time at least.
So yeah, ENIGMA's up to speed. Much better than R3's 30 second compile jobs.
Eh...
ENIGMA is a DLL now. The ENIGMA plug-in fails to pass it the resources, though, due to some major JNA failure. Ism has successfully segfaulted Java on multiple occasions today.
I'm not sure what I will do tomorrow, other than go to school, which will be weird since it's Spring Break for high school but not college. I'll try to get something in this household running Linux again and make sure the engine works for it, too. Oh, by the way, I'm making sure that the new tiering system comes with even better organization than in the repo. It's going to be a fun time committing all these moves and deletes. -.-"
I prepared a small todo list of revisions for the engine. Really, I need Ism to get JNA working so I can test the damn compiler part already. >_<
If anyone has the patients of a saint and the Java skills of, er,... a patient gopher, I could use a hand.
Ciao for now; going to do any homework I may still be putting off.
2211
Proposals / Re: execute_string via Google V8
« on: March 29, 2010, 06:44:52 pm »
And what happens when you introduce functions like random()? I think the nice thing about those languages is that their functions are geared to aid in the domain restriction of the types. C++ is a bit too complicated for that.
Lambda aside, C++ is the one that lets you devise your own types with their own operators as well. And you can's always assume that > will return if left operand is greater than right, nor can you even assume a literal representation of any of it. Unfortunately, that includes var. Which is part of why I offered C types in the first place.
Lambda aside, C++ is the one that lets you devise your own types with their own operators as well. And you can's always assume that > will return if left operand is greater than right, nor can you even assume a literal representation of any of it. Unfortunately, that includes var. Which is part of why I offered C types in the first place.
2212
Proposals / Re: Tierable Systems
« on: March 29, 2010, 06:35:41 pm »
For the few instances I *have* to use it (as in, when the user makes a call via integer.varname), that's the best I'm getting.
The inefficiency of one system out of necessity (or otherwise, for that matter) doesn't justify the inefficiency of another, especially just on the grounds that it seems like a good idea to some individual.
That's no reason to need an accessor for compiled engine code.
The inefficiency of one system out of necessity (or otherwise, for that matter) doesn't justify the inefficiency of another, especially just on the grounds that it seems like a good idea to some individual.
That's no reason to need an accessor for compiled engine code.
2213
Proposals / Re: Tierable Systems
« on: March 29, 2010, 05:54:04 pm »
No, not anyobject.anyarbitraryvar: I'm replacing that with a hard-coded accessor of my own device. One should not be implemented for compiled code; compiled code is just that. Since anyobject is an integer rather than a structure, it will have O(log n) lookup, fetch ID, add to array to get lookup pointer, fetch lookup pointer, dereference lookup pointer, return. All that is necessary because I have no idea what the structure it points to will be.
When I said the point was to avoid recompilation, I figured it was implied I didn't want the load put on the run instead. I make it a point to have the compiler make sure as little has to happen at runtime as possible.
V8 accessors work the same as my integer referencer, except those who include the interpreter will be subject to size increase due to lookup tables.
When I said the point was to avoid recompilation, I figured it was implied I didn't want the load put on the run instead. I make it a point to have the compiler make sure as little has to happen at runtime as possible.
V8 accessors work the same as my integer referencer, except those who include the interpreter will be subject to size increase due to lookup tables.
2214
Proposals / Re: execute_string via Google V8
« on: March 29, 2010, 05:48:10 pm »
I revise, then; if Epigram can catch that bounds error compile time, I'm impressed. I very sincerely doubt it could without tracing hundreds of steps. Even if it was just checking for any limiters, it wouldn't be accurate enough.
I don't care what "real" programmers use, I use C++.
Yes, probably. It would do the same if it was being divided by one.
Ultimately, there is no Magic language. I'm happy with C.
No one's being forced to do anything; if they think they can find a better GM compiler, they can go looking.
I don't care what "real" programmers use, I use C++.
Yes, probably. It would do the same if it was being divided by one.
Ultimately, there is no Magic language. I'm happy with C.
No one's being forced to do anything; if they think they can find a better GM compiler, they can go looking.
2215
Proposals / Re: Tierable Systems
« on: March 29, 2010, 05:37:41 pm »
Components will still require either recompile or your accessors. Accessors are out of the question. The point of this system is to avoid recompile.
Also, instance_change isn't a difficult function to implement. I already have to list all the variables local to each object. Implementing instance_change is as simple as writing a block of code to copy matching variables over for the set of {objects that call instance_change}x{all objects}. Granted, it could largely increase the filesize if every object used instance_change somewhere in their events, but the function will have no tax on performance outside of itself.
Switching rendering engines is lousy. If it runs Windows, it has better DX support than GL support, A Priori. Otherwise, it either supports GL or requires its own rendering system.
I'm not looking for a resume; I'm looking to weed out a suggestion I can dismiss right off the bat as having consequences requiring >10x the number cycles to execute as its alternatives.
Also, instance_change isn't a difficult function to implement. I already have to list all the variables local to each object. Implementing instance_change is as simple as writing a block of code to copy matching variables over for the set of {objects that call instance_change}x{all objects}. Granted, it could largely increase the filesize if every object used instance_change somewhere in their events, but the function will have no tax on performance outside of itself.
Switching rendering engines is lousy. If it runs Windows, it has better DX support than GL support, A Priori. Otherwise, it either supports GL or requires its own rendering system.
I'm not looking for a resume; I'm looking to weed out a suggestion I can dismiss right off the bat as having consequences requiring >10x the number cycles to execute as its alternatives.
2216
Proposals / Re: Tierable Systems
« on: March 29, 2010, 01:52:14 pm »
Remove all those #ifdef #define pairs I can't find another explanation for. If they were so other systems could check if the variable has been implemented, that goes against the purpose of tiering (we'd have to go back over everything and recompile).
Rusky--
And every third instruction would be CALL. Not happening.
Furthermore, "wouldn't have any speed problems..." Do you have ANY research to back this up? Hello, you want me to throw in a function call every time I want object.x? When object is already a pointer? What the FUCK? I'm to the point where I'm unhappy about busing a DWORD back and forth from the RAM, and you want me to make a CALL for it instead. We're talking 6x the number of clocks, easily. That statement genuinely pissed me off this time.
If you want a text-based game with a collision system operating in a terminal window, I'm not programming for you.
Same for if you want to change your fucking mind about what operating system the game is for at runtime. Jesus.
Rusky--
And every third instruction would be CALL. Not happening.
Furthermore, "wouldn't have any speed problems..." Do you have ANY research to back this up? Hello, you want me to throw in a function call every time I want object.x? When object is already a pointer? What the FUCK? I'm to the point where I'm unhappy about busing a DWORD back and forth from the RAM, and you want me to make a CALL for it instead. We're talking 6x the number of clocks, easily. That statement genuinely pissed me off this time.
If you want a text-based game with a collision system operating in a terminal window, I'm not programming for you.
Same for if you want to change your fucking mind about what operating system the game is for at runtime. Jesus.
2217
Proposals / Re: execute_string via Google V8
« on: March 29, 2010, 01:45:43 pm »
> Just because you can't think of a way to solve something doesn't mean it's impossible.
My last bounds related segfault was on that demo game I released. If Haskell could find that at compile time, and then verify that it was fixed in the newer one, I'm impressed.
Also, danger is my middle name.
Was going to pull a C# / Java in debug mode, but gut it for final build.
Let's look at new C++ standard:
auto a = 2;
a /= 3;
cout << a;
I'm not sure how Haskell would go about solving that one. Probably defaulting to some bloaty type all the time. But I'll bet anything C++ prints zero.
My last bounds related segfault was on that demo game I released. If Haskell could find that at compile time, and then verify that it was fixed in the newer one, I'm impressed.
Also, danger is my middle name.
Was going to pull a C# / Java in debug mode, but gut it for final build.
Let's look at new C++ standard:
auto a = 2;
a /= 3;
cout << a;
I'm not sure how Haskell would go about solving that one. Probably defaulting to some bloaty type all the time. But I'll bet anything C++ prints zero.
2218
Proposals / Re: Tierable Systems
« on: March 29, 2010, 01:41:28 pm »
> Anything invisible that affects the collision system.
"visible" is part of the graphics tier.
retep:
extern is a great keyword
"visible" is part of the graphics tier.
retep:
extern is a great keyword
2219
Proposals / Re: Tierable Systems
« on: March 29, 2010, 01:33:17 pm »
Well, that settles that, then.
2220
Proposals / Re: execute_string via Google V8
« on: March 29, 2010, 01:11:53 pm »
> So much better than compile-time checks.
I can't think of any good compile-time checks for any segfaults I've had.
> Umm what?
Yes, if you want to disregard your actions and leave it to the compiler, I'm sure Haskell will perform better than C++.
> If an expression's type is ambiguous, you can specify it. Nobody's stopping you from specifying all your types in Haskell. I don't see what an odd behavior in PHP has to do with that.
Which is why I always would. And PHP was just an example of how shit goes bad when you don't know absolutely everything about something's behavior.
> dynamic_cast<T> is mostly runtime. I used it to implement instanceof in an ancient version of PineDL.
I never use that. Almost used it once, before I realized I couldn't even think of a time I'd need it for ENIGMA. Maybe later for instance_change.
I can't see removing the need for runtime checks on if a dynamic allocation returned NULL.
I can't think of any good compile-time checks for any segfaults I've had.
> Umm what?
Yes, if you want to disregard your actions and leave it to the compiler, I'm sure Haskell will perform better than C++.
> If an expression's type is ambiguous, you can specify it. Nobody's stopping you from specifying all your types in Haskell. I don't see what an odd behavior in PHP has to do with that.
Which is why I always would. And PHP was just an example of how shit goes bad when you don't know absolutely everything about something's behavior.
> dynamic_cast<T> is mostly runtime. I used it to implement instanceof in an ancient version of PineDL.
I never use that. Almost used it once, before I realized I couldn't even think of a time I'd need it for ENIGMA. Maybe later for instance_change.
I can't see removing the need for runtime checks on if a dynamic allocation returned NULL.
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 »