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

2026
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.

2027
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?


2028
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:

Code: (C++) [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.

2029
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.

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

2031
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.

2032
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.

2033
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.

2034
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.

2035
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?

2036
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.

2037
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.

2038
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.

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

2040
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?