If you mean the preview field (right half of the application), Firefox will not render fonts that have ascent-descent-linegap (second tab) set up incorrectly or have characters exceed these boundaries. There’s a little calculator there showing whether what you’re doing is a bad idea.
YellowAfterlife
Creator of
Recent community posts
You can use application_surface_draw_enable
to disable automatic drawing of application_surface and then draw it yourself as you please in Draw GUI event (e.g. right before Gameframe’s draw).
The only thing to be aware with this is that you need to do a little math to calculate the mouse position because there isn’t a application_set_position
function.
If someone paid me, I think I could make the extension load one frame at a time, which would then let you load the GIF bit-by-bit instead of all at once.
If you know Haxe, you can try doing that yourself (see source code) - gotta split up the GifReader.read and Gif.read methods.
To those whom it may concern:
Silver has a whole lot of glyph ranges, so I consider it to be easier to load it dynamically.
So you would add Silver.ttf to your Included Files, and then do the following on game start:
globalvar fnt_silver;
font_add_enable_aa(false);
fnt_silver = font_add("Silver.ttf", 14, false, false, 0, 0);
Then you can do draw_set_font(fnt_silver)
and GameMaker will load the glyphs when you first use them.
Hello, that will be a thing once I decide how to handle custom widths for glyphs.
Writing a FontForge script is a good solution if you iterate on the font a lot.
If you only need to pin the window, that’s window_set_topmost
in the other, free extension. It can be used on its own or along with this/other extensions.
I also have an extension for custom window shapes.
The method function binds a function/script to an instance or a struct.
When you have something like
// Create
live_auto_call;
myCoolFunction = function() {}
What executes is roughly equivalent to
live_auto_call;
var context = {};
context[$"live:self"] = self;
context[$"live:function"] = /* a struct with representation of updated code */;
// ... a few more fields
myCoolFunction = method(context, gml_thread_method_script);
This way gml_thread_method_script
knows both which instance it should run for, and what code it should run.
If you later do
myCoolFunction = method(..., myCoolFunction);
myCoolFunction would no longer have live:self/live:function attached to it and GMLive wouldn’t know what code to run, hence the error.
Variable assignments are explained in the manual.
You are probably familiar with these if you have 758 lines of code in a Step event and are using Scribble.
Also include the line of code that’s on o_control➜Step➜Line 758.
Could this be because I’m using GM:S 1.4?
From the looks of it, I have only implemented this for GMS2, yeah
I could spend an hour or two adding this if you could provide a convincing argument for why you’re sticking to GMS1.x with current GM versions being free* and all
Edit: (checks profile) ah, a 3d game! Some of the d3d functions aren’t easy to port without caveats
This error turned out to be simpler than I was expecting - if you search the project scripts (including GMLive’s) for live_shader_updated(
, there are two calls to the function a few lines apart - one that has 3 arguments and one that has 1.
var l_sh = asset_get_index(l_name);
live_shader_updated(l_sh, ds_map_find_value(l_sup, "vertex"), ds_map_find_value(l_sup, "fragment"));
live_log_script("Reloaded " + l_name + ".", 0);
live_shader_updated(l_sh); // <- problem
The latter (with 1 argument) is a name collision and should be removed - this causes GM to pass nullptr
instead of strings to the DLL, which is not anticipated (and also I have not been previously aware that undefined
becomes nullptr
- isn’t that what pointer_null
is for?)
The workaround is to use live_constant_add
It is not possible to auto-retrieve retrieve constants while the game is running, so GMLive won’t know about them until I update the extension.
Sounds like the same thing as this https://itch.io/t/3678495/unable-to-compile-after-updating-to-newest-ide-version-and-updating-gmlive
If you are working with 2023.11 IDE, chances are that it has removed the file names from the extension upon import, as per linked bug report. You can check this by double-clicking the extension in the resource tree.
You could fix this manually by comparing the file contents to the ones in the demo project and assigning the correct name to each file in the extension.
Or, if you have moved to GM2024 IDE, you can remove the extension and use Add Existing (or Tools ➜ Create Local Package) to copy the extension from the demo project to yours.
The example is for GM2024, hence the name.
I would suggest to test there as GM2023.11 had a tendency to corrupt extensions