А теперь снова о
пресловутых матрицах-ландшафтах. В DBPro
господа из DarkBasic Software Ltd. окончательно
ставят меня в тупик. Дело в том что в группе
функций "World" (которая сама по себе
новая) кроме функций для работы с BSP
уровнями присутствует отдельный блок
функция для работы с... Ландшафтами (!). Здесь
они, как и полагается, названы ландшафтами.
Чем же они отличаются от матриц-ландшафтов?
Способом создания, а способ весьма крут.
Чтобы создать ландшафт нужно указать черно-белую
картинку и движок создаст по ней ландшафт!
Круто да? Светлые участки - возвышения,
темные - впадины. После этого, можно
натянуть цветную текстуру ландшафта.
Только вот непонятно, зачем надо было
размазывать общие функции по разным
группам.
Не 3D
единым: Давайте посмотрим, какие изменения
в 2D части,
тем более, многие слышали громкое заявление
авторов DBPro,
что времена медленного 2D
дескать, кончились.
А вот и нет. Это не
времена кончились, а 2D
скончался :-).
Для осмысления
выше сказанного и нижеследующего текста
проведу небольшой экскурс в историю. До
приобретения DarkBasic
наша команда (CloneSoft)
кочевряжилась над собственным 3D
движком. Дык вот, в нашем движке для
отображения 2D интерфейса на экране мы написали
блок функций отвечающих за это дело и все
объединили в общий модуль под названием "название_движка_Interface_2D"
который базировался на низкоуровневых
функциях 2D (на
них же был повешен и 3D).
Короче движок дает более 700 (!) FPS при отображении истинного 2D TrueColor на Celeron
566 MHz 128 Mb
с TNT
Pro 32 Mb.
Такое количество FPS
достигается благодаря очень умному 2D
движку и возможностью отключения VSync.
В DarkBasic
классический 2D
движок, работающий "по старинке". Я, было,
подумал, что господа из DarkBasic Software
Inc.
дотямкали как ускорить 2D,
ан нет. Не сообразительные. Они пошли другим
путем - вырезали 2D
и заменили его 3D.
А что, не помните
их слоган из DB
- "Будущее 2D
это 3D".
Группа функций BITMAP
по-прежнему работает с истинным 2D,
т.к. их назначение не вывод изображения, а
манипуляции с ним.
Функции IMAGE
и SPRITE теперь
базируются на 3D.
LOAD
IMAGE
теперь работает так:
1. Создается 3D
полигон
2. Грузится картинка и натягивается на
полигон как текстура.
3. Созданный полигон не вносится в список
рендеринга.
Теперь, когда вы
используете команду PASTE
IMAGE, на
экран не копируются биты поверхности, а
просто указанный полигон вносится в список
рендеринга, рендерится и снова исключается
из списка.
Все функции SPRITE
теперь работают так же - мы имеем дело не с
картинками, а с полигонами (поэтому
спрайтам стала доступна такая фича как
аппаратный альфа-канал - эффект
прозрачности).
Координаты можно
по-прежнему указывать в виде 2D
координат экрана, движок сам
преобразовывает их 3D.
Кстати, шрифт
теперь тоже 3D, поэтому символы теперь
сглаживаются по краям.
Что дает переход
с 2D на 3D?
Два эффекта - сглаживание и альфа-канал.
Недостаток - если размеры картинки Вашего
спрайта не кратны 2, то 3D
движок DBPro
создавая из нее текстуру, для наложения на
полигон, автоматически подтянет ее размер
под этот стандарт, а затем, для устранения
корявых пикселов, сгладит. Короче, на экране
спрайт выглядит несколько мутновато.
Вывод. Если Вы
только начали работать над интерфейсом
своей игры и делаете его в 3D
срочно переходите на 2D
(в DBPro,
естественно) - эффект тот же, плюс удобная
система координат.
Раз уж мы
заговорили о 2D, давайте посмотрим, что
новенького в "Aniamtion" (сдесь собраны
функции воспроизведения видео).
В DB мы могли
воспроизводить только AVI. В DBPro этот список
расширился, добавили поддержку MPG формата и
несколько экзотических. Последние нам в
упор не нужны, а вот MPG большой шажок в
сторону профессионального
геймдевелопмента. Если в Вашей игре будут
видеовставки, делайте их в MPG формате.
Почему? Я ничего не имею против AVI, это
отличный формат, но у него есть одно
достоинство превращающееся в существенный
недостаток при использовании в играх. Это
отсутствие собственного видео кодека. AVI
является всего лишь хранилищем для видео,
сжимаемого разными подключаемыми кодеками.
А кто может гарантировать, что кодек,
который Вы использовали для сжатия своих
мувисов, окажется на машине юзверей?
Конечно Вы можете распространять кодек с
игрой, но тут появляются глюки с установкой
и настройкой. Так поступают только
последние ламаки и чайники. Профессионалы
пользуются системонезависимыми форматами.
Лидер - Bink Video кодирующий по стандарту DVD.
Большинство современных игрушек
использует этот формат. На втором месте - MPG.
Этот формат также не зависит ни от каких
кодеков. MPG - выбор профессионала. Хотя, если
позволяют средства, рекомендую купить Bink SDK
у RAD Gametools, благо DBPro поддерживает
подключение DLL.
Ну и заканчивая
описание движка, вернемся к проектной
панели, раздел "Settings". Если кто помнит, настройки,
содержащиеся в рамке "Display
Settings" я
оставил на потом, т.к. эти настройки касаются
непосредственно движка.
Не буду объяснять
Вам действие переключателей "Windowed"
и "Windowed - Desktop",
это и ежу понятно. Важнее ознакомится с
полноэкранным режимом, т.к. здесь произошли
кардинальные изменения.
И так. У нас по-прежнему
имеется режим "Fullscreen
Exclusive
Mode".
Рядом имеется пимпа "Pick"
позволяющая задать стартовое разрешение
экрана, которое Вы затем можете изменить в
своей программе функцией "Set Display Settings".
Что ж. Этот режим
нам знаком по DB.
Но в DBPro
появился еще и "Windowed
- FullScreen".
Что-то не понятно - Оконный - Полноэкранный.
Вот тут самое интересное.
Для тех не знаком
с Microsoft
Direct3D
(а именно на этом 3D
движке и работает DBPro)
- разработчики Direct3D
в руководстве программиста на каждом шагу
доказывают, что самый лучший режим это
полноэкранный эксклюзивный. Только в этом
режиме все ресурсы отдаются нашей
программе и т.п. И действительно, их доводы
подтверждаются тестами FPS.
В DarkBasic
использовался этот режим, но FPS
был весьма низок. Я решил, что это из-за
слабого движка, но тут в DBPro,
к эксклюзивному режиму добавился
полноэкранный-оконный и теперь я в
недоумении.
Смотрите сами.
Запускаю программу в эксклюзивном режиме, FPS
такой же, как и в DarkBasic
(!): Запускаю в полноэкранном-оконном - 80 FPS (!). Хоть убейте из рогатки не пойму
в чем суть (суть в сортире - замечание
прохожего :-).
Объясняю, как
работают эти два режима.
Эксклюзивный -
запрашивает у системы все ресурсы и
сообщает GDI
что программе нужен весь экран. Система
приостанавливает все процессы, GDI
отдает экран. DirectDraw
(2D часть DirectX)
меняет разрешение на требуемое переключая
монитор и захватывает первичный буфер
видеокарты (содержимое этого буфера Вы и
видите на экране). Когда вы вызываете
функцию "Sync",
DBPro рендерит
картинку в задний буфер и затем отражает на
экран аппаратным методом "flip". При использовании флиппинга
первичный и вторичный (задний) буфера
просто меняются местами. Сообразительные
сразу догадались, что это очень быстрый
метод.
Как работает
режим "Windowed
- Fullscreen" -
так же как и оконный, но при этом создается
простое плоское окно без всяких рюшечек и растягивается на весь
экран. Затем, нужно как-то переключить
разрешение экрана на то, которое требует
наша программа, а об этом не может быть и
речи, т.к. режим то у нас оконный!
И что же делает
движок DBPro? А
вот что. Допустим разрешение Вашего DeskTop'а
800x600.
Следовательно, первичный буфер имеет такое
же разрешение. Ваша же программа
запрашивает 640x480.
В этом случае DBPro
создает задний буфер (в нем и происходит
создание кадра) размером 640x480, а когда вы вызываете функцию "Sync"
(рендеринг) он рендерит 3D
сцену в задний буфер и переносит его
содержимое на экран, т.е. первичный буфер,
растягивая до 800x600
аппаратным методом - блиттинг. Т.е. в этом
режиме функция "Set Display Settings"
не меняет разрешение монитора физически, а
лишь создает задний буфер указанного
размера.
И вот я и говорю -
не пойму как он при этом выдает больше FPS,
чем в эксклюзивном. Я уже не говорю о том,
что скорость блиттинга (побитовое
копирование содержимого одно буфера в
другой) намного медленнее флиппинга.
Ну да ладно, какая
разница, лишь бы FPS
был высоким и картинка качественная. Да, но
у вышеописанного метода имеется один
недостаток.
Допустим у юзверя
(к которому попала Ваша игра) текущее
разрешение экрана 1024x768,
а Ваша игрушка сработана под 640x480.
Конечно же, движок DBPro
сделает все как я писал и юзверь увидит
картинку на весь экран, но с побочными
действиями как то: сильное искажение
интерфейса, он будет растянут и для
устранения артефактов сглажен - юзверь
увидит муть; более низкий FPS, чем тот, на который мы
рассчитывали при создании игрушки.
Есть ли выход из
этой ситуации? Да.
Первый путь
состоит в том, чтобы использовать
эксклюзивный режим, но здесь по причине
низкого FPS
вы сильно сузите круг пользователей вашей
гамесы.
Второй путь -
написать DLL (на
C++ или Delphi)
с функцией переключения разрешения. Затем
при старте в оконном-полноэкранном режиме
Ваша DBPro
программа переключит разрешение монитора
на нужное, а уже после этого можно применить
функцию "Set
Display
Settings" и
тогда мы получим задний буфер равный по
размеру первичному, а это - качественная
картинка и высокий FPS!
Часть четвертая:
Язык
Теперь коротко :-)
о языке.
Свершилось!
Теперь на DBPro
станет программировать намного легче.
Можете браться за мощную РПГ и т.п. А все
потому что появилась поддержка
пользовательских типов.
Что такое тип? Тип
это Ваш друг :-). Вы сэкономите многие часы,
если будете пользоваться типами вместо
массивов (массивы, конечно же, тоже
пригодятся).
Смотрите сами.
Допустим в нашей РПГ есть пять персонажей у
каждого по пять характеристик. Раньше Вы
хранили бы это в массиве:
Dim
characters(5,5)
Ну, мы сохранили в
этом массиве номера моделей и
характеристики персонажей (жизнь, сила,
ловкость и т.п.)
А где хранить
имена? Придется добавить еще массивчик:
Dim
char_names$(5)
Удобно? Да это же
нервотрепка!
Смотрите, как это
делается с типом:
`Объявляем тип
Type
type_Characters
Char_Names$(5)
Char_Lifes(5)
Char_Power(5)
EndType
`Присваиваем
переменной
t_Characters As
type_Characters
Теперь в любом
месте программы (там где нужно, например,
увеличить силу персонажу) пишем:
t_Characters.Char_Power(3)
= t_Characters.Char_Power(3) + 10
Этой строчкой я
увеличил силу третьего персонажа на десять
пунктов.
Думаю, Вы
просекли фишку. К сожалению, пользоваться
ею не удобно. В VB и C++
после нажатия точки всплывает список со
всеми переменными типа и нужно лишь
щелкнуть в нужную переменную в списке. В DBPro же придется держать все
переменные типа в голове или записывать на
листок. Но все равно, теперь нам будет
намного легче.
Добавлю ложку
дегтя в бочку дерьма :-). Объявлять типы
можно только в главном модуле вашего
проекта. В противном случае DBPro
вообще их не воспримет, да еще обматерит Вас
трехэтажным.
Отсюда вывод -
создать некий Game
Engine (надстройку
к DBPro)
использующий типы, в одном модуле, а затем
запросто подключать его к новым проектам
Вам не удастся, т.к. типы должны быть
объявлены в главном модуле. Придется
постоянно интегрировать модуль в проект
извращенным способом - вырезанием объяв
типов и вставлением в главный модуль.
Заключение
Вот Вы мы подошли
к концу, пора делать выводы и давать
рекомендации.
Покупать или не
покупать - вот в чем вопрос. На этот вопрос
я спокойно отвечу - ДА!
Когда покупать и
у кого? Мой Вам совет - не в коем разе не
покупайте DBPro сейчас! Первые версии программ (да
чего угодно) всегда содержат массу глюков и
недоделок. Вспомните как нам повезло с DB
- англичанам досталась глючная версия 1.0 и
им еще патчи качать пришлось. Нам же - уже
обкатанная 1.09с с гораздо большим
количеством функций и альтернативным
редактором в одном флаконе!
А пока, в ожидании
Российской версии лицензионного DBPro
рекомендую скачать демо с официального
сайта, пока халяву не обломали - не
пожалеете.
David
Good
advcoder@mail.ru
www.clonesoft.narod.ru