Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Josh @ Dreamland

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?

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.

Proposals / Re: Tiering vs Components
« on: May 08, 2010, 01:48:52 PM »
Here is the snippet, as functions right now in ENIGMA:
Code: [Select]

#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;
      object_collisions(unsigned, int);
      virtual ~object_collisions();


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.

Proposals / Re: Tiering vs Components
« on: May 08, 2010, 01:40:40 PM »
- 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);

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.

Proposals / Re: Tiering vs Components
« on: May 08, 2010, 12:41:48 PM »
Tier System

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) + ")");

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.

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.

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.

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.

Proposals / Re: Tierable Systems
« on: May 06, 2010, 04:44:38 PM »
"If they simply wanted to make a quick text editor do they really need the graphics library? Or the collision? Audio?

Thought not, you need to look at the benefits of a component based framework rather than your own miss-guided attempts at optimization."

I'm thinking I didn't come across clear enough. The difference between the tiering and component system is in two places.
1) The tier system doesn't require me to parse in accessors nor tax the CPU To lookup, store, push, and jump to that accessor.
2)  If you remove the Graphics Tier, the Collision Tier goes with it; that's the only problem. It is very easily removed, and doesn't leave residue, unlike a component system.

So, the only drawback of mine is that you can't have collisions without graphics. I don't even see that as a problem.

And another thing, there is no audio tier. Nor audio component, if I'd used that system. Sounds in Game Maker don't use local variables, and so don't need a tier.

Rusky's component idea makes tiers entirely removable independent of one another, but uses slightly more memory and CPU time. Hardly a loss, but hardly a gain. Especially since if I thought I could have a collision tier that didn't access members of the graphics tier (such as image_index and image_angle), I wouldn't have placed it below that tier.

Further, this will not increase compile times except when you go from compiling a game that does away with a tier to compiling one that does not do away with a tier. In fact, even in that case, I can probably just leave all tiers in until Release compile.

No alignment is hard-coded; it is just calculated based on the size of each inherited tier. If youY want to edit a lower tier, a recompile is necessary. However, what I didn't realize when I originally posted this is that the system attached to each tier is basically intertwined with each higher tier. Adding to tiers is difficult, yes, but there's no point, I realize, unless you are extending the list of available functions, in which case the user will have to recompile it anyway. There's essentially no point to using any other system; rest assured, your fears are in vein VAIN. VAIN. YOUR FEARS ARE IN VAIN.

Issues Help Desk / Re: #define?
« on: May 05, 2010, 08:20:02 PM »
Right now, you can't, as I broke Whitespace. :3
In the near future, you will just go to Enigma Settings and click Definitions, then add them there.

Proposals / Operators .., =, :=
« on: May 05, 2010, 07:40:42 PM »
At present, only operator= is implemented, of the above. I was thinking about implementing a couple neat tricks.

1) Copy-on-write, as mentioned earlier. The ability to set variables to arrays simply with operator=. Only problem; writing will actually be slow, unlike if operator= simply copied the first element as it does in GM.
2) Array sub-arrays via operator.., which does not exist in C++. Basically, when you say varname[2..3], you get the contents of varname[2] and varname[3]. This could be handled by replacing [x..y] with .subArray(x,y). This requires only that the class being accessed has subArray defined, so user-implemented classes could easily provide the same functionality. (As an alternative, an overloadable function could be used, since C++ isn't so easily modified as, say, JavaScript.
3) Referencing vs. Hard copying; should subArray just copy the contents over, as subString does?

So, I was thinking about hijacking operator:=, which does not exist in C++. This could be used to indicate that data should be hard copied instead of  perhaps just turn copying the entire array on via a setting. My original idea was to use := to indicate a hard copy, but such would be difficult without some class tinkering.

Yadda yadda, definitely considering implementing [..] as a wrapper to subArray, not sure what subArray should reference vs what it should copy. Fin.

Proposals / Re: Custom Widgets
« on: May 05, 2010, 07:25:38 PM »
What does that mean for my request? :P

Proposals / Re: On Settings and Dependencies
« on: May 05, 2010, 07:21:11 PM »
Haha, indeed. I forgot I did not, after I spent the effort implementing them. In fact, I guess they are untested except defaults. :D