OFFICIAL 2023.200 Beta Releases Thread

[Dan]

This topic is for the discussion of issues relating to this update of GameMaker. However, this does not replace our normal bug reporting system and you should report all bugs as normal using https://contact.gamemaker.io/contact-us

As ever, PLEASE check the Required SDKs FAQ before/during updating and ensure your antivirus/OS permissions are correct by checking User Permissions and Internet Access Required by GameMaker before you submit any bug reports or post issues here.

You should post here if:

• Something has changed between the previous version and this one, breaking your game (i.e.: code that worked previously now does not)
• Something reported as fixed in the release notes is not actually fixed
• You are having IDE or system issues related to something new in this update
• You are having issues with new features introduced in this version
• You are having issues updating to this version
• Everything works and you want to tell us we are great (seriously, let us know if it all works correctly for you)

When reporting issues to the Helpdesk, please try to add as much information as possible, for example:

• If the issue is with the IDE, then please give a screenshot if you can to help illustrate the problem and always attach the "ui.log" file found via the "Open Log in ..." Help menu command inside GameMaker
• If it is a code issue, then link to or attach a YYZ showing the most basic project possible which exhibits the behaviour
• If it is a system issue (like compiling to a specific target or running on a device) then please always include the compiler log we ask for (it's genuinely very important!) and provide details of the machine being used as well as the software versions involved

Again: posting a comment in these release threads is not a replacement for filing a bug!

IDE Release Notes

Runtime Release Notes


Current Release - IDE v2023.200.0.281 Runtime v2023.200.0.298 (Feb 10, 2023)

Be aware that because this release introduces the entirely new Particle asset type which older IDEs and runtimes have no knowledge of, if you open or create any project in this new release it will not be editable in older GameMaker versions and so will open in those older IDEs in read-only mode! (If you have added any particles into the project, then it will advise the project cannot be loaded and you will be returned to the Start Page.)

The 2023.200 betas bring support for a new particle editor inside the IDE; free users can now create and edit filter layers in rooms, plus manage audio and texture groups; and also that you can now use the majority of the GameMaker IDE without even needing to log in. There are also a number of Feather performance and/or memory leak fixes which should stop IDE slowdown over time and also very high RAM spikes in some cases.

We have also changed Create Exe to always build the package, regardless of if a supported device is connected, and then stop once the file has been created - we have added a new "Create and Launch" command for when you actually want the game to deploy and launch on a device like GameMaker always has in the past.

On the runtimes side, there are new features for audio loop points and so that JavaScript extensions can inject into the game’s .html file; support for various newer external SDKs/tools on different platforms; and important FPS fixes for Android and mobile devices with higher refresh rate screens.


Please be aware there will be a delay before the Beta manual is updated with all this new content.

 

[Dan]

This one is a fairly early look at some of the new features for this month, so please bear that in mind.

As mentioned above, please read the release notes carefully before deciding to update, and at this time be aware that the Particle Editor is still in-progress - do not create any assets you want to use long-term, as the upcoming changes mean you will need to recreate any particles using the next Beta (or any releases after that). Just have a look at the new functionality for now.

There are a number of project save/load and file watcher fixes in this release which we want to release as a small-but-important .1 update to Jan23 early next week if the feedback on this Beta is good.

We are aware of/bugs are already filed that:

• The Preferences for Xbox are blank
• Logging-out and back in again in this IDE can cause session errors for your other IDE installs (you just need to log in again there also, but I wanted to mention it)
• Logging-out and back in again can also cause a slight delay before some menubar items (such as the Marketplace menu) become enabled or your Start Page recent items list will appear
• HTML5 does not run/create exe because the index.html file is in the wrong place
• Android Studio support changes for Electric Eel are not all done yet, so you will continue to get the "missing ADB" error if you have already updated your Android Studio (this has been documented in the Required SDKs FAQ for a little bit)
• We have seen the surface format "surface_rgba4unorm" causing problems with some Nvidia GPUs
• Sequences which contain a sound longer than the animation track cause an "Emitter does not exist" error when closing the game

 

[RefresherTowel]

Other Bugs Fixed
In-Game: [YYC] instanceof() incorrectly always returns "Object" in Jan23

Hoorah! I can finally stress test in YYC again!

 

[Deleted member 84743]

posted this on 2023.1 thread about the groupbug:

i tested the "group duplicate bug" and i can not reproduce it on 2023.1.1.62 or 2023.200.0.281.
i am 99% sure it is fixed.

and i opened a "group corrupted" project on both of those versions, and the corrupted project was fixed automatically, so if someone has got their project broken by the groupbug, it will be fixed if they open the project on 2023.1.1.62 or 2023.200.0.281 version.

thank you very much, good work!

all these new features, this beta is the best one so far, thank you very much!
it is now so easy to start using GameMaker, anyone can try it in 5minutes, just install and make a game, no need for registering or anything, i love it

 

[8BitWarrior]

I'm here to mention sadness with get_string() and get_integer() going away. They were used until the very end. *Sad Music*

Other than that, appreciate the update! But still sad.

 

[Deleted member 84743]

i had a problem on older GameMaker version image editor, the first click was not registered by ide sometimes, but on this version it seems to work, atleast i have not got that bug in this version so far

can someone test the display_reset bug on this beta and give feedback if it is fixed?

 

[FoxyOfJungle]

OMG, new surface formats????? I'm dreaming???

Thank you so much

 

[Deleted member 84743]

I'm here to mention sadness with get_string() and get_integer() going away.

get_string_async and get_integer_async can probably replace those functions.
if you dont want them to be "async" add a check for user input before continuing to next stage on script

 

[Xor]

Surface formats! Particle Editor! Epic!

 

[Luvexian]

There is still a Android FPS bug. I think It has not been properly fixed.
I tested it on my phone : Samsung Galaxy S22+ / Galaxy tab S7+ / Galaxy A50.

My phone samsung galaxy S22 + and Galaxy tab S7+ can switch screen refresh rate between 60 Hz and 120 Hz.
When I set it to 60Hz, 30 fps goes up to 40 fps.
When I set it to 120Hz, 30 fps goes up to 34 fps.
And Galaxy A50, with only 60Hz screen refresh rate option, 30 fps goes up to 40 fps.

So, you can see that at 60 Hz, 30 fps goes up to 40 fps, at 120 Hz, 30 fps goes up to 34 fps.

I think the problem seems to be with display timing method 'tm_countvsyncs'.
Why do I think so?
Because that the default display timing method is 'tm_countvsyncs' (display_get_timing_method() shows it is 'tm_countvsyncs'),
but If you write display_set_timing_method(tm_sleep) at the app start, everything is OK. 30FPS is 30FPS at any Hz.

If you write nothing, default display timing method is 'tm_countvsyncs', so Android FPS bug happens.
But strangely, at this default 'tm_countvsyncs' mode, refreshing app screen fixes wrong fps to 30 fps correctly. (You can refresh app screen by leaving the app screen and returning to it.)
Refreshing app screen doesn't switch 'tm_countvsyncs' to 'tm_sleep' because display_get_timing_method() shows it is still 'tm_countvsyncs',
I don't know why, but anyway, the wrong fps returned to 30fps correctly by refreshing app screen at 'tm_countvsyncs' mode.

I think nothing changed about this bug without that at screen refresh rate 120Hz, 30 fps goes up to 34 fps. In the previous version, it goes up to 40 fps like 60Hz.
i don't know much but as I wrote above, according to my tests, I think the problem is not about devices with higher refresh rate screens, but about the default display timing method 'tm_countvsyncs'.
Because even a device with only 60hz screen refresh rate option have this bug and writing display_set_timing_method(tm_sleep) solved this FPS bug.

I don't know if this 'tm_sleep' has any side effects or if I can continue to use it, but I haven't found any problems yet.
The important thing is display timing method 'tm_sleep' is not default option, so users will use 'tm_countvsyncs' by default option.
I hope the problem is solved next time, thank you.

 

[kburkhart84]

I see the new looping functions for the audio. The manual seems to not have those yet. Will the looping functions allow for you to have the sound start from the beginning and then once it passes into the looping points then loop as it should from there? I ask because the release notes just mention looping and turning off looping but not doing a sort of intro into the looping points first.

If that is not a thing, I highly recommend that it does get made into a thing. It would make the workaround in my audio system no longer be necessary.

 

[fujj]

Will the looping functions allow for you to have the sound start from the beginning and then once it passes into the looping points then loop as it should from there?

Yes, then while looping you can toggle the loop section and have it play an outro if you wish.

On another note, there is a bug with looping in this version. If passing in an asset index to audio_sound_loop_start/end, then you should make sure that you have called audio_sound_length on the asset at least once beforehand. This will be fixed in a future beta.

 

[Gradius]

> You can now add a loop start and end point into your playing sounds, then perform the loop as many times as you wish - turning the loop on and off as required

A great feature. Wav files can have loop points embedded too (though it's not technically standard), so it'd be neat if GM detected these and applied them as a default. Though I suppose it's a relatively niche feature these days.

> surface_rgba32float

Looks like meat's back on the menu, boys. I recall their being a method for order-independant transparency that required float format buffers for the maths to work correctly so now there's the possibility that'll actually work in GM. Which would be great for 3D projects. We can also now have lighting systems with correct HDR behaviour (as well as ways to avoid colour banding), which will look nicer.

Edit: Got a very flakey but technically functional transparency shader working now. Need to get a weighting algorithm that actually plays well with the depth values I'm feeding it though. Now to see if I can get some nice HDR from lighting.

> Removed the type-checking functions is_vec3(), is_vec4() and is_matrix()

Fair. Disappointed that they didn't get implemented (yet?) though. Vector maths is such a crucial part of gamedev that it feels increasingly odd that we can do fluid sims out of the box, but have to do our own vector maths functions (this made sense when GM was very learning-focused, but less so as it's been more indie/indie studio focused).

 

[kburkhart84]

Yes, then while looping you can toggle the loop section and have it play an outro if you wish.

On another note, there is a bug with looping in this version. If passing in an asset index to audio_sound_loop_start/end, then you should make sure that you have called audio_sound_length on the asset at least once beforehand. This will be fixed in a future beta.

So will it be able to to just automatically do the looping part after the intro or will we have to manually turn on the looping part some time after(meaning we will have to check if the song is past the intro)?

 

[fujj]

So will it be able to to just automatically do the looping part after the intro or will we have to manually turn on the looping part some time after(meaning we will have to check if the song is past the intro)?

The loop argument you choose when you play a sound will determine the initial state of the loop section.

The loop section state determines what happens when playback reaches the loop-end:

• Enabled - playback jumps back to the loop-start.
• Disabled - playback continues from the loop-end.

 

[kburkhart84]

The loop argument you choose when you play a sound will determine the initial state of the loop section.

The loop section state determines what happens when playback reaches the loop-end:

• Enabled - playback jumps back to the loop-start.
• Disabled - playback continues from the loop-end.

OK, so I could start at the beginning, enable the loop, and it would continue the intro, enter the loop, and then proceed to loop? Since the manual isn't live with these things I couldn't check before asking here.

 

[fujj]

OK, so I could start at the beginning, enable the loop, and it would continue the intro, enter the loop, and then proceed to loop? Since the manual isn't live with these things I couldn't check before asking here.

That is correct - maybe a code example will be helpful:

/* This just works around a bug in this beta version */
audio_sound_length(snd_1);

/* Set the loop bounds on the asset */
audio_sound_loop_start(snd_1, 5.0); // In seconds
audio_sound_loop_end(snd_1, 10.0);

/* Play the sound
 * Note that the 'loop' argument sets the initial state of the loop section.
 * Loop bounds are pulled down from the asset.
 */
var _idx = audio_play_sound(snd_1, 0, true);

/* Expected behaviour:
 * Sound plays from the beginning.
 * Once playback reaches the loop end (10.0s), jump back to the loop start (5.0).
 * This will continue indefinitely.
 */

/* If I wish to disable looping during playback I can call this */
// audio_sound_loop(_idx, false);

/* New expected behaviour:
 * Sound plays from its current playback position to the end of the asset
 * Playback ends.
 */

 

[kburkhart84]

That is correct - maybe a code example will be helpful:

/* This just works around a bug in this beta version */
audio_sound_length(snd_1);

/* Set the loop bounds on the asset */
audio_sound_loop_start(snd_1, 5.0); // In seconds
audio_sound_loop_end(snd_1, 10.0);

/* Play the sound
* Note that the 'loop' argument sets the initial state of the loop section.
* Loop bounds are pulled down from the asset.
*/
var _idx = audio_play_sound(snd_1, 0, true);

/* Expected behaviour:
* Sound plays from the beginning.
* Once playback reaches the loop end (10.0s), jump back to the loop start (5.0).
* This will continue indefinitely.
*/

/* If I wish to disable looping during playback I can call this */
// audio_sound_loop(_idx, false);

/* New expected behaviour:
* Sound plays from its current playback position to the end of the asset
* Playback ends.
*/

Thanks for the confirmation. That behavior will replace what my audio system has to do a workaround for at the moment. I'll be able to skip that now with this beta. Now hopefully they implement my suggestion of allowing non-emitter sounds to play on any selected bus instead of only the main bus.

 

[TheMagician]

I have to say the new Particle Editor is exactly what I hoped it would be. Who thought that it could be fun an easy to design intricate particle setups

Also want to say Thank You for listening to seemingly small feedback like my wish that the Template Filter on the Start Page remembers its state or the additions to the Download Area on gamemaker.io.

Great to see that you have opened the Filter and Effect layers for free users. Students love to apply quick filters to drastically alter the appearance of a scene.

Have filed two small bug reports - one possibly connected to the new way that mouse clicks are detected in the IDE.

 

[Slyddar]

The particle editor works well, and it's nice to have a smooth workflow for adding particles. Initial thoughts though are using tab is the quickest way to edit the values in the inspector, but
1/ tabbing to the next setting does not work as it gets stuck on the title label of the next section
2/ tabbing should really only move to the value boxes, as it serves no purpose to tab to the small incremental arrows. Those small incremental arrows are next to useless, considering all they do is move the value by a full integer, since most of the changes when working with particles are 0.001 increments.

Also when I added a particle system for the first time there were no controls, and I couldn't work out how to edit them. Only when I went to a room, which always forces opens the inspector, and returned to the particle window, did I see the inspector and was able to edit the particle. It might seem obvious, but it was confusing for a first time user. Maybe it needs to be like the room, where you force the inspector to open when entering the particle editor.

Also to manually create the particles that have been created in the editor, as opposed to dragging them in the room, I assume we can just use part_emitter_stream or part_particles_create as per normal. The default values are :
particle system is "ParticleSystem1"
emitter is "Emitter"
part_type is ??

I don't see the part type value anywhere though, so how do we create the particles manually?

 

[FoxyOfJungle]

The particle editor works well, and it's nice to have a smooth workflow for adding particles. Initial thoughts though are using tab is the quickest way to edit the values in the inspector, but
1/ tabbing to the next setting does not work as it gets stuck on the title label of the next section
2/ tabbing should really only move to the value boxes, as it serves no purpose to tab to the small incremental arrows. Those small incremental arrows are next to useless, considering all they do is move the value by a full integer, since most of the changes when working with particles are 0.001 increments.

Also when I added a particle system for the first time there were no controls, and I couldn't work out how to edit them. Only when I went to a room, which always forces opens the inspector, and returned to the particle window, did I see the inspector and was able to edit the particle. It might seem obvious, but it was confusing for a first time user. Maybe it needs to be like the room, where you force the inspector to open when entering the particle editor.

Also to manually create the particles that have been created in the editor, as opposed to dragging them in the room, I assume we can just use part_emitter_stream or part_particles_create as per normal. The default values are :
particle system is "ParticleSystem1"
emitter is "Emitter"
part_type is ??

I don't see the part type value anywhere though, so how do we create the particles manually?

Basically the particle system is the same, which means that what has changed is that now is possible to create the particle through the IDE.

Then you can create the particle by referencing the asset:

// Create event:
global.pt_system = part_system_create();

// Step event:
if mouse_check_button_pressed(mb_left) {
  part_particles_create(global.pt_system, mouse_x, mouse_y, ParticleSystem1, 10);
}

ParticleSystem1 is the asset in the Resource Tree.

This still requires a system, which is returned with part_system_create() - which is great as it works the same way, except we don't have to write a bunch of code just to guess what an effect looks like.

Note that it is also possible to modify the existing asset on the fly:

if mouse_check_button(mb_left) {
    part_type_direction(ParticleSystem1, 270, 270, 0, 0);
    part_particles_create(global.pt_system, mouse_x, mouse_y, ParticleSystem1, 10);
}

There's something interesting to note: You can actually drag the particle asset into the room, using the Asset Layer:

https://twitter.com/i/web/status/1624140540026429440

When you do this, the particle asset will automatically use the emitter you create in the IDE:

The Emitter is basically an area where particles will spawn.

It's possible to scale them inside the Room too, but they distort lol

Note that when creating particles manually, the Emitter is disregarded.

You can also disable the particle emitter if not used:

--------------------------------------------------

I would like to suggest changing the asset's default name from ParticleSystem1 to ParticleType1. It is confusing to read the name system, as they are different things.

 

[Slyddar]

I would like to suggest changing the asset's default name from ParticleSystem1 to ParticleType1. It is confusing to read the name system, as they are different things.

Thanks Foxy, I understood everything, but the missing piece of the puzzle was they had called a particle type ParticleSystem1. This is very confusing at best. They also must be creating a particle system to display the particle under the hood, so the question becomes what is that called, and can we refer to it in code as well.

 

[TheMagician]

2/ tabbing should really only move to the value boxes

+1000!!

I've already stumbled over this when adjusting Room size - nobody does that in individual pixel clicks. But it becomes even more apparent with all the values in the Particle Editor.

 

[Slyddar]

I would like to suggest changing the asset's default name from ParticleSystem1 to ParticleType1.

So when we create a "Particle System" in the asset browser, that is actually one particle type. And when you edit it, you can create multiple emitters with different particles attached. Have you worked out how to reference those individual particles? It doesn't seem like you are creating a particle type, as it allows multiple particle types to then be created within.

 

[FoxyOfJungle]

So when we create a "Particle System" in the asset browser, that is actually one particle type. And when you edit it, you can create multiple emitters with different particles attached. Have you worked out how to reference those individual particles? It doesn't seem like you are creating a particle type, as it allows multiple particle types to then be created within.

Hmmm, currently you can reference each particle type individually in the Resource Tree:

I know what you mean, but from what I understand, you can't do it in the way you are thinking...

It looks like the particle system used internally is global and has no way of being referenced too.


It works something like this:
Suppose I want another particle (likst dust) to be created at the end of another one, so I create a "preset" of the particle to be created:

Click in the "save" icon and give it a name.

Therefore, it is now possible to see the emitter of the Dust particle, inside my "Bubbles" particle:

So I set the Dust emitter to when the bubble particle dies.


and:

 

[Deleted member 84743]

@Dan i tested and display_reset seems to be okay now on this beta version.

can someone else also test display_reset to confirm this?


i dont know if this is important or not, but ui.log has these lines:

Failed to find particle presets folder at: C:\ProgramData\GameMakerStudio2-Beta\Cache\runtimes\runtime-2023.200.0.298\bin\assetcompiler\ParticlePresets
-trying : C:\ProgramData\GameMakerStudio2-Beta\Cache\runtimes\runtime-2023.200.0.298\bin\ParticlePresets
File exception 'Could not find a part of the path 'C:\ProgramData\GameMakerStudio2-Beta\Cache\runtimes\runtime-2023.200.0.298\bin\ParticlePresets'.'
Failed to find particle presets at runtime path:'C:\ProgramData\GameMakerStudio2-Beta\Cache\runtimes\runtime-2023.200.0.298' error:Could not find a part of the path 'C:\ProgramData\GameMakerStudio2-Beta\Cache\runtimes\runtime-2023.200.0.298\bin\ParticlePresets'.

the new particle system is missing a preset folder.

 

[Deleted member 84743]

hey! feather bug is also fixed!

https://forum.gamemaker.io/index.php?threads/2023-1-release-thread.101141/post-612394

"Feather rewrite engine crashes on GM2017 rule, if "variable_instance_exists" has "self" as target. Bug ticket #206562 "


i had 4 major bugs on my list:
-feather crash on "if (variable_instance_exists(self....". -Fixed on 2023.200.0.281
-group duplicate bug. -Fixed on 2023.200.0.281
-display_reset. -Fixed on 2023.200.0.281
-image editor sometimes does not register first click. -Fixed on 2023.200.0.281

all fixed thanks GameMaker developers

 

[Slyddar]

I know what you mean, but from what I understand, you can't do it in the way you are thinking...

It looks like the particle system used internally is global and has no way of being referenced too.

Yeah I know you can create multiple particles inside the particle type, but you cannot create just one of those particles by itself. It's all or nothing it seems. Also the particle system that gets created is definitely global, and unless we can guess the name of it with part_system_exists(), or the info is given to us, it will remain a mystery.

 

[kraifpatrik]

Basically the particle system is the same, which means that what has changed is that now is possible to create the particle through the IDE.

Then you can create the particle by referencing the asset:

// Create event:
global.pt_system = part_system_create();

// Step event:
if mouse_check_button_pressed(mb_left) {
  part_particles_create(global.pt_system, mouse_x, mouse_y, ParticleSystem1, 10);
}

ParticleSystem1 is the asset in the Resource Tree.

This still requires a system, which is returned with part_system_create() - which is great as it works the same way, except we don't have to write a bunch of code just to guess what an effect looks like.

Note that it is also possible to modify the existing asset on the fly:

if mouse_check_button(mb_left) {
    part_type_direction(ParticleSystem1, 270, 270, 0, 0);
    part_particles_create(global.pt_system, mouse_x, mouse_y, ParticleSystem1, 10);
}

There's something interesting to note: You can actually drag the particle asset into the room, using the Asset Layer:

https://twitter.com/i/web/status/1624140540026429440

When you do this, the particle asset will automatically use the emitter you create in the IDE:

The Emitter is basically an area where particles will spawn.

It's possible to scale them inside the Room too, but they distort lol

Note that when creating particles manually, the Emitter is disregarded.

You can also disable the particle emitter if not used:

--------------------------------------------------

I would like to suggest changing the asset's default name from ParticleSystem1 to ParticleType1. It is confusing to read the name system, as they are different things.

This is not how you use it. Functions part_system_create/_layer were modified to optionally take a particle system resource as the last argument. It might work for you when passed in as a particle type just because the indices match, but it is not intended to be used this way.

 

[JeffJ]

I know I'm probably in the minority, but I honestly find it incredibly annoying when you remove functions like the old non-async versions of system dialogs (such as get_string / get_integer).

The reasoning is that you should never use them for release builds, that your app / program should never stall the OS, that you will fail certification on console and denied release on mobile etc...

My counter arguments are:
1: I would never use them in actual releases anyway, so it doesn't matter
2: Even if I did and then failed cert / whatever, that's my problem, not YYGs
3: These functions works perfectly fine for me for what their intended use is - TESTING AND DEBUGGING (READ: IN MY PRIVATE, SECLUDED SETUP UNAFFECTED BY ANYONE ELSE)
4: In many cases it is actually helpful to me in testing and debugging that these functions are NOT async (as it can be helpful to have the game stall before input is received)
5: Further to the above point, having both async and non-async versions is more options - more options is always preferable, as use cases vary
6: I happen to be using those functions for their exact use - testing and debugging - in current projects. If I update I am having to redo work that is already done and working for my needs, just because, what? You didn't like those functions? Stop giving me extra work when they work just fine for what I need here and now. When I get to that point where they will be replaced by a custom interface that will be done, but you should not dictate WHEN that happens.

It seems a frequent thing that YYG makes me do additional work and / or redo work that was already long since done and working fine with every other update, and frankly is really annoying. Please stop doing this.

EDIT
It's even worse when you consider that very important things such as show-stopping bugfixes are irrevocably tied with other arbitrary runtime change nonsense such as this, always seemingly out of the blue, forcing the user to either be stuck with the bug (as is the case with the current LTS) or get with the program (such as much worse room editor flow, removing of functions forcing you to do additional work for no real reason etc..)

 

[efeberku]

There is still a Android FPS bug. I think It has not been properly fixed.
I tested it on my phone : Samsung Galaxy S22+ / Galaxy tab S7+ / Galaxy A50.

My phone samsung galaxy S22 + and Galaxy tab S7+ can switch screen refresh rate between 60 Hz and 120 Hz.
When I set it to 60Hz, 30 fps goes up to 40 fps.
When I set it to 120Hz, 30 fps goes up to 34 fps.
And Galaxy A50, with only 60Hz screen refresh rate option, 30 fps goes up to 40 fps.

So, you can see that at 60 Hz, 30 fps goes up to 40 fps, at 120 Hz, 30 fps goes up to 34 fps.

I think the problem seems to be with display timing method 'tm_countvsyncs'.
Why do I think so?
Because that the default display timing method is 'tm_countvsyncs' (display_get_timing_method() shows it is 'tm_countvsyncs'),
but If you write display_set_timing_method(tm_sleep) at the app start, everything is OK. 30FPS is 30FPS at any Hz.

If you write nothing, default display timing method is 'tm_countvsyncs', so Android FPS bug happens.
But strangely, at this default 'tm_countvsyncs' mode, refreshing app screen fixes wrong fps to 30 fps correctly. (You can refresh app screen by leaving the app screen and returning to it.)
Refreshing app screen doesn't switch 'tm_countvsyncs' to 'tm_sleep' because display_get_timing_method() shows it is still 'tm_countvsyncs',
I don't know why, but anyway, the wrong fps returned to 30fps correctly by refreshing app screen at 'tm_countvsyncs' mode.

I think nothing changed about this bug without that at screen refresh rate 120Hz, 30 fps goes up to 34 fps. In the previous version, it goes up to 40 fps like 60Hz.
i don't know much but as I wrote above, according to my tests, I think the problem is not about devices with higher refresh rate screens, but about the default display timing method 'tm_countvsyncs'.
Because even a device with only 60hz screen refresh rate option have this bug and writing display_set_timing_method(tm_sleep) solved this FPS bug.

I don't know if this 'tm_sleep' has any side effects or if I can continue to use it, but I haven't found any problems yet.
The important thing is display timing method 'tm_sleep' is not default option, so users will use 'tm_countvsyncs' by default option.
I hope the problem is solved next time, thank you.

When I use tm_sleep and open the game it starts ghosting. The ghosting starts as a line at the bottom of the screen and goes up.

Edit: When I alt+tab ghosting stops.

 

[Slyddar]

This is not how you use it. Functions part_system_create/_layer were modified to optionally take a particle system resource as the last argument. It might work for you when passed in as a particle type just because the indices match, but it is not intended to be used this way.

Instead of just saying no, can you explain how it is meant to be used please? Foxy and I have given suggestions on how we think it works, but it would be nice if we could just get an official answer. It is still in beta after all, and the more info we have, the better we are able to assist with finding any potential problems.

 

[kraifpatrik]

Instead of just saying no, can you explain how it is meant to be used please? Foxy and I have given suggestions on how we think it works, but it would be nice if we could just get an official answer. It is still in beta after all, and the more info we have, the better we are able to assist with finding any potential problems.

What I meant is that when you create a particle system using the new Particle Editor, you can spawn in through GML using functions part_system_create and part_system_create_layer, which were modified to optionally take a particle system resource as the last argument. To give you an example:

// Create an instance of a particle system resource called ps_fire:
ps = part_system_create(ps_fire);
// Or create it on a specific layer:
//ps = part_system_create_layer("MyParticleLayer", false, ps_fire);

// Then you can just use it with the regular part_system_* functions, like
// for example move the created particle system to position of the instance
// that created it:
part_system_position(ps, x, y);

When you do so, it creates all emitters that you've defined in the editor with all the particle type properties etc. It also automatically bursts or streams particles based on which mode you've set in the editor.

 

[Slyddar]

When you do so, it creates all emitters that you've defined in the editor with all the particle type properties etc.

Thanks for offering some clarification. So to clarify a little more, the particle editor automatically creates a global particle system, but only when the particle is dragged into an asset layer in the room. This system is also inaccessible to us? Otherwise, if you want to spawn a single particle from a created particle asset, you can't, as you have to spawn them all, and you also have to manually create the particle system yourself if you wanted to spawn them all in code?

This is not how you use it.

So creating a new particle system actually creates a new system and not just a new part type as Foxy alluded to? If that is so, how do we get the particle type name so we can reference it?

 

[Luvexian]

When I use tm_sleep and open the game it starts ghosting. The ghosting starts as a line at the bottom of the screen and goes up.

Edit: When I alt+tab ghosting stops.

Did you test tm_sleep mode on a Windows desktop PC?
The ghosting you mentioned doesn't seem to happen on my Windows desktop PC and other mobile Android devices at tm_sleep mode.

 

[efeberku]

Did you test tm_sleep mode on a Windows desktop PC?
The ghosting you mentioned doesn't seem to happen on my Windows desktop PC and other mobile Android devices at tm_sleep mode.

Yes, I am using AMD gpu and a cheap acer monitor.

 

[kraifpatrik]

Thanks for offering some clarification. So to clarify a little more, the particle editor automatically creates a global particle system, but only when the particle is dragged into an asset layer in the room. This system is also inaccessible to us? Otherwise, if you want to spawn a single particle from a created particle asset, you can't, as you have to spawn them all, and you also have to manually create the particle system yourself if you wanted to spawn them all in code?


So creating a new particle system actually creates a new system and not just a new part type as Foxy alluded to? If that is so, how do we get the particle type name so we can reference it?

I'm sorry but I think I don't understand what is it you're asking about, so I will try again to explain it as deeply as I can

Particle systems assets in the IDE are collections of emitters - you can have one or more emitters per particle system. Each emitter has its position, size, shape, mode etc. and also defines a type of particles that it emits. Particle system can be 1. put onto asset layers in the room, 2. put into sequences, 3. spawned from GML using the part_system_create/_layer functions. Every time you do so, the entire particle system with all its emitters is spawned - i.e. it looks exactly the same as it does in the Particle Editor. You cannot just use a single emitter/particle type from the system, the entire thing is spawned, always. Currently no new GML functions were added that would allow you to list emitters that a particle system asset has or types that they define.

Please note that I don't provide this info here officially on behalf of YoYo. I've only noticed there's some misunderstanding of the system going on and so I've tried to give my own explanation. There are people better qualified than me to provide official documentation, tutorials etc.

 

[Luvexian]

Yes, I am using AMD gpu and a cheap acer monitor.

If so, it seems that ghosting may occur depending on the gpu or monitor when using tm_sleep mode. Anyway, thank you.

 

[Slyddar]

3. spawned from GML using the part_system_create/_layer functions.

Thank you for clarifying, but it comes back to my original question. When using part_particles_create to spawn the particles it requires a particle system and a particle type. If the named asset is the particle system (ParticleSystem1 by default), what is the parttype argument?

 

[kraifpatrik]

Thank you for clarifying, but it comes back to my original question. When using part_particles_create to spawn the particles it requires a particle system and a particle type. If the named asset is the particle system (ParticleSystem1 by default), what is the parttype argument?

The particle system that function part_particles_create takes is not a particle system asset, but a particle system created with part_system_create - two different things. It is like object vs instance id. So you cannot use a particle system asset with that function. Any use case that I haven't mentioned before is not a valid one.

 

[Yal]

4: In many cases it is actually helpful to me in testing and debugging that these functions are NOT async (as it can be helpful to have the game stall before input is received)

I happen to use these functions a bunch in e.g. level editors, where pausing everything while waiting for input is the desired behavior - now what used to be a basic one-off event needs to be split up into several state machines.

I tried using get_string_async in a project some time ago and found it has terrible UX - the input field doesn't get focused so you gotta manually click the messagebox to use it, you can't confirm by pressing Enter, and then the game isn't focused when the input box closes! I don't see why anyone would use these functions when keyboard_string exists...

 

[Mehdi]

Very glad to see so many new things come in GM.

Only one thing that I feel strongly confusing is the use of the word: "Particle System" as a new game asset. We could probably call it a different word as we have already had a different concept with the exact same name for so many years.

 

[FoxyOfJungle]

Well, I'm not sure if it's really a good particle system design choice to have to use part_system_create() instead of part_particles_create()...

This seems unintuitive.

After all, if I wanted to modify the particle on the fly, I would have to use part_type_*...

And yes, I might want to modify it on the fly, if I use the particle in a missile and set its direction before the missile is created. In addition to many other uses.

IMO, it could be possible to create the particle either using part_system_create() - this way would use the emitter defined in the IDE, or using part_particles_create() - this one would not use the emitter.

In this way, the system becomes much more versatile.

I could just use part_system_create() when I want to spawn the system just once - for rain or snow, as the emitter will be used.

And spawn the particle individually when I want to literally spawn the individual particle.

Also, I wouldn't need to keep using another function to globally reposition the particle system when I could just create the particle at the position when used individually.


But again, this is just my opinion.

 

[TheMagician]

I also want to vote to keep get_string() and get_integer() alive. They are great debug functions. One line and you can immediately pause the whole game and test the outcome of a certain input. Great for prototyping. I doubt that any console dev ever was denied certification because they left a get_string in the code

 

[TheMagician]

I'm not sure if it's really a good particle system design choice to have to use part_system_create()

I see what you're saying. However, to me the current implementation makes sense. You spawn a pre-made complete Particle System with (possibly) multiple emitters and particle types.

Since everything is structs under the hood we might get additional functions to access the different aspects of the Particle System in the future.

For now, if you want to attach a pre-made Particle System to a rocket you would have to pull it into a Sequence and attach/rotate that Sequence along with the rocket.

 

[FoxyOfJungle]

I see what you're saying. However, to me the current implementation makes sense. You spawn a pre-made complete Particle System with (possibly) multiple emitters and particle types.

Yes, I partly agree with the fact that it has an emitter, so it makes sense. What I mentioned is that it could be possible to create the particles in the initial form that I showed. Even if it's not recommended, it's faster and simpler.
That is, both use cases.

For now, if you want to attach a pre-made Particle System to a rocket you would have to pull it into a Sequence and attach/rotate that Sequence along with the rocket.

It looks like a lot of work and tedious than simply changing the direction using a function

 

[Yal]

I doubt that any console dev ever was denied certification because they left a get_string in the code

If having them in "real" game builds is an issue one option could be to have them be treated as errors unless you're doing a windows VM debug build, so you're forced to use macros or whatever to make them not be in scope when doing a real build? (I usually use a "DEBUG_MODE" macro in my games to have a one-stop shop to enable/disable level editors, debug prinouts, and similar things)

 

[JeffJ]

Or better yet, simply treat developers as adult human beings and give them the freedom that entails. Some areas of GameMaker still has a sense of forced hand holding to the detriment of the product, something that made more sense back when it was targeted more towards children, but these days they have a literal "enterprise tier" and are starting to give us stuff like access to more surface types depending on rather specific needs for alpha channels etc.. But then at the same time, with something like the non-async versions, they don't trust the developer to be able to distinguish between when to use and when not to use a debug function? This is such an odd inconsistency. And ultimately, if I am going to do something that, against the clear warning of the official documents, gets my game denied on a certain platform, then that is my problem, no one else's.

 

[Yal]

Oh yeah, side note - I find that the manual didn't make it clear that these functions are deprecated, and the patch notes are outright lying about them being documented as not supposed to be used.
Here's the section from the patch notes:

Below is the latest (stable) version of the manual. Note "all other targets" here - implying that it's totally OK to use on Windows (if you're OK with debug use only - and I mean, we've got functions like show_debug_message and mp_grid_draw which are intended for debug use only so I'm not reading anything lesser into "debug use only").

Before removing it, it should've been changed to deprecated, period, well in advance, together with an announcement in the release notes (and changing its color coding the way e.g. array_length_1d or other deprecated functions are so you notice something is weird even if you don't read the release notes).

The page has no warning that the function shouldn't be used, so I'm not sure where this alleged long-been documentation would've been.

Spoiler

 

[Plura]

There is still a Android FPS bug. I think It has not been properly fixed.
I tested it on my phone : Samsung Galaxy S22+ / Galaxy tab S7+ / Galaxy A50.

My phone samsung galaxy S22 + and Galaxy tab S7+ can switch screen refresh rate between 60 Hz and 120 Hz.
When I set it to 60Hz, 30 fps goes up to 40 fps.
When I set it to 120Hz, 30 fps goes up to 34 fps.
And Galaxy A50, with only 60Hz screen refresh rate option, 30 fps goes up to 40 fps.

So, you can see that at 60 Hz, 30 fps goes up to 40 fps, at 120 Hz, 30 fps goes up to 34 fps.

I think the problem seems to be with display timing method 'tm_countvsyncs'.
Why do I think so?
Because that the default display timing method is 'tm_countvsyncs' (display_get_timing_method() shows it is 'tm_countvsyncs'),
but If you write display_set_timing_method(tm_sleep) at the app start, everything is OK. 30FPS is 30FPS at any Hz.

If you write nothing, default display timing method is 'tm_countvsyncs', so Android FPS bug happens.
But strangely, at this default 'tm_countvsyncs' mode, refreshing app screen fixes wrong fps to 30 fps correctly. (You can refresh app screen by leaving the app screen and returning to it.)
Refreshing app screen doesn't switch 'tm_countvsyncs' to 'tm_sleep' because display_get_timing_method() shows it is still 'tm_countvsyncs',
I don't know why, but anyway, the wrong fps returned to 30fps correctly by refreshing app screen at 'tm_countvsyncs' mode.

I think nothing changed about this bug without that at screen refresh rate 120Hz, 30 fps goes up to 34 fps. In the previous version, it goes up to 40 fps like 60Hz.
i don't know much but as I wrote above, according to my tests, I think the problem is not about devices with higher refresh rate screens, but about the default display timing method 'tm_countvsyncs'.
Because even a device with only 60hz screen refresh rate option have this bug and writing display_set_timing_method(tm_sleep) solved this FPS bug.

I don't know if this 'tm_sleep' has any side effects or if I can continue to use it, but I haven't found any problems yet.
The important thing is display timing method 'tm_sleep' is not default option, so users will use 'tm_countvsyncs' by default option.
I hope the problem is solved next time, thank you.

I tested and sadly this beta didn't fix anything.
On the Xiaomi 12T Pro, it runs at 80 fps instead of 60 fps.
There is also a problem on the amazon Fire 7 2022 and Fire 8 HD 2022 tablets where the fps are not stable enough.
As soon as the windows focus is toggled everything magically works and the game speed is stable at 60 fps.

The real fps on Amazon devices is a little below 60 fps, but as soon as the focus of the application changes and you go back to the application, the real fps jumps from 58 to 300 fps and the room speed is a stable at 60 fps.

This has become very frustrating as I reported this issue months ago and it still hasn't been fixed.