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, 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.

Proposals / Re: Tiering vs Components
« on: May 14, 2010, 09:03:51 PM »
Sure, sure, miky. Clearly this wasn't the replacement for a less-thought-out system.
Believe what you will; your thoughts of matter are of little importance to me.

Proposals / Re: Tiering vs Components
« on: May 14, 2010, 05:39:26 PM »

∴ ∅

Proposals / Re: Tiering vs Components
« on: May 14, 2010, 04:23:55 PM »
The problem is of what they're more important than. More important than an assortment of debug features and a new method of having four systems be dependent on each other, then yes, they are. The microseconds, anyway, for which I've recoded plenty of things to save more.

Proposals / Re: Benchmark mode
« on: May 14, 2010, 04:20:04 PM »
At first it crossed me as a good idea, but I see a few problems.
I'm not sure about GCC's support for 3DNow!, but there's a problem with having ENIGMA make specific choices like that for the user; the user isn't the end user. Or rather, there's an end, end user.  Offering an assortment of optimization flags is by all means a good idea and relatively effortless, yes, but a mode to determine them should only be used as a diagnostic tool for the benefit of the user; ENIGMA shouldn't act on the results of it.

Basically, it should be up to the user to decide that the end users must have X, Y, and Z extension. Not every ENIGMA game is going to have the dependencies of even typical well-endowed games like Portal, for instance. Portal requires pixel shader 1.0; it works on three computers of the seven in this house. But most GM games are more closely akin to Click the Clown, and so shouldn't be set to require more modern extensions just because the user (but not necessarily end user) has a $400 card.

And yes, that's a gross exaggeration, but we're talking about a user base whose cards don't support post-WWII extensions. Okay, another exaggeration. But seriously, integrated Intel chips don't support extensions from 1985. Just not a great idea to put a button for "Use my PC's extensions as the minimum requirement" at the hands of people with more money than wit... that button would basically never be a good idea.

Anyway, as a diagnostic tool, I'll consider such a test program and settings for restricting, possibly based somehow on the results.

Proposals / Re: Tiering vs Components
« on: May 14, 2010, 02:58:13 PM »
I was thinking of such, but it'd have to be more than two columns so each new argument could be responded to. Actual debates are usually done by giving each side time to organize their argument, and then each side responds a certain number of times. I forget whether it is the one with or without the burden of proof who presents last.