Colored Timer Class

Java 2D
#1

Hi all, an open question:

I am trying to create a visual timer for a game. Basically, it displays an ever-shrinking colored bar to tell you how much time you have left. I would like the bar to constantly change color from green (plenty of time) to yellow to red (almost no time left) depending on the situation. I currently have my tick() method producing RGB values that properly express the time remaining.

But that way, I have to allocate a new Color each tick. I am currently just using g.setColor() and then g.drawRect() to update the appearance of the timer. Should I worry about this? (ie - are Color objects at all expensive?) And does anyone know of a better way? I assume there must be a reason why Color doesn’t have setR(), setG() and setB() methods…Thanks for any help.

#2

If you are worried about the object creation, i suggest you pre-render the bar to a suitably sized image.

It is then simply a case of drawing the pre-rendered image with an appropriate clip area set.

So as the timer decreases, you simply decrease the width of the clip rectangle.

#3

Ahhh, very interesting. But how do I control the color of the bar? Pre-rendering 255 * 255 colored bars doesn’t sounds any more appealing than allocating that many Color objects. Am I missing something?

Thank you for your help.

#4

no, pre-render it to an image.


final int barWidth = 40,barCentre = barWidth/2, barHeight = 10, barX = 40,barY = 40;

BufferedImage timerImage = gc.createCompatibleImage(barWidth,barHeight,Transparency.OPAQUE);
Graphics g = timerImage.createGraphics();
for(int i = 0;i < barWidth;i++)
{
    g.setColor( (i<=barCentre)?
                       new Color(255,(i*255)/barCentre,0):
                       new Color(((barWidth-(i+1))*255)/barCentre,255,0));
    g.fillRect(i,0,1,barHeight);
}

float timerProgress = 1.0f;
/* in your drawLoop */

g.setClip(barX,barY,(int)(barWidth*timerProgress),barHeight);
g.drawImage(timerImage,barX,barY,null);
timerProgress-=0.01;
#5

I won’t use fading colors for that.

Simply because the colors shows a somewhat guessed value and the numbers/length of the bar shows the actual value.

Switching between 2 or 3 colors makes much more sense, because you can see the rough value without looking at/focussing it. The color should prevent changing focus - it’s useless if you still have to do that.

Center of focus: shape recognition(eg reading), color, brightness, motion
A bit to the side: color, brightness, motion
More to the side: brightness, motion
Even more to the side: motion only

#6

eek,

ph33r the HCI ;D

#7

Hmmm…good point oNyx. Guess I’ll be saving that code for a rainy day. :stuck_out_tongue: Thanks Abuse!

#8

[quote]But how do I control the color of the bar? Pre-rendering 255 * 255 colored bars doesn’t sounds any more appealing than allocating that many Color objects. Am I missing something?
[/quote]
No, you are completely right. And drawImage() for sure is slower than fillRect(). And I suppose it is far slower than creating a Color object.

I wouldn’t mind creating on Color object per frame.

If you still do, precreate a Color[] table.

#9

um yeah, fillRect is faster than drawImage.

but 1 setClip + 1 drawImage() is much faster than barWidth fillRect()s + barWidth new Color()s.

#10

sure - but as far as I understood, the bar should be of only one color at any time…

If not ---- what about a gradient? Very smooth in Java2D…

#11

ahhhhh.

Just re-read the 1st post… and he didn’t want a gradient fill anyways… DOH!

If thats the case, then the problem was trivial :wink:

p.s.
I didn’t use GradientPaint 'cos… well… in terms of speed its a pile of **** ::slight_smile:
Its totally unsuitable for realtime execution.
(though I s’pose I could have used it for the pre-render example; would have still been atleast as much code though)