Should be fixed now, check the update I just posted.
Recent community posts
Hello, sorry for the delay, Ludum Dare ate up a lot of time.
Anyway - I loaded in the example demo (both versions of it) and let it run for a few minutes and memory usage stayed at a constant 11.58 mb. Hopefully the leak’s gone, but if it comes back send me the whole project and I’ll look around in it.
Also, 2.3.1 came out in beta this morning, which addresses some issues with the garbage collector - although I doubt that’s what was causing your problem.
Let’s see here.
If you want to switch between sets of UI elements (as opposed to creating and destroying them) the fastest way to do that is to probably create them all at the beginning of the game - or as needed - and then saving them somewhere without drawing them. You can also recycle elements by changing some of the variables: the “text” variable, for example, more or less does what you expect it to and is generally safe to change at any point in the code.
Regarding the memory leak, it turns out the list of contents attached to each struct wasn’t actually getting deleted (only cleared) in the Destroy() method, which is probably the cause of what you saw - it would only have been leaking a few bytes per element, but if you created and removed a lot of them it would start to add up over time.
I’m not noticing anything immediately unusual about RemoveContent() that would cause a crash, so later on I’ll poke around and see if I can find it. The only thing in your example file is the obj_emu_demo object, by the way.
Once I’ve done that I’ll post an update. I also kinda want to get rid of as many ds_lists as possible, in favor of things like arrays, since currently losing references to elements in other ways without calling the Destroy method will also cause a memory leak. In the meantime - if you haven’t already - add
ds_list_destroy(contents); to the destroyContent() method in EmuCore.
Hmm, good idea. I’ve cleaned up the hard-coded color values (plus some other things) to hopefully make applying a dark theme easier - although it sounds like you’ve already made the required changes yourself. There’s also a set of example colors that one might use for a dark mode now, and if you want to make dark mode toggle-able instead you can have the macros point to a global settings variable or something instead.
I like callback design for UI things overall, but the main drawback (that I’ve encountered so far) is that too many of them can have a small bit of performance overhead - which is usually tolerable for a user interface with a few dozen elements, but can start to add up if you have five thousand game objects trying to run at 60 frames per second.
Sounds about right. Other scripting languages like js and ruby and python let you do that kind of thing, but since most of my vector functions expand to an array it would probably create more problems than it would solve here.
I’m trying to go all-out with macro function magic, and it seems that I’m not allowed to nest them inside each other.
The compile error is less than helpful but GameMaker seems to take issue with the fact that the second one effectively unwraps to some god-awful recursive monster that I’m not going to try to type out by hand.
I can work around this (going the long way around with some arrays should still be way faster than making them functions and calling them constantly), but it seems to be a limitation of the preprocessor, correct?
22.214.171.124 has some issues with function callbacks. I’m waiting to see if the next update fixes it, otherwise I’ll work out an alternate way to do it: https://dragonite.itch.io/emu-ui-for-gamemaker/devlog/155555/gms23-is-now-in-open-beta
For the benefit of anyone reading this in the future, just so nobody thinks I’m ignoring this: Akitaris also reported this issue on Github, and I’m going to try to deal with it in a timely manner - but I may not get to it for a few days, depending on how deep-rooted the problem is and some other things I’m doing.
Follow-up: there’s an (erroneous) line in the ref script that invokes a different section of Lua code, which itself returns a value of 1, which appears to be the rogue value that makes its way out into the game. This has gone from a case of “I don’t know why this single case isn’t working” to “I don’t know why the other instances aren’t breaking!” If anyone finds this thread in a Google search or something: don’t invoke Lua from inside a ref script.
So much for keeping parts of my code separate!
So I’ve got an interesting issue where a script bound to Lua (
lua_add_function(...)) is having its value changed somewhere between its “return” statement
show_debug_message(BattleActions.SKILL); return BattleActions.SKILL;
and where it’s value is used in the Lua code
local def = Battle.default_act(me) print(def)
(printouts: 0, 1)
The bound script seems to “return” 1 no matter what actually goes in front of the return statement - a number, text, nothing at all, etc. I tried tracing it through the
lua_script_execute in the extension itself using breakpoints and printouts, but most of the returned values inside there seem to be either pointers inside a buffer or instance IDs and I can’t really tell where anything gets lost. I’m not sure if “1” is supposed to represent “true,” or if it’s erroneously turning into “1 return result” as in some of the other lua_call functions, or if it’s just an arbitrary value somewhere in memory.
Side note: big thanks for doing this. This is a really odd issue that I haven’t been able to figure out for two days, but overall using Lua has been really useful for keeping certain parts of my code separate from each other.
I've noticed that if you right-click an Object which is already selected, a lot of the times if the cursor is in the right place it just immediately selects the Duplicate option at the top and closes the context menu; I've accidentally ended up with quite a few clones of objects that I meant to do other stuff with this way.
Anyway, good tool! Integrating it with the other tool(s) I use has been a joy, and I really wish some other game dev utilities could be this easy to use.
This is largely the result of me doing stupid things with GML, but you probably would rather have this on record anyway, so: using the begin and end keywords in enums used in Live-enabled scripts causes Live to encounter problems. Strangely, as far as I can tell this only happens with enums, and using the begin and end keywords elsewhere - in control statements, or other code blocks, or whatever - seems to be fine.
There are other reasons I should probably just use curly braces in my code like most of the rest of the programming world (I was mainly doing it because it looks funny) and I'll be going back and changing it now that I've figured out what the problem is, but there there you have it.
To make things even more interesting, I've actually seen at least two different errors from this. In my main project I get
FATAL ERROR in
action number 1
of Async Event: HTTP
for object World: Push :: Execution Error - Variable Index [0,44] out of range [1,44] - -7.l_arr(100001,44)
at gml_Script_gml_std_haxe_boot_wget (line 3) - return l_arr[l_index];
stack frame is
gml_Script_gml_std_haxe_boot_wget (line 3)
called from - gml_Script_gml_builder_build_line (line 91) - var l__g13=gml_std_haxe_boot_wget(this,this);
called from - gml_Script_gml_builder_build_outer (line 21) - if(gml_builder_build_line(this))return true;
called from - gml_Script_gml_builder_build_loop (line 3) - if(gml_builder_build_outer(this,l_first))return true;
called from - gml_Script_gml_builder_create (line 15) - gml_builder_build_loop(this,l_src);
called from - gml_Script_gml_program_create (line 24) - var l_b=gml_builder_create(l_src);
called from - gml_Script_live_update_script_impl (line 60) - var l_pg=gml_program_create(l_srcs);
called from - gml_Script_live_async_http_1 (line 12) - script_execute(g_live_update_script,l_name,l_ident,l_code);
called from - gml_Script_live_async_http (line 12) - live_async_http_1(l_map);
called from - gml_Object_World_Other_62 (line 1) - live_async_http();
which is caused by this enum
enum PauseStages begin
PARTY_MENU, ETC, end
being used in this way in the script with live_call at the top
while when I do the same thing in an isolated environment in the GM Live demo project I get this in the console instead. The program keeps running, but the live call doesn't otherwise udpate:
[live][5:51:48 PM] Runtime error: live_test[L3,c16] `100000` (obj_gmlive) does not have a variable `PauseStages`
Naturally, this isn't an emergency or anything, but it's probably better to know about it than not.
Thanks! It started out as (and mostly still is) a thing I could use to make terrain that I could use in other Game Maker things myself, so it tends to be pretty helpful to use the same thing to make the tool since the terrain data's already in the exact format that I need. Also this time around it was a side project that I didn't want to spend a lot of time on the technical details of, and had already made the renderer for the other stuff I was working on.
I saw these about the matter but it feels a bit weird to reply to year-old threads so I'll just make a new one: do you plan on this being the behavior forever, or is it possible that after the "new" runtimes have been out for a certain amount of time - say, two years - support for the older runtimes is dropped and the functions like draw_get_font are adopted officially?
The wrapper script idea works fine, I always feel kinda guilty about writing code like that, though. It also makes me wonder what's going to happen when the mythical GML update comes out, which'll hopefully change what Game Maker thinks is valid code in some pretty big ways.
Not sure if you're still maintaining this, but I tried importing a few scripts from another project, but for some reason it spat out the scripts that were living in a nested folder into the root of the Script list instead of actually putting them into a subfolder. (Also it took more than a minute to transfer 36 files, but I'm not sure if my destination project being relatively huge has anything to do with that.)
Still, this was much nicer than transferring everything manually. Thank you!