Методы Майкл Саладино
Майкл Саладино (Michael Saladino), Presto Studios
После ухода из компании Mobeus Designs, занимающейся созданием трехмерных графических движков, Майкл Саладино некоторое время работал в Volition (на ее счету игра Descent, слышали?), где вскоре стал ведущим программистом. В данный момент он снова программирует движки в Presto Studios. Ниже следует список заповедей, предложенных Майклом, и комментарии к каждой из них.
Нельзя недооценивать ассемблер
С появлением каждого нового поколения процессоров Intel в интернетовских группах новостей и курилках фирм, занимающихся разработкой ПО, вновь разгораются дискуссии относительно будущего языка ассемблер. Идея написать игру для ПК целиком на ассемблере уже никогда не осуществится, однако это вовсе не означает, что ассемблер перестал быть чрезвычайно полезным инструментом программирования. Интенсивно выполняющиеся циклы, которые потребляют львиную долю общего времени выполнения игры, всегда будут существовать в той или иной форме. Раньше они использовались для копирования больших битовых массивов, сейчас применяются для внутренних циклов отображения текстур. Что же дальше? Как насчет триангуляции сплайновых персонажей в реальном времени? Блок программы, который выполняет цикл сотни, тысячи или сотни тысяч раз для каждого кадра, часто будет работать гораздо быстрее, если он написан на ассемблере.
Я еще не встречал компиляторов, способных понять тонкие нюансы фрагмента программы так же хорошо, как опытный программист.
Как следствие: не следует надеяться, что применение ассемблера - это уже победа. Медленному алгоритму уготовано медленное выполнение как на ассемблере, так и на Си. Поэтому начинать всегда следует с оптимизации алгоритма. Если вы уверены, что нашли лучшее решение (либо если начался завершающий этап работы над проектом и продюсер не позволяет вам переписывать алгоритм обрезки полигонов в пятый раз), попробуйте применить ассемблер с целью выжать последние капли быстродействия.
Если же вы считаете, что игра не стоит свеч, то представьте себе, как вытянется ваше лицо, когда вы узнаете, что в команде конкурентов нашлись программисты, думающие иначе, а их игра выполняется несколько быстрее, что позволило использовать эти умопомрачительные точечные эффекты...
Не стоит оптимизировать программу раньше времени
Не занимайтесь оптимизацией раздела исходного кода до тех пор, пока не убедитесь, что он значительно замедляет выполнение. В противном случае вы сами, во-первых, потеряете на этом время, а во-вторых, замедлите разработку программы в будущем, когда другим потребуется разбираться в вашем фрагменте на ассемблере. Вот несколько классических примеров.
Оптимизация кода инициализации
Зачем это нужно? Он запускается один раз в начале программы. Разумеется, если из-за предварительной обработки крупных текстур запуск игры занимает полминуты, тогда что-то сделать нужно (скажем, вынести эту задачу как отдельный шаг в обработке уровней), но в 99,9% случаев, если код выполняется всего один раз, вообще не стоит об этом беспокоиться.
Оптимизация до анализа
С моим опытом в программировании, уходящим далеко в прошлое (я впервые сел за Apple II+ в семь лет), я по-прежнему часто ошибаюсь в определении, что замедляет, а что не замедляет мой код. К счастью, профайлеры (особенно VTune от Intel) стали обычным инструментом программирования. Они помогут вам быстро и легко определить, какие функции и даже какие строки являются причиной того, что ваш код выполняется столь вяло. После подобного анализа вы наверняка никогда не будете расточать время, оптимизируя что-то, что и так работает достаточно быстро.
Оптимизация быстрых программ
Вам никогда не попадались программисты, занятые преобразованием отлично читаемых программ на Си в крайне неуклюжие (хотя, возможно, и очень умные) программы на ассемблере, хотя все уже гарантированно работает с частотой 120 кадров в секунду? А мне попадались. Понятно желание сделать код настолько быстрым, насколько это в принципе возможно, но это уж слишком. Не стоит забывать и о том, что код должен легко читаться, что особенно актуально в современных компаниях, занимающихся разработкой ПО (вполне вероятно, что к тому или иному фрагменту вашей программы будут обращаться десятки людей). В большинстве случаев введение в игру кода, написанного на ассемблере, на начальной стадии реализации проекта является плохой идеей. Это сильно затрудняет обновление и дополнение программы.
Любите свою программу, но не обожествляйте ее
Невозможно даже приблизительно сказать, сколько времени тратится на подобные глупости! Программисты так привязываются к своему коду, что закрывают глаза на любые его недостатки. Писать программы - это, конечно, здорово, но не забывайте, что они, в конечном счете, всего лишь буковки на экране. Недостатки вашего кода - вовсе не ваши недостатки, не принимайте их на свой счет. Просто согласитесь с тем, что кто-то другой придумал, как заставить вашу программу работать быстрее. И с этого момента маленький прием, показанный вам другим человеком, стал и вашим тоже.
Кроме того, не устраивайте разборок насчет стилистических разногласий. Когда я слышу очередной спор по поводу того, использовать ли в тексте программы табуляцию или пробелы, мне кажется, что я готов вскрыть себе вены. Меня не волнует, как вы расставите свои пробелы или скобки, для меня важно исключительно содержание программы. Я думаю, каждая компания должна принять одно из двух решений: либо каждый пишет в своем стиле и никому не позволяется выражать по этому поводу недовольство, либо все должны придерживаться единожды принятого стандарта.
И вообще, программистам необходимо уметь отделять себя от своих программ.