Game в OpenGL на FASM

Я скачал себе NVidia OpenGL SDK 10, но он нихрена не пашет. Говорит, что настройки глючные и повторная установка может испровить данный error. Переустанавливал раз десять, но ничего не получилось. Это у меня руки кривые или SDK глючный? Сейчас вытягиваю другую версию.
Книгу, предлагаемую вами, можно ли скачать где-нибудь? У меня безлимитка поэтому скачать дешевле, чем купить.
Как в геймах обрабатывается движение моделей?

 

Hotwire
NVidia OpenGL SDK 10 заточен под самую последнюю видюху от энвидиа
Лучше скачай 9 ый сдк. Там все работает

 

В тьюте по вертексному программированию сказано, что сама вертексная прога это строка, а вызывая соответствующие функции эта прога компилируется.

 

Поле боя я сделал 4-х угольником, с текстурой на нем (пока еще RAW-файл).Танки планирую заменить простыми треугольниками. Как заставить их двигаться?

 

Hotwire

Джим Адамс "DirectX продвинутая анимация", другой не знаю.
Хоть и под директ, но принципы общие. Синхронизация анимации и движения.
Если в кратце, то создаётся массив структур или список. В этой структуре:
1. время относительно начала анимации
2. матрица трансформации.
Определяешь текущее время относительно начала анимации, проходишься по массиву, определяешь между какими элементами массива находится это время, интерполируешь матрицу трансформации для текущего времени, по матрицам тех элементов массива между которыми находится тек. время, и применяешь её к объекту. Если объектов много, то есно надо много массивов. Но это так простая штука. А ещё есть движение по маршрутам, по кривым безье, скелетная.

 

Что понимается под массивом структур?

 

Ну в принципе без разницы что, главное чтобы у тебя была информация о движении.

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

В первый элемент записываешь информацию о первом движении, то есть 2 сек. и матрицу конечной точки движения через эти 2 сек, в следующий элемент структуры соответственно 5 сек, и матрицу конечной точки для этого времени. Допустим у тебя текущее время 4 сек, тебе нужно найти матрицу которая бы определила положение объекта в это время. Вначале находится пара элементов массива, где заключено время 4 сек. Берём первую матрицу, и интерполируем её ко второй, согласно тому проценту времени, которое прошло от времени записанного в первом элементе, у нас это будет 3сек/2сек.

 

Hotwire

Бросте это дело, Холмс, бросте! (С).

Игры вот так ни с того ни с сего не пишутся. Напиши для начала прыгающий кубик с текстурой. Пусть прыгает по шарику. Думаю надоест быстро.

Даже если ты завтра проснешся с идеальным знанием всей компьютерной и некомпьютерной графики, то это будет только 5% от всего пути, который надо пройти для того, чтобы создать игру.

 

_DEN_

Полностью поддерживаю. Опыт тут нужен нехилый. Я бы например с нуля точно не стал бы писать, какой-нибудь готовый движок использовал бы. Нужно разбивать задачи.
Хотя с другой стороны, писали же для spectrum-а, тот же сфинкс или дриллер. Я щас вот думаю, ни фига себе, это ж какими профи надо быть, там ведь даже OpenGL и не пахнет, и ассемблеры и ресурсы там убогие до нельзя. Что тут сказать: учиться и ещё раз учиться. Так что Hotwire обкладывайся книгами и в добрый путь.

 

Booster

Я ковырялся в игрушках на Commodore64, процессор там и вправду "убогий" - регистров всего-ничего, и скорость низкая, зато большие возможности были у графического и звукового процессора. Несколько графических режимов с аппаратной поддержкой спрайтов (правда этим мало кто пользовался, разработчики в основном предпочитали выжимать максимум в программной части). Некоторые игры - программистские шедевры. (например, "N4S" оттуда пошла).

 

crypto
Ну про Commodore64, не знаю, не довелось.
А spectrum то вообще убогий.
Как мне говорили, игры для него на PC писались, типо через эмуль что ли. Ну всё равно с таким набором инструкций, да памятью, наверняка вручную приходилось всё колбасить, ведь если использовать какую-нибудь библиотеку, размер будет очень сильно увеличиваться. Хотя конечно это сейчас всех развратили огромные ресурсы, в том числе писателей библиотек (VCL -). ). Сейчас даже слышу от многих, что писать на асме это дурной тон.

 

Для закрепления ранее полученых знаний напишу прыгающий кубик с текстурой.

 

Hotwire

Самое сложное в архитектуре игрового движка (не графического, а именно игрового), это менеджер и менеджмент игровых объектов. А графика - это просто

 

Что входит в обязанности графического движка.
Простите за беграммотность в этом деле.

 

Hotwire

В обязанности графического движка входит рисование В каком виде возможно реализрвать движок на ассемблере - сказать сложно) Ты видимо первый, кто пытается это делать))

 

А можно коротко алгоритм его работы.

 

Hotwire

Коротко - нет. Есть объекты понятия графики (текстура, меш, итд), есть менеждер(рендерер), который этими объектами оперирует. Есть граф сцены. Есть рисовальщег сцены - он процессит граф сцены и передает рендереру нужные объекты.

 

Когда я писал прыгающий кубик, который прыгал на плоскость, то в обработке его движения не было ничего сложного. Я привязал координату одной вершины к всем остальным и изменял только ее. Перед каждым новым кадром матрица вида очищалась. С кубиком все просто, а как быть с более сложными объектами (ну, например, с vertex array)?

 

Где можно достать иклюды под FASM для работы со всеми расширениями OpenGL'а?