Реализация основного игрового цикла (game loop)

Под сабжем понимать это.

Для начала под real mode (RM).

Допустим, мне нужно опрашивать клавиатуру, писАть в несколько "окон" видеопамяти, просчитывать модель игрового поля в реальном времени и что-нибудь еще. При этом, например, объект типа "пушка" может породить много новых объектов типа "снаряд", т.е. одна задача генерирует другие и их тоже нужно ставить в очередь на обработку.

Вопрос - а как оно реализовано? Какой принцип?

Имеется сильно усечённый алгоритм реализации многозадачности в RM - программный аналог переключения задач в PM.

В памяти строим структуру, каждой задаче (опрос клавы, запись в окно) выделяется своя запись. Формат каждой записи обязательно предусматривает флаг готовности, число приоритета и указатель на стек задачи. Переключение задач реализовано через стек, где каждой задаче выделена своя область для сохранения/восстановления контекста (регистров в общем случае).

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

Вобщем, реверс-инженеринг алгоритма почти завершен
Неясно, причем тут приоритеты. Пока понимаю так:

1. Задача отработала, обнулила свой флаг готовности, установила его для следующей задачи.

2. Диспетчер прочитал - переключил задачи.

3. Перейти к пункту 1.

Дальше вот что-то пока неясно. Сравнивать значения приоритетов и выстраивать отдельную очередь на исполнение? А если в процессе параметры меняются?

Ну и потом - что-то сложновато выходит для просто игры. Какие тут могут быть варианты? И, кстати, пункты 1-3 есть обычный цикл, к чему ж городить огород с таймерами, резидентностью и прочими семафорами? Есть у этой идеи какие-нибудь преимущества?

 

Kristobal Hozevich Hunta, А ничего, что Real mode устарел? иди лучше под SDL делать, там не проще на самом деле.

 

Пускай себе. На высокоуровне можно эффективно работать. А на асме... там железо... оно гудит

 

Я делал только один таймер для РТС типа Дюны 2/Warcraft. Всё остальное выполнялось как только до него доходила очередь. До релиза, конечно, не дошло, но медведи и мечники среди лесов шастали. =)

 

Может вначале стоит предположить и соотнести время выполнения задач, чтобы определить актуальность подхода?

Мне кажется проще всё же постаринке:

1.игровой цикл отрисовывает кадр
2.ждём до начала следующего кадра(1000/CONSTANT_FPS милисекунд)
3.го 1

А в самом цикле по очереди всё как в вики и вызывается.

Идея приоритетов для задач весьма интересна.
К примеру, приоритет чтения устройств ввода пропорционален количеству монстров на экране

 

Мне это сильно напоминает сопрограммы или зеленые потоки - в некоторых языках программирования это есть в уже готовом виде. Правда, опыта в программировании именно игр у меня нет.

 

Не предавай забвению - покажи хоть картинок

Да знаешь, ваяется под чистым ДОСом в эмуле, на fasm с отладкой под debug, td и hiew. Дилетантство конечно полнейшее. Я фактически даже не знаю, как в таких условиях фпс мерять.

Alex Kagansky, ну, умные книжки упоминают Си и функции createq, writeq, readq, а также какие-то синхронизирующие примитивы. Этот раздел я не понял, а вот ассемблерный кусочек с удовольствием разобрал.

Ладно, уточню вопрос. Берем Planescape (вчера ночью нашел в чулане), скажем, рыночную площадь. Встаем Безымянным в круг торговцев, не касаемся мыши, наблюдаем:

- герой анимирован (дыхание, движение рук, тени, различные позы - скрещивание рук, поворот головы);
- портрет героя анимирован (моргает);
- NPC анимированы все (насчитывал до 10-15 одновременно движущихся объектов), время от времени перемещаются (бегают, встают в стойку и пр.), на головой фразы. одновременно могут открываться порталы;
- анимация заклинаний дополнительно к всем прочим анимациям;
- в нижнем правом углу движутся шестеренки.

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

Вот просто стало интересно - каков может быть алгоритм? Какие-то динамические списки отображаемых объектов?

 

Тут особых алгоритмов не надо: каждому объекту выделяется отдельная переменная, в которой хранится номер текущего кадра его анимации. После отрисовки всей картинки данные переменные увеличиваются на 1 (со сбросом в 0, если необходимо). Конечно, я очень сильно упростил, но общий смысл понятен.

 

Просто у каждого игрового объекта есть состояние и метод, то есть то действие, которое он должен совершить за такт игры, исходя из своего состояния и состояния других объектов.
А дальше просто каждый такт каждый объект совершает это действие.
Это если грубо.
Если точнее - каждый такт игры состоит из нескольких стадий ("просчёт поведения" ,"просчёт попаданий", "просчёт хелсов", "отрисовка"), подтактов, и для каждого подтакта у каждого объекта есть своя специальная процедура.
И каждый такт по очереди делаются подтакты, для каждого из которых каждый объект по очереди (очередь тоже может меняться в зависимости от ситуации) выполняет необходимое действие.

 

Картинок можно видеть. Графика была стырена из польской игры Slaves или как-то так. А всё остальное, включая исходники, было накрыто ФАТом.

 

Это только на хилых компьютерах актуально, в принципе. Сейчас можно делать в лоб и на бейсике, скорости хватает.

 

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


---------- Добавлено в 03:33 ---------- Предыдущее сообщение было написано в 03:32 ----------


Кстати, игрушки ещё ладно, но похоже, что весь софт пишется по такому принципу.

 

Без всякого изврата нынче варианты только winapi или один из стандартных либов никсов... Тут возникает только забавный тред о синхронизации потоков и о ядерных спинлоках, и это уже не зависит от количества ядер итд...

 

Мммм... сколько разбирал игрушек под Windows (да и сам писал) всё очень банально - таймер на вызов всей игровой логики+отдельный поток на перерисовку... И никаких тормозов, никакого асма... Хм. Т.е. два потока, по сообщениям от системы.

 

В DOS4GW-играх как-то обходились без всяких потоков, да и в нынешних Win32-играх зачастую обходятся — достаточно посмотреть таблицу импорта: далеко не везде даже CreateThread есть. Это всё ненужное усложнение, да и отладку значительно затрудняет. У Рихтера в «Windows для профессионалов» про это хорошо написано (цитата

...В общем, мораль этого вступления такова: многопоточность следует использовать разумно. Не создавайте несколько потоков только потому, что это возможно. Многие полезные и мощные программы по-прежнему строятся на основе одного первичного потока, принадлежащего процессу.

).

 

Ммм... Честно говоря не очень понимаю, как один поток и один цикл на всё (ну разумеется кроме отрисовки экрана и курсора, а то тормозящая мышь это пц) сможет тормознуть топовую конфигурацию. Тут уже от ума программиста зависит, а не от количества потоков.

 

Я про в лоб, на бейсике и «скорости хватит».

 

Ну в лоб и на бейсике и скорости хватит предполагают мозг

 

Грим, учи матчасть... То что сейчас называется потоками как на одном процессоре реализуется?