Yes indeed, static is used inside a constructor function to make variables of the struct it creates static(which means they only get initialized once despite the constructor being called multiple times). Since it is a keyword in GML now, it can't be used anymore for variable names, etc...When I converted my project to 2.3 for the first time, I had the same problem. In fact, my project had a variable called static. However, in this version it seems that there is also an internal function called static. Replaces all occurrences with the name staticx and solved the problem.
You can have one general constructor, and then create another constructs which extends it, then it still will save memory:Then I have a giant switch-case function for each entity type, which gets an entity index passed in, and adds variables/components to the entity.
function A() constructor {
health = 1;
}
function B() : A() constructor {
some_additional_value = 2;
}
my_params = new B();
Per https://forum.yoyogames.com/index.p...uys-seeing-this-please-read.76385/post-454087 it is probably what you have to look forward to.It doesn't seem wise to make updates to the rest of the engine contingent on full stability with massive new, unrelated features.
I expect you will be able to simply upgrade to keep up, and then simply not use the new GML features until you want to. In my experience and from what I've seen, most people have been able to simply import a project and it auto-converts it. The only actual code that has to change that I know of is that it takes the script code(in resources, not events), and wraps them in a function that is named the same as the script. This lets your code simply work, calling the function as it always has, even though it gets turned into a function inside the script. The new GML lets you do much more than just a single function in that script resource, but since imported projects won't have done that yet, it doesn't affect anything. But yes, part of the beta testing has included the compatibility changes, so your project should basically just work out of the box, at the least once it is fully stable. And as stated in the other thread, I don't think there is any ETA on the stable version. It may not actually be all that much longer, considering they opened the beta to the public(instead of just internal or invite-only).Is there a timeline on full release for 2.3? I want to upgrade only to keep my mobile game current with iOS/Android requirements.
I expect such widescale changes to GML will take a while to make fully stable through beta testing. It doesn't seem wise to make updates to the rest of the engine contingent on full stability with massive new, unrelated features.
Given the kinds of type loss and inheritance anomalies still in the new GML additions, I wouldn't be surprised if there's still at least another month to go.I expect such widescale changes to GML will take a while to make fully stable through beta testing. It doesn't seem wise to make updates to the rest of the engine contingent on full stability with massive new, unrelated features.
I'm not concerned about the new features interfering with my game simply through my upgrading. Or, at least, I wasn't. Hmm.I expect you will be able to simply upgrade to keep up, and then simply not use the new GML features until you want to.
The way GML is can be a whole 'nother discussion. That said, from what I've used of the new features, they really aren't like super buggy or anything like that. However, there are a couple of glitches that you have to be aware of, and of course you have to properly learn how to use them, if you are going to use them. But the good part is that you don't HAVE to use them until you feel like it.I'm not concerned about the new features interfering with my game simply through my upgrading. Or, at least, I wasn't. Hmm.
As for the new language features, they're sort of great, but my view is: (1) they're being bolted onto existing GML, which is itself more an accretion than a language, an assemblage of responses to use-cases that have arisen in the decades since GMS was click-and-make educational software, and (2) they'll probably be buggy as **** and users will need to wait for the community to provide some guidance on safe usage.
I've been having problems with my image_index's (seems like they have different behavior when going below 0), but not sprites themselves being incorrect. Are you using image_index's to act as separate sprites?I can't pinpoint why this happens but I'm trying my best to duplicate it. It only happens randomly. When I compile a project and it starts up, some of my sprites are switched around with other sprites. So my player sprite will sometimes, on start-up, have a sprite I use for GUI, or a sprite I use for other objects. It happens more frequently when using the android target.
I tried cleaning the project, cache folders etc but it still happens at random. This is when using the latest 2.3 Open Beta. Has anyone else had such an issue?
Nope, no usage of image_index in that regard. I have an object who's sprite_index changes according to an imageNumber variable with a range of 1 to 6. There are 6 different sprites and I switch the sprite_index of the object, again, based off what imageNumber equals for the object.I've been having problems with my image_index's (seems like they have different behavior when going below 0), but not sprites themselves being incorrect. Are you using image_index's to act as separate sprites?
Yes, we needSo, structs can have constructors, but what about deconstructors? I have looked through the manual but have found nothing in relation to the delete operator. Without a handler for deletion, using structs in conjunction with data structures is essentially impossible. Since data structures are not garbage collected while structs are, it is not possible to reliably expect the struct to handle a data structure without disappearing into thin air and causing a data leak.
That still doesn't free any data structures from memory. It has to be done manually, freeing all data structures inside the struct, before freeing the structure, else there will me memory leaks.You meant this?
GameMaker Language -> GameMaker Language Overview -> Language Feature -> delete
Or I did not understand the question.
That's explictFor the last time: Destructors have been explicitly denied by YoYo's development team.
You can still implement your own GC on top of GM that handles those things. At the very least you could create one wrapper struct per resource (e.g. create aWell, the lack of destructors is not a big deal in itself, but the matter remains that there is no safe way to use data structures inside of structs. You could replace lists with arrays and maps with structs, but other data types are completely out of the question. Surfaces, buffers, even instances, all unsafe.
It really undermines the point of structs as data containers if they can't reliably contain the large majority of available data types.
Buffer
structure) and the creation of such a struct leads to it being registered in the GC system. The GC system would then check on a regular basis for which wrapper structs were deleted by GM's GC and then cleanup the corresponding resource. This of course has its own pitfalls but it is at least possible. Ofc that native support for this by GM would be much better.global.GLB_DELETE = function (st){
try{ for( var i=array_length(st.__delectList)-1; i>-1; i-- ){ st.__delectList[i](); } }catch(e){ }
delete st;
}
global.GLB_RegistStructDelete = function(st,func){
try{st.__delectList[array_length(st.__delectList)] = func; }catch(e){st.__delectList= [func]; }
}
#macro RegistStructDelete global.GLB_RegistStructDelete
#macro DELETE global.GLB_DELETE
function test1() constructor{
data1 = ds_map_create();
RegistStructDelete(self,function(){
ds_map_destroy(data1);
show_debug_message("delete test1")
});
}
function test2():test1() constructor{
data2 = ds_list_create();
RegistStructDelete(self,function(){
ds_list_destroy(data2);
show_debug_message("delete test2")
});
}
test = new test2(){};
DELETE(test);
//delete test2
//delete test1
Something like that would work. My current approach is to have a free function that just checks if the supplied struct has a free method, invoking that before deleting it. However, this means that you can only free it once and not rely on the reference counting nature of delete. If you want to have the same reference counting behavior then this approach is too simplistic.Maybe we can do staff like this:
Rui Rosário
Annoyed Grunt
drandula
Cameron
FrostyCat
GML:global.GLB_DELETE = function (st){ try{ for( var i=array_length(st.__delectList)-1; i>-1; i-- ){ st.__delectList[i](); } }catch(e){ } delete st; } global.GLB_RegistStructDelete = function(st,func){ try{st.__delectList[array_length(st.__delectList)] = func; }catch(e){st.__delectList= [func]; } } #macro RegistStructDelete global.GLB_RegistStructDelete #macro DELETE global.GLB_DELETE function test1() constructor{ data1 = ds_map_create(); RegistStructDelete(self,function(){ ds_map_destroy(data1); show_debug_message("delete test1") }); } function test2():test1() constructor{ data2 = ds_list_create(); RegistStructDelete(self,function(){ ds_list_destroy(data2); show_debug_message("delete test2") }); } test = new test2(){}; DELETE(test); //delete test2 //delete test1
Yes, if you want the “shared_ptr ”, and let's live in the world before C++11.....Something like that would work. My current approach is to have a free function that just checks if the supplied struct has a free method, invoking that before deleting it. However, this means that you can only free it once and not rely on the reference counting nature of delete. If you want to have the same reference counting behavior then this approach is too simplistic.
Surfaces and buffers are the only two items on your list that I would consider genuinely GC-unsafe. Instances are taken care of by the room lifecycle, and I've already managed to replicate all 6 ds_* data structures as structs and arrays. The biggest obstacle now is YYC and HTML5's tendency to lose track of struct and array types during heavy use.Well, the lack of destructors is not a big deal in itself, but the matter remains that there is no safe way to use data structures inside of structs. You could replace lists with arrays and maps with structs, but other data types are completely out of the question. Surfaces, buffers, even instances, all unsafe.
It really undermines the point of structs as data containers if they can't reliably contain the large majority of available data types.
my_list = ds_list_create();
some_register_function(type.list, my_list);
my_list = struct_ds_list_create();
/// somewhere else
struct_ds_list_create = function() {
var my_list = ds_list_create();
some_register_function(type.list, my_list);
return my_list;
}
Buy and Buy and Buy, don't doubt it.Is it possible to test the GMS 2.3 beta as a trial user? I've been waiting for this to drop so that I can finally decide whether or not to finally upgrade to GMS2.
I haven't been disappointed by YoYo on a single occasion in 15 years, but I do tend to heir on the side of caution.Buy and Buy and Buy, don't doubt it.
There's a reason to live 15 years for yoyoI haven't been disappointed by YoYo on a single occasion in 15 years, but I do tend to heir on the side of caution.
Go into your download page and see if it’s there. My guess is it won’t be as it’s a paid product. But not sure???? There are YouTube videos that go over the features. Should be enough there to decide.Is it possible to test the GMS 2.3 beta as a trial user? I've been waiting for this to drop so that I can finally decide whether or not to finally upgrade to GMS2.
Inside beta installation folder:Those phy_part functions are for the soft body physics. @gnysek can you explain what you see about the "DLL placeholder, layout, and language strings"?
My main issue with using current image editor is, that when image loose focus, but the IDE has it, I can't paste anything. So copypaste seems to not work properly many times, and I always need to click inside actual image, or I can't paste (create a brush in fact). Then, when copying frames, it again works different. So yeah, I would like to see fixes in copy-pasting for whole image editor (especially some visual indication what is focused now, and where I can paste or not)....how about also adding standard copypaste mechanics to the image editor?
Thanks for showing me. Of course since there is no public info on it, I have no idea if they are actually going to expand on the particle system they have, or just make an editor in the IDE for the current system. Back in the day they removed a few things from the particle system to make it more performant for mobile....but I think they should have left them in and made them optional instead. Things like colliders, forces, etc... are easily handled on PC(and really even modern mobile devices often enough). That's why I'd like to make my own particle system, basically a 2d version of the best of what Unity's does, using gradients instead of just 3 values for the parameters.Inside beta installation folder:
View attachment 32469
Inside layouts:
View attachment 32471
Inside Languages/english.csv
View attachment 32470
However, those can't be enabled in any way, and are just placeholders for future use. May come one day, may not.
Going by what you showed me above, they seem to be adding a particle editor...this means that particle systems would be an asset/resource I would think(they wouldn't make us copy/paste gml like we have to do for external editors would they?!?! ). So I'm guessing that they very well could add those resources to be similar to sprites and instances as far as sequences goes, just one more thing to be added to them, and likely animated/simulated as it goes.If they gonna touch particles in any way, I'm pretty sure first they gonna add what now exists into sequences, then they can look into extending them. I would really like to have any editor inside IDE, and after we tried beta, sequences doesn't seem to have any unfinished features, so they must have some new ideas if they are mentioned in roadmap. Particles or text layers are the first two that comes into my mind, that already exists, but aren't covered yet.
^I followBuy and Buy and Buy, don't doubt it.
I know you're doing a spellcheck pass right now. It's not a spelling error but I found this bit of awkwardness:
The updated manual is now live for everyone to check out, and all previous links (docs/docs2) will soon be set to redirect there... Note that, BACK BY POPULAR DEMAND, it has an index again (as previous iterations of the manual in the 2.3 beta didn't).