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 »
2641
Issues Help Desk / Re: Lol
« on: June 09, 2009, 02:46:45 pm »
It's also for writing entire operating systems. And Dave's right; C will leave you with some nasty habits in C++.
2642
Announcements / Re: Compatibility Issues
« on: May 05, 2009, 02:18:40 pm »
Sprintf(), all of the C++ world hates you for no reason at all. Go away.
Also, I'm not dumping useful Windows functions just because Linux and Mac don't have something just like it. That's what SDL did; it's a wonder SDL even creates a window for you since it provides no interface to manipulate it. <_<
Also, I'm not dumping useful Windows functions just because Linux and Mac don't have something just like it. That's what SDL did; it's a wonder SDL even creates a window for you since it provides no interface to manipulate it. <_<
2643
Announcements / Re: Compatibility Issues
« on: May 04, 2009, 05:14:56 am »
Game_boy--
Not for ENIGMA, just in general to see what my options are. There aren't any ENIGMA functions that depend on it yet.
I don't want to set a release date, but I'm hoping a month, maybe two. It's a lot of time, but I want all the bugs out, and I want the system to be at its best and most solid. With all the other releases, I've left room for improvement. With this one, I'm trying to leave only room for additions.
And yeah, I know it's been a while. Sometimes I forget how long a while, and then I remember, gee, the last release of ENIGMA still takes more than a few seconds to compile. But I'm pulling out all the stops.
Quadduc--
Hero for the day.
Not for ENIGMA, just in general to see what my options are. There aren't any ENIGMA functions that depend on it yet.
I don't want to set a release date, but I'm hoping a month, maybe two. It's a lot of time, but I want all the bugs out, and I want the system to be at its best and most solid. With all the other releases, I've left room for improvement. With this one, I'm trying to leave only room for additions.
And yeah, I know it's been a while. Sometimes I forget how long a while, and then I remember, gee, the last release of ENIGMA still takes more than a few seconds to compile. But I'm pulling out all the stops.
Quadduc--
Hero for the day.
2644
Announcements / Re: Compatibility Issues
« on: May 03, 2009, 09:46:10 am »
Every number is currently a double. Which is the problem; doubles are slow.
And yes to the MIME types. But I don't know where that data is stored. I've used GConf, for setting hot keys system wide, but I don't know where it keeps that info.
Ism was looking into ext/ just yesterday, and turned out to not have permission to write to it except when she was root. So that's no good either.
And again, I'm sort of opposed to the idea of keeping the registry file in the main directory. Ism suggested a hidden folder on the user's home directory. Since GM uses registry_set_root for some BIZARRE reason, (it's almost like GM was meant to be cross platform), I could easily rig it to change locations of where I'm writing. But I don't think I'd have permission to put anything on the root of the drive, either. If I did, though, registry_set_root could simply change the directory I write the registry info in.
Also, Retro, I don't want to make a separate release for each group of Windows platforms. I'll stick with the idea of allowing it to be recompiled for older systems. LGM can probably make calls to ENIGMA to rebuild parts of itself for different platforms, since GCC will always be available.
And yes to the MIME types. But I don't know where that data is stored. I've used GConf, for setting hot keys system wide, but I don't know where it keeps that info.
Ism was looking into ext/ just yesterday, and turned out to not have permission to write to it except when she was root. So that's no good either.
And again, I'm sort of opposed to the idea of keeping the registry file in the main directory. Ism suggested a hidden folder on the user's home directory. Since GM uses registry_set_root for some BIZARRE reason, (it's almost like GM was meant to be cross platform), I could easily rig it to change locations of where I'm writing. But I don't think I'd have permission to put anything on the root of the drive, either. If I did, though, registry_set_root could simply change the directory I write the registry info in.
Also, Retro, I don't want to make a separate release for each group of Windows platforms. I'll stick with the idea of allowing it to be recompiled for older systems. LGM can probably make calls to ENIGMA to rebuild parts of itself for different platforms, since GCC will always be available.
2645
Announcements / Re: Compatibility Issues
« on: May 02, 2009, 02:56:21 pm »
I'd have to agree with that.
For Linux and Mac, I was thinking about writing it to the var folder, if permission allows, because I'd really rather not store things like that in the same folder as the game, for obvious reasons. Not so much for security, considering the registry really isn't as hidden as GM users would like to believe. In fact, I don't think security of it would really be a problem: If you're on Linux, chances are you already know what Windows' system registry is anyway, so putting it in a nearby file wouldn't make much of a difference in that respect. Here, the real beauty of the registry (or writing to var/ in Linux' case), would be that the game could still access the data, even if it the game's file was moved without the registry file.
Thinking about it, Windows' registry is also used for associating file types. To be honest, I'm not sure how that works on Linux, so that'd require some research... It'd probably never be compatible anyway. But ENIGMA wasn't really intended to need to associate file types anyway, and if the need arises, I can always make a built-in function for that.
For Linux and Mac, I was thinking about writing it to the var folder, if permission allows, because I'd really rather not store things like that in the same folder as the game, for obvious reasons. Not so much for security, considering the registry really isn't as hidden as GM users would like to believe. In fact, I don't think security of it would really be a problem: If you're on Linux, chances are you already know what Windows' system registry is anyway, so putting it in a nearby file wouldn't make much of a difference in that respect. Here, the real beauty of the registry (or writing to var/ in Linux' case), would be that the game could still access the data, even if it the game's file was moved without the registry file.
Thinking about it, Windows' registry is also used for associating file types. To be honest, I'm not sure how that works on Linux, so that'd require some research... It'd probably never be compatible anyway. But ENIGMA wasn't really intended to need to associate file types anyway, and if the need arises, I can always make a built-in function for that.
2646
Announcements / Compatibility Issues
« on: May 02, 2009, 12:09:17 pm »
Questions that have been haunting me since day one, and I'm sick of dealing with them, so I'll present them to my user base.
Knowing this, do I have all the functions take double and string as parameters (a 100% waste of memory and at least 800% waste of speed), or do I alienate std::string as a return type?
Neither of those are very attractive choices. There is a middle option where I have the user decide whether or not they want to keep var as a type, and re-compile ENIGMA optionally to take scalar arguments. (Scalar meaning one type, in this case of the smallest needed size)
I will try again to get var to work with conflicting cast types, but std::string is the one that causes ambiguity. Even though I added an explicit cast function for it in var. (Meaning I told it exactly what to do to convert var to string, but it errored anyway.)
For the first three releases, I returned zero in all those functions, as int for max speed.
Why not do away with them? Some people like to add a function that needs called but returns nothing to a function that must be called after the first function, in order to call them in one statement. Like registry_set_root(3)+registry_read_real_ext("blah","blah")
That's an ugly, yet useful feature of the language. I was considering having function return ENIGMA_VOID, and the return statement at the end be return_void;. This would enable the user to choose whether or not to do this and recompile.
Should ENIGMA return error codes as WinApi does? For registry functions, this would also eliminate combining things like registry_set_root(3)+registry_read_real_ext("blah","blah"), though since registry_set_root will never fail and the latter returns nonzero normally, that's not exactly the best example here.
Maybe a function to check if the last calls succeeded?
The problem here is, do we stick with the old ones and risk being obsolete come Windows 7, or do we lose 95 and 98 compatibility and go with the new? Again, this can be fixed by compiling separate releases for each operating system, but that's not exactly attractive as an option.
There are plenty more conflicts, but these are just a few that are immediately bothering me.
If you haven't guessed, registry functions have been implemented.
College classes are nearly over; I have a huge take-home final exam to worry about this weekend, followed by 23 more days of high school. But then I'm done, and will actually have a decent amount of time to work. I hope.
- Var can't return int, string, double, and char*. It just can't; it leads to ambiguity out the back end to where your game won't compile.
Knowing this, do I have all the functions take double and string as parameters (a 100% waste of memory and at least 800% waste of speed), or do I alienate std::string as a return type?
Neither of those are very attractive choices. There is a middle option where I have the user decide whether or not they want to keep var as a type, and re-compile ENIGMA optionally to take scalar arguments. (Scalar meaning one type, in this case of the smallest needed size)
I will try again to get var to work with conflicting cast types, but std::string is the one that causes ambiguity. Even though I added an explicit cast function for it in var. (Meaning I told it exactly what to do to convert var to string, but it errored anyway.)
- Game Maker does not have functions that don't return anything. Even functions in GM that return nothing will actually behave as zero, and can be used in assignment and arithmetic. This isn't the case in C++.
For the first three releases, I returned zero in all those functions, as int for max speed.
Why not do away with them? Some people like to add a function that needs called but returns nothing to a function that must be called after the first function, in order to call them in one statement. Like registry_set_root(3)+registry_read_real_ext("blah","blah")
That's an ugly, yet useful feature of the language. I was considering having function return ENIGMA_VOID, and the return statement at the end be return_void;. This would enable the user to choose whether or not to do this and recompile.
- Game Maker does not return success or fail. Especially for functions like registry_write_string(). A lot of functions that are VERY prone to failure have unclear methods or no method at all of determining whether it worked.
Should ENIGMA return error codes as WinApi does? For registry functions, this would also eliminate combining things like registry_set_root(3)+registry_read_real_ext("blah","blah"), though since registry_set_root will never fail and the latter returns nonzero normally, that's not exactly the best example here.
Maybe a function to check if the last calls succeeded?
- WinApi has developed some since its first release in 1912. As such, we have a set of 16 bit functions that are preserved for compatibility with 95 and 98, but then more recent functions that are meant for 2000+ and may not work on really old Windows systems.
The problem here is, do we stick with the old ones and risk being obsolete come Windows 7, or do we lose 95 and 98 compatibility and go with the new? Again, this can be fixed by compiling separate releases for each operating system, but that's not exactly attractive as an option.
There are plenty more conflicts, but these are just a few that are immediately bothering me.
If you haven't guessed, registry functions have been implemented.
College classes are nearly over; I have a huge take-home final exam to worry about this weekend, followed by 23 more days of high school. But then I'm done, and will actually have a decent amount of time to work. I hope.
2647
Announcements / Re: Progress
« on: April 28, 2009, 03:11:38 pm »
Bleh, happens. Not sure why FireFox didn't form complete the password for me, and really not sure how I took five times to enter it correctly. (The last two tries I copied and pasted in the correct password... Even confirmed it with a2h to make sure.)
2648
Announcements / Re: Progress
« on: April 26, 2009, 06:55:31 am »
LibFFI handles DLLs, and lets you call them knowing pretty much nothing about what will be called at compile time. Means we didn't have to keep screwing around with asm.
Expression evaluator is the equivalent to that thing in GM's debug window that lets you watch variables and other small things. I made it so I can parse header files accurately: this way, users can include things from C++ and use them in their GM games. CFile parser just reads C headers and sources to get more functions for the syntax check.
For more C++ oriented people, this means you can have structures in your code along with the GML. If I do this well enough, it'll be able to parse all the standard template library headers, too.
That means you can do this:
map<string,int> a;
a["text string"] = 0;
...and the rest has a small learning curve I won't be posting here.
Expression evaluator is the equivalent to that thing in GM's debug window that lets you watch variables and other small things. I made it so I can parse header files accurately: this way, users can include things from C++ and use them in their GM games. CFile parser just reads C headers and sources to get more functions for the syntax check.
For more C++ oriented people, this means you can have structures in your code along with the GML. If I do this well enough, it'll be able to parse all the standard template library headers, too.
That means you can do this:
map<string,int> a;
a["text string"] = 0;
...and the rest has a small learning curve I won't be posting here.
2649
Announcements / Progress
« on: April 25, 2009, 08:58:16 pm »
Since people are beginning to freak out, I decided I'd best be more liberal with my updates.
...No, I will not get a Twitter. Ever. That would kill me on the inside.
Continuing.
DLL's are working. That doesn't mean they're finished, though; I have some stdcall testing to do now that I have cdecl working.
The endeavor looked something like this:
7:58 - Code is riddled with inline asm. Output is gobbly gook in the form of a message box.
8:?? - Clam mentions the name of LibFFI, which I'd heard of previously but then no one knew its name, so I stopped looking.
8:43 - Clam fixed me up with windows-ready LibFFI junk and a demo.
9:16 - Code is riddled with FFI garbage. Output is somewhat different gobbly gook in the form of a message box.
9:19 - Found the problem, fixed it. Working.
So now DLLs are working, at least with cdecl. Actually, cdecl was the one I wasn't sure how to do, but since it's working, stdcall should be a snap.
As for days previous, I now have a working expression evaluator. There are a couple things left to do so it can support all the types. (Right now it only does int, double, and char*). I was designing it for parsing #define, but it has so many other uses that I intend to make it full-featured. (#define is a C++ macro which I will need to parse in the CFile parser I mentioned earlier. It doesn't support floating points or type casts, but I've implemented those anyway.)
If this works well, I can eventually add a couple things to that evaluator and have an interpreter for debugging purposes. It'd probably help to be able to execute new code in debug mode. And don't worry; since enigma's compiled, it'd be next to impossible to access the debug window unless the game is in debug mode. The only way it would be possible is if a very skilled programmer converted the whole game back to assembly and hand coded the new debug interface, which would be such a massive task, there isn't a person on the planet with that sort of motivation. (They'd sooner just hack your game with a disassembler while it ran.)
And don't give my post that look; there's nothing you can do to make any game totally unhackable. I'm pretty sure everyone knows that and has come to terms with it. ENIGMA just isn't particularly easy to hack, unlike *some*.
The expression evaluator is a suprisingly small 900 lines so far. The CFile parser 630; It's about half done. Still have some keywords and er.... As a general "back to the drawing board" sort of thing, I'm adding support for basically every feature C++ offers. So you won't have to use the awful ds_ functions, you'll have something easily 30x more powerful at your disposal. Not to mention structs, so you have a convenient way of storing things. Oh, and I can't live without ++, so I'm adding that as an option (default to ON). I've also added the ternary operator (a?b():c()) into the expression parser.
All these changes and additions I'm making will mean some recoding in the syntax checker as well as the parser. Shouldn't be difficult; I'm not worried.
Or at least I wasn't, then I found out C++0x supports lambda, and I didn't know what to think. Either way, I'm sure it'll be fine.
Ism has been making things compile on Linux, which was met without much incident. So things are looking bright, overall.
Anyway, I'ma get back to work.
...No, I will not get a Twitter. Ever. That would kill me on the inside.
Continuing.
DLL's are working. That doesn't mean they're finished, though; I have some stdcall testing to do now that I have cdecl working.
The endeavor looked something like this:
7:58 - Code is riddled with inline asm. Output is gobbly gook in the form of a message box.
8:?? - Clam mentions the name of LibFFI, which I'd heard of previously but then no one knew its name, so I stopped looking.
8:43 - Clam fixed me up with windows-ready LibFFI junk and a demo.
9:16 - Code is riddled with FFI garbage. Output is somewhat different gobbly gook in the form of a message box.
9:19 - Found the problem, fixed it. Working.
So now DLLs are working, at least with cdecl. Actually, cdecl was the one I wasn't sure how to do, but since it's working, stdcall should be a snap.
As for days previous, I now have a working expression evaluator. There are a couple things left to do so it can support all the types. (Right now it only does int, double, and char*). I was designing it for parsing #define, but it has so many other uses that I intend to make it full-featured. (#define is a C++ macro which I will need to parse in the CFile parser I mentioned earlier. It doesn't support floating points or type casts, but I've implemented those anyway.)
If this works well, I can eventually add a couple things to that evaluator and have an interpreter for debugging purposes. It'd probably help to be able to execute new code in debug mode. And don't worry; since enigma's compiled, it'd be next to impossible to access the debug window unless the game is in debug mode. The only way it would be possible is if a very skilled programmer converted the whole game back to assembly and hand coded the new debug interface, which would be such a massive task, there isn't a person on the planet with that sort of motivation. (They'd sooner just hack your game with a disassembler while it ran.)
And don't give my post that look; there's nothing you can do to make any game totally unhackable. I'm pretty sure everyone knows that and has come to terms with it. ENIGMA just isn't particularly easy to hack, unlike *some*.
The expression evaluator is a suprisingly small 900 lines so far. The CFile parser 630; It's about half done. Still have some keywords and er.... As a general "back to the drawing board" sort of thing, I'm adding support for basically every feature C++ offers. So you won't have to use the awful ds_ functions, you'll have something easily 30x more powerful at your disposal. Not to mention structs, so you have a convenient way of storing things. Oh, and I can't live without ++, so I'm adding that as an option (default to ON). I've also added the ternary operator (a?b():c()) into the expression parser.
All these changes and additions I'm making will mean some recoding in the syntax checker as well as the parser. Shouldn't be difficult; I'm not worried.
Or at least I wasn't, then I found out C++0x supports lambda, and I didn't know what to think. Either way, I'm sure it'll be fine.
Ism has been making things compile on Linux, which was met without much incident. So things are looking bright, overall.
Anyway, I'ma get back to work.
2650
Tips, Tutorials, Examples / Re: How to Play Sounds
« on: April 21, 2009, 05:23:07 pm »
Now do it with OpenAL.
Oh right, that's my job.
Oh right, that's my job.
2651
General ENIGMA / Re: XOR DOES NOT WORK
« on: April 20, 2009, 03:24:10 pm »
Serpy, I'mma choke you. This is why we work with bools.
If I really must, I could have ENIGMA parse in a logical xor, but it shouldn't be a problem. Could always do !!x ^ !!y.
If I really must, I could have ENIGMA parse in a logical xor, but it shouldn't be a problem. Could always do !!x ^ !!y.
2653
Proposals / Re: I have only one comment
« on: April 20, 2009, 02:43:59 pm »
That's one way of doing it. Yknow, I feel like a change of pace from all this expression and CFile garbage. I think I'ma try my hand at GM DLLs right now...
2654
Announcements / Re: SVN
« on: April 03, 2009, 10:07:21 pm »
Yeah, but Microsoft made that. It's automatically terrible for real use.
...Come to think of it, Outlook Express is the only Microsoft program I use now. Aside from their entire operating system, of course, which I'm not going to complain about, because despite how awful some of its features are, have been, and are becoming, it's still the best. Kind of sad.
...Come to think of it, Outlook Express is the only Microsoft program I use now. Aside from their entire operating system, of course, which I'm not going to complain about, because despite how awful some of its features are, have been, and are becoming, it's still the best. Kind of sad.
2655
Proposals / Re: io_handle() and io_clear()
« on: April 02, 2009, 09:14:26 pm »
Mark threads all this stuff anyway. Create a code that draws thousands of lines towards the mouse, and move the mouse around. Half the lines will follow the mouse.
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 »