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 »
1531
General ENIGMA / Re: Some common GML issues, and dealing with them in Enigma?
« on: December 23, 2010, 09:39:45 pm »
Yes, all of these will be queued in each event if used. Pay attention to that last clause. If no one uses the when(), step{}, or draw{} statement, they will not be added to any of the objects. As polygone mentioned, most of the events are entirely queue-based anyway, so the performance cut from when() will be roughly negligible. Those who are concerned about the negligible (such as myself) can opt to program the checks in manually so they are not stacked anywhere and iterated.
1532
General ENIGMA / Re: Some common GML issues, and dealing with them in Enigma?
« on: December 22, 2010, 09:13:02 pm »
I like the draw {} idea. I think we'll limit it to that.
As for current_step making lives easier... I suppose so, but I think ENIGMA inherits enough bloat from GM as it is. I... guess I'll consider it since current_time in fact will not take space in ENIGMA's RAM unless used.
As for current_step making lives easier... I suppose so, but I think ENIGMA inherits enough bloat from GM as it is. I... guess I'll consider it since current_time in fact will not take space in ENIGMA's RAM unless used.
1533
General ENIGMA / Re: Some common GML issues, and dealing with them in Enigma?
« on: December 22, 2010, 08:05:57 pm »
Timers:
Ah, I see. Not a bad idea; I'll implement it when Ism reads events.res after we have our own format.
when/step:
Yes, I'm pretty happy with the syntax we specified (used in my example code). We should probably document the alarm-like behavior of when (with the ++name) so new users know how to do so simply.
Ah, I see. Not a bad idea; I'll implement it when Ism reads events.res after we have our own format.
when/step:
Yes, I'm pretty happy with the syntax we specified (used in my example code). We should probably document the alarm-like behavior of when (with the ++name) so new users know how to do so simply.
1534
General ENIGMA / Re: Some common GML issues, and dealing with them in Enigma?
« on: December 22, 2010, 07:00:19 pm »
Polygone:
game_end(bool now = false): Good idea.
instance_destroy(obj): Already done. Since R3, and made public in R4.
Rusky:
...Sometimes I think you don't know what with() does...
Is apparently the same as, but much, much less efficient than
Freezway/Ism:
The create event in GML is the equivalent of a constructor in C++. By logical dynamic, the create event must be the first event an instance can perform. Events.res has no control over the create event; it only lists it with an integer mapping to Mark's specification.
game_end(bool now = false): Good idea.
instance_destroy(obj): Already done. Since R3, and made public in R4.
Quote
I'm not actually sure it would work very well having it's own interface, it sounds like a lot of work to implement as well which is never good for Ism.Actually, it'd be as simple as another setting script like the four she offers now under "ENIGMA Settings." Each of those is supposed to be game-specific, and Definitions scripts are supposed to be instantiable. ENIGMA will, at that point, let you set code to be executed before game start, after game end, and (with my proposed addition) during game pause.
I was thinking before of perhaps a separate set of functions for pausing, similar to the high-score functions maybe. So it's functionality is not fully in the hands of the user but more generalised. This would be easier for plain pause menus and for most people to use but then a lot of pause menus also need to interact with the game itself which would be more difficult to do (maybe script_execute could be utilised though?).
I think you should add a separate event for timers, which is executed every step until the count hits 0. Just like alarms really...I see no distinction between your proposal and additional alarms. We could easily make alarms unlimited.
The when statement suggestion I think should definitely be added also, it really is a more powerful system. I don't think it's best suited like a for statement though, more like a do, until statement and I think it should be renamed from when to something elsewhen(){} and do_step{} are two entirely different mechanisms, as I'm sure you realize. They are the step-based equivalents to if() and while(), respectively: if() and when() are performed only once (when the condition is finally met), where do_step() and while() are performed throughout the duration of a condition (or its negation). In ENIGMA, no distinction is made between while !() and until()... that may work to our advantage. How do you feel about when(){} and step(){}[until()]?
Code: (EDL) [Select]
// Destroy the next gate we come near. It'll probably create effects in its destroy event.
when (distance_to_object(instance_nearest(x,y,gate))<32)
{
instance_destroy(instance_nearest(x,y,gate));
}
// Implement an alarm using only one local variable
local int do_explode = 0;
when (++do_explode == 30)
{
// Alarm code
}
// Emit particles until not dizzy
local int dizzy = 100;
step {
instance_create(x,y,dizzy_spiral);
dizzy--;
} until not dizzy
Rusky:
...Sometimes I think you don't know what with() does...
Code: (GML) [Select]
for (i = 0; i < instance_count; i += 1) {
if (instance_id[i].object_index == bomb_obj && distance_to_object(instance_id[i]) < 100)
instance_destroy()
}
Is apparently the same as, but much, much less efficient than
Code: (GML) [Select]
with (bomb_obj) if (distance_to_object(instance_id[i]) < 100)
instance_destroy()
Freezway/Ism:
The create event in GML is the equivalent of a constructor in C++. By logical dynamic, the create event must be the first event an instance can perform. Events.res has no control over the create event; it only lists it with an integer mapping to Mark's specification.
1535
Proposals / Re: Editing Events Inside LGM
« on: December 21, 2010, 08:17:16 pm »
At present Ism doesn't obey events.res. And this is very Java-oriented, which pretty much leaves me out. So I guess we'll see.
1536
Announcements / Re: Collisions update
« on: December 21, 2010, 08:15:09 pm »
I have indeed always been. If there is one thing in that forsaken program that Mark did right, it's collisions. In theory... Actually, I don't have much of a theory. I made sure that ENIGMA's instance and event systems were at least as efficient as his, so any slack he saves I'll be saving as well. What it comes down to is us keeping up with Mark in his own domain (it is my understanding that he teaches courses in collision system design).
1537
General ENIGMA / Re: ENIGMA games on DS
« on: December 21, 2010, 08:12:01 pm »
Yes. Miky started a port for it an eternity ago, when developing for ENIGMA was difficult. By today's standard, ENIGMA for DS would be hundreds of times easier (soon to be thousands when I begin the Wii port later this month).
1538
General ENIGMA / Re: Some common GML issues, and dealing with them in Enigma?
« on: December 21, 2010, 08:03:22 pm »
Trying to sort through you two's bickering is frustrating, so I'll just reply to everything I see without linking the posts together.
First, Poly's original post:
1. Referencing multiple instances
In Game Maker, the only way to do this is multiple inheritance. Most worthwhile scripting languages today offer multiple inheritance, but this isn't compatible with GM's system at face value due to ambiguity in event inheritance. I am still abstracting ideas on how to resolve this, but some of them depend on Ism. I've actually been thinking about this myself for my own purposes, and this is what I have so far:
I've never thought of this. It could be implemented but is not in any plan thus far. As you may be aware, maps are much easier to use in ENIGMA, but if you feel this is beneficial, file a suggestion in the tracker and I'll see about implementing it.
3. Exiting Code
I've been chewing on this issue for tears. Presently, scripts and DND are homogeneous; one exit means all exit. And, game_end() is instantaneous at the moment because I've not standardized an exit method. I've been waiting for someone to complain about this behavior before I modified it; suggestions are always welcome. I may define "exit" as goto <label generated at end of this script> and leave "return" as an omnipotent breaker. I Intended to do this about the time I index the code for quick position lookup on C++ compile error.
4. get_real
Already implemented in GTK interface; will be implemented in WinAPI when the widget APIs are finished and made available.
5. Pausing The Game
In the beginning, when the earth was young, young me wanted a pause feature that would put that kind of functionality in the hands of the user. Back then, it was intended that ENIGMA would have its own interface, and I would have a special resource to implement draw code for the pause screen. I haven't even presented the idea to Ism, because I have enough things on my wish list for her. Do you suppose it will require more than a single script executed each paused step? And should it paused immediately, or just after the frame? (You mentioned this point in another issue on this list).
6. Multiple collisions issue
Good suggestion! When I was new to Game Maker, I had this problem. I wanted to play a sound when crashing into an instance. An abs(hspeed)>0 check wouldn't work, because I just set the hspeed every time you pressed an arrow. So I ended up just checking that the sound wasn't playing. Your example's an even better one, though. The problem hasn't occurred to me in a while, and I never thought up a solution in ENIGMA. I'm a bit tired to think one up now, but I'll put some thought into it over the next while and tell you if I come up with something. My first impulse is a flag called "collision_fresh" which is set to TRUE or FALSE according to whether or not a key exists in a 2D map with the IDs of both instances. I have no idea the implications of the efficiency or simplicity of use, so I'll have to think about it further.
7. Timers
Rusky got me thinking about this problem not long ago. His solution didn't strike me as practical because I didn't see how to implement it (especially in ENIGMA), but the idea is an instantiable event (his proposal involved closures). Presumably this could be resolved by having easily forged first-class functions, but with the current state of both C++ and GML this just doesn't seem practical in full scale. They're illegal inline in C++, and var doesn't allow storing anything but real and string. What I may end up doing is allowing in-place declaration of alarms, which would mean no less bloat, but an easier interface. Again when the earth was young, I was thinking it'd be neat to have a when() {} statement, but I hadn't the foggeiest how to implement it. I may as well use the same mechanism to do so.
Or I can simply implement when() to mimic for(), and it could be used like this:
Upon reading the rest of the replies, they seem to have resolved themselves or have already been answered above. I don't have an API to iterate instances other than rooms, which you can do in GML like so:
First, Poly's original post:
1. Referencing multiple instances
In Game Maker, the only way to do this is multiple inheritance. Most worthwhile scripting languages today offer multiple inheritance, but this isn't compatible with GM's system at face value due to ambiguity in event inheritance. I am still abstracting ideas on how to resolve this, but some of them depend on Ism. I've actually been thinking about this myself for my own purposes, and this is what I have so far:
- Introduce weighted multiple inheritance. The objects are traversed from least important to most important, each overriding the code of the previous one so any conflicts are resolved by taking from the most important. (In any case, the current instance is given highest priority). In the case of empty objects used as groups, all instances of all objects inheriting from that group object are identifiable by the ID of that group object.
- A separate "tag list" deal for grouping. Like objects, only with no wasted space in the object table (or what have you).
- Varied object types. Game Maker games have a lot of controller instances and parent objects for the sole purpose of grouping. Being able to add an object of each kind could improve efficiency and organization in general, and also solve this problem (you reminded me of it). This strikes me as the ideal solution, but depends GREATLY on IsmAvatar, who may not be easily sold on the idea, as well as on a new format for ENIGMA games, which will eventually be necessary but is not yet implemented.
I've never thought of this. It could be implemented but is not in any plan thus far. As you may be aware, maps are much easier to use in ENIGMA, but if you feel this is beneficial, file a suggestion in the tracker and I'll see about implementing it.
3. Exiting Code
I've been chewing on this issue for tears. Presently, scripts and DND are homogeneous; one exit means all exit. And, game_end() is instantaneous at the moment because I've not standardized an exit method. I've been waiting for someone to complain about this behavior before I modified it; suggestions are always welcome. I may define "exit" as goto <label generated at end of this script> and leave "return" as an omnipotent breaker. I Intended to do this about the time I index the code for quick position lookup on C++ compile error.
4. get_real
Already implemented in GTK interface; will be implemented in WinAPI when the widget APIs are finished and made available.
5. Pausing The Game
In the beginning, when the earth was young, young me wanted a pause feature that would put that kind of functionality in the hands of the user. Back then, it was intended that ENIGMA would have its own interface, and I would have a special resource to implement draw code for the pause screen. I haven't even presented the idea to Ism, because I have enough things on my wish list for her. Do you suppose it will require more than a single script executed each paused step? And should it paused immediately, or just after the frame? (You mentioned this point in another issue on this list).
6. Multiple collisions issue
Good suggestion! When I was new to Game Maker, I had this problem. I wanted to play a sound when crashing into an instance. An abs(hspeed)>0 check wouldn't work, because I just set the hspeed every time you pressed an arrow. So I ended up just checking that the sound wasn't playing. Your example's an even better one, though. The problem hasn't occurred to me in a while, and I never thought up a solution in ENIGMA. I'm a bit tired to think one up now, but I'll put some thought into it over the next while and tell you if I come up with something. My first impulse is a flag called "collision_fresh" which is set to TRUE or FALSE according to whether or not a key exists in a 2D map with the IDs of both instances. I have no idea the implications of the efficiency or simplicity of use, so I'll have to think about it further.
7. Timers
Rusky got me thinking about this problem not long ago. His solution didn't strike me as practical because I didn't see how to implement it (especially in ENIGMA), but the idea is an instantiable event (his proposal involved closures). Presumably this could be resolved by having easily forged first-class functions, but with the current state of both C++ and GML this just doesn't seem practical in full scale. They're illegal inline in C++, and var doesn't allow storing anything but real and string. What I may end up doing is allowing in-place declaration of alarms, which would mean no less bloat, but an easier interface. Again when the earth was young, I was thinking it'd be neat to have a when() {} statement, but I hadn't the foggeiest how to implement it. I may as well use the same mechanism to do so.
Or I can simply implement when() to mimic for(), and it could be used like this:
Code: (EDL) [Select]
when (i=0; i==10; i++) {
//Alarm code
}
But that's kind of ugly. What do you think? My original idea was just when(condition), but I'm not sure the typical user is smart enough to say timer_explode = 0; when (timer_explode++ == 10) explode();Upon reading the rest of the replies, they seem to have resolved themselves or have already been answered above. I don't have an API to iterate instances other than rooms, which you can do in GML like so:
Code: (EDL) [Select]
for(r = room_first; r != -1; r=room_next(r)) map[room_get_name(r)] = r;
I could add such an API for all resources, if you like.
1539
Proposals / Re: Script Editor Improvements
« on: December 21, 2010, 07:46:55 pm »
I just wanted something more elegant than JEdit, which wasn't designed for much of anything by the looks of it (It doesn't seem to have an interface to number lines or highlight a certain line number, for example. Or if it does, Ism needs a good smack). I am not great with Java by any stretch, so I asked Ism to isolate JEdit's code so I could work with it to add some functionality specifically tailored to ENIGMA. She was unable to do so, so I dropped it. (thingsihateaboutjava++)
1540
Announcements / Re: Collisions update
« on: December 21, 2010, 07:18:59 pm »
All I can say is, we'll see. I have no idea whatsoever (which is somewhat unusual; I usually thoroughly investigate the implications of any differences before acting, but in this case I have nothing to go by).
I've thought about it, and the idea that scares me the most is that a GM game in which the character could not fall through a 32px gap between blocks of the same size would do so in ENIGMA, or vice versa.
All I can say is, we'll do our best and pay careful attention to reports.
I've thought about it, and the idea that scares me the most is that a GM game in which the character could not fall through a 32px gap between blocks of the same size would do so in ENIGMA, or vice versa.
All I can say is, we'll do our best and pay careful attention to reports.
1541
General ENIGMA / Re: Compiling on OS X
« on: December 19, 2010, 09:21:29 pm »
I've never gotten Java to work on a Mac to which I had access. If LGM runs for you, all you need is the developer tool set mentioned by Ism above. It's about a gigabyte and a half, if I recall correctly (I recall TGMG telling me it was more, but I'm not sure how much more).
You will need an account with Apple at http://developer.apple.com/devcenter/mac/index.action in order to obtain their supermassive tools. Most of them aren't necessary for the correct performance of ENIGMA, but I haven't found any way of obtaining the required tools individually.
You will need an account with Apple at http://developer.apple.com/devcenter/mac/index.action in order to obtain their supermassive tools. Most of them aren't necessary for the correct performance of ENIGMA, but I haven't found any way of obtaining the required tools individually.
1542
Announcements / Re: Collisions update
« on: December 19, 2010, 11:16:16 am »
I'm telling you, there's got to be someplace where they sell Java programmers by the crate. The purebred kind, the ones that don't know any other languages and can't think for themselves. If we buy a whole crate full, we can just throw out the defective ones and keep a few good ones for you to put to work.
Oh, and I fixed some stuff in those thirty revisions, too. I don't feel like reading through them to figure out what they were, but two I can readily recall are a glitch in the syntax checker and another in the motion handlers.
Oh, and I fixed some stuff in those thirty revisions, too. I don't feel like reading through them to figure out what they were, but two I can readily recall are a glitch in the syntax checker and another in the motion handlers.
1543
Proposals / Re: Random speed ups and slow downs with compiled games
« on: December 15, 2010, 09:58:27 pm »
It was a syntax error the checker missed. Most of the parsers didn't give a shit (the formatter never gives a shit), but the variable harvester was pretty pissed about it.
Fixed r566.
Fixed r566.
1544
Function Peer Review / Re: move_towards_point + move_snap
« on: December 15, 2010, 06:11:55 pm »
Hello, Mith. I didn't realize you were still around. I think what you implemented there as move_towards_point is actually mp_linear_step. I don't see a problem with the code at all, though. Nicely done.
1545
Function Peer Review / Re: clamp()
« on: December 14, 2010, 07:56:34 pm »
Clamp is more efficient than median, unless median is specialized for each argument count.
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 »