| ← Сентябрь 2013 → | ||||||
|
1
|
||||||
|---|---|---|---|---|---|---|
|
2
|
4
|
7
|
8
|
|||
|
11
|
12
|
14
|
15
|
|||
|
18
|
19
|
20
|
21
|
|||
|
23
|
24
|
25
|
26
|
27
|
||
|
30
|
||||||
За последние 60 дней 12 выпусков (1-2 раза в неделю)
Сайт листа:
http://www.tiflocomp.ru/
Открыт:
19-10-2011
Пре-модерация: Нет
Адрес для писем в лист: industry.comp.tiflocomp.programming-list@subscribe.ru
нет, готовые движки не пойдут.
зачистую, при начале разработки давольно емкого проекта, не всегда знаешь как
к нему подступиться, с чего начать, его структуру.
вот нужна какая либо ценная литература, которая бы немного прояснила великую
магию иградева.
С уважением: Максим Calculator.
calculator.***@m*****.ru
http://www.twitter.com/calculatorspb/
Приветствую всех.
Вряд ли человек собирается стартовать с такого нуля (разрабатывать собственную
математику для пространственного звука или физических эффектов -это, скорее,
уровень subzero).
Все популярные API для эмуляции 3D-звука реализуют подобные расчеты самостоятельно.
"Популярные API" -- это, конечно, DirectX (компонент DirectSound3D) и OpenAL
(реализация одноименной спецификации от Creative).
Это верно, но обычно ограничивается только уровнем абстракции -- функции для
доступа к различным компонентам имеют "единообразный" дизайн, а код игры менее
сцепле с конкретными компонентами и библиотеками.
В концептуальном смысле, как правило, мы остаёмся на том же уровне, что и, например,
API DirectSound (то есть по-прежнему управляем положением каждого источника или
группой источников, задавая их координаты, скорость для расчета эффекта Доплера,
направленность и еще ряд характеристик).
В графических играх основной задачей игрового цикла является обновление сцены
(т.е. опрос клавиатуры, скорее, второстепенное действие). Для звуковых игр, соответственно,
игровой цикл должен обновлять звуковую картину. Указанные выше API, как правило,
реализуют модель накапливаемых изменений: система принимает новые координаты
источников, но не меняет звуковой картины, пока не будет вызван специальный update-метод,
в результате чего вся звуковая картина будет пересчитанна с учётом накопленных
изменений.
Расчёт координат обычно возлагают на физические движки.
Обработка ввода (в т.ч. клавиатурного) может быть и "внутри" игрового цикла (т.е.
в основном потоке) или выполняться в отдельном потоке (со всеми вытекающими достоинствами
и недостатками).
В теоретическом смысле любая игра сводится к схеме с конечным автоматом: поток
событий на входе и конечный набор состояний -- переход из одного состояния в
другое зависит от входного события и текущего состояния.
Причем каждый игровой объект -- это конечный автомат и само ядро игры тоже реализует
концепцию конечного автомата...
В DirectX за ввод отвечает DirectInput. Но можно использовать и функции WinAPI.
Чтобы JAWS не перехватывал нажатия клавиш, в настройках JAWS для вашего приложения
нужно установить "спящий" режим.
Успехов. Анатолий.
Здравствуйте, Спиридонов Максим.
Ну здесь речь шла скорей не о движках, а об адаптированных средах
разработки. То есть с их помощью реализовывать можно какую угодно игровую
логику, они лишь просто предоставляют более простой и удобный интерфейс
взаимодействия с рядом технологий, например, позиционируемым 3D звуком.
Просто если писать совсем с нуля, то придётся брать библиотеки работы со
звуком и может даже самому рассчитывать тот же эффект Доплера, а потом
отдавать рассчитанные координаты источников звука библиотекам. Если же
использовать адаптированные среды, то это уже зашито в чёрный ящик и мы
работаем на более высоком уровне.
Ну а вообще просто создаёте пустое окно, в глобальном цикле пишите
обработчик нажатий клавиш, а потом на это вешаете всю бизнес логику.
Успехов. Никита.