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 15, 2010, 06:40:59 pm »
And to that I'm saying "Fuck you."

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.

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.

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.

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.

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.

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.

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.

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.

Proposals / Re: Tiering vs Components
« on: May 15, 2010, 10:44:36 am »
Now you've made it clear--as I knew you would--that you don't know how ENIGMA obtains its source. I'll save you the reading: it obtains it as a string in memory from Java. All at once. Every code. There is no "reading the source character-by-character until you recognize a token" because there is no source code to read.

And, if you know that I replace "and" with "&&&", "if" with "ss", etc., then you know how I determine what character to lex the token as. And you understand that adding a token is as simple as saying tokens[tokenname] = tokenchar;, and that instead of fiddle-farting around with a new structure for <> when I add templates, that I will instead replace tttt<..........> with tttttttttttttttt, and it will work flawlessly.

But I know you didn't consider that, because you only see the immediate; JOSH ISN'T LISTENING TO ME.

Proposals / Re: Tiering vs Components
« on: May 15, 2010, 10:36:20 am »
Your method creates a tree. I am 100% certain a copy of the string uses less memory than your tree. Or did you not think about that?

That second string is my lex string. If you knew how the method worked, you'd have seen that from square one.

Proposals / Re: Tiering vs Components
« on: May 15, 2010, 10:22:45 am »
"more memory-hogging"
Clearly you're not making any of this up. Have figures?

For someone who is expecting a token tree with which he has much experience, perhaps. I chose my method because it was so simple, a fifteen-year-old could think it up. GML doesn't require a token tree. Keeping one is pointless. If nothing else, I at least lexed the GML since I would be modifying it.

Reading C++ doesn't require a tree, either. If your program has sufficient understanding to place the code in a tree, your work is already done for my purposes. Perhaps I'd have used something different had you proposed it less than 3/4 way into development.

Announcements / Re: Fixed those Makefiles
« on: May 14, 2010, 11:11:49 pm »
It's some Java bug (Ism says it's actually an X bug, but I blame Java as well since nothing else kills X) invoked when a drag and drop tile is released.

Announcements / Re: Fixed those Makefiles
« on: May 14, 2010, 10:01:44 pm »
That doesn't help the shit-my-entire-computer-is-frozen-because-java-killed-X problem.

Proposals / Re: Tiering vs Components
« on: May 14, 2010, 09:12:24 pm »
If you want to reorganize your argument and refocus it, I'm prepared to drop what I've read thus far and reconsider it. Structure it in a manner that shows its benefits as applied to the lower systems. This almost immediately excludes dependency resolution for reasons past explained, unless you can generate a decent counter-example.