$inellipse - mIRC Discussion Forums

$inellipse is returning wrong value ($true instead of $false) when the 'y' value of the dot tested is between the 'y' value of the circle and the 'y+h' value of that circle, regardless of the 'x' value of the dot tested:

Code:

alias test {
  window -pBCdfo +t @a -1 -1 100 100
  var %x 40,%y 40,%w 20,%h 20,%a 100,%b,%c
  while (%a) {
    %b = 100
    while (%b) {
      %c = $iif($inellipse(%a,%b,%x,%y,%w,%h),64512,255)
      drawdot -r @a %c 1 %a %b
      dec %b
    }
    dec %a
  }
  ;$calc(1+%w) $calc(1+%h) to draw the circle correctly 
  ;instead of being shifted because of the drawrect -e bug
  drawrect -re @a 0 1 %x %y $calc(1+%w) $calc(1+%h)
}

Result:

whereas only the dots inside the circle should be green

The $inellipse() identifier seems to be working correctly here. Note that the x and y values are the top left corner of the ellipse.

Code:

test {
  var %x = 10, %y = 10, %w = 50, %h = 50
  window -ap @test 100 100 100 100
  clear @test
  drawrect @test 3 1 %x %y %w %h
  drawrect -e @test 4 1 %x %y %w %h
  var %x2 = $calc(%x + (%w / 2))
  var %miny = $calc(%y - 5)
  var %maxy = $calc(%y + %h + 5)
  var %y2 = %miny
  while (%y2 <= %maxy) {
    var %e = $inellipse(%x2,%y2,%x,%y,%w,%h)
    echo 1 %x2 %y2 %e
    drawdot @test $iif(%e,4,1) 1 %x2 %y2
    inc %y2
  }
}

The problem is when the y value of the dot tested is between %y and %y + %h, regardless of the value of x. In your example the x value is always inside the circle while the y value changes, therefore it doesn't show the problem, switching to an horizontal line show the problem:

Code:

test {
  var %x = 10, %y = 10, %w = 50, %h = 50
  window -ap @test 100 100 100 100
  clear @test
  drawrect @test 3 1 %x %y %w %h
  drawrect -e @test 4 1 %x %y %w %h
  var %y2 = $calc(%y + (%h / 2))
  var %minx = %x - 5
  var %maxx = $calc(%x + %w + 5)
  var %x2 %minx
  while (%x2 <= %maxx) {
    var %e = $inellipse(%x2,%y2,%x,%y,%w,%h)
    echo 1 %x2 %y2 %e
    drawdot @test $iif(%e,4,1) 1 %x2 %y2
    inc %x2
  }
}

result:

Note the two black dots at 10 35 and 60 35 and how almost every dot outside the circle from that line are wrongly reported as inside the circle, my first code and picture show the problem very well actually.

That is really odd. I cannot seem to reproduce this issue here. The $inellipse() identifier is returning the correct results both inside and outside the ellipse for me. Looking at your results, it seems to be failing when the x value is outside of the ellipse. If you test this in a clean install, do you still see the same issue?

This is tested on a clean install, mIRC 7.25, XP/7 already.
Anyone who tried this can reproduce the problem, are you trying with a clean install and not a debug version or something?

I'm getting the same results as Wims.

A simple way to demonstrate this bug is the following: //echo -a $inellipse(35,5,10,10,50,50) $inellipse(5,35,10,10,50,50)

Both points are outside of the circle. But the first one returns $false and the second one (erroneously) returns $true.

I'm not sure if you are using your own algorithm to check if a point is inside an ellipse or not, but just in case, a working formula for testing if a point is inside an ellipse that works with mIRC's input syntax is this:

If I replace $inellipse with $inellipse2 (as I've written below), everything works correctly:

Code:

; $inellipse2(x2,y2,x,y,w,h)
alias inellipse2 {
  if ($calc( (2 * ($1 - $3) / $5 - 1)^2 + (2 * ($2 - $4) / $6 - 1)^2 ) <= 1) { return $true }
  return $false
}

Using Wims's original script with $inellipse:

Using Wims's original script with $inellipse2:

Thanks, I was able to reproduce this. It turns out it was due to compiler optimization. I had been testing this in a debug version of mIRC (sorry about that, I should have tried the release version first) which was returning the correct results. When I tested in a release version, the issue was present. An identical issue for $inellipse() was fixed in v6.31 but it looks like it was reintroduced after moving to a newer version of Visual Studio for mIRC v7.x. This issue has been fixed for the next version.