• Hey! Guest! The 39th GMC Jam will take place between November 26th, 12:00 UTC and November 30th, 12:00 UTC. Why not join in! Click here to find out more!
  • Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

OFFICIAL GMS2 Version 2.3.1 (Beta Release)

Status
Not open for further replies.

chirpy

Member
Thanks @chirpy ! It seems some variation of what you described was not fixed in this 2.3.1 build. I ended up removing the "App Delegate Class Name" that was specified in the Extension and then everything worked, including the functionality of the extension which I thought might stop working because I had cleared that field naming the App Delgate code!

I updated my ticket with YoYo, so hopefully they can have a look at it and sort it out. At this point, I have no idea what that field is for on the extension since being there doesn't seem to be required.
AppDelegate is usually for detecting app lifecycle events, the OS sends different signals when the game is launched/paused/resumed. The extension may work if it does not have to initialize right after the game launches, but depending on what methods are defined in the class, things may go wrong when app is paused/resumed.

Replacing everything that's trying to check whether the superclass responds [*] to said lifecycle signal should make the chaining work as intended.

[*] We need to replace all
[self superclass] instancesRespondToSelector
in app delegate classes (.mm files) with
[${YYExtAppDelegateBaseClass} class] instancesRespondToSelector
And then, build from GMS2 again to regenerate the .xcodeproj (so GMS replaces the ${} variables)
 

FrostyCat

Member
AppDelegate is usually for detecting app lifecycle events, the OS sends different signals when the game is launched/paused/resumed. The extension may work if it does not have to initialize right after the game launches, but depending on what methods are defined in the class, things may go wrong when app is paused/resumed.

Replacing everything that's trying to check whether the superclass responds [*] to said lifecycle signal should make the chaining work as intended.

[*] We need to replace all
[self superclass] instancesRespondToSelector
in app delegate classes (.mm files) with
[${YYExtAppDelegateBaseClass} class] instancesRespondToSelector
And then, build from GMS2 again to regenerate the .xcodeproj (so GMS replaces the ${} variables)
I genuinely appreciate this kind of detailed investigation. It is a welcome break from the superficial "help i got an error" nonsense I have to put up with on the Q&A sections.

Users with experience in the native language on each export platform are an important part of shaping GM's future in extensions, and also key to holding YoYo accountable to the product we paid for.
 

clee2005

Member
AppDelegate is usually for detecting app lifecycle events, the OS sends different signals when the game is launched/paused/resumed. The extension may work if it does not have to initialize right after the game launches, but depending on what methods are defined in the class, things may go wrong when app is paused/resumed.

Replacing everything that's trying to check whether the superclass responds [*] to said lifecycle signal should make the chaining work as intended.

[*] We need to replace all
[self superclass] instancesRespondToSelector
in app delegate classes (.mm files) with
[${YYExtAppDelegateBaseClass} class] instancesRespondToSelector
And then, build from GMS2 again to regenerate the .xcodeproj (so GMS replaces the ${} variables)
Oh so the problem was actually because of the iOS_IAPs extension which contained the [self class] instancesRespondToSelector code (and you are suggesting to update that with the code above)? The extension that I was questioning (the one that when removed, or when the App Delegate Class Name field was cleared, allowed the IAPs to function) has no such code ([self class] instancesRespondToSelector), but it did specify it's AppDelegate class in the App Delegate Class Name field (see image) so GMS was tying it together with the other AppDelegate classes and causing the conflict?

I checked ant the iOS_InAppPurchaseAppDelegate.mm is the only file in all my extensions that uses [self superclass]. It's also the only one that names it's AppDelegate Class Name in the exension editor (.yy file).

1603277850024.png
Just to be very clear about the field I'm talking about.

Thanks so much for your assistance in this. What you're saying makes a lot of sense, and I'm going to go and do more testing to ensure the functionality does indeed continue to work after pausing and resuming, as it definitely does after initial app startup.
 

clee2005

Member
@Dan I just found something that seems very serious. In our games we have large integers which are now getting encoded in json as 1.234567e + 06 instead of 1234567 for example. This wouldn't be a problem on it's own, except if you take that same value and decode it back to a map then it doesn't translate to the same number! Instead of 1234567 you get 1234570!

GML:
var userid = 1234567;

map = ds_map_create();
map[? "userid"] = userid;

var s = json_encode(map);

show_message("Json encoded : " + s);

newmap = json_decode(s)

show_message("After decoding : " + string(newmap[? "userid"]));
 

Yal

🐧 *penguin noises*
GMC Elder
@Dan I just found something that seems very serious. In our games we have large integers which are now getting encoded in json as 1.234567e + 06 instead of 1234567 for example. This wouldn't be a problem on it's own, except if you take that same value and decode it back to a map then it doesn't translate to the same number! Instead of 1234567 you get 1234570!

GML:
var userid = 1234567;

map = ds_map_create();
map[? "userid"] = userid;

var s = json_encode(map);

show_message("Json encoded : " + s);

newmap = json_decode(s)

show_message("After decoding : " + string(newmap[? "userid"]));
To quote the first post:
However, this does not replace our normal bug reporting system and you should report all bugs as normal using https://accounts.yoyogames.com/contact-us
This seems pretty serious so you probably should report this through the normal bug form as well, to get as many eyes as possible on it.
 

clee2005

Member
To quote the first post:


This seems pretty serious so you probably should report this through the normal bug form as well, to get as many eyes as possible on it.
Yes I did log a ticket before this posting. With a test project as well. Hopefully it gets looked quickly.
 
1) yes, only ds_xxx and loaded resources like sprites will cause issues
2) not sure if big_struct = undefined does same as delete big_struct, but yep, all should be GC at some point (not immediately and not all at same time)
3) yes, they created weak reference functions in 2.3.1 (it returns address to struct, but doesn't count as reference for GC), so you can check if and when something is GC collected.

You can also flush things manually.
Awesome thanks! I'm so used to having to clean up a bunch of ds_* stuff that it feels like it can't possibly be as simple as just setting a variable to undefined to clean up literally an entire GUI so I wanted to make sure I'm doing this right from the start lol I'm loving using structs and constructors for everything, it all feels so much cleaner
 

Ricoh5A22

Member
After the last update (IDE 211 / Runtime 209) my game started to show this artifact:

1603406277596.png

It is a black line that cross vertically or horizontally the whole background, but only when the camera moves. It takes about 1 frame and appears in random location of the screen. Its appearance looks related to the tiled background, an 64x64 image tiled horizontally and vertically, because the black line location is where the tiles connects. And when I replaced the image by a solid color in the background layer, the artifact stopped to show.
 
Last edited:

clee2005

Member
The new runtime 209 has introduced something new for me as well. This is supposed to be a single pixel scaled to be the GUI width and GUI height and displayed on the GUI layer. It should cover the entire screen in solid white, and did before this new beta.


Screenshot_20201022-194547.png

Kind of a neat effect really, but not what I was going for.
 

FrostyCat

Member
After the last update (IDE 211 / Runtime 209) my game started to show this artifact:

View attachment 35217

It is a black line that cross vertically or horizontally the whole background, but only when the camera moves. It takes about 1 frame and appears in random location of the screen. Its appearance looks related to the tiled background, an 64x64 image tiled horizontally and vertically, because the black line location is where the tiles connects. And when I replaced the image by a solid color in the background layer, the artifact stopped to show.
The cause of this kind of tile gapping is well-documented (YoYo blog entry), and is not unique to Runtime 23.1.1.209.
The new runtime 209 has introduced something new for me as well. This is supposed to be a single pixel scaled to be the GUI width and GUI height and displayed on the GUI layer. It should cover the entire screen in solid white, and did before this new beta.


View attachment 35218

Kind of a neat effect really, but not what I was going for.
Then just draw a rectangle instead of a stretched sprite. Sprites are prone to UV roundoff errors, basic shapes aren't.
 

kroart

Member
The new runtime 209 has introduced something new for me as well. This is supposed to be a single pixel scaled to be the GUI width and GUI height and displayed on the GUI layer. It should cover the entire screen in solid white, and did before this new beta.


View attachment 35218

Kind of a neat effect really, but not what I was going for.
Have the same thing. It's also a scaled single pixel.
photo_2020-10-23_13-33-28.jpg
 

Plura

Member
In the new runtime v23.1.1.209, we discovered several issues.
Some issues are about how things are drawn and others have a problem with ds_grid_read and ds_grid_write.
We need more time to investigate this unexpected behavior.
With v23.1.1.187 everything works fine.
 

clee2005

Member
Then just draw a rectangle instead of a stretched sprite. Sprites are prone to UV roundoff errors, basic shapes aren't.
Thanks @FrostyCat that's a good work around. Since this is new to this runtime I thought it'd be worth noting as it's possibly affecting some other functionality, unless it's been purposefully changed and undocumented so far.
 

Plura

Member
We found a bug with the gpu_set_texfilter() function in v23.1.1.209!
When scaling a sprite while gpu_set_texfilter is enabled the sprite is not correctly drawn.
It becomes a gradient variant of a non-gradient sprite.
When gpu_set_texfilter is disabled then everything is correctly drawn.
It shouldn't be drawn like this it must be a bug!
Please see the image:
gpu_set_texfilter_bug.png
 
Last edited:

Yal

🐧 *penguin noises*
GMC Elder
The sprite / single pixel gradients looks like they're caused by the GPU interpolating the texture with its surroundings (which are transparent). Plura's comparison on drawing with/without texture filtering seems to confirm this.

Does it work if you change the sprite's setting to have horizontal and vertical tiling both turned on? Normally you'd only turn these on for backgrounds (to avoid these literal edge cases) but I'm thinking it would help for these stretched sprite effects as well (turning these options on adds a border around the sprite on the texture page to make sure neighboring texels are matching up with the ones inside the sprite, preventing interpolating artefacts).
 

clee2005

Member
Does it work if you change the sprite's setting to have horizontal and vertical tiling both turned on? Normally you'd only turn these on for backgrounds (to avoid these literal edge cases) but I'm thinking it would help for these stretched sprite effects as well (turning these options on adds a border around the sprite on the texture page to make sure neighboring texels are matching up with the ones inside the sprite, preventing interpolating artefacts).
I tried that but it did not make any difference. I did try changing the gpu_set_texfilter(false) before drawing as @Plura mentioned and that fixed it.
 
Beta 2 now released - IDE 211, Runtime 209

Changes are called-out separately in the release notes and there have been quite a lot of fixes since beta 1, so please review the tops of https://gms.yoyogames.com/ReleaseNotes-NuBeta.html and https://gms.yoyogames.com/release-notes-runtime-NuBeta.html for specifics.
I see the Chrome url_open bug is now fixed (https://forum.yoyogames.com/index.php?threads/url_open-function-behaving-oddly.79934/)

@Dan Since you guys found out what was causing this issue, is there any current workaround for the stable version? (except installing an extension)
 

PamiKA

Member
Im excited to find out that now I can compile 64bit. I wonder if I can do games for raspberry pi with this. I could build up my own arcade box finally. lol me just dreaming big ... ^^'
 

clee2005

Member
I'm not having any fun with this new beta. lol ds_grid_read no longer seems to work. I've filed a ticket.

GML:
var grid = ds_grid_create(2,2);
grid[# 0,0] = 1;
grid[# 0,1] = 2;
grid[# 1,0] = 3;
grid[# 1,1] = 4;

var s = ds_grid_write(grid)

var newgrid = ds_grid_create(2,2);
ds_grid_read(newgrid,s);

// Nothing in the grid.
show_debug_message(string(newgrid[# 0,0]) + string(newgrid[# 0,1]) + string(newgrid[# 1,0]) + string(newgrid[# 1,1]) )
The above code, should show 1234 but instead shows 0000
 

Tornado

Member
So ds_grid_read is totally broken, we know that now.

I was curious what was changed in the format of ds_grid_write:
Code:
GMS 2.2.5.481/378 and 23.1.1.193/187:
"5A020000040000000300000000000000000000000000000000000000000000000000F03F00000000000000000000F03F00000000000000000000000000000000000000000000F03F00000000000000000000F03F00000000000000000000F03F00000000000000000000F03F00000000000000000000F03F00000000000000000000F03F00000000000000000000F03F00000000000000000000F03F"

GMS 23.1.1.211/209:
"5B020000040000000300000000000000000000000000000000000000000000000000F03F00000000000000000000F03F00000000000000000000000000000000000000000000F03F00000000000000000000F03F00000000000000000000F03F00000000000000000000F03F00000000000000000000F03F00000000000000000000F03F00000000000000000000F03F00000000000000000000F03F"
Only second character was changed from "A" to "B" !!!
 

chamaeleon

Member
Only second character was changed from "A" to "B" !!!
A version change in the encoding, I would suspect. My guess is GMS uses the first byte (or two, I have no idea and no strong interest in knowing the details, I tend to stay away from these functions) to determine how to parse the rest of the content in an attempt to maintain backwards compatibility with older encoded strings while allowing for new items to be serialized (or serious bugfixes).
 

Tornado

Member
Unfortunately, we use it on one place and saving some important info into user's ini :-( ARGHHHH!!!
It is old piece of code. I'll see to get rid of that piece of dirt as soon as possible, but will have to write some migration code for it in the next app release.
Hopefully Yoyo will fix this soon properly. I guess then we will have to use legacy flag "true" for ds_grid_read to be able to read it out and do one time conversion to something else for every user.
 

clee2005

Member
From the 209 Runtime release notes :

Note: The fix mentioned above for ds_list_read() is actually that 2.3.0 should have written out a different string formatting version number along with the changes to formatting when writing out any data structure as a string (lists/maps/queues, etc.). Therefore, whilst strings from 2.2.5 and older will be read correctly in 2.3.1, strings from 2.3.0 builds will not - you will unfortunately need to use 2.3.0 to read your data now and then re-save the string using 2.3.1/this beta.
I'm concerned about this. What happens if you had released updates to your users built with 2.3.0 and then you go to release an update built with 2.3.1? You have no way of reading in the game data saved on the users device? I realize this is a bug, and it shouldn't have been like this in the first place, but YoYo would need to provide a means to read in the incorrectly formatted data that was saved on a non-beta version of the GMS2 platform. Temporary function, or workaround code.

Now the ds_grid is broken from perhaps something related. I'm worried that this same issue could occur again. This would be from a beta so it's easily justified I suppose. Perhaps I'm misunderstanding something.
 

Tornado

Member
I guess practically noone could have released anything with 2.3.0 as it was a complete desaster.
Honestly if I could I would take two days and go back to 2.2.5 right away and redo all our commits from the last 30+ days manually into 2.2.5 SVN-Branch.
But we can't because of new Android 11 and iOS 14.
They should have released a stable 2.2.x release for Android 11 and iOS 14 first and then "play" with all this new GML language stuff and GC.
Now we users have to work extra shifts (besides our own tasks) to research and report broken stuff. Users who have mobile apps in production are stuck right now.
Until 2.2.5 we were very pleased how GMS2 became stable and mature (respect to yoyo for that), but I'm totally confused what the heck is going on right now! It is a real mystery for us.
Sorry, I just needed to let it out.

Let's hope soon we will have a stable version. I saw Yoyo is fixing the bugs very fast.
 
Last edited:

clee2005

Member
I guess practically noone could have released anything with 2.3.0 as it was a complete desaster.
Honestly if I could I would take two days and go back to 2.2.5 right away and redo all our commits from the last 30+ days manually into 2.2.5 SVN-Branch.
But we can't because of new Android 11 and iOS 14.
They should have released a stable 2.2.x release for Android 11 and iOS 14 first and then "play" with all this new GML language stuff and GC.
Now we users have to work extra shifts (besides our own tasks) to research and report broken stuff. Users who have apps in production are stuck right now.
Until 2.2.5 we were very pleased how GMS2 became stable and mature (respect to yoyo for that), but I'm totally confused what the heck is going rigt now! It is a real mystery for us.
Sorry, I just needed to let it out.

Let's hope soon we will have a stable version. I saw Yoyo is fixing the bugs very fast.
I'm with you my friend 100%. I am in EXACTLY the same boat. In fact, I was glad to read that you are struggling with the same consideration of rolling back completely to 2.2.5 but are stuck with the Android 11 and iOS 14 requirements. I've been trying to work out the best path as well, and it seems that might be to just make 2.3.1 work. I'm completely nervous about that now in light of this new beta (ds_grid broken, and ds_list_read broken in 2.3.1). These are fundamental pieces of GMS2 that aren't easily worked around without a lot of re-writing.

I still think I might go back to 2.2.5 anyway, because this is all beta stuff which can change at any moment. It's too dangerous to base any future direction (ie. making changes to accommodate broken functionality). Hopefully, YoYo sees the importance of the mobile exports being supported sooner than later.
 

chamaeleon

Member
It cannot possibly be a good idea to rely on a serialization format for external storage that is completely unknown to the developer as to its definition, or due to breaking changes are introduced by mistake or necessity. If every release had a documented serialization format for each data structure, it would be different, but it doesn't at the moment (not saying someone can't reverse engineer it, but that might go against the license anyway).

Hopefully none of you relying on these serialization functions store references to other data structures in their fields, only primitive data types like strings and numbers (and structs, I suppose, if it is/gets implemented properly). I doubt the json marker is taken into account for maps and lists when it comes to the read/write functions.
 

Tornado

Member
Talking about ds_grid, I already admitted it was bad idea to use ds_grid. This one piece of code is like 6 years old, created before my time. I indeed saw this code at some point, but never took time to replace it.
Now we have an app with it in production and I should kick myself in the nuts for not replacing it at that time. :bash:
;)
 

clee2005

Member
Talking about ds_grid, I already admitted it was bad idea to use ds_grid. This one piece of code is like 6 years old, created before my time. I indeed saw this code at some point, but never took time to replace it.
Now we have an app with it in production and I should kick myself in the nuts for not replacing it at that time. :bash:
;)
LOL.... but I don't really understand why is it bad to use ds_grid? Perhaps you are just unhappy with THAT piece of old code in your game, and I get that. If that's not it, I'm wondering why you would be against ds_grid (minus the issue that we are currently seeing).

Edit : @chamaeleon Ok, I now see your point about the ds_grid_write being a proprietary format and not a great idea ultimately if anything should happen and we were required to change game engines.
 
Last edited:

Tornado

Member
LOL.... but I don't really understand why is it bad to use ds_grid? Perhaps you are just unhappy with THAT piece of old code in your game, and I get that. If that's not it, I'm wondering why you would be against ds_grid (minus the issue that we are currently seeing).
It is not bad "per se", nor it is our fault that it broke now. And it worked for us without problems almost 7 years!!!
But like @chamaeleon pointed out we made ourselves dependant on some proprietary encoding for which we don't have algorithm.
We have this string saved in INI file on thousands of users' mobile devices. :-( That is the stupid thing now! Once it becomes unstable like now, as soon as it is fixed and it works again I'll see to replace it with more robust mechanism and change it in INI files of all users in the next release of our game. For this to work we have to read it out again correctly from INI file. So we can just hope that the flag "legacy" will work in ds_grid_read once the bugs are fixed.
 

Samuel Venable

Time Killer
The cause of this kind of tile gapping is well-documented (YoYo blog entry), and is not unique to Runtime 23.1.1.209.

Then just draw a rectangle instead of a stretched sprite. Sprites are prone to UV roundoff errors, basic shapes aren't.
Though it may be documented, I still would call that a bug, and the documentation being an excuse to not fix it even though it is a known issue. I could be wrong, but I'm very certain this is something that only happens to begin with because of something YoYo programmed badly, and I haven't witnessed any other game engines that have this problem at all, or the very least not to the god-awful extent GM has it.

I'm just glad they provide workarounds. I'll be sticking with gamemaker and other engines i work with as long as all these tools provide workarounds to their problems, I don't really care if certain bugs ever get fixed at this rate. Other engines have their unique problems all the same so it's not a GM exclusive issue when looked at in a more broad sense.

While these things may be pretty bad, i think we could stand to see the big picture in that no engine is perfect. A lot of people are happy about the new feaures and other are really pissed by the regressions but things that go wrong we don't expect are a part of life. If we are willing to adapt our code and assets to work around these things is a life skill worth getting used to when you have a deadline for releasing a game especially.

I'm still trying to get used to that myself when e.g. Apple makes API changes every year deprecating and breaking perfectly good code even ones as stupid as renaming a function or constant without changing implementation at all, it may be annoying but sometimes we need to just live with it. A lot of people at my dad's work stopped using Macs in the workplace because a ton of software they rely on stops working almost every year they are afraid to update to the latest OS (sound familiar?)
 
Last edited:

Yal

🐧 *penguin noises*
GMC Elder
Now we just need array_shuffle and ds_lists will be completely redundant 🦈
 

Dan

YoYo Games Staff
YYG Staff
Beta 3: (26/10/2020) IDE 214, Runtime 212 now released.

A much smaller release to just "hotfix" a couple of the issues found in Beta 2. No change in the IDE and runtime is just the following:
  • In-Game: Attached project shows a single-pixel sprite being scaled on the GUI is no longer drawing correctly in 2.3.1 Beta 2
  • In-Game: [YYC] draw_sprite_ext() no longer functions correctly in 2.3.1 Beta 2
  • In-Game: ds_grid_read() and ds_map_read() are not working correctly in 2.3.1 Beta 2
  • There is also a fix for some unwanted truncating of x/y values to be ints when running on YYC, which you may have seen as moving sprites "jittering" in Beta 2
 

clee2005

Member
Beta 3: (26/10/2020) IDE 214, Runtime 212 now released.

A much smaller release to just "hotfix" a couple of the issues found in Beta 2. No change in the IDE and runtime is just the following:
  • In-Game: Attached project shows a single-pixel sprite being scaled on the GUI is no longer drawing correctly in 2.3.1 Beta 2
  • In-Game: [YYC] draw_sprite_ext() no longer functions correctly in 2.3.1 Beta 2
  • In-Game: ds_grid_read() and ds_map_read() are not working correctly in 2.3.1 Beta 2
  • There is also a fix for some unwanted truncating of x/y values to be ints when running on YYC, which you may have seen as moving sprites "jittering" in Beta 2
Fast turn around on that! Thanks guys!
 

kupo15

Member
Now we just need array_shuffle and ds_lists will be completely redundant 🦈
I find it amusing how years ago it was all like "arrays are ehh..ds_lists all day long, use those instead" and now its like "arrays are better don't use ds lists" lol I still see the use for ds_lists, just feels "cleaner" to me? Unless I'm missing something. Also can you save out to json using arrays?
 

Ricoh5A22

Member
After the last update (IDE 211 / Runtime 209) my game started to show this artifact:

View attachment 35217

It is a black line that cross vertically or horizontally the whole background, but only when the camera moves. It takes about 1 frame and appears in random location of the screen. Its appearance looks related to the tiled background, an 64x64 image tiled horizontally and vertically, because the black line location is where the tiles connects. And when I replaced the image by a solid color in the background layer, the artifact stopped to show.
Despite not being listed in the release notes, after this update (23.1.1.212) the problem that I mentioned above didn't happen anymore.
 
This hotfix update and the last one both give me "Error opening file for writing: C:\blahblah\MiniDumpUploader.exe Click Abort to stop the installation, Retry to try again or Ignore to skip this file" and hitting Retry just pops the same error back up immediately.

Both times I just leave it like that for like 5-10 minutes doing literally nothing else and then hit Retry again and it suddenly works fine and installs properly. If it's downloading a file or something it might be good for it to indicate that because a lot of newbies might assume something is broken and abort or skip that file which I'm guessing from the name is probably an important one lol
 
Status
Not open for further replies.
Top