notification poll!!

Posted by Alert Games on Jan. 17, 2018, 8:36 p.m.

Hey guys,

I'm curious as to what you guys prefer when tracking project updates. What is your preference??

I would embed the tweet but I don't think I can do that here…. so here you go:

Update on things: I've updated my site in a minor way, but also added a page for GMUI. Check that out here and feedback is of course welcome:

Still trying to get everything done as quickly as possible. Is hard.

Sorry for the short blog, but I felt like contributing some content and would like to hear from you guys too :>


Zuurix 2 years, 7 months ago

Voted. (email)

spike1 2 years, 7 months ago

Doubt it's helpful, but I would vote email if I had an account. With that being said I've been watching its progress from here :P, and it looks like a very competent library. I wish I could say more but I don't use Gamemaker, anyway good luck with its continuation! Also that is a very snazzy looking page :D.

DesertFox 2 years, 6 months ago

I don't twit, but my vote is github / source control notification.

Alert Games 2 years, 6 months ago

yay thanks guys. Looks like i'll still do the usual stuff, posting on twitter (and github can send out notifications itself). But I suppose I'll also focus on setting up a distribution email system that people can subscribe to as well.

I'd like it to just link to a profile, but my guess is that some people won't want to sign up yet and would prefer just submitting an email for updates for now. cool.

Crazy Star 2 years, 6 months ago

Neat progress, I vote Twitter though I use it a bit sparingly ;

The GMUI page could have click-image-zoom feature for old guys with bad sight like me.

I'm working on a GUI as well actually, although progress has been slow recently. If you're interested, find it here:

Alert Games 2 years, 6 months ago

Actually working on the image zoom feature right now, but thanks for the feedback, I'll know someone will make use of it

Interesting project. Did you end up buying the full version of GM Studio 2?

Feel free to check out my GUI project and compare it, I'm trying to make the best possible open-source framework and am not afraid of a little constructive criticism if you don't mind!

Crazy Star 2 years, 6 months ago

Yeah I'm using Studio 2 in a collaborate project and ended up starting some side projects too since I was at it anyway. I think it's a great improvement over previous versions. And I haven't installed any others unfortunately.

I'll list some suggestions, some which you may already have thought of yourself.

- It's not very stylish to look at. This might scare some people away. You could try rounding the corners, adding some colors, skins, whatever. I see you have "themes" planned. This is good.

- It could be a bit confusing to some that when skimming through the presentation there is so much code. This sort of thing should be as condensed as possible. Something just showing a minimal example. I like how all components are listed in a script to begin with and then handled by the UI. It might be better if the create event simply called the script and nothing more, and the script in turn called GMUI_init() (which could have some checking if it had already been run if necessary but idk).

- You should have more examples than just the one with everything in it. This would show how powerful it is and better demonstrate how do do specific tasks.

- Could this work as an overlay, or does mouse clicks etc migrate? Maybe demonstrate how that would work, because I feel that's a very important part of UIs.

- The set of controls are really nice, and have some impressive features like the switch for instance. When playing around with it I noticed how the text input keeps following the mouse until you press the button in the bottom. It's cool how the inputs are editable even if they have buttons. It even supports the Danish alphabet =)

I would like to move the caret though.

- I'm a bit confused still as to what this can actually do, and how large it is, since I haven't looked at the GM project.

- I'm also a bit confused about how things are grouped together and what can be done in that regard, just by looking at the GIF (there are no borders). Looking at the code gives hints but it isn't exactly clear and obvious.

Overall I like what I'm seeing. Even if I'm not always sure what I'm seeing. I'm also seeing lots of things that are still missing before this is practical to use.

Oh, and I actually made a great deal of improvements to ScaleUI since I uploaded last. Thanks for checking that out too.

Alert Games 2 years, 6 months ago

Thanks! Really appreciate the analysis of it, it will help a lot to figure out the best way to showcase the functionality i've been working on.

On the first point, unfortunately, it probably won't get a whole lot more stylish from me lol. I may need some assistance in creating some of the first "themes" when it is released I'll admit. I might be able to create some simple examples like plain white & colors or something, but nothing too extravagant.

Hmmmm, yeah I'll have to figure out a better way to showcase the code. As for the initialization, I can see where you are coming from on that but I don't know a way to do that in GML… (for GMS 1.x or GM8) unless I hardcode the variable name. The init script sets up an identifier global that gets assigned to each 'grid' you create. But perhaps I could include the check inside of the script to see if it was called already at least… EDIT: Or I could include the call with the object as a parameter to assign it and its properties…. That could work, yeah

I'll also have to explore ways to demonstrate is more advanced capabilities, yea.

Could this work as an overlay, or does mouse clicks etc migrate?
Could you elaborate on this? Not sure what you mean by 'migrate'… But it doesn't consume a mouse click at the moment, so a click would work on anything else, except within GMUI it is layer-based.

Thanks. I figured the caret wouldn't be a crucial feature for now, but I'll definitely put it down. I've done it before in particle designer, but it takes a little bit of effort to do correctly.

Codebase is relatively large, but is broken down in folders in the repo. Basically I separated the user-defined script folders from the framework, then also kept the internal scripts separate from what a developer would use.

As for grouping, right now you create a group then call a script to add a control to a group. I might change the method that it is done, but I'll have to see if it makes the code better or worse. Same with layering. You can draw borders and backgrounds, or even use a sprite map, but I don't really have it in the demo at the moment. The menus are currently drawn with rounded rectangles.

Thanks again for the review, I'll take a look at the changes you've made to yours as well

Crazy Star 2 years, 6 months ago


My changes aren't live so don't bother looking yet ^^

Not that there's much to look at. It's basically this:

I kinda feel very inspired but I'm kinda also working on something else.

Oh, and migrate is a word I think they use in wxWidgets for just that - consuming events so they don't keep on happening.

In Scale I use
whenever I capture the mouse, but you could also just set a flag that the user would be able to read if the mouse has been consumed. I find it rather useful, dunno if you noticed in the beginning of my YT tut about extending (which is now outdated) I click the background and circles appear to show that something outside the UI was clicked.

Since I'm at it anyway and since you might find it useful I'll share some more details of what I did.

I have a single script for all events. This keeps everything clean and simple for the user. I use a single object (that's how often do things in GM) for the UI, but I'm considering separating that into two, now that I think of it, a demo obj and the UI object in which the demo interacts. I keep initialization rather small and have all components use the same scripts as if they were custom user extensions. This keeps it lightweight and, again, simple.

Another thing I found useful was to store properties as well as scripts in ds_map's so they can be handled using stings. This makes it easy for the user to do stuff:

ui_set(button2, "action", click_button2);

Hope this gives you ideas too =)

Alert Games 2 years, 6 months ago

Hey thats pretty neat.

Ah yes okay now I know what you mean by capturing the mouse. I think I will make that an optional setting.

I did notice your single script for setting attributes of each component, which I think I will add in. I was planning on doing something similar anyway, but instead of a load of "overloaded" scripts, I might as well just keep the shortcut scripts and add in a individual setting script that works for anything.

The initialization I think I have an idea based off of your approach to the events but also to instantiate from the calling code. Could be good.

I'm thinking a lot of good stuff will come out of this. Guess you'll have to stay tuned for the next update :thumbsup: