Actor Colour self Attribute
fmakawa
Member Posts: 565
HI folks,
So I've just realised that within GS colour attributes for red, blue and green dont use the format where the values have a range from 0-255 but rather 0-1. How do I convert my RGB Values? I've divided by 255 just to see if that how its done and that didn't work either. Perhaps I am being a dunce (nothing new).
Help!
Comments
self.Color.Red = (your 0 to 255 value)/255
That should've worked, it's just maths.
Example:
Change Red to 128/255 . . . . will give you 0.5
So if you want to use 8bit values (0-255), simply divide by 255 to scale the range to 0-1.
@KevinCross tried that no responsive. just getting either white or black
Can you upload a screenshot of the rule you are using ?
@Socks The first screen got me a white object.
When I used the formula as shown it got me a black object. I've also included the table where it is meant to be deriving the values from.
Formula - deriving RGB value from a table
Table
You probably just typed the equation into the box, instead of the equation field (by pressing the 'e' first) ?
Not enough information to comment.
Try throwing another set of parentheses around the tableCellValue. Not sure if that will matter but it's worth a shot.
Instead of tableCellValue(table,row,col)/255
Try (tableCellValue(table,row,col))/255
New to GameSalad? (FAQs) | Tutorials | Templates | Greenleaf Games | Educator & Certified GameSalad User
Nope, I used the expression editor. deleted it and tried again. Its odd really.
@tatiang Tried that and still nothing! so weird. If input values between 0 and 1 then it works fine but formulas not registering for some reason
Yes, strange, you are doing it exactly right, so I'm not sure what to suggest, perhaps you have a corrupt file ?
As a workaround you can of course just enter the 0-1 range values, so 175/255 would be 0.68.
@Socks Yeah but I will working with a lot of colours hence the table. I've pegged about 16 colours already and there will be more as I work the individual scenes. Adding rules for each colour is going to be taxing.
Is game.BG Spawn Colour getting given a value correctly?
Perhaps break the table and a logic to recolour the actor off into a new project. It'll help you test if there's something else causing problems in your project, and will provide a handy demo to post here to be looked at if the problem persists.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
There would be no additional rules, you would simply be using the 0-1 range value were you were previously using the 8bit/255 value.
There would be no additional rules, you would simply be using the 0-1 range value were you were previously using the 8bit/255 value.
I meant that I was going to be placing rules that recognised each and every colour change without using a table. To still use the table I suppose I would to have calculated the values before exporting it to GS. No biggy
I solved it thanks to @Armelline 's suggestion. Turns out I need to constrain it to the formula and there was conflicting code which disappeared once I removed everything to make a demo of the issue. Thanks guys!
I'm not 100% sure I follow ?
You were at a position where you were going to use X/255, this didn't work (even though you set it all up correctly), my suggestion was that you simply do the calculation yourself, so for example instead of using '175/255' you would use '0.68'.
Regardless of whether this takes place in a rule or behaviour or table it puts no additional strain on your project ("Adding rules for each colour is going to be taxing"), as you are not replacing rules for tables or tables for rules, you are just changing one value - wherever it's applied - for another, if you use tables then stick with tables but just swap the 8bit/255 value for its 0-1 range equivalent, if you are using rules then stick with rules but just swap the 8bit/255 value for its 0-1 range equivalent.
In fact this puts fractionally less strain on your project as you are removing a calculation (the division into 255).
Hope that makes sense !
Depending on how you have this set up this might be an inefficient way of working, a constrain fires 60 times a second, a change attribute fires only once, so whereas change attribute colour.red to X will fire once on a single code cycle, constrain attribute colour.red to X will fire 60 times a second, every second . . . so, for example, after 10 seconds that's 1 call versus 600 calls.
But like I say, maybe you've set this up so the constrain only operates for a short period, but just something to be aware of.
@Socks yes it does. Thanks! And I didn't know that about the constraints!
I think he was using change attributes and his code was triggering in other places and changing it back. Make sure you watch out for cross logic. You should watch my GSlogic series.
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS