The Accuracy of Numbers

RacetotheMoon

I'm curious about the accuracy of numbers in Game Salad.

In the project I'm working on I'm attempting to set the individual RGB values of an actor to numbers I've specified. Once all three values are set, a process fires. So far however, I can't seem to get my code to return iron clad results. As such, I can't reliably fire the process at then end because the blending routine doesn't always finish.

The problem is actually two fold.

First problem is getting the values to always come to stop. In some instances, the values of a channel reach a point where it ends up 'straddling' the specified stop point. (I created a little debug viewer so I can see the object's self.color.##### as it blends from one value to the next.) Since it never gets to the value, the process doesn't turn off. So that means, after I give it a new color command it'll adjust that new channel to the value, thus compounding the problem.

Second problem is that my numbers seem to be stopping .08 away from where I need them. So for example, if I'm trying to get .34, and I'm coming down from 1, it'll actually stop at .42 and fire the process telling the game that blending has stopped for that channel. This then leaves me with inaccurate colors, so is also a bit of a drag.

I've tried a number of things in attempts to mitigate this happening, such as playing with the increment the RGB values step through, the time over which it took place, reducing the number of decimal places.. I even tried setting all values (increments and targets) to even numbers so that that it had 'less numbers' to step through, but even then the process 'miscounted'' and returned a value it wasn't 'expecting'.

When the value gets to a point where it should stop counting, ie. the target. It straddles the number and fires continually based on time interval set up by the timer. This results in a flickering of the image and is the main reason I split up the process like this in the first place. I originally had only one process, but when I noticed the flicker I decided to take it a step further to ensure a smoother blend.

I've been searching for about a day so I figured it was time to ask the community. From what I've been able to find, it appears there might be a small issue with number accuracy in Game Salad, but I'd rather not blame the tool.

Perhaps there's an expression that can be written to accept a range of numbers? (ie. .34 -.36) Perhaps something else? Ultimately, I'd like to do this right way first before looking for workarounds. Any help from the community is greatly appreciated. Below is the code I'm using. It's based off the fade in/out example.

Code:
When key 0 is down (this calls the change)
--- Change Attribute game.color00 to True
--- Otherwise game.color00 is False

When game.color00 is True
--- Change Attribute self.nextRedValue to 0
--- Change Attribute self.nextGreenValue to.25
--- Change Attribute self.nextBlueValue to.34
--- Change Attribute game.colorBlendR
--- Change Attribute game.colorBlendG
--- Change Attribute game.colorBlendB

When game.colorBlendR is True
--- Change Attribute game.blendingR
----- When self.nextRedValue > self.Color.Red
------- Timer: Every .01 Change Attribute self.Color.Red to self.Color.Red+.01
------- Otherwise Change Attribute self.Color.Red to self.Color.Red-.01

When self.nextRedValue = self.Color.Red
--- Change Attribute game.colorBlendR to False
--- Change Attribute game.blendingR to False

Notes:
I left out the code for the G and B values, and changing to other colors, as it is the same.

firemaplegames

you can use the MAX and MIN functions in the expression editor to lock down the limits, so it won't overshoot your targets, like this:

------- Timer: Every .01 Change Attribute self.Color.Red to: min(self.nextRedValue,self.Color.Red+.01)

That will always choose the lower of the two numbers.
That SHOULD do the trick.
Let me know if it doesn't and I'll try to think of something else!

rebump

In other situations, you'll find "ceil()" and "floor()" to come in handy when you want some exactness...so to speak.

Also, related to FMG's example, there is also "max()".

RacetotheMoon

I tried your example FMG.

When I added that, coupled with a 'Greater Than or Equals to' instead of plain "Greater Than' I stopped getting straddles, However now I am experiencing some other, strange and less predictable, results. Such as the values 'snapping to' the value or the stopBlend process not firing even though the value had been reached. I really don't see why the equation you supplied should be giving these results, it looks like it makes perfect sense.

I'm still getting an offset of .08 in nearly all occurrences, and can't find what might be stopping the math before it gets to the number.

I'm going to play around with this some more plus research the "floor()" and "ceil()" expressions and see if I can't make it work proper. If not, I may be posting an example as a shared project in the morning.

firemaplegames

hmmm.

yeah, I'm getting frustrated with things MOSTLY working also...

Another possible thing to try, because your numbers are so small, is to multiply them by let's say a 1000.
Do the calculation on the larger number, then divide it back down before you apply it.

I don't know if it will work though, i just made it up!

I am at the same point with my own project, that I am now trying to create hacks so things will ALWAYS behave properly, not 98 out of 100 times...

RacetotheMoon

yeah. I was actually wondering if something like that was possible.. Since I have no problem simply changing the value to a specific number and figured doing the calculation on integers might be cleaner in the engine. I think the downfall to the theory is however that I'm looking to visually capture the blend and if I'm not doing the calculation on self.color.##### then It'll just pop as if I manually changed the value.