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 »
871
Issues Help Desk / Re: Hi there, I am new to ENIGMA
« on: January 19, 2013, 04:32:04 pm »
If it only does that for one particular game file, it's probably a problem parsing or building that particular file. It would be useful if you could try to narrow a test case down for us to fix. Otherwise, just post the game that breaks it and we'll have a look.
872
Issues Help Desk / Re: Hi there, I am new to ENIGMA
« on: January 18, 2013, 10:33:54 pm »
Are you certain it is finding the ENIGMA plugin? It's quite possible it isn't. Or, it's not finding JNA. Both are necessary.
The output from the terminal might help; open the ENIGMA directory in your terminal and run LGM manually with [snip]java -jar lgm16b4.jar[/snip]. Just copy the contents here on the forum or to pastebin so we can see what's going on.
If plugins/shared/jna.jar is missing, there's your problem. Also, if it failed to build compileEGMf.so, there's your problem. The latter shouldn't be your problem, though, since the menus would still appear in LGM.
If you are running the jar by double clicking it, it is quite possible LGM is being run from the wrong path, in which case running it from the console will fix your issue. That's a bug with your file manager's Java launcher; I'm not sure how to fix it.
The output from the terminal might help; open the ENIGMA directory in your terminal and run LGM manually with [snip]java -jar lgm16b4.jar[/snip]. Just copy the contents here on the forum or to pastebin so we can see what's going on.
If plugins/shared/jna.jar is missing, there's your problem. Also, if it failed to build compileEGMf.so, there's your problem. The latter shouldn't be your problem, though, since the menus would still appear in LGM.
If you are running the jar by double clicking it, it is quite possible LGM is being run from the wrong path, in which case running it from the console will fix your issue. That's a bug with your file manager's Java launcher; I'm not sure how to fix it.
873
Issues Help Desk / Re: A few quick questions
« on: January 18, 2013, 11:39:28 am »
Ew, it's a VS project.
Anyway, I'll check it out at some point.
Anyway, I'll check it out at some point.
874
Issues Help Desk / Re: A few quick questions
« on: January 17, 2013, 09:03:12 pm »
If you have the source code for GMOgre or the other 3D library you mentioned, you could plug them in directly with very little modification. Or one of us could on your behalf. I don't know if that source code is available.
875
Issues Help Desk / Re: A few quick questions
« on: January 16, 2013, 08:48:32 pm »
1) Not at the moment. Possibly not ever; chances are, the thing you were using it for in GM is no longer required in ENIGMA. Nine times in ten, that function is used to check if room instance creation code has set a variable already. In ENIGMA, the room creation codes are executed after the object creation codes.
2) You have the entirety of OpenGL at your disposal; I would encourage you to write an Ogre system to replace the main graphics system (in ENIGMA, the graphics system is interchangeable). If you don't want to, you can either include C++ sources in the ENIGMA engine directly, or modify and rebuild the DLL to hijack ENIGMA's classes instead. Stop in on the IRC on a quiet day and one of us would be happy to help you integrate such a system.
3) Those DLL's are what we'd call a "hack"; last I checked (this may have changed in the meantime), they work by dismissing GM's own DirectX context, replacing the context in the window with their own. That fundamentally will not work in ENIGMA since the windows are named differently. However, a modification should be relatively easy. Again, feel free to stop in on the IRC if you are interested in making such a modification.
If you have the source to those DLLs, I don't mind walking you through installing them in ENIGMA from here in this topic, either.
2) You have the entirety of OpenGL at your disposal; I would encourage you to write an Ogre system to replace the main graphics system (in ENIGMA, the graphics system is interchangeable). If you don't want to, you can either include C++ sources in the ENIGMA engine directly, or modify and rebuild the DLL to hijack ENIGMA's classes instead. Stop in on the IRC on a quiet day and one of us would be happy to help you integrate such a system.
3) Those DLL's are what we'd call a "hack"; last I checked (this may have changed in the meantime), they work by dismissing GM's own DirectX context, replacing the context in the window with their own. That fundamentally will not work in ENIGMA since the windows are named differently. However, a modification should be relatively easy. Again, feel free to stop in on the IRC if you are interested in making such a modification.
If you have the source to those DLLs, I don't mind walking you through installing them in ENIGMA from here in this topic, either.
876
Issues Help Desk / Re: Help please, I can't run 'make' in enigma
« on: January 15, 2013, 09:38:13 pm »
You can also change the location of MinGW in Compilers/Windows/gcc.ey Polyfuck or cheeseshit (can't remember which) decided that letting ENIGMA.exe generate that file was cumbersome, and that they should hard-code it instead. So that's what they did, thereby breaking it for users who have multiple drives.
Anyway, glad to hear you got it working. Cheers!
Anyway, glad to hear you got it working. Cheers!
877
Issues Help Desk / Re: Help please, I can't run 'make' in enigma
« on: January 15, 2013, 04:02:36 pm »
Could you pastebin the following, Salvakiya?
1) The contents of your console up to and including the error,
2) The output of the following in cmd: [snip]cd C:\MinGW\bin[/snip], [snip]dir[/snip]
3) The output of these in cmd: [snip]cd C:\MinGW\msys\1.0\bin[/snip], [snip]dir[/snip]
That should give us some insight into what you have installed. If you need to redirect that output to a file, just use [snip]> C:\Users\yourname\Desktop\file.txt[/snip] at the end of your command.
1) The contents of your console up to and including the error,
2) The output of the following in cmd: [snip]cd C:\MinGW\bin[/snip], [snip]dir[/snip]
3) The output of these in cmd: [snip]cd C:\MinGW\msys\1.0\bin[/snip], [snip]dir[/snip]
That should give us some insight into what you have installed. If you need to redirect that output to a file, just use [snip]> C:\Users\yourname\Desktop\file.txt[/snip] at the end of your command.
878
Announcements / Re: Trello
« on: January 14, 2013, 09:28:59 am »
The parser is done, or basically done. It's in the JDI branch with my other changes. The pretty-printer needs written, after those two to-do points are done.
All right, let me use my little remaining free-time to elaborate.
To-do point (1) on the Trello defines a class that can be used to create recursive AST operations from outside of the AST. To-do point number two helps in building the AST in more complicated EDL situations--the kind that aren't supported in the current parser, even.
Once to-do point one is complete, the pretty-printer will be written to simply implement the EDL_ASTOperator class, defining each method as necessary to print the AST out as valid C++. So AST_Node_Statement_for will print a for() statement (or hack something together with goto's if necessary), AST_Node_Statement_repeat will print a while() statement, etc.
Depending on what my schedule looks like today, I might actually get around to work on it. But I also wanted to do some maintenance on JDI, whose template handling is pretty weak.
All right, let me use my little remaining free-time to elaborate.
To-do point (1) on the Trello defines a class that can be used to create recursive AST operations from outside of the AST. To-do point number two helps in building the AST in more complicated EDL situations--the kind that aren't supported in the current parser, even.
Once to-do point one is complete, the pretty-printer will be written to simply implement the EDL_ASTOperator class, defining each method as necessary to print the AST out as valid C++. So AST_Node_Statement_for will print a for() statement (or hack something together with goto's if necessary), AST_Node_Statement_repeat will print a while() statement, etc.
Depending on what my schedule looks like today, I might actually get around to work on it. But I also wanted to do some maintenance on JDI, whose template handling is pretty weak.
879
Announcements / Re: Trello
« on: January 13, 2013, 11:03:43 pm »
Update:
You may or may not have guessed this, but I ran out of time and everything went south. I'm stuck using XNA, of all libraries, to make my game in this quarter, so development of an Ogre ass-end for ENIGMA is out of the question. One of my group members seems to know what he's doing, so this may be painless enough that I have enough time to work. I committed all of my changes to the compiler before I got engrossed in this semester's workload: if you are feeling brave, you might be able to finish it, or at least tackle the to-do points I have made for it on Trello.
If not, I will deal with it as soon as I can.
If you'll excuse me, in the meantime, I have stillborn game code to write.
You may or may not have guessed this, but I ran out of time and everything went south. I'm stuck using XNA, of all libraries, to make my game in this quarter, so development of an Ogre ass-end for ENIGMA is out of the question. One of my group members seems to know what he's doing, so this may be painless enough that I have enough time to work. I committed all of my changes to the compiler before I got engrossed in this semester's workload: if you are feeling brave, you might be able to finish it, or at least tackle the to-do points I have made for it on Trello.
If not, I will deal with it as soon as I can.
If you'll excuse me, in the meantime, I have stillborn game code to write.
880
Announcements / Re: Trello
« on: January 09, 2013, 07:29:16 pm »Maybe it's an OS-specific feature of the JTree? It's worth looking into more.
May very well be; it's working for me on Linux as well. I made a request on the card anyway, though. Space and enter do nothing, even on Linux.
Also, commenting is open to the public.
881
Announcements / Re: Trello
« on: January 09, 2013, 11:57:15 am »
Yeah, the Trello is for immediate-priority or very short-order stuff, otherwise I would have added my plans for the engine to it. Feature requests belong on the wiki or in the bug tracker if they're pretty small and pretty widely used. Plans for later belong on the Proposals board, or elsewhere on the forums.
882
Announcements / Trello
« on: January 09, 2013, 11:14:27 am »
We have a Trello, now.
ENIGMA's development interest has been booming lately—despite Ism and me not having very much time to devote to the project, in general. As such, I figured now's a good time to acquaint everyone with Trello. Dazappa has been putting his to-do points up, and I've been putting the simpler points of mine, If anyone is interested, they are welcome to take on any of them. Just let us know or move the card to "doing" yourself, so two people don't end up doing the same thing.
So. Developers, go ahead and have a look. If you're interested in participating, create a Trello account real quick and we'll add you. There is no qualification for "developer" other than "is interested in developing." Don't be shy.
The alternative is to live vicariously by telling us which card you want and which you have finished. Your choice.
ENIGMA's development interest has been booming lately—despite Ism and me not having very much time to devote to the project, in general. As such, I figured now's a good time to acquaint everyone with Trello. Dazappa has been putting his to-do points up, and I've been putting the simpler points of mine, If anyone is interested, they are welcome to take on any of them. Just let us know or move the card to "doing" yourself, so two people don't end up doing the same thing.
So. Developers, go ahead and have a look. If you're interested in participating, create a Trello account real quick and we'll add you. There is no qualification for "developer" other than "is interested in developing." Don't be shy.
The alternative is to live vicariously by telling us which card you want and which you have finished. Your choice.
883
Announcements / Re: Christmas Plans
« on: January 09, 2013, 12:49:33 am »
See the commit message from my last commit to get an idea of where I am.
I have done some more thinking, and determined that if we want to properly support overloading EDL functions regardless of host language (C and JavaScript being prime examples of languages which do not support overloading), we need a second pass after I'm aware of the types of everything in order to pick the correct overload.
Still haven't decided what to do with generics, for that matter, but that's another case.
Quote
Restructured and reorganized fuck-everything. Changed around fuck-everything.
My brain hurts from thinking about this shit for so long, and some of it still needs modification.
I have encapsulated most of everything correctly.
Remaining considerations:
- Events.res locals are still loaded by lang_CPP; they should be loaded universally.
- Where are events even parsed? I totally lost track. Being honest.
- We need a system for denoting where something was declared, for error reporting purposes.
- JDI handles some of its AST features funny
- It checks the left-hand of a function call and bails if it's not a function or cast
- It crams all the literal types into one AST node type
- It doesn't handle error reporting very well, and, to top it all off,
- It isn't fucking modular or extensible at all; nothing is abstract or virtual
- I have no idea if a second pass before pretty-print is actually required
- None of this outside the basic parser has been tested, and it's not blowing me away, either
- No amount of therapy will make this commit okay
I have done some more thinking, and determined that if we want to properly support overloading EDL functions regardless of host language (C and JavaScript being prime examples of languages which do not support overloading), we need a second pass after I'm aware of the types of everything in order to pick the correct overload.
Still haven't decided what to do with generics, for that matter, but that's another case.
884
Proposals / Re: Weird stuff that works in GM but fails in ENIGMA
« on: January 08, 2013, 06:26:24 pm »You would use .so files in Linux, right?Correct. FFI works with whatever's native; it's pretty extensive.
Honestly, I wouldn't bother.If I were to seriously implement an execute_string, it would be language sensitive, with the default being loose GML which I would format as JavaScript. It would serve 99.9% of all "legitimate" execute_string purposes, not to imply that there's a very legitimate purpose for it.
Funny, that's exactly what I was using them for in that old project. Once again, I wouldn't bother.That's all anyone uses them for, ever. For var and variant, it's as simple as assigning a bogus default type. The type will be fixed upon assignment. The only issue is packing them all into a map by reference. So variable_local_exists will only ever check if implicit vars exist, never declared types. Really not that hard, which is why I thought polygone could do it.
885
Proposals / Re: Weird stuff that works in GM but fails in ENIGMA
« on: January 08, 2013, 02:50:22 am »
Okay, sorry this reply took so long; it took insanely longer than I thought to the compiler building correctly again, but now it's mostly up with the new system and I can at least use it to prepare a response.
1. Bogus for statment.
Your [snip=edl]for (i = 0; i < stuff; i += 1;) {}[/snip] is actually the less bogus of the two for() issues. The weirder one is [snip=edl]for ({i = 0;} i < stuff; { i += 1; } ) {}[/snip]. The raw output for the two of these in the new parser is as follows:
It doesn't warn about the trailing semicolon, and in fact, includes it in the output because the dump function always puts a semicolon after statements. The C++ pretty-printer will not do that.
In fact, more work will need done in the pretty printer to support the latter for() loop, as it is basically unsalvageable. Code output will look like this instead:
The pretty-printer already needs to be able to support custom break and continue labels in order to support [snip=edl]continue 2[/snip].
2. Checking for inequality with <>.
When I wrote the old pretty-printer, I'd forgotten about <>. It pretty much indiscriminately puts spaces everywhere. Output for [snip=edl]if a <> b c = d[/snip] is as follows:
3. Giving a variable the name of a C++ data type or the name of a function.
Yes, its silence on the matter is an issue. The new parser accepts the code as well; this is its text-dump:
The AST tells another story:
I haven't decided if I want it to bitch out in a frenzy or let the pretty-printer salvage it (which, as you can see, is possible). In compatibility mode, the lexer will not honor "int" as a type, and the problem becomes moot, so really, it's in the air. I have a little more work to do to help scope resolution in the AST builder anyway, so we shall see.
4. Resources that would have the same name, if not for an asterisk one of them has.
Asterisks are invalid in resource names in GM and ENIGMA alike. GM doesn't care because it is in charge of the entire AST, anyway. ENIGMA is in charge of the AST only until it is converted to C++. While it was originally supposed to be LGM's job to verify resource name integrity, during my rewrite of practically everything in the compiler, I decided to handle this myself. A correct structure name is now generated for the objects up front, and objects themselves are referred to exclusively by ID during print.
5. Other stuff you probably know about already.
dll functions: These are implemented in Windows using libFFI. The same code can be ported to Linux with very little modification (only what is required to use the system FFI library instead of the one included in ENIGMA for Windows).
ini functions: I think someone started working on these, but probably got bored. No one uses INI anymore, so they've been given pretty low priority.
execute_string: This is implemented in EGMJS, and is liable to stay that way for quite some time. Otherwise, a substantial portion of the compiler must be included with the engine; it's just messy. ENIGMA is compiled, not interpreted.
variable_local_exists: In C++ (among other compiled languages), a variable can't conditionally exist. A key in a map can conditionally exist. I might implement this for var and variant, but the truth is, there is never a good reason to use this function. Its only valid use case in GM is to work around the stupid order in which Mark handled instance creation codes in rooms (room instance creation code was fired before instance creation code). In ENIGMA, as well as in later versions of GM, this has been corrected.
user_event: I have a bigger, better plan for these that doesn't involve Mark's shoddy, pathetically finite and otherwise very ugly and limited implementation of "User events". Think local scripts.
event_inherited: I wanted polygone to implement this as practice. Never happened. So I guess I'll handle it while I finish recoding the rest of the compiler.
sprite_create_from_screen: I thought someone had coded this by copying my implementation of screen_save. I guess that isn't the case, but for anyone whose interested, this can be written by copying my implementation of screen_save.
file_exists: I can't believe this isn't implemented. On Windows, this is [snip]CreateFile()[/snip]. On Linux, this is [snip]stat()[/snip].
I was already aware of most of this stuff, but I don't mind a refresher.
1. Bogus for statment.
Your [snip=edl]for (i = 0; i < stuff; i += 1;) {}[/snip] is actually the less bogus of the two for() issues. The weirder one is [snip=edl]for ({i = 0;} i < stuff; { i += 1; } ) {}[/snip]. The raw output for the two of these in the new parser is as follows:
Code: [Select]
Warning(Code,38,6): Blocks not actually allowed in `for' parameters
Warning(Code,38,26): Blocks not actually allowed in `for' parameters
Warning(Code,38,33): Semicolon should follow statement at this point
for ((i) = (0); (i) < (stuff); (i) += (1);)
{}
for ( (i) = (0); (i) < (stuff); (i) += (1);)
{}
It doesn't warn about the trailing semicolon, and in fact, includes it in the output because the dump function always puts a semicolon after statements. The C++ pretty-printer will not do that.
In fact, more work will need done in the pretty printer to support the latter for() loop, as it is basically unsalvageable. Code output will look like this instead:
Code: (cpp) [Select]
{
{i = 0;}
while (i < stuff) {
{}
continue_destination:
i += 1;
};
break_destination:
}
The pretty-printer already needs to be able to support custom break and continue labels in order to support [snip=edl]continue 2[/snip].
2. Checking for inequality with <>.
When I wrote the old pretty-printer, I'd forgotten about <>. It pretty much indiscriminately puts spaces everywhere. Output for [snip=edl]if a <> b c = d[/snip] is as follows:
Code: [Select]
if ((a) <> (b))
(c) = (d);
3. Giving a variable the name of a C++ data type or the name of a function.
Yes, its silence on the matter is an issue. The new parser accepts the code as well; this is its text-dump:
Code: [Select]
((alarm)[0]) = ((100) - ((random) (int)));
The AST tells another story:
I haven't decided if I want it to bitch out in a frenzy or let the pretty-printer salvage it (which, as you can see, is possible). In compatibility mode, the lexer will not honor "int" as a type, and the problem becomes moot, so really, it's in the air. I have a little more work to do to help scope resolution in the AST builder anyway, so we shall see.
4. Resources that would have the same name, if not for an asterisk one of them has.
Asterisks are invalid in resource names in GM and ENIGMA alike. GM doesn't care because it is in charge of the entire AST, anyway. ENIGMA is in charge of the AST only until it is converted to C++. While it was originally supposed to be LGM's job to verify resource name integrity, during my rewrite of practically everything in the compiler, I decided to handle this myself. A correct structure name is now generated for the objects up front, and objects themselves are referred to exclusively by ID during print.
5. Other stuff you probably know about already.
dll functions: These are implemented in Windows using libFFI. The same code can be ported to Linux with very little modification (only what is required to use the system FFI library instead of the one included in ENIGMA for Windows).
ini functions: I think someone started working on these, but probably got bored. No one uses INI anymore, so they've been given pretty low priority.
execute_string: This is implemented in EGMJS, and is liable to stay that way for quite some time. Otherwise, a substantial portion of the compiler must be included with the engine; it's just messy. ENIGMA is compiled, not interpreted.
variable_local_exists: In C++ (among other compiled languages), a variable can't conditionally exist. A key in a map can conditionally exist. I might implement this for var and variant, but the truth is, there is never a good reason to use this function. Its only valid use case in GM is to work around the stupid order in which Mark handled instance creation codes in rooms (room instance creation code was fired before instance creation code). In ENIGMA, as well as in later versions of GM, this has been corrected.
user_event: I have a bigger, better plan for these that doesn't involve Mark's shoddy, pathetically finite and otherwise very ugly and limited implementation of "User events". Think local scripts.
event_inherited: I wanted polygone to implement this as practice. Never happened. So I guess I'll handle it while I finish recoding the rest of the compiler.
sprite_create_from_screen: I thought someone had coded this by copying my implementation of screen_save. I guess that isn't the case, but for anyone whose interested, this can be written by copying my implementation of screen_save.
file_exists: I can't believe this isn't implemented. On Windows, this is [snip]CreateFile()[/snip]. On Linux, this is [snip]stat()[/snip].
I was already aware of most of this stuff, but I don't mind a refresher.
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 »