freezway
|
|
Reply #30 Posted on: March 30, 2010, 06:20:01 pm |
|
|
Joined: Dec 2009
Posts: 220
|
can someone explain this in english?
|
|
|
Logged
|
if you drop a cat with buttered toast strapped to its back, which side lands down? joshdreamland: our languages are based on the idea that it's going to end up FUBAR /kick retep998
|
|
|
|
freezway
|
|
Reply #32 Posted on: March 30, 2010, 07:35:27 pm |
|
|
Joined: Dec 2009
Posts: 220
|
... JUST USE THE CURRENT FRIGGING THING B/C IT GET DONE SOONER!
|
|
|
Logged
|
if you drop a cat with buttered toast strapped to its back, which side lands down? joshdreamland: our languages are based on the idea that it's going to end up FUBAR /kick retep998
|
|
|
|
|
Josh @ Dreamland
|
|
Reply #35 Posted on: March 30, 2010, 07:41:38 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
"SOMETHING THAT WASTS A CPU CYCLE " Something that quadruples (probably more accurately decatuples, but I didn't want to assert a too-outlandish figure, after all) the number of clock cycles necessary to look up a fucking variable in a class I have a pointer to?
"Slippery slope, circular logic and outright lies." I pointed out the slippery slope myself, with a slight satisfaction I might add ("That was a slippery slope fallacy. It's pretty commonly used in court cases"). There was no circular reasoning as far as I can discern, and I assure you none of it was a lie.
"If you want to build a bad system, go ahead, but don't come asking for suggestions." A "bad system" in the opinion of one who would multiply the number of cycles necessary to look up a fucking x value, in a class to which I have a pointer, by at least four. In my opinion, and in the opinion of everyone else on the team who didn't feel you were worth responding to, it's better not to waste the cycles on something like x.
Also, I didn't even explicitly ask for a suggestion, I simply welcomed them. I didn't explicitly ask you, either. You gave a suggestion, I declined it. You continued to defend it, I continued to decline it. If you can't cope with me declining a suggestion, quit offering them.
|
|
« Last Edit: March 30, 2010, 07:52:38 pm by Josh @ Dreamland »
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
freezway
|
|
Reply #36 Posted on: March 30, 2010, 07:45:05 pm |
|
|
Joined: Dec 2009
Posts: 220
|
PWND!
|
|
|
Logged
|
if you drop a cat with buttered toast strapped to its back, which side lands down? joshdreamland: our languages are based on the idea that it's going to end up FUBAR /kick retep998
|
|
|
Rusky
|
|
Reply #37 Posted on: March 30, 2010, 07:55:32 pm |
|
|
Joined: Feb 2008
Posts: 954
|
Basically, Enigma is designed to combine gm with c++. Rusky says screw that, and make it like haskell. Josh says no, cuz that's slower. I say no, BECAUSE IT DEFEATS THE WHOLE PURPOSE OF ENIGMA! No. This has nothing to do with Haskell. My suggestion was to make selectable systems rather than tierable systems- you could pick any graphics system including a lack of one, same with any other system, and you would be able to build your own reusable systems. Josh thinks that would be too slow because he has no concept of scale, he hasn't run any benchmarks and he hasn't even seen such a system in action. It absolutely does not defeat the purpose of Enigma. It helps it. "SOMETHING THAT WASTS A CPU CYCLE " Something that quadruples (probably more accurately decatuples, but I didn't want to assert a too-outlandish figure) the number of clock cycles necessary to look up a fucking variable in a class I have a pointer to? The question is how often you need to look up that variable that way, not necessarily how fast that lookup is. "Slippery slope, circular logic and outright lies." I pointed out the slippery slope myself, with a slight satisfaction I might add ("That was a slippery slope fallacy. It's pretty commonly used in court cases"). There was no circular reasoning as far as I can discern, and I assure you none of it was a lie. I wasn't referring to the post in which you pointed out your fallacies. It was a slippery slope from accessors to changing the calling convention. Circular logic was you excusing your lack of examples of my suggestions by just assuming they must exist. GM does not have 7 fps except in your unrealistic particle system examples. There are plenty of nice-running games in GM. That was the lie. "If you want to build a bad system, go ahead, but don't come asking for suggestions." A "bad system" in the opinion of one who would multiply the number of cycles necessary to look up a fucking x value in a class to which I have a pointer by at least four. In my opinion, and in the opinion of everyone else on the team who didn't feel you were worth responding to, it's better not to waste the cycles on something like x. Yes, it is my opinion that it is a bad system. It would also be the opinion of a lot of other programmers. However, if you're going to post ideas here and have people discuss them, don't be surprised when people do so. Besides, with a component system, which you seem incapable of understanding, you wouldn't be wasting those cycles. Internal code accessing x would be in the component that owns x, with no virtual methods or accessors of any kind. External accesses could be inlined, although they would require an extra pointer lookup to get to the component. However, even in the worst-case scenario of non-inlined accessors, you don't even know what the real-world impact would be, so you really have no defense at the moment.
|
|
« Last Edit: March 30, 2010, 07:58:10 pm by Rusky »
|
Logged
|
|
|
|
Josh @ Dreamland
|
|
Reply #38 Posted on: March 30, 2010, 08:13:23 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
"you could pick any graphics system including a lack of one, same with any other system, and you would be able to build your own reusable systems" That's the intention of this system as well. I'm taking a different approach, attempting to reduce everything to organized tiers assuming a chain of previous tiers.
"Josh thinks that would be too slow because he has no concept of scale, he hasn't run any benchmarks" Josh asserts that this is slow relative to the system in place, due to the factor by which the necessary number of cycles will be multiplied. Josh would rather remove those cycles, pushing the excess time consumption on the compile process rather than the running engine.
"unrealistic particle system examples" 250 * 20 = 5000. If that's an unrealistic number of lines, I can't wait to see your responses when I'm running a 1,000,000 pixel-particle shader. And yes, yes, shaders are so much different. Only not really; they're a great way to speed up heavy procedural particles. Which that example was. Something is not "unrealistic" just because Game Maker can't pull it off at >10 fps.
"Circular logic was you excusing your lack of examples of my suggestions by just assuming they must exist." I'll grant it again due to laziness. But now I'm starting a list.
"There are plenty of nice-running games in GM. That was the lie." There are plenty of nice-running games for DOS. Therefore Portal requires an unrealistic system to run. (inb4 portal for DOS) Try making anything 3D in Game Maker. Oh, but GM isn't for 3D? Well, it's not for decent game creation either.
You suggested yourself that the accessors be virtual, and then verified yourself that virtual and inline were exclusive. The workarounds to make everything non-virtual would be the same as those when working with this simple tiered system. So leaving them non-virtual comes down to me not seeing the point, other than that you suggest it makes more "sense."
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
Rusky
|
|
Reply #39 Posted on: March 31, 2010, 06:51:32 am |
|
|
Joined: Feb 2008
Posts: 954
|
Tiers would let you add your own systems, but that kind of a system doesn't allow you to choose which systems you very easily. Every combination basically needs its own chain.
Yes, more cycles are slower. However, with a component system, you greatly reduce the number of times you actually multiply the number of cycles, and completely eliminate it in some places. Same effect with a better system.
Games are not particle system displays. That's why it's unrealistic. Either way, particle systems don't usually involve rotating lines, but rather small sprites and possibly shaders, which are much more hardware-accelerated. Maybe if you tried GM's particle engine it would be better?
There are plenty of nice-running games in GM, which are nicer than many DOS-standard games. Besides, DOS's limitations come from hardware, not software. It runs in real mode, which has severely limited memory among other things. The reason GM isn't for 3D is not its speed- it's the fact that the editor was not designed for 3D. Enigma, currently, is not designed for 3D either. However, GM doesn't run on DOS, and when you use it for what it's designed for, you can make decent games.
I'll try to explain the component system again. Rather than use inheritance, objects would hold pointers to components. There would be a physics or motion component holding x and y (if they're in a component at all). Physics components would all inherit their required members from the same base class, so even if you change the system you're using, the core stuff will all be in the same place. Accessors would be inline- return someComponent->x. It serves the same purpose as the tier system while being much more flexible.
|
|
|
Logged
|
|
|
|
Josh @ Dreamland
|
|
Reply #40 Posted on: March 31, 2010, 10:25:34 am |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
What happens when I remove the draw tier and the pointer to the collision tier is a DWord shorter than it's supposed to be? Or do I just leave a NULL pointer in there anyway and maybe optimize it out on full compile? I'd rather try to keep the quick compile and optimized compile at least vaguely close, if only for the sake of games running in debug mode.
Though, I think you keep missing the point of a demonstration. Most of what I say is demonstrative of a system I assumed doesn't need explained. That particle demo isn't the only neat particle system you can do with a bunch of lines. The entire point of that demo was to show not that ENIGMA can run a massive particle system faster than GM, which is obvious, but to show that graphics-heavy (specifically of the code-drawn variety since most of the sprite work can be done with compiled code in GM) effects code can actually start to be employed now. ENIGMA could draw four of that which GM couldn't render one, and do so at full FPS rather than GM's 7fps. That wasn't meant to incinuate that everything about ENIGMA is so much faster (though I'm fine with everyone believing that); it was meant to imply that new options are available as far as designing effects for games. Serprex in particular has always been big on not including sprites in his games; he either creates them at load time or draws them procedurally the entire time. Most of his games don't have a single sprite. Is this extreme? Probably. Did I respect him for it? Hell yes.
The same can be said about ENIGMA. I'm scrutinizing absolutely everything to make sure all this code works efficiently at run time. There comes a problem of increased compile times along with that sometimes, but I'm personally willing to sacrifice a little compile time to make room for a lot of run time, and I imagine most here would agree with me on that. As nice as a quick compile is, I prefer a quick game.
A problem with this tier system, as you know, is the inability to just use multiple inheritance and hope that the compiler sorts everything out for us. This shot down one of my main hopes for the system; I wanted users to be able to decide that they no longer wished for their locals to be var, but to use int or even double instead where applicable. No system here, including my own, will allow doing that without recompile; we would have to try using a void* to everything and then a global to specify the type, which goes against the point of just using var anyway (though memory saving from string and global would be sizable, speed savings would be none or less).
Swapping systems out for other-sized systems is also a possibility, but is unlikely: The goal of most of the systems was to implement the same variables from GM for the sake of compatibility. Granted, later on we may add support for other locals due to one system, but then it will be a goal to get the same new variables working in all the other systems to achieve the same performance no matter what platform. That was one of the reasons I still liked supporting GML; 1. A huge audience knows it, 2. Those who don't can learn a few functions and guess at the rest, 3. When they want to compile for a different OS, even as different as the Wii, their code will not require modification (or will require very little).
That said, it would seem against at least my philosophy to have two systems requiring a local structure of different sizes where a new tier shouldn't have been added.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|
Micah
|
|
Reply #42 Posted on: March 31, 2010, 04:48:27 pm |
|
|
Joined: May 2008
Posts: 128
|
Basically, Enigma is designed to combine gm with c++. Rusky says screw that, and make it like haskell. Josh says no, cuz that's slower. I say no, BECAUSE IT DEFEATS THE WHOLE PURPOSE OF ENIGMA! Rusky never, ever suggested that Josh make any changes to Engima that have anything to do with Haskell whatsoever. Maybe you should pay a little more attention to things before you start mouthing off in defense of your big brother. Rusky was suggesting a system that would pretty much add no overhead and would greatly increase the flexibility of the system Josh is talking about adding, the point of which, is to add flexibility in the first place. Josh misunderstood him and thought that it would add much more overhead that it would (although even that amount would probably be negligible anyway). You completely failed to understand what was going on, along with the other tards who are shouting "PWND," and other such mindless exclamations, to reassure themselves of the superiority of the side that they are taking, when Josh makes a post showing his failure to understand what Rusky was proposing.
|
|
« Last Edit: March 31, 2010, 04:54:35 pm by miky »
|
Logged
|
|
|
|
Josh @ Dreamland
|
|
Reply #43 Posted on: March 31, 2010, 04:58:37 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
"Maybe you should pay a little more attention to things before you start mouthing off in defense of your big brother." lolirony
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
Rusky
|
|
Reply #44 Posted on: March 31, 2010, 05:02:20 pm |
|
|
Joined: Feb 2008
Posts: 954
|
I would put a blank draw component, rather than a null pointer. No null checks required for the majority of the cases, and possibly complete removal in the case of the blank draw component. This would also work for switching the visible option on and off, especially if draw events were put into each object's draw component. Different-sized systems would be possible because they could be stored as pointers to components with common parents. You would always be able to depend on the parent and thus the default fields. New systems could add, besides just new fields, new or different functionality. You could have components that implement only certain parts of GM's default object behavior, for example. Systems could be for behavior and optimization besides just cross-platform compatibility.
The reason I don't think your demo was realistic was that that wasn't how that effect would be accomplished in GM. I don't know how GM's particle system works, but it's probably optimized for particle systems, and possibly hardware accelerated. I used it as an example because you (ridiculously) claimed that GM games all run at 7 fps. The most recent time that actually happened was your example, where GM was used as it probably wasn't intended.
|
|
|
Logged
|
|
|
|
|