Store and Modify a Colour with Code: Possible? How?
-
@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.
-
@GameCRAZY Let me try to explain why your claim that a label will help is wrong, so you can see why it is that I'm telling you it's wrong, and you might understand why you feel the way you currently do.
You said you know a little Swift, that will help understand this.
Swift is an incredibly type strict language, for reasons Chris Lattner had in mind for the future that will now never be: Namely, that Swift should be the next language used to make the next operating system. But Swift still has convenience handlers, like printing a line to the console.
If you print something to the console, with Swift, looking at the output, you can't tell what type it is. It doesn't show. Just the content does (in most cases).
So an Int, Int64, Vector, String, Hex number, they all look the same.
If you show a label of a Hex number it's going to look EXACTLY the same as a label of the same figures as a string. The label doesn't help you know what type something is because it just makes a best effort to output something.
AND, @Thecheater887 had already isolated anything else the label could tell us as not being useful... he'd already done a round test to find where exactly his "code" was failing.
When you continued to press for your claim that a label would help, in the face of it being wrong twice, I pushed back.
If you feel hurt, or anything else, that's a result of pushing on something that is probably wrong.
-
@Deeeds I don't feel hurt... No, I just wanted a proper explanation, and I thought it was worth trying.
