Josh @ Dreamland
|
|
Reply #45 Posted on: March 07, 2010, 09:52:38 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
No one asked why you didn't work, we stated that you didn't. You defended yourself. We didn't ask for such.
C++ isn't an afterthought to me. Granted, it wasn't truly part of the plan from the beginning, but as far as I am concerned, it was. I will be treating it like it was.
If the users allocate things, it's up to them to free them. C++ has destructors; what more does it need? The only place I introduced anything resembling a GC was for instance_destroy, and that was only to prevent a delete this; followed by invalidating an iterator. Nothing else in the project is particularly prone to leak...
"You need a separate executable for every architecture anyway." Good, may as well make it all native and strip unused goodies as per the original plan.
"Clang is more standards-compliant than GCC." Again, I'm not using Clang. I don't care how standards compliant it is; I don't see it compiling for all the things the GCC compiles for.
|
|
« Last Edit: March 07, 2010, 09:55:21 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
|
|
|
Post made March 08, 2010, 08:25:00 am was deleted at the author's request.
|
Rusky
|
|
Reply #47 Posted on: March 08, 2010, 10:22:23 am |
|
|
Joined: Feb 2008
Posts: 954
|
Of course you didn't initially ask. But after I stated my reasons, you asked "What good design would you be torturing with GM's?" and that's when you were "bombarded with languages" or whatever you called it.
C++ isn't an afterthought for Enigma, but it is for GM. Enigma's design is GM + C++, it was created without C++ in mind. The user doesn't allocate a the things that do get allocated- by the engine. Are you going to leave all the rooms with all the backgrounds and all the sprites loaded the entire time? Even if you use all stack-based allocation for user code, you have to have some way to deallocate stuff the user doesn't allocate.
You can't have a windows and linux executable in the same file. You wouldn't be putting the linux VM in a windows executable. Basically, size is not a reason to use a VM as you claimed. So your reason for using a VM is... you aren't already doing it? Size and speed aren't problems as you've seen.
LLVM supports x86 and PowerPC, 32 and 64 bit versions, Arm, and several other processors. What else are you planning to support? The fact that Clang is standards-complaint nullifies the advantage you claim GCC has in parsing the standard library. Clang is the one with the advantage there- it will parse it for you. With GCC you have to do it yourself, so it all gets parsed twice.
|
|
|
Logged
|
|
|
|
|
|
Josh @ Dreamland
|
|
Reply #50 Posted on: March 08, 2010, 02:05:45 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
"Enigma's design is GM + C++, it was created without C++ in mind." Assuming it is the fault of a typo that the sentence is contradictory, you are apparently trying to tell me what was on my own mind as I created the project... "Are you going to leave all the rooms with all the backgrounds and all the sprites loaded the entire time?" Considering that this is exactly what GM does, I don't see doing so as a problem. I intend to implement a system to use object grouping data to allow importing and exporting blocks of resources, maybe on a basis that won't need the game to freeze (reading a small amount each step so small cutscenes can run in the game in the meantime). However, this is irrelevant to the current argument. You are asking me to include a garbage collector for data the *engine* works with? Garbage collectors are for the lazy. They aren't very slow as of late, but they will never be as fast as handling the allocation and freeing linearly,except, maybe, with a well-optimized VM the likes of which will not be written for this project and thus is again irrelevant. I'm not writing a garbage collector for my own convenience, and I cannot make accurate guesses at which resources will be added when, due a lot to how GML is structured. "So your reason for using a VM is... you aren't already doing it?" Incorrect. The only reason to use a VM for this project is to have a once-compiled, cross-platform module. The necessary VM to run such a project on each system would need to be installed on each system, however, thus totally ruining that idea. And don't give me any shit about how many people have LLVM installed; there are people out there who don't even have Java installed, and that's giving me a hard enough time as it is. Also, I didn't claim that GCC had an advantage in parsing *the* standard library. I implied it had an advantage in parsing *its* standard library. Which is better than Clang's because it comes with GCC, which is better than Clang because there is a version of GCC to cross compile for everything I ever wanted to port ENIGMA to (my favorite presently being the Wii). All the Wii Brew developers utilize GCC, last I checked. Feel free to move to their forums and convince them to switch to Clang; I'm sure none of them will laugh at you. "Your search - site:wiibrew.org clang - did not match any documents." No one there even advocates the noise the project was named after.
|
|
« Last Edit: March 08, 2010, 02:17:56 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
|
|
|
Micah
|
|
Reply #51 Posted on: March 08, 2010, 04:28:45 pm |
|
|
Joined: May 2008
Posts: 128
|
He was explaining that the bulk of Enigma is already designed, as Game Maker. Game Maker was designed completely separate from C++.
So your argument against including GC is that real programmers don't use GC? In that case, you should stop using C++, because real programmers use butterflies. It would be really stupid not to include some way to get rid of the crap that users allocate. That's one of the reasons GM takes up so much memory, and I thought a main goal of this project was to make a more efficient GM.
You're completely failing. A VM is not something that has to be installed on the user's computer. The Lua VM is very, very small, and it's almost always embedded in the programs that use it. Look at Löve2D. LLVM works the same way.
Clang parses the whole thing for you, so you would be done already with what you've been working on for... how many months?
This was mentioned a while ago, but I'll answer it now. Closures are not only in functional languages. C#, Ruby, and JavaScript all have closures, all of which are not functional languages at all.
|
|
« Last Edit: March 08, 2010, 05:33:53 pm by miky »
|
Logged
|
|
|
|
Rusky
|
|
Reply #52 Posted on: March 08, 2010, 05:01:17 pm |
|
|
Joined: Feb 2008
Posts: 954
|
Sorry, GM was originally created without C++ in mind. "It" was rather ambiguous.
GM also uses a lot of memory; why would you use what it does as justification? Also, manually allocating and freeing requires a different kind of heap than what GC usually uses. It's not really faster, it's just got the load in a different place. Have you ever written malloc? The only difference is that GC puts the load on freeing while manual puts the work on allocation. If the collector ran at the right time or in a different thread, it could potentially be faster. Finally, I never suggested making Enigma's internals garbage collected, only the parts that the user interfaces with or writes.
Ack. Having a once-compiled module is one advantage, yes. But the user would not have to install the VM on their system. Just like GM games include the runner and Enigma links the engine to the game, it could be included with the game. Literally nobody has LLVM installed, because it's a library intended to work exactly this way. There are also several other advantages of a VM. The game module could be easily separated for use with different runners simultaneously like instant-play. Optimization can be more aggressive with JIT. The engine's API, the runner and the games would be decoupled.
Clang is GCC compatible. The platform it's built on supports PowerPC. There's no reason for it not to support Wii in the future (just like it will support the rest of C++ in the future). I did not suggest using Clang right now. However, Clang has a separate library that will parse C++ for you, which would save you the work of having to do it yourself as well as allow future versions to cooperate with the Clang compiler to get rid of all the unnecessary work.
Just so you know, again, I am not advocating Enigma using these tools or even techniques. I'm just giving you the design you asked for.
|
|
|
Logged
|
|
|
|
Josh @ Dreamland
|
|
Reply #53 Posted on: March 08, 2010, 05:38:54 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
So your argument against including GC is that real programmers don't use GC? In that case, you should stop using C++, because real programmers use butterflies. It would be really stupid not to include some way to get rid of the crap that users allocate. That's one of the reasons GM takes up so much memory, and I thought a main goal of this project was to make a more efficient GM. I didn't say I wanted to act anything like a real programmer, I said that garbage collecting my own code was lazy and that GML doesn't have anything worth garbage collecting, especially being so spontaneous as a language. Again, GM users don't allocate anything. I've sometimes opened files and forgotten to close them, yes, but that can't be garbage collected. Nothing in GM can be, because everything is an integer. There is no reference, weak or strong. A reference can be pulled out of one's ass. You're completely failing. A VM is not something that has to be installed on the user's computer. The Lua VM is very, very small, and it's almost always embedded in the programs that use it. Look at Löve2D. I'm aware. I couldn't tell what in specific Rusky was promoting, probably due to the fact that he claims not to be advocating anything in specific. Clang parses the whole thing for you, so you would be done already with what you've been working on for... how many months? Almost half a year, thanks. Probably less than Clang spent on theirs, or has left before they say it supports all of C++. GM also uses a lot of memory; why would you use what it does as justification? Also, manually allocating and freeing requires a different kind of heap than what GC usually uses. It's not really faster, it's just got the load in a different place. Have you ever written malloc? The only difference is that GC puts the load on freeing while manual puts the work on allocation. If the collector ran at the right time or in a different thread, it could potentially be faster. Finally, I never suggested making Enigma's internals garbage collected, only the parts that the user interfaces with or writes. That wasn't meant to be justification in the sense that it was excuse; I should have been more specific. I can't just load and dump resources as they come in and out of need, simply because I never really know when they're needed. GM always keeps them in memory; when the user wants them, they are there instantly. The best I can do is provide functions to give the user more control of that. Like I said, not much in the GML really needs freed. GM offers no method of freeing anything except through functions ending in _destroy. I suppose those could have threaded frees, but I'm not sure it'd be worth it to do so. Ack. Having a once-compiled module is one advantage, yes. But the user would not have to install the VM on their system. Just like GM games include the runner and Enigma links the engine to the game, it could be included with the game. Literally nobody has LLVM installed, because it's a library intended to work exactly this way. There are also several other advantages of a VM. The game module could be easily separated for use with different runners simultaneously like instant-play. Optimization can be more aggressive with JIT. The engine's API, the runner and the games would be decoupled. I know little about LLVM. Simply have no interest in it, especially seeing that the only advantage it seems to have is a potentially more aggressive optimization, which no one has backed up (in advance: "it's a fact" will not back this up). That separation doesn't seem to be an advantage. In fact, I take it for more of a problem; the same problem half the GMC was screaming about. ENIGMA games compress to fit inside 300 KB. Last I recall, they compress to fit in just over 100. This sounds like another attack on compression and step back toward decompilation-made-simple. Yes, obfuscation... Just like Yoyo's been promising but never delivered... Not good enough if they did. Clang is GCC compatible. The platform it's built on supports PowerPC. There's no reason for it not to support Wii in the future (just like it will support the rest of C++ in the future). I did not suggest using Clang right now. However, Clang has a separate library that will parse C++ for you, which would save you the work of having to do it yourself as well as allow future versions to cooperate with the Clang compiler to get rid of all the unnecessary work. GCC compatibility is a plus you'd not yet advertised. You did mention it supports PowerPC, but just because there is no reason for something not to happen does not mean it is going to happen. There's also no reason for it to support Wii in the future. Just because you are enamored with it, and maybe others are, doesn't mean someone will take the effort to do for it what they did for GCC. The work is done, and people are happy with it. Passing the parse work off to clang would have been nice if I knew I could trust it and I knew so from the beginning. Since my parser's done now, and in the format I like, I have no reason to switch to anything else from here on out. Unless something really stupid happens. Again, I didn't ask for a design. I wrote my own, and it's done now. I don't want to hear about other techniques unless they are genuinely worth the work to replace what I have with them.
|
|
|
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 #54 Posted on: March 08, 2010, 06:26:54 pm |
|
|
Joined: Feb 2008
Posts: 954
|
So there's no strings, surfaces, data structures, sounds or images that you could ever possibly delete? How could you not tell what I was promoting VM-wise? You can't have a windows and linux executable in the same file. You wouldn't be putting the linux VM in a windows executable. You only need one VM in an executable, not one for every architecture. You need a separate executable for every architecture anyway. Thus, a 20Mb runner is a myth. A VM doesn't need to be a separate thing like the JVM or .NET/Mono. It also doesn't need to be large, especially if it's not a separate installation with all the libraries in the universe. I think I made myself fairly clear on the nature of the VM I was describing. Clang has been going for at least 2 and a half years. LLVM has been around far longer- nearly 10 years. Clang's C++ parser is done. What's not done is public/private/protected/friend checking and some code generation. This means that if you were to use Clang's parser you would have a complete (and not redundant) parser in the time it would take you to set up a library, rather than in the time it would take to write a whatever-you-have. That's a good thing. LLVM has its website to back itself up. Check it out. Trying to prevent decompilation by using native code is just silly. What harm has come out of the decompiler other than the frightening of a few 10-year-olds? Size might be an argument, but any decent-sized game's resources are going to be much, much larger than its engine, and if you include execute_string/file then you have to have some kind of parser anyway and it may as well be the same (removable) one. To support Wii, you need to 1) compile for its architecture and 2) link with its libraries. Clang can already do the first. The homebrew libraries are for GCC, so Clang could support Wii without the developers themselves even caring. I doubt the GCC developers do. There wouldn't be any work beyond possibly recompiling the Wii libraries. Again, I didn't ask for a design. I wrote my own, and it's done now. I don't want to hear about other techniques unless they are genuinely worth the work to replace what I have with them. I quote: What good design would you be torturing with GM's?
|
|
|
Logged
|
|
|
|
Micah
|
|
Reply #55 Posted on: March 08, 2010, 07:12:14 pm |
|
|
Joined: May 2008
Posts: 128
|
Nothing in GM can be [garbage collected], because everything is an integer. There is no reference, weak or strong. A reference can be pulled out of one's ass. So can pointers in C++. Does that mean that C++ can't be garbage collected? Almost half a year, thanks. Probably less than Clang spent on theirs, or has left before they say it supports all of C++. Yours has absolutely no way of being adapted to do anything but get information from template declarations. Theirs turns C(++) into LLVM bytecode. Bragging that yours took less time, even if it did, means nothing. Clang has many advantages over GCC, one of which is incredibly better error messages. And since it can be used on anything with LLVM support, LLVM may very well be ported to the Wii. NOTE: I am not advocating that you switch to Clang anytime soon. LLVM isn't much higher-level than normal assembly; it's just not machine-specific. It's nothing like JVM or .NET bytecode. It wouldn't really be any more decompilable than machine code from GCC. Anyway, the whole decompilation and obfuscation issue is moronic. Who cares if people can decompile your game and see its source code? What are they going to do with it? Claim it's their own? How are they going to get away with that? Steal the ideas in the code? Don't flatter yourself.
|
|
|
Logged
|
|
|
|
Josh @ Dreamland
|
|
Reply #56 Posted on: March 08, 2010, 09:37:58 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
"So can pointers in C++. Does that mean that C++ can't be garbage collected?" "So there's no strings, surfaces, data structures, sounds or images that you could ever possibly delete?"
C++ could be garbage collected if I replaced all calls to malloc with my own. It is because GM integers are only incremented by one, and are completely ambiguous. Case-in-point: object0 == sprite0, sprite0 == sound0, sound0 == path0. The only unique IDs are for instances, and, well, that's the only thing I come close to garbage collecting. People often shortcut and reference some sprites by integer instead of full identifier. I have also seen choose(spritex,spritey...), and with that, of course, random() used in the mix. There's no garbage collecting resources that are identified like that. My best bet is to assume they are in use until _destroy is called. Good garbage collectors work by tracking references rather than pointers, especially ambiguous ID's representing pointers in an array.
"I think I made myself fairly clear on the nature of the VM I was describing." Yes, reading that over, now that my expectations for a good reason to use such a VM are zero, I see what you are describing. I was just looking for something to set it off as a better idea than native code. Granted that being able to discover the architecture the program is on and run some specific optimizations for it at load time is nice. However, I don't see it as necessary for the extra work on the platforms for which I would/could include it.
"LLVM has its website to back itself up" I don't see a single statistic, though it is a nice site compared to others of its breed. They even invested in background textures.
"LLVM isn't much higher-level than normal assembly; it's just not machine-specific" Which makes it a fraction of the work to write a decompiler for. Though I suppose that can be dropped as a concern since they do optimize it some at compile/link time.
"Anyway, the whole decompilation and obfuscation issue is moronic. Who cares if people can decompile your game and see its source code? What are they going to do with it? Claim it's their own? How are they going to get away with that? Steal the ideas in the code? Don't flatter yourself." Everyone says that. I agree with most of it. Doesn't mean everyone will kiss ENIGMA's ass for using that same excuse. Some people just like feeling more secure.
Anyway, all this future talk. Clearly, the closest thing Clang has to what I need is its parser, assuming it can really tell me what can be used as a type, and verify if X is a member of Y with a decent complexity. I will add that to my list of considerations for if the one I wrote should ever fail to be enough. Until then, I don't need it, and other than that, the project is no use to me.
|
|
|
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
|
|
|
|
Josh @ Dreamland
|
|
Reply #58 Posted on: March 08, 2010, 10:26:55 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
But the bytes coding for those may vary. Now we know it doesn't; to write a decompiler for one is to have one secured for them all. There is only one. And by stats, I meant benchmarks of LLVM-JIT code versus native on different platforms and architectures. Not just a list of over-elaborated features.
Also, I don't want to do a check to see if the sprite or background has been loaded every time you draw it. The less such checks, the better. If GM offers such (which I think it may), it will be replaced with a more hands-on system, driven by functions or user-defined events.
|
|
« Last Edit: March 08, 2010, 10:29:10 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
|
|
|
|
|