Post by berserkjeff in Emu - UI for GameMaker comments

Viewing post in Emu - UI for GameMaker comments

tldr: Couple changes needed for Android. Performance isn't spectacular but good enough especially if you don't use a lot of elements.

-----

Overall Emu UI is hands down my favourite UI framework out there for Gamemaker. It looks good. The learning curve isn't bad. Adding new element types is easy. There are a few hardcoded variables you need to change around sizing and padding for a small canvas size like mine (180 x 320) but totally doable. There's also a few functions you need to adjust if you are scaling your game size. If it came with a few extra element types such as a drop-down selection it'd be perfect and as is it is still pretty darn good—especially compared to it's competition on the Gamemaker marketplace, blows everything there out of the water.

You do need to make a couple changes for Android. For example, you need to swap out window_get_mouse_x/y() in the getMouseHover method and a few other places for mouse_x/y or another alternative as the function doesn't work with touch input. Clicking on textboxes also doesn't prompt a keyboard to appear.

Performance is good enough imo. I'm testing it on a Samsung Note 9 and my game, with 0 optimization, gets around 60~ fps with menus/text only going down to 58~ when I draw my sprite-stacked tank.

Performance does steadily drop as you add more elements. I'm not too worried though, with a menu-based game like mine fps doesn't matter too much and I'm probably going to default the game settings to a battery-friendly 30 fps mode anyway on Android. Either way my code has plenty of room for optimization down the line.

For example this EmuDialog: https://imgur.com/rC8y6LG contains 1 EmuButton and 18 EmuText elements (the sprites are being rendered by scribble as part of the EmuTexts' values and are not the fps drop cause) and costs my Note 9 a consistent 5 fps to display. My high-end gaming pc has no issue getting and keeping 144 (fps_real of 500 that drops to 300 with that dialog) while my pretty old non-gaming laptop can touch 144 but drops down to 130~ with that dialog open.

Fair bit of room for optimization though, like I can bring that dialog container down to 4 text elements instead of 18 fairly easily but it does show how performance will degrade with additional elements.

Making a drop-down element is next up on my todo list once I think of how to prevent double-clicking on elements below a list without having to disable any elements.

Dragonite3 years ago

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.

berserkjeff3 years ago (4 edits)

Hey thanks for the response! Anchor points would be a cool addition.

The issue with using scaling and Emu Dialog is just getting the mouse position. With my project I could simply swap out window_mouse_get_x/y() for mouse_x/y everywhere as well as window_width/height for room_width/height in EmuDialog, solving both the Android click detection issue and the mouse position issue. Other's will need a different solution if they have camera movement.

Another common problem I've had is with updating variables for EmuText and progress bars. This is mostly, at least with the progress bar, a problem for me because a lot of my elements are created dynamically my functions can't be fully explicit like in the demo. One of my band-aid solutions was to add an assigned_index value to EmuProgressBar.

I derived an EmuTable and EmuDropDown element from EmuList. EmuTable was straightforward but there were a few hurdles with adding a Drop down selection element. Firstly, ui elements created after the drop down render over it, so I made a one_time_surfaces variable in my obj_camera that will render a surface in the draw end event then delete them. Instead of rendering it's own surface, EmuDropDown just passes its surface to that variable. The second issue was clicking on a drop down option would also activate any element below that selection. This could be avoided by making GetMousePressed/Released check for any surfaces in obj_camera.one_time_surfaces not owned by the calling object.

I do really like Emu Overlay and am quite happy to have found it!

Dragonite3 years ago

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.

itch.io

Viewing post in Emu - UI for GameMaker comments