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

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

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

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

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

1985
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?

"harder-to-understand"
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.

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

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

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

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

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




∴ ∅




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

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

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

1994
Proposals / Re: Tiering vs Components
« on: May 14, 2010, 02:20:25 PM »
I gave examples of what I claimed you've done, and I've dropped none of my criticisms; I'd ceased to emphasize some, such as the efficiency concern I reintroduced in the last post, simply because you have no defense against it other than shrugging it off as "negligible." That has been a concern since square one, back when you were casually proposing this system and I was casually declining it. I've emphasized time and time again that it introduces no useful features for the lower tiers, that it makes ugly code with accessor calls everywhere, that it's a bitch to implement, that it shares dependency structure with the tiers anyway.

Show me contradictions; I've pointed out yours (back when you were trying to pass components off as simpler organizational methods, but yes, they're a bitch to resolve), and show me vague, angry sentences.

Also, does this mean you can't defend yourself against any of the previous post?

1995
Proposals / Re: Tiering vs Components
« on: May 14, 2010, 09:24:57 AM »
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.