Show Posts

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

Messages - Josh @ Dreamland

Proposals / Re: Tiering vs Components
« on: May 12, 2010, 02:36:31 pm »
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.

Proposals / Re: Tiering vs Components
« on: May 12, 2010, 12:52:50 pm »
Does that benefit the user? Because it sure as hell doesn't benefit me. And, as stated, any benefits it would offer the user can be emulated otherwise thanks to how ENIGMA is set up.

General ENIGMA / Re: ENIGMA's value
« on: May 12, 2010, 10:06:32 am »
No, 90% of the code is mine. They're basing their calculations on the effort put out by people who get paid by the hour, not who work for beans.

Off-Topic / Re: Music?
« on: May 12, 2010, 08:17:20 am »
"Basically, I can't listen to bad music and partly because of that, I often prefer silence."
I feel that way, too, and some people (especially those who know even less about astronomy than I do but refuse to omit it from their song) give me a knot in my stomach that makes me prefer not to have heard them speak. Others and their self-important idea of what should never have been called "singing" are better off just cutting the vocals. I do appreciate some lyrics, most often the ones I can't understand. So I tend to like songs in other languages and that are distorted or contain meaningless vocals.

I've told my friends, essentially, "Yes, I see you've found another song containing a guitar and someone raving about something in song. DO. NOT. WANT."

Proposals / Re: Tiering vs Components
« on: May 12, 2010, 08:11:43 am »
"You've split the parser, but you haven't split the debug code, which is somehow different and should stay in the same file."
No, it would operate the same way. There would be one declaration from the split files in the main file, and a function call in concerned functions.

"Classes, and thus the ways you can use them, are a feature of C++, so splitting debug code out would be relying on a feature of the language."
On one too many features of the language. I could put it all in a namespace, too. Doesn't really mean I'm going to.

"Components make things more readable"
For you
"and separate different purposes better,"
In your opinion
"which has somewhat more weight than putting debug code with what it's debugging with most programmers."
Have a poll? Hell, if I didn't print debug information inline, I'd double my line count trying to separate it. The actual debug code would be lost in all the hackish attempts to get at all the information I could have had immediately otherwise.

"Polymorphism is a nice feature that makes code more readable, putting debug code in a separate file does the same thing."
"Makes code more readable"? I'll give you, "can make code more readable." Regardless, the debug code can and sometimes will be in a separate file, but there will still be a call to it in the main file. The call will be about a line long, maybe two if I include a comment or three if it requires a real lot of parameters. You can't really debug a loop without having some inline debug code for it. Unless you want to have your debug code make a separate iteration, which I'm sure you'd have no problem with.

Announcements / Fixed those Makefiles
« on: May 12, 2010, 08:00:05 am »
Good news everyone. I got the makefiles not to recompile all the time. I've not yet committed my changes though; be patient. I want to make sure all the changes I've made to the syntax checker and parser hold up during some field testing, and there's some code that needs moved around because it's being called too often.

Anyway, I'm not sure I can enumerate all the changes between my next revision (expect it tonight) and my last; that's why we have Diff.

The IRC has relieved me of the things I usually keep in a list to say when I make a newspost, especially with freezway asking how makefiles are coming every twenty minutes. Freezway, the makefiles work, but you can't have them. So there.

I may as well share concerns as well as success. I decided to use makefiles, despite them being an ancient art that's a huge pain to get working, because I wanted individual systems to be responsible for their own rules of building. This would be especially helpful, I thought, when we did the Wii port, which is necessarily Make-based. Problem is, I'm not sure what changes would need made to the makefile (particularly the ones under SHELL/ and SHELL/Universal_System/) to enable the modified Make to compile it correctly. I will need to thoroughly inspect the Wii-written makefiles for things that need set.

The most glaringly obvious of these is that $(DEVKITPPC) needs set, and that it includes a file called wii_rules from that directory. This leaves a number of questions that I can't yet answer with certainty. Namely, do I want to make it so that every system relies on a file called $(COMPILER_DATA)/$(PLATFORMNAME)_rules? Do I want to just include makefiles/makefile.$(PLATFORMNAME)?

It seems the latter would be the simplest as well as the most easily extended since as many files can be dumped into that folder as the OS allows, and the makefile will include any of them LGM/ENIGMA request by name or fragment of name (wii, pc, etc). It is what I will likely be going with unless someone has a better idea.

That leaves one additional problem that needs dealt with for a number of reasons. How do we incorporate multiple compilers? Currently, ENIGMA frantically searches for c++ and g++ at load time. If it doesn't find them, it errors to Ism, who asks the user. Either way, it leaves knowing where gcc and make/mingw32-make are located. That location name can be made into a map, certainly. But, where do we store compiler information? A new folder, ENIGMAsystem/compilers/?  A new text file, ENIGMAsystem/compilers? The former would be more desirable so that, should compilers be pluginized (and this is thinking way ahead), plugins aren't fighting for permissions and last word in one text file, and aren't iterating it on and off for their input. It would just rely--as the entire remainder of the system would, really--on no two compilers sharing a name.

Perhaps all that belongs in Proposals anyway, I guess I just needed something to put in this newspost. Maybe I'll post it there later.

Anyway, real work to do now.

Proposals / Re: Tiering vs Components
« on: May 11, 2010, 08:17:15 pm »
"What's wrong with splitting a shared behavior into a different file, especially when it's for debugging purposes only?"
Nothing; I've split pieces of a single parser into separate files. What's wrong with relying on the features of a language to handle that?

"Just because you can handle extra #if blocks and debug lines littering your code doesn't mean it's ideal."
I believe the same about components for everything.

"I'm sure you could handle writing Enigma in C, why use C++?
Because C++ implements polymorphism which I would otherwise have to handle myself, which would take a phenomenal amount of effort.

"But it is a suggestion as to why you have so few developers."
As if we needed a reason for that. Ism's on her own now, too. Where did she go wrong? Hell, a lot of open source projects are. That's a pretty trashy reason.

Proposals / Re: Tiering vs Components
« on: May 11, 2010, 07:53:46 pm »
"They're object specific and operate in the context of their owner."
Then they should be coded in the context of the owner, including the file.

"You could, for example, mute, make invisible, highlight or otherwise affect a specific object from within that object."
Like what visible = 0; does. Ingenious.

"In build mode, components would go along with or even make unnecessary your #if by handling build mode-specific behavior from within each object."
Yes, but the #if takes up less space and requires only the changing of a single flag. Besides, the option to include Build and Debug mode when compiling a game is not a feature that can be turned off, and is of the few things the system is absolutely designed around the idea of including an option for.

"Anyway- you don't have to use components. Tiers will just be another part of Enigma that makes me not want to contribute."
Your only contribution before you cared about how the rest of the system looked was too incomplete to use... Is that a veiled threat?

"You can organize files however you want, but mixing debug and normal code just makes things less readable and workable."
Most of us can learn to ignore a single line reading debug_call(), the rest should sleep before/instead of developing for a large project.

"Put them in a debug folder mirroring the main tree or something- debug code does not belong with release code, it's not for the same purpose."
Sure, it's not for the same purpose, but it should be designed to integrate with that purpose. As for the separate tree, that's fine, if a bit extreme--I was thinking a separate source--, but the declaration and call of the function is still being included in the main system.

"Sticking it in at compile time is a little better, but you don't do this everywhere and swapping a pointer is still much simpler than recompiling and inserting new blocks of code."
Better for someone who can't juggle the purpose of the code and a single-line debug call, certainly.

Proposals / Re: Tiering vs Components
« on: May 11, 2010, 06:56:59 pm »
"You could add a debug wrapper (i.e. a new component that forwards calls to the original one, doing something else as well) that draws the path an object is following."
Where would I put the code for that? Personally, I think it'd be a good idea to put it in with, say, the rest of the code. Otherwise it's just a pain in the ass to find the corresponding debug code.

"You could add one that draws and deals with build mode controls, letting you modify objects when the game is paused."
Yes, as the supreme lord and master of all code that goes through ENIGMA, I can do that without a component system by inserting the code myself at compile time. I mentioned that before.

"You could add one that turns off specific sounds to help debug audio."
Sounds have to be queued anyway for sound_stop_all. Practically all of ENIGMA needs queued in some way, shape, or form. This could be done with a simple global-scope function. How does your system help me?

"You could add one that pauses for build mode on a certain event (okay, this one's an event, whatever)."
I don't follow the parenthetical statement. Build mode is presently handled with an #if around an if-else pair in the event loop. The #if checks that it's in build mode, the if() checks if build mode has the game paused. This has worked for over a year. How does your system help me?

"These are not the same level of debugging that uses proxy<> and an interactive debugger- it's higher level and more specific to Enigma games."
If it's that specific, it should be included in or by the concerned source. It doesn't make sense to put the debug code anywhere else just because I can.

"You were the one who suggested using a tiered system for paths: "Paths...are a good reason to add a component pointer""
What? How is  "Paths...are a good reason to add a component pointer" suggestive of tiers? Now, in "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," I meant "component pointer" rather than "tier pointer." And no, this would be handled using all your fancy semantic proposals; the paths would be a component in your domain as described by the better of your previous proposals and a few methods of my own. The path system would be the first to justify using your component idea as I see it. Even with it, though, I would build on your idea to prevent fuck-ugly path_index() calls (Ironically, path_index() is probably a better idea though, since it's a read-only variable). These ideas that I would use to build on components would be inlining them then taking a member pointer to them instead of a component pointer. This could be achieved thanks to the not-"real"-code semantics you started down earlier. Again, paths are worth it to me, the underlying important systems are not.

"Couldn't you just pass an Object reference to them as a hidden argument?"
Sure, but then I would have to scope the locals the script uses into everything derived from Object, so scripts designed especially for a certain object using fifty variables would inflict those fifty variables on every other instance as well. Imagine a controller object with its own script folder, each script using some 12 variables, 25 unique among them all. That would be 200 bytes for each instance for no reason at all.

"You can't know what members will exist at compile time anyway"
Omigosh, I wonder how ENIGMA's been compiling all this time.  :ohdear:

"Even with "treat uninitialized variables as 0" turned off you can still insert new members at any time"
How is that? ENIGMA has no variable_local_set(). When it does, that will simply access a map of references to locals, and if its not in the map, it will allocate a new one. If I didn't know every single variable at compile time, then GCC wouldn't, and the game wouldn't compile. We have no execute_string and no variable_local_set at this time.

R3 dealt with "a.b" access somewhat badly, implementing a dynamic cast between instances instead of an integer-taking accessor like R4 will use. All variables "b" accessed as "a.b" are added to an instance of Object called "Global" and identified with "global". If "b" didn't exist in "a.b", the global instance of it was returned. Some behavior is dropped that way, which is why Luda proposed a hash map. I didn't like the idea, but it will be implemented optionally down the road.

And yes, usable behaviors could work just that way. But not for the key motherfucking systems. I'm not having my parser go around picking apart and gluing back together the single most fundamental pieces of this system.

Proposals / Re: Tiering vs Components
« on: May 11, 2010, 05:46:27 pm »
Code: (C++) [Select]
extern void vague_debug_event_that_somehow_applies_to_everything();
extern void (*vague_debug_event_that_somehow_applies_to_everything_and_can_be_disabled_at_runtime)();
#ifndef ENIGMAdebug
#define vague_debug_event_that_somehow_applies_to_everything()
#define vague_debug_event_that_somehow_applies_to_everything_and_can_be_disabled_at_runtime()
Now, as far as calling that in systems that aren't designed to have special debug information; why would you need to, number one? What would you call for every function called by every system? What would be the point? To get what last executed before fail? That's where stepping through comes in.

At this second paragraph, I believe you're just trolling. The entire fucking point of the tier system is to allow files that make use of common elements to only include pieces parts of the elements, leaving the rest to mystery. Using the tier system for something as worthless as paths--that exactly one source file depends on--is about the most ridiculous thing I've heard this whole debate.

"When extending GM (e.g. reusable behaviors), components address organization issues much better than GM's single inheritance."
"They're much better than scripts, which are really just components organized in the most horrible way imaginable."
In your opinion, I'll grant that. But I'd like to point out that scripts require special passes over to get to function correctly; mostly to tell the system what other locals need included in the objects that call each script. This isn't an option for hard-coded components.
"Components do code reuse far better than templates and wizards, which are just fancy copy-paste (and so somehow different from the "real" code?)"
In your opinion, close (yes, they're different in that code is being modified dynamically by the compiler/wizard)
"That's why they're a good way to extend GM- its existing inheritance model and paradigms are irrelevant."
Yes, I agreed with this two posts ago. What does this have to do with the underlying system about which this debate is concerned?

Off-Topic / Re: David Cameron is the new UK Prime Minister
« on: May 11, 2010, 04:37:40 pm »
Ism's is probably more accurate. Ideally he'll be doing a bit of that, too.

Proposals / Re: Tiering vs Components
« on: May 11, 2010, 02:19:30 pm »
"(x and y come from which parent? PlayerCharacter or PlatformCharacter?)"
Neither; a parent of both. GM doesn't have multiple inheritance anyway. Most of what you're describing otherwise is achievable with scripts. ai_avoid_bullet(), ai_seek_powerup()... much of those will lead to conflict in either system.

Nonetheless, that is outside the scope of this debate.

Just because the language looks close doesn't mean it behaves close. The parts of EDL that require a parser to use shouldn't be employed in C++ functions. If you want with() and case "string", use a script.

"When I asked "Why would you decide to add a component pointer?" I assumed components like Path would either always be in Object or only be included in OBJ_*s. Neither would force a recompile."
The latter is impossible without a global due to inability to assume position of that pointer, which is, for the fourth time, a problem shared between components and my old system. And no, I don't want those damn pointers to always be included.

"Instantiating components inline goes back to the problem of changing tier sizes. Changing a component in such a system would have the same results as in your pre-tier system."
Hence I mentioned the (Object::*). I neglected to mention that it would be at the global scope. All the Path component's source would need to know is the location of its structure inside Object, which would be represented by extern Object::* ::component_location::path;.

"You haven't really given any points against using components for core systems other than "it's too complicated," which is a stupid reason, and "it's ugly," which is completely subjective at this point. You haven't shown how you would accomplish the debugging features I suggested without components. You haven't shown how tiers are any less ugly than components."
Debugging has always been done with preprocessors. To initiate debug mode, one flag would have to be set, and the sources could be compiled in a separate objects folder called ".eobjs_debug" instead of just ".eobjs". Tracking variable changes can be done by adding "debug_proxy<>" around all the types; something I have complete control over. I know I've mentioned that, maybe I didn't stress it. And although I wasn't going to mention it until plans were laid, I was considering hooking up GDB to the debug window when the time comes to allow stepping through code one expression at a time, like Code::Blocks and other IDEs do.
And I said that the code produced is uglier. Saying "x" is prettier than saying "x()".
Every benefit you've suggested to using components on the lower system, I gave how it would be accomplished with the current system instead. Feel free to enumerate more, and I'll respond to them as well.
And the argument isn't that it's too complicated, it's that it is -more- complicated. And all else being the same, the simpler method wins.

General ENIGMA / Re: ENIGMA's value
« on: May 11, 2010, 01:30:59 pm »
Josh is making THAT MUCH?

Proposals / Re: Tiering vs Components
« on: May 11, 2010, 01:24:07 pm »
In GM, you would create object Character and then have objects Mario and Luigi inherit from that, incorporate a jump_height in Character so Luigi's can be higher than Mario's, as well as setting a sprite_base, then call inherited event if need be. Granted, GM's gross system of resource ID-ing could inhibit that sprite_base idea. That can be worked out later (LGM already has some features for that).

Does it truly matter how close the end result is to the EDL? No, not really. But if I get it close enough, I can let users choose to stop relying on the parser and do their coding entirely in C++, which would be an interesting opportunity to leave open. Besides, should they choose to start developing their own C++ functions, having to put an () after all the variables would be required and is annoying.

The path system is a great example of a waste of a component/tier. It implements some seven variables for its own purpose, using only about two from other tiers/components. I could think of a hundred additional systems I can do that with. Paths, and any systems like them, would be best suited to components because they have very little dependence on anything else. Paths incorporate their own speed variables, their own index variable; the only thing they really need from other tiers is x and y. Paths, and components like them about which the system is not designed, are a good reason to add a component pointer.

Of course, my component pointer would be done somewhat differently than yours. Because I understand that I am in control of the layout of object, the pointer would be achieved by making the compiler instantiate the path component inline. As in, say the path component contained path_index, path_position, and path_speed. Those three would be added in-place into the structure by the compiler, and the component pointer would be taken by casting the (Object::*) to (PathComponent*), which would be non-virtual.

The lower tiers, on the other hand, including graphics and collisions, I have denounced all your reasons to use components for. They will be of no more use to me in debugging than preprocessor expressions and a separate folder for debug object files. They only serve to complicate dependencies since they are all ground level, and they don't improve performance in any way. Not to mention that they make code ugly.

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.