R
rui.rosario
Guest
@Samuel Venable I think @Mike made a rhetorical question, meaning that if it isn't in the roadmap then it probably isn't being considered.
I have an on topic question about something that's currently on the roadmap. What are YYG's plans for the Garbage collector? Is it going to be an optional thing we can call only when we want it, or is it going to be doing its own thing with few options for fine control from us?Let's use this topic for discussing the update itself rather than asking for new potential roadmap items.
Will the garbage collector work better than the one in place for arrays? My last test indicated it did not know how to deal with cyclical references.@Kuro - we will definitely have an on/off for the Garbage Collector, but I suspect there will not be a lot of fine grain control apart from that, it's not like we currently have any destructors or finalisers (NOTE: Instances do not count as the room/layer keeps a reference to them even if you do not).
The current explicit creation and destruction will still be there... Garbage Collection will be used for more transient (lite objects).
Russell
What if you created your map as usual,I've been trying on and off game development for years. After often being disappointed in the time it took me to progress, I'm kind of over trying to get better at coding, I accept that I'll never been good at it. I'm delving into gamedev again, after maybe more than 2 years, and now I'd like to feel like I'm progressing instead of being stuck on simple mechanics for days, which is what led me to Game Maker. All that to say, right now runtime autotiling is very, very sorely lacking for me. I have been looking into autotiling for days, and admittedly I've learned some things, but as I said I'm just not very good, and I'm sure what I've been trying to do (TBS-style fog of war) isn't that hard, plus the use is only cosmetic (I can get big, square black and transparent tiles fine), so it's frustrating to feel stuck on it.
Oops my bad thenI think they wanted nice corners and stuff to the fog, not just every cell of fog being a featureless rectangle.
They are read only, but you can manipulate them with other variables (x, y and image_xscale, image_yscale )Don't you plan autolayout which allows to align sprites and objects to any side (not top left corner only)? It is already implemented in Unity, WPF, xCode, html and etc.
I have also found the following properties:
- instance.bbox_top
- instance.bbox_bottom
- instance.bbox_left
- instance.bbox_right
But the problem is they are readonly.
- instance.sprite_width
- instance.sprite_height
If you mean the pivot of the sprite, you already can do this.Don't you plan autolayout which allows to align sprites and objects to any side (not top left corner only)? It is already implemented in Unity, WPF, xCode, html and etc.
I mean I want for example to place a square object into right bottom corner and its size and distances to right and bottom sides should be fixed independently from the device resolutionIf you mean the pivot of the sprite, you already can do this.
I'm not entirely sure what're you're trying to do.I mean I want for example to place a square object into right bottom corner and its size and distances to right and bottom sides should be fixed independently from the device resolution
And using pivot in this situation is a bad approach because pivot belongs to a sprite. So if I need a number of similar objects but with different alignment I need to duplicate the sprites
Is it for a GUI?I mean I want for example to place a square object into right bottom corner and its size and distances to right and bottom sides should be fixed independently from the device resolution
And using pivot in this situation is a bad approach because pivot belongs to a sprite. So if I need a number of similar objects but with different alignment I need to duplicate the sprites
No, for objects in general. I want to create a scrolling shooter and stretch enemy waypoints (in gamemaker it is called "path") only, not enemies' spritesIs it for a GUI?
What do you mean by "enemy waypoints"? Paths are used to move objects around in a predefined pattern or to be changed at runtime to hold a path that an AI will use.No, for objects in general. I want to create a scrolling shooter and stretch enemy waypoints (in gamemaker it is called "path") only, not enemies' sprites
This is why it would be SO MUCH EASIER if GML had basic init, update (_fixed_update for physics) instead of needing a new command for everything... GML does a lot right and so much wrong.Right, forgot to regurgiate the stuff I'm suggesting for every new GM version... Could we have the Room Start event renamed to "Enter Room" and then get a "REAL Room Start" event that's only run the first time you enter a persistent room [and every time you enter a non-persistent room]? And also instance_activate_object_region() and instance_deactivate_object_region()?
Shaders aren't written in GML though, they are made with one of the shading languages supplied by GameMaker.The path system works perfectly but having a particle resource on the resources tree with a particle editor would be nice oh and a shader editor that has a checkbox for create using gml mode for shader label, also leaving that unchecked on 1 particular shader whilst editor is open will give an entire library of tools to use, just like the one in construct 2 by scirra so we can outcompete them.
I completely agree. While a visual shader editor would be cool, other things take way more priority over it.A visual shader editor/creator would be nice...I just kind of think it is somewhat out of the scope of what GM is really meant for. Shaders can add a lot to a game(even a 2d game), but I think there are other things that should take priority, things that are more useful. A better particle system(with resource type and editor) would be an example of a higher priority for me. Lots of what is on the roadmap would also be in that boat. Right now, you can write shaders using one of the shader languages...but unless you make your own particle system, the one currently in place sucks. I know they removed affectors, etc... because of performance, but I think those should actually be added back in. For PC games the performance is fine, and we would have to just manage our usage of them on lower-end platforms.
Which version of GM were they added, and which version were they removed?Affectors were things that affected particles. There were forces, which could attract/repel particles from a specific point, to a general force in a single direction...and colliders that could change or destroy particles.
Ahhh man. That stuff sounds very cool. It's a bit odd how they were removed for performance reasons.If I'm not mistaken, they were added in GM7, but maybe it was before. And I'm understanding they were removed for GMS1.
Why not just use collision masks with precise collision detection?I was aware of that as well I mean...c'mon it's the most common "2D" feature of any game engine in the last 10 years! Yes, Game Maker has shape collision but with physics only, you don't need physics in a RPG... I mean, why neglect such a common feature amongst every game engine? You guys would probably need to bring in rigid and kinematicbody as well.. very easy should just be a simple check box in the object or uncheck it and it works as is right now.
the installer will uninstall the old one on it's own, then install the new one. you don't have to do anything yourself except allow it to do so. (it'll ask you)Do I have to uninstall and re-install GMS2 or does the update automatically overrides the old version of the program?
Thank you.the installer will uninstall the old one on it's own, then install the new one. you don't have to do anything yourself except allow it to do so. (it'll ask you)
Best practice is to backup your entire project before doing an upgrade and to use git to maintain a constant backup.Thank you.
This is the first time I use Game Maker on a Mac.
I bought it like two weeks ago and I really don't want to lose everything already because I had an oversight.
Thanks!
Of course.Best practice is to backup your entire project before doing an upgrade and to use git to maintain a constant backup.