Я бы предложил прежде всего спланировать простую игру в качестве тестового примера для вашего движка.Базовая игра будет стимулировать разработку и разработку API.Написание движка без четкой цели делает проект более рискованным.Хотя я согласен с тем, что nVidia и ATi следует рассматривать как отдельные цели по соображениям производительности, я бы рекомендовал вам не начинать с них.
Я лично написал физический движок для Uncharted: Drake's Fortune - игры для PS3 - и я сделалпередать в C ++, и когда это сработало, сделал проход, чтобы оптимизировать его для VMX, а затем положить его на SPU.Имейте в виду, я сделал только часть того, что я хотел сделать изначально из-за нехватки времени.После этого я сделал итерацию, чтобы разделить этапы данных и сформулировать конвейер преобразований данных.Это важно, потому что современные процессоры с нетривиальным кодом, будь то CPU, GPU или SPU, проводят большую часть времени в ожидании кэшей.Вы должны уделять особое внимание структурам данных и составлять их так, чтобы на любом этапе у вас был небольшой рабочий набор данных.Например, сначала я делаю широкофазные, поэтому мне не нужны фигуры, но мне нужны ограничивающие рамки мирового пространства.Поэтому я разбил ограничивающие блоки на отдельный массив и вычислил их все вместе за один проход, который выписал их оптимальным образом.В качестве входных данных для вычисления bbox мне нужны преобразования фигур и некоторые их границы, но не обязательно целые фигуры.После широкой фазы я вычисляю / обновляю сим-острова, одновременно выполняя узкую фазу, для которой мне действительно нужны фигуры.И так далее - я описал это с помощью картинок в статье для Game Physics Pearls , которую я написал.
Я думаю, что я пытаюсь сказать следующие пункты:
- Убедитесь, что у вас есть четкая цель, которая движет вашим развитием - очень простая игра с продуманным дизайном была бы лучшей в случае с игровым физическим движком.
- Не пытайтесь оптимизировать, пока у вас нет работающеготовар.Сначала напишите это самым простым и быстрым способом и исправьте все ошибки в математике.Спроектируйте его так, чтобы вы могли портировать его на CUDA позже, но не начинайте писать ядра CUDA до того, как на экране появятся окна.
- После того, как вы напишите первый проход в C ++, оптимизируйте его для CPU: упроститеэто так, что он не перебивает кэш и не разбивает код на части, чтобы не было спагетти вызовов, и весь код каждого этапа локализован.Это поможет: а) портировать на CUDA; б) перенести на OpenCL; в) перенести на консоль; г) сделать так, чтобы он работал достаточно быстро; д) сделать возможным отладку.
- При разработке не поддавайтесь искушению пойти и сделать что-то, что выпросто подумайте, если эта функция не является необходимой для вашей ясной цели (см. # 1) - вот почему вам нужна цель, чтобы направить вас к ней и дать возможность завершить реальный проект.Отвлечения обычно убивают проекты без четких целей.
- Помните, что, так или иначе, разработка программного обеспечения является итеративной.Это нормально, чтобы сделать черновик, а затем уточнить его.Кожа, промыть, повторить - это мантра программиста:)
Легко дать совет.Если ты хочешь что-то сделать, просто иди и сделай это, и мы будем сидеть сложа руки и критиковать :)