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 »
2041
Proposals / Re: Tiering vs Components
« on: May 09, 2010, 06:49:06 pm »
A single text file? So systems that want to add to that file have to fight over it? Or just check every line to make sure they have their input?
...How is this system more extensible than tiers, again?
...How is this system more extensible than tiers, again?
2042
Proposals / Re: Tiering vs Components
« on: May 09, 2010, 01:45:27 pm »
Luis--
I didn't say your explanation was wrong, I said it was flat. And that was entirely an example, but is how most of the programs I've looked at (namely, Unity) handle such. And the diagram took roughly 45 minutes in InkScape. I figured I'd invest that much time in it because I can just use it as docs later.
Rusky--
No, it doesn't. I need to know how to construct your individual components: where does the pointer come from I'm passing to the constructors?
Inline accessors for built-ins... Okay, how do I know what's a built-in? And how/where are the accessors implemented? Your system doesn't use inheritance, so the accessors have to come from somewhere global or in the Object struct.
I didn't say your explanation was wrong, I said it was flat. And that was entirely an example, but is how most of the programs I've looked at (namely, Unity) handle such. And the diagram took roughly 45 minutes in InkScape. I figured I'd invest that much time in it because I can just use it as docs later.
Rusky--
No, it doesn't. I need to know how to construct your individual components: where does the pointer come from I'm passing to the constructors?
Inline accessors for built-ins... Okay, how do I know what's a built-in? And how/where are the accessors implemented? Your system doesn't use inheritance, so the accessors have to come from somewhere global or in the Object struct.
2043
Proposals / Re: New Rule:
« on: May 09, 2010, 11:50:21 am »
These debates make for better software. I think.
Besides, I'm usually not so avidly opposed to an idea as this one.
Besides, I'm usually not so avidly opposed to an idea as this one.
2044
Proposals / Re: Tiering vs Components
« on: May 08, 2010, 11:19:40 pm »
Antidote, don't be so quick to judge. I value flexibility quite highly; it's part of ENIGMA's name. I don't see the benefits of the component system as being worth their cost. I see the tier system as quite extensible; that's why I'm bothering to implement it. Just because the component system is likewise (and probably even more) extensible doesn't mean that the tier system does not allow for it. And if I were truly stuck in my ways, this thread wouldn't exist.
"Well, that's how open-source works. You get fed up with something, you implement it yourself on a fork, they decide that they like your system and pull it into mainstream."
The former is constantly happening here. The second will never happen; people would rather just bitch about how much easier ENIGMA developer's lives could be if I did X, Y, and Z. Well, as the one responsible for 90% of ENIGMA's code, I can say this system would not make 90% of the developers' lives any easier. Granted, that's a terribly pessimistic view, and of course begs the question of, "would more people develop if all these provisions were put into place?". The answer is no, but even assuming it is a yes, I'll follow this with a description.
Attached is an SVG that roughly represents this idea. Luis's depiction is a bit flat.
Here's a PNG render:
If I were to draw up this component system, it would show a pointer for -every- component in the main object, meaning I'd need a way to enumerate all the components, which I'm waiting for Rusky to provide. The tier system needs only the name of the bottommost tier, making internal extension effortless and making adding tiers to the end as simple as one line of replacement. I'm working on ceasing that line from being hard-coded.
It may turn out that neither of these systems are right for the job, but I'm getting more and more certain that tiers are closer.
At this point, I've placed my vote. I might reconsider when those two questions get answered. Of course, the answers will either be paired with attack or riddled with holes, so there will probably be more questions either way.
"Well, that's how open-source works. You get fed up with something, you implement it yourself on a fork, they decide that they like your system and pull it into mainstream."
The former is constantly happening here. The second will never happen; people would rather just bitch about how much easier ENIGMA developer's lives could be if I did X, Y, and Z. Well, as the one responsible for 90% of ENIGMA's code, I can say this system would not make 90% of the developers' lives any easier. Granted, that's a terribly pessimistic view, and of course begs the question of, "would more people develop if all these provisions were put into place?". The answer is no, but even assuming it is a yes, I'll follow this with a description.
Attached is an SVG that roughly represents this idea. Luis's depiction is a bit flat.
Here's a PNG render:
If I were to draw up this component system, it would show a pointer for -every- component in the main object, meaning I'd need a way to enumerate all the components, which I'm waiting for Rusky to provide. The tier system needs only the name of the bottommost tier, making internal extension effortless and making adding tiers to the end as simple as one line of replacement. I'm working on ceasing that line from being hard-coded.
It may turn out that neither of these systems are right for the job, but I'm getting more and more certain that tiers are closer.
At this point, I've placed my vote. I might reconsider when those two questions get answered. Of course, the answers will either be paired with attack or riddled with holes, so there will probably be more questions either way.
2046
Proposals / Re: Tiering vs Components
« on: May 08, 2010, 04:49:06 pm »
I didn't ask for "id stuff"; I asked for an implementation of instance_create as applied to this code. "They get passed to Object's constructor." Show me this.
And I asked for a method of determining what I prepend to local variables such as "x" and "y." How do I know that they are for the "sprite" component? An extensible system should have nothing of that hard coded; my tier system certainly doesn't. In that system, I simply traverse all the parents of the local object, which is a normal part of C++ qualifier resolution. How do I find the components in yours?
Moreover, I need to be able to identify all components in order to devise the constructors for the component-based objects. Where do I get that list?
And I asked for a method of determining what I prepend to local variables such as "x" and "y." How do I know that they are for the "sprite" component? An extensible system should have nothing of that hard coded; my tier system certainly doesn't. In that system, I simply traverse all the parents of the local object, which is a normal part of C++ qualifier resolution. How do I find the components in yours?
Moreover, I need to be able to identify all components in order to devise the constructors for the component-based objects. Where do I get that list?
2047
Proposals / Re: Tiering vs Components
« on: May 08, 2010, 02:01:01 pm »
Retro: The point only seems to be organization on this level; this is about adding and removing functionality with as little a ripple as possible.
So yes, I'm still waiting on an explanation for the origin of "sprite." and the constructor parameters in all that mess.
So yes, I'm still waiting on an explanation for the origin of "sprite." and the constructor parameters in all that mess.
2048
Proposals / Re: Tiering vs Components
« on: May 08, 2010, 01:48:52 pm »
Here is the snippet, as functions right now in ENIGMA:
I can not move them back into Object, as that will create an access problem and/or screw up your component. They will be accessing different instances of like-named variables.
How do I know they are sprite.x and sprite.y? What tells me that?
Yes, that was obvious.
Also, instance_create shows me from where you are exhuming the initial parameters to your constructors.
Code: [Select]
#ifndef _COLLISIONS_OBJECT_H
#define _COLLISIONS_OBJECT_H
#include "transform_object.h"
namespace enigma
{
struct object_collisions: object_transform
{
//Bit Mask
var mask_index;
var solid;
//Bounding box
var bbox_top;
var bbox_bottom;
var bbox_left;
var bbox_right;
//Constructors
object_collisions();
object_collisions(unsigned, int);
virtual ~object_collisions();
};
}
#endif
I can not move them back into Object, as that will create an access problem and/or screw up your component. They will be accessing different instances of like-named variables.
How do I know they are sprite.x and sprite.y? What tells me that?
Yes, that was obvious.
Also, instance_create shows me from where you are exhuming the initial parameters to your constructors.
2049
Proposals / Re: Tiering vs Components
« on: May 08, 2010, 01:40:40 pm »
Problems:
- Lots of "pretending," which I will assume can be overlooked.
- "sprite.x", "sprite.y"; am I to traverse every pointer in the system to determine what locals are implemented? In the tier system, I just check ancestors, which is natural. Here, it seems I'm expected to check all members, too.
Perhaps it's also good to show an instance_create(), which is generated code. For this, we can assume the constructor takes an X and Y parameter as well as the other two (instance_create is designed for a 2D system, hence parameters X and Y), and adds the instance into the network for execution. If this is incompatible with a component system, give an alternative.
instance_create(): Tier System
- Lots of "pretending," which I will assume can be overlooked.
- "sprite.x", "sprite.y"; am I to traverse every pointer in the system to determine what locals are implemented? In the tier system, I just check ancestors, which is natural. Here, it seems I'm expected to check all members, too.
Perhaps it's also good to show an instance_create(), which is generated code. For this, we can assume the constructor takes an X and Y parameter as well as the other two (instance_create is designed for a 2D system, hence parameters X and Y), and adds the instance into the network for execution. If this is incompatible with a component system, give an alternative.
instance_create(): Tier System
Code: [Select]
void instance_create(int x, int y, int id)
{
switch (id)
{
case object0:
new OBJ_object0(x,y,enigma::max_id++,id);
break;
}
}
2050
Proposals / Re: Tierable Systems
« on: May 08, 2010, 12:44:51 pm »
Here's a better idea; instead of wasting time arguing with words, why don't we get back to the purpose of this venture and start demonstrating with code? See the nearby poll under this forum and submit your idea of this system in a similar fashion.
2051
Proposals / Re: Tiering vs Components
« on: May 08, 2010, 12:41:48 pm »
Tier System
Instantiable code:
Collision code:
Create event code:
Instantiable code:
Code: [Select]
struct ultimate_tier : collision_tier //This includes collision and all lower tiers
{
//worthless locals shared by all objects go here.
ultimate_tier(): collision_tier() { } //takes care of id and object_index, which are const; myevent_create is in this case inherited from the first tier.
ultimate_tier(const unsigned ID, const int ObjectID): collision_tier(ID,ObjectID) { } //takes care of id and object_index, which are const
}
struct OBJ_object0 : ultimate_tier //This again includes collision and all lower tiers
{
var my_local; //Here is the local we're using
enigma::variant myevent_create();
OBJ_object0(): ultimate_tier() { myevent_create(); } //takes care of id and object_index, which are const; myevent_create is in this case inherited from the first tier.
OBJ_object0(const unsigned ID, const int ObjectID): ultimate_tier(ID,ObjectID) { myevent_create(); } //takes care of id and object_index, which are const
}
Collision code:
Code: [Select]
#include "collision_tier.h"
bool check_collision(int id)
{
object_basic *o = get_object_by_id(int); //Fetch an instance of a pointer to the type of the lowermost tier from the instance array
object_collision *c = (object_collision*) o; //Assume that it contains locals for our tier.
return check_rotated_rectangle(c->x,c->y,c->bbox_left,c->bbox_right,c->bbox_top,c->bbox_bottom,c->image_angle); //Check and return
}
Create event code:
Code: [Select]
enigma::variant OBJ_object0::myevent_create()
{
show_message("Hello, world! I am at (" + string(x) + "," + string(y) + ")");
}
2052
Proposals / Tiering vs Components
« on: May 08, 2010, 12:37:01 pm »
It looks like it's time once again for a poll.
Before voting, give Miky / Rusky a chance to present their idea of a Component system, as applicable to ENIGMA.
If you have a separate proposal, post it in the same format as I am about to post mine. This format should include the following:
- Code for an object called object0 containing a local "my_local"
----- This should include ALL code required to include necessary locals, particularly those needed throughout the rest of this demonstration
- Code for a simple collision function, check_collision(int id), returning bool, utilizing these hypothetical functions:
----- get_object_by_id(int), returning whatever the system requires (probably a pointer)
----- check_rotated_rectangle(x,y,bbox_left,bbox_right,bbox_top,bbox_bottom,image_angle); returning bool
- A create event code that shows message "Hello, world! I am at (<x>,<y>)", as it will look when compiled.
My code will have the official names in it, except where a substitute has been given above explicitly. It doesn't really matter what return types are if not specified.
DO NOT vote before a similar description is available for the Component system.
Moreover, I'd say requesting additional code on the behalf of either/any party is fair game.
Before voting, give Miky / Rusky a chance to present their idea of a Component system, as applicable to ENIGMA.
If you have a separate proposal, post it in the same format as I am about to post mine. This format should include the following:
- Code for an object called object0 containing a local "my_local"
----- This should include ALL code required to include necessary locals, particularly those needed throughout the rest of this demonstration
- Code for a simple collision function, check_collision(int id), returning bool, utilizing these hypothetical functions:
----- get_object_by_id(int), returning whatever the system requires (probably a pointer)
----- check_rotated_rectangle(x,y,bbox_left,bbox_right,bbox_top,bbox_bottom,image_angle); returning bool
- A create event code that shows message "Hello, world! I am at (<x>,<y>)", as it will look when compiled.
My code will have the official names in it, except where a substitute has been given above explicitly. It doesn't really matter what return types are if not specified.
DO NOT vote before a similar description is available for the Component system.
Moreover, I'd say requesting additional code on the behalf of either/any party is fair game.
2053
Proposals / Re: Tierable Systems
« on: May 08, 2010, 12:01:54 pm »
"Completely reprogram everything that uses it"
If you mean a sixteen line header, then yes. That's exactly what you do.
Code isn't stored in the tiers, only locals. Each tier implements roughly ten original lines. Other lines include the previous tier, license the file, declare the structure by name, and call the parent constructors.
The sole purpose of the tier system is to organize local variables so that concerned systems, stored in separate, non-tiered files, can access them in an object without needing to know what all is included. Using a component system, we still need a list of components to store a pointer for. Your idea of a decorator is quite similar to what is actually going on, from one parent point.
Forking a tier is not a difficult task.
Also, I meant "outperform" in an all-inclusive sense, not just in the sense that mine is faster. Your idea of "over optimization" pisses me, and a number of others, off.
If you mean a sixteen line header, then yes. That's exactly what you do.
Code isn't stored in the tiers, only locals. Each tier implements roughly ten original lines. Other lines include the previous tier, license the file, declare the structure by name, and call the parent constructors.
The sole purpose of the tier system is to organize local variables so that concerned systems, stored in separate, non-tiered files, can access them in an object without needing to know what all is included. Using a component system, we still need a list of components to store a pointer for. Your idea of a decorator is quite similar to what is actually going on, from one parent point.
Forking a tier is not a difficult task.
Also, I meant "outperform" in an all-inclusive sense, not just in the sense that mine is faster. Your idea of "over optimization" pisses me, and a number of others, off.
2054
Proposals / Re: Tierable Systems
« on: May 07, 2010, 10:39:50 pm »
I didn't realize we'd defined accessor to imply a function. Operator-> is an accessor that I would need to parse in, instead of using the implicit this->. Assuming there is no function (which would be necessary in some cases), the push is dropped.
Once again, the need for specific combinations in the tier system is not a problem for flexibility simply because there is no other order the tier system could operate in. I failed to understand this when I opened this for discussion. Adding, for example, a "z" variable to the "planar" tier makes it no longer a "planar" tier; it doesn't make sense for the lower tiers to inherit from it, as the lower tiers are intended for access by a system designed around the game being 2-Dimensional. Having a component for this won't matter; it'll just change the position of the "`z' is not a member" error if a source file tries to access that local. I don't see any amount of flexibility; changing a lower tier for any good reason implies a need to change the systems inheriting from them. Find a counter example instead of screaming "Flexibility" and I might consider what you are saying.
Also, understand that in this discussion, my arguments are never in vain. I am the only one coding for this project; that's the sad fact about it. Our friends at Canonical recently asserted, "This isn't a democracy." Granted, that's an assholish move, but that's what it comes down to. You have the burden of proof, always, because I'm coding. You are the one that needs to enumerate plenty of examples of where your system outperforms mine. "Flexibility," as a general term applied to nothing, doesn't count.
I've made large changes in the past when someone has provided a genuinely better idea; usually the fact of the idea being better has been obvious, but I know Luda threw me at least one instance where that wasn't the case. As it stands, each tier uses variables from -every- inherited tier. Meaning recompile rates for the systems would be the same anyway if, for example, the type of "x" was changed from "double" to "int." I in fact see no gain with respect to recompilation from using a component system, except in the case that you are only -adding- to a specific component, and each component is tiered itself. That's a decent-sized if, not to mention that I'd consider that an ugly system.
Moreover, a component system for a number of wild, so far unconceived systems can easily be added as a bottom tier, anyway. Not that I can name such a system. A simple variable could be used for bottom_tier_size to skip to the end of the essentials and locate such a system.
What you need to see is that the undefined residuum of flexibility you claim the component system offers is inapplicable to the lower tiers. The -first- instance of a tier that does not depend on every lower tier would be the path tier, which needs to implement path_index but does not need access to the collision tier nor the graphics tier. In this special case, bottom_tier_size would be valued as sizeof(collision_tier) if the graphics and collision systems are in use, or just sizeof(planar_tier) otherwise. There, it would perhaps be logical to implement a component system, which would take up, in itself, 33% of the space used if no component system existed (or 50% on 64 bit systems). The hope would of course be that as more components emerged (which doesn't seem likely), the system would pay for itself. Regardless, there's a lot to consider as far as what is hard coded.
Once again, the need for specific combinations in the tier system is not a problem for flexibility simply because there is no other order the tier system could operate in. I failed to understand this when I opened this for discussion. Adding, for example, a "z" variable to the "planar" tier makes it no longer a "planar" tier; it doesn't make sense for the lower tiers to inherit from it, as the lower tiers are intended for access by a system designed around the game being 2-Dimensional. Having a component for this won't matter; it'll just change the position of the "`z' is not a member" error if a source file tries to access that local. I don't see any amount of flexibility; changing a lower tier for any good reason implies a need to change the systems inheriting from them. Find a counter example instead of screaming "Flexibility" and I might consider what you are saying.
Also, understand that in this discussion, my arguments are never in vain. I am the only one coding for this project; that's the sad fact about it. Our friends at Canonical recently asserted, "This isn't a democracy." Granted, that's an assholish move, but that's what it comes down to. You have the burden of proof, always, because I'm coding. You are the one that needs to enumerate plenty of examples of where your system outperforms mine. "Flexibility," as a general term applied to nothing, doesn't count.
I've made large changes in the past when someone has provided a genuinely better idea; usually the fact of the idea being better has been obvious, but I know Luda threw me at least one instance where that wasn't the case. As it stands, each tier uses variables from -every- inherited tier. Meaning recompile rates for the systems would be the same anyway if, for example, the type of "x" was changed from "double" to "int." I in fact see no gain with respect to recompilation from using a component system, except in the case that you are only -adding- to a specific component, and each component is tiered itself. That's a decent-sized if, not to mention that I'd consider that an ugly system.
Moreover, a component system for a number of wild, so far unconceived systems can easily be added as a bottom tier, anyway. Not that I can name such a system. A simple variable could be used for bottom_tier_size to skip to the end of the essentials and locate such a system.
What you need to see is that the undefined residuum of flexibility you claim the component system offers is inapplicable to the lower tiers. The -first- instance of a tier that does not depend on every lower tier would be the path tier, which needs to implement path_index but does not need access to the collision tier nor the graphics tier. In this special case, bottom_tier_size would be valued as sizeof(collision_tier) if the graphics and collision systems are in use, or just sizeof(planar_tier) otherwise. There, it would perhaps be logical to implement a component system, which would take up, in itself, 33% of the space used if no component system existed (or 50% on 64 bit systems). The hope would of course be that as more components emerged (which doesn't seem likely), the system would pay for itself. Regardless, there's a lot to consider as far as what is hard coded.
2055
Issues Help Desk / Re: #define?
« on: May 07, 2010, 08:50:23 am »
As a matter of fact, it should. XD
The syntax checker doesn't unfold macros itself at the moment; only the parser does. That's easily fixed.
I'm getting the last of my work out of the way this weekend, then I'm nearly 100% free to work on ENIGMA.
The syntax checker doesn't unfold macros itself at the moment; only the parser does. That's easily fixed.
I'm getting the last of my work out of the way this weekend, then I'm nearly 100% free to work on ENIGMA.
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 »