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 »
1996
Proposals / Re: Tiering vs Components
« on: May 14, 2010, 09:03:51 pm »
Sure, sure, miky. Clearly this wasn't the replacement for a less-thought-out system.
Believe what you will; your thoughts of matter are of little importance to me.
Believe what you will; your thoughts of matter are of little importance to me.
1998
Proposals / Re: Tiering vs Components
« on: May 14, 2010, 04:23:55 pm »
The problem is of what they're more important than. More important than an assortment of debug features and a new method of having four systems be dependent on each other, then yes, they are. The microseconds, anyway, for which I've recoded plenty of things to save more.
1999
Proposals / Re: Benchmark mode
« on: May 14, 2010, 04:20:04 pm »
At first it crossed me as a good idea, but I see a few problems.
I'm not sure about GCC's support for 3DNow!, but there's a problem with having ENIGMA make specific choices like that for the user; the user isn't the end user. Or rather, there's an end, end user. Offering an assortment of optimization flags is by all means a good idea and relatively effortless, yes, but a mode to determine them should only be used as a diagnostic tool for the benefit of the user; ENIGMA shouldn't act on the results of it.
Basically, it should be up to the user to decide that the end users must have X, Y, and Z extension. Not every ENIGMA game is going to have the dependencies of even typical well-endowed games like Portal, for instance. Portal requires pixel shader 1.0; it works on three computers of the seven in this house. But most GM games are more closely akin to Click the Clown, and so shouldn't be set to require more modern extensions just because the user (but not necessarily end user) has a $400 card.
And yes, that's a gross exaggeration, but we're talking about a user base whose cards don't support post-WWII extensions. Okay, another exaggeration. But seriously, integrated Intel chips don't support extensions from 1985. Just not a great idea to put a button for "Use my PC's extensions as the minimum requirement" at the hands of people with more money than wit... that button would basically never be a good idea.
Anyway, as a diagnostic tool, I'll consider such a test program and settings for restricting, possibly based somehow on the results.
I'm not sure about GCC's support for 3DNow!, but there's a problem with having ENIGMA make specific choices like that for the user; the user isn't the end user. Or rather, there's an end, end user. Offering an assortment of optimization flags is by all means a good idea and relatively effortless, yes, but a mode to determine them should only be used as a diagnostic tool for the benefit of the user; ENIGMA shouldn't act on the results of it.
Basically, it should be up to the user to decide that the end users must have X, Y, and Z extension. Not every ENIGMA game is going to have the dependencies of even typical well-endowed games like Portal, for instance. Portal requires pixel shader 1.0; it works on three computers of the seven in this house. But most GM games are more closely akin to Click the Clown, and so shouldn't be set to require more modern extensions just because the user (but not necessarily end user) has a $400 card.
And yes, that's a gross exaggeration, but we're talking about a user base whose cards don't support post-WWII extensions. Okay, another exaggeration. But seriously, integrated Intel chips don't support extensions from 1985. Just not a great idea to put a button for "Use my PC's extensions as the minimum requirement" at the hands of people with more money than wit... that button would basically never be a good idea.
Anyway, as a diagnostic tool, I'll consider such a test program and settings for restricting, possibly based somehow on the results.
2000
Proposals / Re: Tiering vs Components
« on: May 14, 2010, 02:58:13 pm »
I was thinking of such, but it'd have to be more than two columns so each new argument could be responded to. Actual debates are usually done by giving each side time to organize their argument, and then each side responds a certain number of times. I forget whether it is the one with or without the burden of proof who presents last.
2001
Proposals / Re: Tiering vs Components
« on: May 14, 2010, 02:20:25 pm »
I gave examples of what I claimed you've done, and I've dropped none of my criticisms; I'd ceased to emphasize some, such as the efficiency concern I reintroduced in the last post, simply because you have no defense against it other than shrugging it off as "negligible." That has been a concern since square one, back when you were casually proposing this system and I was casually declining it. I've emphasized time and time again that it introduces no useful features for the lower tiers, that it makes ugly code with accessor calls everywhere, that it's a bitch to implement, that it shares dependency structure with the tiers anyway.
Show me contradictions; I've pointed out yours (back when you were trying to pass components off as simpler organizational methods, but yes, they're a bitch to resolve), and show me vague, angry sentences.
Also, does this mean you can't defend yourself against any of the previous post?
Show me contradictions; I've pointed out yours (back when you were trying to pass components off as simpler organizational methods, but yes, they're a bitch to resolve), and show me vague, angry sentences.
Also, does this mean you can't defend yourself against any of the previous post?
2002
Proposals / Re: Tiering vs Components
« on: May 14, 2010, 09:24:57 am »
I can hardly believe I'm going to respond to this. Now you're just pretending. All your latest `things which are simpler` are sadly abstracted concepts to the point where you are not only once again not look at the bigger picture, you're not even looking at the immediate picture. It's like the games we played as children, proving 1 == 2 by dividing both sides by zero.
I'm about done entertaining your argument. It fell to trash, and then you tried to revive it with indeterminate calculations on a language in what is actually a loosely-garbled reduction of the original proposals.
Yes, you can have a function call a function that calls a function, the middle function implementing debug code. That's quite far from what I'm looking for in efficiency. And for the LAST TIME, I have nothing to add, debug wise, to all those functions.
Yes, the tier system is separate from the functions implemented on its basis. No, that is not overly complicated; I don't want anything developing for ENIGMA that finds this concept overly-complicated.
Yes, you can reduce the number of components, and this does "simplify" the ultimate object in your system. Not in mine; mine just inherits from the top tier. It wouldn't change a thing if the collision tier had the same name. So I suppose in your system, now that you have abstracted the tier system out of your own thinking pattern entirely, less components would in fact be the simpler solution. In the tier system, you can't tell from looking at the ultimate object how many tiers there are.
Yes, the ultimate tier does practically nothing because they ALL DO PRACTICALLY NOTHING. They are a device for organization. I could include the ultimate object in everything and manage to reason circularly in code, but I prefer not to and not doing so saves effort.
It is clear at this point you haven't had a look at any code in ENIGMA In a while. Why don't you check out and compile some games and watch what happens. You're basing much of your latter argument on fantasy and myth about how ENIGMA can and cannot function. Need I remind you of "ENIGMA can't possibly know all the members at compile time"? Damn, I don't even know where that came from.
I'm about done entertaining your argument. It fell to trash, and then you tried to revive it with indeterminate calculations on a language in what is actually a loosely-garbled reduction of the original proposals.
Yes, you can have a function call a function that calls a function, the middle function implementing debug code. That's quite far from what I'm looking for in efficiency. And for the LAST TIME, I have nothing to add, debug wise, to all those functions.
Yes, the tier system is separate from the functions implemented on its basis. No, that is not overly complicated; I don't want anything developing for ENIGMA that finds this concept overly-complicated.
Yes, you can reduce the number of components, and this does "simplify" the ultimate object in your system. Not in mine; mine just inherits from the top tier. It wouldn't change a thing if the collision tier had the same name. So I suppose in your system, now that you have abstracted the tier system out of your own thinking pattern entirely, less components would in fact be the simpler solution. In the tier system, you can't tell from looking at the ultimate object how many tiers there are.
Yes, the ultimate tier does practically nothing because they ALL DO PRACTICALLY NOTHING. They are a device for organization. I could include the ultimate object in everything and manage to reason circularly in code, but I prefer not to and not doing so saves effort.
It is clear at this point you haven't had a look at any code in ENIGMA In a while. Why don't you check out and compile some games and watch what happens. You're basing much of your latter argument on fantasy and myth about how ENIGMA can and cannot function. Need I remind you of "ENIGMA can't possibly know all the members at compile time"? Damn, I don't even know where that came from.
2003
Issues Help Desk / Re: C++, Linux and 39DLL.
« on: May 14, 2010, 08:46:20 am »
He knows. Hence option 5
2004
Announcements / Re: Fixed those Makefiles
« on: May 14, 2010, 08:04:12 am »
You have local shops with computers running X? Most people around here don't really know what Linux is...
2005
Issues Help Desk / Re: C++, Linux and 39DLL.
« on: May 14, 2010, 07:54:49 am »
I was wondering that myself, really. I mean, not how to make a server, but how to bring multiplayer functions to ENIGMA cross-platform.
I, unlike the Game Maker brigade, see the potential and beauty in importing all-popular projects such as 39Dll. My thought was a mix of #1 and essentially #2, though ting wasn't my personal thought. Perhaps ting is worth looking in to for it. In other words, I want to incorporate a cross platform version of 39Dll into ENIGMA's default functions.
You're thinking of disaster cases on a forum regarding at least a mildly better option. ENIGMA is like five revisions away from letting you #include ting and use it in your scripts, which I imagine you'd like better than being lost in the world of C++ without a graphics library.
I don't want to begin a cross-platform port of 39Dll just now, for obvious reasons. Perhaps you should turn this into a development plea for ENIGMA and someone will take it on themselves more immediately. Otherwise, I'll get to it "eventually" but would recommend--since I assume you don't wish to wait--doing the same; using ting to recode the contents of 39Dll. If you succeed, and it works well, and you give it to us, we can add it right in as part of the language.
Not sure how similar ting is to WinSock. Good luck either way.
I, unlike the Game Maker brigade, see the potential and beauty in importing all-popular projects such as 39Dll. My thought was a mix of #1 and essentially #2, though ting wasn't my personal thought. Perhaps ting is worth looking in to for it. In other words, I want to incorporate a cross platform version of 39Dll into ENIGMA's default functions.
You're thinking of disaster cases on a forum regarding at least a mildly better option. ENIGMA is like five revisions away from letting you #include ting and use it in your scripts, which I imagine you'd like better than being lost in the world of C++ without a graphics library.
I don't want to begin a cross-platform port of 39Dll just now, for obvious reasons. Perhaps you should turn this into a development plea for ENIGMA and someone will take it on themselves more immediately. Otherwise, I'll get to it "eventually" but would recommend--since I assume you don't wish to wait--doing the same; using ting to recode the contents of 39Dll. If you succeed, and it works well, and you give it to us, we can add it right in as part of the language.
Not sure how similar ting is to WinSock. Good luck either way.
2006
Announcements / Re: Fixed those Makefiles
« on: May 13, 2010, 10:38:54 pm »
You know, few things are more annoying than your OS dying because Java really blows on it.
2007
Issues Help Desk / Re: Physics bugs
« on: May 13, 2010, 08:01:05 pm »
I'll also inform you that ternary works in ENIGMA.
2008
Proposals / Re: Tiering vs Components
« on: May 13, 2010, 07:58:58 pm »
The point of this system is not to implement separate debugging. That never had -anything- to do with the point. I explained that if I need debugging done, a single function call will be inserted. And I did give a tier implementation; the rest differ only in the names of the variables declared which can be inferred. I don't feel like posting them; I know what they look like, and anyone who wishes to see them can use SourceForge's SVN browser.
And yes, you made that apparent by including X and Y in with the sprite component, which I regard as a bad move. And it doesn't matter how many configurations you propose; I've already went through them all and I can't find one less outwardly dependent on everything than the configuration established with my tiers. You should never, ever, ever, ever, ever, ever (and do note that I typed manually every ever ever), include the 2D sprite component/tier with a "focused" or "specific" 3D component/tier. 3D games don't use sprite_index and image_index, except in GM. So how does the tier system provide for that? It already does! Nothing changes, it's as simple as that. Now, when you decide you want to include a more specialized system for 3D, you drop the planar tier; you drop instance_nearest for instance_nearest_3d, you drop bitmasked-based place_free and whatnot for yet-unplanned model collision functions; you drop anything that was based in design and principle for a 2D game in favor of the 3D equivalents.
The tier system implements a total of *does some counting*... zero functions. There's nothing in them to debug. Functions like sprite_draw, should they under any circumstance require debug information, will have it called as an external function via a macro. This isn't negotiable in the tier system, and the component system isn't worth it for that one feature, outside of which nothing is offered.
And yes, you made that apparent by including X and Y in with the sprite component, which I regard as a bad move. And it doesn't matter how many configurations you propose; I've already went through them all and I can't find one less outwardly dependent on everything than the configuration established with my tiers. You should never, ever, ever, ever, ever, ever (and do note that I typed manually every ever ever), include the 2D sprite component/tier with a "focused" or "specific" 3D component/tier. 3D games don't use sprite_index and image_index, except in GM. So how does the tier system provide for that? It already does! Nothing changes, it's as simple as that. Now, when you decide you want to include a more specialized system for 3D, you drop the planar tier; you drop instance_nearest for instance_nearest_3d, you drop bitmasked-based place_free and whatnot for yet-unplanned model collision functions; you drop anything that was based in design and principle for a 2D game in favor of the 3D equivalents.
The tier system implements a total of *does some counting*... zero functions. There's nothing in them to debug. Functions like sprite_draw, should they under any circumstance require debug information, will have it called as an external function via a macro. This isn't negotiable in the tier system, and the component system isn't worth it for that one feature, outside of which nothing is offered.
2009
Announcements / Re: Fixed those Makefiles
« on: May 13, 2010, 02:30:16 pm »
Ism:
I'm not sure if Retro's makefile could magically discern what OS you are on, but mine can't. From the main directory's makefile, call make ENIGMA PLATFORM=linux.
And yes, threading and console output would be nice. If you like, I can prefix messages to redirect with "enigma: ".
Don't worry, compile is only slow the first time, then it completes in seconds.
I'm not sure if Retro's makefile could magically discern what OS you are on, but mine can't. From the main directory's makefile, call make ENIGMA PLATFORM=linux.
And yes, threading and console output would be nice. If you like, I can prefix messages to redirect with "enigma: ".
Don't worry, compile is only slow the first time, then it completes in seconds.
2010
Proposals / Re: Tiering vs Components
« on: May 13, 2010, 02:24:37 pm »
And you keep missing the point that we are discussing ENIGMA's lowermost systems. And as a side note, I have no debug code to add to tiers; nothing can possibly go wrong with them until you start linking in and using systems that aren't accounted for, which the compiler makes impossible.
"What you've thought about more are the specific dependencies present in a GM-like system."
And this is precisely what we're debating. All that thinking considered, tiers appear to me to be the perfect method for the key systems.
"Wherever you put coordinates, it needs that component or tier. There is absolutely no difference in this respect."
Good, simpler system wins.
"Dependencies are resolved better with components because they're more specific- you can have something depend on one other section rather than all the others below it, you can have two depend on each other, etc."
Yes. Now think about that in the context of the systems we're debating. If every tier in my system was likewise paired with a component in yours, the relative dependencies would be exactly the same. Your sprite component still needs the 2D component, your collision component still needs the sprite component. There is neither an audio tier nor component. I have no debug info to pile onto either system, nor anything else to make use of the features components offer. All they'd do is ugly up my code and slow the system (yes, minutely, but as I've said and will continue to say, I'm accounting for each little piece).
"What you've thought about more are the specific dependencies present in a GM-like system."
And this is precisely what we're debating. All that thinking considered, tiers appear to me to be the perfect method for the key systems.
"Wherever you put coordinates, it needs that component or tier. There is absolutely no difference in this respect."
Good, simpler system wins.
"Dependencies are resolved better with components because they're more specific- you can have something depend on one other section rather than all the others below it, you can have two depend on each other, etc."
Yes. Now think about that in the context of the systems we're debating. If every tier in my system was likewise paired with a component in yours, the relative dependencies would be exactly the same. Your sprite component still needs the 2D component, your collision component still needs the sprite component. There is neither an audio tier nor component. I have no debug info to pile onto either system, nor anything else to make use of the features components offer. All they'd do is ugly up my code and slow the system (yes, minutely, but as I've said and will continue to say, I'm accounting for each little piece).
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 »