Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics


A member registered Oct 01, 2014 · View creator page →

Creator of

Recent community posts

The fact that this started happening all of sudden suggests that this is yet another format change brought by an IDE update, but I’m yet to look into it. If your project is relatively small, email me a copy as the other samples I have received are pretty big.

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.

That’s done now

Itch works, or there’s a PayPal on my hotmail contact address.

$50 or so

To be completely honest, it’s a little hard to guess what could be going wrong with code that I wrote 5 years ago

I bet people on game’s Discord would have more ideas than me at this point.

(2 edits)

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 and methods.

That is, U+0445.

Usually in Вихід, х and и would be the same height;
Latin x is unaffected.

No rush or anything - I have an existing font for Cyrillic and was testing whether Silver would fit in the UI.

  • 9940 should be installed over the stable u99 release
  • 9944 should be installed over modbranch_2021
  • ntt_development has NTT pre-installed

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;
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.

(1 edit)

Make sure you’re importing display_measure-for-GMS2.3+.yymps - GMS1/GMS2.2 DLLs don’t work in recent GameMaker versions

Edit: renamed these a little to be more clear about what is what

The new GMLive release fixes this.

Added these in 1.0.76

1.0.76 is exported from LTS so should be fine now

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.

Apparently it has been a grave mistake to update the test project to GM2024 to debug issues with GM2024? Gotta love GameMaker

You can also use menu:Build ➜ Build Solution

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.

You still cannot Run (F5) a DLL project, but you can Build it (F8).

I still don’t know what you’re asking about, but I don’t think it has to do with my GameMaker extension for live-reloading.

That’s okay, you cannot “run” a DLL. Now compile for x64 too and it should be getting copied to the GameMaker project folder

Apparently the script is allergic to paths with spaces in them - replace that “gameframe directoryquesionmark” by “gameframe-directoryquesionmark” and it should be fine

The method function binds a function/script to an instance or a struct.

When you have something like

// Create
myCoolFunction = function() {}

What executes is roughly equivalent to

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.

(1 edit)

If there is no DLL, something about the DLL build failed - care to post your Output from Visual Studio?

(1 edit)

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

That does sound like you are re-binding it to your object somewhere. And how does the call and assignments of the variable look like?

You may have to elaborate on what you mean

I can tell that live:self is undefined if it throws that error, but what is in self?

As making GameMaker extensions is not my full-time job, I have limited capacity for debugging issues in large projects - especially when many these turn out to be GameMaker bugs or self-sabotage.

I’d need a small sample project that reproduces this

You can also run the game in debug mode and see what exactly is stored inside self when it errors - when live_method is used, it should be a little struct with live:self and a few other variables.

(1 edit)

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

That’s caused by the new GameMaker update changing the project format, you should update GMLive.

Thank you!

I don’t speak German and machine translation has some limitations, but still this was fun to watch - hitting both yourself and a friend with a Disc Gun is an absolute classic for this game.

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

Alright, I uploaded a demo project (window_set_cursor_demo (for GM2024).zip). Seems to work fine on my end on both Windows and HTML5..?

If you need HTML5 support, you can use the first version of this extension (window_set_cursor (for GMS2.3).yymps) - V2 doesn’t have a JS version yet.

Depends on what you desire - generally I prefer writing text tutorials as they are easier to update when something inevitably changes.

I believe that I have fixed this in the offline documentation for latest version, but I have not updated the online one yet as there are minor technical issues.