Pages: 1 [2] 3
  Print  
Author Topic: Some common GML issues, and dealing with them in Enigma?  (Read 5089 times)
Offline (Male) polygone
Reply #15 Posted on: December 22, 2010, 07:11:58 PM

Contributor
Location: England
Joined: Mar 2009
Posts: 809

View Profile
Quote
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.

Quote
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.

Quote
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.
Offline (Male) Josh @ Dreamland
Reply #16 Posted on: December 22, 2010, 08:05:57 PM

Prince of all Goldfish
Developer
Location: Ohio, United States
Joined: Feb 2008
Posts: 2946

View Profile Email
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
Offline (Male) polygone
Reply #17 Posted on: December 22, 2010, 08:28:38 PM

Contributor
Location: England
Joined: Mar 2009
Posts: 809

View Profile
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:

Code: (EDL) [Select]
draw
{
  draw_text(x, y, "Yo");  //this would draw the text "Yo" from now on
}
OR

Code: (EDL) [Select]
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 ...

Quote
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.
Offline (Male) polygone
Reply #18 Posted on: December 22, 2010, 08:55:12 PM

Contributor
Location: England
Joined: Mar 2009
Posts: 809

View Profile
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:

Code: (EDL) [Select]
var message_end = current_step +  4*room_speed;
draw
{
  draw_text(x, y, "some text");
}
until (current_step == message_end)

Code: (EDL) [Select]
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.
Offline (Male) Josh @ Dreamland
Reply #19 Posted on: December 22, 2010, 09:13:02 PM

Prince of all Goldfish
Developer
Location: Ohio, United States
Joined: Feb 2008
Posts: 2946

View Profile Email
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
Offline (Male) polygone
Reply #20 Posted on: December 22, 2010, 09:24:06 PM

Contributor
Location: England
Joined: Mar 2009
Posts: 809

View Profile
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 :)

Quote
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.
Offline (Female) IsmAvatar
Reply #21 Posted on: December 22, 2010, 09:36:45 PM

LateralGM Developer
LGM Developer
Location: Pennsylvania/USA
Joined: Apr 2008
Posts: 891

View Profile Email
Careful with how you name them. 'draw' is a common variable name that people use to determine whether something will draw or not. 'step' is usually an incremental variable, sometimes used to indicate how many 'steps' a character has walked. I wouldn't expect people to use them as script names, though, so draw() and step() would be safe, as long as they are distinguished from their non-parenthesized namesake.
Logged
Offline (Unknown gender) luiscubal
Reply #22 Posted on: December 23, 2010, 11:43:18 AM
Member
Joined: Jun 2009
Posts: 452

View Profile Email
There are edge cases that need to be solved.
For instance, is draw{} drawn BEFORE or AFTER the draw event contents?

Also, in
Code: (EDL) [Select]
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
Offline (Male) polygone
Reply #23 Posted on: December 23, 2010, 12:11:47 PM

Contributor
Location: England
Joined: Mar 2009
Posts: 809

View Profile
Quote
For instance, is draw{} drawn BEFORE or AFTER the draw event contents?
After would make more sense to me.

Quote
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.

Quote
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.
Offline (Unknown gender) luiscubal
Reply #24 Posted on: December 23, 2010, 01:28:39 PM
Member
Joined: Jun 2009
Posts: 452

View Profile Email
If you have multiple draw{}until(); statements, in which order are they executed.

Also, regarding performance, I think I misread the way "when" works.
Logged
Offline (Male) polygone
Reply #25 Posted on: December 23, 2010, 01:46:54 PM

Contributor
Location: England
Joined: Mar 2009
Posts: 809

View Profile
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.
Offline (Unknown gender) TheExDeus
Reply #26 Posted on: December 23, 2010, 05:10:43 PM

Developer
Joined: Apr 2008
Posts: 1914

View Profile
There is reason why GM can draw only in draw event you know... For example, if object1 has depth=0, and another object2 has depth=2. So the first object1 draw event is executed before the second one and thus draws on top of the other. Now what happens when object1 draws in step event? It will draw below the object2 even thou it should draw on top. This can be fixed with some kind of queue, but that seems just like another way to lose memory and speed. Thou Josh can prove me wrong and get this done for the next rev, so I can snuff my coke in amazement.
Logged
Offline (Male) polygone
Reply #27 Posted on: December 23, 2010, 05:15:02 PM

Contributor
Location: England
Joined: Mar 2009
Posts: 809

View Profile
Quote
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.
Offline (Unknown gender) TheExDeus
Reply #28 Posted on: December 23, 2010, 05:43:46 PM

Developer
Joined: Apr 2008
Posts: 1914

View Profile
Well queues need memory (in best case a vector that can autoresizes) and speed, well, because it just needs all this. Maybe the impact wouldn't be that big, but who knows.

I agree about the timer thing, and it would kick ass. But the draw{} thing just seems very problematic. Maybe Josh came up with some biblical idea that will blow our minds, but will see.
Logged
Offline (Male) polygone
Reply #29 Posted on: December 23, 2010, 05:53:51 PM

Contributor
Location: England
Joined: Mar 2009
Posts: 809

View Profile
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.
Pages: 1 [2] 3
  Print