Store and Modify a Colour with Code: Possible? How?
-
@Thecheater887 Tried what? What went wrong?
-
@Aidan-Oxley Forming and using a color.
I start with “#” stored in a box container.
I then generate 6 random numbers and append them to the box container, so it should read like “#1F390C” thus far. I then append FF for 100% opacity.
Output that to a change color, and my logic all the sudden doesn’t run by it, when with a standard-typed #FFFFFFFF or anything else functions normally.
-
@Thecheater887 Can you please provide a link?
Otherwise, try debugging. Make a label, and after each behavior make sure the hex code is proper. Also make sure each behavior is being triggered.
-
Read this sentence more carefully:
Output that to a change color, and my logic all the sudden doesn’t run by it, when with a standard-typed #FFFFFFFF or anything else functions normally.
He's already debugged it and isolated the problem to the conversion of a Box Container's storage to a Set Colour's capacity to receive what's stored. This is, most likely, due to mismatched data types. The Box Container has probably stored a String (almost certainly) from his modifications (appends are probably defaulting to being done as strings) whilst the Set Colour is imagining it's going to receive a hexadecimal data type.
For some reason, Box Containers seem to be storing a hexadecimal when manually entering #FFFFFFFF. That's why this weird. This has been partially considered. But not wholly. Features that could/should have been there include dynamic RGB/HSL entry/modifications possible in code, too, and an easy way to alter opacity levels dynamically, too, in isolation from all other aspects of a colour. Hue shifting would be enormously assistive, in its own right, for all manner of effects and level articulation.
-
Look through Jack8680’s Hub projects, he has a working colour manipulator.
-
@Aidan-Oxley Which doesn't address the problem.
There is no simple, elegant and/or nicely abstracted way to store, edit and utilise dynamic colours.
In a 2D game engine...
...without Sprite Animations, Sprite Sequences, Bitmap fonts or other forms of frame based animation.
-
@Deeeds Jack’s project converts a bunch of percentages into hexadecimal code and then sets an object (the entire background) to that colour. Unless hyperPad released an update that broke this, it proves you can store and manipulate colour codes and then set an object to the colour you want. EDIT: Oh, you meant simple and elegant (missed a few words read too fast), yeah not too simple needs a bunch of maths I think.
-
@Aidan-Oxley fixed... see above ^
-
@Deeeds So what you really want then is hyperPad to be able to do maths in hexadecimal then? And convert bases?
-
@Aidan-Oxley
No.
I want an easy, elegant, simple and nicely abstracted way to dynamically adjust colours and alpha.
Saturation, Hue, Brightness and Alpha should be separable and operable upon independently. That's part of being NICE and abstracted. etc...
-
@Deeeds You can still output that string to a label!
-
@GameCRAZY Labels aren't much use to the process of modifying a colour.
-
@Deeeds Just check WHAT the string is, and work with that information!
-
@GameCRAZY IT IS A STRING!!!
That IS the problem.
-
@GameCRAZY do you know what I mean if I say "different data types?"
-
@Deeeds Yes, but you can still work with strings. I do know some Swift.
-
@GameCRAZY If you don't have access to type casting, nor can you set a type, then once data has had its type changed by the system (hyperPad) and it's no longer compatible with the data required of colouring something (what we're speculating is happening here) then that is the problem.
So labels of no use.
-
@Deeeds The label is only checking whether it's actually a string.
-
@GameCRAZY hyperPad implicitly converts everything to the needed data type at runtime.
-
@GameCRAZY No, the label makes a best effort to show what it can. It's not a type checking mechanism, it's a type handling mechanism.
And your contention, from the beginning, that both debugging by a label and that a label are somehow necessary are both wrongheaded. And you've continued to try to back that. That's why you're in a loop.
Just let that idea go. Labels cannot help, in this situation, and theCheater has already isolated anything a label could tell us.