Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs

Dragonite

53
Posts
12
Topics
146
Followers
36
Following
A member registered Mar 09, 2016 · View creator page →

Creator of

Recent community posts

The original thing that this is based on actually does have a dropdown menu system in place, but I didn’t carry it over to here (yet) because I’m not really a fan of how it works. A dropdown element would probably honestly look a lot like that, minus the ability to unfold.

Trees could theoretically be done already by combining a bunch of buttons and text labels and whatnot… but have an element dedicated to that would probably be vastly preferable.

I definitely need to do drop-down lists, a few people have requested them now. I think you’re the first person I’ve seen mention trees/foldable regions, but I can see those being hugely useful too.

Yeah, the goal in that one was a bit vague. If I’d had more time I would have liked to add a few more large objects to help orient yourself.

Hmm, I’d initially done that intentionally but honestly I can see how that would be more annoying than anything else. I’ve disabled changing course during transit, new version should be good now!

Here

mouse_x and mouse_y are the mouse’s position relative to the room, so if you make use of views and cameras it may start to conflict (although if it works for you, that’s all that matters).

The device mouse functions are probably the solution that should work in pretty much all cases, since they’re designed to take the GUI layer into account - I’ll play around with that next chance I get; as long as nothing bad happens I might make that the default.

If absolutely necessary I could make the mouse position value a macro that the user could change depending on their needs, although I doubt it would come down to that.

Oh dear, thanks for reminding me. This should do it.

I also saw you left a few comments on Emu; I’ll try to work on that some time this week, there are a few other changes I need to make over there as well.

Well, it looks like I’ve got my work cut out for me, lol.

I’ll try to get to the more important issues first (getting the elements to react to touch events rather than the mouse, making lists scroll by clicking and dragging, etc) and then I’ll dive into some of the more specific issues. I’ll try not to keep you waiting too much longer, although there’s some work I want to get done in the next week or so, so I might not get around to it for a few days.

Regarding text elements (and other such elements) that need to continuously update, I usually override their Render methods in a way that fetches the updated values before drawing, like:

element.inherited_render = element.Render;
element.Render = method(element, function(args...) {
    self.text = "Updated text value";
    self.inherited_render(args...);
});

although that may not be the most element solution if you need to do it in a lot of places - so I might at some point add some extra code to account for that sort of thing.

Okay, wow, that’s in-depth. Glad you seem to like it!

I don’t have the mobile exports so I can’t test it (currently), are there any other changes that need to be made for it to work smoothly besides the window mouse functions and the on-screen keyboard? It may be worth me making a configuration specifically for mobile. Performance-wise it might also help to optionally use the built-in GameMaker text renderer instead of Scribble - Scribble is great on desktop, but the text shader is a bit beefy so it may not be worth it on mobile devices, or laptops with integrated GPUs - as you seem to be seeing.

Drop-down elements might be a good idea (I assume you mean something like these), I might add one next time I get around to implementing new features. Functionally they’d be pretty similar to single-selection lists, except that they’d be collapsible when not active. (The original UI code I wrote that this is based on actually had something like that, but I didn’t think it worked very well so I didn’t include it in here - probably worth redoing at some point.)

I’ve also been (slowly) trying to remove the amount of hard-coding, but as I see you’ve noticed there’s still quite a lot of it left. Adding anchor points and other support for scaling is also something I’ve thought about - I haven’t needed it myself so it’s kind of taken a back seat, but a few people have expressed interest in that sort of thing so I should probably work something out one of these days.

There’s a compatibility script for the old GameMaker models, depending on how far you want to go with that (.d3d is a pretty obscure format).

Good fun! Not sure if you’re still maintaining this or not, but somewhere along the line GMS2 changed the way depth works, causing the skybox to get drawn over half of the screen. (It looks like someone else had a similar problem, but I don’t know if it was caused by the same issue or not).

Anyway, when you draw the skybox, you now need to force the depth buffer off (gpu_set_zwriteenable, as well as gpu_set_ztestenable if you really want) to prevent the background from persisting in 3D space after it’s been drawn. Not sure when GameMaker changed this, since it works just fine in GMS1. ¯_(ツ)_/¯

Also, I’m impressed that you managed to model everything in the game using exclusively paths. I would have just gone straight to 3D object files, lol.

Buckle up, everyone. (Get it? ‘cause it’s a driving game?)

The glowing singularity thingy that shows up at crossroads is a bit confusing, since for the most part you’re supposed to move towards the glowing things, while the singularity thingy hurts you.

Otherwise, good job!

Generally speaking, it’s the direction opposite the vector of gravity.

Okay, I didn’t realize that the design changed - but now that I look closer at my Xbone controller I see that’s what they are now. Good to know, thank you!

These are pretty nice! It doesn’t seem to have icons for the Start and Back (Start/Select) buttons though, nor some of the control keys on the keyboard such as Insert and Delete, do you have a set somewhere that includes them (or failing that, would I be able to commission some)?

camouflage would probably be beneficial for the witches’ safety at their trials, tbh

Thanks! Unfortunately it doesn’t work on HTML5 specifically, the culprit is the text renderer doing some things that don’t work on HTML5. If you need to use it there I could make a version that just uses the normal GameMaker text features, though (or you could replace all the scribble references yourself, if you’re comfortable doing that).

There aren’t any more features in mind that I plan on adding right now, although it’s possible that I might think of something I want to do eventually.

I haven’t tested it on mobile, but it should work. It’s only GML.

It’s included. It’s an older version though (6.0.14), so I should probably update it to scribble 7 at some point as more people start to use the newer versions.

Oh nice, it automatically turns if (value == undefined) value = something statements into a null coalescence. This is going to save me quite a bit of typing.

Thanks! Hope it works out for you!

Related: https://twitter.com/tha_rami/status/1074118059223326720

Add “Removed Bogosort” to all of your patch notes the way Notch had Herobrine.

Should be fixed now, check the update I just posted.

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.

She was a good chicken :(

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.

Anyway, thanks!

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?

You actually did it, lol.

Usually when I need to do this I just overlay a regular Text element on top of it - but that’s a good idea, I’ll make sure to add this in next time I work on this!

Thanks!

23.1.1.146 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

What are you trying to do

Thanks!

I definitely want to add custom particle sprites (and some other things) eventually! Going to work on some other things first though. Glad you liked it!

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.

Sindre, you mad, mad lad.