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

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.

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!"

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.

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...
Collision systemAny 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 systemsThis 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 SystemSame case as graphics.
Window SystemEach 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 SystemMuch 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.
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.

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.

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 fact, all of this code, really, is as good as just hard coding in all the locals and adding a pointer to store more.

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?

Proposals / Re: Tiering vs Components
« on: May 09, 2010, 01:45:27 PM »
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.

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.

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.

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.

Off-Topic / Re: ACTA
« on: May 08, 2010, 08:08:10 PM »

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