местах в заданном порядке (при помощи задания нескольких объектов класса КеяоигсеЗоигсе).
Такой подход позволяет легко добавлять в систему поддержку как новых форматов ресурсов (например, других форматов текстур), так и новых типов ресурсов. Далее мы добавим загрузку сцен и моделей, используя этот же маханизм. При этом добавление новых типов ресурсов совершенно не затрагивает функционирование остальных частей системы.
ПИШЕМ ПОРТАЛЬНЫЙ РЕНДЕРЕР (часть I)
С этой главы мы начинаем писать портальный рендерер. К концу этой главы мы напишем простейший портальный рендерер с использованием библиотеки OpenGL. Полный исходный код, а также соответствующий проект для среды Visual С++ содержатся на компакт-диске. Выбор именно портальной модели объясняется как ее простотой и гибкостью, так и отсутствием необходимости сложной и длительной предварительной обработки сцены, что часто встречается во многих играх.
Еще одним преимуществом портальной модели является возможность вносить изменения в сцену прямо на ходу.
В пользу метода порталов также говорят и те игры, которые используют его для своей работы: Unreal, Serious Sam и многие другие. Кроме того, существуют возможности для расширения классической портальной модели, позволяющей эффективно использовать графический ускоритель и работать с различными типами сцен. Некоторые такие расширения мы рассмотрим в этой книге.
Тем не менее в гл. 11 приводится рендерер для уровней игры Quake II, использующей схему BSP/PVS для определения видимости в сцене.
Схема "Модель - контроллер - вид" При написании нашего рендерера для организации ввода-вывода мы будем использовать концепцию "Модель - вид - контроллер" (Model-View-Controller, MVC [12]), впервые применявшуюся при построении пользовательских интерфейсов в среде Smalltalk и с тех пор получившей широкое распространение.
В этой концепции разделяются объект, отвечающий за графическое представление объекта (вид), сама модель объекта (модель) и контроллер, отвечающий за обработку ввода пользователя и визуальное отображение модели (рис. 7.1).