I'm trying to do something really simple:
I got two images for my button. The one image should be displayed initially and once the mouse hovers over the button, the other image should be displayed, until the mouse leaves the button.
So far I'm doing it like this:
I defined an Animation for each state and the corresponding transistions inside an AnimationSet. In my update function I constantly pick (orxObject_Pick) the object under the mouse and check if it's one of my buttons. If so, I set the target animation accordingly. In order to change back to the normal button image, once the mouse leaves the button, I have to store the currently highlighted object. So once a object other then the highlighted object is picked, I will set the target animation back to the normal button.
Well this works, but it involves quite a lot of code and configuration(defining animations etc.). If it were only for one button, I wouldn't mind. However I got quite many buttons, so it's kind of annoying. So I wanted to ask you guys, if you know a simpler way of achieving the same functionality?
If you take a look to (the now outdated) MushroomStew editor (aka ScrollEd), I handle buttons in a generic way.
Each button, in his config section, gives the name of its highlight state, active state and action.
If you look at ScrollEd::UpdateButtons() method in ScrollEd.inl, there's a short generic code that will enable or not the highlight for all the buttons (which will then be displayed in front of the base one).
There's also code for enabling the active version of a button if the associated input has been triggered so that its state will always be synchronized with the action. This part of code is in the event handler, when handling input events.
It's probably not the best solution but it works just fine, is generic (in the sense that I can add or not a button for any defined input in the editor without having to touch the code at all).
The config info is in /data/scrolled/ui.ini
For example, here's how a button is defined in config:
As you can see, I'm using the same prefix here for all the buttons info, so instead of writing everything by hand in the config file, I could have automated all this as a loading step at runtime.
Let me know if something doesn't look clear or if you have any suggestion to make all this better.
I wrote some tutorial about how I did it:
I'm not good at writing tutorials... but maybe it helps someone!
I added syntax highlighting to your tutorial, if you would like I can do some work on it and make it into a working example? Perhaps following the same style as my own tutorials (Pics and all? ^_^)
I also saw the percentage2color one and I have 2 suggestions:
- You can use .fR/.fG/.fB to access the fields, which might be more intuitive than .fX/.fY/.fZ;
- You can use different color spaces that are more suited for this kind of color manipulation (namely HSL and/or HSV). Orx provides functions to convert HSV<->RGB and HSL<->RGB: orxColor_FromHSVToRGB, orxColor_FromRGBToHSV, orxColor_FromHSLToRGB, orxColor_FromRGBToHSL. You'd then access the field with .fH/.fS/.fV/.fL.
So when you set the color of the orxobject, then it's expected that it is in RGB, right?
so I would have to set the HSL values, then convert it and then set it. or could I use HSL directly?
Yep, you're right. All the orx*_SetColor() expect RGB format (unless you have a custom shader you wrote that explicitely require another color space ^^). So you'd set HSL/HSV values then convert them before applying them to your object.