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 »
2026
Proposals / Re: Tiering vs Components
« on: May 11, 2010, 06:56:59 pm »
"You could add a debug wrapper (i.e. a new component that forwards calls to the original one, doing something else as well) that draws the path an object is following."
Where would I put the code for that? Personally, I think it'd be a good idea to put it in with, say, the rest of the code. Otherwise it's just a pain in the ass to find the corresponding debug code.
"You could add one that draws and deals with build mode controls, letting you modify objects when the game is paused."
Yes, as the supreme lord and master of all code that goes through ENIGMA, I can do that without a component system by inserting the code myself at compile time. I mentioned that before.
"You could add one that turns off specific sounds to help debug audio."
Sounds have to be queued anyway for sound_stop_all. Practically all of ENIGMA needs queued in some way, shape, or form. This could be done with a simple global-scope function. How does your system help me?
"You could add one that pauses for build mode on a certain event (okay, this one's an event, whatever)."
I don't follow the parenthetical statement. Build mode is presently handled with an #if around an if-else pair in the event loop. The #if checks that it's in build mode, the if() checks if build mode has the game paused. This has worked for over a year. How does your system help me?
"These are not the same level of debugging that uses proxy<> and an interactive debugger- it's higher level and more specific to Enigma games."
If it's that specific, it should be included in or by the concerned source. It doesn't make sense to put the debug code anywhere else just because I can.
"You were the one who suggested using a tiered system for paths: "Paths...are a good reason to add a component pointer""
What? How is "Paths...are a good reason to add a component pointer" suggestive of tiers? Now, in "If I decide to add a tier pointer, your ass will be recompiling everything that uses a single local, just like my system before tiers," I meant "component pointer" rather than "tier pointer." And no, this would be handled using all your fancy semantic proposals; the paths would be a component in your domain as described by the better of your previous proposals and a few methods of my own. The path system would be the first to justify using your component idea as I see it. Even with it, though, I would build on your idea to prevent fuck-ugly path_index() calls (Ironically, path_index() is probably a better idea though, since it's a read-only variable). These ideas that I would use to build on components would be inlining them then taking a member pointer to them instead of a component pointer. This could be achieved thanks to the not-"real"-code semantics you started down earlier. Again, paths are worth it to me, the underlying important systems are not.
"Couldn't you just pass an Object reference to them as a hidden argument?"
Sure, but then I would have to scope the locals the script uses into everything derived from Object, so scripts designed especially for a certain object using fifty variables would inflict those fifty variables on every other instance as well. Imagine a controller object with its own script folder, each script using some 12 variables, 25 unique among them all. That would be 200 bytes for each instance for no reason at all.
"You can't know what members will exist at compile time anyway"
Omigosh, I wonder how ENIGMA's been compiling all this time.
"Even with "treat uninitialized variables as 0" turned off you can still insert new members at any time"
How is that? ENIGMA has no variable_local_set(). When it does, that will simply access a map of references to locals, and if its not in the map, it will allocate a new one. If I didn't know every single variable at compile time, then GCC wouldn't, and the game wouldn't compile. We have no execute_string and no variable_local_set at this time.
R3 dealt with "a.b" access somewhat badly, implementing a dynamic cast between instances instead of an integer-taking accessor like R4 will use. All variables "b" accessed as "a.b" are added to an instance of Object called "Global" and identified with "global". If "b" didn't exist in "a.b", the global instance of it was returned. Some behavior is dropped that way, which is why Luda proposed a hash map. I didn't like the idea, but it will be implemented optionally down the road.
And yes, usable behaviors could work just that way. But not for the key motherfucking systems. I'm not having my parser go around picking apart and gluing back together the single most fundamental pieces of this system.
Where would I put the code for that? Personally, I think it'd be a good idea to put it in with, say, the rest of the code. Otherwise it's just a pain in the ass to find the corresponding debug code.
"You could add one that draws and deals with build mode controls, letting you modify objects when the game is paused."
Yes, as the supreme lord and master of all code that goes through ENIGMA, I can do that without a component system by inserting the code myself at compile time. I mentioned that before.
"You could add one that turns off specific sounds to help debug audio."
Sounds have to be queued anyway for sound_stop_all. Practically all of ENIGMA needs queued in some way, shape, or form. This could be done with a simple global-scope function. How does your system help me?
"You could add one that pauses for build mode on a certain event (okay, this one's an event, whatever)."
I don't follow the parenthetical statement. Build mode is presently handled with an #if around an if-else pair in the event loop. The #if checks that it's in build mode, the if() checks if build mode has the game paused. This has worked for over a year. How does your system help me?
"These are not the same level of debugging that uses proxy<> and an interactive debugger- it's higher level and more specific to Enigma games."
If it's that specific, it should be included in or by the concerned source. It doesn't make sense to put the debug code anywhere else just because I can.
"You were the one who suggested using a tiered system for paths: "Paths...are a good reason to add a component pointer""
What? How is "Paths...are a good reason to add a component pointer" suggestive of tiers? Now, in "If I decide to add a tier pointer, your ass will be recompiling everything that uses a single local, just like my system before tiers," I meant "component pointer" rather than "tier pointer." And no, this would be handled using all your fancy semantic proposals; the paths would be a component in your domain as described by the better of your previous proposals and a few methods of my own. The path system would be the first to justify using your component idea as I see it. Even with it, though, I would build on your idea to prevent fuck-ugly path_index() calls (Ironically, path_index() is probably a better idea though, since it's a read-only variable). These ideas that I would use to build on components would be inlining them then taking a member pointer to them instead of a component pointer. This could be achieved thanks to the not-"real"-code semantics you started down earlier. Again, paths are worth it to me, the underlying important systems are not.
"Couldn't you just pass an Object reference to them as a hidden argument?"
Sure, but then I would have to scope the locals the script uses into everything derived from Object, so scripts designed especially for a certain object using fifty variables would inflict those fifty variables on every other instance as well. Imagine a controller object with its own script folder, each script using some 12 variables, 25 unique among them all. That would be 200 bytes for each instance for no reason at all.
"You can't know what members will exist at compile time anyway"
Omigosh, I wonder how ENIGMA's been compiling all this time.
"Even with "treat uninitialized variables as 0" turned off you can still insert new members at any time"
How is that? ENIGMA has no variable_local_set(). When it does, that will simply access a map of references to locals, and if its not in the map, it will allocate a new one. If I didn't know every single variable at compile time, then GCC wouldn't, and the game wouldn't compile. We have no execute_string and no variable_local_set at this time.
R3 dealt with "a.b" access somewhat badly, implementing a dynamic cast between instances instead of an integer-taking accessor like R4 will use. All variables "b" accessed as "a.b" are added to an instance of Object called "Global" and identified with "global". If "b" didn't exist in "a.b", the global instance of it was returned. Some behavior is dropped that way, which is why Luda proposed a hash map. I didn't like the idea, but it will be implemented optionally down the road.
And yes, usable behaviors could work just that way. But not for the key motherfucking systems. I'm not having my parser go around picking apart and gluing back together the single most fundamental pieces of this system.
2027
Proposals / Re: Tiering vs Components
« on: May 11, 2010, 05:46:27 pm »Code: (cpp) [Select]
extern void vague_debug_event_that_somehow_applies_to_everything();
extern void (*vague_debug_event_that_somehow_applies_to_everything_and_can_be_disabled_at_runtime)();
#ifndef ENIGMAdebug
#define vague_debug_event_that_somehow_applies_to_everything()
#define vague_debug_event_that_somehow_applies_to_everything_and_can_be_disabled_at_runtime()
#endif
Now, as far as calling that in systems that aren't designed to have special debug information; why would you need to, number one? What would you call for every function called by every system? What would be the point? To get what last executed before fail? That's where stepping through comes in.At this second paragraph, I believe you're just trolling. The entire fucking point of the tier system is to allow files that make use of common elements to only include pieces parts of the elements, leaving the rest to mystery. Using the tier system for something as worthless as paths--that exactly one source file depends on--is about the most ridiculous thing I've heard this whole debate.
"When extending GM (e.g. reusable behaviors), components address organization issues much better than GM's single inheritance."
Obviously.
"They're much better than scripts, which are really just components organized in the most horrible way imaginable."
In your opinion, I'll grant that. But I'd like to point out that scripts require special passes over to get to function correctly; mostly to tell the system what other locals need included in the objects that call each script. This isn't an option for hard-coded components.
"Components do code reuse far better than templates and wizards, which are just fancy copy-paste (and so somehow different from the "real" code?)"
In your opinion, close (yes, they're different in that code is being modified dynamically by the compiler/wizard)
"That's why they're a good way to extend GM- its existing inheritance model and paradigms are irrelevant."
Yes, I agreed with this two posts ago. What does this have to do with the underlying system about which this debate is concerned?
2028
Off-Topic / Re: David Cameron is the new UK Prime Minister
« on: May 11, 2010, 04:37:40 pm »
Ism's is probably more accurate. Ideally he'll be doing a bit of that, too.
2029
Proposals / Re: Tiering vs Components
« on: May 11, 2010, 02:19:30 pm »
"(x and y come from which parent? PlayerCharacter or PlatformCharacter?)"
Neither; a parent of both. GM doesn't have multiple inheritance anyway. Most of what you're describing otherwise is achievable with scripts. ai_avoid_bullet(), ai_seek_powerup()... much of those will lead to conflict in either system.
Nonetheless, that is outside the scope of this debate.
Just because the language looks close doesn't mean it behaves close. The parts of EDL that require a parser to use shouldn't be employed in C++ functions. If you want with() and case "string", use a script.
"When I asked "Why would you decide to add a component pointer?" I assumed components like Path would either always be in Object or only be included in OBJ_*s. Neither would force a recompile."
The latter is impossible without a global due to inability to assume position of that pointer, which is, for the fourth time, a problem shared between components and my old system. And no, I don't want those damn pointers to always be included.
"Instantiating components inline goes back to the problem of changing tier sizes. Changing a component in such a system would have the same results as in your pre-tier system."
Hence I mentioned the (Object::*). I neglected to mention that it would be at the global scope. All the Path component's source would need to know is the location of its structure inside Object, which would be represented by extern Object::* ::component_location::path;.
"You haven't really given any points against using components for core systems other than "it's too complicated," which is a stupid reason, and "it's ugly," which is completely subjective at this point. You haven't shown how you would accomplish the debugging features I suggested without components. You haven't shown how tiers are any less ugly than components."
Debugging has always been done with preprocessors. To initiate debug mode, one flag would have to be set, and the sources could be compiled in a separate objects folder called ".eobjs_debug" instead of just ".eobjs". Tracking variable changes can be done by adding "debug_proxy<>" around all the types; something I have complete control over. I know I've mentioned that, maybe I didn't stress it. And although I wasn't going to mention it until plans were laid, I was considering hooking up GDB to the debug window when the time comes to allow stepping through code one expression at a time, like Code::Blocks and other IDEs do.
And I said that the code produced is uglier. Saying "x" is prettier than saying "x()".
Every benefit you've suggested to using components on the lower system, I gave how it would be accomplished with the current system instead. Feel free to enumerate more, and I'll respond to them as well.
And the argument isn't that it's too complicated, it's that it is -more- complicated. And all else being the same, the simpler method wins.
Neither; a parent of both. GM doesn't have multiple inheritance anyway. Most of what you're describing otherwise is achievable with scripts. ai_avoid_bullet(), ai_seek_powerup()... much of those will lead to conflict in either system.
Nonetheless, that is outside the scope of this debate.
Just because the language looks close doesn't mean it behaves close. The parts of EDL that require a parser to use shouldn't be employed in C++ functions. If you want with() and case "string", use a script.
"When I asked "Why would you decide to add a component pointer?" I assumed components like Path would either always be in Object or only be included in OBJ_*s. Neither would force a recompile."
The latter is impossible without a global due to inability to assume position of that pointer, which is, for the fourth time, a problem shared between components and my old system. And no, I don't want those damn pointers to always be included.
"Instantiating components inline goes back to the problem of changing tier sizes. Changing a component in such a system would have the same results as in your pre-tier system."
Hence I mentioned the (Object::*). I neglected to mention that it would be at the global scope. All the Path component's source would need to know is the location of its structure inside Object, which would be represented by extern Object::* ::component_location::path;.
"You haven't really given any points against using components for core systems other than "it's too complicated," which is a stupid reason, and "it's ugly," which is completely subjective at this point. You haven't shown how you would accomplish the debugging features I suggested without components. You haven't shown how tiers are any less ugly than components."
Debugging has always been done with preprocessors. To initiate debug mode, one flag would have to be set, and the sources could be compiled in a separate objects folder called ".eobjs_debug" instead of just ".eobjs". Tracking variable changes can be done by adding "debug_proxy<>" around all the types; something I have complete control over. I know I've mentioned that, maybe I didn't stress it. And although I wasn't going to mention it until plans were laid, I was considering hooking up GDB to the debug window when the time comes to allow stepping through code one expression at a time, like Code::Blocks and other IDEs do.
And I said that the code produced is uglier. Saying "x" is prettier than saying "x()".
Every benefit you've suggested to using components on the lower system, I gave how it would be accomplished with the current system instead. Feel free to enumerate more, and I'll respond to them as well.
And the argument isn't that it's too complicated, it's that it is -more- complicated. And all else being the same, the simpler method wins.
2030
General ENIGMA / Re: ENIGMA's value
« on: May 11, 2010, 01:30:59 pm »
Josh is making THAT MUCH?
GO AFTER HIM WITH TORCHES
GO AFTER HIM WITH TORCHES
2031
Proposals / Re: Tiering vs Components
« on: May 11, 2010, 01:24:07 pm »
In GM, you would create object Character and then have objects Mario and Luigi inherit from that, incorporate a jump_height in Character so Luigi's can be higher than Mario's, as well as setting a sprite_base, then call inherited event if need be. Granted, GM's gross system of resource ID-ing could inhibit that sprite_base idea. That can be worked out later (LGM already has some features for that).
Does it truly matter how close the end result is to the EDL? No, not really. But if I get it close enough, I can let users choose to stop relying on the parser and do their coding entirely in C++, which would be an interesting opportunity to leave open. Besides, should they choose to start developing their own C++ functions, having to put an () after all the variables would be required and is annoying.
The path system is a great example of a waste of a component/tier. It implements some seven variables for its own purpose, using only about two from other tiers/components. I could think of a hundred additional systems I can do that with. Paths, and any systems like them, would be best suited to components because they have very little dependence on anything else. Paths incorporate their own speed variables, their own index variable; the only thing they really need from other tiers is x and y. Paths, and components like them about which the system is not designed, are a good reason to add a component pointer.
Of course, my component pointer would be done somewhat differently than yours. Because I understand that I am in control of the layout of object, the pointer would be achieved by making the compiler instantiate the path component inline. As in, say the path component contained path_index, path_position, and path_speed. Those three would be added in-place into the structure by the compiler, and the component pointer would be taken by casting the (Object::*) to (PathComponent*), which would be non-virtual.
The lower tiers, on the other hand, including graphics and collisions, I have denounced all your reasons to use components for. They will be of no more use to me in debugging than preprocessor expressions and a separate folder for debug object files. They only serve to complicate dependencies since they are all ground level, and they don't improve performance in any way. Not to mention that they make code ugly.
Does it truly matter how close the end result is to the EDL? No, not really. But if I get it close enough, I can let users choose to stop relying on the parser and do their coding entirely in C++, which would be an interesting opportunity to leave open. Besides, should they choose to start developing their own C++ functions, having to put an () after all the variables would be required and is annoying.
The path system is a great example of a waste of a component/tier. It implements some seven variables for its own purpose, using only about two from other tiers/components. I could think of a hundred additional systems I can do that with. Paths, and any systems like them, would be best suited to components because they have very little dependence on anything else. Paths incorporate their own speed variables, their own index variable; the only thing they really need from other tiers is x and y. Paths, and components like them about which the system is not designed, are a good reason to add a component pointer.
Of course, my component pointer would be done somewhat differently than yours. Because I understand that I am in control of the layout of object, the pointer would be achieved by making the compiler instantiate the path component inline. As in, say the path component contained path_index, path_position, and path_speed. Those three would be added in-place into the structure by the compiler, and the component pointer would be taken by casting the (Object::*) to (PathComponent*), which would be non-virtual.
The lower tiers, on the other hand, including graphics and collisions, I have denounced all your reasons to use components for. They will be of no more use to me in debugging than preprocessor expressions and a separate folder for debug object files. They only serve to complicate dependencies since they are all ground level, and they don't improve performance in any way. Not to mention that they make code ugly.
2032
Proposals / Re: Tiering vs Components
« on: May 11, 2010, 11:50:09 am »
"What they see is the results, and the component system gives better results."
<<Components are better because they give better results. They give better results because they are better.>>
For the purpose of the underlying systems--sprites, collisions, etc--the systems give the same results. No user will know the difference.
"What's so ugly about components? Adding () to members is just to keep GM compatibility;"
Yes. Except, my system doesn't require the (), it's as close to GM as possible by nature.
"You don't have to write behaviors to use the component system either. I'm fairly sure that being able to drag and drop "platform physics" onto an object and just tweak its numbers would be useful to plenty of GM users."
Aware. That leaves the question, "what is this improving, then?" And yes, the system you describe would be quite nice. I was going to do this with templates--not in the C++ sense, but in the sense that you just include a prescripted engine, perhaps via a wizard with its own scripting language. I'd prefer such be separate from the real code.
"Components are better-organized than tiers because separate behaviors are more separated from the main Object."
You included "Object.h" just to implement instance_nearest. Don't give me any bullshit. If I decide to add a tier pointer, your ass will be recompiling everything that uses a single local, just like my system before tiers. That set of functions requires two tiers in my system; so long as your game is 2D and uses instances, you won't need to recompile; and in the case that it is, you probably don't need instance_nearest, and it won't help you.
"This solution is also safer; it's harder to accidentally cast to a tier that doesn't exist and segfault your game. It would just not do anything rather than exploding."
I'd prefer it explode--That's how I know I've done something wrong.
"For instance_nearest, Object.h doesn't have the actual component implementations. It only uses the interfaces. Changing RasterSprite or whatever component actually implements the coordinates wouldn't affect Object.h. The idea is to design a minimal interface that doesn't need to change to implement GM's library, and let the actual systems that use extra stuff be the only code that knows about anything beyond the interface."
The same is true for tiers. Objects include the tiers only to know the locations of locals. The sources are compiled independently.
<<Components are better because they give better results. They give better results because they are better.>>
For the purpose of the underlying systems--sprites, collisions, etc--the systems give the same results. No user will know the difference.
"What's so ugly about components? Adding () to members is just to keep GM compatibility;"
Yes. Except, my system doesn't require the (), it's as close to GM as possible by nature.
"You don't have to write behaviors to use the component system either. I'm fairly sure that being able to drag and drop "platform physics" onto an object and just tweak its numbers would be useful to plenty of GM users."
Aware. That leaves the question, "what is this improving, then?" And yes, the system you describe would be quite nice. I was going to do this with templates--not in the C++ sense, but in the sense that you just include a prescripted engine, perhaps via a wizard with its own scripting language. I'd prefer such be separate from the real code.
"Components are better-organized than tiers because separate behaviors are more separated from the main Object."
You included "Object.h" just to implement instance_nearest. Don't give me any bullshit. If I decide to add a tier pointer, your ass will be recompiling everything that uses a single local, just like my system before tiers. That set of functions requires two tiers in my system; so long as your game is 2D and uses instances, you won't need to recompile; and in the case that it is, you probably don't need instance_nearest, and it won't help you.
"This solution is also safer; it's harder to accidentally cast to a tier that doesn't exist and segfault your game. It would just not do anything rather than exploding."
I'd prefer it explode--That's how I know I've done something wrong.
"For instance_nearest, Object.h doesn't have the actual component implementations. It only uses the interfaces. Changing RasterSprite or whatever component actually implements the coordinates wouldn't affect Object.h. The idea is to design a minimal interface that doesn't need to change to implement GM's library, and let the actual systems that use extra stuff be the only code that knows about anything beyond the interface."
The same is true for tiers. Objects include the tiers only to know the locations of locals. The sources are compiled independently.
2033
Proposals / Re: Tiering vs Components
« on: May 10, 2010, 11:01:53 pm »
"You've already extended semantics for users with things like GM objects and with statements, why is this all of a sudden different?"
There's a difference between adding a file of information for informations' sake and implementing a system that I don't like and that no one will ever see.
You've "explained over and over" progressively improving ideas, all of which were slop until this one, which is much, much better, and is in fact a plausible method at this point.
"When they make a new behavior, they'll be making a new component"
Yes. Why does this require that the underlying systems likewise be component based instead of tier based? So the actual C++ can continue to be ugly as fuck? And yes, x() is still fuck-ugly compared to just x. At least it's not one of certain other language's long-winded jobs... The rest of ENIGMA, up to this point, save switch() and the innards of with(), is identical to C++. I wouldn't object to coding in ENIGMA without the parser, it remains that simple. And you want to add () to everything.
And I wouldn't even venture a guess at how many users would "absolutely be making direct use of the component system." The count stands at six presently; I imagine it will eventually end up about where map<> users will, if not even worse off. You're assuming that a community derived mostly from that of GM will be as enamored with the system as you, rather than as much so as me. I'd implement it above the tier system just for them, though. But you'll have to really justify the lower systems, the ones in question, being components if you expect me to recode all of that.
Which proposed benefits you've dropped is relatively unclear; among them are swapping out systems at runtime, which you dropped long ago. Others include, and this is ambiguous; how much better-organized components are than tiers, when components are a bigger bitch to resolve dependencies for. Tiers can only have one alignment; I don't see how you can beat that in organization. You keep trying to resurrect the idea that components can be easily "turned off", but when confronted you return to the realization that it will leave mess.
Now, regarding your instance_nearest code, we have a dilemma. You included Object.h: do you regard that as a mistake? That means that if you wish to add a new type of component, you're recompiling anything that makes use of any component's implemented locals. The tier system was designed specifically to avoid that. If you're not using the planar tier, your game isn't 2D, and you're not using instance_nearest. That's the concept. I can't really add or remove pointers now, except if the user implements one in a derived class from Object. Wasn't this one of the huge things components avoided?
There's a difference between adding a file of information for informations' sake and implementing a system that I don't like and that no one will ever see.
You've "explained over and over" progressively improving ideas, all of which were slop until this one, which is much, much better, and is in fact a plausible method at this point.
"When they make a new behavior, they'll be making a new component"
Yes. Why does this require that the underlying systems likewise be component based instead of tier based? So the actual C++ can continue to be ugly as fuck? And yes, x() is still fuck-ugly compared to just x. At least it's not one of certain other language's long-winded jobs... The rest of ENIGMA, up to this point, save switch() and the innards of with(), is identical to C++. I wouldn't object to coding in ENIGMA without the parser, it remains that simple. And you want to add () to everything.
And I wouldn't even venture a guess at how many users would "absolutely be making direct use of the component system." The count stands at six presently; I imagine it will eventually end up about where map<> users will, if not even worse off. You're assuming that a community derived mostly from that of GM will be as enamored with the system as you, rather than as much so as me. I'd implement it above the tier system just for them, though. But you'll have to really justify the lower systems, the ones in question, being components if you expect me to recode all of that.
Which proposed benefits you've dropped is relatively unclear; among them are swapping out systems at runtime, which you dropped long ago. Others include, and this is ambiguous; how much better-organized components are than tiers, when components are a bigger bitch to resolve dependencies for. Tiers can only have one alignment; I don't see how you can beat that in organization. You keep trying to resurrect the idea that components can be easily "turned off", but when confronted you return to the realization that it will leave mess.
Now, regarding your instance_nearest code, we have a dilemma. You included Object.h: do you regard that as a mistake? That means that if you wish to add a new type of component, you're recompiling anything that makes use of any component's implemented locals. The tier system was designed specifically to avoid that. If you're not using the planar tier, your game isn't 2D, and you're not using instance_nearest. That's the concept. I can't really add or remove pointers now, except if the user implements one in a derived class from Object. Wasn't this one of the huge things components avoided?
2034
Proposals / Re: Tiering vs Components
« on: May 10, 2010, 09:41:21 pm »
I read this line from you: "Saying that everything should be designed with the system's specific purpose in mind is ridiculous, and you've completely gone against it anyway."
And I remembered this line from you: "The built-ins go in Object, and you know which component to look in because, as built-ins, the whole system will be implemented with them in mind."
And I wasn't really sure what to make of your argument anymore, but I'll continue anyway.
Libraries are designed quite specifically, but tend to include a lot of options. GL offers hundreds of functions, many redundant, for things so simple as drawing points. glVertex[2-3][f,i,d]... It's general as a whole, yes, but the functions are designed for operating specifically. GL is actually pretty bloated compared to, say, GX, which is an ugly system expecting exactly a pre-specified format and freezing if it doesn't get it. I actually prefer it that way; it's how I know exactly what's being done for me. But that's beside the point.
"ENIGMA isn't C++..."
Yes, a semantic aspect is required to allow switching tiers. It's like that in both systems; the tier system just greatly reduces it as I can generate a list of all locals from only the name of the uppermost tier. Even with a list of all your components, I couldn't just traverse their contents; the point of your components is to extend outward from themselves, as tiers do. That is the only way they save compile time; when none are edited, only extended. How am I to keep track of all the extensions? I can't. I'd require the developer to name them all in a file. Sounds like a pain to be a developer.
There's a control panel of roughly five items so far to specify semantics. More will soon be read from individual files in each folder under Graphics_Systems and Platforms, mostly to inform the user of which options are available and give them a brief description. The files so far have no bearing on how code is compiled.
Also, my goal has been for a while now to move ENIGMA closer and closer to C++. The way R4 is geared, only three items of GML will be changed to migrate to C++.
1) Semicolons and other punctuation will be added. ENIGMA is more tolerant than GM in that "for ;;;" parses to "for (; ; );", among other such items.
2) Switch statements will be hijacked to allow for switching floating point values and strings. Additionally, they will be replaced with if-else combos if case labels are not constant (This is what GM does always).
3) Dot based accessing (x.y) will be replaced with an accessor function if x is not an instance of a structure containing y. Additionally, variables in with() statements will be prepended with enimga::withiter-> or similar.
Other than that, EDL and C++ are indistinguishable with the current configuration.
If you think I'm going to extend the C++ language for ENIGMA developers (as in, those working ON, not WITH Enigma), well, I'm not. ENIGMA is C++, regardless of how many things I'm adding to the language for EDL. ENIGMA's system is not written in EDL. There are no with()s in the instance functions, no variant types in the object code, and least of all, no C# properties in the tier system.
"Reusable behaviors are nice for users. That should be a good reason to implement them. The point of Enigma is not to be easy on you, it's to help users in making their games. A system should be pretty near impossible before you start considering implementation difficulty over usefulness."
My argument wasn't "it's difficult, therefore it's not worth it." In fact, it was my impression that said argument hurts you more. "Reusable behaviors are nice for users." You're advocating them because they are nice... for users. But they aren't nice for me? ENIGMA being so close to C++, how can what helps the users fail to help me?
The users aren't making direct use of the component system if it is used only by the compiler as a method to switch systems, now are they? So how does that help the users? This is why I thought it was to help me. To help developers in general. That ENIGMA would be gloriously easy to extend for all developer, myself included. Because all you have to do now is enumerate all the possible components and pass one as a flag to all the instances you are creating instead of just adding a single, nasty, old #define in there. So which is it? Whose life is this improving?
Most will never even know how ENIGMA organizes its lower systems, much less need to know. Of course, here I'm using your premise "Reusable behaviors are nice for users" instead of that the system will be a pain in the ass to implement but that it should be the developers' (aka, my) job to grin and bear it for the "users." Which users, exactly? What will users do knowing that their objects are component based instead of tier based?
The only way that what you're saying isn't self-contradictory is if you're trying to imply that my parser life becomes difficult, but that it will make the system much easier to develop for later. That's not true, either. Just naming the bottom tier in a text file called configure would suffice for me, maybe giving a description after it and lower tiers, all optionally. Your system requires that all components and all possible component extensions that may implement variables be named, that I may actually collect a sufficient list of locals for the accessors. And any way you try to contort your idea, I still need that list. That's a real pain in the ass for myself and any developers. With tiers, you just extend them and go. In fact, I'll already have a planar and intend to have a spacial tier in. Developers will just extend the one they require (planar for 2D, spacial for 3D, some new one if neither apply) with an alternative graphics system, or extend the current graphics tier with a new collision system (like box2D). I don't cater to games that want to implement a 3D mesh rendering tier but wish to use Colligma, a pixel-perfect, 2D collision system, on top of that. How would such a system make sense? You or miky gave an example of a game that used vector graphics but still wished to use Colligma. Well, I don't know why, but okay; the tier system would require recompile of collision functions (Colligma is separate in both cases) because the sprite tier was edited; your system, at this point, would also, as Sprite/RasterSprite would no longer be used. Where's the gain?
At this juncture, most of the benefits you've proposed once upon a time (such as swapping out graphics systems on runtime) you have dropped, without warning and with little regard afterward. Those that you have not are slowly unraveling as I demand more code. Here I'll ask for instance_nearest. Here's mine:
I'm interested to see where the name of the component and location of the instance comes from.
And I remembered this line from you: "The built-ins go in Object, and you know which component to look in because, as built-ins, the whole system will be implemented with them in mind."
And I wasn't really sure what to make of your argument anymore, but I'll continue anyway.
Libraries are designed quite specifically, but tend to include a lot of options. GL offers hundreds of functions, many redundant, for things so simple as drawing points. glVertex[2-3][f,i,d]... It's general as a whole, yes, but the functions are designed for operating specifically. GL is actually pretty bloated compared to, say, GX, which is an ugly system expecting exactly a pre-specified format and freezing if it doesn't get it. I actually prefer it that way; it's how I know exactly what's being done for me. But that's beside the point.
"ENIGMA isn't C++..."
Yes, a semantic aspect is required to allow switching tiers. It's like that in both systems; the tier system just greatly reduces it as I can generate a list of all locals from only the name of the uppermost tier. Even with a list of all your components, I couldn't just traverse their contents; the point of your components is to extend outward from themselves, as tiers do. That is the only way they save compile time; when none are edited, only extended. How am I to keep track of all the extensions? I can't. I'd require the developer to name them all in a file. Sounds like a pain to be a developer.
There's a control panel of roughly five items so far to specify semantics. More will soon be read from individual files in each folder under Graphics_Systems and Platforms, mostly to inform the user of which options are available and give them a brief description. The files so far have no bearing on how code is compiled.
Also, my goal has been for a while now to move ENIGMA closer and closer to C++. The way R4 is geared, only three items of GML will be changed to migrate to C++.
1) Semicolons and other punctuation will be added. ENIGMA is more tolerant than GM in that "for ;;;" parses to "for (; ; );", among other such items.
2) Switch statements will be hijacked to allow for switching floating point values and strings. Additionally, they will be replaced with if-else combos if case labels are not constant (This is what GM does always).
3) Dot based accessing (x.y) will be replaced with an accessor function if x is not an instance of a structure containing y. Additionally, variables in with() statements will be prepended with enimga::withiter-> or similar.
Other than that, EDL and C++ are indistinguishable with the current configuration.
If you think I'm going to extend the C++ language for ENIGMA developers (as in, those working ON, not WITH Enigma), well, I'm not. ENIGMA is C++, regardless of how many things I'm adding to the language for EDL. ENIGMA's system is not written in EDL. There are no with()s in the instance functions, no variant types in the object code, and least of all, no C# properties in the tier system.
"Reusable behaviors are nice for users. That should be a good reason to implement them. The point of Enigma is not to be easy on you, it's to help users in making their games. A system should be pretty near impossible before you start considering implementation difficulty over usefulness."
My argument wasn't "it's difficult, therefore it's not worth it." In fact, it was my impression that said argument hurts you more. "Reusable behaviors are nice for users." You're advocating them because they are nice... for users. But they aren't nice for me? ENIGMA being so close to C++, how can what helps the users fail to help me?
The users aren't making direct use of the component system if it is used only by the compiler as a method to switch systems, now are they? So how does that help the users? This is why I thought it was to help me. To help developers in general. That ENIGMA would be gloriously easy to extend for all developer, myself included. Because all you have to do now is enumerate all the possible components and pass one as a flag to all the instances you are creating instead of just adding a single, nasty, old #define in there. So which is it? Whose life is this improving?
Most will never even know how ENIGMA organizes its lower systems, much less need to know. Of course, here I'm using your premise "Reusable behaviors are nice for users" instead of that the system will be a pain in the ass to implement but that it should be the developers' (aka, my) job to grin and bear it for the "users." Which users, exactly? What will users do knowing that their objects are component based instead of tier based?
The only way that what you're saying isn't self-contradictory is if you're trying to imply that my parser life becomes difficult, but that it will make the system much easier to develop for later. That's not true, either. Just naming the bottom tier in a text file called configure would suffice for me, maybe giving a description after it and lower tiers, all optionally. Your system requires that all components and all possible component extensions that may implement variables be named, that I may actually collect a sufficient list of locals for the accessors. And any way you try to contort your idea, I still need that list. That's a real pain in the ass for myself and any developers. With tiers, you just extend them and go. In fact, I'll already have a planar and intend to have a spacial tier in. Developers will just extend the one they require (planar for 2D, spacial for 3D, some new one if neither apply) with an alternative graphics system, or extend the current graphics tier with a new collision system (like box2D). I don't cater to games that want to implement a 3D mesh rendering tier but wish to use Colligma, a pixel-perfect, 2D collision system, on top of that. How would such a system make sense? You or miky gave an example of a game that used vector graphics but still wished to use Colligma. Well, I don't know why, but okay; the tier system would require recompile of collision functions (Colligma is separate in both cases) because the sprite tier was edited; your system, at this point, would also, as Sprite/RasterSprite would no longer be used. Where's the gain?
At this juncture, most of the benefits you've proposed once upon a time (such as swapping out graphics systems on runtime) you have dropped, without warning and with little regard afterward. Those that you have not are slowly unraveling as I demand more code. Here I'll ask for instance_nearest. Here's mine:
Code: (cpp) [Select]
#include <math.h>
#include "var_cr3.h"
#include "planar_object.h"
int instance_nearest(int x,int y,int obj)
{
double dist_lowest=-1,retid=-4;
int objind=(int) obj;
double xl,yl;
for (enigma::instance_iterator=enigma::instance_list.begin(); enigma::instance_iterator != enigma::instance_list.end(); enigma::instance_iterator++)
{
if ((*enigma::instance_iterator).second->object_index==objind)
{
xl = ((enigma::object_planar*)enigma::instance_iterator->second)->x;
yl = ((enigma::object_planar*)enigma::instance_iterator->second)->y;
const double dstclc = hypot(xl,yl);
if (dstclc < dist_lowest or dist_lowest == -1)
{
dist_lowest = dstclc;
retid = (*enigma::instance_iterator).second->id;
}
}
}
return retid;
}
I'm interested to see where the name of the component and location of the instance comes from.
2035
Off-Topic / Re: i am mahfreenameh
« on: May 10, 2010, 07:06:40 pm »
Yes, you are. You are. And don't let anyone tell you that you're not.
2036
Proposals / Re: Tiering vs Components
« on: May 10, 2010, 06:18:38 pm »
Rusky, your argument has started a motion towards how everything wrong with the component system is wrong with the tier system, and that's a big part of what I've been saying from the start. Now we've established that dependency resolution is harder with components; that doesn't help me.
"Looking up names in parents is just as much work as looking up names in *Component-type members." You're getting this from where? My system parses C++; it, by design, HAS to traverse structures' parents to gain insight into members. All I have to do is invoke that same system, not invoke some hackish loop for any membered types beginning with "component_". I can name the tiers whatever I want; if it's inherited, it's already implemented.
Reusable behaviors are nice for users; not for me, and I assume not for other developers. Other developers should design the system with special purposes in mind. General behavior code -> Hasty generalizations about what the code should do -> Haste -> Waste.
As a proposal for a way to help users out, components are great, and I will probably look into an implementation. However, they only serve to clutter engine code; all the examples you named (especially handles in build mode), I have already planned to implement using a more general means. Since the compiler structures events into their respective member functions, I can insert anything I want. This is how vector/force variables such as hspeed, vspeed, gravity, etc. are handled. I truly have no personal need for components.
I'd prefer debug behaviors be preprocessed out; that's how they work in var, which only complains on undefined access and checks for division by zero during debug. However, I do understand the beauty in using functions for some such options; aborting on non-fatal errors is handled using a function at the moment, but that was because of laziness and I will eventually look for a way to remove the need to do so.
I also know how useful function pointers are; I've used them since R1 to enable room create codes. Instead of making each room a structure, they all share one which is assigned a create code on load time. It's relatively low-cost considering how infrequently rooms are changed.
Now something I will be using function pointers for in the future is allowing users to compile new objects into a DLL, then linking in that DLL with a system vaguely resembling your component system; each new object provides a function pointer which calls the constructor of the new object struct; that function is called on create, and it adds itself to the instance lists flawlessly, which takes care of the rest. "The rest" being event execution and instance iteration.
I know I'm hard on new proposals and it can be indistinguishable from ignorance, but I'm not lost in any of this. I've had a plan for a long, long time, regardless of how long its taking to realize it. Components weren't a part of this plan; they'd grossly slow me down and require a deal of recoding. Not to mention there's still considerations of how much should be included in your parent component object so functions like sprite_add can be reused; it doesn't seem possible without adding another--yes--tier. For instances where some code can be shared, but others can't be, I mean. The system just isn't ideal enough for me to say, "components are the way to go!"
"Looking up names in parents is just as much work as looking up names in *Component-type members." You're getting this from where? My system parses C++; it, by design, HAS to traverse structures' parents to gain insight into members. All I have to do is invoke that same system, not invoke some hackish loop for any membered types beginning with "component_". I can name the tiers whatever I want; if it's inherited, it's already implemented.
Reusable behaviors are nice for users; not for me, and I assume not for other developers. Other developers should design the system with special purposes in mind. General behavior code -> Hasty generalizations about what the code should do -> Haste -> Waste.
As a proposal for a way to help users out, components are great, and I will probably look into an implementation. However, they only serve to clutter engine code; all the examples you named (especially handles in build mode), I have already planned to implement using a more general means. Since the compiler structures events into their respective member functions, I can insert anything I want. This is how vector/force variables such as hspeed, vspeed, gravity, etc. are handled. I truly have no personal need for components.
I'd prefer debug behaviors be preprocessed out; that's how they work in var, which only complains on undefined access and checks for division by zero during debug. However, I do understand the beauty in using functions for some such options; aborting on non-fatal errors is handled using a function at the moment, but that was because of laziness and I will eventually look for a way to remove the need to do so.
I also know how useful function pointers are; I've used them since R1 to enable room create codes. Instead of making each room a structure, they all share one which is assigned a create code on load time. It's relatively low-cost considering how infrequently rooms are changed.
Now something I will be using function pointers for in the future is allowing users to compile new objects into a DLL, then linking in that DLL with a system vaguely resembling your component system; each new object provides a function pointer which calls the constructor of the new object struct; that function is called on create, and it adds itself to the instance lists flawlessly, which takes care of the rest. "The rest" being event execution and instance iteration.
I know I'm hard on new proposals and it can be indistinguishable from ignorance, but I'm not lost in any of this. I've had a plan for a long, long time, regardless of how long its taking to realize it. Components weren't a part of this plan; they'd grossly slow me down and require a deal of recoding. Not to mention there's still considerations of how much should be included in your parent component object so functions like sprite_add can be reused; it doesn't seem possible without adding another--yes--tier. For instances where some code can be shared, but others can't be, I mean. The system just isn't ideal enough for me to say, "components are the way to go!"
2037
Proposals / Re: Tiering vs Components
« on: May 10, 2010, 02:08:12 pm »
I meant that other developers are mythological creatures. But yes, as far as ENIGMA is concerned, components still seem unrealistic to me as well.
2038
Proposals / Re: Tiering vs Components
« on: May 10, 2010, 09:54:33 am »
Yes, you can get rid of things by including a null pointer, which is about a quarter the size of a typical tier in my system, not to mention I have no idea how that would come to behave, as I'm not sure I can tell what an implementation of draw_sprite would look like nor where it would be located. Would you mind showing me that?
Either way, it's not that it's just difficult to get rid of everything; it's difficult to add things, too. With the tier system, all I need to know is the name of the bottom tier.
I've given your component system so much thought that I literally spent the night dreaming about it and rolling over every hour as a consequence. I see that the beautiful thing about this system is that the components can be swapped out just by passing a pointer different child component to the structure. That's great. Not for here. I vastly prefer to just include the appropriate header and link the appropriate source from a well-organized system of folders.
An argument that keeps popping up is the ability to change out systems at run time. That's catastrophic. Let's look at what systems we can actually exchange...
Now, that table is on a per-OS basis; it doesn't account for the benefits when moving platforms. This is because you can't move a C++ module from platform to platform, end of story.
Feel free, of course, to point out some benefit I've missed; your best bet is to show how a run-time plug-and-play debug mode would be useful.
I can't see how a debugger component would help me at all; I have sovereign control over the types of every variable. I can replace all local variables from "type varname;" to "debug_proxy<type> varname;", and I can do it without any effort at all. I never once felt the need for a system such as this to help me.
Further, I don't understand what could be added to the functions of a component to help with debugging. Users are supposed to be able to assume that the functions in ENIGMA behave as they say they will. If they don't, that's my problem, and I know how to work GDB.
And yes, you've again named more vague things that I can do with this system but will probably never want/need to do. Show me an instance in which you, the advocate of this method, would find reusable behaviors useful. Further, as I've been hinting at, dependency resolution isn't simpler with components. In fact, it seems far more difficult. The tier system lets my parser figure out what all the implemented locals are based only on the name of the top tier. I can't think of a method of determining the contents of your components without being told, and it seems that you can't, either. You yourself mentioned earlier that the "whole system will be implemented with them in mind;" this is contrary to the point you're trying to make about components--that they are more modular and have less dependencies requiring recompilation.
In fact, your system suffers the same problems as my old system, before tiers; it has to either include the end result of the system (being the definition of struct Object) before it can make use of its members--meaning that it needs basic definitions of each (if only your small parent classes)--, or you can work around knowing the entirety of Object by passing, say, RasterSprite to Colligma via its constructor, as it seems you've done. This is remarkably similar to what is happening with the tiers. It comes down to the difference being that you can pass something other than RasterSprite, or a modified RasterSprite, to Colligma without relying on the preprocessor, which I love and you hate.
But, just like in my tier system, if you want to edit the RasterSprite component, the Colligma component needs recompiled; editing a component will produce the same amount of recompilation as editing a tier in my current system. It's extending a component that yours can do without recompiling everything (the extension being done itself tiering, I might add). Even then, you still need to recompile the main source, because now the available locals have changed and the wrong component will be allocated otherwise, (you'll get the shorter RasterSprite than you ultimately ended up using), leading to misbehavior (in the form of calling the short function if all the code is stored in the components as you are suggesting, or a segfault otherwise).
With this system, I just include the highest tier I need in each source, and then include the correct set of sources for the system I want.
Also, ENIGMA is not supposed to be just a GM clone; that's why it implements a number of functions that GM Does not, in addition to the entirety of the C/C++ libraries. What more do you want, other than pointers everywhere, which makes life no easier for the users, much harder for me, and only possibly easier for future developers, which are apparently mythological creatures.
Either way, it's not that it's just difficult to get rid of everything; it's difficult to add things, too. With the tier system, all I need to know is the name of the bottom tier.
I've given your component system so much thought that I literally spent the night dreaming about it and rolling over every hour as a consequence. I see that the beautiful thing about this system is that the components can be swapped out just by passing a pointer different child component to the structure. That's great. Not for here. I vastly prefer to just include the appropriate header and link the appropriate source from a well-organized system of folders.
An argument that keeps popping up is the ability to change out systems at run time. That's catastrophic. Let's look at what systems we can actually exchange...
Collision system | Any motivation to change this out would result from the speed increase. This should vary only proportionally from system to system; changing out the system at run time would be of no benefit. |
Graphics systems | This seems useful at first, but the only platform to which this applies is Windows. Every other platform only offers one system. And on Windows, it is safe to assume that DirectX vastly outperforms GL, because that's what lazy cardmakers invest in (think Intel). On Windows, DirectX would always be the choice for speed; GL would be offered mostly for people whose philosophy forbids DX. |
Sound System | Same case as graphics. |
Window System | Each platform has only one at the moment; I chose to code each natively because that would likely be the fastest method. This is the most fundamental change between platforms. |
Debug System | Much of ENIGMA is based on the thought that debugging should be done -prior- to release. I can't think of a good reason to put debug information for my game at the hands of its users; people got pretty pissed about GM's debug mode being invocable at the flip of a bit. |
Feel free, of course, to point out some benefit I've missed; your best bet is to show how a run-time plug-and-play debug mode would be useful.
I can't see how a debugger component would help me at all; I have sovereign control over the types of every variable. I can replace all local variables from "type varname;" to "debug_proxy<type> varname;", and I can do it without any effort at all. I never once felt the need for a system such as this to help me.
Further, I don't understand what could be added to the functions of a component to help with debugging. Users are supposed to be able to assume that the functions in ENIGMA behave as they say they will. If they don't, that's my problem, and I know how to work GDB.
And yes, you've again named more vague things that I can do with this system but will probably never want/need to do. Show me an instance in which you, the advocate of this method, would find reusable behaviors useful. Further, as I've been hinting at, dependency resolution isn't simpler with components. In fact, it seems far more difficult. The tier system lets my parser figure out what all the implemented locals are based only on the name of the top tier. I can't think of a method of determining the contents of your components without being told, and it seems that you can't, either. You yourself mentioned earlier that the "whole system will be implemented with them in mind;" this is contrary to the point you're trying to make about components--that they are more modular and have less dependencies requiring recompilation.
In fact, your system suffers the same problems as my old system, before tiers; it has to either include the end result of the system (being the definition of struct Object) before it can make use of its members--meaning that it needs basic definitions of each (if only your small parent classes)--, or you can work around knowing the entirety of Object by passing, say, RasterSprite to Colligma via its constructor, as it seems you've done. This is remarkably similar to what is happening with the tiers. It comes down to the difference being that you can pass something other than RasterSprite, or a modified RasterSprite, to Colligma without relying on the preprocessor, which I love and you hate.
But, just like in my tier system, if you want to edit the RasterSprite component, the Colligma component needs recompiled; editing a component will produce the same amount of recompilation as editing a tier in my current system. It's extending a component that yours can do without recompiling everything (the extension being done itself tiering, I might add). Even then, you still need to recompile the main source, because now the available locals have changed and the wrong component will be allocated otherwise, (you'll get the shorter RasterSprite than you ultimately ended up using), leading to misbehavior (in the form of calling the short function if all the code is stored in the components as you are suggesting, or a segfault otherwise).
With this system, I just include the highest tier I need in each source, and then include the correct set of sources for the system I want.
Also, ENIGMA is not supposed to be just a GM clone; that's why it implements a number of functions that GM Does not, in addition to the entirety of the C/C++ libraries. What more do you want, other than pointers everywhere, which makes life no easier for the users, much harder for me, and only possibly easier for future developers, which are apparently mythological creatures.
2039
Proposals / Re: Tiering vs Components
« on: May 09, 2010, 07:43:25 pm »
What I meant was, what if I no longer wish to have x at all? What becomes of the accessor? How do I remove it? "Pretty much always be there"? I thought the point of this was to allow easy removal.
The tier system has no regard for the implementation of functions; it only stores the variables. Implementations are added by linking in the desired source file, which is related only in that it includes the highest tier it requires. I'm not interested in zero recompilation; the game still needs recompiled to move from platform to platform and code still needs compiled when it is to be tested. Tiers will only cause any additional recompile when a lower tier is edited, which is essentially never.
I see how all this stuff could be done runtime; what you're describing is a plugin system. Moreover, it's contrary to the point of ENIGMA. ENIGMA is a compiler. It is developed to specialize a game for a platform of the user's choice. I have no behaviors I want to filter that I wouldn't feel better about putting in a single #if. Reusable behaviors aren't useful considering the vast change required to justify dumping a tier. What little behavior could be reused would look better in place where it can be double checked.
A component system would be impossibly useful for a system that isn't so cut-and-dry as storing locals in a game development program. Without a doubt. However, this is no divine revelation, and despite the massive assortment of features it could offer, I have no use for them.
Perhaps if my goal were to have every game so easily modable as Valve games, that would be a good option. That's certainly not my intention.
The tier system has no regard for the implementation of functions; it only stores the variables. Implementations are added by linking in the desired source file, which is related only in that it includes the highest tier it requires. I'm not interested in zero recompilation; the game still needs recompiled to move from platform to platform and code still needs compiled when it is to be tested. Tiers will only cause any additional recompile when a lower tier is edited, which is essentially never.
I see how all this stuff could be done runtime; what you're describing is a plugin system. Moreover, it's contrary to the point of ENIGMA. ENIGMA is a compiler. It is developed to specialize a game for a platform of the user's choice. I have no behaviors I want to filter that I wouldn't feel better about putting in a single #if. Reusable behaviors aren't useful considering the vast change required to justify dumping a tier. What little behavior could be reused would look better in place where it can be double checked.
A component system would be impossibly useful for a system that isn't so cut-and-dry as storing locals in a game development program. Without a doubt. However, this is no divine revelation, and despite the massive assortment of features it could offer, I have no use for them.
Perhaps if my goal were to have every game so easily modable as Valve games, that would be a good option. That's certainly not my intention.
2040
Proposals / Re: Tiering vs Components
« on: May 09, 2010, 06:55:42 pm »
So how do I pick accessors when a component is removed? Having the accessors enumerated in the Object structure...in fact, all of this code, really, is as good as just hard coding in all the locals and adding a pointer to store more.
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 »