Многие люди думают, что графика невосприимчива к традиционным тестам TDD / unittesting.Это не так.
Проблемы, связанные с TDD, заключаются в том, что изображения не всегда будут точно одинаковыми.Такие вещи, как настройки сглаживания (которые могут быть переопределены настройками драйвера).Различия между тем, как разные графические процессоры отображают одно и то же изображение (порядок раскрутки полигонов и т. Д.).Кроме того, по мере того, как ваша игра проходит через разработку, такие вещи, как сетки и текстуры, могут быть изменены или изменены.
Также люди думают, что вам часто нужно это делать и оценивать результат, прежде чем посмотреть, все ли в порядке, затем добавить его в качестве проходного тестаcase (который сломается из-за вышеуказанных проблем).
Вы можете обернуть все вызовы OpenGL журналами и убедиться, что все вызываются, как и ожидалось, но это не проверяет, что графика действительно действительна, простопроверяет, что ваша программа выполняет вызовы, которые вы предсказываете.Это не очень полезно, и это будет довольно много работы.Также будет сложно поддерживать, если вы будете выполнять такие вещи, как оптимизация ненужных вызовов отрисовки.
Что я бы порекомендовал сделать, так это отделить результаты рендеринга от вашей оконной системы.Под этим я подразумеваю 'Render to Texture' или использование объектов FrameBuffer.Это также помогает делать такие вещи, как видовые окна и оверлеи UI / HUD.
Создание объекта 'Window'.Что-то, что открывает настоящее окно рабочего стола с использованием Qt, SDL, SFML, GLUT или чего-либо еще.И передать ему какой-нибудь рендерер.Вы можете сделать такие вещи, как разрешить несколько рендеров и указать координаты прямоугольника (вы можете визуализировать другой вид в углу экрана).Или, может быть, сделать один мастер рендеринга, но унаследовать версию, которая позволяет ему иметь subrenderers.Объект Window также может обрабатывать ввод, это обеспечивает хороший способ ввести ложный / фиктивный объект ввода, вы можете проверить, движется ли игрок вперед, как ожидалось.
Этот модульный подход - это то, что падаетвне TDD он также может позволить вашему рендереру иметь свои собственные рендереры (возможно, вы хотите сделать скайбокс отдельно или изображение на мониторе безопасности в игре, отражения, карты теней и т. д.).Вы также можете легко выполнить рендеринг с другим разрешением для собственного рабочего стола (что полезно для установки фиксированного разрешения в TDD и может быть чем-то вроде 32x32 для простых операций, но также полезно для устройств, таких как Android, где фиксированные разрешения иГрафические процессоры имеют различные возможности. Nexus 10 недостаточно мощен, чтобы визуализировать вашу игру с ее XDPI? Уменьшите ее. Также помогает с Linux / Xorg, который не всегда позволяет вам устанавливать все разрешения, которые делает GPU, хотя сейчас это не проблема).
Как только у вас будет FBO, сделайте несколько функций для запроса цвета пикселей.Затем вы можете запросить все ваши основные операции.Правильно ли отображаются ваши сетки?Попробуй это.Создайте сетку с одним белым треугольником и спросите, какие позиции вы ожидаете увидеть белым, а какие должны оставаться черными при рисовании этого треугольника.Треугольник 1x1 в окне 1x1 должен охватывать% 50 по диагонали, поэтому тестируйте пиксели около края и обеих сторон середины, границ окна и заостренных битов.Далее объединяем два треугольника в прямоугольник и он должен заполнить экран, теперь все пиксели должны быть белыми.Теперь попробуйте отодвинуть его от камеры и проверить, что границы черные, но центр белый, с прямоугольником 1,0x1,0 в окне 1,0x1,0 на расстоянии 1,0, вы можете применить простую геометрию, чтобы увидеть приблизительно, где границыдолжен закончиться. Тест с другим цветом .Сделайте более сложную сетку с разноцветным кубом и проверьте вращение.Сделайте тестовую карту нормалей.
Возможно, вы сможете проверить источники света, отрисовав сферу и проверив, что с левой стороны она ярче правой, и если вы добавите другой источник света с другой стороны, они будут примерно одинаковыми (просто добавьте все пиксели слева и все пиксели справа и сравнить с допустимой погрешностью). Увеличьте яркость света и посмотрите, увеличивается ли сумма пикселей. Вы можете проверить алгоритмы освещения, разработав ожидаемый цвет в определенной точке на плоской плоскости.
Вы могли видеть, что спектральная подсветка является самой яркой в ожидаемой области. Для нормального / рельефного отображения сделайте тестовую текстуру .
Просто избегайте чего-то особенного, например, не тестируйте точно на грани. Они могут быть сглажены или просто немного отключены. Если вы делаете что-то вроде тестирования яркости влево / вправо для освещения, не ожидайте, что количество пикселей будет одинаковым в разных системах или даже в обеих сторонах (в симметричной сцене), используйте погрешность. Не используйте реальные данные, убедитесь, что вы используете базовые «тестовые» текстуры и сетки, которые не изменятся.