ENIGMA Forums

Contributing to ENIGMA => Proposals => Topic started by: Josh @ Dreamland on March 28, 2010, 10:16:04 pm

Title: Tierable Systems
Post by: Josh @ Dreamland on March 28, 2010, 10:16:04 pm
Some people don't want a huge-ass graphics system or collisions system. Different systems can require more variables to operate than others. Switching out systems means incorporating different variables.

Solution:

Code: [Select]
struct parent_basic {
  const unsigned id;
  const int object_index;
  parent_basic(): id(0), object_index(noone) {}
  parent_basic(unsigned x, int y): id(x), object_index(y) {};
};

In the local directory of each graphics system:
Code: [Select]
struct inherit_graphics_GL : parent_basic  {
  int sprite_index;
  int image_index;
  inherit_graphics_GL() {}
  inherit_graphics_GL(int x, int y) parent_basic(x,y) {}
};

Of the collision system, which we assume to require graphics system:
Code: [Select]
struct inherit_collisions_colligma : inherit_graphics_GL   {
  int mask_index;
  inherit_collisions_colligma() {}
  inherit_collisions_colligma(int x, int y) inherit_graphics_GL(x,y) {}
};



Then finally, in the IDE Editable headers in which code is stored:

struct parent_locals :
Code: [Select]
#if USE_GRAPHICS
  #if USE_COLLIGMA
    #define high_tier inherit_collisions_colligma
  #else
    #define high_tier inherit_graphics_GL
  #endif
#else
  #define high_tier parent_basic
#endif

struct parent_locals: high_tier
{
  var health;
  var lives;
  var otherworthlessthings;
  //...
  parent_locals() {}
  parent_locals(unsigned my_id, int my_object_index): high_tier(my_id,my_object_index) {}
};


This is being implemented for testing *now.*

Note: I left out X and Y for brevity. They will be assumed to be needed before collisions but after graphics.
Title: Re: Tierable Systems
Post by: Rusky on March 29, 2010, 09:07:45 am
How about multiple inheritance or a component system so you could combine them in more ways? Collisions, graphics, both or neither?
Title: Re: Tierable Systems
Post by: Josh @ Dreamland on March 29, 2010, 09:44:29 am
I considered it (it was in fact my first thought), but then indexes could end up different between files, and thus a file could end up reading the wrong block of memory to fetch its variable.

Like using int vs a variant type for x and y: changing the size based on multiple inheritance could totally fuck up collision code, as it would suddenly be reading 12 bytes further than where it should be for each variant that became an int.

The solution would be to include the settings file to understand which size it was looking at, but doing so would require recompile, and that is exactly what this tier system is designed to avoid.

Edit: let me clarify.
Each new step in the tier must assume as few sizes as possible from the previous ones. We want systems to be removable or swappable, but allowing a system to be changed can likely impact the behavior of other parts of the system. In this hierarchy, the affected parts will all be lower tiers. For instance, if you removed graphics, the assumption is that you'd have no further need for collisions.

The instance functions can make use of tier one, needing only ID and object index. They'll never even notice if the collision system is removed or changed.

There is still some need for recompile, but with completely linear tiers it becomes seldom or trivial enough to where a new source file can be made to accommodate each change to a lower tier. Multiple inheritance could vastly screw that up.
Title: Re: Tierable Systems
Post by: luiscubal on March 29, 2010, 12:41:12 pm
What about invisible walls?
Title: Re: Tierable Systems
Post by: Rusky on March 29, 2010, 12:52:31 pm
Virtual accessor functions?
Title: Re: Tierable Systems
Post by: Josh @ Dreamland on March 29, 2010, 01:07:19 pm
> Virtual accessor functions?
Could work, then I'd have to hope they were always inlined. I'll look into it if I need. They won't help much since they'll need to be given a certain type as well, but they could allow for multiple inheritance. I'll see if they come in handy.

> What about invisible walls?
Not sure what you're referring to.
Title: Re: Tierable Systems
Post by: Rusky on March 29, 2010, 01:28:34 pm
Virtual and inline are mutually exclusive.
Title: Re: Tierable Systems
Post by: Josh @ Dreamland on March 29, 2010, 01:33:17 pm
Well, that settles that, then.
Title: Re: Tierable Systems
Post by: luiscubal on March 29, 2010, 01:36:29 pm
Quote
> What about invisible walls?
Not sure what you're referring to.
Anything invisible that affects the collision system.
Title: Re: Tierable Systems
Post by: retep998 on March 29, 2010, 01:38:47 pm
Code: [Select]
//Objects
#ifndef _OBJECTS_
#define _OBJECTS_

#ifndef _OBJECT_INDEX
#define _OBJECT_INDEX
var object_index;
#endif

#ifndef _OBJECT_ID
#define _OBJECT_ID
var id;
#endif

#endif
Code: [Select]
//Collisions
#ifdef _OBJECTS_
#ifndef _OBJECT_COLLISIONS_
#define _OBJECT_COLLISIONS_

#ifndef _OBJECT_X
#define _OBJECT_X
var x;
#endif

#endif
#endif
Code: [Select]
//Drawing
#ifdef _OBJECTS_
#ifndef _OBJECT_DRAWING_
#define _OBJECT_DRAWING_

#ifndef _OBJECT_X
#define _OBJECT_X
var x;
#endif

#ifndef _OBJECT_SPRITE
#define _OBJECT_SPRITE
var sprite_index;
#endif

#endif
#endif
Such a system would have a lot of preprocessor calls, however it would work fairly well (unless Josh got something better) and would be able to handle invisible walls like luiscubal said.
Title: Re: Tierable Systems
Post by: Josh @ Dreamland on March 29, 2010, 01:41:28 pm
> Anything invisible that affects the collision system.
"visible" is part of the graphics tier.

retep:
extern is a great keyword
Title: Re: Tierable Systems
Post by: retep998 on March 29, 2010, 01:45:08 pm
retep:
extern is a great keyword
What would extern do to make it better?
Title: Re: Tierable Systems
Post by: Rusky on March 29, 2010, 01:51:53 pm
retep, what on earth does that do? Josh, why would you limit the ways you can remove stuff? That seems rather counter-intuitive. What if you wanted to make an invisible wall by entirely removing the graphics system?

It would make even more sense to give objects GrahpicsComponents, CollisionComponents and OtherSystemCompoents. It would make different system changeable at runtime (e.g. for instance_change or game options), definable by DLL's, distributed as extremely reusable "behaviors", etc. If you designed a good interface between them you would need less explicit member access, and all the functions that are doing more general things (built-in systems, for example) wouldn't have any speed problems.
Title: Re: Tierable Systems
Post by: Josh @ Dreamland on March 29, 2010, 01:52:14 pm
Remove all those #ifdef #define pairs I can't find another explanation for. If they were so other systems could check if the variable has been implemented, that goes against the purpose of tiering (we'd have to go back over everything and recompile).

Rusky--
And every third instruction would be CALL. Not happening.
Furthermore, "wouldn't have any speed problems..." Do you have ANY research to back this up? Hello, you want me to throw in a function call every time I want object.x? When object is already a pointer? What the FUCK? I'm to the point where I'm unhappy about busing a DWORD back and forth from the RAM, and you want me to make a CALL for it instead. We're talking 6x the number of clocks, easily. That statement genuinely pissed me off this time.

If you want a text-based game with a collision system operating in a terminal window, I'm not programming for you.
Same for if you want to change your fucking mind about what operating system the game is for at runtime. Jesus.
Title: Re: Tierable Systems
Post by: Micah on March 29, 2010, 05:24:28 pm
wow
Title: Re: Tierable Systems
Post by: Rusky on March 29, 2010, 05:28:18 pm
With components you wouldn't end up with every third instruction as CALL. That's just if you heavily used accessors. I was talking about a component system. That's when you wouldn't have any speed problems.

I'm not talking about bizarre and/or impossible situations either. I'm talking about real situation that I have had experience with. Things that real games do. Instance_change is something you need to deal with. Allowing the player to switch rendering engines lets the same executable run on a lot more hardware. Separating behavior into components makes your system way more flexible and reusable.

I'm talking from experience here. Yes, really.
Title: Re: Tierable Systems
Post by: Josh @ Dreamland on March 29, 2010, 05:37:41 pm
Components will still require either recompile or your accessors. Accessors are out of the question. The point of this system is to avoid recompile.

Also, instance_change isn't a difficult function to implement. I already have to list all the variables local to each object. Implementing instance_change is as simple as writing a block of code to copy matching variables over for the set of {objects that call instance_change}x{all objects}. Granted, it could largely increase the filesize if every object used instance_change somewhere in their events, but the function will have no tax on performance outside of itself.

Switching rendering engines is lousy. If it runs Windows, it has better DX support than GL support, A Priori. Otherwise, it either supports GL or requires its own rendering system.

I'm not looking for a resume; I'm looking to weed out a suggestion I can dismiss right off the bat as having consequences requiring >10x the number cycles to execute as its alternatives.
Title: Re: Tierable Systems
Post by: Rusky on March 29, 2010, 05:46:29 pm
Components are specifically designed to avoid recompilation. And have you even tested accessors? Are they really any worse than what you'll have to do to get anyobject.anyarbitraryvar?
Title: Re: Tierable Systems
Post by: Micah on March 29, 2010, 05:51:37 pm
Also, instance_change isn't a difficult function to implement. I already have to list all the variables local to each object. Implementing instance_change is as simple as writing a block of code to copy matching variables over for the set of {objects that call instance_change}x{all objects}. Granted, it could largely increase the filesize if every object used instance_change somewhere in their events, but the function will have no tax on performance outside of itself.
How will this implementation go along with your V8 execute_string?
Title: Re: Tierable Systems
Post by: Josh @ Dreamland on March 29, 2010, 05:54:04 pm
No, not anyobject.anyarbitraryvar: I'm replacing that with a hard-coded accessor of my own device. One should not be implemented for compiled code; compiled code is just that. Since anyobject is an integer rather than a structure, it will have O(log n) lookup, fetch ID, add to array to get lookup pointer, fetch lookup pointer, dereference lookup pointer, return. All that is necessary because I have no idea what the structure it points to will be.

When I said the point was to avoid recompilation, I figured it was implied I didn't want the load put on the run instead. I make it a point to have the compiler make sure as little has to happen at runtime as possible.

V8 accessors work the same as my integer referencer, except those who include the interpreter will be subject to size increase due to lookup tables.
Title: Re: Tierable Systems
Post by: Rusky on March 29, 2010, 06:17:14 pm
An O(log n) lookup is just as bad or worse than an O(1) virtual call.
Title: Re: Tierable Systems
Post by: Josh @ Dreamland on March 29, 2010, 06:35:41 pm
For the few instances I *have* to use it (as in, when the user makes a call via integer.varname), that's the best I'm getting.
The inefficiency of one system out of necessity (or otherwise, for that matter) doesn't justify the inefficiency of another, especially just on the grounds that it seems like a good idea to some individual.

That's no reason to need an accessor for compiled engine code.
Title: Re: Tierable Systems
Post by: Rusky on March 29, 2010, 10:56:05 pm
Alright, even if that's not a good reason to you then flexibility still should be. You're basing these wild claims of inefficiency on nothing, not even microbenchmarks. Until you can show me that accessors are a problem in real situations (e.g. actual GM games written without Enigma in mind), I don't believe you'll even notice the difference.
Title: Re: Tierable Systems
Post by: Josh @ Dreamland on March 29, 2010, 11:00:25 pm
*shrug* I don't see that as a problem.
Title: Re: Tierable Systems
Post by: Rusky on March 29, 2010, 11:03:15 pm
XD No, you wouldn't. Modern CPU cycles (which involve at least one fetch) are faster than it takes a photon from the screen to reach your eye. Do you really need to be counting them at this point? Premature microoptimization is useless. It makes more sense to focus on the architecture.
Title: Re: Tierable Systems
Post by: Josh @ Dreamland on March 29, 2010, 11:22:27 pm
That's a bit bold a statement on all counts. Your missing the point; you just suggested that I reduce the speed of the lookup of needed locals by >75%. The few cycles it once took to look up X are now repeated more than three additional times to successfully make a call to that un-inlined function. We're quadrupling the work that needs done. And now you're justifying it with "a cycle is small, therefore all the cycles you will be throwing out the window with this method are small" (That's the fallacy of composition, just as a fun side-note. And it doesn't apply to mathematically distributing a 4x cycle factor to all processes, by the by).

All I need to do is take advice like that on a dozen or so more systems, and I can successfully reduce the speed of the project by a quarter, and then I can render those lined-flames like GM8 does. At seven frames per second for some 250 of them (That was a slippery slope fallacy. It's pretty commonly used in court cases).

I'm not even starting down that road. I don't care how relatively small the change is compared to the rest of the project; this isn't the first such change you've suggested and I highly doubt it will be the last.
Title: Re: Tierable Systems
Post by: Rusky on March 30, 2010, 06:51:41 am
I never said cycles don't matter, just that you're making mountains out of molehills. I would bet that most of the time is spent doing things besides running the GML- drawing, possibly even waiting for the next frame. Run a profiler and then you can argue about whether it matters.

What other changes have I suggested that would make Enigma so slow?
Title: Re: Tierable Systems
Post by: Josh @ Dreamland on March 30, 2010, 05:57:16 pm
Yes, yes. But we'll start with inherited member access and then it'll progress to something in draw_line I can't even fathom your improvement for. Or maybe ENIGMA's calling convention in general, who knows; the net result somehow being GM's 7fps rate.

Also, I can't really tell your suggestions apart from anti-C++ propaganda. :troll:
In actuality, I'm too lazy to go read through our other four page debates.
Title: Re: Tierable Systems
Post by: Micah on March 30, 2010, 06:04:23 pm
BECAUSE YOU SUGGESTED SOMETHING THAT WASTS A CPU CYCLE YOU ARE TRYING TO RUIN THE PROJECT AND MAKE ENIGMA 2FPS

NO REALLY YOU ARE I KNOW IT FOR SURE
Title: Re: Tierable Systems
Post by: Rusky on March 30, 2010, 06:15:48 pm
Wow. Slippery slope, circular logic and outright lies. You're just being ridiculous. If you want to build a bad system, go ahead, but don't come asking for suggestions.
Title: Re: Tierable Systems
Post by: freezway on March 30, 2010, 06:20:01 pm
can someone explain this in english? ???
Title: Re: Tierable Systems
Post by: retep998 on March 30, 2010, 07:26:07 pm
Basically, Enigma is designed to combine gm with c++.
Rusky says screw that, and make it like haskell.
Josh says no, cuz that's slower.
I say no, BECAUSE IT DEFEATS THE WHOLE PURPOSE OF ENIGMA!
Title: Re: Tierable Systems
Post by: freezway on March 30, 2010, 07:35:27 pm
... JUST USE THE CURRENT FRIGGING THING B/C IT GET DONE SOONER!
Title: Re: Tierable Systems
Post by: notachair on March 30, 2010, 07:36:14 pm
... JUST USE THE CURRENT FRIGGING THING B/C IT GET DONE SOONER!
patience
Title: Re: Tierable Systems
Post by: retep998 on March 30, 2010, 07:40:04 pm
... JUST USE THE CURRENT FRIGGING THING B/C IT GET DONE SOONER!
patience
Josh is looking for saints with patients if you got any.
Title: Re: Tierable Systems
Post by: Josh @ Dreamland on March 30, 2010, 07:41:38 pm
"SOMETHING THAT WASTS A CPU CYCLE "
Something that quadruples (probably more accurately decatuples, but I didn't want to assert a too-outlandish figure, after all) the number of clock cycles necessary to look up a fucking variable in a class I have a pointer to?

"Slippery slope, circular logic and outright lies."
I pointed out the slippery slope myself, with a slight satisfaction I might add ("That was a slippery slope fallacy. It's pretty commonly used in court cases"). There was no circular reasoning as far as I can discern, and I assure you none of it was a lie.

"If you want to build a bad system, go ahead, but don't come asking for suggestions."
A "bad system" in the opinion of one who would multiply the number of cycles necessary to look up a fucking x value, in a class to which I have a pointer, by at least four. In my opinion, and in the opinion of everyone else on the team who didn't feel you were worth responding to, it's better not to waste the cycles on something like x.

Also, I didn't even explicitly ask for a suggestion, I simply welcomed them. I didn't explicitly ask you, either. You gave a suggestion, I declined it. You continued to defend it, I continued to decline it. If you can't cope with me declining a suggestion, quit offering them.
Title: Re: Tierable Systems
Post by: freezway on March 30, 2010, 07:45:05 pm
PWND!
Title: Re: Tierable Systems
Post by: Rusky on March 30, 2010, 07:55:32 pm
Basically, Enigma is designed to combine gm with c++.
Rusky says screw that, and make it like haskell.
Josh says no, cuz that's slower.
I say no, BECAUSE IT DEFEATS THE WHOLE PURPOSE OF ENIGMA!
No. This has nothing to do with Haskell. My suggestion was to make selectable systems rather than tierable systems- you could pick any graphics system including a lack of one, same with any other system, and you would be able to build your own reusable systems. Josh thinks that would be too slow because he has no concept of scale, he hasn't run any benchmarks and he hasn't even seen such a system in action. It absolutely does not defeat the purpose of Enigma. It helps it.

"SOMETHING THAT WASTS A CPU CYCLE "
Something that quadruples (probably more accurately decatuples, but I didn't want to assert a too-outlandish figure) the number of clock cycles necessary to look up a fucking variable in a class I have a pointer to?
The question is how often you need to look up that variable that way, not necessarily how fast that lookup is.

"Slippery slope, circular logic and outright lies."
I pointed out the slippery slope myself, with a slight satisfaction I might add ("That was a slippery slope fallacy. It's pretty commonly used in court cases"). There was no circular reasoning as far as I can discern, and I assure you none of it was a lie.
I wasn't referring to the post in which you pointed out your fallacies. It was a slippery slope from accessors to changing the calling convention. Circular logic was you excusing your lack of examples of my suggestions by just assuming they must exist. GM does not have 7 fps except in your unrealistic particle system examples. There are plenty of nice-running games in GM. That was the lie.

"If you want to build a bad system, go ahead, but don't come asking for suggestions."
A "bad system" in the opinion of one who would multiply the number of cycles necessary to look up a fucking x value in a class to which I have a pointer by at least four. In my opinion, and in the opinion of everyone else on the team who didn't feel you were worth responding to, it's better not to waste the cycles on something like x.
Yes, it is my opinion that it is a bad system. It would also be the opinion of a lot of other programmers. However, if you're going to post ideas here and have people discuss them, don't be surprised when people do so.

Besides, with a component system, which you seem incapable of understanding, you wouldn't be wasting those cycles. Internal code accessing x would be in the component that owns x, with no virtual methods or accessors of any kind. External accesses could be inlined, although they would require an extra pointer lookup to get to the component.

However, even in the worst-case scenario of non-inlined accessors, you don't even know what the real-world impact would be, so you really have no defense at the moment.
Title: Re: Tierable Systems
Post by: Josh @ Dreamland on March 30, 2010, 08:13:23 pm
"you could pick any graphics system including a lack of one, same with any other system, and you would be able to build your own reusable systems"
That's the intention of this system as well. I'm taking a different approach, attempting to reduce everything to organized tiers assuming a chain of previous tiers.

"Josh thinks that would be too slow because he has no concept of scale, he hasn't run any benchmarks"
Josh asserts that this is slow relative to the system in place, due to the factor by which the necessary number of cycles will be multiplied. Josh would rather remove those cycles, pushing the excess time consumption on the compile process rather than the running engine.

"unrealistic particle system examples"
250 * 20 = 5000. If that's an unrealistic number of lines, I can't wait to see your responses when I'm running a 1,000,000 pixel-particle shader. And yes, yes, shaders are so much different. Only not really; they're a great way to speed up heavy procedural particles. Which that example was. Something is not "unrealistic" just because Game Maker can't pull it off at >10 fps.

"Circular logic was you excusing your lack of examples of my suggestions by just assuming they must exist."
I'll grant it again due to laziness. But now I'm starting a list.

"There are plenty of nice-running games in GM. That was the lie."
There are plenty of nice-running games for DOS. Therefore Portal requires an unrealistic system to run. (inb4 portal for DOS)
Try making anything 3D in Game Maker. Oh, but GM isn't for 3D? Well, it's not for decent game creation either.

You suggested yourself that the accessors be virtual, and then verified yourself that virtual and inline were exclusive. The workarounds to make everything non-virtual would be the same as those when working with this simple tiered system. So leaving them non-virtual comes down to me not seeing the point, other than that you suggest it makes more "sense."
Title: Re: Tierable Systems
Post by: Rusky on March 31, 2010, 06:51:32 am
Tiers would let you add your own systems, but that kind of a system doesn't allow you to choose which systems you very easily. Every combination basically needs its own chain.

Yes, more cycles are slower. However, with a component system, you greatly reduce the number of times you actually multiply the number of cycles, and completely eliminate it in some places. Same effect with a better system.

Games are not particle system displays. That's why it's unrealistic. Either way, particle systems don't usually involve rotating lines, but rather small sprites and possibly shaders, which are much more hardware-accelerated. Maybe if you tried GM's particle engine it would be better?

There are plenty of nice-running games in GM, which are nicer than many DOS-standard games. Besides, DOS's limitations come from hardware, not software. It runs in real mode, which has severely limited memory among other things. The reason GM isn't for 3D is not its speed- it's the fact that the editor was not designed for 3D. Enigma, currently, is not designed for 3D either. However, GM doesn't run on DOS, and when you use it for what it's designed for, you can make decent games.

I'll try to explain the component system again. Rather than use inheritance, objects would hold pointers to components. There would be a physics or motion component holding x and y (if they're in a component at all). Physics components would all inherit their required members from the same base class, so even if you change the system you're using, the core stuff will all be in the same place. Accessors would be inline- return someComponent->x. It serves the same purpose as the tier system while being much more flexible.
Title: Re: Tierable Systems
Post by: Josh @ Dreamland on March 31, 2010, 10:25:34 am
What happens when I remove the draw tier and the pointer to the collision tier is a DWord shorter than it's supposed to be? Or do I just leave a NULL pointer in there anyway and maybe optimize it out on full compile? I'd rather try to keep the quick compile and optimized compile at least vaguely close, if only for the sake of games running in debug mode.

Though, I think you keep missing the point of a demonstration. Most of what I say is demonstrative of a system I assumed doesn't need explained. That particle demo isn't the only neat particle system you can do with a bunch of lines. The entire point of that demo was to show not that ENIGMA can run a massive particle system faster than GM, which is obvious, but to show that graphics-heavy (specifically of the code-drawn variety since most of the sprite work can be done with compiled code in GM) effects code can actually start to be employed now. ENIGMA could draw four of that which GM couldn't render one, and do so at full FPS rather than GM's 7fps. That wasn't meant to incinuate that everything about ENIGMA is so much faster (though I'm fine with everyone believing that); it was meant to imply that new options are available as far as designing effects for games.
Serprex in particular has always been big on not including sprites in his games; he either creates them at load time or draws them procedurally the entire time. Most of his games don't have a single sprite. Is this extreme? Probably. Did I respect him for it? Hell yes.

The same can be said about ENIGMA. I'm scrutinizing absolutely everything to make sure all this code works efficiently at run time. There comes a problem of increased compile times along with that sometimes, but I'm personally willing to sacrifice a little compile time to make room for a lot of run time, and I imagine most here would agree with me on that. As nice as a quick compile is, I prefer a quick game.

A problem with this tier system, as you know, is the inability to just use multiple inheritance and hope that the compiler sorts everything out for us. This shot down one of my main hopes for the system; I wanted users to be able to decide that they no longer wished for their locals to be var, but to use int or even double instead where applicable. No system here, including my own, will allow doing that without recompile; we would have to try using a void* to everything and then a global to specify the type, which goes against the point of just using var anyway (though memory saving from string and global would be sizable, speed savings would be none or less).

Swapping systems out for other-sized systems is also a possibility, but is unlikely: The goal of most of the systems was to implement the same variables from GM for the sake of compatibility. Granted, later on we may add support for other locals due to one system, but then it will be a goal to get the same new variables working in all the other systems to achieve the same performance no matter what platform. That was one of the reasons I still liked supporting GML; 1. A huge audience knows it, 2. Those who don't can learn a few functions and guess at the rest, 3. When they want to compile for a different OS, even as different as the Wii, their code will not require modification (or will require very little).

That said, it would seem against at least my philosophy to have two systems requiring a local structure of different sizes where a new tier shouldn't have been added.
Title: Re: Tierable Systems
Post by: score_under on March 31, 2010, 04:31:06 pm
GM does not have 7 fps except in your unrealistic particle system examples.
Troll wins! Flawless victory!
Title: Re: Tierable Systems
Post by: Micah on March 31, 2010, 04:48:27 pm
Basically, Enigma is designed to combine gm with c++.
Rusky says screw that, and make it like haskell.
Josh says no, cuz that's slower.
I say no, BECAUSE IT DEFEATS THE WHOLE PURPOSE OF ENIGMA!
Rusky never, ever suggested that Josh make any changes to Engima that have anything to do with Haskell whatsoever. Maybe you should pay a little more attention to things before you start mouthing off in defense of your big brother.

Rusky was suggesting a system that would pretty much add no overhead and would greatly increase the flexibility of the system Josh is talking about adding, the point of which, is to add flexibility in the first place. Josh misunderstood him and thought that it would add much more overhead that it would (although even that amount would probably be negligible anyway). You completely failed to understand what was going on, along with the other tards who are shouting "PWND," and other such mindless exclamations, to reassure themselves of the superiority of the side that they are taking, when Josh makes a post showing his failure to understand what Rusky was proposing.
Title: Re: Tierable Systems
Post by: Josh @ Dreamland on March 31, 2010, 04:58:37 pm
"Maybe you should pay a little more attention to things before you start mouthing off in defense of your big brother."
lolirony
Title: Re: Tierable Systems
Post by: Rusky on March 31, 2010, 05:02:20 pm
I would put a blank draw component, rather than a null pointer. No null checks required for the majority of the cases, and possibly complete removal in the case of the blank draw component. This would also work for switching the visible option on and off, especially if draw events were put into each object's draw component. Different-sized systems would be possible because they could be stored as pointers to components with common parents. You would always be able to depend on the parent and thus the default fields. New systems could add, besides just new fields, new or different functionality. You could have components that implement only certain parts of GM's default object behavior, for example. Systems could be for behavior and optimization besides just cross-platform compatibility.

The reason I don't think your demo was realistic was that that wasn't how that effect would be accomplished in GM. I don't know how GM's particle system works, but it's probably optimized for particle systems, and possibly hardware accelerated. I used it as an example because you (ridiculously) claimed that GM games all run at 7 fps. The most recent time that actually happened was your example, where GM was used as it probably wasn't intended.
Title: Re: Tierable Systems
Post by: Josh @ Dreamland on March 31, 2010, 05:27:54 pm
How can you specify a blank draw component? Just a pointer to a dummy?
In either case, the tier system is implemented and doing a fabulous job. Rebuild for an additional tier or two isn't much to ask when you already have to rebuild one, especially considering the total build time for the entire project, fully optimized, isn't far past 20 seconds. At this point, I don't see much to gain, even at the cost of only a pointer (That system shouldn't require an accessor if it's including its own structure; I'm still not even considering accessors).

Also, I never claimed that GM games all run at 7fps. I showed that that's what can happen. 5,000 isn't an unreasonable number of lines; GM couldn't manage it 10 fps, ENIGMA wasn't even phased by it. It doesn't matter how they'd be accomplished in GM; GM users are used to working around its incapability. I started a 3D Metroid clone once; couldn't import my model; found a way to, but it ran at 2FPS because of it (where it rendered at 60 in the editor). Ended up rendering it ahead of time and drawing it as a cheap overlay. Looked horrible. All the walls had to be flat... It was sad. But I was happy with it, because it was the best I could do in GM.

miky:
The way I see it, the amount of flexibility I'd gain from this system over the tier system isn't really enough to justify any sort of speed loss whatsoever. Maybe the extra pointer dereference if it really brought anything to the table in the long run. I'd much rather put the doubling of workload on the compiler.
Title: Re: Tierable Systems
Post by: Noodle on March 31, 2010, 05:50:22 pm
Rusky, Obviously we can't see how ENIGMA would perform under average conditions, because nobody has made an average game with it yet. Its just extrapolation for now, but the purpose of the demo was to compare rendering capabilities, not to downplay GM.

Im not interested in making an 'average' 2d platformer in ENIGMA either. I care about the freedom to make something extraordinary and unique which wouldn't be feasible in GM. That can't just be me?
Title: Re: Tierable Systems
Post by: Rusky on March 31, 2010, 07:04:31 pm
5000 may very well be an unreasonable number of lines if you're not using hardware acceleration of some kind. In GM you could use the particle system, line lists or models. While Enigma is faster, that doesn't mean all that much. Anyone can come up with a giant computation problem and say "look, this runs faster compiled." Also, again, GM wasn't designed for 3D, engine or editor. I understand the reasons for the demo, but it would make more sense to outdo GM without using it badly.

If you want removable systems you have to sacrifice something. You seem to favor imperceptible speed improvements over flexibility, for some reason. A component system is a vast improvement in flexibility over a tier system, at the cost of a single extra pointer dereference when accessing members from outside an object:

More precise code reuse- tiers only let you use specific, pre-made combinations; components would let you pick any possible set of systems to include. Components would be more share-able between different types of objects.

Minimal recompilation- if all your components are already there and you don't change any code to use the new components, the only change is the object's constructor.

Better organization- engine code will be partitioned much more obviously into graphics code, collision code, etc. instead of being all in one object (this one's not that big though, as a lot of the subsystems would be in the tiers anyway).

Possibility of runtime configuration- you would be able to switch systems mid-game. While that's not so important with things like GL v DX in the graphics subsystem, it's huge with things like instance_change or new mechanics only possible with a new system (for example, AI states could be components rather than giant switch statements if the system were exposed to the programmer).

Decorators- debugging would be insanely easy. You could make "decorator" components that wrap other components to do things like logging, enabling/disabling specific behavior at runtime and implementing build mode on top of the normal object behavior. These debugging features could be completely removed in non-debug mode without a bunch of ugly #ifdefs- it would all be in completely separate files and the only change would be the affected objects' constructors.
Title: Re: Tierable Systems
Post by: Josh @ Dreamland on March 31, 2010, 07:13:32 pm
More precise code reuse-
Shouldn't matter in a compiled system; anything unused that's declared in a structure will simply be ignored. Just include the highest tier you need shit from.

Minimal recompilation-
As I said, I'd rather double or even triple the compile time when a recompile is necessary (it will be necessary at about the same time for both systems) than double the clocks needed to look up a local. Even if doubling it is as little as one more dereference. :P

Better organization-
No, the tiers do that, too. Each tier gets its own header and, if necessary, source file.

Possibility of runtime configuration-
Not even slightly interested. I don't see how it helps instance_change, either: with the tier system, instance change is a memcpy(y,x,sizeof(highest tier)) followed by more specific code that the component system wouldn't avoid. In fact, component system makes instance_change slightly more complicated (The compiler would likely take care of the complications, though, if we had a method in each one that could be inlined).

Decorators-
What could possibly stop me from doing that with the tier system?

It seems the key difference between us is that you want to move as much as possible to run time, where I want to do just the opposite.
Title: Re: Tierable Systems
Post by: Rusky on March 31, 2010, 07:46:55 pm
Code reuse- what on earth does that have to do with anything? Selecting the highest tier you need is the problem- tiers imply a specific order to things you can have and not have. With graphics and physics, you would end up having to make only one removable without the other. With components, you pick exactly what systems you want. Instead of a drop-down menu or something of "core, graphics, physics", "core, graphics", "core", you could select each of core, graphics and physics separately for every possible combination. With the right interfaces, these components could work entirely separately.

Recompilation- compile time is rather large as it is. A simple GM game takes only a second or so to compile, and it doesn't grow much with extra code, only resources. Because you have to parse the GML, compile it and then link it all, the amount of code matters a lot more. Long compile times get completely unusable- they're one major reason people use scripting languages in the first place- zero recompilation. Also, you still have no idea how much a dereference would matter. How often do you access members of other objects, anyway?

Runtime configuration- with components, instance_change use pointer assignment instead of memcpy, because the common stuff is already separated from the main object. Components could also be extended to new functionality, like I explained before. Even if you aren't interested in that, the fact that a system is more extensible is generally a good sign, and others definitely will be interested in that. It's a common C++ technique to delegate behavior to member objects, and this would be another way to help people move to C++.

Decorators- the entire idea behind the tier system is to keep systems the same size to avoid total recompilation or virtual accessors, no? Decorators would often need to change the size of a subsystem. Even if you're find with more compile time, you still wouldn't be able to enable, disable and switch decorators at runtime (which definitely matters in debugging) without adding every possibility into one tier and adding a bunch of extra runtime checks. Components would also make it possible for users to add their own decorators for their own decorators.
Title: Re: Tierable Systems
Post by: Josh @ Dreamland on March 31, 2010, 10:09:47 pm
Your instance_change argument had me reconsidering the implications of your proposal for a few seconds before I remembered what it would look like for an event to access any of your component-ized locals. I assume this is where your proposed accessor comes in, which I said before wouldn't really be needed: I could parse in a "componentname->" before each local. However, I don't want to do so, and I don't believe anyone else does either. I was discussing this with Luda; he asked what the point was. I referred him to your independence and instance_change arguments (those were your good ones; coincidentally, they were your only two that were worth a second glance). He then remembered that instance_change existed, he decided it was ugly. I agree, of course. It looks great from a distance when you start forgetting about the lower components you're cursing.

The reason I don't want to parse in componentname-> is not even to do with the amount of work. First off, Luda thought dynamic allocation was ugly; I think requiring a list of what's in each component is ugly. To add that in before the correct variables, I'd need to know what variable is in what component. We have no C++ way of signifying what's a component, so I'd need to keep a list of locals again, or read them from some messy INI. I refuse to do that.

I wanted the system to be extensible from the low level more than the high, really; easy to add more systems to using C++. I have been doing some serious reorganization towards that in every system.

And again, my tier hierarchy is designed to try to emulate true dependence. Consider this; In order to check collisions (the highest tier in my system), I require the following:
- IDs and Object Indexes from object_basic (tier 0)
- Coordinates on the screen from object_planar (tier 1)
- Image Index (to tell which mask to use) from object_graphics (tier 2)
- Bounding boxes and bit masks from object_collisions (tier 3)

That's every tier. If you want to use a DLL like Ultimate3D instead of the built-in drawing systems, but utilize Ludamad's collision system as well, that doesn't really make a bit of sense; Luda uses bitmasks based on sprites. Mutually exclusive tiers can be included just that way, and a source file only has to utilize the one it was designed for. For example, it'd make more sense to use some physics library like Newton instead of Colligma to accompany Ultimate3D. So, a Newton tier could be engineered to only require the first two tiers. This'd be a total of two combinations, really; I'll bet you can't really afford to swap out the planar system if you know how many coordinates you need.


Anyway, I'm proceeding with the tier system until further notice. If you can convince Luda, serp, Ism, ...anyone other than your brother, really, I'll investigate it a bit further. Until then it's better I stick with what's now implemented.

We also discussed how instance_change isn't really used a lot. Normally I'd hate to use that as an excuse, but the function is an oddball. You picked up on that as well. It's one of the very few functions that approached justifying an interpreted language. Also, it's one of the few things R3 randomly lacked that no one even asked about. Despite me not thinking highly of it, I would include an option to employ a component system just to improve any game seriously whoring that function (though neither Luda nor I can think of a good reason for a game to do so), but the choice for this system has far too deep-rooted consequences. It's one of the new backbones of the project; perhaps that's why you're so avidly proposing the components.

Ultimately, too, most of the flexibility issues with removing tiers from my system would manifest as similar problems in moving them from a component system; except we'd just be removing one pointer rather than changing entire chunks of data. The size of the change really doesn't matter; it's that it changed that throws off other systems.
Title: Re: Tierable Systems
Post by: Rusky on April 01, 2010, 10:32:14 am
instance_change isn't really that ugly. In a purely GM context, you could use it for new objects that get created on destroy without requiring a(s much) reallocation. Especially if you could statically create the components beforehand, AI (or other) states would be very nice with components. You wouldn't need a list of locals either, I don't think. Non-standard members could go in the main object as before, while any new members or methods on new components could either use a #include for additional inline accessors to the main object or just require them to know about components and use it directly.

Your dependencies make sense. However, switching out tiers does as well. What if, instead of just switching to U3D, you wanted to switch to your own graphics system besides DX or GL, perhaps some library that works on more platforms or your own version for the DS or something. Or maybe you'd want to switch the physics engine to something that doesn't have GM's default behavior with friction, gravity, etc. If you were willing to deal with some things GCC couldn't verify for you, you could even use components to switch the types of the default members without as much recompilation.

Components are better at handling removal and changes because they're not part of the actual object. Removing one doesn't let you remove the pointer, but dummy components are always an option that would at least get rid of GM's default behaviors, if not the space the members take up. New systems can easily add their own private members as needed without screwing up the sizes. Then there's the debugging stuff- how on earth do you plan to do that with tiers?
Title: Re: Tierable Systems
Post by: Josh @ Dreamland on April 01, 2010, 12:07:29 pm
The hope behind adding a new graphics system (such as GX for the DS and Wii) is that doing so doesn't change any of the tiers; we're striving to allow lossless cross-compilation. Obviously we'll be sacrificing some things between consoles and the PC (namely the keyboard, at least for the DS) and we will be adding some functionality (such as managing viewports with the DS; I'm not sure how it handles multiple screens). Fortunately, most of that will not have to do with locals and will not even need to interface with the tier system.

I do see where components would be handy; I don't think ENIGMA is such a case.

As for debugging, many of the projects I've seen let you compile a debug configuration and a release configuration. Storing a separate object file for each is an option. If I need a notification on write to a variable, I will add such a directive to "var," which, unfortunately, is the tiers' default type. That will require the recompilation (or storing of a second object file) of one source. Two for types such as hspeed, vspeed, direction, and speed, whose assignments are already special-cased to interact with one another. Making the decision to leave var behind can indeed end up being costly of compile time; the hope is to make that happen only the first time and to keep the object files from there.

I'd also like to point out that the tiers are not to be included by most files; only those that truly need to interface with local variables. For example, that includes a good deal of the collision system, but not the collision testing code. Ludamad won't even include a tier, because his system will operate independently of them. There will be a go-between file that I intend to author that will make calls to his system based on active instances.
Title: Re: Tierable Systems
Post by: Rusky on April 01, 2010, 02:39:10 pm
Yes, different graphics systems would be to keep the same interface with different underlying engines. However, that doesn't mean their internals should or even could remain the same. You need different handles and objects that would inevitably end up taking up different sizes. The tier system loses half of its raison d'etre because of this. Components let you organize the different systems however they need to be set up without worrying about size, and still get the benefits you were looking for in the tier system.

With components, those debugging features could be turned on and off at runtime, without any recompilation. You could just switch out the component being used. In build mode, for example, you could make a decorator component that handles and filters interface events to quickly switch to a user-friendly editor where you could select, create, destroy and move objects while still running their normal draw events. A debugger could enable and disable different events, subsystems, etc. without any checks getting in the way of the rest of the code.
Title: Re: Tierable Systems
Post by: Josh @ Dreamland on April 01, 2010, 06:08:14 pm
"to keep the same interface ... that doesn't mean their internals should or even could remain the same."
I tried explaining this, maybe not thoroughly enough. The tiering system is only for local variables instantiated along with objects. These are the variables that will be in every single instance, like x and y in GM. They are entirely independent of locals to a system; a system can have as many of those as it wants and still be independent. Certainly you knew that... To have the same interface is to have the same locals.

"With components, those debugging features could be turned on and off at runtime, without any recompilation"
The community is going to respond GREAT to this. That was political suicide in the world of GM, sorry. And don't bother attacking me; I'm a little above that. Number one, no one else is; number two, debug things are costly size-wise. Is it your intention to remove the debug things entirely during final compilation? If not, you may as well just leave; otherwise, there's no point to having them removable before that final build anyway.
Title: Re: Tierable Systems
Post by: Rusky on April 01, 2010, 06:36:25 pm
"To have the same interface is to have the same locals."
So if a system needs any extra data per-instance, it has to keep it in a global array or put it in another piece to be included in the instance? Either way it's not as well organized as components.

I have no idea what you just said on that second thing. Of course they could be removed completely- they're just wrapper components. They can go on and off at runtime and be removed at compile time.
Title: Re: Tierable Systems
Post by: antidote on May 06, 2010, 02:58:27 am
I know I really have no say, but as I read this I find myself agreeing with Rusky.

Josh your being really defensive about your library and refusing to take into account the fact that most modern CPUs are beyond even the nano second in cycle times, an extra pointer de-referencing is not only negligible but also highly suggested in liu of the flexibility gained. It would allow the developer of a project to have complete control over what they want their game/utility to do.

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.

There is such a thing as over optimizations. Getting everything inlined and perfectly sized will only cause problems in the future. If a program is poorly coded it will cause enigma to segfault if the system is picky about how things are formatted in memory, which is were the current trend with your code is going.

Also as a developer, I would rather have flexibility and "slow" look-ups with a component system than the obscenely long compile time and "fast" look-ups of an over optimized tier system.

These are my thoughts on the whole topic if you don't like them thats not my problem I was just giving you my take on the whole deal.
Title: Re: Tierable Systems
Post by: Josh @ Dreamland 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.
Title: Re: Tierable Systems
Post by: retep998 on May 06, 2010, 09:43:40 pm
your fears are in vain.
Corrected
The worst part about censorship is                
Title: Re: Tierable Systems
Post by: score_under on May 07, 2010, 12:39:16 pm
Actually, I'm fairly sure the worst part of censorship is the way the ██████████████ in ███████████████ whenever they please.
Title: Re: Tierable Systems
Post by: Micah on May 07, 2010, 07:33:44 pm
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.
I'm thinking that you didn't pay any attention at all to the component system. You would not need accessors. The component system simply requires one extra pointer dereference for the stuff in components.

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 you completely fail to understand why you'd use the component system. The tier system lets you do a few optimizations when you need certain combinations of systems and only those combinations. The component system allows you to do those optimizations in many more cases with a single extra pointer dereference for each property inside a component, and beside this, it affords an enormous amount of flexibility, which has already been explained above, and which the tier system simply does not provide.

You completely misunderstand why you would use the component system. YOUR ARGUMENTS ARE IN VAIN.
Title: Re: Tierable Systems
Post by: Josh @ Dreamland 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.
Title: Re: Tierable Systems
Post by: Micah on May 08, 2010, 11:39:56 am
"Decorator" components are a huge benefit of components. I believe that these have already been explained sufficiently. There have actually been many other useful cases for components to which you evidently did not pay any attention.

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.
If that's your mentality for the project--"Speed is the only thing that matters. Flexibility doesn't even exist"--which has been illustrated by your overoptimization and C++ evangelism already quite a bit, then wow.

You don't always need the graphics tier to have a collision system. What if you wanted to use a completely different vector graphics system but wanted to reuse the collision system? What if you wanted to exchange anything along the whole entire tier system but wanted to keep the old systems things that use that tier? Completely reprogram everything that uses it, or use components? Hmm.
Title: Re: Tierable Systems
Post by: Josh @ Dreamland 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.
Title: Re: Tierable Systems
Post by: Micah on May 08, 2010, 12:42:25 pm
Your idea of "over optimization" pisses me, and a number of others, off.
Your premature optimization and destruction of flexibility and good design to save a cycle or two pisses me, and many, many other people, off. Pretty much every good programmer except for those who come from Game Maker (and perhaps Linus and a few other silly people--although even he has said on occasion how much nicer higher-level programming is :P) agrees with this.

Name this "number of others."
Title: Re: Tierable Systems
Post by: Josh @ Dreamland 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.