polygone
|
|
Reply #15 Posted on: December 22, 2010, 07:11:58 pm |
|
|
Location: England Joined: Mar 2009
Posts: 794
|
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. Ah I see, that's a good idea yeah. I didn't realise you could do something like that so easily. If you could get that to work it would be a very good way of implementing pausing. I see no distinction between your proposal and additional alarms. We could easily make alarms unlimited. The timer suggestion I made is different to alarms, the code in alarm events only executes when the alarm timer reaches 0. The code in timer events would execute every step until the timer reaches 0. Timer event probably isn't the best name for it as it's confusing, I couldn't think of a proper name for it though. How do you feel about when(){} and step(){}[until()]? Yes step() is a good name instead of do_step. That all works good. I didn't think of the ++do_explode trick, I see how that makes things even easier. So are you happy with that syntax yourself now? I think it all works well and comes rather naturally to write, I don't think a beginner would struggle with the concept either, it seems pretty easy to follow in my opinion (it's probably easier to understand than a for loop).
|
|
« Last Edit: December 22, 2010, 07:34:45 pm by polygone »
|
Logged
|
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
|
|
|
Josh @ Dreamland
|
|
Reply #16 Posted on: December 22, 2010, 08:05:57 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
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.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
polygone
|
|
Reply #17 Posted on: December 22, 2010, 08:28:38 pm |
|
|
Location: England Joined: Mar 2009
Posts: 794
|
Oh I have just had some sudden thoughts. I was thinking could you make it so using until after step was optional, if it wasn't added it would just always execute the code in the step event. While visualising that and due to your changed naming convention I then thought could you not also add beginstep and endstep statements as well? This would then give you control over when the step code is actually executed. And, then I thought surely a draw statement could also be added in the exact same way. So things like this could be done: draw { draw_text(x, y, "Yo"); //this would draw the text "Yo" from now on } OR i = 0; draw { i++; draw_text(x, y, "some text"); //this now actually solves the original problem I stated! :] } until (i == 4*room_speed) This would be great. Not being able to draw in events other than the draw event is actually another one of GML's common problems but this would be a neat way of solving it if it is possible to implement, which I'm thinking it is ... Timers: Ah, I see. Not a bad idea; I'll implement it when Ism reads events.res after we have our own format. Cool. Maybe think of a better name for them though
|
|
« Last Edit: December 24, 2010, 09:17:51 am by polygone »
|
Logged
|
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
|
|
|
polygone
|
|
Reply #18 Posted on: December 22, 2010, 08:55:12 pm |
|
|
Location: England Joined: Mar 2009
Posts: 794
|
Another thought, could you add a read-only global variable current_step, which would work just like current_time except with steps. Then alarm codes will become even easier and not need to involve creating a local variable each time:
var message_end = current_step + 4*room_speed; draw { draw_text(x, y, "some text"); } until (current_step == message_end)
var step_now = current_step; when (current_step == step_now + 30) { // Alarm code }
|
|
« Last Edit: December 24, 2010, 09:16:18 am by polygone »
|
Logged
|
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
|
|
|
Josh @ Dreamland
|
|
Reply #19 Posted on: December 22, 2010, 09:13:02 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
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.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
polygone
|
|
Reply #20 Posted on: December 22, 2010, 09:24:06 pm |
|
|
Location: England Joined: Mar 2009
Posts: 794
|
I like the draw {} idea. I think we'll limit it to that.
OK. I suppose beginstep and endstep aren't exactly 'pretty' as statements. Draw and step will be nice enough 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. Hmm, I'll try to think of some other uses for it to try and justify it's inclusion. Perhaps you should not add any unnecessary extra bloat though like you said, it is a variable you kind of expect to exist though. EDIT: It could be useful with timelines maybe? In fact wouldn't you actually need an internal variable like this if timelines were used in a game (that's if you even bother to actually implement them of course :p).
|
|
« Last Edit: December 23, 2010, 01:59:53 pm by polygone »
|
Logged
|
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
|
|
|
|
luiscubal
|
|
Reply #22 Posted on: December 23, 2010, 11:43:18 am |
|
|
Joined: Jun 2009
Posts: 452
|
There are edge cases that need to be solved. For instance, is draw{} drawn BEFORE or AFTER the draw event contents?
Also, in
var step_now = current_step; draw { draw_text(x, y, "some text"); } until (current_step == step_now + 4*room_speed) If current_step != step_now + 4*room_speed for a bit, and then equal once again, would some text be rendered in the screen or not?
Also, regarding WHEN, couldn't it significantly harm performance?
|
|
|
Logged
|
|
|
|
polygone
|
|
Reply #23 Posted on: December 23, 2010, 12:11:47 pm |
|
|
Location: England Joined: Mar 2009
Posts: 794
|
For instance, is draw{} drawn BEFORE or AFTER the draw event contents? After would make more sense to me. If current_step != step_now + 4*room_speed for a bit, and then equal once again, would some text be rendered in the screen or not? Text would be drawn while (current_step != step_now + 4*room_speed) and then when (current_step == step_now + 4*room_speed) the code piece would be removed so it would not be drawn again. Also, regarding WHEN, couldn't it significantly harm performance? Why?
|
|
« Last Edit: December 23, 2010, 01:00:59 pm by polygone »
|
Logged
|
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
|
|
|
|
polygone
|
|
Reply #25 Posted on: December 23, 2010, 01:46:54 pm |
|
|
Location: England Joined: Mar 2009
Posts: 794
|
If you have multiple draw{}until(); statements, in which order are they executed.
I presume in the order they were called. I see it as just adding them in a list to the end of the draw code, then if their until statement is met they are removed from the list.
|
|
« Last Edit: December 23, 2010, 01:50:42 pm by polygone »
|
Logged
|
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
|
|
|
|
polygone
|
|
Reply #27 Posted on: December 23, 2010, 05:15:02 pm |
|
|
Location: England Joined: Mar 2009
Posts: 794
|
This can be fixed with some kind of queue, but that seems just like another way to lose memory and speed. Why would it lose memory and speed?
|
|
|
Logged
|
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
|
|
|
|
polygone
|
|
Reply #29 Posted on: December 23, 2010, 05:53:51 pm |
|
|
Location: England Joined: Mar 2009
Posts: 794
|
Isn't the whole event system already on a queue?
|
|
« Last Edit: December 23, 2010, 05:58:11 pm by polygone »
|
Logged
|
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
|
|
|
|