|
Josh @ Dreamland
|
|
Reply #61 Posted on: May 12, 2010, 02:36:31 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
Everyone who has remarked on the code in this thread has said that mine was the cleaner; I've heard nothing but how well-organized R4's system is from new developers.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|
Josh @ Dreamland
|
|
Reply #63 Posted on: May 12, 2010, 06:48:04 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
Good. Your edit doesn't follow; it's okay for your code to be unreadable if it's only unreadable in a sense that you don't care about?
|
|
« Last Edit: May 12, 2010, 07:18:35 pm by Josh @ Dreamland »
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|
Josh @ Dreamland
|
|
Reply #65 Posted on: May 13, 2010, 08:14:10 am |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
Last I checked, cout << 's are usually pretty readable. Even when called debug_print.
I included a tier below. The others look identical, save the names. Somewhat of a nice part about tiers, really. My code would be much bigger, though; not without justification.
Your code is set up such that a separate component needs coded for a game that doesn't want to use sprites but still would like to use instance_nearest. So much for reusable behavior.
Oh sure, you can separate it into another component, but then an amazing thing happens; each component is dependent on another, kinda like my tiers. Astounding, really. It exhibits the same behavior.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|
Josh @ Dreamland
|
|
Reply #67 Posted on: May 13, 2010, 09:08:32 am |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
"They may be readable on their own, but less, more focused code is always more readable than more, unfocused code." You'd best define focused if you're going to assert that yours is more so.
"Your code would be much longer, so you just omitted most of it and basically pretended the entire system. It's no wonder it's more readable here." Is this your argument? My code is redundant, making it very simple for our zip-like memories to generalize them without having to examine them constantly. And considering tiers are more efficient nonetheless, I don't see how this is a problem.
"yours is coming from a long-standing plan. You've thought about the dependencies more, you can reorganize the components if you feel like." And after all this thought, I say tiers are the way to go; you disagree. That implies you still feel you know better. How did that help your argument?
"you can reorganize the components if you feel like. Put coordinates in the collision component and pass it the other way." I could do the same thing with tiers; it'd be a huge pain in the ass and it'd be counter-intuitive. Instance_nearest doesn't need the collision system or the sprite system; it just needs X and Y. Yes, you showed how to resolve those dependencies; they're easier with tiers, too, as you've agreed.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|
Josh @ Dreamland
|
|
Reply #69 Posted on: May 13, 2010, 02:24:37 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
And you keep missing the point that we are discussing ENIGMA's lowermost systems. And as a side note, I have no debug code to add to tiers; nothing can possibly go wrong with them until you start linking in and using systems that aren't accounted for, which the compiler makes impossible.
"What you've thought about more are the specific dependencies present in a GM-like system." And this is precisely what we're debating. All that thinking considered, tiers appear to me to be the perfect method for the key systems.
"Wherever you put coordinates, it needs that component or tier. There is absolutely no difference in this respect." Good, simpler system wins.
"Dependencies are resolved better with components because they're more specific- you can have something depend on one other section rather than all the others below it, you can have two depend on each other, etc." Yes. Now think about that in the context of the systems we're debating. If every tier in my system was likewise paired with a component in yours, the relative dependencies would be exactly the same. Your sprite component still needs the 2D component, your collision component still needs the sprite component. There is neither an audio tier nor component. I have no debug info to pile onto either system, nor anything else to make use of the features components offer. All they'd do is ugly up my code and slow the system (yes, minutely, but as I've said and will continue to say, I'm accounting for each little piece).
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|
Josh @ Dreamland
|
|
Reply #71 Posted on: May 13, 2010, 07:58:58 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
The point of this system is not to implement separate debugging. That never had -anything- to do with the point. I explained that if I need debugging done, a single function call will be inserted. And I did give a tier implementation; the rest differ only in the names of the variables declared which can be inferred. I don't feel like posting them; I know what they look like, and anyone who wishes to see them can use SourceForge's SVN browser.
And yes, you made that apparent by including X and Y in with the sprite component, which I regard as a bad move. And it doesn't matter how many configurations you propose; I've already went through them all and I can't find one less outwardly dependent on everything than the configuration established with my tiers. You should never, ever, ever, ever, ever, ever (and do note that I typed manually every ever ever), include the 2D sprite component/tier with a "focused" or "specific" 3D component/tier. 3D games don't use sprite_index and image_index, except in GM. So how does the tier system provide for that? It already does! Nothing changes, it's as simple as that. Now, when you decide you want to include a more specialized system for 3D, you drop the planar tier; you drop instance_nearest for instance_nearest_3d, you drop bitmasked-based place_free and whatnot for yet-unplanned model collision functions; you drop anything that was based in design and principle for a 2D game in favor of the 3D equivalents.
The tier system implements a total of *does some counting*... zero functions. There's nothing in them to debug. Functions like sprite_draw, should they under any circumstance require debug information, will have it called as an external function via a macro. This isn't negotiable in the tier system, and the component system isn't worth it for that one feature, outside of which nothing is offered.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
Rusky
|
|
Reply #72 Posted on: May 14, 2010, 08:51:01 am |
|
|
Joined: Feb 2008
Posts: 954
|
Separate debugging was part of my point. I explained that the component system allows much more high-level and useful debugging tools than inserting a function call or macro, and is more readable in that case because there is less, more focused code. Switching the debug behavior in a single place (the used component), rather than at every function the debugger affects, is simpler. Simpler solution wins.
Components allow better dependency resolution, which you dismiss as "complicated". It is, however, much more flexible- 3D doesn't have sprite_index, so sprite_index goes in the 2D component. This specific proposal is more of a cross between components and tiers- components would be tiered, which in the end would simplify objects quite a bit, as there would be less components and less opportunities for recompile. Simpler solution wins.
While the tier system itself implements zero functions, you have to implement functions that are based on what's included in the tiers. Whether or not these functions are actually declared in the tiers, they are still part of their interface. Reducing instance_nearest and instance_nearest_3d into the same function makes things simpler for the user; reducing the number of components in the final object makes things simpler for the developer. Simpler solution wins.
While you included ultimate_tier, it did practically nothing and doesn't represent the actual code the tier system requires. It may work perfectly fine for this thread, but you cannot claim that it's more readable without including the same things I did.
|
|
|
Logged
|
|
|
|
Josh @ Dreamland
|
|
Reply #73 Posted on: May 14, 2010, 09:24:57 am |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
I can hardly believe I'm going to respond to this. Now you're just pretending. All your latest `things which are simpler` are sadly abstracted concepts to the point where you are not only once again not look at the bigger picture, you're not even looking at the immediate picture. It's like the games we played as children, proving 1 == 2 by dividing both sides by zero.
I'm about done entertaining your argument. It fell to trash, and then you tried to revive it with indeterminate calculations on a language in what is actually a loosely-garbled reduction of the original proposals.
Yes, you can have a function call a function that calls a function, the middle function implementing debug code. That's quite far from what I'm looking for in efficiency. And for the LAST TIME, I have nothing to add, debug wise, to all those functions.
Yes, the tier system is separate from the functions implemented on its basis. No, that is not overly complicated; I don't want anything developing for ENIGMA that finds this concept overly-complicated.
Yes, you can reduce the number of components, and this does "simplify" the ultimate object in your system. Not in mine; mine just inherits from the top tier. It wouldn't change a thing if the collision tier had the same name. So I suppose in your system, now that you have abstracted the tier system out of your own thinking pattern entirely, less components would in fact be the simpler solution. In the tier system, you can't tell from looking at the ultimate object how many tiers there are.
Yes, the ultimate tier does practically nothing because they ALL DO PRACTICALLY NOTHING. They are a device for organization. I could include the ultimate object in everything and manage to reason circularly in code, but I prefer not to and not doing so saves effort.
It is clear at this point you haven't had a look at any code in ENIGMA In a while. Why don't you check out and compile some games and watch what happens. You're basing much of your latter argument on fantasy and myth about how ENIGMA can and cannot function. Need I remind you of "ENIGMA can't possibly know all the members at compile time"? Damn, I don't even know where that came from.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|
|