-
Can you tell how much time you want the counter to last, and how would you like its size to be?
(ex. in 20 seconds, fill a screen of 640 pixels)
Floating point values are, in short, decimal point values:
0.12345 = float
1436.35 = float
134 = integer
it seems, at least to my testing, that bar counters, though effectively doing correct math upon them,
refuses to graphically represent other values than integers XD
-
Schrodinger,
It's for that card flipping game that you helped me with. At the start of the game, the counter will start filling. I'm at work currently. I wish I would've timed it. I would say 2 minutes should be enough to match 9 pairs? The counter is 466=x 22=y. I'll test it tonight to get an exact timing and update. Thanks.
Thanks for the math lesson. ;D
-
1 Attachment(s)
Well, two minutes is a long run for a single counter, in a hypotetical area of 640 pixels
EDIT >> I was saying "if you can't represent floats" but floats in this case are unappliable, since counter max value is much greater than bar pixel size!
This means that in 640 pixels you can stuff in, at minimum interval of 1/100 second
(and if you go at a frame rate of 60 fps, no matter what, they will transform in 1/60 second!)
about 1 pixel every 11/60 th second
Following a one - and three counters solution representing two minutes at 60 fps...
Attachment 16218
if you want smoothness, you'll have to grow in size :(
-
Oh, if you want to change elapsed time, use this formula:
single counter solution: set maximum value to 60*total seconds
three counters solution: (obviously) set each counter's maximum value to (60*total seconds) / 3
-
1 Attachment(s)
Thanks for checking Snail! :)
I generally prefer counters over actives for this kind of jobs due to the built-in gradient effect,
that gives a sense of "approaching to full/empty",
to achieve a similar effect within actives you'd have to setup a routine for "cutting" it (-->active picture)
because scaling would also scale the gradient image.
@ Emerson3: I woke up this morning with another example in mind already built :o,
and I've now added to the ones above, so here it is:
Attachment 16221
Gives a nice snake/"powder keg" effect,
and decreasing from full gives a harder tragic sense of panic, rather than increasing from 0 XD!
This example also led me to notice that,
while refreshing every 0.01 seconds the timers/counters keeps on par with real time (and debugger time)
---meaning that at 60 fps on each frame real time grows by 1/60=0.01666666... seconds---
doing so each 1 second causes a noticeable lag between the timer and real time! :O
Thus I would assume that every 1 second is not a reliable timing event on the long run?
(see example)
Maybe altering fps could fix this, but I've not tested.
(Emerson you can obviously neglect this issue for your application ;D)
-
Hey Schro,
I used the one counter example set at 2400 max. I created event "Every 0.3 add 1 to counter. Its working great. I just saw your last message so I'm excited to get home and check out the new example. I'm going to post my MFA file so you can see it in action. Hee-Haw!!! :D
-
I find the active approach to give more flexibility on the visual style of the bar. You can paint your own gradient, which won't get stretched if you make the bar the right thickness from the start. You only scale on one axis, so nothing would be distorted, unless you wanted the gradient to go along the length of the bar. But with an active, you can animate the bar, which allows for flashing or other effects like an animated gradient. But to each his own. :)
-
Thanks Snail,
Ya'll are giving me so many examples! Can't wait to get home and check em out!