Я выбрал число 10 как верхний предел (названный ограничителем цикла) экспериментально. Я сыграл несколько раз в бильярд, используя различные ограничители цикла и наблюдал физические результаты в зависимости от значения времени, которое требуется на выполнение цикла. В итоге, ограничитель десяти циклов дает оптимальную физическую производительность с небольшим циклом по времени сверху. В строке 10 мы запускаем скрипт, который делает проверку на столкновения между шарами и бортами. Если шар сталкивается с бортом, мы также проверяем его на столкновение с лузой, используя функцию detectPocket(). Проверка столкновения лузы с каждым шаром в каждом кадре привела бы к неоправданным лишним вычислениям, так что мы проверяем лишь в случае, когда шар сталкивается с бортом. Это помогает уменьшить количество кода, выполняющегося в каждом кадре.
Несмотря на всю математику и физику, использованную в этой игре для приданий ей высокой степени реализма, по-прежнему остаются проблемы, которые могут возникнуть. Приблизительно 1 из каждых 50 или 100 ударов заканчиваются слипаниемм двух шаров – совсем небольшим, но совершенно явным. Это ошибка, которую я, несомненно, буду решать в следующих версиях этой игры, но эта работа вводит меня в ступор. Как последнее средство в ситуации подобной этой, я создал специальную функцию, основанную на временном факторе, для проверки возникновения проблем. Эта функции имеет внутренний таймер, который позволяет ей выполняться приблизительно раз в 20 кадров. Когда функция выполняется, она проверяет с помощью hitTest() реальные клипы шаров. Никакие два шара не должны никоим образом соприкоснуться, - что, естественно, означает столкновение. Если hitTest() возвращает true, то шары соприкасаются, и возникает наша ошибка. Затем мы слегка расталкиваем шары в стороны, так что они расходятся в стороны. Как упомянуто выше, это не происходит слишком часто, но когда это происходит, мы подготовлены.
В строке 12 мы берем координаты шаров в памяти и помещаем их на экране
Русская версия