OFFICIAL GMS 2.3.0 BETA ANNOUNCEMENT

Status
Not open for further replies.

gnysek

Member
it should be easy enough to see how it all holds together and how to modify existing sequences. ;)
For me it looks like reverse-engineering...

But from what I understand, to get Sequence track (of 1st level) you need to do something like:

GML:
function findSeqTrack(sequence_index, name) {
  var s = sequence_get(sequence_index);
  var tracks = array_length(s.tracks);
  for(var i = 0; i< tracks; i++) {
    if (s.tracks[i].name = name) {
      return s.tracks[i];
    }
  }
  return undefined;
}
Then probably keyframes[] and channels[] .
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
Don't know if its been brought up already but would be great to see this updated [or something similar] with the 2.3 changes: https://www.yoyogames.com/blog/63/best-practices-when-coding-in-gamemaker-studio-2
particularly, outlining whats faster than what with arrays/each DS type/structs, and efficient implementation of global/local/static/method variables and functions :)
It will be updated but not right away. The 2.3.0 release adds a lot of new features, but these features have not been fully optimised, as this release is concentrating on getting them all working and bug free (or as bug free as possible :p ). Internal optimisation will be a gradual process after the main release and when it's done and the dust has settled, then the article will be updated.
 

kburkhart84

Firehammer Games
Good to know that there's still space for noticeable improvement, I thought it's already at limit :)
Considering some people are reporting things like structs being slower than objects....its a good thing. I honestly haven't done any tests myself so don't get me wrong...just agreeing with the message.
 
FINALLY I get to play with 2.3!! I had another project to to finish first and it's just been sitting there on my drive with its tantalizing new features dangling in front of me like a carrot on a stick...absolute psychological torture!

Loving it so far, doing a bunch of tests of the rough code I was brainstorming earlier in this thread learning the ropes.

The manual updates look great but is it unbelievably slow for anyone else? I can't tell if it's just me and I don't want to file a bug report if it's just my internet or something (which doesn't make sense because the URL is the 127.0.0.1 stuff, doesn't that mean it's local?)

But literally it's legit like 20-30 seconds of watching those little squares flip around and things slowly pop in hoping that the thing I clicked on will load, even when I leave it open in my browser and just type searches in or click on stuff. One of the HUGE time-savers for learning was how fast it was to use the manual before, just instantly middle-click and boom the function I forgot some nuance of, right there in my face and I'm in & out and back to my code in 1/4 of the time it takes to even do a search or load something I clicked on in this new manual.

Is that just a "we'll speed this thing up when it's fully written and fully functional, be patient grasshopper" thing? I don't wanna sound like a complainer, this 2.3 thing is incredible so far lol but it's slow going to find my mistakes with the new features' syntax etc when it takes so long to get around the manual.. is there going to be a lightning-fast offline version? I don't care if it's 500GB or needs to be re-downloaded every week as its updated, I just want my fast workflow so I can pretend I know what I'm doing lol

Great work to the YoYo team! It's gonna take me all weekend just to try out all these new features, I've barely even scratched the surface!

(edit): bolded my question because I type too much lol
 

Fanatrick

Member
Good to know that there's still space for noticeable improvement, I thought it's already at limit :)
I'm very pleased with the beta, I really am. That being said, please don't give them ideas - this is way too slow. We got some language features which we paid for with 30% of speed. Gamemaker was always infamously garbage in terms of speed, imagine updating to make it run even worse... I hope that's unacceptable, otherwise I can see us howling at the moon for another decade's time until we're introduced to a "brand new" band-aid export called YYT(hreading) so we can finally start using 20+ year old tech natively in our 2030 pixel games :)
 

erayzesen

Member
I'm very pleased with the beta, I really am. That being said, please don't give them ideas - this is way too slow. We got some language features which we paid for with 30% of speed. Gamemaker was always infamously garbage in terms of speed, imagine updating to make it run even worse... I hope that's unacceptable, otherwise I can see us howling at the moon for another decade's time until we're introduced to a "brand new" band-aid export called YYT(hreading) so we can finally start using 20+ year old tech natively in our 2030 pixel games :)
I think, will be optimizations after this version. Because the new version have big changes and features. And sorry but I don't agree with you about game maker performance issue. I was using some game engines (unity,cocos2d-x..etc), even I writed a lite c++ game engine for my old project but game maker isn't bad against populer game engines. So I think, gms isn't great about performance issue but it's not bad too.
 
...does CTRL+T no longer go to the object in the Workspace like it used to??

It just takes me to an already open tab for one of its existing events, but I want to add another event to the object (or set it's visibility off or change its parent etc), that's why I'm CTRL+T'ing away from the tab windows to it in the first place lol


(edit): Nevermind! If you have the "Object double click opens all object events" option turned on in the Preferences/Asset Browser section, pressing Enter on an object in the CTRL+T search does that lol I turned that off and now it works as expected whew!
 
Last edited:

Gradius

Member
Yup, YYC performances on GMS2.3 are appalling: on a 50 pass test, I measured the real_fps during 5 seconds, after another 5 second wait to remove the executable start overhead... And here are my results :

2.2 YYC average: 1983.1707763672 real_fps
2.3 YYC average: 1047.6929931641 real_fps[/CODE]
You're using FPS not frame time, which is a absolutely terrible metric when you're talking about something running at thousands of FPS since it makes small differences look far more significant.

1983 fps = 0.504 ms per frame.
1047 fps = 0.955 ms per frame.
60 fps = 16.6 ms per frame!

That 0.35ms of additional processing time really isn't much. Though that's assuming it's a static cost to frame time, and not something that slows down code execution itself. So testing the difference under some kind of load would make sense.
 
3) Is there a way to indicate a variable is optional? Like:
GML:
function point(_necessary_var, [_optional_var]) constructor {
Answering my own question from a bunch of pages back for anyone else who wanted to know this, I just discovered from a post on reddit by @Juju that you can put a longer list of args above like this:
GML:
///@func Enemy(x, y, [hp], [strength], [is_friendly?], [weapon:melee/<blade>/magic], [etc])
function Enemy(_x, _y) constructor {
    x  = _x;
    y  = _y;
    hp = (argument_count > 1 ? argument[2] : 100);
    //etc...
}

//And the helper in the auto-complete and bottom of the window will show:
Enemy(x, y, [hp], [strength], [is_friendly?], [weapon:melee/<blade>/magic], [etc])
It's a nice short simple one-line way to indicate a bunch of extra optional variables with the new way functions are made. I haven't figured out a good consistent style guide for what brackets and symbols to use to indicate what but I find it helpful to be able to see [is_friendly?] and know that's an optional boolean or [weapon_type<weapons.?>] to remember it wants something in the weapons enum as an optional value, or to show a few options to choose between and indicate the default value etc

But here's the BIG discovery I wanna share with everyone: I'm using @FrostyCat's idea from a bunch of pages back but I figured out how to also use it for constructors:
GML:
//merge the _source struct into the _target struct and if any keys match, overwrite their value
function struct_merge(_target, _source) {
    var _Keys = variable_struct_get_names(_source),
        _i    = array_length(_Keys);

    repeat (_i) {
        var _key = _Keys[--_i],
            _val = variable_struct_get(_source, _key);

        variable_struct_set(_target, _key, _val);
    }

    return _target;
}

enum Weapon {MELEE, BLADE, MAGIC}

///@func Enemy(x, y, { hp | strength | is_friendly? | weapon })
function Enemy(_x, _y) constructor {
    x           = _x;
    y           = _y;
    hp          = 1;
    strength    = 1;
    is_friendly = false;
    weapon      = Weapon.MELEE;

    struct_merge(self, argument[2]);//2 is how many mandatory args are between the brackets in the "function Enemy(_x, _y) constructor {" line
}

//in the auto-complete and at the bottom you'll see this:
Enemy(x, y, { hp | strength | is_friendly? | weapon })
//and with no commas between the args inside the {} that section
//gets highlit all at once when you're typing which is nicer than if each
//has a comma because these can be entered in any order or left out etc

ogre = new Enemy(100, 100, {});//empty squiggly brackets means just use the default values
//{ x : 100, y : 100, hp : 1, strength : 1, is_friendly : 0, weapon : 0 }

skeleton = new Enemy(100, 100, {hp: 200, strength: 1, is_friendly: true, weapon: Weapon.MAGIC});
//{ x : 100, y : 100, hp : 200, strength : 1, is_friendly : 1, weapon : 2 }

//and it works even if you change the key order and/or leave some out! SERIOUSLY 💩💩💩💩ING COOL:
ninja = new Enemy(100, 100, {weapon: Weapon.BLADE, hp: 300});
//{ x : 100, y : 100, hp : 300, strength : 1, is_friendly : 0, weapon : 1 }
Also, to use the same struct_merge function but with a normal function that does something and just needs optional throw-away parameters inside it to calculate something you could do this kind of thing:
GML:
///@func draw_enemy(sprite, x, y, { subimg | x_scale | y_scale | h_flip: -1 or 1 | alpha })
function draw_enemy(_sprite, _x, _y) {
    //set defaults for the {optional arguments}:
    var _o = {
        subimg:  0,
        x_scale: 1,
        y_scale: 1
        h_flip:  1,
        alpha:   1
    };

    //3 mandatory args (_sprite, _x, _y) so the 4th (aka argument[3]) contains the {struct}
    struct_merge(_o, argument[3]);

    draw_sprite_ext(_sprite, _o.subimg, _x, _y, (_o.x_scale * _o.h_flip), _o.y_scale, 0, c_white, _o.alpha);
}

draw_enemy(spr_ogre, ogre.x, ogre.y, {});//just use the defaults
draw_enemy(spr_skeleton, ogre.x, ogre.y, {h_flip: -1});//only set necessary args
//and again you can set them in any order:
draw_enemy(spr_ghost, ogre.x, ogre.y, {alpha: 0.5, h_flip: -1, subimg: 5, y_scale: 3});
I am loving GMS2.3. I've been experimenting non-stop to figure out the best way to approach things using this stuff. I was on the fence about rewriting my game but there's no way I can't after seeing what GMS2.3 can do. I can tell just from my experimenting so far that the difference in my code quality is going to be like going from McDonald's to a 5 star restaurant lol incredible props to the YoYo team and their hard work on all this, I'm having so much fun just thinking of all the possibilities these new features have opened up! ...and I haven't even touched sequences yet!!

(edit): added the draw_enemy example to show a normal function VS a constructor...I think you could combine the two and put a "static draw = function() {" that uses the {optional arguments} squiggly brackets INSIDE the Enemy constructor so you could call like "ogre.draw(sprite_index, x, y, {h_flip: -1, y_scale: 2});" but I'm too tired to try it myself right now lol
 
Last edited:

Juju

Member
Some people use [optional], other people use optional*. In a few places you can see GM swap between the two as well. I'm not sure which is preferred, though some of my peers have suggested that square brackets could be misconstrued as indicating that an argument should be an array. I think has only become a potential issue due to array literals, but they have a point.

It's at times like these that I wish there was a proper style guide for GM, as many people have wished. I would suggest it should be in the official manual but Mark would do something weird with identation and curly brackets :p
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
I would suggest it should be in the official manual but Mark would do something wonderful and clear and easy to read with identation and curly brackets using the whitesmith style that everyone with an ounce of sanity uses.
Fixed it. ;)
 
though some of my peers have suggested that square brackets could be misconstrued as indicating that an argument should be an array.
I could see that being a problem for some people...I use a capital letter for my arrays so when I see an [Array] I know it's optional and an array! I'm making a little style guide for myself in my game's Notes section even though it's just me working on my game lol
It's at times like these that I wish there was a proper style guide for GM, as many people have wished. I would suggest it should be in the official manual but Mark would do something weird with identation and curly brackets :p
Not gonna lie when I saw this kind of thing in the manual:
GML:
function (_x, _y)
    {
    x = _x;
    y = _y;
    }
...I thought my browser messed up the formatting or something. I have never seen that particular bracket placement in my life lol
Answering my own question from a bunch of pages back for anyone else who wanted to know this, I just discovered from a post on reddit by @Juju that you can put a longer list of args above like this:
GML:
///@func Enemy(x, y, [hp], [strength], [is_friendly?], [weapon:melee/<blade>/magic], [etc])
function Enemy(_x, _y) constructor {
    x  = _x;
    y  = _y;
    hp = (argument_count > 1 ? argument[2] : 100);
    //etc...
}

//And the helper in the auto-complete and bottom of the window will show:
Enemy(x, y, [hp], [strength], [is_friendly?], [weapon:melee/<blade>/magic], [etc])
It's a nice short simple one-line way to indicate a bunch of extra optional variables with the new way functions are made. I haven't figured out a good consistent style guide for what brackets and symbols to use to indicate what but I find it helpful to be able to see [is_friendly?] and know that's an optional boolean or [weapon_type<weapons.?>] to remember it wants something in the weapons enum as an optional value, or to show a few options to choose between and indicate the default value etc
I just realized that you can "override" the default variables in-between the brackets with ///@func so even if you don't have extra arguments, you can do this:
GML:
///@func Enemy(_x, _y, [_alpha])
function Enemy(_x, _y, _alpha)

//and the helper will look like:
Enemy(_x, _y, [_alpha])
So you can just use ///@func to add brackets around optional ones. Sorry if this is already known behavior, I've only ever used ///@arg and didn't know why anyone used the others for anything but with the new function calls suddenly ///@func has all sorts of cool benefits! I am loving how clean this can all look, I hated having a huge vertical list of ///@arg's and then a bunch of var _alpha = argument[3]; stuff just to get STARTED on the actual code it's supposed to run.

In other news here's a fun little tidbit I used to use pragma stuff to do but now it can be done in one line:
GML:
function Main() constructor {
    static is_compiled = audio_play_sound(sfx_compile_done, 100, 0);
}

//obj_main Create Event
main = new Main();
Call that at the top of your first object's Create event and during late night coding sessions you can close your eyes while your game compiles and let whatever sound effect you put in there let you know when your game window finally pops up lol it won't play again when you reset the game or room because of that static magic

(edit): Answering another of my own questions for anyone who wanted to know lol:
Do you know off-hand if it's possible to get variables from outside the struct, like manipulating the image_alpha of whatever instance created the struct? The equivalent of "other." essentially. Or do you have to pass in whatever vars you need and return new versions of them?
"other." works exactly like I was hoping :)
GML:
x = 300;
var _struct = {
    x: 100,
    do_something: function() {x += other.x;}
}
show_message(_struct.x);//100
_struct.do_something();
show_message(_struct.x);//300
Don't even need a with()!!
 
Last edited:
R

rinkuhero

Guest
nice (this comment is being made just to keep my account active since i got an email saying my account will be deleted if i don't use it at least once a year)
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
Sorry Noc, but I've literally only seen that style in the GM manual... So maybe you're the only sane coder I had contact with?
You young whippersnappers just don't know enough about life yet to appreciate the beauty of whitesmiths... it really is the great-granddaddy of indentations, designed for the great-granddaddy of compilers way back in the late 70's


PS: Be thankful I'm not this madman!
 
Last edited:

TheMagician

Member
Two questions on the current state of the Beta:

1) Source Control
Can people who use GMS with source control share their opinion on the improvements in the new Beta?

2) Custom Particle Engine
I need to write a custom particle engine for my next project and I would like to know which system you guys would use for storing the particle information: arrays, ds or structs?
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
Can people who use GMS with source control share their opinion on the improvements in the new Beta?
Yes, absolutely. A lot of the changes to the Asset Browser and the file formats for storing assets were done specifically to make SC easier.

I need to write a custom particle engine for my next project and I would like to know which system you guys would use for storing the particle information: arrays, ds or structs?
In the future, almost certainly you'd want to use structs. However they are not entirely optimised right now (they will be gradually improved as we see use cases and improve the internal pipeline and GC, etc...), so arrays would be the fastest option for storing and accessing data right now I think.
 

Yal

🐧 *penguin noises*
GMC Elder
I need to write a custom particle engine for my next project and I would like to know which system you guys would use for storing the particle information: arrays, ds or structs?
You're aware there's a built-in particle system framework that lets you create custom particles, right?
 

Fanatrick

Member
You're aware there's a built-in particle system framework that lets you create custom particles, right?
You're aware he explicitly mentioned "custom particle engine", right? There are couple of issues with the native one, mainly lack of control when it comes to drawing/manipulating vertices of the part_system (inside a shader or writing to a scalable surface).
 

Yal

🐧 *penguin noises*
GMC Elder
You're aware he explicitly mentioned "custom particle engine", right? There are couple of issues with the native one, mainly lack of control when it comes to drawing/manipulating vertices of the part_system (inside a shader or writing to a scalable surface).
There's a pretty big span of "custom particle system" between effect_create_* and sending raw vertex data into a shader, and I was just worried about them jumping into the deep end too soon.
 
See the manual for the different contents of the sequence structs. If it is an instance of the sequence that is in the room, then you need to access the sequence instance struct (see here), getting the "activeTracks" array. If it is the sequence asset (object) itself, then you need to access the "tracks" array in the object struct (see here). Regardless of how you access the tracks, they will also be structs and their contents are explained here.


The manual has complete information over multiple pages that explain the different structs that comprise a sequence asset along with each of their properties (see some of the links in this reply). There is also an example of how to create a sequence struct from scratch on this page, and from that it should be easy enough to see how it all holds together and how to modify existing sequences. ;)
For the love of god is there an offline version of the manual??? This thing is SO unbelievably slow...it takes legitimately 30 seconds of watching the squares flip around to load a page and half the time it doesn't even load the page for the thing I middle-clicked on, it just goes to the Getting Started page, or it literally just never loads anything and stays flipping those tiles eternally!

It's such a valuable resource in trying to learn how to use these new features but it's honestly practically completely unusable! The old manual was instant, you just middle-clicked and boom you were at the help page for what you needed and were back to your code in seconds.

I tried to make do but I just can't with how slow and cumbersome and half-broken this thing is ahhhhh!!

It's going to http://127.0.0.1:51290/index.htm#t=blahblah is it supposed to point to the website or something to go faster? I just want to be able to check how to do something in less than 2 min of waiting and ending up on the wrong page and having to reload and watching it hang and then having to reload again etc just to check one tiny thing about how to use static or a constructor lol
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
The version you are using is the offline version if that's the URL. The manual no longer loads in the IDE but in the default browser for the user (the IDE loading was very flaky and this is much more stable). The initial load might take a moment, but it shouldn't be taking as long as you're saying, and if it is then you should mention it in the Beta Forums on the helpdesk so it can be looked at.

PS: You may find it slow, but it's not "half broken"!!! Functionally, it's a massive improvement over the old manual....
 
The version you are using is the offline version if that's the URL. The manual no longer loads in the IDE but in the default browser for the user (the IDE loading was very flaky and this is much more stable). The initial load might take a moment, but it shouldn't be taking as long as you're saying, and if it is then you should mention it in the Beta Forums on the helpdesk so it can be looked at.

PS: You may find it slow, but it's not "half broken"!!! Functionally, it's a massive improvement over the old manual....
Don't get me wrong, it's an amazing manual and I'm not trying to discount the hard work that went into it, but I just recorded a video to show you what's happening. speedtest.net clocks me at 12ms ping, 128Mbps download, 10Mbps upload and no other sites are running slow so it's not my connection lol:

- I closed GM2.3 and re-started it and created a brand new project with just a script & room in it​
- first I middle-click on static and after 18 seconds the help finally loads...but it shows the Getting Started section instead of static?? This happens often enough that it happened on my first try recording lol
- then I type static into the search bar of that page and after it loads I click on Method Variables and it loads properly, yay!​
- then without closing that browser window, I go back to my code and middle-click on show_debug_message and after 15 seconds it shows show_debug_message
- then I type in function into the search bar and after it loads the seach I click on Function Call and spend a full minute watching those grey boxes flip around
- when I'm selecting the txt I accidentally click on Compiler Output Window lol (you can see the URL at the top change) but regardless it takes another 30 seconds waiting for it to finally show that (ignore my "WTF" text, I didn't realize I hit Output Window that time lol and the first one still loaded the Getting Started page instead of static)​
- I click Function Call again (you can see the URL change at the top) and it gets stuck loading for infinity (I stopped the recording after like 40 seconds)
The worst is the infinite loading, because when it takes 30 seconds for a normal page to load that means I have to wait 30 seconds before I know if it's even stuck, and then I have to try reloading or reopening it and wait another 30+ seconds to see if THAT gets stuck (it happens multiple times in a row sometimes) and it's like now I'm 2+ minutes into just trying to quickly check the syntax for using static lol

I just middle-clicked constructor in my code and got taken to the index.html again, so bare minimum "static" and "constructor" middle-click to the index.html instead of their page it looks like, if that helps...maybe it's just not linked up properly for some keywords?

The old manual didn't have as many features but you just middle-click a keyword and INSTANTLY you're looking at the definition and sample code to refer to and were immediately back into coding again. That quick in and out to the necessary page was such a HUGE help for self-teaching because any time I didn't remember what to do I could instantly check the reference and learn fast.

With the current state of this thing I'm trying to avoid even opening it, and dreading when I start learning the sequences stuff where I know I'm going to have to check the manual a ton because it's totally new stuff :( Is it possible for there to be like a "lite" version of the manual that just instantly goes from what you middle-clicked to the page relevant to it and that's it, without loading all the stuff that's making it take forever to get to?

(edit): I've got a C:\Program Files\GameMaker Studio 2-Beta\RoboHelp\YoYoStudioRoboHelp.zip file, is that supposed to be unzipped or something? Maybe it's unzipping this thing every time I open help? lol

(edit2): oh 💩💩💩💩 lol I unzipped that to another directory and opened the HTML file in it in my browser and it's lightning fast...the search is still a little slow but once I've got the list of search results I can click them and INSTANTLY see the page's content! I'mma just keep this thing open in a browser for now...although it means I can't use middle-click which was a huge time saver, but I'll take that over the 30s load times for now lol

Would it be possible to add an option in the Preferences/Help/ to choose a local directory for the manual but with a big red letter warning that it won't get auto-updated while that option is selected or something? Or is that a hassle on YoYo's end lol
 
Last edited:

gnysek

Member
Would it be possible to add an option in the Preferences/Help/ to choose a local directory for the manual but with a big red letter warning that it won't get auto-updated while that option is selected or something? Or is that a hassle on YoYo's end lol
Some Javascripts won't work when URL points to disc instead of http(s) protocol. That's the same as with HTML5 games. However... maybe unzipping it on first use and leaving in that form for faster load in future would be good idea? Also, I noticed that after restarting IDE help can't be used until opened for first time (even if still left in browser). Cause of that I'm rather using https://manual.yoyogames.com now.
 
A

Arconious

Guest
Don't get me wrong, it's an amazing manual and I'm not trying to discount the hard work that went into it, but I just recorded a video to show you what's happening. speedtest.net clocks me at 12ms ping, 128Mbps download, 10Mbps upload and no other sites are running slow so it's not my connection lol:
I think Nocturne was trying to indicate to you that GM 2.3 already by default uses a locally hosted version of the manual. From your video, it's connecting to "127.0.0.1", which is essentially an address that points to your own computer. The online manual is at: https://manual.yoyogames.com/

Regardless, as your video shows, something funky is going on as it shouldn't be taking that long to load. I tested on my machine and found it be very quick, with only noticeable lag on the initial load. As a minor aside, I did find that it continually opened a new tab instead of addressing the already active tab/window with the manual.
 
Last edited by a moderator:
However... maybe unzipping it on first use and leaving in that form for faster load in future would be good idea?
I assumed this is how it would work, maybe it's supposed to unzip and for some reason didn't? I tried unzipping it inside that directory but it doesn't do anything.
I think Nocturne was trying to indicate to you that GM 2.3 already by default uses a locally hosted version of the manual. From your video, it's connecting to "127.0.0.1", which is essentially an address that points to your own computer. The online manual is at: https://manual.yoyogames.com/
That's why I don't understand why it's so slow...I can unzip the help files and just drag the directory into my browser and it's blazing fast, literally instant loading for everything I click on whether I've opened it before or not. Shouldn't it just work as beautiful as this does?
Regardless, as your video shows, something funky is going on as it shouldn't be taking that long to load.
I have no idea what could be going on...it seems like it should either both (through 127.0.0.1 and file:///) be slow, or both be fast lol it's frustrating that I can see it run perfectly lightning fast when I go to it via file:/// but through the IDE I have to use the super slow version to do middle-clicking lol

For now I'm just going to keep the file:/// address for the unzipped manual in my browser and type in what I need to find, that'll be faster than staring at the flipping squares for 2 min lol
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
This is definitely something that needs looking into, but for that you need to post in the official beta forums on the helpdesk (you can find the link in the first post in this topic). If you could simply copy paste your posts here into a new thread on the beta forum, I'd really appreicate it. That way the QA team and devs will look at it, as this forum is purely for the community to use.
 
This is definitely something that needs looking into, but for that you need to post in the official beta forums on the helpdesk (you can find the link in the first post in this topic). If you could simply copy paste your posts here into a new thread on the beta forum, I'd really appreicate it. That way the QA team and devs will look at it, as this forum is purely for the community to use.
Sure no problem! I wasn't sure where exactly to report this kind of thing lol the manual is fantastic outside of this, don't take this as me hating on all your hard work! :D

...although that Whitesmiths bracket style makes me uncomfortable...unsettling, like watching the kid tricycling down the hallways in The Shining..........lol
 
Last edited:

Mick

Member
I have no idea what could be going on...it seems like it should either both (through 127.0.0.1 and file:///) be slow, or both be fast lol it's frustrating that I can see it run perfectly lightning fast when I go to it via file:/// but through the IDE I have to use the super slow version to do middle-clicking lol
I suspect an antivirus program could be the reason for the slow help, try disabling it or exclude the location of the help files.
 

TheMagician

Member
Yes, absolutely. A lot of the changes to the Asset Browser and the file formats for storing assets were done specifically to make SC easier.
Thanks for the info. I think I had already gathered as much. Was just wondering what people, who have used the previous versions of source control with GMS, think about these changes. From Yoyo's side it has often sounded like source control has been properly implemented now, only to be revised again later ;)

In the future, almost certainly you'd want to use structs. However they are not entirely optimised right now (they will be gradually improved as we see use cases and improve the internal pipeline and GC, etc...), so arrays would be the fastest option for storing and accessing data right now I think.
Thank you! I've started an implementation where I use structs for the emitters and a 2D array for the actual particles. That seems like a good compromise for now.
 

gnysek

Member
I can confirm that after opening manual from IDE, it loads in 1-2 seconds, then next page need about 5-6 seconds to load, then every next loads in less than 1s, so I've also got some wierd issues, will try to look into it during weekend and report it (or add my two cents to existing topic on beta forum).
 
D

Deleted member 45063

Guest
Thanks for the info. I think I had already gathered as much. Was just wondering what people, who have used the previous versions of source control with GMS, think about these changes. From Yoyo's side it has often sounded like source control has been properly implemented now, only to be revised again later ;)
I never used the source control options from the IDE itself, I always use Git in the CLI, but I can say the new project file format is much simpler to work with. You can reason about it quite simply, which comes a long way if you do have merge conflicts (which by itself the format already reduces the occurrences of by a lot).
 

Cpaz

Member
Source Control
Can people who use GMS with source control share their opinion on the improvements in the new Beta?
I guess to sort of give my two cents on source control, so long as you are working on one branch only, and understand that you'll have to redo all other work that hasn't been merged in yet, then you should be golden.

So TLDR: should be as simple as:
New branch - > update to 2.3 - > merge with master.
Any extra steps in between, and you'll likely run into some trouble.

EDIT: Forgot to mention that this also applies to the asset browser. Don't change the folder structure immediately, because you'll likely end up with a weird duplicate folders.
When you do get around to messing with the asset browser, someone has made a tool to fix this. I'll need to find it and share it.
 
Last edited:

TheMagician

Member
When you do get around to messing with the asset browser, someone has made a tool to fix this. I'll need to find it and share it.
Are you saying that you need to use this tool whenever you restructure your assets in the browser or just when upgrading from a 2.2 to a 2.3 project?
 

Cpaz

Member
Are you saying that you need to use this tool whenever you restructure your assets in the browser or just when upgrading from a 2.2 to a 2.3 project?
It isn't necessary. But on the odd occasion, you'll end up with duplicate folders that'll keep reappearing when you re-load a project.
They don't break anything (at least, from what I've seen) but they do clutter things up.
But yes, you should only have to use it once.
 

gnysek

Member
Just copy your 2.2 project somewhere and remove everything except (hidden) .git directory from copy. Now convert original project to 2.3 and don't save it over any of two directories (it will be a third directory then). Now copy 2.3 into empty 2.2 (the one with .git only). All should be OK without duplicates now.

If something goes wrong there's still original folder (in fact you still have it on remote repository too).

Edit: if you saved project under different name, then you need to edit main .yy file to fix it after copying over.
 
Last edited:

kburkhart84

Firehammer Games
@Nocturne This detail isn't specific to version 2.3, but since you are updating the manual, now is a good time.

In the page about gamepads, specifically with the constants, I think some details should be specified. For example, it mentions button constants for the analog shoulder buttons on XBOX gamepads. It assumes that you know that these count on buttons, despite that though physically they are buttons, they function more like axes supplying a value between 0 and 1 based on how far down it is pressed. I don't disagree if they want to continue counting them as buttons(despite the analog nature of them), however, I think there should be some clarification about this point in there somewhere.

Another thought..it is discussed that XInput and DInput work differently(and even about 0 - 3 being XInput, etc....). However, I think there should be some more detail about there not being any actual correct constants for axes and buttons for DInput devices. I'm sure the XInput constants would work(they seem to just be value 0 - X), but they won't match up with the actual inputs on the device. I don't expect them to(there are no standards with DInput gamepads/devices anyway). So I think it could be explained to simply use integers for those function calls and be done with it(that's what my input system is doing).
 

Yal

🐧 *penguin noises*
GMC Elder
@Nocturne This detail isn't specific to version 2.3, but since you are updating the manual, now is a good time.

In the page about gamepads, specifically with the constants, I think some details should be specified. For example, it mentions button constants for the analog shoulder buttons on XBOX gamepads. It assumes that you know that these count on buttons, despite that though physically they are buttons, they function more like axes supplying a value between 0 and 1 based on how far down it is pressed. I don't disagree if they want to continue counting them as buttons(despite the analog nature of them), however, I think there should be some clarification about this point in there somewhere.

Another thought..it is discussed that XInput and DInput work differently(and even about 0 - 3 being XInput, etc....). However, I think there should be some more detail about there not being any actual correct constants for axes and buttons for DInput devices. I'm sure the XInput constants would work(they seem to just be value 0 - X), but they won't match up with the actual inputs on the device. I don't expect them to(there are no standards with DInput gamepads/devices anyway). So I think it could be explained to simply use integers for those function calls and be done with it(that's what my input system is doing).
I had a bunch of issues with gamepad support on Linux (which appear to be due to GM platform-to-platform inconsistencies - I've filed a bug report on my findings), so I learned a lot about how gamepads work under the hood:
  • The analog shoulder button constants can be supplied when checking for axial inputs to read them analogously, or with the button-reading function to get a simple on/off value. (On systems without xInput support (or on a non-xInput controller that pretends to be an xbox controller), pressing the analog triggers might give you control stick inputs).
  • The 0-3 / 4-11 thing is windows-specific, you get and use the raw device ID without abstractions. The async events that fire on gamepad connect/disconnect may give you an ID outside this range (on my Linux computer, gamepads started at id 20) so ideally your code should be range-agnostic. (This should be clarified in the manual). On anything non-Windows it seems like everything is treated as a DInput device (i.e. constants might not match), and as you might've noticed, on mobile ports 0 is unused.
  • The button constants' values start at like 32600, not 0. Drawing the number directly to signify the button (hoping to get something like "button 3") just looks ugly.
  • Using axes 0 and 1 for the movement stick seems to be fairly universal, but anything above that can be completely arbitrary.
  • GM seem to capture most "hats" (d-pads) as axial inputs. You won't get actual analog data from it, but you don't need to have two sets of logic for D-pads and axes.
 

kburkhart84

Firehammer Games
@Nocturne I believe there is a pretty big error with the Gamepad section of the manual, specifically on "hats." It states that the second argument is for the index of the hat(which means DInput devices would support more than one POV hat). There is also a function for checking how many hats the device has, so this correlates there.

However....
Note that these can be combined (for example, supplying a hat index of 3 would be checking up and right) but only at most 2 bits can be pressed at once. The function will return a real value between 0 and 1, where 0 is not pressed and 1 is fully pressed (and there may be values in between depending on whether the gamepad supports analog input for hats).
This part says that you supply the bit mask to the hatindex argument...which would mean you don't support multiple hats, and the function can return a value between 0 and 1 if the POV hat is actually analog.

Then....
var _dir = gamepad_hat_value(global.PadIndex, 0);
switch (_dir)
{
case 1: y -= 3; break;
case 2: x += 3; break;
case 3: y -= 3; x += 3; break;
case 4: x -= 3; break;
case 6: y += 3; x += 3; break;
case 8: y += 3; break;
case 9: y -= 3; x -= 3; break;
case 12: y += 3; x -= 3; break;
}
But...the above code example shows you using hatIndex the first way I describe, to say which hat it is(not a bitMask for the direction). And then the return of the function would seem to be the bitmask itself...meaning you would only be able to get digital values from it, like shown in the example, and not be able to get values between 0 and 1.

So....which is it? Are we supporting multiple hats for each DInput gamepad? Or are we supporting analog values for only 1 device?

I hate to be such a bother...but the input system is basically not well done(except if you are only using XInput). It isn't just the documentation of course, it is also the idea of what we discussed before, what Yal mentioned above about Linux, etc... All platforms should work pretty much the same at least in a general sense, and Linux giving us devices over 20 is simply not this. They should work where those indices get broken down to 4 - 11 since they aren't XInput specific devices.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
@kburkhart84 File a bug report about it and I'll get it all looked at. I can't comment further as I haven't really explored all the possibilities and have simply documented things as I was told to.
 

kburkhart84

Firehammer Games
@kburkhart84 File a bug report about it and I'll get it all looked at. I can't comment further as I haven't really explored all the possibilities and have simply documented things as I was told to.
Will do.

EDIT****

Report added here. I also included a bit of what Yal was discussing above about the indices...and I added about clarifying the documentation on how the shoulder triggers of XInput devices work as axes but use the "button" version of the gamepad functions.
 
Last edited:

kburkhart84

Firehammer Games
Just FYI, upon testing the function...it DOES indeed return the bitmask...so it seems that the example part and the syntax part of the doc page is correct, but the first section and the part about it returning analog( axis 0 - 1 values) would be wrong.
 

Yal

🐧 *penguin noises*
GMC Elder
Will do.

EDIT****

Report added here. I also included a bit of what Yal was discussing above about the indices...and I added about clarifying the documentation on how the shoulder triggers of XInput devices work as axes but use the "button" version of the gamepad functions.
Just for the record, my bug report on the Linux inconsistencies (which were from the current latest 2.2 stable release) has ticket number 173118. Figured I should share that since kburkhart linked to their report so it's got a chance to get on the being-looked-at train.
 
Do you guys have a problem with particles not showing up? This was a problem I have in 2.2 and is still problem in 2.3 One way I fixed this is to run on admin and make a new copy of the game but the problem keeps reoccurring. I wish it could just work, no running on admin, no making a new copy. This problem seems to only happen with the windows and not html5 (I've only tested both)

Also, the web version seems to be working better now but the animations don't work. If I manually change the image_index, the sprite does change but if I let it automatically change using image_speed, nothing happens. Also, my sfx are working but the bgm is not.
 
Last edited:

Yal

🐧 *penguin noises*
GMC Elder
Do you guys have a problem with particles not showing up? This was a problem I have in 2.2 and is still problem in 2.3 One way I fixed this is to run on admin and make a new copy of the game but the problem keeps reoccurring. I wish it could just work, no running on admin, no making a new copy. This problem seems to only happen with the windows and not html5 (I've only tested both)
What's the depth of the particle system? Anything outside the range +/- 16,000 will have undefined sorting relative to each other, so it might e.g. end up behind the background layer. If you carry over GMS1 code to define it (where 1,000,000 was the default depth for tile layers so most people stuck to depths in that range) it's more likely than not that you're giving your particle systems depths in that range. (There's a new function to place a particle system on a particular layer, too, but if you're like me and have one or two global particle systems that stick around between rooms, it might get annoying to reassign it in every room)
 
Status
Not open for further replies.
Top