Графика для Windows средствами DirectDraw - [16]

Следовательно, к переключению режимов в приложениях DirectDraw следует подходить с осторожностью. В коммерческих приложениях должен присутствовать механизм страховки, который бы позволял проверить видеорежим перед тем, как переходить в него. Подобный механизм используется при выборе видеорежима рабочего стола и в Windows NT, и в Windows 95. Когда вы приказываете Windows сменить видеорежим, новый режим активизируется на 15 секунд, после чего восстанавливается предыдущий. Затем диалоговое окно спрашивает, правильно ли система работала с новыми параметрами.

Вероятно, подобную страховку стоит включать и в коммерческие приложения для Windows 95 — ведь никто не гарантирует, что параметры монитора были заданы верно. При неверном выборе типа монитора в Windows 95 могут быть обнаружены видеорежимы, которые в действительности не поддерживаются. 

Заключение

Наш интенсивный краткий курс DirectDraw подходит к концу. В главе 2 мы поговорим о проектировании и оптимизации приложений, а также о том, что ждет DirectDraw в ближайшем будущем.

Глава 2. Проблемы быстродействия

Быстродействие никогда не выйдет из моды. Чтобы обеспечить максимальное быстродействие программы, ее необходимо оптимизировать. Об этом знают все программисты, занимающиеся разработкой аркадных игр. Их игры должны работать быстро, иначе они будут плохо продаваться. С каждым годом игроки желают иметь все более высокое быстродействие. Каждая новая игра-бестселлер устанавливает новые стандарты и поднимает планку еще выше — несомненно, в будущем эта тенденция только усилится.

Впрочем, на аркадных играх (и играх вообще) свет клином не сошелся. Скажем, разработчики САПР, графических редакторов, имитаторов и образовательных программ в меньшей степени озабочены вопросами оптимизации и быстродействия, чем игровые программисты. Но все эти приложения тоже должны работать достаточно быстро. Никому не нравится работать с медленными программами. Пользователи желают, чтобы события на компьютере происходили сразу же, а не через несколько секунд. Вполне достойный, но плохо оптимизированный пакет может проиграть в конкурентной борьбе.

Не стоит полагать, что каждый пользователь, знакомясь с новой программой, говорит себе: «Пусть эта штуковина работает побыстрее, а не то…» Быстродействие программы чаще оценивается на подсознательном уровне. Работа с быстрой программой, мгновенно реагирующей на все ваши желания, доставляет радость. Хорошее быстродействие вселяет в пользователя уверенность и желание работать дальше. Медленные программы лишь испытывают наше терпение. Каждый, кому приходится работать с ними, мечтают поскорее закончить свои мучения. Пользователи предпочитают, чтобы любая программа (текстовый или графический редактор, игра или любое другое приложение) быстро и адекватно реагировала на их действия.

В этой главе речь пойдет о некоторых практических аспектах быстродействия, знакомство с которыми позволит вам поднять свои программы на новый уровень. Сначала мы рассмотрим общие вопросы быстродействия, а затем перейдем к проблемам, специфичным для DirectDraw.

Традиционная оптимизация

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

Тем не менее из теории оптимизации необходимо выделить один важнейший урок: усилия, затраченные на оптимизацию, окупаются лишь в некоторых частях программы. Не стоит напрасно тратить время на возню с однократно выполняемым кодом, однако оптимизация кода в циклах и часто вызываемых функциях оказывается жизненно важной.

Не стоит просто предполагать, что некоторые части вашей программы работают медленно. Перед началом вскрытия расставьте таймеры в подозрительном фрагменте и воспользуйтесь профайлером Visual C++. Издевательства над невинными функциями не только ведут к напрасным затратам времени, но и повышают вероятность внесения новых ошибок.

Действительно ли C++ медленнее C?

Мы подходим к деликатной теме. Защитники C дружно объединяются для защиты своего любимого языка. Адепты C++ тоже настроены весьма воинственно. К сожалению, преданность такого рода нередко оборачивается неразумным фанатизмом.

Язык C известен своей эффективностью. Именно поэтому он стал первым языком высокого уровня, на котором была написана операционная система (Unix). И все же по скорости C уступает ассемблеру. Он создавался как высокоуровневая альтернатива той чрезмерной детализации, с которой связано программирование на ассемблере.

C++ был создан для того, чтобы обогатить существующий язык C конкретными функциональными возможностями и при этом воспользоваться преимуществами его скорости. Добавлений было несколько, но основным усовершенствованием стало появление объектов, или классов. Более того, первоначально C++ назывался C with classes.

Классы были включены в C++ для поддержки таких объектно-ориентированных принципов, как наследование и полиморфизм. Эти возможности уже присутствовали в других языках (например, в Smalltalk), но C++ был задуман как высокопроизводительный объектно-ориентированный язык. Smalltalk при всей своей мощности работает медленно.