Pages: 1 2 [3]
  Print  
Author Topic: Some common GML issues, and dealing with them in Enigma?  (Read 4944 times)
Offline (Male) Josh @ Dreamland
Reply #30 Posted on: December 23, 2010, 09:39:45 PM

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

View Profile Email
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.
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 (Unknown gender) r9k
Reply #31 Posted on: December 24, 2010, 06:49:42 AM
Member
Joined: Aug 2010
Posts: 25

View Profile
I approve.
Logged
Offline (Male) polygone
Reply #32 Posted on: December 24, 2010, 06:51:21 AM

Contributor
Location: England
Joined: Mar 2009
Posts: 810

View Profile
As I said previously I think these statements will actually improve efficiency. Let's look at an example. Say you are making a platform game and you want to the game to save once automatically when the player's x reaches 300. Now this is the method I would normally use in GM:

Creation Event:
Code: (EDL) [Select]
saved = false;
save_dist = 300;

Step Event:
Code: (EDL) [Select]
if !(saved)
{
  if (x >= save_dis)
  {
    game_save();
    saved = true;
  }
}

And this is the method I would use with a when() statement:

Creation Event:
Code: (EDL) [Select]
var save_dist = 300;
when (x >= save_dist)
{
  game_save();
}

Using the when() statement there is no need for a saved variable check because once the when statement has been met it will be removed and not checked again. Thus the code will be more efficient both before and after the player reaches 300 because that extra 'saved' check is not needed. Note also the decrease in memory and the opportunity to use no extra local variables.

You can then go even further, imagine you want to add a save point from a key press instead of just the creation event. Easy to do with the when() statement but try doing it in GML, you have to add another variable and it's even messier.
« Last Edit: December 24, 2010, 09:46:35 AM by polygone » Logged
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
Offline (Unknown gender) r9k
Reply #33 Posted on: December 24, 2010, 06:57:53 AM
Member
Joined: Aug 2010
Posts: 25

View Profile
I would expect when() to run more than once.

Code: (EDL) [Select]
onceWhen(x >= 300)
game_save();
}
Logged
Offline (Male) polygone
Reply #34 Posted on: December 24, 2010, 07:10:54 AM

Contributor
Location: England
Joined: Mar 2009
Posts: 810

View Profile
I would expect it to only run once. I would expect something like whenever for running multiple times:

Code: (EDL) [Select]
whenever (x >= 300 && xprevious < 300)
{
  show_message("You crossed the 300 line!");
}
This would be just the same as adding an if check in the step statement though so is pretty pointless:

Code: (EDL) [Select]
step
{
  if (x >= 300 && xprevious < 300)
  {
    show_message("You crossed the 300 line!");
  }
}
« Last Edit: December 24, 2010, 09:44:37 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 #35 Posted on: December 24, 2010, 07:38:45 AM

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

View Profile Email
You seemed to expect when() to fire for each call when you called it in that script. Each when would have only one id, but there's an issue with that, anyway; neither x nor argument0 is a constant. We haven't specified any way of denoting that one of the parameters passed to when() is constant. So when that when() was called, the condition x > argument0 would be superimposed on the step event, and that check would be done each step verbatim.
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 #36 Posted on: December 24, 2010, 07:43:53 AM

Contributor
Location: England
Joined: Mar 2009
Posts: 810

View Profile
You seemed to expect when() to fire for each call when you called it in that script. Each when would have only one id, but there's an issue with that, anyway; neither x nor argument0 is a constant. We haven't specified any way of denoting that one of the parameters passed to when() is constant. So when that when() was called, the condition x > argument0 would be superimposed on the step event, and that check would be done each step verbatim.
Hmm I had not thought of that, I have edited it out of the examples so it is not an issue.

What syntax could be used be used to specify constants? You can define a variable local to a script for it to be constant, for example:

Code: (EDL) [Select]
var arg0 = argument0;
when (x >= arg0)
{
  game_save();
}
But it would be useful to have a way of defining constants.
« Last Edit: December 24, 2010, 09:49:01 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 #37 Posted on: December 24, 2010, 09:21:39 AM

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

View Profile Email
Not sure. We could just abuse the const keyword, like so:
Code: (EDL) [Select]
when (x >= const(argument0))
  game_save();
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 (Unknown gender) TheExDeus
Reply #38 Posted on: December 25, 2010, 11:17:19 AM

Developer
Joined: Apr 2008
Posts: 1919

View Profile
Quote
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.
I just meant drawing. As far as I know drawing is not queued, and thus using draw{} inside step event would cause problems with depth. That was all I was saying. Maybe I misunderstood something thou.
Logged
Offline (Male) Josh @ Dreamland
Reply #39 Posted on: December 25, 2010, 11:35:05 AM

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

View Profile Email
I don't see how. A function is a function....
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 (Unknown gender) TheExDeus
Reply #40 Posted on: December 25, 2010, 01:53:15 PM

Developer
Joined: Apr 2008
Posts: 1919

View Profile
Quote
I don't see how. A function is a function....
Well but isn't step before draw? And so if there is draw{} inside step, then wouldn't it draw in the wrong depth (below everything)? Well, but if its queued then ok. I just don't see where that queuing is happening, as I have only made some draw functions themselves and haven't checked any event code. I guess I will have to study the code some more. :) And how font loading from LGM is going?
Logged
Offline (Female) IsmAvatar
Reply #41 Posted on: December 25, 2010, 04:58:29 PM

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

View Profile Email
LGM passed font information to ENIGMA, and passes each glyph separately. Josh asked for a compression callback, so I provided one. Everyone was using font_load_from_sprite, which required each subimage be a separate glyph, so to alleviate the processs I added in sprite strip loading into LGM. At this point, LGM+Plugin does everything ever asked of it to make the font support easier, short of drawing the glyphs itself each draw event... the rest is Josh being too lazy to do anything about it, or to even bother finding out/reporting any problems with the stuff I provided him.

Edit: guy32123 was nice enough to report that populating the font glyphs sometimes somehow populates more than 255 glyphs, causing an ArrayIndexOutOfBoundsException. I'm investigating it right now and trying to reproduce it.

Edit2: I think I fixed that. Should be in for the next revision (r583).
« Last Edit: December 25, 2010, 05:59:42 PM by IsmAvatar » Logged
Offline (Male) RetroX
Reply #42 Posted on: December 30, 2010, 11:46:55 PM

Master of all things Linux
Contributor
Location: US
Joined: Apr 2008
Posts: 1055
MSN Messenger - classixretrox@gmail.com
View Profile Email
2. Referencing resources as strings

People often find themselves wanting to reference a resource index from it's corresponding string, being lazy they don't wish to map all the object indexes to strings manually, so is there a way this can be done easily in Enigma?
Haven't read the topic, but:

This will be nice, as it removes 90% of the use of execute_string().

Oftentimes, people do things like:
status = 'standing';
color = 'blue';
execute_string('sprite_index = player_' + color + '_' + status);
Logged
My Box: Phenom II 3.4GHz X4 | ASUS ATI RadeonHD 5770, 1GB GDDR5 RAM | 1x4GB DDR3 SRAM | Arch Linux, x86_64 (Cube) / Windows 7 x64 (Blob)
Quote from: Fede-lasse
Why do all the pro-Microsoft people have troll avatars? :(
Offline (Unknown gender) TheExDeus
Reply #43 Posted on: December 31, 2010, 05:15:52 AM

Developer
Joined: Apr 2008
Posts: 1919

View Profile
Quote
This will be nice, as it removes 90% of the use of execute_string().
I agree. That's actually the only reason why I use execute_string. Even thou GM can set variables using strings too, it doesn't allow creating them. It wouldn't change anything sprite_index case, but it would be nice if things like variable_create("int variable"), would create a variable. This is the reason why I still needed to use execute_string in one GM project, as it allows creating variables too. I had an alternative, but it would be harder to use, so...

edit: Though I don't know how this (even if this) would work in C++.
Logged
Offline (Male) RetroX
Reply #44 Posted on: December 31, 2010, 11:49:19 AM

Master of all things Linux
Contributor
Location: US
Joined: Apr 2008
Posts: 1055
MSN Messenger - classixretrox@gmail.com
View Profile Email
The only way that it would work in C++ is by creating a map of variables to strings.

map<var*, string> var_map;
var_map.find(variable_name);

Of course, I think that ENIGMA should have a separate resource and variable map, and have each disablable.  This also probably is how execute_string would pull variable/resource names.
« Last Edit: December 31, 2010, 12:02:17 PM by RetroX » Logged
My Box: Phenom II 3.4GHz X4 | ASUS ATI RadeonHD 5770, 1GB GDDR5 RAM | 1x4GB DDR3 SRAM | Arch Linux, x86_64 (Cube) / Windows 7 x64 (Blob)
Quote from: Fede-lasse
Why do all the pro-Microsoft people have troll avatars? :(
Pages: 1 2 [3]
  Print