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 »
856
Announcements / Re: Iji
« on: February 07, 2013, 08:45:58 pm »
Marriage is neither necessary nor sufficient for procreation.
Also, I fear the world could not handle such a creature, were it to exist.
Not to mention the wait.
Also, I fear the world could not handle such a creature, were it to exist.
Not to mention the wait.
857
Issues Help Desk / Re: Ever since the newest Java update...
« on: February 07, 2013, 02:23:58 pm »
I've committed a fix to ENIGMA.exe. I am getting sick of this patch-maintenance bullshit; this is something this server ought to be doing for us. Or, if we must, EnigmaBot's server. Point is, compiling ENIGMA.exe is trivial, albeit not something Linux ought to do. Downloading a zip file from GitGub and packing in some files? That's trivial and something the server ought to be doing.
Anyone want to volunteer to write a PHP script to (optionally) compile ENIGMA.exe, download the repository from GitHub, and pack in the Additional files?
Would be great if it could generate deb/rpm packages, too.
Anyone want to volunteer to write a PHP script to (optionally) compile ENIGMA.exe, download the repository from GitHub, and pack in the Additional files?
Would be great if it could generate deb/rpm packages, too.
858
Announcements / Re: Iji
« on: February 04, 2013, 10:09:24 pm »
Thanks. I assumed their reaction would be roughly to the tune it adopted, but I suppose it was worth the post.
Anyone know how to clone me?
Anyone know how to clone me?
859
Announcements / Re: Iji
« on: February 04, 2013, 03:51:15 pm »
Your post makes me want to start drinking coffee.
Holy shit.
*cough*
Okay, so it may be time to invest in the idea of pre-compiling the majority of shellmain.h and writing objects to individual source files, each including that header. Functions such as instance_create would then need to use a virtual class instance or function pointer to do the allocation. This process would not only allow us to compile objects individually (which is apparently a fucking must for big objects) but would also ensure that it's possible to add objects to the game dynamically by loading them as DLLs.
This will be great for the ultimate resurrection of R3's "Build Mode," hereafter "Design Mode."
Another concern to address for both venues is the idea of scripts. Right now, I do funny things with scripts. I try to scope scripts into calling objects, and then create a global version of the script for use with, eg, script_execute(). This behavior is worth preserving; objects which call scripts will need to be rebuilt when that script is modified, anyway, to ensure that all required locals are present. That being the case, we may as well continue to scope scripts into objects so that they can be called in a way where the structure of the object pointed to by [snip]this[/snip] is known (instead of using the built-in access routines, which I'd guess are about a quarter as fast at best).
Holy shit.
*cough*
Okay, so it may be time to invest in the idea of pre-compiling the majority of shellmain.h and writing objects to individual source files, each including that header. Functions such as instance_create would then need to use a virtual class instance or function pointer to do the allocation. This process would not only allow us to compile objects individually (which is apparently a fucking must for big objects) but would also ensure that it's possible to add objects to the game dynamically by loading them as DLLs.
This will be great for the ultimate resurrection of R3's "Build Mode," hereafter "Design Mode."
Another concern to address for both venues is the idea of scripts. Right now, I do funny things with scripts. I try to scope scripts into calling objects, and then create a global version of the script for use with, eg, script_execute(). This behavior is worth preserving; objects which call scripts will need to be rebuilt when that script is modified, anyway, to ensure that all required locals are present. That being the case, we may as well continue to scope scripts into objects so that they can be called in a way where the structure of the object pointed to by [snip]this[/snip] is known (instead of using the built-in access routines, which I'd guess are about a quarter as fast at best).
860
Announcements / Re: Iji
« on: February 04, 2013, 11:11:57 am »
Our IRC friend compiled the complete list of missing functions for this game for us:
As you can see, a few of them are trivial. What this list excludes, however, is pitfalls like you mentioned, forthevin, and as I mentioned in the post before: The draw functions are very different.
Now, we can simulate GM5's draw options (such as draw_color = c_red) using multifunction_variant instances. That's easy. The issue is finding all of those differences. If anyone has them documented, it's IsmAvatar. Otherwise, we'll need to either go digging for Mark Overmars' original release on the subject, or compile a list of them ourselves.
Legacy mode for GM5 games might not be out of reach, and it might be worth the investment to attract more of these cases.
Quote
void background_restore(int back);
int draw_polygon_begin();
int draw_polygon_end();
int draw_polygon_vertex(double, double);
void draw_text_sprite(int x,int y,string str, int, int, int, int, int);
void keyboard_clear(int key);
void keyboard_set_map(int, int);
void keyboard_unset_map();
void screen_gamma(float, float, float);
void set_graphics_mode(int, int, int, int, int, int, int);
int sound_add(string fname, int kind, int, int);
void sound_discard(int sound);
void sound_frequency(int sound, float value);
void sound_restore(int sound);
void sprite_restore(int);
void tile_layer_delete(int);
void tile_layer_hide(int);
void tile_layer_shift(int, double, double);
As you can see, a few of them are trivial. What this list excludes, however, is pitfalls like you mentioned, forthevin, and as I mentioned in the post before: The draw functions are very different.
Now, we can simulate GM5's draw options (such as draw_color = c_red) using multifunction_variant instances. That's easy. The issue is finding all of those differences. If anyone has them documented, it's IsmAvatar. Otherwise, we'll need to either go digging for Mark Overmars' original release on the subject, or compile a list of them ourselves.
Legacy mode for GM5 games might not be out of reach, and it might be worth the investment to attract more of these cases.
861
Announcements / Re: Iji
« on: February 03, 2013, 11:55:42 pm »
I don't know that they could help if they wanted.
An issue is that I was wrong; this game was not re-released in GM7. Only some of his other titles were. So we still need to fix references to variables like draw_color, in place of draw_set_color, etc. Perhaps they'd be interested in doing some of that grunt work, but then, why not just build it in GM? Other than the price, of course.
An issue is that I was wrong; this game was not re-released in GM7. Only some of his other titles were. So we still need to fix references to variables like draw_color, in place of draw_set_color, etc. Perhaps they'd be interested in doing some of that grunt work, but then, why not just build it in GM? Other than the price, of course.
862
Announcements / Iji
« on: February 03, 2013, 01:17:18 pm »
I was approached today by someone on the IRC regarding an apparently quite famous game made in Game Maker 5 and re-released for Game Maker 7. By the sounds of it, a lot of you should have heard of it. The game is Iji, by Daniel Remar. You can view it and download it from his home page here:
http://www.remar.se/daniel/iji.php
Apparently, the race is on to get the project ported to other operating systems, and GM is (for whatever reason) out of the question. It seems to me like this would be a good place, strategically, for ENIGMA to make an entrance.
There is a discussion open on the Cave Story forums, for those who are interested in a little related literature:
http://www.cavestory.org/forums/index.php?/topic/4628-iji-ports-permission-granted-by-remar/
It seems that the biggest obstacles standing between the game and working on ENIGMA are timelines and name conflicts, which I guess are both a bit overdue. Unfortunately, it'd be unwise to add them to the old compiler with the new one so close to being finished, so I guess the work is going to largely involve me.
I will try to commit some time to getting that pretty printer written and plugged in to the current system. I'd appreciate it if someone else could go through and see what other functions are missing from the game. That probably means you, polygone.
Just posting this here as an FYI. Thoughts on the endeavor are welcome.
http://www.remar.se/daniel/iji.php
Apparently, the race is on to get the project ported to other operating systems, and GM is (for whatever reason) out of the question. It seems to me like this would be a good place, strategically, for ENIGMA to make an entrance.
There is a discussion open on the Cave Story forums, for those who are interested in a little related literature:
http://www.cavestory.org/forums/index.php?/topic/4628-iji-ports-permission-granted-by-remar/
It seems that the biggest obstacles standing between the game and working on ENIGMA are timelines and name conflicts, which I guess are both a bit overdue. Unfortunately, it'd be unwise to add them to the old compiler with the new one so close to being finished, so I guess the work is going to largely involve me.
I will try to commit some time to getting that pretty printer written and plugged in to the current system. I'd appreciate it if someone else could go through and see what other functions are missing from the game. That probably means you, polygone.
Just posting this here as an FYI. Thoughts on the endeavor are welcome.
863
Issues Help Desk / Re: Ever since the newest Java update...
« on: January 30, 2013, 04:06:34 pm »
It's a Java issue. I've been hearing about it a lot, recently, and I wish people would start directing these posts to Oracle so they'd fix it. Basically, someone decided that wildcards in Java filenames was a bad idea, and so they randomly and unceremoniously dropped support for it.
I'm sure if I said that to the wrong person, I'd get a lecture about how this has been the plan since dinosaurs roamed the earth, because * is terrible practice and isn't anything like how the filesystem actually works, and causes security holes from ninjas who pretend to be the file you're trying to execute... but in the meantime, I'm going to be pissed that they broke it.
Also in the meantime, I'll see about rebuilding ENIGMA.exe for Windows to run it with the full filename.
I'm sure if I said that to the wrong person, I'd get a lecture about how this has been the plan since dinosaurs roamed the earth, because * is terrible practice and isn't anything like how the filesystem actually works, and causes security holes from ninjas who pretend to be the file you're trying to execute... but in the meantime, I'm going to be pissed that they broke it.
Also in the meantime, I'll see about rebuilding ENIGMA.exe for Windows to run it with the full filename.
864
Announcements / Re: Trello
« on: January 29, 2013, 09:20:48 pm »
No biggie; that's why git has the ability to check out previous revisions.
865
Announcements / Re: Trello
« on: January 29, 2013, 10:12:27 am »
forthevin: I'm hearing that you forgot to commit your particle attractor header. Someone posted this error over the IRC:
[snip]Graphics_Systems/OpenGL/ParticleSystems/PS_particle_system.cpp:33:35: fatal error: PS_particle_attractor.h: No such file or directory[/snip]
[snip]Graphics_Systems/OpenGL/ParticleSystems/PS_particle_system.cpp:33:35: fatal error: PS_particle_attractor.h: No such file or directory[/snip]
866
Issues Help Desk / Re: How do I Change the MinGW Directory?
« on: January 28, 2013, 10:34:56 pm »
Edit the file Compilers/Windows/gcc.ey.
Specifically, change these lines:
Replace [snip]\MinGW[/snip] with the path to MinGW on your desktop. It should have no spaces in it, preferably.
Cheers
Specifically, change these lines:
Code: (yaml) [Select]
path: \MinGW\bin\;\MinGW\msys\1.0\bin\;
tcpath: /MinGW/bin:/bin:
make: \MinGW\msys\1.0\bin\make.exe
binpath: \MinGW\bin\
defines: \MinGW\bin\cpp -dM -x c++ -E $blank
searchdirs: \MinGW\bin\gcc -E -x c++ -v $blank
Replace [snip]\MinGW[/snip] with the path to MinGW on your desktop. It should have no spaces in it, preferably.
Cheers
867
Announcements / Re: Trello
« on: January 26, 2013, 02:21:27 pm »
Nicely done.
Maybe tonight or tomorrow night I'll be back on Linux and can do something myself.
Maybe tonight or tomorrow night I'll be back on Linux and can do something myself.
868
Announcements / Re: Trello
« on: January 26, 2013, 11:58:10 am »
> In regards to committing, I have decided to make the change in a fork and then make a pull request, just to keep things cleaner.
That's fine. I'll review it before I pull it, then.
> I must admit that I prefer tagged unions when the language used provides support for them
Indeed, such a system would be messier in C++. You'll find that the structures JDI uses to represent macros are similar to a tagged union; instead of a vtable, they rely on a boolean to determine whether they contain a function or a scalar. Dealing with those in C++ can be a headache, though, and so I try to limit my use of them.
Another consideration was to pack all the functions for dealing with ASTs into an array, and then use the type enum to choose the correct call from it, but arrays of member functions could prove problematic. Virtual classes seemed like the best way of dealing with the problem, but if you have a better way, it would honestly not be hard to switch them out.
> I don't like that (Const)ASTOperator and AST_Node are so tightly coupled
If this were C#, we'd use its built-in "Extension method" system that seemingly violates all manner of encapsulation, and we wouldn't need AST_Operator at all. However, this is C++, so sometimes promoting extensibility requires putting in more code to make the object extensible.
> I found out that the "friend" concept does not extend to subclasses.
Yikes. I assumed that since the methods were pure virtuals, C++ would have to let you implement them in children of any kind. Somewhat of an unfounded assumption, I suppose. Anyway, go ahead and make them all public, then; I very rarely use [snip]protected:[/snip] and almost never use [snip]private:[/snip] for this sort of reason. I thought it would be good to denote which members serve typical use-case purposes in JDI and which are for people extending or developing it, but I suppose we'll probably be the only people to ever use JDI, anyway.
Another idea, though: Could this be handled using a typedef from within the ASTOperator class? It probably cannot, but you could try it if you value the protection level.
> What kind of operations do you have in mind should be performed on the abstract syntax tree (apart from printing EDL to C++ and javascript)?
Really, I don't have any plans for them apart from pretty-printing. Those two classes were created to replace the lack of ability to add member functions to the node classes, for general-purpose recursive operations. My having a plan for them would therefore be a detriment to that purpose. In the event that there exists a more elegant way to add this capability, those classes can be scrapped. I'm open to suggestions.
> I don't have much in terms of plans regarding what to work on after the first to-do, but I believe that I will work towards finishing up the particle systems. It works pretty well at the moment, but there are some non-core functionality that is still missing, such as effects, attractors, changers, destroyers and deflectors, and emitters are not fully implemented yet.
That's fine. Like I said, I wasn't actually expecting that anyone would pick up the torch while I'm doing school things.
Even if I had the pretty-printer ready right now, there's still a cluster of little shit that needs done to the compiler to maintain its interface with the API LGM currently uses to work with ENIGMA. For instance, the new parser throws multiple syntax errors and warnings; LGM displays only one, like GM. LGM (or to be more accurate, the ENIGMA plugin for LGM) will eventually need fixed up, and Ism isn't really available to do the work, either. I have no idea how long this will get delayed as a result of the two of us being busy.
When I do have the free-time required to finish this integration and test it, the real test for this new system will be if TGMG is able to hook in his JavaScript port. That will prove that the system is modular enough to support any kind of language we want to add to it, and that it's simple enough to be read and understood by someone who did not write it.
In the meantime, the project will limp by with the old translator, which seems to be doing an "ok" job.
When this thing is all in, though, the first thing on my list is to get rid of the globals used to identify the current instance. The new pretty-printer should be in charge of passing the necessary information to each function to work with the current instance. I will probably want all the help I can get doing that.
That's fine. I'll review it before I pull it, then.
> I must admit that I prefer tagged unions when the language used provides support for them
Indeed, such a system would be messier in C++. You'll find that the structures JDI uses to represent macros are similar to a tagged union; instead of a vtable, they rely on a boolean to determine whether they contain a function or a scalar. Dealing with those in C++ can be a headache, though, and so I try to limit my use of them.
Another consideration was to pack all the functions for dealing with ASTs into an array, and then use the type enum to choose the correct call from it, but arrays of member functions could prove problematic. Virtual classes seemed like the best way of dealing with the problem, but if you have a better way, it would honestly not be hard to switch them out.
> I don't like that (Const)ASTOperator and AST_Node are so tightly coupled
If this were C#, we'd use its built-in "Extension method" system that seemingly violates all manner of encapsulation, and we wouldn't need AST_Operator at all. However, this is C++, so sometimes promoting extensibility requires putting in more code to make the object extensible.
> I found out that the "friend" concept does not extend to subclasses.
Yikes. I assumed that since the methods were pure virtuals, C++ would have to let you implement them in children of any kind. Somewhat of an unfounded assumption, I suppose. Anyway, go ahead and make them all public, then; I very rarely use [snip]protected:[/snip] and almost never use [snip]private:[/snip] for this sort of reason. I thought it would be good to denote which members serve typical use-case purposes in JDI and which are for people extending or developing it, but I suppose we'll probably be the only people to ever use JDI, anyway.
Another idea, though: Could this be handled using a typedef from within the ASTOperator class? It probably cannot, but you could try it if you value the protection level.
> What kind of operations do you have in mind should be performed on the abstract syntax tree (apart from printing EDL to C++ and javascript)?
Really, I don't have any plans for them apart from pretty-printing. Those two classes were created to replace the lack of ability to add member functions to the node classes, for general-purpose recursive operations. My having a plan for them would therefore be a detriment to that purpose. In the event that there exists a more elegant way to add this capability, those classes can be scrapped. I'm open to suggestions.
> I don't have much in terms of plans regarding what to work on after the first to-do, but I believe that I will work towards finishing up the particle systems. It works pretty well at the moment, but there are some non-core functionality that is still missing, such as effects, attractors, changers, destroyers and deflectors, and emitters are not fully implemented yet.
That's fine. Like I said, I wasn't actually expecting that anyone would pick up the torch while I'm doing school things.
Even if I had the pretty-printer ready right now, there's still a cluster of little shit that needs done to the compiler to maintain its interface with the API LGM currently uses to work with ENIGMA. For instance, the new parser throws multiple syntax errors and warnings; LGM displays only one, like GM. LGM (or to be more accurate, the ENIGMA plugin for LGM) will eventually need fixed up, and Ism isn't really available to do the work, either. I have no idea how long this will get delayed as a result of the two of us being busy.
When I do have the free-time required to finish this integration and test it, the real test for this new system will be if TGMG is able to hook in his JavaScript port. That will prove that the system is modular enough to support any kind of language we want to add to it, and that it's simple enough to be read and understood by someone who did not write it.
In the meantime, the project will limp by with the old translator, which seems to be doing an "ok" job.
When this thing is all in, though, the first thing on my list is to get rid of the globals used to identify the current instance. The new pretty-printer should be in charge of passing the necessary information to each function to work with the current instance. I will probably want all the help I can get doing that.
869
Announcements / Re: Trello
« on: January 25, 2013, 09:49:19 pm »
<rant>
<tl:dr>
- Heh, all right. I certainly won't object, because I'm not making any headway while I'm stranded on Windows.
I have added the account "forthevin" to the project. I hope that's yours (I assume you'd have otherwise specified the account).
I will review your commit to make sure it's not missing anything. I can do that much from GitHub during class. I'll also admit that I got a little sidetracked and started going over the way JDI handles templates, which could be a sizey operation. That said, don't bother to start on point (2).
<rant level="2">
- To be honest, though, I did the JDI one in ten minutes using regular expressions. So if it's going to take you much longer than that, don't worry about it. As I mentioned earlier, I mostly put that up so cheeseboy had something to do other than bitch at me (he can't really bitch if he's not capable of doing any of my to-do points).
<rant level="over 9000">
- To be even more honest, the to-do point evolved into somewhat of a curiosity project of mine wherein I postulated that no one would even try figuring out anything to do with how the parser worked. I wanted to see how long it would be before someone offered an attempt at it. I would have you do it more to get your opinion on how it is handled and to have someone else understand so much as one God-damned component of the new parser system than to save myself effort.
So yes, feel free to do so, but do so in the spirit of learning (and possibly of improving) rather than of really breaking ground.
Then again, if you're really on a roll, maybe you can write the whole pretty printer using that entirely untested system, and the new parser will be ready-to-rock without the other to-do points (if slightly incomplete).
Meh.
<tl:dr>
- I have added you. Have fun.
870
Proposals / Re: Proposals for implementing ASTOperator for EDL_AST
« on: January 20, 2013, 11:37:32 am »
I mostly put the task on Trello to give cheeseboy something to do instead of bitching at me to do it. Your (1) is more than sufficient.
The ASTOperator class is just an interface: the node types themselves call it. So when a node needs operated on, instead of calling a function in ASTOperator, you call one in node; ie, instead of astOperator->operate(node), you call node->operate(astOperator). The vtable in the node handles making the correct call.
So even if JDI AST elements could end up accidentally storing an EDL AST element (which doesn't happen, presently), the vtable would still call the correct method (but it would have to cast from jdi::ASTOperator to EDL_ASTOperator, which is potentially dangerous).
So yeah, no templates necessary. Just vtables.
The ASTOperator class is just an interface: the node types themselves call it. So when a node needs operated on, instead of calling a function in ASTOperator, you call one in node; ie, instead of astOperator->operate(node), you call node->operate(astOperator). The vtable in the node handles making the correct call.
So even if JDI AST elements could end up accidentally storing an EDL AST element (which doesn't happen, presently), the vtable would still call the correct method (but it would have to cast from jdi::ASTOperator to EDL_ASTOperator, which is potentially dangerous).
So yeah, no templates necessary. Just vtables.
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 »