gauge.lua bugs

Posted by Fiendish on Sun 21 Nov 2010 04:17 AM — 8 posts, 21,947 views.

Fiendish USA Global Moderator Sun 21 Nov 2010 04:17 AM #0

gauge.lua draws the bar wider than the border
So

local gauge_width = width * Fraction

should be

local gauge_width = (width-2) * Fraction

Also, the hotspots don't get redone if the miniwindow is resized and the gauges are redrawn in different places.
So


-- mouse-over information: add hotspot if not there
if not WindowHotspotInfo(win, name, 1) then
   WindowAddHotspot (win, name, left, top, left + width, top + height, "", "", "", "", "", "", 0, 0)
end -- if

should just be


-- mouse-over information: add hotspot
WindowAddHotspot (win, name, left, top, left + width, top + height,"", "", "", "", "", "", 0, 0)

Fiendish USA Global Moderator Sun 21 Nov 2010 04:35 AM #1

Also, the gradient content is off by a pixel, so I think that


-- top half
WindowGradient (win, left, top, 
            left + gauge_width, top + height / 2, 
            0x000000, -- black
            fg_colour, 2)  -- vertical top to bottom

should be


-- top half
WindowGradient (win, left, top-1, 
            left + gauge_width, top + height / 2, 
            0x000000, -- black
            fg_colour, 2)  -- vertical top to bottom

Nick Gammon Australia Forum Administrator Sun 21 Nov 2010 04:41 AM #2

Fixed in version 4.71, thanks!

Fiendish USA Global Moderator Mon 13 Dec 2010 02:38 PM #3

I don't see a change to the top half windowgradient in 4.71's version

Nick Gammon Australia Forum Administrator Mon 13 Dec 2010 09:18 PM #4

It doesn't seem off by 1 to me.

Code to reproduce:


win = "test"

WindowCreate (win , 
  0, -- left
  0, -- top
  200, -- width
  200, -- height
  miniwin.pos_top_left, -- mode
  0, -- flags
  ColourNameToRGB ("navajowhite"))

 WindowRectOp (win, miniwin.rect_frame, 10, 10, 50, 50, ColourNameToRGB ("red"))
 

 WindowGradient (win, 10, 10, 50, 50, 
                    ColourNameToRGB ("green"),
                    ColourNameToRGB ("blue"), 2)


 WindowRectOp (win, miniwin.rect_frame, 10, 10, 50, 50, ColourNameToRGB ("cyan"))
 

require "gauge"

gauge (win,    
        "hp",                  
        50, 100,              
        10, 60, 40, 20,  
        ColourNameToRGB ("green"), 
        ColourNameToRGB ("red"),       
        0, 0x000000,       
        ColourNameToRGB ("cyan"),           
        nil)             

 WindowShow (win  , true)

Nick Gammon Australia Forum Administrator Tue 14 Dec 2010 03:06 AM #5

I did another test with a 10 x 10 gauge (rest of the above code the same), that is:


gauge (win,    
        "hp",                  
        50, 100,              
        10, 60, 10, 10,  
...

Then zooming in with Photoshop, I see this:

The box is exactly 10 x 10 pixels (one pixel border, 8 pixels in the middle for the gradient). There doesn't seem to be any rogue pixels in there. The gradient is a bit different on the bottom to the top, but I put that down to rounding errors when generating the colours for each line.

Nick Gammon Australia Forum Administrator Tue 14 Dec 2010 05:42 AM #6

Well now, the fascinating thing about this is, assuming you are complaining about the slightly off-center band in the middle, if you change to the older behaviour (and not use the GradientFill function that Twisol suggested) then the thing is more symmetrical:

In fact, if I comment out the second WindowGradient, I get the first five bars of gradient, starting at G=0 (hidden by the border), G=25, G=51, G=76, and G=102. But not G=128 which is the end-point. So it seems to me that GradientFill, although requested to draw from black to G=128, is not in fact doing that.

However when "manually" doing it, my figures are:

G=0, G=32, G=64, G=96, G=128.

So just to explain, when calculating the gradient intermediate values, I divided the difference by the number of bars minus one. So, 128 / 4 = 32. So I added 32 to the green value for each change (there are four changes, not five), so my calculations give me the requested range.

The Windows programmers seem to have taken the number of bars as the divisor (128 / 5 = 25.6). Thus the increment of about 25 for each bar. But this is wrong because you don't get the end-point colour.

Now since this calculation is an internal one in the way GradientFill is implemented, I'm not sure I can fix it.

Fiendish USA Global Moderator Tue 14 Dec 2010 06:11 PM #7

Quote:
The gradient is a bit different on the bottom to the top, but I put that down to rounding errors when generating the colours for each line.

Yeah, this is what I meant. It seems, at least in the cause of the gauge.lua use case, that starting one pixel earlier hid the problem for me. Perhaps not a general solution for drawing all gradients, especially if you don't have a border to hide it behind, but at least for the gauge bars it seemed to work out visually.