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 »
2491
Announcements / Re: stdio.h
« on: November 15, 2009, 09:49:54 pm »
It may turn out that Ism will have to start saving ENIGMA files in the format we use to communicate between the two apps, depending on how many of EINGMA's non-GM features we can cram into GMK format.
As for arrays by reference, your question is inapplicable. Ha.
var::operator double() will return the first element.
var::operator =(const var&) will ideally "copy" the entire array by reference as std::string does. This will be O(1). Editing an element from that point until the freeing of the first var will be O(N) for the first time, then O(1) from the second edit on. (The array is only physically copied when necessary).
For example.
Current var doesn't do that, but minor modification will make that possible. This is planned, and easy to do.
Edit: Progress
As it happens, Linux stdio takes advantage of all those nice things I said still needed testing. So I've been working my ass off to get those to work. Also, apparently __const is a GCC keyword. Along with asm, __asm, and apparently __asm__, thanks score_under. v..v"
Furthermore, I'm tired, and still have psychoblah homework to do. Guess I'll do it tomorrow morning.
As for arrays by reference, your question is inapplicable. Ha.
var::operator double() will return the first element.
var::operator =(const var&) will ideally "copy" the entire array by reference as std::string does. This will be O(1). Editing an element from that point until the freeing of the first var will be O(N) for the first time, then O(1) from the second edit on. (The array is only physically copied when necessary).
For example.
Code: [Select]
//script0:
var array;
//do some stuff to array
return array;
//Step event:
var a = script0();
a[1] = 10;
Everything in that code operates in O(1), constant time. Code: [Select]
var array;
//do stuff to array
var b = a; //copies reference to array, operates in O(1)
b = 1; //sets b[0] to 1, operates in O(N)
b[5] = 2; //Obvious what it does. operates in O(1)
var c = b; //operates in O(1) once more
if (c) //operates in O(1)
b[5] = 0; //operates in O(N)
b[3] = 2; //operates in O(1) if c[0] != 0, otherwise operates in O(N)
Hopefully that clears it up rather than confusing people.Current var doesn't do that, but minor modification will make that possible. This is planned, and easy to do.
Edit: Progress
As it happens, Linux stdio takes advantage of all those nice things I said still needed testing. So I've been working my ass off to get those to work. Also, apparently __const is a GCC keyword. Along with asm, __asm, and apparently __asm__, thanks score_under. v..v"
Furthermore, I'm tired, and still have psychoblah homework to do. Guess I'll do it tomorrow morning.
2492
Announcements / Re: stdio.h
« on: November 15, 2009, 11:11:16 am »
I suppose you could consider it peripheral. It has to be done at some point, however. It probably won't help GM conversion directly, but indirectly it will be able to parse the headers itself. What that means is that it can enable selection of which headers to include for later.
Basically, it brings the system closer to C++. Var is no longer just a type, it's a structure. And that structure has a method for casting to int, which can be used to identify an instance. It makes for a more intelligent parse that will make life easier down the road.
That being the case, although it doesn't directly help pure-GM games, it's not something I want to put off.
Basically, it brings the system closer to C++. Var is no longer just a type, it's a structure. And that structure has a method for casting to int, which can be used to identify an instance. It makes for a more intelligent parse that will make life easier down the road.
That being the case, although it doesn't directly help pure-GM games, it's not something I want to put off.
2493
Announcements / Re: stdio.h
« on: November 12, 2009, 05:45:55 pm »
That question is actually pretty vague, considering how ENIGMA works. I am 90% positive GCC supports them, though I've never used one myself. I was considering an implementation of my own format for them to make syntax checking faster, but really, I'm not sure if there's a point. Ideally ENIGMA would be loaded as a DLL, and could do a lot of precompiling at start, which would save time later at the cost of startup time. However, it's really not that much time anyway... parsing those headers takes significantly less time than actually compiling them, obviously.
So, assuming you are talking about my parser, I might implement my own precompilation, but probably not right away, and almost definitely not GCC's. (Being able to work with GCC's output would void the point of parsing this myself.)
As for using precompiled headers in GCC to speed up compile time, that was something I intended to look into. I have no plan for it yet.
So, assuming you are talking about my parser, I might implement my own precompilation, but probably not right away, and almost definitely not GCC's. (Being able to work with GCC's output would void the point of parsing this myself.)
As for using precompiled headers in GCC to speed up compile time, that was something I intended to look into. I have no plan for it yet.
2494
Announcements / stdio.h
« on: November 12, 2009, 10:37:36 am »
Hello, all.
I'm happy to say stdio.h parses correctly, which means it's all uphill from here. (That saying makes no sense. Isn't going up hill more difficult than going down?) Okay, how about, it's smooth sailing from here.
Now, note that stdio is by far not the most difficult header to parse. Overall, it probably only tests 70% of what needs testing. The C++ headers will present plenty of challenge, as scopes will turn into my worst enemies. However, having stdio compile means that I can rely on some very basic things working as I tackle the more complicated problems. I can't really think of an analogy for what that means.
I'm very confident that quite soon, map<var,var> will be ENIGMA-parser-friendly.
Anyway, I'm going to move on to other C headers first, as there are some aspects of C that I've not yet focused on. These include the following, for those who are literate in the language:
...Actually, that's it. Everything else should follow once those are done. Then we move on to templates (mostly implemented), class (needs to be integrated into the piece of code that handles struct), scope operator (see below) and tacos.
Scope operator (from bits/stl_tree.h):
In honesty, that was just to scare people. Like I told that one guy that none of you have ever heard of, that line doesn't look so scary when read character by character at millions of chars per second.
End.
I'm happy to say stdio.h parses correctly, which means it's all uphill from here. (That saying makes no sense. Isn't going up hill more difficult than going down?) Okay, how about, it's smooth sailing from here.
Now, note that stdio is by far not the most difficult header to parse. Overall, it probably only tests 70% of what needs testing. The C++ headers will present plenty of challenge, as scopes will turn into my worst enemies. However, having stdio compile means that I can rely on some very basic things working as I tackle the more complicated problems. I can't really think of an analogy for what that means.
I'm very confident that quite soon, map<var,var> will be ENIGMA-parser-friendly.
Anyway, I'm going to move on to other C headers first, as there are some aspects of C that I've not yet focused on. These include the following, for those who are literate in the language:
Code: [Select]
#define concat(x,y) x##y
This appears in many headers stdio includes. It's a wonder stdio actually works, unless I've implemented it and forgotten, which is a distinct possibility.Code: [Select]
int (*blah)(int,int)[];
Not sure how it will handle the parentheses around blah, or no identifier being named after int. It will probably bitch about both, so I'll run some isolated tests on that before I parse anything else. Do note that the system was designed with those in mind....Actually, that's it. Everything else should follow once those are done. Then we move on to templates (mostly implemented), class (needs to be integrated into the piece of code that handles struct), scope operator (see below) and tacos.
Scope operator (from bits/stl_tree.h):
Code: [Select]
pair<typename _Rb_tree<_Key,_Val,_KeyOfValue,_Compare,_Alloc>::iterator,bool>
In honesty, that was just to scare people. Like I told that one guy that none of you have ever heard of, that line doesn't look so scary when read character by character at millions of chars per second.
End.
2495
General ENIGMA / Re: Hardware Acceleration
« on: November 10, 2009, 08:37:35 am »
I was originally. Now my idea is to use first my NVidia to get everything working nice, and then my ass-sore Intel chip that's never heard of GL to get it just working.
2496
General ENIGMA / Re: Hardware Acceleration
« on: November 08, 2009, 09:42:47 pm »
Except implementing those for general purpose use will be a bitch. Try to run a valve game on the typical GM user's computer, I dare you. And hell, Valve's games are DX, which at least guarantees SOMETHING. Older users can tell you, surfaces errored for half the people that downloaded them.
Don't worry though, with the right extensions, they'll run great on *decent* cards, and they'll at least work on the rest.
Don't worry though, with the right extensions, they'll run great on *decent* cards, and they'll at least work on the rest.
2497
Announcements / free()
« on: November 02, 2009, 09:14:04 pm »
Today I had to turn in Paper 3 for English 101. It was a 4-5 page requirement. I also had to turn in a 10-12 page essay on a self-help book for psychology. In both cases, I barely scraped the minimum requirement. I just hope I manage a good grade for them. Truthfully, I did the entire psych essay yesterday. All ten pages, including reading the book. THAT is an accomplishment. Unsurprisingly I am ending the venture as a slightly more religious person than when I began.
It is a nice feeling, to move that self help book and the accompanying essay to ~/Hell. I won't miss it.
Progress:
Um. I can't remember. My brain is full of psychology and English fluff. Moment... Ah, yes. __asm. Totally forgot.
That particular piece of code threw a parse error. After some WUTs, I fixed the problem. That's when I took a look at my psychology essay requirement and realized it was 10 pages. So I will be continuing now...
Also, we seem to be having some server trouble today. Don't worry, they're on it.
It is a nice feeling, to move that self help book and the accompanying essay to ~/Hell. I won't miss it.
Progress:
Um. I can't remember. My brain is full of psychology and English fluff. Moment... Ah, yes. __asm. Totally forgot.
Code: [Select]
int returns_one() __asm(":mov $1, %eax");
That particular piece of code threw a parse error. After some WUTs, I fixed the problem. That's when I took a look at my psychology essay requirement and realized it was 10 pages. So I will be continuing now...
Also, we seem to be having some server trouble today. Don't worry, they're on it.
2498
Announcements / Re: Progress
« on: November 02, 2009, 09:07:57 pm »
Yes, I do remember you. You were the one that helped answer questions on that topic I since stopped supervising. Wow, that was a long time ago.
I hope at some point to implement a system for updating variables that comes across as easily as that library did.
And yes, waiting for R4 would be a good idea, I believe.
I hope at some point to implement a system for updating variables that comes across as easily as that library did.
And yes, waiting for R4 would be a good idea, I believe.
2499
Announcements / Re: Progress
« on: October 30, 2009, 05:36:48 am »
Mmm, to run with execute_string(), assuming I ever feel like implementing it?
Or maybe they'll include GCC with their game like ENIGMA does, who knows?
Or maybe they'll include GCC with their game like ENIGMA does, who knows?
2500
Announcements / Re: Progress
« on: October 29, 2009, 07:33:38 pm »
;_________; ?
And yes, but that's true for static linking as well. Assuming that's an easy option with Scintilla. Can't really think why a game would want a Scintilla interface...
And yes, but that's true for static linking as well. Assuming that's an easy option with Scintilla. Can't really think why a game would want a Scintilla interface...
2501
Announcements / Re: Progress
« on: October 29, 2009, 02:30:58 pm »
Funny how both you named are no longer under development, last I checked.
2502
Announcements / Re: Progress
« on: October 29, 2009, 07:30:47 am »
Rusky--
You're comparing the size of an OS to the size of a game. How the hell often do you need to update a GM sized game?
There's no doubt DLLs are good in other cases. It's why most people are content to use SDL's ten DLLs instead of statically linking. But, ENIGMA is designed to be all-in-one, like GM. (Although GM does include a DLL in its actual runner, you can't see it, so it looks less messy).
Which reminds me, you say static linking is ugly... Static linking produces one standalone executable. I always liked my games to be standalone; means I can just drag one item over without fear of missing a DLL. Dave used to send me projects of his in all sorts of different libraries. First SDL, then Ogre... There were others I can't remember. Each time, I'd need him to send five different DLLs until it worked. He'd send two he could remember at a time, but it's still not very convenient.
Ideally, yes, it's good to be able to update large projects without having to redownload all the compiled code. A whole damn operating system is a great example of that, as I can scarcely think of one operating without it.
They are also useful in extensibility, such as Pidgin's plug-ins.
How many GM games honestly require DLLs for that purpose? GM would not make it that hard to do, actually, but I've never seen an instance where that was even implemented, much less required. Not to mention, one in every two hundred million people on the GMC knows any DLL-ready language. So having a well-used plugin system is unlikely.
At its prime, in a community full even moderately capable C++ programmers working on things other than games, are DLLs useful? Oh, certainly. In a community full of developers who rival companies like Valve (who externalize everything), are DLLs useful? Yes. On a forum whose immediate intended population has twenty people that know C++ and are willing to contribute code to everyone that does not, are DLLs all that useful? No more than static linking.
Luis--
Those who develop specifically for ENIGMA can bear that in mind for later. For now, all GM DLLs can be assumed to be closed source and of course are not static, which is basically the only reason external_define() exists. A lot of the better GM DLLs are open source anyway, if only poorly so. Like 39Dll. Source is included, no license.
You're comparing the size of an OS to the size of a game. How the hell often do you need to update a GM sized game?
There's no doubt DLLs are good in other cases. It's why most people are content to use SDL's ten DLLs instead of statically linking. But, ENIGMA is designed to be all-in-one, like GM. (Although GM does include a DLL in its actual runner, you can't see it, so it looks less messy).
Which reminds me, you say static linking is ugly... Static linking produces one standalone executable. I always liked my games to be standalone; means I can just drag one item over without fear of missing a DLL. Dave used to send me projects of his in all sorts of different libraries. First SDL, then Ogre... There were others I can't remember. Each time, I'd need him to send five different DLLs until it worked. He'd send two he could remember at a time, but it's still not very convenient.
Ideally, yes, it's good to be able to update large projects without having to redownload all the compiled code. A whole damn operating system is a great example of that, as I can scarcely think of one operating without it.
They are also useful in extensibility, such as Pidgin's plug-ins.
How many GM games honestly require DLLs for that purpose? GM would not make it that hard to do, actually, but I've never seen an instance where that was even implemented, much less required. Not to mention, one in every two hundred million people on the GMC knows any DLL-ready language. So having a well-used plugin system is unlikely.
At its prime, in a community full even moderately capable C++ programmers working on things other than games, are DLLs useful? Oh, certainly. In a community full of developers who rival companies like Valve (who externalize everything), are DLLs useful? Yes. On a forum whose immediate intended population has twenty people that know C++ and are willing to contribute code to everyone that does not, are DLLs all that useful? No more than static linking.
Luis--
Those who develop specifically for ENIGMA can bear that in mind for later. For now, all GM DLLs can be assumed to be closed source and of course are not static, which is basically the only reason external_define() exists. A lot of the better GM DLLs are open source anyway, if only poorly so. Like 39Dll. Source is included, no license.
2503
Announcements / Re: Progress
« on: October 28, 2009, 04:13:45 pm »
NONSENSE! MAHAHAHAHHAHAHAHAHAHAHA *filinaeny goes off daep edn*
2504
Announcements / Re: Progress
« on: October 27, 2009, 07:29:58 pm »
Code isn't supposed to be all that big. If you want small updates, make your resources external, not your code.
2505
Announcements / Re: Progress
« on: October 27, 2009, 04:22:31 pm »
What he meant by that was, DLLs are a practical way to use code you don't understand that runs fast in GM. In ENIGMA, the only point to having them is because people are set in their 39Dll-loving ways.
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 »