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 »
1756
Announcements / Re: Mini Progress Feed
« on: August 29, 2010, 02:18:41 PM »
Ah, yes. That was just me being tired at two in the morning. I didn't feel like intercepting parse output between the part where self. is added and OBJ.varname is replaced.

1757
Announcements / Re: Mini Progress Feed
« on: August 29, 2010, 01:12:57 AM »
Retro: I asked you ages ago to test file_find_first on your system. The only explanation I have is that ENIGMA cannot read the YAML files defining those locals on your platform. I have a hunch it has to do with access() rather than opendir().
Progress:
Haven't seen Ism all bloody day. Worked with TGMG and resolved a few more Mac issues, but there seems to be a problem with one of the compatibility macros on that platform. We'll look into it tomorrow.
Fixed the parsing of `OBJECT.variable`. Its functionality, however, is not yet finished. I may finish it before I fall asleep, but I can't promise that. It will be finished sometime today, though.
Annoyed at a problem retep and Rusky are experiencing. For some reason, their MinGW configurations are trying to access something from the Program Files, but only manage to call C:Program. Talk about annoying.
Further update:
What that means is as follows:
1) string is incorrect until I remove the template flag when typedef'd with zero unfilled parameters
2) OBJ.x will operate more efficiently than OBJ.randomness, because x is guaranteed to exist.
3) Operator <dot> is now universal. Pointer.Member === Pointer->Member. StructInst.Member is left alone. Instance.Member is parsed correctly to allow lookup.
With() has one remaining bug, being that this code:
The reason self is added at all is because the system recognizes self (-3 or whatever it is) as [the currently active object], which with() modifies.
Progress:
Haven't seen Ism all bloody day. Worked with TGMG and resolved a few more Mac issues, but there seems to be a problem with one of the compatibility macros on that platform. We'll look into it tomorrow.
Fixed the parsing of `OBJECT.variable`. Its functionality, however, is not yet finished. I may finish it before I fall asleep, but I can't promise that. It will be finished sometime today, though.
Annoyed at a problem retep and Rusky are experiencing. For some reason, their MinGW configurations are trying to access something from the Program Files, but only manage to call C:Program. Talk about annoying.
Further update:
Code: (C) [Select]
int cfp;
cfp.x = 0;
cfp.y = 0;
cfp.randomness = 0;
cfp.bliss = 0;
cfp.speed = 0;
cfp.health = 0;
string xfp;
xfp.length = 0;
instance_nearest(x,y,0).r = 0
er.ar.bar = car;
string *xstr;
xstr.length = 0;
//=======================================\\
// P a r s e s t o
//=======================================//
int cfp;
int cfp;
enigma::glaccess(cfp)-> x = 0;
enigma::glaccess(cfp)-> y = 0;
enigma::varaccess_randomness(int(cfp))= 0;
enigma::varaccess_bliss(int(cfp))= 0;
enigma::glaccess(cfp)-> speed = 0;
enigma::glaccess(cfp)-> health = 0;
string<> xfp;
xfp.length = 0;
with(enigma::varaccess_nigr(int(anus)))
enigma::varaccess_arse(int(self))= enigma::varaccess_tits(int(self));
enigma::varaccess_r(int(instance_nearest(x, y, 0)))= 0;
enigma::varaccess_bar(int(enigma::varaccess_ar(int(er))))= car;
string<> * xstr;
xstr -> length = 0;
What that means is as follows:
1) string is incorrect until I remove the template flag when typedef'd with zero unfilled parameters
2) OBJ.x will operate more efficiently than OBJ.randomness, because x is guaranteed to exist.
3) Operator <dot> is now universal. Pointer.Member === Pointer->Member. StructInst.Member is left alone. Instance.Member is parsed correctly to allow lookup.
With() has one remaining bug, being that this code:
Code: (GML) [Select]
with (a) b.c = d;
Intermediately parses toCode: (GML) [Select]
with (a) self.b.self.c = d;
Instead of just self.b.c, as it should.The reason self is added at all is because the system recognizes self (-3 or whatever it is) as [the currently active object], which with() modifies.
1758
Announcements / Re: Mini Progress Feed
« on: August 28, 2010, 02:33:38 PM »
Well, when it sees the comma at present, it does what C++ would do: use the latter term.
1759
Announcements / Mini Progress Feed
« on: August 28, 2010, 06:26:16 AM »
They say coordinating programmers is like herding cats.
Well, if herding cats is this disinteresting, I believe them.
Anyway, I have truly no idea where everybody is. I swear LGM still isn't rebuilding ENIGMA for me on Linux. I think Retro's done with his packages, and I think they only contain the essentials now, but I'm not certain. Last I heard he was uploading them at 80kbps, with an ETA of 18 hours or something? It wasn't exactly encouraging.
Anyway, I wanted Ism to get our new C++ resource working (as in, saving) before the release, as it is the method by which users can create and share C++ functions. With it, you can take part in ENIGMA's development, whether by implementing your own C++ functions or by including other users' to test or for personal use. The resource has many applications outside of the beta program; I know it'll become a crowd pleaser over time. Especially when I finish what I'm working on right now.
Basically, I have three things in my scope at the moment:
1) var[x,y]
2) room order: base off resource tree, not ID
3) OBJ.varname
Presently, I am working on the third. It worked in R3, but was so inefficient I decided to replace it early on, but didn't finish it.
When that is done, with() should start working also.
I added backgrounds to the executable, but I don't do much with them at the moment. I didn't want to add tiles until I worked out a depth system that agreed with the way I read events from a YAML configuration file. As it stands, the compiler doesn't ship knowing the name of a single event: How am I supposed to give draw event order special behavior?
Actually, the answer just came to me (Which is odd considering the hour; I think I had the idea before). In essence, the special variable I'll need to instantiate for depth will insert its call into the correct depth layer on construct. On assign, it unlinks and re-inserts. On destruct, it unlinks finally.
Okay, that solved, I'm going to sleep, then finish OBJ.varname so with and such works. To-do to finish that:
1) Keep list of `member` instances parsed as "access_%1"
2) Add that function to the usable function list so as to avoid a.b.c mis-parse.
3) Check variable data from all objects for type conflicts
4) Generate the access functions based off data from all objects
Next I'll do var[x,y] (needs replaced with var(x,y)), then rooms (needs double-buffered: one array by room ID, one non-sparse array for quick traversal.
Mac progress... Good on my end, waiting for update from TGMG. Must have fixed ten problems. Looking promising.
For now, good night.
Well, if herding cats is this disinteresting, I believe them.
Anyway, I have truly no idea where everybody is. I swear LGM still isn't rebuilding ENIGMA for me on Linux. I think Retro's done with his packages, and I think they only contain the essentials now, but I'm not certain. Last I heard he was uploading them at 80kbps, with an ETA of 18 hours or something? It wasn't exactly encouraging.
Anyway, I wanted Ism to get our new C++ resource working (as in, saving) before the release, as it is the method by which users can create and share C++ functions. With it, you can take part in ENIGMA's development, whether by implementing your own C++ functions or by including other users' to test or for personal use. The resource has many applications outside of the beta program; I know it'll become a crowd pleaser over time. Especially when I finish what I'm working on right now.
Basically, I have three things in my scope at the moment:
1) var[x,y]
2) room order: base off resource tree, not ID
3) OBJ.varname
Presently, I am working on the third. It worked in R3, but was so inefficient I decided to replace it early on, but didn't finish it.
When that is done, with() should start working also.
I added backgrounds to the executable, but I don't do much with them at the moment. I didn't want to add tiles until I worked out a depth system that agreed with the way I read events from a YAML configuration file. As it stands, the compiler doesn't ship knowing the name of a single event: How am I supposed to give draw event order special behavior?
Actually, the answer just came to me (Which is odd considering the hour; I think I had the idea before). In essence, the special variable I'll need to instantiate for depth will insert its call into the correct depth layer on construct. On assign, it unlinks and re-inserts. On destruct, it unlinks finally.
Okay, that solved, I'm going to sleep, then finish OBJ.varname so with and such works. To-do to finish that:
1) Keep list of `member` instances parsed as "access_%1"
2) Add that function to the usable function list so as to avoid a.b.c mis-parse.
3) Check variable data from all objects for type conflicts
4) Generate the access functions based off data from all objects
Next I'll do var[x,y] (needs replaced with var(x,y)), then rooms (needs double-buffered: one array by room ID, one non-sparse array for quick traversal.
Mac progress... Good on my end, waiting for update from TGMG. Must have fixed ten problems. Looking promising.
For now, good night.
1760
Announcements / Re: Where do we stand?
« on: August 28, 2010, 03:16:59 AM »/
| |
\ \
| | |
\ / / \
\ | | | |
| / /\ \ /
/ | /# \ | |
| \ * ` \
\ / = # ` |
| | # ___/ /
/ _`---^^^ `. |
| .* # = | \
| = # __/
.\____-------^^ `.
/ # # \
| = = |
\___ # #___--^
^^^^^^^^^^^
Not much else to explain.
Fixed that and ten other things. Adding something I know everyone will be happy about.
1761
Proposals / Re: Optimize it
« on: August 27, 2010, 05:06:49 PM »
So, then. What's it like to program with C++?
1762
Proposals / Re: Optimize it
« on: August 27, 2010, 01:27:14 PM »
The latter problem you describe is exactly what the latest revision fixes... I'll investigate.
I'll remove the dependency on endian.h; it figures it was too useful to be available on Windows.
I'll remove the dependency on endian.h; it figures it was too useful to be available on Windows.
1763
Proposals / Re: GM Function Implementations
« on: August 26, 2010, 11:23:00 PM »
That much isn't actually my responsibility. Someone would have to be gravely stupid to type action_if(); instead of if(). DND caters to novices. Real programmers learn when to semicolon.
However, what does action_if(false); show_message("weee"); do in GM?
However, what does action_if(false); show_message("weee"); do in GM?
1764
Proposals / Re: Optimize it
« on: August 26, 2010, 11:18:57 PM »
My biggest suggestions are to reduce your draw_set_color() calls (by calling one up front of the loop instead of letting the graphics system call the equivalent literally 80,000 times) and to use C++ types more often.
I noticed your implementation has a few workarounds in it. I will do my best to remove the need for such. I have already made one improvement to allow further optimization of your game. Please check out the latest revision.
I have implemented my suggestions here:
http://dl.dropbox.com/u/1052740/watersimulation.gmk
Cheers.
I noticed your implementation has a few workarounds in it. I will do my best to remove the need for such. I have already made one improvement to allow further optimization of your game. Please check out the latest revision.
I have implemented my suggestions here:
http://dl.dropbox.com/u/1052740/watersimulation.gmk
Cheers.
1765
Proposals / Re: GM Function Implementations
« on: August 25, 2010, 03:21:41 PM »
RetroX:
In whitespace:
#define action_if(x) if (x)
#define action_draw_arrow draw_arrow
#define create_object instance_create
int action_draw_life(int x, int y, int spr) {
for (int i = 0; i < life; i++)
draw_sprite(spr,0,x + i*sprite_get_width(spr), y);
}
etc.
Note: that draw_life one won't work as-is; it's just a demonstration. Let me set up an API to make that easy for typical users, and I'll update this with it.
In whitespace:
#define action_if(x) if (x)
#define action_draw_arrow draw_arrow
#define create_object instance_create
int action_draw_life(int x, int y, int spr) {
for (int i = 0; i < life; i++)
draw_sprite(spr,0,x + i*sprite_get_width(spr), y);
}
etc.
Note: that draw_life one won't work as-is; it's just a demonstration. Let me set up an API to make that easy for typical users, and I'll update this with it.
1766
General ENIGMA / Re: Help File?
« on: August 23, 2010, 06:39:59 PM »
HaRRiKiRi:
The function list page (however outdated) will allow you to submit a description.
The function list page (however outdated) will allow you to submit a description.
1767
General ENIGMA / Re: Help File?
« on: August 23, 2010, 04:15:35 PM »
ENIGMA Will do no such thing. A warning is thrown if the variable is not an ENIGMA type, and the value is truncated.
1768
Announcements / Re: Where do we stand?
« on: August 23, 2010, 11:33:38 AM »
IsmAvatar:
As on Unix, a beginning \ denotes root of the drive on Windows. So when you see \, just replace with the current drive letter if Java can't.
We'll discuss the updating on the IRC, if both of you are on.
As on Unix, a beginning \ denotes root of the drive on Windows. So when you see \, just replace with the current drive letter if Java can't.
We'll discuss the updating on the IRC, if both of you are on.
1769
Announcements / Re: Where do we stand?
« on: August 23, 2010, 01:40:15 AM »
Also, Ism. When winmake.txt reads this:
\MinGW\bin\mingw32-make.exe
Java can't find it. I don't know what Java uses to make system calls, but it's apparently bad at life. Could you try to remedy that?
Also, seems the gray, open console box is fixed in the latest revision.
\MinGW\bin\mingw32-make.exe
Java can't find it. I don't know what Java uses to make system calls, but it's apparently bad at life. Could you try to remedy that?
Also, seems the gray, open console box is fixed in the latest revision.
1770
Announcements / Where do we stand?
« on: August 23, 2010, 01:35:44 AM »
I decided to implement backgrounds in the meantime, and dazappa has kept me busy with a number of interesting bug reports (the worst of which I have just worked out). I am not sure what is in the update-stable/ tag, but fixing it to actually work out of the box on at least Windows and Linux is priority one.
Ism has made great progress on the updater. From what I can tell it is finished, though it has an odd tendency to leave a console window open with a gray background for me.
RetroX has finished some packages, but we were discussing what the package should be responsible for vs what LGM should be responsible for. I believe right now, he's configured them to give 777 permissions to /opt/enigma, where it is installed. But it seems he includes the entire repository with the package, which means users could be downloading an outdated package from square one. Correct, RetroX?
As for the Windows release, I don't even think an installer is necessary. I think a zip file containing ENIGMA.exe, lgm16b4.jar, and the plugins folder will suffice. ENIGMA.exe and LGM will take care of the rest.
If you object to not having an installer for Windows, speak now, and I or someone else will make one.
Retro, if you want to carry our discussion regarding the packages over here, please do so. Otherwise, I think ENIGMA.exe and the jar files will suffice, along with that dependency list you've already implemented.
I am going to finish dazappa's last few bug reports.
IsmAvatar, when you are content with the updater, please say so.
RetroX, when you are done with the packages, please link all of them here, and I will rehost.
The release (And frantic workarounds for everything that goes wrong soon after) will begin as soon as the three of us are done.
Ism has made great progress on the updater. From what I can tell it is finished, though it has an odd tendency to leave a console window open with a gray background for me.
RetroX has finished some packages, but we were discussing what the package should be responsible for vs what LGM should be responsible for. I believe right now, he's configured them to give 777 permissions to /opt/enigma, where it is installed. But it seems he includes the entire repository with the package, which means users could be downloading an outdated package from square one. Correct, RetroX?
As for the Windows release, I don't even think an installer is necessary. I think a zip file containing ENIGMA.exe, lgm16b4.jar, and the plugins folder will suffice. ENIGMA.exe and LGM will take care of the rest.
If you object to not having an installer for Windows, speak now, and I or someone else will make one.
Retro, if you want to carry our discussion regarding the packages over here, please do so. Otherwise, I think ENIGMA.exe and the jar files will suffice, along with that dependency list you've already implemented.
I am going to finish dazappa's last few bug reports.
IsmAvatar, when you are content with the updater, please say so.
RetroX, when you are done with the packages, please link all of them here, and I will rehost.
The release (And frantic workarounds for everything that goes wrong soon after) will begin as soon as the three of us are done.
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 »