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

1966
Announcements / Re: Fixed those Makefiles
« on: May 16, 2010, 12:21:57 PM »
The splash screen doesn't display here; I assumed you'd removed it.

1967
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 09:31:15 PM »
Well, it's an irremovable part of ENIGMA's philosophy. And it's a bit late to fork the project over it. If you don't like it, you don't like ENIGMA, and you probably don't belong here.

1968
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 08:25:19 PM »
In the case that it is declared as "local int", "local string", or what have you, in a later event, which could be considered bad practice, but it seems asinine to disallow that over the minuscule amount of work taken to support it.

1969
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 06:55:06 PM »
COBOL did work fine, then we found something better.
Hey, go find something better.

Don't give me "lots and lots" bullshit; I can enumerate every inconsistency with the languages and what's been done about it. There are roughly five. Holding lexed code to determine what type an object is before acting on it isn't one of those inconsistencies.

1970
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 06:46:05 PM »
I recall no such people.

C++ isn't a problem with the architecture; clearly it's working fine. Just not with your proposal. This doesn't agree with your idea of what I should be doing, so you see it as a problem.

1971
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 06:42:43 PM »
Great ad hominem. Is there an argument to go with it?

1972
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 06:40:59 PM »
And to that I'm saying "Fuck you."

1973
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 06:39:41 PM »
That's impossible to do from a compiled language with integer-id access.
Furthermore, neither of us know that for certain.

1974
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 06:36:46 PM »
There is no difference between what ENIGMA is doing and what Mark did with globalvar.

Also, if you're going to forward that ENIGMA should introduce no new functionality over its "ingredients," you destroy your component argument for systems that can actually use them later on. Or rather, your brother's; you never actually forwarded an argument.

1975
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 06:33:41 PM »
Good argument. (Y)

What ENIGMA does with its token string later on is essentially what C++ does while it links. It's also what Mark has to do to check if a variable was previously declared as globalvar.

1976
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 06:09:40 PM »
Nah, I don't like that idea. :troll:

Anyway, the tokens need to remain in memory so I can go back over them for another pass as more information becomes available, such as localized types and members by certain types.

For example, a.size would mean two different things based on the type of "a." If left undeclared, or declared scalar, the meaning is to access "a" as an object by id, then access implicit member "size." Otherwise, it should be left as-is.

1977
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 05:52:29 PM »
Except that each operator would require its own element in the list, with a forward and reverse pointer. Unless I'm missing some magical way to eliminate that, we'd be multiplying by either 9 or 17 the size of each operator.

1978
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 05:22:37 PM »
"Your only argument against using Rusky's parsing method besides that you created the one you're using yourself was that it uses too much memory. Having smashed that argument and you having dropped it, now we're back to how you keep choosing crappy methods just because you came up with them."
I acknowledged that replacing the second string with linear-linked structures would be more efficient and would probably be done at some point in the future. Now is not the time, as the only end of that system is to work. Furthermore, I had thought of that idea long, long ago; the method now employed was simply quicker to implement.

Moreover, it is unlikely that the newer method would save memory, but it would probably save insertion time. Because I don't know the gain and the gain is unnecessary, it's not high on my priority list.

1979
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 11:48:03 AM »
That's actually just type; and yes, I'd considered doing something like that (using one char and a pointer instead of the full name) if only because it saves space, but then I realized that memory is cheap and that it's pretty much worse it for the ability to just cout << both strings to see if anything is the matter. It could probably be more efficient both in memory and in cycles, which is why I've been considering redoing it for a while with a linked list of such structs. It'll basically happen on a when-I-get-around-to-it basis, though, if it ever does happen. This method has proven quite convenient and simple to code for.

And don't use this as an axiom for why compiled games should be allowed to bloat; the compiler has no effect on the end end user.

And as a fun side note, this was posted through some miracle through the Wifi of a local restaurant or something; I'm in the car right now headed off to some race (against my will, I might add) and will return later.

1980
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 11:02:04 AM »
I don't see anything wrong with what you've said about my parser--the good or the bad--; I also don't see any reason to bother using a lookup table to conserve so little space, especially compared to GCC's AST. I know I don't have the skill to write an AST better than Clang's; to forsake a method this simple in an attempt would be asinine.

Anyway, does this mean you are finished defending the component system? At this point, I see no gain in using it instead of tiers for up to the collision system; only loss.