Ламерский вопрос

[GNTB]

По настоящему ламерский вопрос про программирование и компы:

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

PS И не надо ответов в стиле: "Убей сибя ап стену!".

Я серьёзно. Обьясните физику процесса.

PS Это один из примеров. Также: например, почему в аркадах одновременно движутся и твой спрайт, и враждебные спрайты?

[GNTB]

Предположу, что используются прерывания. Версия:
Программа получает сигнал от контролёра клавиатуры (мыши, джойстика, gamepad'а), ЦП обрабатывает, перерисовывает спрайт в другом месте (пикселем-другим дальше), стирает прежнее положение. Прерывается. Переходит к подпрограмме, отвечающей за мелодию, обращается к звуковухе, извлекает ноту. Прерывается. Переходит и обрабатывает подрограмму перемещения врага. Прерывается. Возвращается к подпрограмме, работающей с персонажем.

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

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

Про 3D я даже и думать боюсь.

Очевидно, проще текстовые квесты делать. А вы спрашиваете, откуда столько низкокачественных квестов?
А потому, что многие команды делают их, не потому, что любят квесты, а потому, что это технически несколько проще станет.

[GNTB]

Таак... Я запутался. Наверно, следовало так: спрайт стирается, затем перерисовывается в другом месте, пикселем-другим дальше.
(а не наоборот).

[Hrumer]

Таак... Я запутался. Наверно, следовало так: спрайт стирается, затем перерисовывается в другом месте, пикселем-другим дальше.
(а не наоборот).

Это в старые времена DOS можно было задумываться про прерывания, ассемблерные вставки и прочее. Сейчас все это намного проще, хош сам под DirectX/OpenGL пишешь, хош через надстройки для них в виде компонентов и голова у тебя не болит. Просто указываешь какие спрайты в каком месте рисуются и отрисовывается весь экран.

[Кость]

Также: например, почему в аркадах одновременно движутся и твой спрайт, и враждебные спрайты?

Расчет перемещений, как правило, происходит последовательно -- сначала для первого объекта, который виден на экране, потом для другого, третьего и так далее до последнего. Компьютер складывает числа "в уме" довольно быстро. А обновляется экран тоже быстрее, чем может воспринять глаз человека. Потому и кажется, что одновременно.
В 3D все тоже самое с расчетами, только расчитывать надо побольше -- не только траекторию ракеты, но и освещение на пути этой ракеты, реакцию жертвы, в которую эта ракета попала, вмятины в стенах и т.п.

[GNTB]

Так. Стоп. Извините.

Всё, написаное МНОЙ выше (кроме первого поста) - считать бредом.
Я задал вопрос, не получил ответа (в тот момент), ударился в неподкреплённые практикой фантазии, а потом обьявил всё это правдой жизни. Это даже не глупость - это психическая аномалия.

[Hrumer]

Так. Стоп. Извините.

Всё, написаное МНОЙ выше (кроме первого поста) - считать бредом.
Я задал вопрос, не получил ответа (в тот момент), ударился в неподкреплённые практикой фантазии, а потом обьявил всё это правдой жизни. Это даже не глупость - это психическая аномалия.

- Доктор, мы его теряем!
- Не переживайте сестра, там таких еще целая палата.

[GNTB]

Нет. Я уникален в своей самонадеянности

[Hrumer]

Нет. Я уникален в своей самонадеянности

По факту посты бесмысленные. В первом посте ты задал вопрос, во втором сам же на него ответил. Любиш сказки про серого/белого бычка?
Если это тебе нужно для своего проекта, то знания познаются именно в практике. Можно бесконечно облизывать технологию отображения спрайтов и одновременного перемещения их по экрану, но так и не вникнуть в смысл. Если есть идея, то на её основе нее можно создать концет проекта хоть на бумаге или в виде текстового файла, а уже потом реализовать это программно/графически.

[Dmitriy 1st]

GNTB

Я серьёзно. Обьясните физику процесса.

мдаааа... вот и выросло поколение Windows... Одно радует - что твоя голова вообще задается подобными вопросами и пытается найти на них ответ, значит не все еще потеряно
На самом деле, все очень просто. Раньше, во времена DOS при написании любой игрухи (да и любой более-менее серьезной программы) был так называемый главный цикл, выглядивший в общих чертах так :

пока НЕ КОНЕЦ игры
отрисовать текущее состояние игрового экрана
опросить устройства ввода (и изменить в зависимости от реакции координаты героя, объектов)
пересчитать состояние самой игры (на основе изменившихся координат или просчитать реакцию AI на их изменение)
проиграть кусочек музыки
ПОВТОРЯТЬ

Как разбить все вышеозначенные пункты так, чтобы ни на одном из них программа не "залипала" слишком долго и тем самым не тормозила вывод графики, например, было задачей кодеров. Проигрывание музыки же вообще не было проблемой, ты наверное забываешь, что у звуковых карт, есть своя небольшая ОЗУ, можно всего десятком команд звуковой карте заставить ее пиликать разными MIDI инструментами хоть полчаса Тем не менее, подход этот не очень совершенен и чаще всего использовалась система прерываний. Для проигрывания цифровых сэмплов в интерактивном режиме использовалась система прерываний, а если быть точнее – прерывание системного таймера, которое инициировалось каждые 55 ms, подсадив на него свой обработчик, ты мог проигрывать что угодно и в какое угодно время.

А далее пришла эра Windows, которая является МНОГОЗАДАЧНОЙ ОС, т.е. она сама регулярно дает поработать всем запущенным программам, распределяя в соответствии с их приоритетом выделяемое им время. Запускаешь проигрыватель спецэффектов/музыки и контроллер устройств ввода в отдельных threads одного процесса (игры), организуешь связь между ними и все.

PS Это один из примеров. Также: например, почему в аркадах одновременно движутся и твой спрайт, и враждебные спрайты?

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

[GNTB]

Одно радует - что твоя голова вообще задается подобными вопросами и пытается найти на них ответ, значит не все еще потеряно

Угу... Спасибо. Изучаем потихоньку...

[GNTB]

Туплю...

Написал такую ерунду:

#include <iostream.h>

main()
{
short unsigned int suiPeremennaya = 0;
cout << "suiPeremennaya = " << suiPeremennaya << endl;

_asm {
mov ax, 300
mov ah, 0
shr ax, 1
mov suiPeremennaya, ax
}

cout << "suiPeremennaya = " << suiPeremennaya << endl;

return 0;
}

Думал, получу 128. Пишет: 22... Я считал, что AH - верхняя восьмибитная часть 16-разрядного регистра AX. Что обнуляю я верхние 44, и оставляю 256. Затем совершаю сдвиг вправо. Память в x86 адресуется вроде от большего к меньшему, но это вроде здесь нипричём?

Всё. Я "завис". Жму reset для перезагрузки головного мозга.

Sorry, я "чайник".

[GNTB]

Действительно туплю...

00000001 00101100
00000000 00101100
00000000 00010110

Извините...
...спасибо за внимание. Всё правильно...