Обнаружение столкновений работает в половине случаев

Question

Я пытаюсь проверить столкновения между двумя массивами, один из которых состоит из движущихся прямоугольников, а другой - из границ канцелярских товаров (пытаясь заставить прямоугольники отскакивать от стен).

Проблема в том, что я написал вложенный цикл for, который, кажется, работает для 2 из 4 границ. Мой цикл не достигает всех возможных комбинаций?

Вот мой цикл:

for(int n=0;n<_f;n++){
   for(int m=0;m<_b;m++){
       if(farr[n].inter(barr[m]))
           farr[n].setD();
   }
}

_f считает движущиеся прямоугольники (начинается с 0 и увеличивается после добавления каждого из них), а _b подсчитывает границы. Интер () - это метод, который я использую для обнаружения коллизий, и он работал во всех других частях моей программы.

Любая помощь будет принята с благодарностью, Спасибо заранее!

public boolean inter(Rect rect){
    if(Rect.intersects(rect, rec))
        return true;
    else
        return false;
}

Метод setD ():

public void setD(){
    if(_d==0)
        _d=2;
    if(_d==1)
        _d=3;
    if(_d==2)
        _d=0;
    if(_d==3)
        _d=1;
    }

Метод перемещения, в котором используется _d:

public void moveF(){
    if(_d==0){_l+=_s;_r+=_s;}
    if(_d==1){_t+=_s;_b+=_s;}
    if(_d==2){_l-=_s;_r-=_s;}
    if(_d==3){_t-=_s;_b-=_s;}
}

_l - левая сторона, _t - верх, _r - правая, _b - нижняя, а _s - количество пикселей, которое он перемещает за итерацию (во всех случаях устанавливается равным 1)

Answer 1

Предполагая, что _f, _b, farr и barr не меняются во время выполнения цикла, ваш цикл проверяет все комбинации ровно один раз. Так почему же вы «проверяете некоторые столкновения дважды»? SetD () делает что-то подлое? Вы имеете в виду, что после столкновения прямоугольника нет необходимости проверять больше границ? Если это так, это можно исправить с помощью простого оператора break. В противном случае, вероятно, возникнет проблема с вашим методом inter (), независимо от того, будет ли он работать в другом месте. Можете ли вы опубликовать вашу внутреннюю реализацию?

Существует возможность еще одной проблемы - принятия непрерывных свойств в дискретном пространстве. Как показывают мои удивительные навыки ascii art (под названием: ball and wall) ...

Кадр 1:

o__|_

Рамка 2:

_o_|_

Кадр 3:

__o|_

Рамка 4:

___|o

Обратите внимание, что мяч прошел сквозь стену! Ни в каком кадре мяч не пересекает стену. Это происходит, если расстояние, которое вы перемещаете за кадр, может быть примерно таким же или больше, чем характерный размер вашего движущегося объекта. Это трудно проверить с помощью простой проверки пересечения. Вам на самом деле нужно проверить путь, по которому шарик занимал между кадрами.

Если ваши прямоугольники и барьеры ориентированы без поворота, это все еще довольно простая проверка. Используйте ограничивающий прямоугольник движущегося прямоугольника между двумя кадрами и пересекайте его с барьерами.

Другие идеи:

1. Вы удваиваетесь сталкиваетесь, переключая направление дважды.

2. Ваши прямоугольники находятся в двух разных координатных пространствах.

3. Какая-то другая нить прикручивается к вашим ритуам.

Но в основном ваш код выглядит хорошо. Сколько у вас прямоугольников? Вы можете сделать их отличными цветами? Затем, в вашем цикле, когда вы сталкиваетесь, вызовите setD и выведите цвет прямоугольника, который столкнулся, и где он был. Затем, когда вы заметите проблему, убейте код и посмотрите на результат. Если вы видите два столкновения подряд (в результате чего прямоугольник дважды меняет направление), вы поймете свою ошибку. Вывод координат также может помочь, если вы не в двух разных координатных пространствах.

Если это проблема с многопоточностью, самое время освежить критические разделы.

Нашли ошибку:

public void setD(){
    if(_d==0)
        _d=2;
    if(_d==1)
        _d=3;
    if(_d==2)
        _d=0;
    if(_d==3)
        _d=1;
    }

Каждое из них должно быть в другом случае, если в противном случае вы обновите 0, чтобы стать 2, и затем 2, чтобы стать 0 в том же вызове.