Unhovered SetScreenVariable("tt_val", "") Imagebutton auto "gui/menu/confirm_%s.png": screen confirm(message, yes_action, no_action): In this case, we only have one screen (the confirmation dialogue itself) and attach transforms directly to text elements within it. This is definitely not ideal, but it does work. Instead, I kind of hacked around the problem, using simple text elements that are rendered (or not) based on the state, and attaching ATL effects to them. While this does indeed show the screen, it also strangely results in the screen being shown twice: Once next to the buttons as expected, but again in the top left corner of the screen on hover. I tried a few different things for this… the most naive approach was to copy the above approach, and use the “ use confirm_tooltip” to include the screen next to the buttons. What happens now when we’re dealing with a modal screen (like the confirmation dialogue) that isn’t always located at a consistent place on the screen? We can’t exactly place the text at a certain x/y coordinate and expect it to look right all the time. In particular, the location of the tooltip screen’s text was hardcoded to be placed next to the menu buttons. So this is all well and good… but notice that we’ve had to hardcode the position of everything above. Hovered Show("mm_tooltip",ttcontent="Quit") Hovered Show("mm_tooltip",ttcontent="Preferences") Imagebutton auto "gui/menu/prefs_%s.png": Hovered Show("mm_tooltip",ttcontent="About") Imagebutton auto "gui/menu/about_%s.png": Hovered Show("mm_tooltip",ttcontent="Load") Hovered Show("mm_tooltip",ttcontent="Save") Hovered Show("mm_tooltip",ttcontent="History")Īction Imagebutton auto "gui/menu/history_%s.png": Hovered Show("mm_tooltip",ttcontent="Main Menu") Hovered Show("mm_tooltip",ttcontent="Return") Imagebutton auto "gui/menu/return_%s.png": (I’ve also added ATL effects, not shown above, to the buttons themselves so they fade in and out, in addition to the tooltip text.) screen game_navigation(): You can lay them out however you want, but the important part is the “ Show” action for their hover attributes. Next are the actual menu items themselves. Transform mm_tooltip_show(delaytimer=0.0, duration=0.25): Xanchor 1.0 yanchor 1.0 ypos 1035 xsize 300 ysize 100 In this case, the tooltip fades in as it moves leftward out of the buttons, and fades out as it moves rightward back into the buttons. I believe this is also the more “traditional” way of doing tooltips.įirst thing’s first: We’ll need to define a screen to hold the tooltip text and a transform to show and hide it. You can even apply AT effects to the tooltip to make it fade out or whatever. This is fairly straightforward to do in the quick menu/game menu case, where the location of the tooltip is fixed. Part of the GUI work I did for Xenopathy was converting traditional buttons (in the quick menu, game menus, and confirmation screen, for example) into images, with hover tooltips that provide an explanation. Posted by admin JDecemPosted in Main Tags: updates, xenos, yaoijam Leave a comment on Xenopathy: Week One Codes: Hover Tooltips, Two Ways
My goal is to have a super rough draft of the first half of the game done, and possibly also some further GUI cleanup. Next week is likely to be more of the same. We’re also 7000+ words into it, so that’s some decent progress. We have a (very) rough draft of day one, along with the beginning of day 2.
We got a few different variants to start the conversation on character design, and got to a rough sprite for him, but he’s already looking amazing!Īs for me, after getting some stuff done on the GUI, I’ve mostly been writing. There’s not a lot to directly show there, but suffice to say, this is probably the largest part of what’s gotten done over the past been hard at work on the first sprite, Axton. We’re one “week” into Yaoijam (only because we started early), and we’ve made a lot of great been doing a lot of research, story planning, and world-building.
0 kommentar(er)
