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.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 »
2311
Announcements / Re: Pride
« on: March 08, 2010, 11:01:08 pm »
I understood it to be machine-independent code that is optimized and loaded native, JIT.
I assume it should be at least somewhat faster than code compiled for a particular architecture but not optimized for a particular system. I'd like to know by how much on average it's faster, to see if it at all justifies its use.
Memory is cheap. I can't know which objects will use a certain resource, everything's an integer. Doing so by sprites I know will be used is begging for trouble.
Assuming Haskell and C's performance boosts are the same, that's not a bad gain, but I'm not sure it's worth the effort.
I assume it should be at least somewhat faster than code compiled for a particular architecture but not optimized for a particular system. I'd like to know by how much on average it's faster, to see if it at all justifies its use.
Memory is cheap. I can't know which objects will use a certain resource, everything's an integer. Doing so by sprites I know will be used is begging for trouble.
Assuming Haskell and C's performance boosts are the same, that's not a bad gain, but I'm not sure it's worth the effort.
2312
Announcements / Re: Pride
« on: March 08, 2010, 10:26:55 pm »
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.
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.
2313
Announcements / Re: Pride
« on: March 08, 2010, 09:37:58 pm »
"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.
"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.
2314
Announcements / Re: Pride
« on: March 08, 2010, 05:38:54 pm »Quote
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.
Quote
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.
Quote
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++.
Quote
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.
Quote
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.
Quote
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.
2315
Announcements / Re: Quick Poll
« on: March 08, 2010, 02:27:17 pm »
Game_boy:
Correct. This doesn't even affect anyone who does use the resource; only those who want to declare structures in individual events, which is a hassle anyway.
Luis:
Yes. Didn't want to complicate things with a second new vocabulary word that's essentially synonymous to the first.
The 11th plague of Egypt:
The problem with that is figuring out when you're ready to remove the training wheels and stop hearing that particular error. It'd confuse people when pressing the syntax check button revealed a warning. What about the rest of the document? Is this the only problem? Perhaps clicking the syntax button again would suppress that warning... I really don't have an intuitive system planned out for it, though.
Correct. This doesn't even affect anyone who does use the resource; only those who want to declare structures in individual events, which is a hassle anyway.
Luis:
Yes. Didn't want to complicate things with a second new vocabulary word that's essentially synonymous to the first.
The 11th plague of Egypt:
The problem with that is figuring out when you're ready to remove the training wheels and stop hearing that particular error. It'd confuse people when pressing the syntax check button revealed a warning. What about the rest of the document? Is this the only problem? Perhaps clicking the syntax button again would suppress that warning... I really don't have an intuitive system planned out for it, though.
2316
Announcements / Re: Prophase
« on: March 08, 2010, 02:20:19 pm »
Yes, was being funny. Linux port was written with the thought "maybe this'll finally bring more than 20 games to the OS...." But then it turned out I hate Windows in comparison.
Regardless, Windows is still the first priority (though not so much first to justify me stopping to write a DirectX port right away).
Regardless, Windows is still the first priority (though not so much first to justify me stopping to write a DirectX port right away).
2317
Announcements / Re: Pride
« on: March 08, 2010, 02:05:45 pm »
"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.
"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.
2318
Announcements / Quick Poll
« on: March 08, 2010, 08:58:12 am »
As the more conscious of you realize by now, ENIGMA allows for C++-style declarations to be used in your projects. As you all should know, GM is very loose about its semicolons.
I asked Ism to create a script-like resource that will allow users to define their own structures and functions for use in the rest of the project. However, it is also legal in C to define structs in your code, and I don't want to alienate that as a feature.
For those who are new to C, structs are a simple data structure that lays out how chunks of memory look. They allow you to keep track of multiple things, like a named array. Instead of having, for example, a 2-Dimensional array to store x-y pairs, you could create a structure like the one featured below.
Veterans know that R3 allowed for cpp {} to handle such things. The cpp statement created a block of un-parsed code to allow users access to C++ without the parser having to check it for error, creating a workaround as well as a decent expandability. That block is no longer necessary for its old purpose; now we can choose to have it serve a new one along with it.
Say that in a create event, you want to create a structure with an X and Y pair. I don't know why you'd want to do this since you may as well just keep two arrays, but for the sake of example pretend you do.
Being used to the GM way, you say this:
That's a problem.
The parser would naively make your code look like this:
The above code looks correct, but in actuality, it redeclares direction as an xy structure in that piece of code. This is because the proper form for structure declaration in C is this:
All this considered, we are left with three options.
Code as entered for option 3:
Please read over carefully and make your choice; feel free to ask questions or justify your answer. You can change your vote (assuming SMF works like the checkbox implies it will), so don't be afraid to just place one.
Note that the script-like resource mentioned is pure C++, and so expects perfect grammar. This does not apply to it.
I also ask that you don't just randomly pick one, though picking one because your retarded friend told you to do so is fine. I figure cheating on polls is a good thing; it reflects who cares most.
I asked Ism to create a script-like resource that will allow users to define their own structures and functions for use in the rest of the project. However, it is also legal in C to define structs in your code, and I don't want to alienate that as a feature.
For those who are new to C, structs are a simple data structure that lays out how chunks of memory look. They allow you to keep track of multiple things, like a named array. Instead of having, for example, a 2-Dimensional array to store x-y pairs, you could create a structure like the one featured below.
Veterans know that R3 allowed for cpp {} to handle such things. The cpp statement created a block of un-parsed code to allow users access to C++ without the parser having to check it for error, creating a workaround as well as a decent expandability. That block is no longer necessary for its old purpose; now we can choose to have it serve a new one along with it.
Say that in a create event, you want to create a structure with an X and Y pair. I don't know why you'd want to do this since you may as well just keep two arrays, but for the sake of example pretend you do.
Being used to the GM way, you say this:
Code: [Select]
struct xy {
var x;
var y;
}
direction = 0
speed = 0
That's a problem.
The parser would naively make your code look like this:
Code: [Select]
struct xy {
var x;
var y;
}
direction = 0;
speed = 0;
The above code looks correct, but in actuality, it redeclares direction as an xy structure in that piece of code. This is because the proper form for structure declaration in C is this:
Code: [Select]
struct name { int members; } instance;
I'm sure you can all imagine why that isn't good... For those who can't, it means that for the rest of that code, the word "direction" will NOT refer to the builtin variable direction. It will instead refer to an instance of your xy structure, which behaves like an instance in GML. You could say direction.x = 0; direction.y = 1;, and it would be valid. To fix this, preventing the instantiation of immediate varnames (in this case, direction), you would simply add a semicolon following the closing brace.Code: [Select]
struct xy {
var x;
var y;
};
direction = 0;
speed = 0;
The above piece behaves as one would expect.All this considered, we are left with three options.
- We can leave it up to the user to remember that semicolon.
I still forget that semicolon at times. It is one of the most common mistakes in C/C++.
It won't error, because direction is declared elsewhere. You'll have to figure it out yourself. - We can disallow immediate instantiation.
This means that code will be treated as if the {} had been followed by a semicolon immediately, and that you cannot declare a new structure and instantiate it with one semicolon. - We can use cpp %{ %} for such declarations, erroring if the struct isn't in one.
This is like the first option, but it will remind users to watch what they're doing. It's also pretty inconvenient, in my opinion. Whenever you want a new structure, you will have to input code similar to that below. I did like this suggestion when Miky made it, but then I couldn't make up my mind.
Code as entered for option 3:
Code: [Select]
cpp %{
struct a {
int b;
} c;
%}
Creates a structure called a, with a member called b, and instantiates it in a variable called c. You can say c.b = 0, for example.Please read over carefully and make your choice; feel free to ask questions or justify your answer. You can change your vote (assuming SMF works like the checkbox implies it will), so don't be afraid to just place one.
Note that the script-like resource mentioned is pure C++, and so expects perfect grammar. This does not apply to it.
I also ask that you don't just randomly pick one, though picking one because your retarded friend told you to do so is fine. I figure cheating on polls is a good thing; it reflects who cares most.
2319
Announcements / Re: Prophase
« on: March 08, 2010, 07:22:31 am »
Why am I making this work for Windows, again? >_>
Oh right, GM userbase. *begrudgingly gets back to work*
Oh right, GM userbase. *begrudgingly gets back to work*
2320
Announcements / Re: Pride
« on: March 07, 2010, 09:52:38 pm »
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.
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.
2321
Announcements / Re: Pride
« on: March 07, 2010, 08:43:12 pm »
This is C++. There is no GC. There will not be one.
You would evidently have me include a VM for all concerned architectures (And believe me, there are multiple) in with the executable...? Or rather, the platform independent byte code? That would be ginormous. It'd be a 20MB job just like Yoyo's Mac runner.
And it's irrelevant if you wouldn't better GML by mixing in some C++, because I would. Serp would just as soon leave it as GML. And again, since presently we are the only two people doing anything on the project, it doesn't matter what anyone else would do.
If you are interested in how this project turns out, then by all means feel free to watch. Stop bombarding me with facts about languages you think are better than the one months of work have gone into using. Or have someone else fork it. I'm not just dropping all this in favor of a highly idealized VM to magically solve all our problems.
I'd have shown a lot more interest in your system if I thought it had a chance of doing what mine does, or performing as fast. It never would have made it through C++.
Your ideals on the subject seem to be just that. If you could find another C++ parser project to expediently obtain all the class and function definitions for users to take advantage of, that'd be a great start. I don't trust it, maybe you do. Seems all the projects you pointed out parse their own dialect and their own headers rather than that and those of the GCC. So, why do I want GCC's? Because it compiles for every platform I intend to target. Every. One of them.
There isn't a language nor a C++ compiler that you will pick out that can do all the GCC can. To be able to parse the same things as GCC ensures that it is always an option to include headers for the current system. It was my best option from the start, it still is.
Maybe you've noticed that I'm working from the broad to the specific, not vice-versa. Starting with GL rather than DirectX, and other such strategies where possible. If one day it becomes a decent consideration to write my own VM for ENIGMA, then maybe I will. I can't see that happening at this point; the project is young and a 20 MB RUNNER would only scare people away.
You would evidently have me include a VM for all concerned architectures (And believe me, there are multiple) in with the executable...? Or rather, the platform independent byte code? That would be ginormous. It'd be a 20MB job just like Yoyo's Mac runner.
And it's irrelevant if you wouldn't better GML by mixing in some C++, because I would. Serp would just as soon leave it as GML. And again, since presently we are the only two people doing anything on the project, it doesn't matter what anyone else would do.
If you are interested in how this project turns out, then by all means feel free to watch. Stop bombarding me with facts about languages you think are better than the one months of work have gone into using. Or have someone else fork it. I'm not just dropping all this in favor of a highly idealized VM to magically solve all our problems.
I'd have shown a lot more interest in your system if I thought it had a chance of doing what mine does, or performing as fast. It never would have made it through C++.
Your ideals on the subject seem to be just that. If you could find another C++ parser project to expediently obtain all the class and function definitions for users to take advantage of, that'd be a great start. I don't trust it, maybe you do. Seems all the projects you pointed out parse their own dialect and their own headers rather than that and those of the GCC. So, why do I want GCC's? Because it compiles for every platform I intend to target. Every. One of them.
There isn't a language nor a C++ compiler that you will pick out that can do all the GCC can. To be able to parse the same things as GCC ensures that it is always an option to include headers for the current system. It was my best option from the start, it still is.
Maybe you've noticed that I'm working from the broad to the specific, not vice-versa. Starting with GL rather than DirectX, and other such strategies where possible. If one day it becomes a decent consideration to write my own VM for ENIGMA, then maybe I will. I can't see that happening at this point; the project is young and a 20 MB RUNNER would only scare people away.
2322
Announcements / Re: Pride
« on: March 07, 2010, 04:35:56 pm »
I don't see how a "'small API'" won't cut it. ENIGMA's resources are stored in an array; giving a DLL read and write access to that array wouldn't take any more than an additional pointer.
That VM idea sounds great when you assume everyone has it installed. I like native code because it runs quickly, doesn't need touched at load time, and doesn't require large VM's that no one has installed. In advance: I don't care about `this awesome language by Google' or `by the Ubuntu team' that Construct was thinking about using because it's so fast, cross platform, and great.
Working from architecture to architecture is nice. It's also not going to happen. Cross-compilation has been invented to come close to the ideals of such.
The parser is only a "big mess" in your opinion. Dedicate some of the time you would spend finding a "decent method" to studying mine before you start criticizing it.
...
It seems the difference between you and me is only that of a few years: In the beginning of the project, I had no direction. I'd see a shiny thing and think WOW THIS WOULD BE GREAT IN ENIGMA! Then I'd see another one and think WOW THIS WOULD BE GREAT IN ENIGMA! Eventually I came to realize that not all of the things that WOULD BE GREAT IN ENIGMA, WOW! can be added; that I have to choose between different systems. I decided that some systems could be added alongside others to be used one at a time when appropriate, such as OpenGL and DirectX, or Win32 and XLib.
I also realized that the foundational language for this project was NOT such a system. And so I chose one. I chose the language that will work on Windows, Mac, and Linux, without it being anyone's fault by my own if it misbehaved, and that would then work on the most non-computer systems (consoles, mainly). That language happened to be C, though I later revised to C++ wanting to provide more to users than GML. C/C++ were my best bet for getting ENIGMA running on the most systems and performing the fastest.
Also in advance: Please spare us your spiel about how C# (or perhaps something similar you may have found) is a beautiful language that half-ass works on Linux as long as you use Mono, and that works on Windows if you're patient, and that works on XBox if you have plenty of time and money, and that works on the Wii if you are X company (look, we have a Barby game written in C# to prove it!). I also don't want to know how many wonderful functional languages people have managed to write a C++-based interpreter for on different consoles. I hate it when people start naming off ten different languages that collaboratively, if magically used all at once, match the ability of C++.
You can, however, feel free to gravitate back to how I should be writing an assembler for each of these architectures myself.
Score_:
They want to pretend that by writing a VM for it, everyone will magically have said VM installed so code will be smaller and cross platform (as one module) and all-around happier for everyone, the end.
That VM idea sounds great when you assume everyone has it installed. I like native code because it runs quickly, doesn't need touched at load time, and doesn't require large VM's that no one has installed. In advance: I don't care about `this awesome language by Google' or `by the Ubuntu team' that Construct was thinking about using because it's so fast, cross platform, and great.
Working from architecture to architecture is nice. It's also not going to happen. Cross-compilation has been invented to come close to the ideals of such.
The parser is only a "big mess" in your opinion. Dedicate some of the time you would spend finding a "decent method" to studying mine before you start criticizing it.
...
It seems the difference between you and me is only that of a few years: In the beginning of the project, I had no direction. I'd see a shiny thing and think WOW THIS WOULD BE GREAT IN ENIGMA! Then I'd see another one and think WOW THIS WOULD BE GREAT IN ENIGMA! Eventually I came to realize that not all of the things that WOULD BE GREAT IN ENIGMA, WOW! can be added; that I have to choose between different systems. I decided that some systems could be added alongside others to be used one at a time when appropriate, such as OpenGL and DirectX, or Win32 and XLib.
I also realized that the foundational language for this project was NOT such a system. And so I chose one. I chose the language that will work on Windows, Mac, and Linux, without it being anyone's fault by my own if it misbehaved, and that would then work on the most non-computer systems (consoles, mainly). That language happened to be C, though I later revised to C++ wanting to provide more to users than GML. C/C++ were my best bet for getting ENIGMA running on the most systems and performing the fastest.
Also in advance: Please spare us your spiel about how C# (or perhaps something similar you may have found) is a beautiful language that half-ass works on Linux as long as you use Mono, and that works on Windows if you're patient, and that works on XBox if you have plenty of time and money, and that works on the Wii if you are X company (look, we have a Barby game written in C# to prove it!). I also don't want to know how many wonderful functional languages people have managed to write a C++-based interpreter for on different consoles. I hate it when people start naming off ten different languages that collaboratively, if magically used all at once, match the ability of C++.
You can, however, feel free to gravitate back to how I should be writing an assembler for each of these architectures myself.
Score_:
They want to pretend that by writing a VM for it, everyone will magically have said VM installed so code will be smaller and cross platform (as one module) and all-around happier for everyone, the end.
2323
Announcements / Re: Pride
« on: March 07, 2010, 12:07:37 am »
Never heard it used that way, only in reference to Lisp (or maybe it was Haskell).
That can easily be fixed with a small API.
I like things compiled natively.
As opposed to simply better?
I'm not about to debate something as subjective as which language is perfect. C++ is perfect for me.
That can easily be fixed with a small API.
I like things compiled natively.
As opposed to simply better?
I'm not about to debate something as subjective as which language is perfect. C++ is perfect for me.
2324
Tips, Tutorials, Examples / Re: lol streams
« on: March 06, 2010, 10:18:28 pm »
Yeah, compiler presently concatenates "" + "" automatically. For "" + anything else, I want it to cast first "" to variant.
2325
Announcements / Re: Pride
« on: March 06, 2010, 10:01:09 pm »
EDL is the union of GML and C++, not the intersection. If you consider either of those a real language, then I don't see how EDL isn't. EDL has GM's only type, and any type from the C++ STL, as well as any types users care to define. I have no idea how you are defining closures, other than as found in the functional paradigm, and as far as foreign functions go, we have LibFFI for GML's external_define, as well as the ability to just add to your project with other C++ libraries (whether designed specifically for ENIGMA or not). If that's not good enough, feel free to make a suggestion.
Way to extend objects? Easy. Way to make simpler structures? Good thing I just wrote a C++ parser; now you can make as many as you want. I'm having a new script resource added for that purpose. As for "A good compiler that goes directly to bytecode rather than through C++," what the fuck is that? Oh, that's right: A synthetic axiom with the soul purpose of ruling out ENIGMA, not even attached to a valid complaint, such as "not doing it yourself is slow." Perhaps that's because all such complaints could so easily be stricken down.
As for your next paragraph of bitching, it's been an intention of mine to tier ENIGMA to allow for removal of indexing. The first public hint at that was back when I announced that a new instance system I've developed will allow using pointer instead of ID to reference instances. The same could be done with sprites for anyone brave enough (and well-practiced enough) to enable it. I like the idea of C++ being an option; it's a beautiful language, especially when you can create a new project and have the annoying parts done for you. That's all C was ever missing. I would want the language to be a part of the project even if I could create so good an optimizer as that employed by the GCC...
As for your last statement, "If you don't want to hear our opinion, stop complaining about your problems."... this is my damn forum. I paid for it; legally I own it. This is the place where I present the problems of my project, for which this site was founded. Just because you hang around here doesn't mean you are entitled to a say in anything, or that your goals should in any way be reflected by the proceedings of this forum or the project of its topic. I am all for constructive criticism. Making the same suggestion repeatedly as I respectfully decline it isn't constructive, nor is telling me how much better I could have done had I listened to you, especially offering no proof other than child's-play proofs-of-concept and examples of full-fledged teams that have pulled similar stunts.
Way to extend objects? Easy. Way to make simpler structures? Good thing I just wrote a C++ parser; now you can make as many as you want. I'm having a new script resource added for that purpose. As for "A good compiler that goes directly to bytecode rather than through C++," what the fuck is that? Oh, that's right: A synthetic axiom with the soul purpose of ruling out ENIGMA, not even attached to a valid complaint, such as "not doing it yourself is slow." Perhaps that's because all such complaints could so easily be stricken down.
As for your next paragraph of bitching, it's been an intention of mine to tier ENIGMA to allow for removal of indexing. The first public hint at that was back when I announced that a new instance system I've developed will allow using pointer instead of ID to reference instances. The same could be done with sprites for anyone brave enough (and well-practiced enough) to enable it. I like the idea of C++ being an option; it's a beautiful language, especially when you can create a new project and have the annoying parts done for you. That's all C was ever missing. I would want the language to be a part of the project even if I could create so good an optimizer as that employed by the GCC...
As for your last statement, "If you don't want to hear our opinion, stop complaining about your problems."... this is my damn forum. I paid for it; legally I own it. This is the place where I present the problems of my project, for which this site was founded. Just because you hang around here doesn't mean you are entitled to a say in anything, or that your goals should in any way be reflected by the proceedings of this forum or the project of its topic. I am all for constructive criticism. Making the same suggestion repeatedly as I respectfully decline it isn't constructive, nor is telling me how much better I could have done had I listened to you, especially offering no proof other than child's-play proofs-of-concept and examples of full-fledged teams that have pulled similar stunts.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 »