http://www.gamedev.ru/community/gamedev_lecture/ Gamedev Lecture ru http://skif.qrim.ru/ http://www.gamedev.ru/community/gamedev_lecture/articles/lecture36 Sat, 01 Aug 2009 18:24:59 GMT http://www.gamedev.ru/community/gamedev_lecture/articles/lecture36 http://www.gamedev.ru/community/gamedev_lecture/forum/?id=123901 angelscript Lua vm <p>Лекция Black_Phoenix с обзором VM скриптовых языков Lua и AngelScript. Часть вторая. <p>[19:00] &lt;Black_Phoenix&gt; Это вторая часть лекции о вирутальных машинах/скриптовых языках AngelScript и Lua. В первой части лекции было рассмотрено различие между ними (вкратце), а также виртуальная машина LVM (языка Lua) <br />[19:00] &lt;Black_Phoenix&gt; Первую часть лекции можно найти по этой ссылке: <a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=4446">http://www.gamedev.ru/community/gamedev_lecture/articles/?id=4446</a> <br />[19:01] &lt;Black_Phoenix&gt; В второй части будет кратко рассмотрено виртуальную машину AngelScript, и также то, как можно биндить Lua и AngelScript в ваших програмах. <br />[19:02] &lt;Black_Phoenix&gt; AngelScript сравнительно новый проект - он был начат примерно в 2003ем году некиим Андреасом Джонсоном. Это достаточно интересный скриптовый движок - он есть strong-typed как уже раньше говорилось, и он достаточно близок к С <br />[19:03] &lt;Black_Phoenix&gt; В основе AngelScript сидит виртуальная машина AngelScript. Она по своей архитектуре чем-то напоминает архитектуру ARM, и даже ненмого х86. <br />[19:04] &lt;Black_Phoenix&gt; Одинм из бонусов такой архитектуры (и вообще движка в целом) есть то, что AngelScript умеет вызывать прибинденые функции С по stdcall (или ещё некоторым конвенциям) - т.е. в принципе ничего биндить как в Lua не надо. <br />[19:05] &lt;Black_Phoenix&gt; Здесь достаточно указать функцию (её сигнатуру), её входную точку (т.е. указатель на функцию), и то какие она типы принимает или отдаёт. <br />[19:05] &lt;Black_Phoenix&gt; Весь AngelScript основан на принципах ООП - структура движка достаточно модульная, и разобраться в его работе совершенно не составляет труда. <br />[19:06] &lt;Black_Phoenix&gt; Как и в прошлый раз при рассмотрении Lua начнём рассматривать AngelScript с самого начала. В начале создаёться обьект asIScriptEngine - собвственно сам скриптовый движок (точнее это интерфейс к нему). <br />[19:07] &lt;Black_Phoenix&gt; Для этого вызваеться функция asCreateScriptEngine() [as_scriptengine.cpp:161], которая проверяет настройки платформы (размеры всех базовых типов, также порядок байт), и создаёт сам движок - asCScriptEngine [as_scriptengine.h:76]. <br />[19:07] &lt;Black_Phoenix&gt; Да кстати, здесь используеться такое же обозначение как в прошлой лекции - ссылки на исходные коды выглядят вот так: [имя файла:номер строки] <br />[19:08] &lt;Black_Phoenix&gt; В принципе этот &quot;движок&quot; и есть стейтом для виртуальной машины, также она привязывает к себе другие блоки - компилятор, интерпретатор, менеджер памяти, сборщик мусора. <br />[19:08] &lt;Black_Phoenix&gt; Перед рассмотрением самого стейта имеет смысл посмотреть на asCObjectType [as_objecttype.h:112] - базовый тип обьекта в AngelScript. <br />[19:09] &lt;Black_Phoenix&gt; Каждый обьект наследуется от этого класса - и предоставляет AngelScript информацию о своём названии, базовом типе (ссылка на acIObjectType - интерфейс), настройкам, и размере. <br />[19:09] &lt;Black_Phoenix&gt; Реализация операций над обьектом зделана через такие себе Behaviours - поведение обьекта в разных ситуациях - при добавлении, отнимании, и т.п. В AS есть такой тип как asEBehaviours - энумерация всех возможных поведений [angelscript.h:135] <br />[19:11] &lt;Black_Phoenix&gt; В принципе тут всё понятно - хотя видно разницу против типов Lua. Так вот, стейт движка хранит в себе списки всех зарегистрированых типов, синонимов к типам (typedefs), и энумераций (registeredObjTypes, registeredTypeDefs, registeredEnums). <br />[19:11] &lt;Black_Phoenix&gt; Также тут храниться таблица всех глобальных функций и переменных (registeredGlobalProps, registeredGlobalFuncs), информация о шаблонах (templateTypes), адреса всех глобальных переменных, вообще все функции (scriptFunctions) котрые были где-либо обявлены. <br />[19:11] &lt;Black_Phoenix&gt; Здесь же есть функции для получения и работы со всеми этими таблицами и информацией. <br />[19:12] &lt;Black_Phoenix&gt; Вообще в этом &quot;движке&quot; полно классных и интересных функций - все их рассматривать долго, но стоит уделить некоторым внимание. Тут есть много функций подобных RegisterObjectType - регистрация собственных типов, свойств, функций. <br />[19:13] &lt;Black_Phoenix&gt; Тут есть загрузка скриптовых модулей, представленная GetModule(), которая возвращает интерфейс к модулю (asIScriptModule [angelscript.h:594]), от которого позже можно получить индексы всех функций модуля, переменных, и т.п. <br />[19:14] &lt;Black_Phoenix&gt; Модули проименованы, и модуль без имени (вместо указателя на строку просто 0) ссылаеться на глобальный контекст - через него можно получать глобальные переменные и функции <br />[19:14] &lt;Black_Phoenix&gt; Кстати все функции как уже говорилось находяться в одной таблице - ScriptFunctions, и &quot;индексом функции&quot; возвращаемым всеми разными модулями есть именно индекс функции в этой таблице (массиве) <br />[19:15] &lt;Black_Phoenix&gt; А вот что нас интересует, это CreateContext(). Если брать аналогию с Lua, то здесь движок - global_State, а контекст - это собственно то, что задаёт состояние самой виртуальной машины, её выполнение. <br />[19:16] &lt;Black_Phoenix&gt; Контекстом выполнения являеться asIScriptContext [angelscript.h:656] - здесь есть функции для подготовки, запуска, остановки текущего выполнение, для установки аргументов передаваемых в скрипт (функцию), получения возвращённого значения, обработки исклю <br />[19:16] &lt;Black_Phoenix&gt; чений, и функции для отладки скрипта. <br />[19:16] &lt;Black_Phoenix&gt; Реальной имплементацией контекста есть asCContext [as_context.h:60]. <br />[19:17] &lt;Black_Phoenix&gt; Тут есть прямой указатель на двоичные данные байткода, указатель на стек, указатель на текущую функцию, стек вызовов функций, данные о последнем исключении, ссылка на коллбеки (коллбек который вызываеться для каждой строки, и для исключений). <br />[19:17] &lt;Black_Phoenix&gt; Стек задаётся указателем на стек-фрейм функции - stackFramePointer, и указателем на сам стек - stackPointer. <br />[19:17] &lt;Black_Phoenix&gt; Байткод кстати достаточно интересный. Каждая инструкция виртуальной машины может быть от 1 до 18 байт в длину - в зависимости от передаваемых параметров. <br />[19:18] &lt;Black_Phoenix&gt; Набор опкодов чем-то напоминает ARM архитектуру, и вообще архитектуры разных процесоров в целом. Здесь есть 174 опкода, которые есть всемя возможными комбинациями операндов <br />[19:19] &lt;Black_Phoenix&gt; Кстати, операции прибавления, множения и всё такое выполняються в 64 битах - если исходное значение меньше чем 64 бита, то оно должно быть приведено к 64-битному значению <br />[19:20] &lt;Black_Phoenix&gt; Полный список опкодов есть здесь: <a href="http://www.everfall.com/paste/id.php?3kep988a627d">http://www.everfall.com/paste/id.php?3kep988a627d</a> (немного табуляция сломалась) <br />[19:21] &lt;Black_Phoenix&gt; Операндом может быть константа (передаётся в инструкции), регистр (в AS есть один регистр, называеться он &quot;register1&quot; или просто &quot;v&quot;), либо значение со stack-frame функции (тогда оно обозначается как &quot;vn&quot; где n это сдвиг относительно stackFramePointer). <br />[19:21] &lt;Black_Phoenix&gt; Кстати в AngelScript есть удобная и полезная функция, которая выводит в файл скомпилированый байткод - надо просто скомпилировать библиотеку в режиме отладки (должен существовать дефайн AS_DEBUG) <br />[19:22] &lt;Black_Phoenix&gt; Для примера скомпилируем вот такой код: &quot;int a = 10; int b = 20; sin(a+b)&quot; (если у нас уже определена функция sin(float). В результате будет сгенерирован вот такой байткод: <a href="http://www.everfall.com/paste/id.php?v8e2lo7qn0ut">http://www.everfall.com/paste/id.php?v8e2lo7qn0ut</a> (и записан в файл) <br />[19:23] &lt;Black_Phoenix&gt; В первой колонке будет находиться сдвиг инструкции в байткоде (в байтах), во второй колонке размер stack frame функции (текущий), звёздочка обозначает меченые опкоды (для отладки), дальше название опкода и передаваемые параметры. <br />[19:23] &lt;Black_Phoenix&gt; Цифры между минусами (например &quot;- 1,13 -&quot;) показывают номер строки (1) и столбца (13) той части скрипта, для которой следует байткод. <br />[19:23] &lt;Black_Phoenix&gt; Интересный опкод SUSPEND - он вызывает коллбек для каждой строки. Вообще он не являеться необходимым - но его нельзя отключить (его добавление зашито в компилятор AngelScript). <br />[19:24] &lt;Black_Phoenix&gt; Без него прервать выполнение кода будет невозможно (либо пока выполнение не выйдет из блока в котором храниться байткод) <br />[19:24] &lt;Black_Phoenix&gt; Кстати, недавно была дискуссия о новой JIT для AngelScript - пока правда только для платформы ARM. (Её можно прочитать здесь <a href="http://www.gamedev.net/community/forums/topic.asp?topic_id=537993">http://www.gamedev.net/community/forums/topic.asp?topic_id=537993</a>). Пока что насколько я знаю пока что нету рабочей JIT AngelScript. <br />[19:25] &lt;Black_Phoenix&gt; В принципе в общем здесь всё - более технические детали очень легко узнать самим. Стоит заметить что здесь тоже есть сборка мусора, которая производится периодически, и просто убирает все элементы на которых больше нету ссылок. <br />[19:26] &lt;Black_Phoenix&gt; А вот теперь самая полезная часть лекции - о том как собственно биндить AngelScript и Lua. Надеюсь вы читали/смотрели последнюю лекцию, и знаете основные понятия Lua и то, как она работает. <br />[19:26] &lt;Black_Phoenix&gt; Я постараюсь приводить примеры с комментариями для этой части лекции, возможно будут задержки (при заливании кода на everfall.com). Я уделил немного больше внимания Lua, поскольку она более популярна, и более сложна в освоении <br />[19:27] &lt;Black_Phoenix&gt; Начнём с простого - просто создадим стейт Lua. Для этого надо вызвать lua_open() или lua_newstate() - это одно и тоже (но lua_open(), он же luaL_newstate() подставляет malloc, free, realloc как обычные функции работы с памятью). <br />[19:28] &lt;Black_Phoenix&gt; У нас получаеться такой код (надо не забыть закрыть Lua, и высвободить её ресурсы): <a href="http://www.everfall.com/paste/id.php?3f2uig2twqt2">http://www.everfall.com/paste/id.php?3f2uig2twqt2</a> <br />[19:28] &lt;Black_Phoenix&gt; (этот, и следущие исходные коды будут на С, я опустил заголовки и всё такое для краткости) <br />[19:29] &lt;Black_Phoenix&gt; Стоило бы кстати ещё загрузить стандартные библиотеки. Это можно зделать вызовом luaL_openlibs(),&nbsp; передав туда наш стейт (вообще, во все функции Lua надо передавать стейт lua_State, это же С) <br />[19:30] &lt;Black_Phoenix&gt; Если позволите, в дальшейнем я опущу обработку ошибок от вызовов функций Lua - её можете потом добавить сами. Ну, разве что кроме только вывода ошибок в самом скрипте (об этом чуть ниже) <br />[19:30] &lt;Black_Phoenix&gt; Теперь у нас есть готовая среда для запуска скрипта. Для начала просто запустим некоторою строку (скажем &quot;myvar = 200; print('Variable is '..myvar)&quot;). Для этого есть замечательная функция luaL_dostring() <br />[19:31] &lt;Black_Phoenix&gt; Теперь наш код выглядит так (помните, мы загрузили функцию print вместе со стандартной библиотекой): <a href="http://www.everfall.com/paste/id.php?rc6659i1hciq">http://www.everfall.com/paste/id.php?rc6659i1hciq</a> <br />[19:31] &lt;Black_Phoenix&gt; Продолжим. Мы теперь можем запускать строчку - как теперь загрузить целый скрипт? Вообще, вызов luaL_dostring() это два вызова других функций - luaL_loadstring() который компилирует наш скрипт в байткод, и возвращает его на стек, и lua_pcall() для его запуска. <br />[19:32] &lt;Black_Phoenix&gt; Т.е. реально мы компилируем наш скрипт как одну функцию - что-то вроде &quot;function script() ..сюда идёт всё что мы передали в loadstring.. end&quot;, а затем её вызываем. Если мы просто вызовем loadstring, а потом очистим стек, то байткод будет убран сборщиком мусора. <br />[19:32] &lt;Black_Phoenix&gt; Давайте пока у нас есть просто скрипт, в котором прописана логика функции TakeDamage (получить урон) нашего персонажа (мы кстати делаем мморпг сервер). <br />[19:33] &lt;Black_Phoenix&gt; Она принимает количество жизней, и возвращает новое количество жизней (после получегого урона). Т.е. это просто логика поведения сервера <br />[19:33] &lt;Black_Phoenix&gt; Наш скрипт будет таким: <a href="http://www.everfall.com/paste/id.php?yiwylnxxdfiq">http://www.everfall.com/paste/id.php?yiwylnxxdfiq</a> <br />[19:33] &lt;Black_Phoenix&gt; А вот так мы его запустим: <a href="http://www.everfall.com/paste/id.php?0wx6ujrwy0tc">http://www.everfall.com/paste/id.php?0wx6ujrwy0tc</a> <br />[19:34] &lt;Black_Phoenix&gt; И вдруг он не работает! Казалось бы что не так, ведь вроде всё правильно. Нам бы не помешал вывод ошибок в консоль - а зделать это очень просто. Lua построена так, что компилятор в случае ошибки, вернёт нам её текст на стеке. <br />[19:35] &lt;Black_Phoenix&gt; Мы просто должны напечатать эту строчку если значение, возвращённое luaL_dostring не ноль. Изменим нашу програму вот так: <a href="http://www.everfall.com/paste/id.php?vx1odvpfar0t">http://www.everfall.com/paste/id.php?vx1odvpfar0t</a> <br />[19:35] &lt;Black_Phoenix&gt; И вот мы видим ошибку: &quot;1: 'end' expected near '&lt;eof&gt;'&quot;. И тут понимаем, что забыли дописать в конец строки &quot;\n&quot;, ведь у нас там есть коментарий, который собой коментирует наш end. <br />[19:36] &lt;Black_Phoenix&gt; Добавляем &quot;\n&quot;, у нас получаеться вот такой код: <a href="http://www.everfall.com/paste/id.php?67piuhoqn8wd">http://www.everfall.com/paste/id.php?67piuhoqn8wd</a> и он успешно запускаеться. <br />[19:37] &lt;Black_Phoenix&gt; Пора приступать к самому движку нашей ММОРПГ, а именно - наш персонаж должен получать урон. Скрипт уже обрабатывает наше событие, осталось его только вызвать. <br />[19:38] &lt;Black_Phoenix&gt; Для этого мы хотим получить функцию TakeDamage из глобальной таблицы (а наша функция, заметьте глобальная). В Lua для этого используется вызов lua_getglobal который возвращает указатель функции на стек (делает PUSH). <br />[19:39] &lt;Black_Phoenix&gt; Дальше запихнём наши текущие жизни на стек через функцию lua_pushinteger (есть такие-же функции для всех типов Lua, кроме таблиц), и вызовем получение урона (у нас на стеке всё уже как надо, просто запускаем интерпретатор через lua_call). <br />[19:39] &lt;Black_Phoenix&gt; Не забудем правильно указать количество аргументов, и результатов которые мы ждём, и потом не забудем забрать результат со стека. <br />[19:39] &lt;Black_Phoenix&gt; Получение результата выполняеться функциями lua_tonumber, lua_tostring, и т.д. Результат будет нас ждать начиная с текущего положения на стеке. <br />[19:40] &lt;Black_Phoenix&gt; (оно правильно устанавливаеться вызваной функцией, переданые параметры будут убраны) <br />[19:41] &lt;Black_Phoenix&gt; Вот такой у нас код получился: <a href="http://www.everfall.com/paste/id.php?i2qpb2wdla4u">http://www.everfall.com/paste/id.php?i2qpb2wdla4u</a> <br />[19:41] &lt;Black_Phoenix&gt; Запускаем, видим что жизней стало 75. Повод отпраздновать! Теперь наша ММОРПГ достигла версии 0.99 BETA <br />[19:42] &lt;Black_Phoenix&gt; Это классно, но мало. Хочется что-бы скрипт мог вызывать наши функции (функции написаные на С). Зделаем функцию на С - RandomDamage, которая вернёт случайное повреждение для нашего героя. <br />[19:43] &lt;Black_Phoenix&gt; Любая С функция вызываемая Lua должна быть за таким шаблоном: &quot;int &lt;function name&gt;(lua_State *L)&quot;, т.е. нам надо всегда возвращать целое, и принимать указатель на стейт. Возвращаемое значение - код ошибки (если всё хорошо, то это будет 1). <br />[19:43] &lt;Black_Phoenix&gt; Итак, мы написали нашу функцию (она у нас будет принимать два значения - нижний и верхний порог случайного повреждения). Не забываем что параметры следуют за самой функцией, а при вызове функции вершина стека указывает на первый аргумент (на стеке). <br />[19:44] &lt;Black_Phoenix&gt; Зарегистрировать функцию просто - есть удобная функция lua_register(). <br />[19:45] &lt;Black_Phoenix&gt; У нас получился вот такой код (не забудем поправить скрипт для вызова нашей С функции): <a href="http://www.everfall.com/paste/id.php?imu8u3iqifrj">http://www.everfall.com/paste/id.php?imu8u3iqifrj</a> <br />[19:45] &lt;Black_Phoenix&gt; Всё хорошо, но дедлайн нашей ММОРПГ близиться, и пора бы уже выделить героя в отдельный обьект. В Lua это делается достаточно легко - мы просто зделаем таблицу, в которой будут храниться жизни и броня героя (как-бы обьект). <br />[19:46] &lt;Black_Phoenix&gt; Кстати, размер скрипта растёт, пора бы его зделать в отдельном файле. Создадим файл &quot;rpg.lua&quot;, и засунем туда вот такой код (инициализация игрока, и его методы): <a href="http://www.everfall.com/paste/id.php?0zat0o73e5xt">http://www.everfall.com/paste/id.php?0zat0o73e5xt</a> <br />[19:47] &lt;Black_Phoenix&gt; Заметьте обьявление функций героя - если мы пишем так, как в скрипте, то мы добавляем функции в таблицу &quot;HERO&quot;. Это будет &quot;базовый класс&quot; нашего героя. Мы также зделали функцию &quot;utilNewHero&quot; которая создаст нового героя (возможно с параметрами) <br />[19:47] &lt;Black_Phoenix&gt; Создавать героя мы будем из нашей програмы - а затем менять его характеристики и вызывать его функции. <br />[19:47] &lt;Black_Phoenix&gt; Итак, сначала мы вызовем utilNewHero. Потом мы инициализируем нашу таблицу (вызовем для неё функцию Initialize) - а дальше просто будем работать с нашим героем. <br />[19:48] &lt;Black_Phoenix&gt; Кстати, вызов у нас непростой - здесь мы должны передать нашего героя в функцию - так, что-бы работал SELF. <br />[19:49] &lt;Black_Phoenix&gt; Для того что-бы это работало (а это эквивалентно вызову some_hero:Initialize(..)) нам надо будет передать нашу таблицу героя как первый параметр функции <br />[19:50] &lt;Black_Phoenix&gt; Т.е. some_hero:Initialize() - тоже самое что и Initialize(some_hero,...), только компилятор Lua об этом знает (по тому, как была определена функция) <br />[19:50] &lt;Black_Phoenix&gt; Сейчас я покажу код, и детально опишу что мы делаем с нашим героем. Вот такой код у нас получился: <a href="http://www.everfall.com/paste/id.php?h0msm6bef8rq">http://www.everfall.com/paste/id.php?h0msm6bef8rq</a> <br />[19:51] &lt;Black_Phoenix&gt; (Я буду ссылаться на строки файла, они отмечены по ссылке) <br />[19:52] &lt;Black_Phoenix&gt; Для начала вызовем создание нашего героя - utilNewHero. Вызов такой как мы раньше видели, просто получаем функцию из глобальной таблицы, и вызываем её через lua_call <br />[19:53] &lt;Black_Phoenix&gt; Хочу заметить, что адресация стека, которая используеться в API lua достаточно странная. Здесь -1 это текущий элемент на стеке, -2 это предыдущий, -3 это ещё раньше... <br />[19:53] &lt;Black_Phoenix&gt; А вот положительные значения - это сдвиг относительно указателя base. 1 это base+1, и так далее <br />[19:54] &lt;Black_Phoenix&gt; Также есть специальные индексы - индексы из глобальной таблицы, и прочие. Но они нас не интересуют <br />[19:55] &lt;Black_Phoenix&gt; Итак, строчки 29-30 это создание героя. Мы говорим Lua что хотим передать 0 параметров, и получить 1 результат (таблица героя). Наш герой будет на стеке с адресом -1 <br />[19:56] &lt;Black_Phoenix&gt; Дальше мы хотим вызвать somehero:Initialize(..) - а это вызов HERO.Initialize(somehero,...). В строчке 35 мы получаем указатель на таблицу-базовый класс HERO <br />[19:56] &lt;Black_Phoenix&gt; Теперь по адресу -1 таблица HERO, по адресу -2 таблица героя <br />[19:56] &lt;Black_Phoenix&gt; В строчке 36 мы получаем поле из таблицы - HERO.Initialize. <br />[19:57] &lt;Black_Phoenix&gt; Теперь по адресу -1 находиться функция HERO.Initialize (её туда запихнул вызов lua_getfield), по адресу -2 - HERO, по адресу -3 - таблица героя <br />[19:57] &lt;Black_Phoenix&gt; нам больше таблица HERO не нужна, убираем её со стека на строчке 37 <br />[19:58] &lt;Black_Phoenix&gt; Теперь таблица героя передвинулась на позицию -2. Не забывайте что нам её надо передать первым параметром (а щас на стеке идёт сначала таблица, потом функция) <br />[19:58] &lt;Black_Phoenix&gt; Поэтому вызовом lua_pushvalue (фактически скопировать значение) мы копируем ссылку на таблицу, и заносим на стек <br />[19:59] &lt;Black_Phoenix&gt; За ним мы запихиваем жизни героя и его имя (так, как надо для вызова инициализации). Наш стек выглядит так: (-1) &quot;John Jackson&quot; | (-2) 125 | (-3) таблица героя | (-4) HERO.Initialize | (-5) таблица героя <br />[19:59] &lt;Black_Phoenix&gt; Мы вызваем функцию, и наш герой готов к бою <br />[20:00] &lt;Black_Phoenix&gt; После вызова функции со стека будет убрано всё, до указателя функции (и он тоже) <br />[20:00] &lt;Black_Phoenix&gt; Т.е. у нас будет стек такой: (-1) таблица героя (и это всё) <br />[20:01] &lt;Black_Phoenix&gt; Мы получаем &quot;health&quot; из таблицы нашего героя, а потом и &quot;name&quot;. Заметьте как адрес таблицы меняеться после добавления новых значений на стек <br />[20:02] &lt;Black_Phoenix&gt; Мы печатаем информацию, и правильно получаем &quot;Our heroes life is 125 percent, our hero is Mr. John Jackson&quot;. Не забудьте убрать значения со стека, иначе они там и остануться! Для этого надо вызвать lua_pop, аргументом есть количество значений которые надо убрать <br />[20:03] &lt;Black_Phoenix&gt; Пора в битву - в строчках 58-60 мы снова получаем указатель, теперь на Hero.TakeDamage; также как на строчках 35-37 <br />[20:03] &lt;Black_Phoenix&gt; Мы просто запихиваем таблицу героя на стек, и вызываем нашу функцию. Наш герой потерпел урон, и мы это проверим строками 67-71 (тоже самое что раньше) <br />[20:04] &lt;Black_Phoenix&gt; Нам правильно будет указано сообщение &quot;Mr. John Jackson got hurt! :( His life is now 123 %%&quot;. А наша таблица всё ещё находиться на стеке! <br />[20:05] &lt;Black_Phoenix&gt; Пора бы её сохранить в глобальной таблице - для этого есть (моя персонально любимая функция) lua_setglobal - она сохраняет текущий элемент в вершине стека в глобальную переменну <br />[20:05] &lt;Black_Phoenix&gt; Поскольку мы убрали &quot;health&quot; и &quot;name&quot; со стека, в вершине будет наша таблица - и она сохраниться в переменную &quot;johnhero&quot; <br />[20:06] &lt;Black_Phoenix&gt; Вызов lua_setglobal зделает POP - и уберёт текущее значение со стека. А нам John ещё нужен, поэтому мы просто заново получим его из глобальной таблицы (строчка 79) - и он будет снова на стеке. <br />[20:07] &lt;Black_Phoenix&gt; На строках 81-82 указано как можно не убирая значение со стека добавить его в глобальную таблицу - просто банально продублировать. Теперь у нас есть 2 ссылки на Джона - johnhero и john_is_the_hero <br />[20:08] &lt;Black_Phoenix&gt; Проверим что обе таблицы - это просто две ссылки на одну и туже таблицу. Просто запустим простой скрипт - поменяем жизни в одной таблице и увидим что они меняються в другой (строки 88-90) <br />[20:09] &lt;Black_Phoenix&gt; Наш сервер почти готов. Теперь вам должно быть легче работать с Lua. Единственное что я ещё хочу добавить это то, как можно создавать новые таблицы из C кода (или менять уже существующие) <br />[20:10] &lt;Black_Phoenix&gt; Допустим мы хотим програмно создать нового героя. Для этого мы сначала вывовем &quot;lua_newtable(L)&quot; - создание новой таблицы, и PUSH её на стек. <br />[20:11] &lt;Black_Phoenix&gt; Для редактирования таблицы теперь есть два пути. Первый путь добавить/изменить значение которое уже лежит на стеке с заданым ключём - через lua_setfield <br />[20:11] &lt;Black_Phoenix&gt; Для этого надо что-бы в текущей позиции на стеке была таблица, и нужно указать индекс добавляемого элемента. Например: <br />[20:12] &lt;Black_Phoenix&gt; lua_pushinteger(L,123); lua_newtable(L); lua_setfield(L,-2,&quot;my_integer&quot;); //целое число находиться в позиции -2, таблица - в -1 <br />[20:13] &lt;Black_Phoenix&gt; Есть второй, более красивый способ - использование lua_rawset(). Эта функция принимает индекс таблицы которую мы редактируем, и запихивает туда значения заданые парой ключ-значение которые находяться сейчас на стеке <br />[20:13] &lt;Black_Phoenix&gt; Создать нового героя для нашего мморпг сервера мы могли бы вот так: <br />[20:13] &lt;Black_Phoenix&gt; lua_newtable(L); <br />[20:14] &lt;Black_Phoenix&gt; lua_pushstring(L,&quot;health&quot;); lua_pushnumber(L,125); lua_rawset(L,-3); //-3 = идекс таблицы, щас у нас два значения в таком порядке: ключ - значение <br />[20:14] &lt;Black_Phoenix&gt; lua_pushstring(L,&quot;name&quot;); lua_pushstring(L,&quot;Jack Johnson&quot;); lua_rawset(L,-3); <br />[20:15] &lt;Black_Phoenix&gt; после этого в положении -1 (текущем положении стека) у нас будет наш новый герой (lua_rawset() делает POP два раза) <br />[20:15] &lt;Black_Phoenix&gt; По биндингу Lua это пока всё. Планировалось ещё рассмотреть сохранение состояния скриптов Lua - но это будет в отдельной лекции. <br />[20:16] &lt;Black_Phoenix&gt; Теперь кратко о биндинге AngelScript - я покажу только основы, а дальше очень легко разобраться самому - интерфейсы достаточно понятны и назначение функций очевидно. <br />[20:17] &lt;Black_Phoenix&gt; Для начала нам просто надо создать движок: asCreateScriptEngine(). После этого AngelScript уже будет готов к выполнению скриптов. Наш код будет выглядеть так: <a href="http://www.everfall.com/paste/id.php?jrf5pr0gcxix">http://www.everfall.com/paste/id.php?jrf5pr0gcxix</a> <br />[20:18] &lt;Black_Phoenix&gt; Нам скорее всего захочеться также смотреть ошибки скрипта. Это очень просто - нужно просто установить коллбек который будет вызываться при ошибке. AS передаёт структуру, которая содержит текст ошибки, и её позицию (строка, столбец). <br />[20:19] &lt;Black_Phoenix&gt; Вот пример установки такого коллбека: <a href="http://www.everfall.com/paste/id.php?jf3pvkr2qgkl">http://www.everfall.com/paste/id.php?jf3pvkr2qgkl</a> <br />[20:20] &lt;Black_Phoenix&gt; И наконец биндинг С функций - тут с этим очень просто. Нужно просто зарегистрировать нашу функцию как функцию глобальную (или функцию модуля, класса...). <br />[20:21] &lt;Black_Phoenix&gt; Мы передаём сигнатуру функции: &quot;&lt;возвращаемый тип&gt; &lt;название функции&gt;(&lt;тип 1&gt;, &lt;тип 2&gt;, ..)&quot;, указатель на точку входа, и параметры которые нужно передавать и возвращать. <br />[20:22] &lt;Black_Phoenix&gt; Есть специальный макрос asFUNCTIONPR который правильно скастует вашу функцию так, как нужно для AngelScript. Получаеться такой код: <a href="http://www.everfall.com/paste/id.php?9an52g7stcyy">http://www.everfall.com/paste/id.php?9an52g7stcyy</a> <br />[20:23] &lt;Black_Phoenix&gt; Если мы захотим запускать из файла, нам надо будет просто передать текст файла в ExecuteString, либо зделать свой контекст (CreateContext()), скомпилировать туда исходный код, и запустить. <br />[20:23] &lt;Black_Phoenix&gt; Это пока всё, можно задавать вопросы.</p><p><a href="http://www.gamedev.ru/community/gamedev_lecture/articles/lecture36?page=2">Продолжение</a></p> http://www.gamedev.ru/community/gamedev_lecture/articles/?id=4446 Sat, 25 Jul 2009 17:37:23 GMT http://www.gamedev.ru/community/gamedev_lecture/articles/?id=4446 angelscript Lua vm <p>Лекция Black_Phoenix с обзором VM скриптовых языков Lua и AngelScript. Часть первая. <p>[20:01:32] &lt;Black_Phoenix&gt; Короче я просто програмист, занимаюсь много чем, в т.ч. виртуальными машинами. Написал VM эмулятор PII, также специальную VM &quot;ZCPU&quot; для одной игровой модификации (внутриигровой микропроцессор, для цифровых схем). <br />[20:01:54] &lt;Black_Phoenix&gt; На данный момент я пишу ОС которая полностью основана на виртуальной машине, но это не тема этой лекции <br />[20:02:19] &lt;Black_Phoenix&gt; В этой лекции будет рассмотрено общее сравнение AngelScript и Lua (как кто-то попросил), а также небольшой глубокий экскурс в то, как они работают (т.е. сами вирутальные машины, интерпретаторы). <br />[20:02:52] &lt;Black_Phoenix&gt; Перед началом экскурса в сами VM рекомендуеться достать исходные коды [AngelScript 2.16.3] и [Lua 5.1.4]. Ссылки (действительная на момент лекции): <a href="http://www.angelcode.com/angelscript/sdk/files/angelscript_2.16.3.zip">http://www.angelcode.com/angelscript/sdk/files/angelscript_2.16.3.zip</a> <a href="http://www.lua.org/ftp/lua-5.1.4.tar.gz">http://www.lua.org/ftp/lua-5.1.4.tar.gz</a> <br />[20:03:11] &lt;Black_Phoenix&gt; Я буду ссылаться на файлы (в принципе пока нужна только Луа) <br />[20:03:36] &lt;Black_Phoenix&gt; В этой части лекции будет общее описание Lua и AngelScript, а также детальное описание движка Lua. Во второй части будет описание движка AngelScript, и информация о том, как их надо биндить (и возможно некоторые малоизвестные фичи). <br />[20:04:10] &lt;Black_Phoenix&gt; Итак, сначала общее. И AngelScript и Lua являються скриптовыми языками для использования в программах и играх. Lua была создана в 1993 году, и на данный момент используеться в очень многих проектах. AngelScript был создан в 2003 году, и пока я не встречал прое <br />[20:04:11] &lt;Black_Phoenix&gt; ктов которые его используют (т.е. лично не встречал). <br />[20:04:40] &lt;Black_Phoenix&gt; Для начала синтаксис: Lua использует свой синтаксис. Синтаксис AngelScript чем-то похож на синтаксис С++, он также поддерживает классы и наследование. <br />[20:04:56] &lt;Black_Phoenix&gt; Lua написана на чистом С, AngelScript написан на С++, его код достаточно объектно-ориентированый. <br />[20:05:21] &lt;Black_Phoenix&gt; (лично мне больше нравиться как написан AS, хотя там много C++-изма) <br />[20:05:41] &lt;Black_Phoenix&gt; В обоих языках пошаговый интерпретатор. Есть возможность отлаживать построчно, компилировать и запускать байткод. <br />[20:05:47] &lt;_ShaMan_&gt; remark: список проектов, которые используют AngelScript, можно увидеть здесь: <a href="http://www.angelcode.com/angelscript/users.asp">http://www.angelcode.com/angelscript/users.asp</a> <br />[20:06:06] &lt;Black_Phoenix&gt; В обоих движках есть поддержка coroutines (псевдо-паралельного выполнения), и поддержка multithreading (мультипоточности). Вообще в AngelScript несколько лучше реализована загрузка и сохранение байткода - более очевидно <br />[20:06:37] &lt;Black_Phoenix&gt; В второй части лекции (которая будет через неделю) я постараюсь показать как это делать с Lua (без сторонних утилит :) ) <br />[20:07:05] &lt;Black_Phoenix&gt; Lua - стековая виртуальная машина (хотя формально регистровая), AngelScript - регистровая (почти). <br />[20:07:31] &lt;Black_Phoenix&gt; Что важно, Lua есть почти для всех языков и платформ которые вам встретяться. С код достаточно легко компилируеться везде, и единственная привязка Lua к ОС это функции перераспределения памяти (не считая дополнительных библиотек). <br />[20:07:41] &lt;Black_Phoenix&gt; AngelScript есть на всех современных платформах (игровых консолях, разных ОС, также на iPhone). Известно что он компилируеться под MSVC++, GNUC, MinGW, DJGPP. <br />[20:08:06] &lt;Black_Phoenix&gt; Вообще насколько я знаю поддержка iPhone вам не нужна будет, на AppStore не принимаються виртуальные машины <br />[20:08:46] &lt;Black_Phoenix&gt; Lua требует биндинга каждой функции по своему, AS работает с функциями без биндинга (надо только сообщить движку о них). Lua использует свой стек для передачи параметров - и туда-же нужно их возвращать. AS вызывает функции по stdcall (точнее она сама <br />[20:08:47] &lt;Black_Phoenix&gt; подбирает способ вызова совместимый). <br />[20:09:21] &lt;Black_Phoenix&gt; Достаточно субьективно скажу, что Lua быстрее чем AS - здесь overhead при вызове функций, а также в garbage collectore меньше. Но в принципе по тестам они более-менее на одном уровне (по тому что я видел AS проигрывает Lua всего не более чем на 10%) <br />[20:09:51] &lt;Black_Phoenix&gt; Вообще при правильной архитектуре движка скорость скриптового движка не должна иметь значения <br />[20:10:11] &lt;Black_Phoenix&gt; В лекции я буду ссылаться на код вот так: [имя файла:номер строки], например [lvm.c:64]. В этой части пока только на исходники Lua <br />[20:10:48] &lt;Black_Phoenix&gt; Используеться такая терминология: <br />[20:11:04] &lt;Black_Phoenix&gt; (момент, я залью на everfall.com) <br />[20:11:27] &lt;Black_Phoenix&gt; <a href="http://www.everfall.com/paste/id.php?pt9ys4s20uk0">http://www.everfall.com/paste/id.php?pt9ys4s20uk0</a> вот <br />[20:11:47] &lt;Black_Phoenix&gt; Это кроме основных понятий которые должны быть знакомы. Почти всё есть на википедии (я проверял) <br />[20:12:08] &lt;Black_Phoenix&gt; Итак, Lua. В ядре луа сидит Lua virtual machine (LVM). LVM - формально регистровая VM, но вам врут, она не регистровая (регистрами там и не пахнет) - она всё ещё стековая. <br />[20:12:27] &lt;Black_Phoenix&gt; Опкоды LVM могут читать и писать на стек (это задаёться смещением), а также со списка констант который существует у каждой функции. <br />[20:13:05] &lt;Black_Phoenix&gt; В принципе она регистровая - здесь напрямую нету операций PUSH/POP для изменения стека, но тем не менее стек - основная структура данных, скелет Луа <br />[20:13:27] &lt;Black_Phoenix&gt; Нашу экскурсию мы будет начинать с [lua.h:110]. В этом месте определены основные функции - lua_newstate(...) lua_close(...), создание стейта для виртуальной машины. <br />[20:13:50] &lt;Black_Phoenix&gt; Для создания LVM вы должны их вызвать (они вообще вызываються автоматом при вызове lua_open(). Фактически lua_open() это просто вызов lua_newstate(..)). <br />[20:14:08] &lt;Black_Phoenix&gt; Итак, что такое стейт виртуальной машины? Это структура данных которая полностью определяет текущее состояние VM. <br />[20:14:30] &lt;Black_Phoenix&gt; В LVM определение стейта (это struct) содержиться в файле [lstate.h:100] (вообще строго говоря в LVM существует два стейта - глобальный и per-thread стейт). <br />[20:15:03] &lt;Black_Phoenix&gt; При вызове lua_newstate(...) будет создан новый lua_State (локальный/per-thread стейт, [lstate.h:100]), а также будет создан глобальный стейт (global_State, [lstate.h:68]). Далее для каждого нового треда LVM будет создаваться новый lua_State. <br />[20:15:28] &lt;Black_Phoenix&gt; Вообще global_State должен быть только одним - иметь их больше чем один смысла не имеет. <br />[20:15:58] &lt;Black_Phoenix&gt; SIDE-NOTE: луа поддерживает мультипоточность - при этом вы должны совершить такие действия: создать глобальный стейт LVM и создать главный поток (lua_newstate() или lua_open(), тоже самое). Дальше средствами ОС вы создаёте ещё один поток, в котором вызываете <br />[20:15:59] &lt;Black_Phoenix&gt;&nbsp; lua_newthread(), и запускаете скрипт. <br />[20:16:44] &lt;Black_Phoenix&gt; Сама Lua - полностью threadsafe, насколько я смотрел везде в критических местах есть защита от конкуренции нескольких потоков <br />[20:16:56] &lt;Black_Phoenix&gt; В результате у вас у каждого потока будет lua_State, и собственно свой статус LVM. Теперь использование обоих потоков идёт аналогично и паралельно. <br />[20:17:15] &lt;Black_Phoenix&gt; Вам возможно надо будет создать свой враппер/биндинг, поскольку в стандартной Lua нету библиотек для мультипоточности (т.е. что-бы это можно было вызывать из скриптов). <br />[20:17:45] &lt;Black_Phoenix&gt; Все потоки могут вызывать глобальные функции друг друга, почему будет сказано потом. <br />[20:18:10] &lt;Black_Phoenix&gt; Итак, теперь кратко о том, что же задают global_State и lua_State. Если вы использовали LVM/Lua то вы заметили, что почти в каждую функцию надо передавать &quot;lua_State *L&quot; - указатель на per-thread стейт (далее - просто &quot;стейт луа&quot;). <br />[20:18:53] &lt;Black_Phoenix&gt; Итак, lua_State ([lstate.h:100]) содержит в себе такие поля: <a href="http://www.everfall.com/paste/id.php?1ng1yo9ft9n6">http://www.everfall.com/paste/id.php?1ng1yo9ft9n6</a> (желательно ознакомиться) <br />[20:19:26] &lt;Black_Phoenix&gt; Это всё задаёт состояние скрипта, и упс, я забыл туда про garbage collector дописать :) <br />[20:20:11] &lt;Black_Phoenix&gt; Про global_State ([lstate.h:68]) я расскажу кратко (он в принципе менее интересен чем lua_State): <a href="http://www.everfall.com/paste/id.php?0qak518m03km">http://www.everfall.com/paste/id.php?0qak518m03km</a> <br />[20:20:39] &lt;Black_Phoenix&gt; Он менее интересен, в основном он только следит за всеми ресурсами и мусоросборщиком. <br />[20:21:40] &lt;Black_Phoenix&gt; В LVM есть несколько базовых типов - они все захардкожены прямо в виртуальную машину. На данный момент они такие [lua.h:74]: <a href="http://www.everfall.com/paste/id.php?5h2cpg36h0yq">http://www.everfall.com/paste/id.php?5h2cpg36h0yq</a> <br />[20:22:16] &lt;Black_Phoenix&gt; (различие между LUA_TLIGHTUSERDATA и LUA_TUSERDATA в том, как будут сравниваться два обьекта) <br />[20:23:10] &lt;Black_Phoenix&gt; LVM теоретически позволяет добавлять новые типы (надо только создать #define-ы, и функции для работы с типом, возможно поправить парсер), но я ещё не видел что-бы их добавляли прямо в VM <br />[20:23:28] &lt;Black_Phoenix&gt; Для типов подобных vector, color обычная таблица должна подойти <br />[20:24:03] &lt;Black_Phoenix&gt; Внутри LVM все типы называються общим именем TValue - типизированое значение. Оно задаёться структурой lua_TValue [lobject.h:73], которая содержит в себе числовой аналог этого типа (lua_Number), тип этого значения (например LUA_TTABLE), ссылку на свой обьект (GCObject), а <br />[20:24:03] &lt;Black_Phoenix&gt; также указатель на двоичные данные. <br />[20:24:42] &lt;Black_Phoenix&gt; lua_Number - это обычно 64-битный флоат, если не ошибаюсь. Но это можно перенастроить <br />[20:26:00] &lt;Black_Phoenix&gt; Стек в LVM - это просто стек из этих lua_TValue. base, top, stack, и другие в стейте lua_State - всё это указатели на элемент на стеке, которые имеют тип StkId [lobject.h:193]. <br />[20:26:24] &lt;Black_Phoenix&gt; StkId - не более чем просто указатель на lua_TValue, и так-же определяеться (как *TValue) <br />[20:27:01] &lt;Black_Phoenix&gt; При создании локального стейта создаёться стек (stack_init(...) в f_luaopen(...) [lstate.c:70]) размером BASE_STACK_SIZE + EXTRA_STACK_SIZE (обычно это 40 записей), и вершина стека устанавливаеться в его начало. <br />[20:27:59] &lt;Black_Phoenix&gt; Щас я попробую показать картинку того, куда указывают эти указатели <br />[20:28:48] &lt;Black_Phoenix&gt; Так, картинка будет чуть позже <br />[20:29:19] &lt;Black_Phoenix&gt; Итак, что происходит со стеком при вызове функции? Вызов любой функции Lua (не С) выполняеться вызовом lua_call(...) [lapi.c:776]. <br />[20:29:24] &lt;Black_Phoenix&gt; При вызове функции требуеться указать количество параметров которые передаються, и количество параметров которые ожидаються на выходе. <br />[20:29:46] &lt;Black_Phoenix&gt; SIDE-NOTE: вызов C-функции выполняеться вызовом lua_pcall(...) - protected call, который защищает стек Lua от &quot;повреждения&quot;. Оба способа вызова, как будет щас показано, почти одно и то-же. <br />[20:31:03] &lt;Black_Phoenix&gt; Все аргументы функции находяться на стеке, сразу после самой функции (которая тоже запихиваеться на стек). Stack-frame формально начинаеться как-раз с самой функции (вообще реально запихиваеться только указатель на функцию) <br />[20:32:09] &lt;Black_Phoenix&gt; При возвращении из функции все результаты будут на стеке, начиная с начала stack frame функции (обычно). Агрументы и результаты находяться на стеке в порядке pusha на стек. <br />[20:32:47] &lt;Black_Phoenix&gt; Результаты могут находиться и за аргументами (точнее оно так почти всегда), реально при выходе из функции она сама указывает где на стеке результаты <br />[20:33:05] &lt;Black_Phoenix&gt; Результаты - это то что возвращаеться return-ом, и может быть несколько (return x,y,z) <br />[20:33:37] &lt;Black_Phoenix&gt; lua_call(...) проводит нужные проверки, и запускает виртуальную машину если вызываемая функция - не C функция. Это проверяеться вызовом luaD_precall(...) [ldo.c:264] - по сути это самая важная часть LVM. <br />[20:34:09] &lt;Black_Phoenix&gt; luaD_precall(...) запихивает новый CallInfo на стек вызваных функций, сохраняет текущий PC, запоминает текущее состояние стека. <br />[20:34:31] &lt;Black_Phoenix&gt; (PC - указатель инструкций, здесь он прямо указывает на двоичные данные, где находиться следущая инструкция) <br />[20:34:55] &lt;Black_Phoenix&gt; Если функция - С-функция, то проверяем что на стеке есть минимум места (равный LUA_MINSTACK значений), и вызываем функцию. Поскольку эта лекция - только общий обзор внутренностей, то какие именно функции здесь используються останеться тайной (сам <br />[20:34:55] &lt;Black_Phoenix&gt; и посмотрите по [ldo.c:307]). <br />[20:34:58] &lt;Black_Phoenix&gt; сами* <br />[20:35:44] &lt;Black_Phoenix&gt; SIDE-NOTE: в Lua 5.1.4 есть глюк, который позволяет C-функции нарушить стек вернув слишком много результатов. Для этого есть патч на оффициальном сайте. <br />[20:35:57] &lt;Black_Phoenix&gt; Если же это функция Lua, то будет подготовлен вызов функции (и возможно будет вызов hook-функции, если такова была установлена). <br />[20:36:23] &lt;Black_Phoenix&gt; Если вы внимательно слушали (читали), то заметили что я сначала сказал что стек создаётся размером в 40 записей. Но ведь можно делать огромную рекурсию - как это происходит? <br />[20:36:53] &lt;Black_Phoenix&gt; На самом деле, если посмотреть на то, как ведёт себя стек, можно заметить, что при достижении 50% заполнености стека его размер будет увеличен на 200%, пока этого нельзя будет зделать, или пока количество рекурсивных вызовов не превысит некото <br />[20:36:53] &lt;Black_Phoenix&gt; рое значение. <br />[20:37:43] &lt;Black_Phoenix&gt; Изменение размера стека производиться функцией luaD_reallocstack(..) [ldo.c:141] - она вызываеться автоматически, но вообще её можно вызывать и самому. Освобождённое место будет возвращено програме. <br />[20:38:18] &lt;Black_Phoenix&gt; LVM будет прерывать рекурсивные вызовы если их слишком много, что-бы стек не вырос до коллосальных размеров. К тому же сам стек ограничиваеться максимальным размером (если не ошибаюсь MAX_SIZET байт, обычно это 65536 байт). <br />[20:39:02] &lt;Black_Phoenix&gt; Ваши С-функции вызываемые Lua могут падать. Если вы правильно вернёте код ошибки (не ноль), то она даже восстановит стек и выдаст пользователю сообщение. (И работа скрипта будет продолжена) <br />[20:39:42] &lt;Black_Phoenix&gt; Итак, теперь о самой LVM. LVM основана на очень простом интерпретаторе (в Lua 5.1.4 используеться просто пошаговое выполнение инструкций). Каждый шаг - одна инструкция. <br />[20:40:28] &lt;Black_Phoenix&gt; Выполнение будет продолжаться пока скрипт не напорёться на ошибку, либо пока не будет вызван &quot;return&quot;, либо пока установленый hook (если таковой есть) не закончиться с ошибкой. <br />[20:41:07] &lt;Black_Phoenix&gt; Таким образом прерывать выполнение скрипта можно только из самого скрипта, либо контролируя его выполнение хуком. <br />[20:42:03] &lt;Black_Phoenix&gt; Я точно не смог найти где (и вообще ли) ограничиваеться откуда будет браться байткод - могу точно сказать только то, что парсер всегда будет ставить RETURN как последнюю инструкцию в скрипте (и он будет прерван) <br />[20:42:33] &lt;Black_Phoenix&gt; Формат у опкодов такой (в скобках - сначала позиция в битах, потом размер в битах): [lopcodes.h:37] <a href="http://www.everfall.com/paste/id.php?ry0zq4z4v1vk">http://www.everfall.com/paste/id.php?ry0zq4z4v1vk</a> <br />[20:43:07] &lt;Black_Phoenix&gt; Опкод сам определяет, нужно ли брать B или Bx. Каждый параметр - 8-бит смещения (unsigned) на стеке относительно указателя стека base; 8ой бит параметров В и С указывает брать ли значение из регистра (памяти), или из константы. <br />[20:43:52] &lt;Black_Phoenix&gt; Если значение берёться из константы, то параметр - индекс в список констант текущей функции. В Lua достаточно замудрено с тем, как значение собственно получается, поэтому обяснять здесь не буду. <br />[20:45:22] &lt;Black_Phoenix&gt; В LVM есть 38 опкодов, полный список их можно достать здесь: <a href="http://www.everfall.com/paste/id.php?4xs8bzkw0fld">http://www.everfall.com/paste/id.php?4xs8bzkw0fld</a> ([lopcode.h:154]) <br />[20:46:02] &lt;Black_Phoenix&gt; В списке опкодов R(A) - это как-бы регистр №A, но реально это значение полученое по смещению A относительно указателя стека base. Как видите, хотя она называеться регистровой, она всё таки остаётся стековой VM. <br />[20:46:53] &lt;Black_Phoenix&gt; В общем дожно быть всё понятно по виртуальной машине. Почти все их опкодов понятны, возможно кроме некоторых <br />[20:48:24] &lt;Black_Phoenix&gt; Опкоды FORLOOP, FORPREP существуют для подготовки и выполнения цикла for (цикл while выполняеться через jmp). CLOSURE &quot;создаёт&quot; новую функцию. Это и другие опкоды в деталях будет рассмотрено позже, щас только общий экскурс <br />[20:48:59] &lt;Black_Phoenix&gt; Итак, теперь можно наконец поговорить о парсере Lua, а также о крутых штуках - например о глобальной таблице (точнее таблице глобальных переменных и функций). <br />[20:50:06] &lt;Black_Phoenix&gt; Сам парсер - рекурсивный, компилирует используя набор синтаксических правил ([lparser.c:1]) <br />[20:50:27] &lt;Black_Phoenix&gt; Таблица глобальных переменных - обычная таблица Луа которая в себе хранит все глобальные функции и переменные (всё что не помечено как local). Если обявляеться функция или переменная без ключевого слова local, то она будет занесена в эту таблиц <br />[20:50:27] &lt;Black_Phoenix&gt; у. <br />[20:50:31] &lt;Black_Phoenix&gt; таблицу* <br />[20:50:55] &lt;Black_Phoenix&gt; При вызове lua_newstate() будет создан новый локальный стейт, и новый глобальный стейт - а также новая таблица глобальных переменных. <br />[20:51:16] &lt;Black_Phoenix&gt; При вызове lua_newthread() таблице глобальных переменных нового стейта будет присвоена таблица из другого стейта (который передаётся в lua_newthread()). <br />[20:52:00] &lt;Black_Phoenix&gt; Это значит что при создании нового потока можно использовать уже существующие глобальные функции. При добавлении новых глобальных функций одним из скриптов она будет доступна и всем другим потокам. <br />[20:52:37] &lt;Black_Phoenix&gt; Причём она станет доступной прямо во время выполнения другого скрипта - можно создать систему сигналов основаную на этом. <br />[20:52:46] &lt;Black_Phoenix&gt; Кстати, в таблице глобальных переменных и функций кроеться небольшой, но существенный облом. <br />[20:53:03] &lt;Black_Phoenix&gt; Он кроеться в том, что парсер глобальные переменные добавляет в таблицу, как и положено (для этого есть специальный опкод). Скажем мы компилируем код &quot;gvar = 100; myvar = 200&quot;, при этом парсер запустит такой код: <br />[20:53:11] &lt;Black_Phoenix&gt;&nbsp; LOADK 00000000 00000ACF //Загрузка строки &quot;gvar&quot; <br />[20:53:17] &lt;Black_Phoenix&gt;&nbsp; SETGLOBAL 00000000 00000ACE //Засовываем в таблицу &quot;100&quot; с ключём &quot;gvar&quot; <br />[20:53:17] &lt;Black_Phoenix&gt;&nbsp; LOADK 00000000 00000AD1 //Загрузка строки &quot;myvar&quot; <br />[20:53:17] &lt;Black_Phoenix&gt;&nbsp; SETGLOBAL 00000000 00000AD0 //myvar = 200 <br />[20:53:17] &lt;Black_Phoenix&gt;&nbsp; RETURN 00000000 1 //завершение работы VM <br />[20:53:36] &lt;Black_Phoenix&gt; Так вот, а тепер обратимся к этим переменным (вызовем код &quot;print(gvar)&quot;): <br />[20:53:45] &lt;Black_Phoenix&gt;&nbsp; GETGLOBAL 00000000 00000BA4 //Получить переменную за ключём &quot;print&quot; <br />[20:53:45] &lt;Black_Phoenix&gt;&nbsp; GETGLOBAL 00000001 00000BA5 //Получить переменную за ключём &quot;gvar&quot; <br />[20:53:45] &lt;Black_Phoenix&gt;&nbsp; CALL 00000000 2 0 //Вызвать функцию, расположеную на base+0 в стеке (с 2 значениями на стеке, 0 значений полученых назад) <br />[20:53:45] &lt;Black_Phoenix&gt;&nbsp; RETURN 00000000 1 //завершаем работу VM <br />[20:54:13] &lt;Black_Phoenix&gt; Для сравнения запустим код &quot;local lvar = 100; print(lvar)&quot;: <br />[20:54:23] &lt;Black_Phoenix&gt;&nbsp; LOADK 00000000 00000BCD //Загрузка значения lvar <br />[20:54:23] &lt;Black_Phoenix&gt;&nbsp; GETGLOBAL 00000001 00000BCE //Загрузка &quot;print&quot; <br />[20:54:23] &lt;Black_Phoenix&gt;&nbsp; MOVE 00000002 00000000 //Просто переносим +0 в +2 (на стеке) <br />[20:54:23] &lt;Black_Phoenix&gt;&nbsp; CALL 00000001 2 0 //print... <br />[20:54:24] &lt;Black_Phoenix&gt;&nbsp; RETURN 00000000 1 //завершаем работу VM <br />[20:54:43] &lt;Black_Phoenix&gt; (LOADK это просто загрузка значения/константы) <br />[20:55:05] &lt;Black_Phoenix&gt; И здесь можно заметить облом - вызовы локальных переменных и функций обращаются к таблице значений, куда компилятор неким ему ведомомым образом позапихивал наши переменные. <br />[20:55:09] &lt;Black_Phoenix&gt; А вот вызов глобальной функции (или переменной) будет запрашивать у таблицы глобальных переменных её адрес - каждый раз при обращении. <br />[20:55:31] &lt;Black_Phoenix&gt; Желательно избегать глобальных функций, а особенно глобальных переменных - при росте их количества они будут всё более и более тормозить. <br />[20:56:21] &lt;Black_Phoenix&gt; Кстати, всегда при сравнении сравниваеться &quot;A &lt; B&quot;. Если написано &quot;A &gt; B&quot;, то парсер превратит это в сравнение &quot;B &lt; A&quot; <br />[20:56:46] &lt;Black_Phoenix&gt; Все стандартные библиотеки (table, string, io) - это просто таблицы с функциями. Обращение к ним вызывает GETGLOBAL для полчучения таблицы, и GETTABLE для получения значения из таблицы. <br />[20:56:57] &lt;Black_Phoenix&gt; Т.е. все библиотеки Lua создаються как просто добавление таблицы с функциями в глобальную таблицу. <br />[20:57:22] &lt;Black_Phoenix&gt; Для этого есть функция luaI_openlib [lauxlib.c:242]. Здесь будет проверено загружена ли эта библиотека (есть ли имя этой таблицы в таблице &quot;_LOADED&quot;), и затем создано таблицу с функциями. <br />[20:58:54] &lt;Black_Phoenix&gt; В завершение кратко о сборщике мусора - он постоянно чистит уже не используемые ресурсы, а также ресурсы оставленые/забытые на стеке <br />[20:59:51] &lt;Black_Phoenix&gt; Каждый обьект который может быть убран сборщиком помечаеться как чёрный, серый, или белый - что значит что сборщик должен убрать обьект, должен проверить надо ли его убирать, и что он вообще не должен этот обьект трогать <br />[21:00:55] &lt;Black_Phoenix&gt; Существует также очистка таблиц - поиск &quot;слабых&quot; элементов, но это уже детали сборщика мусора. <br />[21:01:45] &lt;Black_Phoenix&gt; В принципе это всё, теперь можно задавать вопросы (если _ShaMan_&nbsp; снимет +m). Желательно вопросы по LVM/Lua - на вопросы по AngelScript я отвечу в следущей лекции <br />[21:02:33] &lt;Black_Phoenix&gt; <a href="http://users.d2k5.com/Black%20Phoenix/files/luastack.png">http://users.d2k5.com/Black%20Phoenix/files/luastack.png</a> вот кстати картинка о которой я говорил <br />[21:03:07] &lt;Black_Phoenix&gt; top - указатель вершины стека, base - начало stack frame, stack + stack_end - просто для проверок выхода за границы</p> <p>Вопросы: <br />[21:03:22] &lt;gamer3d&gt; как расшифровываеться LOADK 00000000 00000ACF ? <br />[21:04:22] &lt;Black_Phoenix&gt; Загрузка на стек со смещением +0 относительно BASE. Значение для загрузки береться из списка констант за номером 0xACF (или немного другим номером, не суть) <br />[21:05:06] &lt;Black_Phoenix&gt; Я немного модифицировал VM что-бы она выводила запускаемый код, она неправильно выводит номера констант <br />[21:06:28] &lt;Black_Phoenix&gt; Есть ещё LOADNIL (загрузка nil, фактически удаление), и LOADBOOL. Кстати LOADNIL почти сразу удаляет значение, высвобождая память</p> <p>[21:08:24] &lt;gamer3d&gt; а отлаживать lua код как? <br />[21:09:31] &lt;Black_Phoenix&gt; Надо поставить hook, он будет вызываться перед каждой инструкцией. Дополнительный API в [ldebug.c] позволит находить номер строки, делать отладку построчно, смотреть весь стек удобным образом</p> <p>[21:10:57] &lt;DDMZ&gt; как правильно использовать коуротины? <br />[21:13:11] &lt;Black_Phoenix&gt; Должна быть библиотека &quot;coroutine&quot; в которой можно создать и работать с короутинами <br />[21:14:08] &lt;Black_Phoenix&gt; Надо вызвать coroutine.create(&lt;функция&gt;), что вернёт значение типа TTHREAD, с которым потом можно будет работать - есть функции coroutine.status, coroutine.resume, coroutine.yield <br />[21:15:27] &lt;Black_Phoenix&gt; Вообще коротуны тоже вызывают lua_newthread - они создают новый стейт (который кстати и есть тем, что прячеться за TTHREAD), и потом VM будет переключаться автоматически между ними (если не ошибаюсь) <br />[21:15:59] &lt;Black_Phoenix&gt; [lbaselib.c:490] - здесь сама имплементация библиотеки coroutines</p> <p>[21:17:14] &lt;gamer3d&gt; как делать save game/load game если в игре используется lua? <br />[21:17:45] &lt;Black_Phoenix&gt; gamer3d, детально об этом будет в следущей лекции, но по мне правильно выполнить такие шаги: <br />[21:18:12] &lt;Black_Phoenix&gt; 1) сохранить глобальную таблицу (возможно кроме таблиц библиотек) <br />[21:18:34] &lt;Black_Phoenix&gt; 2) если не хочеться возиться слежением за загружеными скриптами, сохранить весь байткод <br />[21:19:07] &lt;Black_Phoenix&gt; 3) сохранить lua_State и возможно global_State (интересует стек вызваных функций, и стек Lua) <br />[21:19:30] &lt;Black_Phoenix&gt; Это метод влоб - я бы предложил просто дать скриптам коллбек &quot;OnGameSave&quot; <br />[21:19:51] &lt;Black_Phoenix&gt; Пусть они сами вернут таблицу которую надо сохранить - ведь всё-таки можно и вернуть self :)</p> <p>[21:21:36] &lt;DDMZ&gt; как правильно загрузить скрипт в луастейт? <br />[21:22:51] &lt;Black_Phoenix&gt; DDMZ, luaL_loadbuffer или luaL_loadfile если хочешь прямо грузить <br />[21:23:07] &lt;Black_Phoenix&gt; dofile/dostring это тоже самое, но ещё вызывают lua_call <br />[21:24:03] &lt;DDMZ&gt; чтобы грузить из памяти luaL_loadbuffer , и в один луастейт мы можем загрузить один скрипт? а если больше, то их склеить вручную и потом загрузит</p><p><a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=4446&amp;page=2">Продолжение</a></p> http://www.gamedev.ru/community/gamedev_lecture/articles/?id=2921 Sun, 20 Apr 2008 16:47:05 GMT http://www.gamedev.ru/community/gamedev_lecture/articles/?id=2921 аппроксимация битстрим векторные данные сжатие сплайны <p><b>Полная форматированная версия лога лежит <a href="http://rageous.jino-net.ru/mydocs/Postgraduate/LectureCompression">здесь</a>.</b> <p>18:02:06&nbsp; Rageous: лекция, которую я сегодня читаю, посвящена моим исследованиям в области компрессии векторных данных <br />18:02:30&nbsp; Rageous: в связи с тем, что мне уже задавали вопросы, что есть векторные данные, я проясню этот вопрос отдельно <br />18:02:52&nbsp; Rageous: здесь и далее под векторными данными я буду подразумевать функции f(t), где t - время, а f(t) - функция, возвращающая некоторое рациональное значение <br />18:03:16&nbsp; Rageous: с подобными данными мы работаем каждый день: в играх это анимации персонажей, пути перемещения объектов, траектории движения физических тел <br />18:03:35&nbsp; Rageous: в софте это информация по трекингу машин автопарка, к примеру <br />18:03:58&nbsp; Rageous: здесь, к примеру, можно увидеть сохраненный путь автомобиля. сохраненные данные используются для анализа скорости, времени и количества остановок: <br /><img src="http://www.gamedev.ru/files/images/gps_tiny.png" alt="gps_tiny | Лекция #35. Компрессия векторных данных [Лектор - Rageous]" /> <br />18:04:21&nbsp; Rageous: здесь зеленоградский автопарк предоставил свои данные для анализа дорожной обстановки на одной из самых нагруженных московских трасс, чем облегчил жизнь множеству автомобилистов: <br /><img src="http://www.gamedev.ru/files/images/zelgps_tiny.png" alt="zelgps_tiny | Лекция #35. Компрессия векторных данных [Лектор - Rageous]" /> <br />18:04:47&nbsp; Rageous: итак, векторные данные полезны. часто бывает полезно их сохранять. к сожалению их объем нередко далек от &quot;незначительного&quot; <br />18:05:17&nbsp; Rageous: в связи с этим возникает вопрос об их компрессии <br />18:05:54&nbsp; Rageous: к примеру, если вы хотите сохранить реплей заезда в автосимуляторе, чтобы поделиться им с друзьями, вам придется думать о том, как переслать по интернету до десятка мегабайт данных <br />18:06:56&nbsp; Rageous: если же вы занимаетесь ПО и хотите хранить годами информацию по имеющимся в вашем распоражении автомобилям или морским судам или самолетам или еще чему - вы можете легко столкнуться с проблемой огромного объема этих сведений <br />18:07:19&nbsp; Rageous: к счастью существуют архиваторы :) <br />18:07:48&nbsp; Rageous: и к сожалению сжатие векторных данных - одно из самых низких для большинства современных алгоритмов <br />18:08:00&nbsp; Rageous: так, например, zip сжимает такие данные в 2-3 раза <br />18:08:17&nbsp; Rageous: rar и 7zip обеспечивают сжатие до 25 раз, но делают это весьма медленно <br />18:09:07&nbsp; Rageous: слабым местом архиваторов является то, что они предоставляют lossless (без потерь) компрессию, а так же не располагают сведениями о структуре предоставленных им данных <br />18:10:17&nbsp; Rageous: целью, которую я ставил перед собой, когда начинал заниматься компрессией векторных данных, было сжатие в 100-1000 раз при скорости достаточной, чтобы осуществлять это сжатие в реальном времени без серьезного удара по производительности основного приложения <br />18:10:34&nbsp; Rageous: итак, что я делал <br />18:11:17&nbsp; Rageous: первое - все данные были разбиты на отдельные потоки вида v(t), где v - это функция времени, возвращающая одно или несколько рациональных чисел <br />18:12:07&nbsp; Rageous: имеющиеся данные были слегка изменены, чтобы избавиться от избыточности: вместо полных матриц 4*4 трансормации я писал вектора и нормализованные (3 компоненты) кватернионы <br />18:12:48&nbsp; Rageous: потоки, объединяющие в себе несколько флоатов для одного момента времени пригодились для записи нормализованных кватернионов - уменьшив погрешность <br />18:13:27&nbsp; Rageous: второе - так как данные нужно было сжимать и сохранять в реальном времени, все данные были разбиты на пакеты фиксированной длины (обычно порядка 30-90 секунд) <br />18:14:09&nbsp; Rageous: в памяти одновременно находятся два пакета: текущий и прошлый. прошлый сжимается вместе с наполнением текущего, что позволяет избежать пиковых нагрузок при сохранении пакета в файл или иное хранилище <br />18:14:33&nbsp; Rageous: после сохранения сжатого пакета его место, соот-но, занимает текущий, а текущий начинает наполняться новыми данными <br />18:16:08&nbsp; Rageous: третье - данные в библиотеку приходят очень часто. в играх - раз в кадр. в софте - при каждом замере. в большинстве ситуаций это означает избыточность данных, т.к. объект, который движется почти прямолинейно, создает такой же объем сведений, как и объект, который бешенно меняет свою позицию и ориентацию <br />18:16:19&nbsp; Rageous: чтобы избавиться от этой избыточности нужно провести аппроксимацию <br />18:16:54&nbsp; Rageous: наиболее частым и простым подходом в данной ситуации является аппроксимация кусочно-линейным сплайном <br />18:17:01&nbsp; Rageous: или, проще говоря, ломаной <br />18:17:31&nbsp; Rageous: фиттинг (вычисление минимального набора необходимых ключей) для такого сплайна осуществляется очень просто и быстро <br />18:18:03&nbsp; Rageous: но результат оставляет желать лучшего как с т.з. компрессии, так и с т.з. внешнего вида полученных после обработки данных <br />18:18:15&nbsp; Rageous: машина начинает двигаться &quot;угловато&quot; <br />18:18:49&nbsp; Rageous: вторым подходом является фиттинг сплайнов более высокого порядка - квадратичных и кубических сплайнов <br />18:19:25&nbsp; Rageous: сразу скажу, несмотря на интуитивно-большую гибкость кубических, я остановился на квадратичных <br />18:19:46&nbsp; Rageous: это связано с тем, что фиттинг кубических сплайнов - весьма сложный процесс, который требует тонкой настройки <br />18:20:02&nbsp; Rageous: в противном случае на сплайне появляются выбросы, которые сводят на нет все преимущества <br />18:20:10&nbsp; Rageous: либо же компрессия становится чрезвычайно низкой <br />18:20:41&nbsp; Rageous: неплохая статья с исходниками по кубическим сплайнам находится здесь: <a href="http://alglib.sources.ru/interpolation/spline3.php">http://alglib.sources.ru/interpolation/spline3.php</a> <br />18:21:00&nbsp; Rageous: про фиттинг можно почитать здесь: <a href="http://www.stanford.edu/~boyd/cvx/examples/cvxbook/Ch06_approx_fitting/html/fig6_20.html">http://www.stanford.edu/~boyd/cvx/examples/cvxbook/Ch06_approx_fi&hellip; /fig6_20.html</a> и здесь: <a href="http://ask.metafilter.com/50554/Generating-Bezier-curves-from-discrete-point-sets">http://ask.metafilter.com/50554/Generating-Bezier-curves-from-dis&hellip; te-point-sets</a> <br />18:21:22&nbsp; Rageous: что же квадратичный сплайн. я взял сплайн безье: <a href="http://ru.wikipedia.org/wiki/Кривая_Безье" rel="nofollow">http://ru.wikipedia.org/wiki/Кривая_Безье</a> <br />18:21:54&nbsp; Rageous: он имеет очень простую формулу, которая легко обращается, дабы вычислить опорную точку по имеющимся точкам начала и конца, а так же некоторой промежуточной <br />18:22:05&nbsp; Rageous: потому его фиттинг легко объяснить на пальцах: <br />18:22:24&nbsp; Rageous: мы берем весь пакет данных, вычисляем для него усредненную опорную точку <br />18:22:55&nbsp; Rageous: с ней прогоняем функцию оценки ошибки. если ошибка слишком велика, делим данные пополам - и проводим ту же процедуру с первой половиной <br />18:23:37&nbsp; Rageous: так - до тех пор, пока не найдем кусок данных максимальной длины, который можно представить в виде начальной, конечной точек и опорного значения (P1 в формулах на вики) <br />18:24:09&nbsp; Rageous: с оставшимися данными процесс повторяется до тех пор, пока весь пакет не будет представлен в виде наборов квадратичных сплайнов</p><p><a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=2921&amp;page=2">Продолжение</a></p> http://www.gamedev.ru/community/gamedev_lecture/blog/?id=2915 Mon, 14 Apr 2008 23:39:51 GMT http://www.gamedev.ru/community/gamedev_lecture/blog/?id=2915 http://www.gamedev.ru/community/gamedev_lecture/forum/?id=79405 irc Ogre3D лекция <p>19.04.08 в 18:00 МСК на канале #Ogre3D состоится лекция по компрессии векторных данных. Лектор - <a href="http://dtf.ru/person/info.php?id=4654">Rageous</a>.</p> <p>Огромная просьба ко всем, кто собирается присутствовать: прислать в личку (на сайте или в ирке) свои ФИО и место работы/учебы. Это нужно для отчетности по кандидатской работе. Заранее спасибо!</p> http://www.gamedev.ru/community/gamedev_lecture/articles/?id=2800 Mon, 07 Jan 2008 11:40:11 GMT http://www.gamedev.ru/community/gamedev_lecture/articles/?id=2800 http://www.gamedev.ru/community/gamedev_lecture/forum/?id=75108 бред деньги игра концепт отстой <p>Если вы хотите написать самую отстойную игру, разбогатеть и прославиться, то эта лекция для вас. <br />В лекции раскрываются некоторые тайны известных разработчиков игр. <p>&lt;DDMZ&gt; Для начала нужно выбрать правильную операционную систему. <br />&lt;DDMZ&gt; Лучше всего выбрать операционную систему DOS поскольку она с трудом работает под виндовсом. Либо накрайний случай выбрать сам виндовс <br />&lt;DDMZ&gt; Следущим шагом должен стать выбор языка програмирования, приэтом неважно какой язык програмирования вы уже знаете. Чем хуже знаком вам выбраный язык програмирования тем отстойнее получится игра <br />&lt;DDMZ&gt; Лидер среди языков програмирования BASIC, поскольку даже если вам этот язык програмирования знаком игра всеравно получится отстойной <br />&lt;DDMZ&gt; далее нужно представить себе как будет выглядеть игра, придумать концепт. <br />&lt;Dorfe[notebook]&gt; танк с сиськами + табуретки?.. <br />&lt;DDMZ&gt; Что угодно ... <br />&lt;DDMZ&gt; Исходя от того что вы там задумали, внешний вид, и т.п. вам нужно полностью отказатся от графического режима, таким образом вам непотребуется тратить свои сылы на рисование графики <br />&lt;DDMZ&gt; в качестве устройства вывода звука лучше всего подходит PCSpeaker посокльку это устройство стандартное и у вашей игры будет большая совместимость. И ещё один существенный плюс вам ненужно замарачиватся со всякими там хитросплетениями работы звуковых карт <br />&lt;DDMZ&gt; На этом шаге уже можно представлять себя рокфелером гребущим лопатой деньги. поскольку создаваемую таким образом игру нужно продавать например как шаровары, ведь даже такие скудные труды должны окупатся, а люди с чувством юмора и при деньгах ещё неперевелись. неужно незабыть навешать всяческой защиты и кучу прозьб о регистрации, которые будут закрывать основной игровой процесс чтобы у игрока сложилось впечатление о том что: <br />&lt;DDMZ&gt; игра действительно стоящая, хоть сам игровой процесс и невидно из-за прозьб о регистрации <br />&lt;Dorfe[notebook]&gt; ых, этим кстати и занимаемся =) вешаем рекламу в игры <br />&lt;DDMZ&gt; следующий шаг это взять ранее придуманый концепт, опсание и начать програмировать. Незабыв гденить предупредить общественность о том что разрабатывается некая игра под строгой секретностью, дабы заинтересовать больше игроков к моменту выхода игры <br />&lt;DDMZ&gt; При програмировании небрезговать использовать кучу опереатаров print и go to <br />&lt;DDMZ&gt; пока игра находитсмя в разработке, можно подливать интерес к игре ожидающих игроков, выкладыванием на формуах всяких красочных концептов и скриншотов <br />&lt;DDMZ&gt; приэтом откуда сделаны скриншоты неособо важно... <br />&lt;DDMZ&gt; чем на дольший срок затянется разработка тем больше игроков заинтересуется вашей игрой к моменту выхода <br />&lt;DDMZ&gt; а если вы ещё и несколько раз перенесёте дату выхода, то это будет просто кассовый сбор, поскольку пресса будет пестрить о том что какаято секретная игра которую все ждут переносится. Игроки уже будут грезить супер спец эффектами этой игры <br />&lt;DDMZ&gt; когда вы уже будите заканчивать игру, нивкоем случае неделайте демо версию, поскольку в демке нет прозьб о регистрации которые закрывают собой полностью игровой процесс, и игроки увидят насколько ваша игра отстойна... <br />&lt;DDMZ&gt; в итоге у вас должно получится что то типа тетриса или крестиков ноликов, ибо это проще всего спрограмировать, накрайняк должна получится игра угадай число которое задумал копьютер... <br />&lt;DDMZ&gt; вот таким образом можно создать самую отстойную игру и приэтом заработать кучу денег. <br />&lt;DDMZ&gt; Игра будет признана просто величайшим отстоем с момента игровой индустрии! <br />&lt;DDMZ&gt; люди будут хотеть купить эту игру и посмотреть насколько она интересна/отстойна <br />&lt;DDMZ&gt; Выйдет куча журналов, где будет говорится только о вашей игре и насколько она отстойна <br />&lt;DDMZ&gt; везде будет упоминатся ваше имя! такчто вы ещё и прославитеь =) <br />&lt;DDMZ&gt; лекция окончена, если есть вопросы отвечу</p> <p>Полный лог лекции здесь: <a href="http://www.everfall.com/paste/id.php?023e2v1b5ynw">http://www.everfall.com/paste/id.php?023e2v1b5ynw</a></p> http://www.gamedev.ru/community/gamedev_lecture/articles/?id=2526 Sun, 29 Jul 2007 09:25:00 GMT http://www.gamedev.ru/community/gamedev_lecture/articles/?id=2526 http://www.gamedev.ru/community/gamedev_lecture/forum/?id=68422 <p>Из лога вырезан мусор, некоторые места подправлены. Полный лог: <a href="http://www.everfall.com/paste/id.php?phy8s5l4zxe8">http://www.everfall.com/paste/id.php?phy8s5l4zxe8</a></p> <p>&lt;Denton&gt; Итак. сегодня я расскажу о том, чтоже такое projective grid <br />&lt;Denton&gt; и о том, как и где можно её использовать. <p>&lt;Denton&gt; данный способ был использован для реализации водной поверхности <br />&lt;Denton&gt; Projective grid, на русский язык переводится как проективная сетка, это сетка которая получается в результате проецирования вершин сетки с экраных координат в 3д пространство <br />&lt;Denton&gt; Основная идея проективной сетки заключается в достижении максимальной теселяции при приближении к виртуальной камере и уменьшении при удалении вершин от виртуальной камеры <br />&lt;Denton&gt; Для чего же можно её применить... <br />&lt;Denton&gt; В следствии того что сетка около камеры получается высокой плотности( количество вершин на квадратную единицу 3д пространства высокое), а с удалением от горизонта сетка становится более разреженная,&nbsp; её удобно использовать для рендеринга сетки меша, используемого для рендеринга водной поверхности <br />&lt;Denton&gt; Мной использовался данный способ лишь для рендеринга водной поверхности, но также предполагается, что возможно будет использовать&nbsp; данный способ и для рендеринга слоя облаков для открытых пространств <br />&lt;Denton&gt; Если данная лекция пройдёт успешно, и реализация слоя облаков удасться, по этому поводу будет ещё одна лекция <br />&lt;Denton&gt; хочется также сказать что данный способ был реализован в других играх жанра стратегии <br />&lt;Denton&gt; в частности не так давно вышедшей Supreme Commander <br />&lt;Denton&gt; но там она с некоторыми доработками</p> <p>&lt;Denton&gt; Далее будет рассказано о том, как получить проективную&nbsp; сетку и как можно её использовать для рендеринга поверхности воды <br />&lt;Denton&gt; В начале напомню как происходит рендеринг воды в принципе <br />&lt;Denton&gt; а) Создаётся плоскоская сетка <br />&lt;Denton&gt; б) С использованием шумовой функции создаётся карта высот и в соответствие с ней сдвигаются вершины <br />&lt;Denton&gt; немного не точно выразился. Не с шумовой функцией, а с волновой. <br />&lt;Denton&gt; Спасибо washth <br />&lt;Denton&gt; в) Полученная геометрия выводится на экран <br />&lt;Denton&gt; с применением различных заранее подготовленных, либо отсчитаных в рендертаргет текстур и шейдеров <br />&lt;Denton&gt; В обычном случае сетка лежит в плоскости разбивается на треугольники, чем ближе к камере – тем мельче треугольники.</p> <p>&lt;Denton&gt; Возможны применения различных способов тесселяции <br />&lt;Denton&gt; но в любом случае это делается вручную при изменении определённых параметров <br />&lt;Denton&gt; Для создания карты высот используются какие либо волновые функции,&nbsp; например шум Перлина <br />&lt;Denton&gt; Используется несколько октав, каждая из которых делает карту шума более мелкой и в итоге карты шумов всех октав сумируются</p> <p>&lt;Denton&gt; На этом рисунке <a href="http://img444.imageshack.us/img444/3627/58435634rk6.jpg">http://img444.imageshack.us/img444/3627/58435634rk6.jpg</a> обозначены: <br />&lt;Denton&gt; Sbase - плоскость в которой расположена сетка <br />&lt;Denton&gt; Supper – верхний предел смещений вершин согласно карте высот <br />&lt;Denton&gt; Slower – нижний предел смещения вершин согласно карте высот <br />&lt;Denton&gt; Nbase – нормаль к плоскости Sbase <br />&lt;Denton&gt; Vdisplaceble - объём в котором будут смещатся вершины <br />&lt;Denton&gt; Тут <a href="http://img444.imageshack.us/img444/3671/64592334sq0.jpg">http://img444.imageshack.us/img444/3671/64592334sq0.jpg</a>&nbsp; отображено как смещаются вершины согласно карты шума</p> <p>&lt;Denton&gt; это всё было известно и ранее. ничего нового тут нет. вопросы есть по этому? <br />&lt;paladinrus&gt; где происходит смещение? <br />&lt;paladinrus&gt; ведь не у всех есть геометрические шейдеры <br />&lt;paladinrus&gt; тогда программно? <br />&lt;Denton&gt; можно и на CPU их смещать <br />&lt;Black_Phoenix&gt; Есть вопрос <br />&lt;NULL_PTR&gt; вершины смещай в вертексном шейдере</p> <p>&lt;paladinrus&gt; и ещё <br />&lt;paladinrus&gt; может я ошибаюсь но при дифферд шейдинге можно смещать в пиксельном шейдере? <br />&lt;Denton&gt; в пиксельном шейдере смещать вершины нельзя <br />&lt;Denton&gt; при дифер шейдинге в пиксельном происходил расчёт освещения <br />&lt;Denton&gt; а в текстурах были координаты вершин <br />&lt;paladinrus&gt; ну <br />&lt;paladinrus&gt; и что нам мешает поменять координаты <br />&lt;Denton&gt; можно и менять <br />&lt;Denton&gt; тогда для задания вершин в сетке необходимо использовать r2vb <br />&lt;Denton&gt; т.е. данные с текстуры использоваться как координаты вершин. <br />&lt;Denton&gt; а при деффер шейдинге, насколько мне известно мы зная координаты вершин получали текстуру <br />&lt;paladinrus&gt; ну я это и имел ввиду, ок, вопросов нет</p> <p>&lt;Denton&gt; тогда&nbsp; поехали дальше <br />&lt;Denton&gt; Принцип построения проективной сетки для меша поверхности воды, состоит из следующих этапов <br />&lt;Denton&gt; а) создание плоскости расположенной перпендикулярно вектору направления взгляда виртуальной камеры <br />&lt;Denton&gt; б) проектирование угловых вершин полученой плоскости на плоскость Sbase <br />&lt;Denton&gt; проектирование в данном случае - с учётом матрицы проектора. в нашем случае - виртуальной камеры <br />&lt;Denton&gt; в) смещение вершин в соответствии с картой высот. <br />&lt;Denton&gt; г) вывод полученого меша на экран. <br />&lt;Denton&gt; также у меня дальше будут использоваться следующие обозначения: <br />&lt;Denton&gt; Vcam – объём занимаемый конусом камеры <br />&lt;Denton&gt; Vvisible – пересечение объёмов Vcam и Vdisplaceable <br />&lt;Denton&gt; также считаем что нормали к Supper и Slower равны <br />&lt;Denton&gt; и равны также нормали к Sbase <br />&lt;Denton&gt; Vcam - объём создаваемый ближней плоскостью отсечения, дальней, и гранями фрустума <br />&lt;Denton&gt; те части объёма Vdisplaceable которые попадаёт в Vcam и есть Vvisible <br />&lt;Denton&gt; Если сравнивать как и что должно получиться, то удобнее всего взять настольную лампу и тонкую прозрачную бумагу <br />&lt;Denton&gt; нарисовать на ней ручкой равномерную сетку, и закрыть этой бумагой конус настольной лампы <br />&lt;Denton&gt; После включения лампы можно будет увидеть что спроецированные нарисованные точки на бумаге, на стол уже не будут равномерно удалены друг от друга <br />&lt;Denton&gt; По мере их отдаления от лампы, они будут находится на более дальнем расстоянии друг от друга <br />&lt;Denton&gt; Примерно это будет выглядеть так: <br />&lt;Denton&gt; <a href="http://img528.imageshack.us/img528/9441/77454362vf8.jpg">http://img528.imageshack.us/img528/9441/77454362vf8.jpg</a></p> <p>&lt;Denton&gt; Как же создаётся плоскость расположенная перпендикулярно вектору направления взгляда виртуальной камеры… <br />&lt;Denton&gt; Для начала необходимо найти точки пересечения Vdisplaceable с конусом видимости камеры, с frustum’ом <br />&lt;Denton&gt; Полученые координаты будут находится в modelview matrix в пространстве виртуальной камеры. <br />&lt;Denton&gt; как находить пересечения я думаю не стоит объяснять. <br />&lt;Denton&gt; Далее для построения плоскости которая была бы параллельна вектору направления взгляда камеры, необходимо получить экранные координаты вершин <br />&lt;Denton&gt; Далее необходимо найти минимальный и максимальные координаты вершин на экране <br />&lt;Denton&gt; т.е. берётся каждая вершина и находится минимальный X, максимальный X среди них. И аналогично с Y <br />&lt;Denton&gt; С учётом этих значений строится матрица проектора, с помощью которой и будут найдены точки в мировой системе координат <br />&lt;Denton&gt; Матрица строится так: <a href="http://www.everfall.com/paste/id.php?y7hw8s2se8sl">http://www.everfall.com/paste/id.php?y7hw8s2se8sl</a> <br />&lt;Denton&gt; Теперь умножая на эту матрицу вершины (0,0) (1,0) (0,1) (1,1) можно получить 4 вершины трапеции, которая будет лежать в плоскости Sbase <br />&lt;Denton&gt; следует сказать, что полученные координаты будут гомогенными. иными словами 4д вектора <br />&lt;Denton&gt; Далее между данными вершинами строится сетка по тривиальному алгоритму – стороны трапеции делятся на равные участки и строится сетка. <br />&lt;Denton&gt; тут в принципе есть одна особенность <br />&lt;Denton&gt; при расчёте координат сетки используются гомогенные координаты. <br />&lt;Denton&gt; т.е. для расчёта ширины между двумя строками, берётся Yдальнее - Yближнее в гомогенных координатах <br />&lt;Denton&gt; это нужно для того, чтобы сетка была равномерной на экране виртуальной камеры <br />&lt;Denton&gt; а при переводе в декартовую системы координат получится что сетка рястягивается с увеличением расстояния от камеры <br />&lt;Denton&gt; После этих действий со стороны наблюдателя сетка будет иметь вид: <a href="http://img207.imageshack.us/img207/1530/23414408qp1.jpg">http://img207.imageshack.us/img207/1530/23414408qp1.jpg</a> <br />&lt;Denton&gt; а с вида камеры сетка будет абсолютно равномерна. <br />&lt;Denton&gt; что это даёт... <br />&lt;Denton&gt; если камера направлена в сторону горизонта, и у нас размер сетки 128х128, то большая часть вершин сетки будет около камеры что обеспечит хорошую детальность перед камерой. <br />&lt;Denton&gt; и если опустить камеру &quot;под ноги&quot;, получим те же самые 128х128 вершин <br />&lt;Denton&gt; но использоваться они будут для более малой площади поверхности. <br />&lt;Denton&gt; т.е. фактически все вершины используются только для видимой части поверхности <br />&lt;Denton&gt; и совсем не важно - огромный у нас океан или маленькая лужа. количество вершин на водную поверхность не нужно делать сильно большим. <br />&lt;Denton&gt; так же есть некоторые особенности в реализации. <br />&lt;Denton&gt; в частности при нахождения матрица проектора. <br />&lt;Denton&gt; если смотреть в небо, то может получится так называемый эффект back firing <br />&lt;Denton&gt; когда у нас сетка будет отрисовываться с обратной стороны камеры. <br />&lt;Denton&gt; для борьбы с этим создаётся дополнительная виртуальная камера <br />&lt;Denton&gt; которая используется для перевода найденых вершин пересечения Vcam и Vdisplaceable <br />&lt;Denton&gt; в экранные координаты <br />&lt;Denton&gt; для получения экранных координат вершин</p><p><a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=2526&amp;page=2">Продолжение</a></p> http://www.gamedev.ru/community/gamedev_lecture/articles/game_orhetecture Thu, 14 Jun 2007 21:20:10 GMT http://www.gamedev.ru/community/gamedev_lecture/articles/game_orhetecture http://www.gamedev.ru/community/gamedev_lecture/forum/?id=67296 <p>Disclaimer: из лога вырезаны куски, ну и так далее. <a href="http://www.everfall.com/paste/id.php?nwwkchotfkn0">полный лог</a></p> <p>[21:00] &lt;dDIMA&gt; Всем доброго getlocaltime();</p> <p>[21:00] &lt;dDIMA&gt; Тема сегодняшней лекции - &quot;Плюсы и минусы игровых &lt;орхетектур&gt;&quot;. <br />[21:01] &lt;dDIMA&gt; Я постараюсь кратко рассказать про основные решения, которые приходится принимать на верхнем уровне разработки игрового проекта, какие здесь бывают варианты реализации, чем они плохи и хороши. <br />[21:01] &lt;dDIMA&gt; Предварительно одно небольшое предупреждение&nbsp; я, разумеется, буду приводить разные примеры из жизни&nbsp; с какими интересными вещами мне приходилось встречаться, но ссылок на конкретные компании и конкретные игровые движки приводить не буду. <br />[21:01] &lt;dDIMA&gt; И на вопросы &lt;у кого именно встретилось такое г.&gt; отвечать тоже, естественно, не буду :) <br />[21:01] &lt;dDIMA&gt; Ни на канале, ни в привате.</p> <p>[21:01] &lt;dDIMA&gt; Сразу &lt;с места в карьер&gt; - первый ключевой вопрос&nbsp; это каким образом ведется разделение кода на столь модное понятие &lt;движок&gt; и &lt;игра&gt;. <br />[21:02] &lt;dDIMA&gt; Можно явно выделить 2 крайних подхода, ну и соответственно, множество промежуточных вариантов. <br />[21:02] &lt;dDIMA&gt; <a href="http://www.ddima.ru/articles/v_lecture1/engine_game.jpg">http://www.ddima.ru/articles/v_lecture1/engine_game.jpg</a> (<a href="http://www.gamedev.ru/files/images/?id=48038">http://www.gamedev.ru/files/images/?id=48038</a>) <br />[21:03] &lt;dDIMA&gt; Левая картинка иллюстрирует подход, при котором игровой движок и сама игра не разделаются по сущностям. <br />[21:03] &lt;dDIMA&gt; Мы начинаем разработку игры (ширина трапеций символизирует объем кода, по оси Y вниз идет время) под названием Project 1. <br />[21:03] &lt;dDIMA&gt; Когда игра сделана и (дай бог) выпущена, мы на основе всего имеющегося кода делаем второй проект (естественно, схожего жанра). <br />[21:03] &lt;dDIMA&gt; К середине разработки второго проекта мы сильно разрослись и решаем запустить третий проект. <br />[21:03] &lt;dDIMA&gt; Для этого мы копируем полное содержимое Project 2 в Project 3 и продолжаем разработку. <br />[21:03] &lt;dDIMA&gt; Незадолго до окончания второго проекта начинаются работы по четвертому проекту, а третий проект бренчуется в Project 5. <br />[21:04] &lt;dDIMA&gt; Правая картинка иллюстрирует подход с организацией отдельного независимого движка (это центральный ствол &lt;дерева&gt;), на котором &lt;висят&gt; отдельные ветки Project1 ... Project5. <br />[21:04] &lt;dDIMA&gt; Мы тщательно следим за тем, чтобы главный ствол рос и развивался, <br />[21:04] &lt;dDIMA&gt; и чтобы в него не попадали разные паразитные части, которые Project specific <br />[21:04] &lt;dDIMA&gt; и которые в будущем могут не позволить нам нормально развивать движок для других нужд. <br />[21:05] &lt;dDIMA&gt; Естественно, что в случае достаточно мощного и полного движка не все его части будут использованы. <br />[21:05] &lt;dDIMA&gt; Это символизируют дополнительные линии, отсекающие части главного ствола для нужд того или иного проекта.</p> <p>[21:05] &lt;dDIMA&gt; Каковы плюсы и минусы указанных решений?</p> <p>[21:05] &lt;dDIMA&gt; Вариант слева выглядит достаточно простым и удобным для реализации <br />[21:05] &lt;dDIMA&gt; к тому же позволяет использовать максимум имеющегося кода в новых проектах. <br />[21:05] &lt;dDIMA&gt; Однако он не лишен существенных недостатков. <br />[21:06] &lt;dDIMA&gt; Ключевая проблема в организации такого способа работы&nbsp; это тесное переплетение разных &lt;системных&gt; и &lt;игровых&gt; подсистем в один чудовищный клубок. <br />[21:06] &lt;dDIMA&gt; Причем чем дальше&nbsp; тем сильнее этот клубок завязывается. <br />[21:06] &lt;dDIMA&gt; Я видел примеры игровых движков, в которых базовая система анимации персонажей имела режимы анимации Male, Female и MegoBoss <br />[21:06] &lt;dDIMA&gt; причем логика применения анимационных секвенций зависела от этого флага! <br />[21:06] &lt;dDIMA&gt; Второй нюанс&nbsp; тупое выделение полного проекта в новый бренч обязательно должно сопровождаться рефактором и удалением старых более не нужных объектов <br />[21:07] &lt;dDIMA&gt; В противном случае объем неиспользуемого в проекте &lt;мусора&gt; будет сильно возрастать и может достигать цифр в 20-40% общего объема кода <br />[21:07] &lt;dDIMA&gt; А это и лишние перекомпиляции и усложненная навигация, и общая потеря понимания, что происходит в проекте <br />[21:08] &lt;dDIMA&gt; Третий аспект - переплетение системного и игрового кода приводит к тому, что общая разработка библиотеки для нескольких одновременно идущих проектов становится крайне сложной задачей <br />[21:08] &lt;dDIMA&gt; На левом рисунке есть пересечение по времени между Project 4, 5 и 3, но совместная разработка какой-нибудь новой компоненты (например, сетевой игры) потребует достаточно долгой и мучительной вставки требуемого кода в исходники <br />[21:08] &lt;dDIMA&gt; (проверено на собственном опыте) <br />[21:08] &lt;dDIMA&gt; Потому что весь код представляет из себя большой &lt;клубок&gt;, <br />[21:08] &lt;dDIMA&gt; и вам потребуется править несколько сотен файлов по дюжине строк, чтобы оно все взлетело <br />[21:09] &lt;dDIMA&gt; Фактически это приводит к тому, что компания остается &lt;компанией одного проекта&gt;, так как... <br />[21:09] &lt;dDIMA&gt; на приведенном рисунке активный код продолжает использоваться только в линии Project 1 - 2 - 3 - 5, причем не самым оптимальным способом :( <br />[21:09] &lt;dDIMA&gt; Когда объемы данных начинают конфликтовать с заложенными в движок ограничениями, наступает коллапс <br />[21:09] &lt;dDIMA&gt; Вы более не можете создавать игры, основываясь на такой технологии, <br />[21:09] &lt;dDIMA&gt; вам надо будет бросать имеющуюся разработку и фактически начинать делать новый движок с нуля <br />[21:10] &lt;dDIMA&gt; Цикл развития компании по такой схеме составляет 5-8 лет, после чего технология распадается <br />[21:10] &lt;dDIMA&gt; Картинка справа выглядит посимпатичнее - в ней имеется четко выделенный ствол, который растет и развивается <br />[21:10] &lt;dDIMA&gt; Если главный движок качественно написан и состоит из достаточно независимых модулей, то вы можете разрабатывать новые компоненты движка, причем одновременно для всех текущих проектов <br />[21:10] &lt;dDIMA&gt; Минусы данного подхода заключаются в том, <br />[21:10] &lt;dDIMA&gt; что для создания такой структуры проекта требуется крайне высокая квалификация программистов, <br />[21:11] &lt;dDIMA&gt; а также наличие отдельных людей, которые разрабатывают и модернизируют движок, не привязываясь к нуждам отдельно взятых проектов <br />[21:11] &lt;dDIMA&gt; Ибо как только в движок пролезает game specific код, начинаются проблемы у всех остальных команд <br />[21:11] &lt;dDIMA&gt; Крайне важно обеспечивать единость движка для всех проектов <br />[21:11] &lt;dDIMA&gt; Как только вы для собственного удобства делаете отдельные бренчи системного движка для отдельных игр, вы мгновенно переползаете в вариант разработки, представленный на левой картинке, со всеми вытекающими последствиями <br />[21:12] &lt;dDIMA&gt; Также из минусов подхода отмечу, что универсальность практически всегда означает определенную потерю перформанса <br />[21:12] &lt;dDIMA&gt; Делая универсальное решение вы теряете возможность сэкономить на каких-то game-specific моментах и, естественно, решение оказывается не самым высокопроизводительным <br />[21:12] &lt;dDIMA&gt; Цикл развития компании по такой схеме составляет 10-15 лет. <br />[21:12] &lt;dDIMA&gt; Технология либо обновляется в течение этого времени, <br />[21:12] &lt;dDIMA&gt; либо распадается в том случае, если заложенные архитектурные ограничения оказываются непреодолимыми на новом железе, платформе и т. п. <br />[21:13] &lt;dDIMA&gt; Цифры чисто практические на текущем железе, с ростом next-next-генов время может сокращаться <br />[21:13] &lt;dDIMA&gt; Естественно, в чистом виде оба подхода встречаются редко. <br />[21:14] &lt;dDIMA&gt; Большинство компаний стремится иметь выделенный системный код, но при этом &lt;не гнушаются&gt; возможностью скопировать чего-нибудь побольше из проекта в проект <br />[21:14] &lt;dDIMA&gt; Что касается начинающих разработчиков, то я, конечно же, ратую за второй подход, но скорее всего, первые ваши 2-3 пилотных проекта не смогут выдержать строгую схему движок-игра <br />[21:14] &lt;dDIMA&gt; Первый вариант разработки можно применять только при условии внимательного анализа, а что же на самом деле в проекте является универсальным, а что&nbsp; специфичным для игры <br />[21:15] &lt;dDIMA&gt; Такой анализ должен сопровождаться постоянным рефактором (хотя о его вреде я еще скажу ниже) <br />[21:15] &lt;dDIMA&gt; и стремлением выделить &lt;на будущее&gt; универсальный системный и игровой код <br />[21:15] &lt;dDIMA&gt; Так, <br />[21:16] &lt;dDIMA&gt; Первый вопрос я кратко осветил :) <br />[21:16] &lt;dDIMA&gt; теперь плавно переходим ко второму пункту лекции, <br />[21:16] &lt;dDIMA&gt; если есть вопросы по первой части, готов выслушать.</p> <p>[21:16] &lt;Zeux&gt; Правая картинка про движок для одной платформы? <br />[21:16] &lt;dDIMA&gt; Может быть для одной, может для нескольких <br />[21:16] &lt;dDIMA&gt; Для нескольких надо стараться, чтобы &quot;ветки&quot; дерева были максимально независимыми от платформ</p> <p>[21:16] &lt;cppg&gt; Разделение движок-игра - это только разделение на шаред/специфик код? <br />[21:17] &lt;dDIMA&gt; гуру, недопонял. Поясни вопрос, плз <br />[21:17] &lt;cppg&gt; Ну, вопрос, что ты называешь движком и что игрой? <br />[21:17] &lt;dDIMA&gt; движком - что-то общее, что можно выделить :) <br />[21:18] &lt;cppg&gt; Ага <br />[21:18] &lt;_ShaMan_&gt; я обычно придерживаюсь разделение по подсистемам <br />[21:18] &lt;Cunter&gt; Движок - графа, звук, управление, сеть, физика, аи, скрипт? <br />[21:18] &lt;_ShaMan_&gt; графический, игровой и т.д. <br />[21:21] &lt;dDIMA&gt; графика, звук (кроме процедурных примочек), управление, скрипты - это движок <br />[21:21] &lt;dDIMA&gt; Физика - часть безусловно системная, но очень много игровой специфики <br />[21:21] &lt;dDIMA&gt; да, забыл упомянуть, middleware тоже фактически представляет собой ствол <br />[21:22] &lt;dDIMA&gt; Причем за счет многолетней обкатанности - очень хороший ствол :)</p> <p>[21:17] &lt;Darth&gt; Вариант с готовым движком? Тут по идее и туда и туда тоже может уйти. <br />[21:17] &lt;dDIMA&gt; конечно <br />[21:18] &lt;dDIMA&gt; Darth: особенно хорошо он туда уходит, если поставляется без сорсов <br />[21:19] &lt;dDIMA&gt; Darth: Были примеры, когда народ правил системный код, а потом оригинальная игра начинала падать в единственном месте <br />[21:19] &lt;dDIMA&gt; (обнаружили через несколько месяцев)</p> <p>[21:18] &lt;_Winnie&gt; Интересно, если проекта три, и у любых двух есть пересечение, а у трёх вместе - нет... <br />[21:19] &lt;dDIMA&gt; Я специально на правом рисунке выделил, что необязательно все проекты юзают весь функционал движка <br />[21:20] &lt;dDIMA&gt; Т.е. если мы делаем сингплеер, нафиг нам сеть? ;) <br />[21:20] &lt;dDIMA&gt; А функционал - с ним посложнее будет :)</p> <p>[21:20] &lt;_ShaMan_&gt; ну я так понимаю что во втором подходе игра как бы собирается из кирпичиков? <br />[21:21] &lt;_ShaMan_&gt; т.е. берётся общая кодобаза и на ней строится игра <br />[21:22] &lt;dDIMA&gt; _ShaMan_: фактически да, из кирпичиков <br />[21:22] &lt;dDIMA&gt; То есть вариант 1 - это реконструкция имеющегося дома <br />[21:23] &lt;dDIMA&gt; вариант 2 - это сборка нового дома из блоков</p> <p>[21:21] &lt;Cunter&gt; Модульность позволит движку даже с ростом технологий держаться на плаву? <br />[21:23] &lt;dDIMA&gt; модульность позволяет держаться на плаву, и при необходимости менять отдельные &quot;тяжелые&quot; модули (если повезет)</p> <p>[21:24] &lt;dDIMA&gt; Я еще на 1 вопрос из привата отвечу <br />[21:24] &lt;dDIMA&gt; &gt; Какой примерно процент успешных созданий живучего движка для нескольких игр одной компании? <br />[21:24] &lt;dDIMA&gt; Не все компании работают по второму варианту <br />[21:24] &lt;dDIMA&gt; Хотя многие пробуют создать свою технологию <br />[21:25] &lt;dDIMA&gt; Успешных - так сходу могу прикинуть примерно треть <br />[21:25] &lt;dDIMA&gt; Есть компании, которые вполне успешно работают по первому варианту</p> <p>[21:26] &lt;dDIMA&gt; продолжаем <br />[21:26] &lt;dDIMA&gt; Теперь про DG <br />[21:26] &lt;dDIMA&gt; С точки зрения организации взаимодействия объектов в игровом мире можно выделить 2 основные схемы работы: <br />[21:27] &lt;dDIMA&gt; 1. Если кому-то из объектов требуется обновление, он вызывает другой объект с запросом на Update() <br />[21:27] &lt;dDIMA&gt; 2. Система знает о порядке вызова объектов и сама вызывает им Update в требуемом порядке <br />[21:27] &lt;dDIMA&gt; Оба варианта проиллюстрированы на следующем рисунке <br />[21:27] &lt;dDIMA&gt; <a href="http://www.ddima.ru/articles/v_lecture1/dep_graph.jpg">http://www.ddima.ru/articles/v_lecture1/dep_graph.jpg</a> (<a href="http://www.gamedev.ru/files/images/?id=48037">http://www.gamedev.ru/files/images/?id=48037</a>) <br />[21:28] &lt;dDIMA&gt; Вариант 1 более подробно <br />[21:28] &lt;dDIMA&gt; World перед тем, как обновляться, вызывает Player.Update(), SkyBox.Update() и BackGroundSound.Update() <br />[21:28] &lt;dDIMA&gt; Игрок из себя вызывает WeaponMng.Update() и Camera.Update() <br />[21:28] &lt;dDIMA&gt; Аналогично послупают и все остальные объекты в сцене <br />[21:28] &lt;dDIMA&gt; Чтобы предотвратить рекурсивные вызовы, обычно делается темплейтный или базовый класс-переходник, в котором записывается счетчик кадров <br />[21:29] &lt;dDIMA&gt; Если на текущем кадре еще не было обновления объекта, то он будет обновляться, в противном случае ничего делаться не будет <br />[21:29] &lt;dDIMA&gt; <a href="http://www.everfall.com/paste/id.php?rhk0dppm9tth">http://www.everfall.com/paste/id.php?rhk0dppm9tth</a> <br />[21:29] &lt;dDIMA&gt; Вариант 2 более подробно <br />[21:30] &lt;dDIMA&gt; Существует некоторый базовый класс (условно назовем его GameObject) с виртуальным методом virtual void Update()=0 <br />[21:30] &lt;dDIMA&gt; Все перечисленные объекты наследуются от данного класса, переопределяют Update() и каким то образом сообщают в Update Manager, что объекты существуют, причем между ними есть такие-то зависимости <br />[21:30] &lt;dDIMA&gt; Update Manager на каждом фрейме вызывает обновление указанных объектов <br />[21:31] &lt;dDIMA&gt; Подход №1 прост и удобен для реализации <br />[21:31] &lt;dDIMA&gt; Все связи между объектами видны прямо в коде, отладка проста и эффективна <br />[21:31] &lt;dDIMA&gt; Однако этот вариант приводит к сильной связанности компонент приложения <br />[21:31] &lt;dDIMA&gt; Фактически он (если применяется в чистом виде) форсирует нас на создание не движка+игра, а большой кучи малы <br />[21:31] &lt;dDIMA&gt; см. еще раз на <a href="http://www.ddima.ru/articles/v_lecture1/engine_game.jpg">http://www.ddima.ru/articles/v_lecture1/engine_game.jpg</a>, рисунок слева <br />[21:32] &lt;dDIMA&gt; Этот вариант также является более произволительным <br />[21:32] &lt;dDIMA&gt; так как если что-то не потребовалось апдейтить на текущем фрейме, то оно и не будет вызвано :) <br />[21:32] &lt;dDIMA&gt; Второй вариант более удобен для слабого связывания компонент игры и движка, но сложен как для реализации, так и для отладки <br />[21:32] &lt;dDIMA&gt; Нам требуется каким-то образом задавать порядок вызова объектов <br />[21:32] &lt;dDIMA&gt; и по шагам программу пройти очень и очень сложно <br />[21:32] &lt;dDIMA&gt; Тут вылезают наружу все тонкости событийно-управляемой системы и отладки таких приложений <br />[21:33] &lt;dDIMA&gt; На практике первая схема используется часто, а вот вторая в чистом виде используется крайне редко <br />[21:33] &lt;dDIMA&gt; Как правило, разработчики ищут компромисс с использованием событийной схемы, <br />[21:33] &lt;dDIMA&gt; а внутренности крупных сущностей самостоятельно вызывают внутренние апдейты для своих &lt;детей&gt; <br />[21:34] &lt;dDIMA&gt; То есть например Player является GameObject'ом, а вот внутри него ручками вызывается обновление Inventory, Camera, WeaponMng и т.п. <br />[21:34] &lt;dDIMA&gt; SoundManager является GameObject'ом, а вот внутри него он сам напрямую вызывает BGSound, обновляет 3D источники и т.п. <br />[21:35] &lt;dDIMA&gt; Короткий комментарий по вопросам <br />[21:35] &lt;dDIMA&gt; приведенный пейст сделан для варианта, что Update() вызывается именно 1 раз на фрейм <br />[21:35] &lt;dDIMA&gt; Это как раз позволяет всем нахально вызывать DoUpdate() столько, сколько хочется <br />[21:35] &lt;dDIMA&gt; а реальный Update() придет только 1 раз <br />[21:36] &lt;dDIMA&gt; Если почему-то захотелось вызвать Update() дважды, можно сделать метод типа Invalidate() <br />[21:36] &lt;dDIMA&gt; Но будьте аккуратны - легко можно провалиться в бесконечную рекурсию :) <br />[21:36] &lt;dDIMA&gt; Возвращаясь ко второму моменту: <br />[21:36] &lt;dDIMA&gt; *второму варианту <br />[21:37] &lt;dDIMA&gt; Во второй схеме существенный нюанс - это порядок вызовов объектов <br />[21:37] &lt;dDIMA&gt; Его надо сохранять в правильном порядке, ибо если камера обновится раньше игрока, мы получим на экране отставание на фрейм с неприятными дрожаниями и прочими эффектами <br />[21:37] &lt;dDIMA&gt; Вариантов сортировки подписчиков Update() есть довольно много <br />[21:38] &lt;dDIMA&gt; самые популярные - это разные магические цифры, определяющие порядок <br />[21:38] &lt;dDIMA&gt; или задание зависимостей между классами <br />[21:38] &lt;dDIMA&gt; Как правило цифры удобны в комбинированной схеме, когда подписчиков Update() немного, а внутренние Update вызываются ручками <br />[21:39] &lt;dDIMA&gt; Там можно даже не городить огород с DoUpdate() - риск свалится в рекурсию минимальный <br />[21:39] &lt;dDIMA&gt; Также я еще рассмотрю подробнее организацию GameObject в виде единственного класса или группы классов <br />[21:39] &lt;dDIMA&gt; Недостатком общего единого GameObject является то, что он будет к концу разработки сильно перегружен различными методами <br />[21:39] &lt;dDIMA&gt; Основываясь на опыте работы с такими движками, можно прогнозировать цифру в 100-300 методов <br />[21:40] &lt;dDIMA&gt; Поэтому часто разбивают базовую сущность GameObject на несколько <br />[21:40] &lt;dDIMA&gt; Например что-то в таком роде: GameSystemObject, GameObject, SpriteObject и т.п. <br />[21:40] &lt;dDIMA&gt; Это позволяет как-то разнести интерфейсы и (тоже заодно) отсортировать порядки вызова <br />[21:40] &lt;dDIMA&gt; Но схема не лишена недостатков, ключевой из которых - жесткая фиксация различных типов объектов <br />[21:41] &lt;dDIMA&gt; То есть если появится какая-нибудь динамическая лава, которая взаимодействует с игроком, хитро светит на environment и т.п., ей может не найтись места среди заготовленных базовых классов <br />[21:41] &lt;dDIMA&gt; Как вы организуете иерархию объектов - ваше личное право <br />[21:41] &lt;dDIMA&gt; Можете сделать Hero public MoveableObject public GameObject public Object <br />[21:41] &lt;dDIMA&gt; Можете сделать 1 уровень интерфейса <br />[21:42] &lt;dDIMA&gt; Лично мне больше нравится более простая с точки зрения иерархии схема, как я писал ранее в ЖЖ, сильно хочется, чтобы компиляторы выдавали синтаксическую ошибку в том случае, если глубина наследования больше 3-4 :) <br />[21:42] &lt;dDIMA&gt; Мне сильнее импонирует схема наследования, когда в качестве базовых выступают не логически-игровые Game, Moveable, Sprite и прочие Objects, <br />[21:43] &lt;dDIMA&gt; а очевидные с точки зрения действия объекты Update, Render и т.п. <br />[21:43] &lt;dDIMA&gt; В данной схеме игровой цикл разворачивается в вызов обсерверов в некотором упорядоченном порядке, а конкретные объекты имплементируют те интерфейсы, которые им самим актуально требуются <br />[21:43] &lt;dDIMA&gt; Как водится, на практике часто применяется комбинированный вариант - с универсальными GameObject + дополнительные имплементации <br />[21:43] &lt;dDIMA&gt; Более подробно я займусь разделеняими на иерархии объектов чуть позже. <br />[21:44] &lt;dDIMA&gt; Сейчас небольшое лирическое отступление с красивыми картинками :) <br />[21:44] &lt;dDIMA&gt; Но еще раньше - давайте сделаем небольшой перерыв, даже перекур? <br />[21:44] &lt;dDIMA&gt; Пока что есть текущие вопросы?</p> <p>[21:44] &lt;Zeux&gt; Что является ключевым в первой схеме и что во второй? <br />[21:44] &lt;Zeux&gt; т.е. первая схема - это про то, что явный immediate вызов <br />[21:45] &lt;dDIMA&gt; ага <br />[21:45] &lt;dDIMA&gt; И как следствие - сильная связанность компонент <br />[21:45] &lt;Zeux&gt; точнее про то, что явный вызов или про то, что мгновенный? <br />[21:45] &lt;Zeux&gt; аналогично, вторая схема - про то, что есть один большой граф? <br />[21:45] &lt;Zeux&gt; или про что-то еще <br />[21:45] &lt;dDIMA&gt; Ну мгновенный и связанный - вещи одного плана <br />[21:46] &lt;dDIMA&gt; Я уже говорил, что за универсальность приходится платить <br />[21:46] &lt;dDIMA&gt; второй вариант более универсален, но соответственно, и тормознутее</p><p><a href="http://www.gamedev.ru/community/gamedev_lecture/articles/game_orhetecture?page=2">Продолжение</a></p> http://www.gamedev.ru/community/gamedev_lecture/articles/?id=2431 Wed, 23 May 2007 21:34:09 GMT http://www.gamedev.ru/community/gamedev_lecture/articles/?id=2431 http://www.gamedev.ru/community/gamedev_lecture/forum/?id=70277 <p>&lt;Zeux&gt; типичное RMGUI приложение <br />&lt;Zeux&gt; имеет четко определенные стадии. <br />&lt;Zeux&gt; 1. инициализация контролов <br />&lt;Zeux&gt; она производится по-разному <br />&lt;Zeux&gt; либо в коде добавляются контролы <br />&lt;Zeux&gt; либо они описываются в xml файле <br />&lt;Zeux&gt; либо еще как <br />&lt;Zeux&gt; 2. обновление и синхронизация <br />&lt;Zeux&gt; тут на самом деле 3 под-пункта <br />&lt;Zeux&gt; а. запихнуть изменившиеся данные приложения в контролы <br />&lt;Zeux&gt; (labels для текста, значения слайдеров, поменявшиеся по каким-то причинам, etc.) <br />&lt;Zeux&gt; b. вызвать какую-то мега-функцию GUI <br />&lt;Zeux&gt; которая отрендерит контролы и обновит состояние <br />&lt;Zeux&gt; обработает ввод, etc. <br />&lt;Zeux&gt; c. запихнуть изменившиеся данные контролов в приложения <br />&lt;Zeux&gt; 3. деинициализация контролов <br />&lt;Zeux&gt; замечу <br />&lt;Zeux&gt; что 3. часто делают автоматически <br />&lt;Zeux&gt; умными указателями <br />&lt;Zeux&gt; 2.a. в некоторых случаях делают полуавтоматически <br />&lt;Zeux&gt; например, передавая при создании слайдера в него - указатель на данные <br />&lt;Zeux&gt; но тут варианты очень ограничены <br />&lt;Zeux&gt; 2.c часто делают в 2.b <br />&lt;Zeux&gt; вызывая колбеки <br />&lt;Zeux&gt; тем не менее <br />&lt;Zeux&gt; все эти стадии есть</p> <p>&lt;MiF&gt; интересно минимально сформулированное отличие имгуя от рмгуя <br />&lt;Zeux&gt; сейчас попробую <br />&lt;Zeux&gt; хотя оно немного разное у всех :)</p> <p>&lt;Zeux&gt; так вот <br />&lt;Zeux&gt; IMGUI предлагает совсем другой подход <br />&lt;Zeux&gt; замечу <br />&lt;Zeux&gt; что в RMGUI основных проблем - 2 <br />&lt;Zeux&gt; первая - информация о контролах разнесена <br />&lt;Zeux&gt; потому что 1. их нужно создавать/удалять, 2. ими нужно управлять <br />&lt;Zeux&gt; часто для упрощения управления даже делают id <br />&lt;Zeux&gt; т.е. CreateButton(ID_BUTTON1, params) <br />&lt;Zeux&gt; а потом оперируют с ID_BUTTON1 <br />&lt;Zeux&gt; так сделано в DXUT <br />&lt;Zeux&gt; но в любом случае у вас в одном месте - информация о контролах, в другом - о том, как ей управлять <br />&lt;Zeux&gt; это - не хорошо и не плохо <br />&lt;Zeux&gt; разделение этой информации в некоторых случаях - очень во благо <br />&lt;Zeux&gt; например, когда над ней И ТАК работают разные люди <br />&lt;Zeux&gt; тогда у них ВСЕ РАВНО есть некоторый synchronization point <br />&lt;Zeux&gt; (дизайнер и программист договариваются, &quot;ты назовешь этот слайдер Exposure&quot; <br />&lt;Zeux&gt; etc.) <br />&lt;Zeux&gt; и наконец вторая проблема <br />&lt;Zeux&gt; контролы в подавляющем большинстве содержат информацию в себе <br />&lt;Zeux&gt; в слайдере - есть float value <br />&lt;Zeux&gt; в чекбоксе - bool checked <br />&lt;Zeux&gt; в листбоксе - int selected_item, float scrollbar_position <br />&lt;Zeux&gt; и проблема заключается в том <br />&lt;Zeux&gt; что у вашего приложения стейты - совсем не такие <br />&lt;Zeux&gt; у вас есть enum HDRType <br />&lt;Zeux&gt; он где-то там хранится <br />&lt;Zeux&gt; конечно, не в листбоксе! <br />&lt;Zeux&gt; т.е. часть состояния дублируется <br />&lt;Zeux&gt; например, float scrollbar_position может быть и не дублируется. А может быть и дублируется - смотря что вам нужно сохранять при выходе из приложения или даже при закрытии/открытии окон <br />&lt;Zeux&gt; именно эти 2 проблемы и называются - Retained Mode <br />&lt;Zeux&gt; у вас 1. есть объекты (которые надо создавать/удалять/управлять), 2. в них хранится состояние <br />&lt;Zeux&gt; грубо говоря, чтобы не рисовать контрол - надо сделать ему setVisible(false). <br />&lt;Zeux&gt; IMGUI нацелен в основном на решение второй проблемы. <br />&lt;Zeux&gt; т.е. основное отличие IMGUI <br />&lt;Zeux&gt; это - стейты контролов, не относящиеся к внутренней информации GUI - иначе говоря, стейты контролов, которыми приложение может хотеть управлять - управляются приложением <br />&lt;Zeux&gt; хранятся приложением <br />&lt;Zeux&gt; а не GUI. <br />&lt;Zeux&gt; также IMGUI пытается решать первую проблему <br />&lt;Zeux&gt; пытается - потому что есть разные IMGUI, и не всегда ее целесообразно решать, <br />&lt;Zeux&gt; Итак, маленький пример. <br />&lt;Zeux&gt; пусть у вас есть кнопка <br />&lt;Zeux&gt; и вы хотите, чтобы при нажатии на нее - приложение закрывалось. <br />&lt;Zeux&gt; типичные способы сделать это в RMGUI. <br />&lt;Zeux&gt; 1. <br />&lt;Zeux&gt; где-то в начале приложения: scoped_ptr&lt;Button&gt; button; где-то в инициализации: button.reset(new Button(data)); <br />&lt;Zeux&gt; button-&gt;setOnClick(&MyFunc); <br />&lt;Zeux&gt; dialog-&gt;add(button) <br />&lt;Zeux&gt; где-то в главном цикле: <br />&lt;Zeux&gt; dialog-&gt;update(); <br />&lt;Zeux&gt; где-то еще: <br />&lt;Zeux&gt; void MyFunc() { exit(); } <br />&lt;Zeux&gt; 2. <br />&lt;Zeux&gt; где-то в инициализации: <br />&lt;Zeux&gt; dialog.Load(&quot;dialog.xml&quot;); <br />&lt;Zeux&gt; в dialog.xml: <br />&lt;Zeux&gt; &lt;dialog&gt;&lt;button id=&quot;Exit&quot; caption=&quot;Good bye!&quot; width=120 height=60 /&gt;&lt;/dialog&gt; <br />&lt;Zeux&gt; в инициализации еще: <br />&lt;Zeux&gt; dialog-&gt;setCallbackById(&quot;Exit&quot;, MyFunc); <br />&lt;Zeux&gt; MyFunc аналогична <br />&lt;Zeux&gt; 3. где-то в инициализации <br />&lt;Zeux&gt; dialog-&gt;addButton(EXIT_BUTTON_ID, data); <br />&lt;Zeux&gt; (выше где-то const unsigned int EXIT_BUTTON_ID = 1;) <br />&lt;Zeux&gt; dialog-&gt;registerCallbackFunc(MyFunc); <br />&lt;Zeux&gt; где-то в главном цикле <br />&lt;Zeux&gt; dialog-&gt;update(); <br />&lt;Zeux&gt; где-то еще <br />&lt;Zeux&gt; void MyFunc(unsigned int id) { switch (id) { case EXIT_BUTTON_ID: exit(); break; } } <br />&lt;Zeux&gt; типичные способы сделать это в IMGUI: <br />&lt;Zeux&gt; 1. в главном цикле: if (button(EXIT_BUTTON_ID, data)) { exit(); } <br />&lt;Zeux&gt; 2. в главном цикле: if (button(GenerateUniqueIDSomehow(), data)) { exit(); } <br />&lt;Zeux&gt; 3. в dialog.xml то, что выше <br />&lt;Zeux&gt; в инициализации dialog.Load(&quot;dialog.xml&quot;); <br />&lt;Zeux&gt; в главном цикле if (dialog.button(&quot;Exit&quot;)) { exit(); } <br />&lt;Zeux&gt; я пока ни слова не сказал про применимость, это потом <br />&lt;Zeux&gt; в целом - отличия понятны?</p> <p>&lt;Denton&gt; да <br />&lt;Denton&gt; указывается не кудато а сразу делается то что надо. и работа идёт с данными приложения <br />&lt;Zeux&gt; да</p> <p>&lt;Zeux&gt; собственно <br />&lt;Zeux&gt; очевидно - IMGUI - далеко не silver bullet <br />&lt;Zeux&gt; как и RMGUI <br />&lt;Zeux&gt; более того! <br />&lt;Zeux&gt; очевидно, что вообще IM vs RM - мягко говоря не ограничено GUI <br />&lt;Zeux&gt; в OpenGL есть immediate mode <br />&lt;Zeux&gt; glBegin(); отдать OpenGL СВОИ ДАННЫЕ; glEnd(); <br />&lt;Zeux&gt; при этом - эти данные можно менять как угодно <br />&lt;Zeux&gt; если бы OpenGL в них писал - можно было бы свободно из них читать <br />&lt;Zeux&gt; есть и retained mode <br />&lt;Zeux&gt; glBufferData(ваши данные) <br />&lt;Zeux&gt; а потом glBindBuffer <br />&lt;Zeux&gt; чтобы изменить ваши данные <br />&lt;Zeux&gt; или прочесть их (если бы OpenGL их менял - или в случае с текстурами, ЕСЛИ он их поменял) <br />&lt;Zeux&gt; надо это сделать отдельно. <br />&lt;Zeux&gt; ну и в дополнение <br />&lt;Zeux&gt; в начале надо сделать glGenTextures <br />&lt;Zeux&gt; в конце - glDeleteTextures <br />&lt;Zeux&gt; надеюсь, я переврал меньше половины названий ф-ий. <br />&lt;Zeux&gt; очевидно, что в данном конкретном случае - IM проще <br />&lt;Zeux&gt; очевидно также <br />&lt;Zeux&gt; что в случае статических данных <br />&lt;Zeux&gt; и в случае OpenGL <br />&lt;Zeux&gt; второй подход будет быстрее <br />&lt;Zeux&gt; по очевидным причинам. <br />&lt;Zeux&gt; т.е. очевидно, что в разных ситуациях разные подходы применимы или не применимы в разной степени <br />&lt;Zeux&gt; итак <br />&lt;Zeux&gt; плюсы IMGUI - как я их вижу. <br />&lt;Zeux&gt; - простые вещи делаются просто, потому что вы пишете ТУПОЙ, ПРЯМОЛИНЕЙНЫЙ код. <br />&lt;Zeux&gt; потому что когда вам надо написать &quot;закрыть при нажатии&quot; - вы пишете if (button(...)) { закрыть } <br />&lt;Zeux&gt; когда вам надо сделать слайдер <br />&lt;Zeux&gt; с текстом под ним <br />&lt;Zeux&gt; который двигается со слайдером <br />&lt;Zeux&gt; и в котором меняется текст <br />&lt;Zeux&gt; вы пишете ровно это <br />&lt;Zeux&gt; float value = slider(data); <br />&lt;Zeux&gt; text(slider_pos.x + value * slider_width, slider_pos.y + someconstant, &quot;Value: &quot; + tostring(value), font_align_center); <br />&lt;Zeux&gt; вместо: <br />&lt;Zeux&gt; 1. создания отдельного коллбека для слайдера <br />&lt;Zeux&gt; 2. в нем поиска лейбла по ID <br />&lt;Zeux&gt; 3. в нем установки позиции и текста <br />&lt;Zeux&gt; если у вас есть пара editbox + slider, которые контролирует одно значение, то у вас не возникает проблем с синхронизацией. <br />&lt;Zeux&gt; из очевидных соображений. <br />&lt;Zeux&gt; потому что - НЕТ никакой синхронизации <br />&lt;Zeux&gt; она есть, когда данные представлены в нескольких местах <br />&lt;Zeux&gt; а здесь все данные - у вас. <br />&lt;Zeux&gt; - сложные вещи ИНОГДА делаются не сложнее, чем сама вещь <br />&lt;Zeux&gt; по тем же самым причинам <br />&lt;Zeux&gt; - не только код, использующий GUI, но и код самого GUI - прост, туп, прямолинеен. Это очень хорошо <br />&lt;Zeux&gt; потому что типично требования к GUI библиотеке меняются <br />&lt;Zeux&gt; - разделять функциональность не сложнее, чем в любом другом случае <br />&lt;Zeux&gt; это такой же код в конце концов <br />&lt;Zeux&gt; разделять - в смысле share</p><p><a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=2431&amp;page=2">Продолжение</a></p> http://www.gamedev.ru/community/gamedev_lecture/articles/r_e_n_de_r Wed, 09 May 2007 21:10:32 GMT http://www.gamedev.ru/community/gamedev_lecture/articles/r_e_n_de_r GSC render reverse engineering S.T.A.L.K.E.R. <p>Disclaimer: некоторые реплики убраны, посты - передвинуты, опечатки - исправлены. <a href="http://www.everfall.com/paste/id.php?y2a69dc2y3y8">полный лог</a></p> <p>[19:59] &lt;Zeux&gt; Давайте начинать. <br />[19:59] &lt;Zeux&gt; Привет всем, спасибо, что пришли послушать. <br />[20:00] &lt;Zeux&gt; Сначала <b>вкратце о лекции и правилах проведения</b> <br />[20:00] &lt;Zeux&gt; Лекция о том, как сделан рендер в игре STALKER <br />[20:00] &lt;Zeux&gt; Лекция будет преимущественно проходить в +m режиме <br />[20:00] &lt;Zeux&gt; т.е. говорить могу только я <br />[20:00] &lt;Zeux&gt; и несознательные слушатели <br />[20:00] &lt;Zeux&gt; которые являются опами <br />[20:00] &lt;Zeux&gt; будут делаться перерывы на вопросы <br />[20:01] &lt;Zeux&gt; наверное, 2-3 <br />[20:01] &lt;Zeux&gt; если у вас возникают вопросы по ходу лекции - пишите мне в приват. <br />[20:01] &lt;Zeux&gt; Логи лекции будут доступны <br />[20:02] &lt;Zeux&gt; наверное, через час после окончания <br />[20:02] &lt;Zeux&gt; так что если надо будет через пол часа куда-то срочно бежать - особо не переживайте, вы сможете прочитать то, что пропустили :) <br />[20:02] &lt;Zeux&gt; Теперь таки начнем.</p> <p>[20:03] &lt;Zeux&gt; Эта лекция является своеобразным продолжением лекции про рендер в Обливионе (была примерно год назад). В начале той лекции я рассказывал, почему реверс игр возможен <br />[20:03] &lt;Zeux&gt; И рассказывал, как можно прореверсить большинство игр <br />[20:03] &lt;Zeux&gt; Повторяться я не буду. <br />[20:03] &lt;Zeux&gt; При анализе рендера Сталкера я использовал все тот же NV PerfHUD <br />[20:03] &lt;Zeux&gt; который доблестные разработчики все так же (как в Обливионе) забыли отключить в финале <br />[20:04] &lt;Zeux&gt; Так же были два полезных источника <br />[20:04] &lt;Zeux&gt; Один - исходники шейдеров Сталкера <br />[20:04] &lt;Zeux&gt; которые вынимаются из архивов с помощью утилиты <br />[20:04] &lt;Zeux&gt; STALKER Data Unpacker <br />[20:04] &lt;Zeux&gt; лежит где-то на ag.ru :) <br />[20:05] &lt;Zeux&gt; Второй - статья Олеся (программист графики Сталкера) в GPU Gems 2 <br />[20:05] &lt;Zeux&gt; статья помогла значительно меньше (хотя и решила несколько вопросов), без исходников шейдеров - лекция появилась бы значительно позже <br />[20:05] &lt;Zeux&gt; и была бы менее подробной.</p> <p>[20:05] &lt;Zeux&gt; Ну и напоследок, перед тем как начать основную часть <br />[20:06] &lt;Zeux&gt; В сталкере есть несколько режимов рендеринга <br />[20:06] &lt;Zeux&gt; 3, если быть точным <br />[20:06] &lt;Zeux&gt; Я буду рассматривать только самый совершенный <br />[20:06] &lt;Zeux&gt; который использует Deferred Shading <br />[20:06] &lt;Zeux&gt; Поехали.</p> <p>[20:06] &lt;Zeux&gt; В Сталкере используется <b>технология Deferred Shading</b> <br />[20:07] &lt;Zeux&gt; Я чуть-чуть расскажу о ней <br />[20:07] &lt;Zeux&gt; чтобы людям, с ней не знакомым, было проще. <br />[20:07] &lt;Zeux&gt; Основная идеология &quot;обычного&quot; (forward) рендеринга - для каждого меша <br />[20:07] &lt;Zeux&gt; послать его на отрисовку, и в шейдерах (вершинном и пиксельном) выполнить освещение <br />[20:08] &lt;Zeux&gt; Когда у вас появляются несколько источников - возникают несколько вариантов решения проблемы &quot;как осветить меш не 1 источником, а 4&quot; <br />[20:08] &lt;Zeux&gt; В Doom 3 проблема решена так - каждый меш рисуется столько раз, сколько на него влияет источников (на самом деле, вроде немного больше). <br />[20:08] &lt;Zeux&gt; Очевидно, с этим подходом возникают проблемы - увеличивается сложность трансформации геометрии <br />[20:08] &lt;Zeux&gt; (особенно в случае &quot;тяжелых&quot; вершинных шейдеров - скелетная анимация) <br />[20:09] &lt;Zeux&gt; Возрастает нагрузка на CPU <br />[20:09] &lt;Zeux&gt; из-за увеличенного количества вызовов API <br />[20:09] &lt;Zeux&gt; В Oblivion проблема решена чуть более хорошо, но все равно на каждый меш может приходиться до 4 кажется вызовов отрисовки <br />[20:09] &lt;Zeux&gt; что не очень здорово. <br />[20:09] &lt;Zeux&gt; Очевидно, если вам нужно осветить сцену большим количеством источников (50? 100?) <br />[20:10] &lt;Zeux&gt; то про подобные подходы сразу можно забыть. <br />[20:10] &lt;Zeux&gt; И еще одна проблема - проблема overdraw. Когда вы рисуете меш, и в пиксельном шейдере производите сложные вычисления, то не факт, что получившийся пиксель в итоге <br />[20:10] &lt;Zeux&gt; (после отрисовки всей сцены) <br />[20:10] &lt;Zeux&gt; будет виден на экране <br />[20:11] &lt;Zeux&gt; Это решают сортировкой по расстоянию, дополнительным проходом, заполняющим глубину, и прочим <br />[20:11] &lt;Zeux&gt; Deferred Shading предлагает другое решение обоих проблем <br />[20:11] &lt;Zeux&gt; Рендеринг разбивается на 2 стадии. 1 - заполнение т.н. G-buffer <br />[20:11] &lt;Zeux&gt; G-buffer - это одна или несколько полноэкранных текстур <br />[20:11] &lt;Zeux&gt; (размером с экран) <br />[20:12] &lt;Zeux&gt; содержащих всю информацию, которая нужна для того <br />[20:12] &lt;Zeux&gt; чтобы осветить сцену источником света, положить на нее тени <br />[20:12] &lt;Zeux&gt; и т.д. <br />[20:12] &lt;Zeux&gt; Например, очевидно, что если у вас есть в каждом пикселе его позиция в скажем world space <br />[20:12] &lt;Zeux&gt; его нормаль <br />[20:13] &lt;Zeux&gt; и diffuse color, взятый из диффузной текстуры <br />[20:13] &lt;Zeux&gt; то этой информации достаточно, чтобы в каждом пикселе посчитать освещенность по модели скажем Фонга <br />[20:13] &lt;Zeux&gt; Посчитать, находится ли он в тени (если используются Shadow maps, например) <br />[20:13] &lt;Zeux&gt; и т.д.</p> <p>[20:14] &lt;Zeux&gt; Поэтому в первой стадии вся сцена рендерится в G-buffer <br />[20:14] &lt;Zeux&gt; здесь происходит заполнение текстур позицией, нормалью, и прочим <br />[20:14] &lt;Zeux&gt; потом для каждого источника на экран рисуется примитив (для простоты - full screen quad) <br />[20:14] &lt;Zeux&gt; с хитрым пискельным шейдером <br />[20:15] &lt;Zeux&gt; пиксельный шейдер читает информацию из G-buffer (позицию, нормаль, diffuse цвет, etc.) <br />[20:15] &lt;Zeux&gt; и производит вычисление освещенности для данного источника <br />[20:15] &lt;Zeux&gt; Если отрендерить 100 квадов с разными параметрами источника с аддитивным блендом <br />[20:16] &lt;Zeux&gt; получится суммарная освещенность сцены от 100 источников. <br />[20:16] &lt;Zeux&gt; Замечу, что при этом геометрическая стоимость - практически нулевая <br />[20:16] &lt;Zeux&gt; (трансформировать 4 вершины на каждый источник) <br />[20:16] &lt;Zeux&gt; Количество вызовов - по 1 на каждый источник <br />[20:16] &lt;Zeux&gt; Однако, pixel cost - все еще большой <br />[20:17] &lt;Zeux&gt; Главная проблема - если в forward renderer вы можете балансировать нагрузку между VS и PS <br />[20:17] &lt;Zeux&gt; вынося часть вычислений освещенности в VS <br />[20:17] &lt;Zeux&gt; то здесь вам приходится делать все в PS <br />[20:17] &lt;Zeux&gt; с одной стороны - проблема, с другой - освещение юниформное - т.е. везде попиксельное :) <br />[20:18] &lt;Zeux&gt; Общее введение в DS на этом я завершу. Я не рассчитываю, что тем, кто не знает, что такое DS, стало все понятно - это не цель лекции - по DS есть набор статей и tutorial-ов <br />[20:18] &lt;Zeux&gt; Но надеюсь, что кто-то что-то понял. Сейчас я буду рассказывать, как DS реализован в сталкере - что-то станет более понятно (надеюсь): )</p> <p>[20:19] &lt;Zeux&gt; Итак. <br />[20:19] &lt;Zeux&gt; <b>В Сталкере G-buffer</b> представлен тремя текстурами <br />[20:20] &lt;Zeux&gt; все три - формата A16B16G16R16F <br />[20:20] &lt;Zeux&gt; т.е. 4 канала, каждый канал - half (16-битный float) <br />[20:21] &lt;Zeux&gt; В первой текстуре находится нормаль в каналах RGB <br />[20:21] &lt;Zeux&gt; нормаль - в view space <br />[20:21] &lt;Zeux&gt; и, гм, hemi - в A <br />[20:21] &lt;Zeux&gt; что такое hemi я потом скажу :) <br />[20:22] &lt;Zeux&gt; во второй текстуре - позиция в каналах RGB <br />[20:22] &lt;Zeux&gt; тоже view space <br />[20:22] &lt;Zeux&gt; и индекс материала - в A <br />[20:22] &lt;Zeux&gt; значений индекса 4 штуки. <br />[20:22] &lt;Zeux&gt; т.е. 4 варианта материала <br />[20:22] &lt;Zeux&gt; в третьей текстуре в RGB находится цвет <br />[20:23] &lt;Zeux&gt; диффузный <br />[20:23] &lt;Zeux&gt; в четвертом канале - gloss коэффициент <br />[20:23] &lt;Zeux&gt; контролирующий количество спекуляра. <br />[20:23] &lt;Zeux&gt; Итак, первой задачей является - заполнить эти 3 текстуры. <br />[20:24] &lt;Zeux&gt; Для этого каждый видимый меш сцены рисуется в 3 текстуры с использованием MRT (из пиксельного шейдера возвращаются 3 цвета, каждый попадает в свою текстуру)</p> <p>[20:24] &lt;Zeux&gt; Теперь начинаются интересные вещи <br />[20:25] &lt;Zeux&gt; Вершины в мешах типично занимают 32 байта для статической геометрии <br />[20:25] &lt;Zeux&gt; 24 или 28 - для моделей персонажей и монстров <br />[20:25] &lt;Zeux&gt; что в них хранится. <br />[20:25] &lt;Zeux&gt; object space позиция вершины - float3 (12 байт) <br />[20:26] &lt;Zeux&gt; нормаль - byte4 (точнее, d3dcolor; 4 байта) <br />[20:26] &lt;Zeux&gt; касательная и бинормаль - так же <br />[20:26] &lt;Zeux&gt; 2 текстурных координаты - каждая в short2 (4 байта) <br />[20:27] &lt;Zeux&gt; это для статики, с монстрами потом <br />[20:27] &lt;Zeux&gt; первая текстурная координата используется для выборки из всех текстур, кроме лайтмапа <br />[20:27] &lt;Zeux&gt; вторая - для выборки из лайтмапа, в котором записано статическое освещение <br />[20:27] &lt;Zeux&gt; лайтмап оригинально - с их старого рендера <br />[20:28] &lt;Zeux&gt; который &quot;статическое освещение&quot; и про который рассказано не будет :) <br />[20:28] &lt;Zeux&gt; текстурные координаты изначально имеют range -32768..32767 (потому как short) <br />[20:28] &lt;Zeux&gt; для лайтмапа текс. координата просто делится на 32768 <br />[20:29] &lt;Zeux&gt; получается значение [-1, 1] (используется реально [0,1]), этого хватает, т.к. тайлинг не нужен <br />[20:29] &lt;Zeux&gt; а лайтмапы - 2048х2048. <br />[20:29] &lt;Zeux&gt; текстурные координаты делятся на 1024 <br />[20:29] &lt;Zeux&gt; получается значение [-32, 32] <br />[20:29] &lt;Zeux&gt; так вот <br />[20:30] &lt;Zeux&gt; как вы наверное заметили, в нормали, бинормали и касательной - остаются свободные компоненты - по 1 на вектор <br />[20:30] &lt;Zeux&gt; tangent.w и binormal.w - используются для повышения точности текстурных координат <br />[20:30] &lt;Zeux&gt; в них хранится значение [0, 1], которое прибавляется к текстурной координате перед делением на 1024. <br />[20:31] &lt;Zeux&gt; В свободной компоненте нормали хранится дополнительный фактор освещенности - скорее всего, статически просчитанный Ambient Occlusion</p><p><a href="http://www.gamedev.ru/community/gamedev_lecture/articles/r_e_n_de_r?page=2">Продолжение</a></p> http://www.gamedev.ru/community/gamedev_lecture/blog/?id=2416 Sat, 05 May 2007 20:09:53 GMT http://www.gamedev.ru/community/gamedev_lecture/blog/?id=2416 http://www.gamedev.ru/community/gamedev_lecture/forum/?id=64919 <p>В среду, 9.05, в 20:00 MSK, состоится <s>я не верю, что пишу это!</s> лекция Zeux-а &quot;R.E.N.D.E.R.&quot;</p> http://www.gamedev.ru/community/gamedev_lecture/blog/?id=2210 Mon, 15 Jan 2007 18:08:43 GMT http://www.gamedev.ru/community/gamedev_lecture/blog/?id=2210 http://www.gamedev.ru/community/gamedev_lecture/forum/?id=60036 <p>Ну вот и прошёл первый год для Gamedev Lecture. Хоть идея казалась немного странной, было много споров и сомнений - Lecture всё-же вышла вполне удачной. Много интересного опыта было &quot;разшарено&quot; и увековечено в виде IRC логов.</p> <p>За этот год накопилось 30+ лекций. Многие из них золотые и несут огромное количество информации и экспы (кстати их большинство), некоторые короткие и познавательные; даже есть одна <a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=1">шутка-лекция</a> :) (эх, первый опыт).</p> <p>Конечно эксперимент бы провалился без человека электро-веника <b>Zeux</b>'а, который проводил львиную долю суппорта и модерации. Так-же из постояльцев хочу отметить <b>MiF</b>'а, <b>kas</b>'а, <b>const</b>'а, <b>Rageous</b>'а, <b>Innochenti</b>, <b>xmvlad</b>'a, <b>dotprod</b>'а, <b>DrPadawan</b>'а, <b>_ShaMan_</b>'а, <b>VoidEx</b>'а, <b>Sark7</b>, <b>_Winnie</b>, <b>ShTiRLiC</b>'а, <b>DaGGeR</b>'а, <b>cppguru</b>, <b>XperienS</b>'а, <b>Joric</b>'а, <b>dRake</b>'а. (заранее извиняюсь если кого забыл занести в лист).</p> <p>Хочу так-же поблагодарить наших лекторов:</p> <p><b>Zeux</b> - за лекцию о <a href="http://www.gamedev.ru/community/gamedev_lecture/articles/resmgmt_1a">&quot;ресур менеджерах&quot;</a>, и конечно-же, за лекцию о <a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=25">технологиях рендера великого и ужасного - Oblivion'а</a>. <p><b>xmvlad</b> - за лекцию о <a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=5">принципах ООП</a>, <a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=6">физической водичке</a>, <a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=12">цветовых пространствах</a>, <a href="http://www.gamedev.ru/community/gamedev_lecture/articles/sh">Spherical Harmonics</a>, <a href="http://www.gamedev.ru/community/gamedev_lecture/articles/ga">генетических алгоритмах</a>. <p><b>kas</b> - за лекцию о <a href="http://www.gamedev.ru/community/gamedev_lecture/articles/landscape_lod_1">GPU-unfriendly техниках LOD для ландшафта</a>. <p><b>IronPeter</b> - за лекцию о <a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=10">скелетной анимации</a>. <p><b>Sark7</b> - за лекцию о <a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=13">Atmospheric scattering</a>, <a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=27">GUI</a>. <p><b>roman_p</b> - за лекцию о <a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=14">игровом AI</a>. <p><b>shodan</b> - за &quot;ревью&quot; <a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=15">системы шейдерных материалов</a>. <p><b>Innochenti</b> - за лекции о физике: <a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=16">GJK</a>, <a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=22">физическое моделирование твердых тел с шарнирами и контактами</a>. <p><b>aruslan</b> - за объемную лекцию о <a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=18">паттернах</a>. <p><b>CEMEH</b> - за объемную лекцию о <a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=19">тенях</a>. <p><b>XperienS</b> - за лекцию о <a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=20">итеративных LCP-солверах</a>. <p><b>fd</b> - за лекцию о <a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=23">&quot;LCP методом Лемке&quot;</a>. <p><b>cppguru</b> - за лекцию о <a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=24">оптимизации геометрии (strips, vcache, VBO)</a>. <br /> <br /><b>new</b> и <b>Joric</b> - за лекцию о <a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=26">физике на основе интегрирования Верлета</a>. <p><b>Cool Ace</b> - за лекцию о <a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=28">GUI</a>. <p><b>Jihar</b> - за <a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=29">постмортем игры &quot;Трюкмания&quot;</a>. <p><b>DaGGeR</b> - за то что поведал нам о своём подходе к <a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=33">игровой механики</a>. <p><b>ShTiRLiC</b> - за лекцию о <a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=34">Symbian development</a>. <p><b>NexiliaN</b> - за лекцию о <a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=35">&quot;Убер-система микрошейдеров&quot;</a>. <p><b>korak</b> - за лекцию о <a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=38">спаривание редактора на C# с движком на С++</a>. <p><b>egge</b> - за лекцию о <a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=40">встраивание интерпретатора C/С++ - CINT в игровой движок</a>. <p><b>MiF</b> & <b>Rageous</b>- за целую <a href="http://www.gamedev.ru/community/oo_design/articles/">книгу лекций о паттернах и архитектуре игрового движка</a>. <p>(Если кого пропустил из лекторов - заранее извиняюсь; говорите - исправим) <br />&nbsp; <br />Нельзя конечно забывать что лекций бы не было без слушателей. Благодарности всем тем кто слушал, интересовался, спрашивал, и вообще как-либо участвовал в процессе.</p> <p>Жгите дальше, больше, лучше! :)</p> http://www.gamedev.ru/community/gamedev_lecture/articles/?id=2204 Thu, 11 Jan 2007 19:58:22 GMT http://www.gamedev.ru/community/gamedev_lecture/articles/?id=2204 http://www.gamedev.ru/community/gamedev_lecture/forum/?id=59888 <p>&lt;egge&gt; перед тем как начать лекцию я хотел бы кой-че огласить <br />&lt;egge&gt; во первых пример здесь <a href="http://ifolder.ru/843324">http://ifolder.ru/843324</a> [<a href="http://www.gamedev.ru/download/?id=4833">http://www.gamedev.ru/download/?id=4833</a>] <br />&lt;egge&gt; во вторых пример только под линух <br />&lt;egge&gt; для компиляции понадобиться scons <br />&lt;egge&gt; <a href="http://scons.org">http://scons.org</a> <br />&lt;egge&gt; можно откомпилить под MinGW, но только с цинтом <br />&lt;egge&gt; там два варианта компиляции <br />&lt;egge&gt; scons -Q -h подскажет <br />&lt;egge&gt; и еще переменная среды CINTSYSDIR должна указывать на папку с цинтом <br />&lt;egge&gt; кстати я счастливый обладатель плохого инета, так что если вы увидите что я зашел второй раз, значит предыдущие сообщения не читал <br />&lt;egge&gt; ну что приступим? <br />----- <br />&lt;egge&gt; итак, зачем нужны скрипты <br />&lt;egge&gt; скрипты нужны чтоб не все время не компилить код <br />&lt;egge&gt; когда их меняют каждые 5 минут дизайнеры <br />&lt;egge&gt; для безопастности <br />&lt;egge&gt; правда в случае с интерпретатором с/с++ это не совсем получаетcя <br />&lt;egge&gt; безопастность в основном зависит от реализации движка <br />&lt;egge&gt; еще один плюс в с/с++ скриптах - это возможность безобидно откомпилить код в релизе вместо его интерпретации <br />&lt;egge&gt; чтобы увеличить скорость работы игры <br />&lt;egge&gt; Принцип встраивания <br />&lt;egge&gt; встраивать цинт очень просто <br />&lt;egge&gt; берем хеадеры движка, вызываемые из скриптов <br />&lt;egge&gt; обромляем все нужное ( тоесть паблики ) дефайнами <br />&lt;egge&gt; далее прогоняем через cint <br />&lt;egge&gt; на выходе получаем два файла <br />&lt;egge&gt; *.h и *.c <br />&lt;egge&gt; включив их в проэкт <br />&lt;egge&gt; можно вызывать собсно то, что мы обромляли из хеадеров движка <br />&lt;egge&gt; в скриптах <br />&lt;egge&gt; далее просто загружаем файлы и выполняем функции <br />&lt;egge&gt; как в примере <br />&lt;egge&gt; название функций в скрипте должны быть уникальными <br />&lt;egge&gt; если хотите откомпилить скрипты заранее обычным компилятором <br />&lt;egge&gt; нужно просто экспортировать свой entry_point в скриптах как это делаеться при создании длл <br />&lt;egge&gt; тоесть для винды это __declspec(dllexport) перед обьявлением <br />&lt;egge&gt; делее загружаем как длл <br />&lt;egge&gt; только handle указываем на NULL, для загрузки из текущего процесса <br />&lt;egge&gt; получаем указатель на функцию и запускаем на выполнение <br />&lt;egge&gt; загрузка как длл позволяет отладить скрипты <br />&lt;egge&gt; если нужно <br />&lt;egge&gt; вопросы? <br />&lt;DobroKOT&gt; у меня вопрос - как быстро оно парсилось. <br />&lt;DobroKOT&gt; Намного ли быстрей обычных компиляторов при сборке в релизе? <br />&lt;egge&gt; процесс сборки сильно ускорился <br />&lt;DobroKOT&gt; И, ещё - на сколько оно медленней по сравнению с Debug-кодом обычных компиляторов? <br />&lt;egge&gt; нельзя тут точно сказать на сколько, медленей <br />&lt;egge&gt; а на сколько быстрей <br />&lt;egge&gt; в нашем проэкте <br />&lt;egge&gt; фпс понизился где-то на 10 <br />&lt;egge&gt; по сравнению с комерческим аналогом ch <br />&lt;DobroKOT&gt; со скольких? <br />&lt;egge&gt; с 50 до 30 <br />&lt;egge&gt; *между <br />&lt;egge&gt; почему такой маленький фпс? <br />&lt;egge&gt; потому в движке было очень мало оптимизаций <br />&lt;DobroKOT&gt; это в Debug-режиме? <br />&lt;egge&gt; &lt;egge&gt; по сравнению с комерческим аналогом ch, цинт быстрее в несколько раз <br />&lt;egge&gt; да <br />&lt;DobroKOT&gt; а не меряли, сколько скрипты отжирают в процентах от общего? <br />&lt;egge&gt; нет <br />&lt;DobroKOT&gt; ага <br />&lt;DobroKOT&gt; Ещё у кого-нибудь вопросы?.. <br />&lt;DobroKOT&gt; вопросов нет :] <br />&lt;egge&gt; Встречаемые несовместимости <br />&lt;egge&gt; первая попавшаяся на глаза несовместимость с обычным компилятором - это макросы <br />&lt;egge&gt; цинт не позволяет делать макросы <br />&lt;egge&gt; тоесть можно использовать дефайты и ифдефы <br />&lt;egge&gt; но макросы - нет <br />&lt;egge&gt; далее инициализация структур <br />&lt;egge&gt; struct s i = { 0 }; // такое нельзя делать <br />&lt;egge&gt; это мс-специфик <br />&lt;egge&gt; цинт пропустит это не выдав никакого варнинга <br />&lt;egge&gt; нелзя инициализировать структуры в структурах <br />&lt;egge&gt; struct a { int i; }; <br />&lt;egge&gt; struct b { int j; }; <br />&lt;egge&gt; struct c{ struct a z; struct b x; } m; <br />&lt;egge&gt; m = { {0}, {0} }; //такое не поймент цинт <br />&lt;egge&gt; m = { 0, 0 }; //такое не поймент мс-компилер <br />&lt;egge&gt; итак выводы <br />&lt;egge&gt; можно почти без изменений встраивать функции для вызова из скриптов <br />&lt;egge&gt; увеличение скорости компиляции и линковки <br />&lt;egge&gt; при изменении кода не надо его постоянно компилить <br />&lt;egge&gt; можно вбилдить в код скрипты по релизу проэкта, для увеличения скорости выполнения <br />&lt;egge&gt; минусы: <br />&lt;egge&gt; безопастность кода очень низкая и зависить напрямую от интерфейса движка <br />&lt;egge&gt; некоторые несовместимости с компиляторами <br />&lt;egge&gt; вопросы есть? <br />&lt;Juster&gt; в каких проектах использовали? <br />&lt;egge&gt; использовалась для детской аркадной игры, которая еще вышла <br />&lt;KASiak&gt; не вышла? <br />&lt;egge&gt; нет <br />&lt;egge&gt; кстати извиняюсь что лекция может прошла может не очень интересно <br />&lt;egge&gt; это первый выход мой в свет</p> http://www.gamedev.ru/community/gamedev_lecture/articles/?id=2182 Sun, 24 Dec 2006 20:14:42 GMT http://www.gamedev.ru/community/gamedev_lecture/articles/?id=2182 http://www.gamedev.ru/community/gamedev_lecture/forum/?id=59233 <p>[21:17:41] korak: для начала пара слов о выборе .Net и С#. <br />[21:18:34] korak: поднималось много тем что лучше для редактора. какой язык, какая библиотека... спор штука бесполезная. поэтому просто приведу аргументы своего выбора: <br />[21:19:31] korak: * использование одной и той же среды разработки без дополнительных зависимостей. т.е. везде где есть студия есть .Net framework <br />[21:20:03] korak: * низки порог вхождения. как для C# так и для WinForms в целом <br />[21:20:23] korak: * большое комьюнити в фриварными контролами. <br />[21:20:44] korak: * наличие механизма рефлекшена <br />[21:21:02] korak: вот основные причины. вопросы? <br />[21:21:36] Reystlin: что такое рефлекшен? <br />[21:23:34] korak: <a href="http://en.wikipedia.org/wiki/Reflection_" rel="nofollow">http://en.wikipedia.org/wiki/Reflection_</a>(computer_science) <br />[21:23:47] Reystlin: сенкс <br />[21:24:29] korak: своими словами: это механизм посредством которого можно узнать информацию о типах которые содержит программа(модуль). <br />[21:24:45] korak: т.е. какие есть классы, какие у классов методы и т.д. <br />[21:25:33] Reystlin: понятно <br />[21:26:39] korak: ок. продолжаю. <br />[21:28:07] korak: первый блин использования .Net вышел комом. <br />[21:28:59] korak: причина была в движке. у него не было четкого порядка инициализации, т.к. какждый модуль был оформлен в виде сингельтона. <br />[21:30:51] korak: другая причина - попытка сделать &quot;быстрее&quot;. было принять решение писать редактор &quot;быстро&quot; на CLI C++. и через 2 дня сглючил форм дизайнер. продолжать разработку на CLI C++ прекратили. <br />[21:32:33] korak: CLI C++ не глюкавый сам по себе. но MS решила не делать из него нормальный инструмент для написания оконных приложений. поэтому код получается совершенной ужасным + дизайнер форм работает медленно и периодически случаются глюки. <br />[21:34:51] korak: после этого грабли кончились :) <br />[21:36:13] korak: решили не &quot;халявить&quot;. за 2 дня был написан прототип редактора который работал с движком через адаптер - .Net C++ CLI dll. <br />[21:37:39] korak: дальше буду расказывать о том хорошем что получили от .Net и С# и какие сложности предолели. если есть вопросы лучше задать. <br />[21:38:53] korak: ок. вопросов нет :) <br />[21:38:59] korak: есть. <br />[21:40:20] korak: egge: вы экспортили классы в длл? <br />[21:41:12] korak: в C# классы не экспортили. для классов писалась обвязка на CLI C++ - обвязка являлась .Net объектом и с ней уже&nbsp; работал редактор. <br />[21:42:44] korak: egge: тоесть вы начали писать только после того как у вас движок был полностью написан? <br />[21:43:23] korak: нет, движок полностью написан не был. но базовые классы и механизмы движка уже были в стабильной стадии. <br />[21:44:51] korak: продолжаю. <br />[21:48:06] korak: манаджед языки имеют ограничения на создания найтив типов <br />[21:50:44] korak: очень полезным ресурсом по вопросам связанным с .Net оказался rsdn.ru <br />[21:52:08] korak: Но как часто бывает решения &quot;наших&quot; проблем там не было. писались классе хендлеры для оборачивания Boost::shared_ptr&lt;&gt; на игровые объекты, хелперные классы для перехвата лога движка и пр. <br />[21:54:34] korak: к сожалению из-за предновогодней суеты я не успел подготовить исходники по этим проблемам. исправлю это упущение в ближайшее время. <br />[21:58:08] korak: далее шли только &quot;плюшки&quot; от .Net. на codeproject была найдена библиотека контролов с поддержкой докинга и сохранением раскаладки, так была решена проблема кастомизации редактора под нужны программистов и артистов. там же был найдет и вставлен за пару часов контрол изменения цвета. <br />[21:58:46] korak: общая архитектура системы этот момент была такая: <br />[22:01:05] korak: создавался редактор. он передвал хэндл на окно для рендера в метод создания движка. движок грузил данные прописанные в &quot;стартовом&quot; xml файле <br />[22:01:40] korak: редактор узнавал об добавлении\\удалении объектов сцены через&nbsp; callback <br />[22:03:07] korak: главный цикл крутился в редакторе, где и вызывались engine::tick и engine::render <br />[22:04:53] korak: изначально были написаны обвязки только для базовых типов движка. по мере необходимости дописались wrapperы для остальных типов. написание 1 врапера занимало &lt;= 1 час. <br />[22:06:44] korak: выделив объект в списке объектов сцены, можно было редактировать его паблик совойства в property grid редактора. <br />[22:10:36] korak: список объектов сцены содержал только объекты базового типа. и этого было достаточно для работы механизмов выделения и редактирования св-в через property grid контрол. <br />[22:13:49] korak: кастомизация работы с контретными типами достигалась за счет использования RTTI - проверялся тип выбранного объекта и если он приводился, например к типу AnimatedObject, то создавалось окно со списком анимаций. <br />[22:16:19] korak: так же в врапперной DLL использовались 2 класса атрибутов. которыми помечались методы класса, для представления их в виде кнопочек редактора, один атрибут отвечал за кнопочки на toolbar другой - на tab panel объекта. параметрами атрибутов были: отображаемый текст, текст тултипа, имя файла с картинкой. <br />[22:17:50] korak: так же с помощью атрибутов превратили в кнопочки сервисные методы движка, как, например, перезагрузка всех текстур. <br />[22:18:14] korak: вопросы и закругляюсь. <br />[22:22:13] korak: egge: сколько было потраченно времени и стоит ли оно того? я имею ввиду вобще написание редактора <br />[22:22:32] korak: базовая версия была написана за неделю. потом только расширялась, причем другими людьми. впрочем об этом будет подробней в заключении. <br />[22:28:21] korak: xmvlad: как происходила сериализация и миграция данных между движком и редактором? то есть добавили пачку новых свойств как преобразовывались старые данные редактора? <br />[22:28:28] korak: что значит старые данные? <br />[22:28:48] korak: xmvlad: ну наклепали часть сцены. потом добавились новые свойства материалов например. <br />[22:29:27] korak: а причем тут редактор? загрузку он только делегирует движку. поддержка и расширения формата данных движка - тема, вероятно, другой лекции. причем не моей :) <br />[22:30:14] korak: заключение: <br />[22:31:23] korak: базовая версия редактора с 0 была написана где-то за 1 неделю. включая враперную DLL и редактирования базовых св-в игровых объектов, как то цвет, позиция, имя, т.д. <br />[22:36:01] korak: все цели которые ставились написанием редактора были достигнуты. основные проблемы были связанны с изначальной непродуманностью архитекторы движка в целом. <br />[22:36:12] korak: *архитектуры. <br />[22:36:58] kas: вот у меня вопрос - делали undo/redo? врапер не станет ли толстым слишком изза етого? <br />[22:37:24] korak: экспорт утилитарных методов в редактор занимал меньше времени чем тоже самое на ingame gui <br />[22:39:09] kas: ну, по опыту написания остального, тяжело было бы внедрить? <br />[22:39:34] kas: на что следует обращать внимание при написании движка, чтобы потом можно было безболезненно оборачивать? <br />[22:39:45] korak: нет. тут бы и проявился один из основных плюсов врапера - то что логика редактора никак не влияет на движок. <br />[22:40:34] korak: kas, класические советы. ничего более. <br />[22:40:45] viv_: nothing more <br />[22:40:52] korak: просто код должен быть кодом а не помойкой :) <br />[22:40:55] kas: ага. понимать. ещё раз спасибо :) <br />[22:41:23] viv_: Это можно подискусировать? /me счетает если код помойка - то это просто кажеццо <br />[22:41:32] egge: а что насчет функционала? <br />[22:42:06] kas: насамом деле приятно конечно, пропертигрид пропертя автоматом показывает, вынес во врапер всякого и радуйся... <br />[22:42:12] korak: очень лично меня радовало что разный крап связанный с логикой редактирования никак не добавлял мусора и багов&nbsp; в движок :) <br />[22:44:04] ** *kas понял что его основная ошибка была с++/cli*</p><p><a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=2182&amp;page=2">Продолжение</a></p> http://www.gamedev.ru/community/gamedev_lecture/articles/?id=816 Wed, 28 Jun 2006 20:43:39 GMT http://www.gamedev.ru/community/gamedev_lecture/articles/?id=816 <p>Disclaimer: некоторые опечатки поправлены, некоторые реплики передвинуты. <a href="http://www.everfall.com/paste/id.php?ggtu9bh6ysfu">полный лог </a></p> <p>[22:59] &lt;_NexiliaN_&gt; речь в общем о довольно простой вещи - незнаю почему такая шумиха <br />[22:59] &lt;_NexiliaN_&gt; и так. <br />[22:59] &lt;_NexiliaN_&gt; Здравствуйте товарищи! ) <br />[22:59] &lt;_NexiliaN_&gt; и так начинаем наш сказ про убер микро шОйдеры. <br />[22:59] &lt;_NexiliaN_&gt; Пролог: <br />[22:59] &lt;_NexiliaN_&gt;&nbsp; 1.&nbsp; Убер-система микрошейдыров&nbsp; за это название спасибо Zeux. <br />[22:59] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; a.&nbsp; Убер-Шаудеры это очень толстые монстры с тонной #if/def <br />[22:59] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; это из другой оперы в общем. <br />[22:59] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; b.&nbsp; Речь же идёт о microshaders <br />[23:00] &lt;_NexiliaN_&gt;&nbsp; 2.&nbsp; система microshaders собирает код из фрагментов. <br />[23:00] &lt;_NexiliaN_&gt; 3.&nbsp; Фрагмент ( микро-шадер ) - код на asm или на языке высокого <br />[23:00] &lt;_NexiliaN_&gt; уровня( от реализаций ) с входными/выходными данными, <br />[23:00] &lt;_NexiliaN_&gt; требованиями и профилем. <br />[23:00] &lt;_NexiliaN_&gt; 4.&nbsp; лекция идёт as-is, то есть обвинять лектора в обкуренности <br />[23:00] &lt;_NexiliaN_&gt; не стоит.</p> <p>[23:00] &lt;_NexiliaN_&gt; далее немного поиграю в q.a;)</p> <p>[23:00] &lt;_NexiliaN_&gt; q. <b>что такое микро шадеры</b> и чем они лучше убершадеров? <br />[23:00] &lt;_NexiliaN_&gt; a. Убер-шадеры явно фиксированные(#if/def)&nbsp; могут помочь <br />[23:00] &lt;_NexiliaN_&gt; сгенерировать несколько вариаций, но в пределах максимально <br />[23:00] &lt;_NexiliaN_&gt; заложенных возможностей *препроцессор рулит . Микро шадеры от <br />[23:00] &lt;_NexiliaN_&gt; данного недостатка избавлены и могут свободно комбинироваться c <br />[23:00] &lt;_NexiliaN_&gt; заранее неизвестными.</p> <p>[23:00] &lt;_NexiliaN_&gt; q. <b>зачем это надо? Как это отразится на материалах?</b> <br />[23:01] &lt;_NexiliaN_&gt; a. в общем-то со стороны материала мало что меняется. Это скорее <br />[23:01] &lt;_NexiliaN_&gt; более тонкие возможности. <br />[23:01] &lt;_NexiliaN_&gt;&nbsp; &nbsp; Пример: в материале обычно есть модификатор diffuse&nbsp; он <br />[23:01] &lt;_NexiliaN_&gt; отвечает за diffuse(цвет точки без затенения) <br />[23:01] &lt;_NexiliaN_&gt;&nbsp; &nbsp; например: color = sample2D(diffise,&nbsp; uv) + sample2D(noise , <br />[23:01] &lt;_NexiliaN_&gt; uv + time * 2) * sample(mask, uv). =)) <br />[23:01] &lt;_NexiliaN_&gt;&nbsp; &nbsp; и такой эффект скажем, встречается крайне редко. <br />[23:01] &lt;_NexiliaN_&gt;&nbsp; &nbsp; Что нам теперь делать описывать все вариаций shadera или <br />[23:01] &lt;_NexiliaN_&gt; очередной uber-shader для света, кожинга и т.д.? ;) <br />[23:01] &lt;_NexiliaN_&gt;&nbsp; &nbsp; А в случай с microshaders эта проблема отпадает. <br />[23:01] &lt;_NexiliaN_&gt;&nbsp; &nbsp; Для этого примера мы просто создаём материал, указываем <br />[23:01] &lt;_NexiliaN_&gt; модификатор и создаём новый microshader который и делает <br />[23:01] &lt;_NexiliaN_&gt; указанную операцию.</p> <p>[23:01] &lt;_NexiliaN_&gt; q. <b>что такое модификатор?</b> <br />[23:01] &lt;_NexiliaN_&gt; a. модификатор это система управление определёнными группами <br />[23:01] &lt;_NexiliaN_&gt; microshaderев. *Модификаторов столько, сколько и систем. <br />[23:01] &lt;_NexiliaN_&gt;&nbsp; &nbsp; К Примеру: diffuse, lightmap, light, posteffect и т.д. Они <br />[23:01] &lt;_NexiliaN_&gt; зависимы и расположены иерархически. Вернёмся к ним позднее.</p> <p>[23:02] &lt;_NexiliaN_&gt; q. то есть если просто к материалу прицепит модификатор? <br />[23:02] &lt;_NexiliaN_&gt; skinning, shader автоматически скомпилируется? <br />[23:02] &lt;_NexiliaN_&gt; a. да. Только не к материалу, а непосредственно к объекту/render <br />[23:02] &lt;_NexiliaN_&gt; actorу. (меш если хотите) <br />[23:02] &lt;_NexiliaN_&gt;&nbsp; &nbsp; К примеру: есть на просторах, новой Зеландий, меш травы <br />[23:02] &lt;_NexiliaN_&gt; (конопли, если хотите) <br />[23:02] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; мы к этому объекту просто прицепляем глобальный <br />[23:02] &lt;_NexiliaN_&gt; модификатор Vegetation waves. <br />[23:02] &lt;_NexiliaN_&gt;&nbsp; &nbsp; Разумеется, веса должны хранится в потоке vb.</p> <p>[23:02] &lt;_NexiliaN_&gt; <b>Лекция:&nbsp; begin: часть 1</b> <br />[23:03] &lt;_NexiliaN_&gt; Система microshaderев представляем из себя набор и фрагментов <br />[23:03] &lt;_NexiliaN_&gt; на любом языке дружественный для GPU. <br />[23:03] &lt;_NexiliaN_&gt; Позволяет собирать из них полноценные программы для GPU <br />[23:03] &lt;_NexiliaN_&gt; (shaders). <br />[23:03] &lt;_NexiliaN_&gt; Формирует RenderGraph (точнее его узел). - Выходной сценарий <br />[23:03] &lt;_NexiliaN_&gt; обрисовки.- Последовательность установки буферов, shaderов и <br />[23:03] &lt;_NexiliaN_&gt; т.д. <br />[23:03] &lt;_NexiliaN_&gt; Я предпочёл asm в своё время (точнее свой скрипт).&nbsp; это <br />[23:03] &lt;_NexiliaN_&gt; позволило более точно оценивать длину фрагмента и точнее <br />[23:03] &lt;_NexiliaN_&gt; профилировать( hlsl такого на компилит порой ). ;)</p> <p>[23:03] &lt;_NexiliaN_&gt; <b>MicroShader и методы</b> ( в дальнейшем microshader == ms ) <br />[23:05] &lt;_NexiliaN_&gt;&nbsp; 1.&nbsp; Method&nbsp; это непосредственно код GPU и все параметры <br />[23:05] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; необходимые для того объекта. <br />[23:05] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; a.&nbsp; Описывается как тип method программы (может быть <br />[23:05] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ps/vs/psva/any в будущем сложнее). <br />[23:05] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; i.&nbsp; Пример: &lt; method type=&quot;any&quot; name=&quot;Normalize&quot; template_name = <br />[23:05] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &quot;vector3&quot; &gt; <br />[23:05] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 1.&nbsp; type&nbsp; тип программы <br />[23:05] &lt;_NexiliaN_&gt; 2.&nbsp; name&nbsp; имя <br />[23:05] &lt;_NexiliaN_&gt; 3.&nbsp; template_name&nbsp; имя для другим программ. ( реализация =] ) <br />[23:05] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; b.&nbsp; Link&nbsp; указывает явные зависимости программ. <br />[23:05] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; i.&nbsp; К Примеру: пиксельная программа ссылается на нужную для неё <br />[23:05] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; vs программу. <br />[23:05] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 1.&nbsp; Например:&nbsp; &lt;link type=vs name=baryCentricCoord&gt; <br />[23:05] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; a.&nbsp; Именно это устанавливает связку программ.</p> <p><i> <br />[23:06] &lt;_NexiliaN_&gt; korak : для какого АПИ была реализована система? <br />[23:07] &lt;_NexiliaN_&gt; апи значение иметь небудет если вы позаботитесь о собственном скрипте <br /></i> <p>[23:07] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; c.&nbsp; Include&nbsp; тоже что и #include в cpp&nbsp; целые ms <br />[23:07] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; i.&nbsp; Пример: &lt;include name = &quot;Normalize&quot;/&gt; <br />[23:07] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; d.&nbsp; Common&nbsp; указывается необходимый общий ms до этого ms. <br />[23:07] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; i.&nbsp; Пример: в случай со светом <br />[23:07] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 1.&nbsp; &lt;common name = ReflectVector/&gt; <br />[23:07] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; a.&nbsp; этот объект встанет выше последнего просившего.&nbsp; хотя его <br />[23:07] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; также можно запросить в IO. <br />[23:07] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; i.&nbsp; Применяется в частных случаях. <br />[23:08] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; e.&nbsp; IO&nbsp; входящий и выходящие параметры (сроковыми именами) <br />[23:08] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; i.&nbsp; К Примеру: &lt;IO input = &quot;vector3&quot; var = &quot;invec&quot; proxy = any <br />[23:08] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; params =/&gt; <br />[23:08] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; a.&nbsp; input&nbsp; создает переменную IO для фрагмента. Где явно <br />[23:08] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; указывает, с чем работаем. Это может быть строковое имя. <br />[23:08] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; i.&nbsp; Например, явное указание:&nbsp; в место vector3&nbsp; normal3 (что <br />[23:08] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; потребует до этого фрагмента нормаль). Не в этом случай. <br />[23:08] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 2.&nbsp; var&nbsp; имя как будет называться в нутрии фрагмента эта IO <br />[23:08] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; переменная. <br />[23:08] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 3.&nbsp; proxy&nbsp; явные Тип. (например, что это anyFloat3). <br />[23:08] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 4.&nbsp; params&nbsp; доп. Параметры. <br />[23:09] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ii. К Примеру: &lt;IO output = &quot;vector3&quot; var = &quot;outvec&quot; proxy=any <br />[23:09] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; params=/&gt; <br />[23:11] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; f.&nbsp; Далее описывается: порядок параметров&nbsp; необходимо <br />[23:11] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; использование линковки в телах других фрагментов. <br />[23:11] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; i.&nbsp; К Примеру: &lt;func_order&gt; &lt;order name = &quot;outvec&quot;/&gt; &lt;order name <br />[23:11] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; = &quot;invec&quot;/&gt; &lt;/func_order&gt;. <br />[23:12] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ii. Обязательно только для библиотечных ms как эта. <br />[23:12] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; g.&nbsp; Requare&nbsp; описание требований (констант или текстур и т.д.) <br />[23:12] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; i.&nbsp; Пример: &lt;require texLookUp = &quot;normalizeCubeMap&quot; var = <br />[23:12] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &quot;nrmLookUp&quot;/&gt; - $к этому примеру не относится. <br />[23:12] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 1.&nbsp; сто соответственно запросит самплер normalizeCubeMap <br />[23:12] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; переменная nrmLookUp - $к этому примеру не относится. <br />[23:12] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ii. Пример: &lt;require global_constant = adaptiveBias, var = <br />[23:12] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; bias/&gt; - $к этому примеру не относится. <br />[23:12] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; iii.Пример: &lt;require interpolator = diffuse_uv, var = bias/&gt; <br />[23:12] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; - и т.д. - $к этому примеру не относится. <br />[23:12] &lt;_NexiliaN_&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 1.&nbsp; diffuse_uv равна общей uv.</p><p><a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=816&amp;page=2">Продолжение</a></p> http://www.gamedev.ru/community/gamedev_lecture/blog/?id=807 Sun, 25 Jun 2006 09:39:55 GMT http://www.gamedev.ru/community/gamedev_lecture/blog/?id=807 <p>В среду, 28.06, в 23:00 MSK, состоится лекция <b>NexiliaN</b>-а &quot;Убер-система микрошейдеров.&quot;</p> <p>Также выложены <a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=34">логи прошедшей лекции</a> Symbian development (лектор - <b>ShTiRLiC</b>).</p> http://www.gamedev.ru/community/gamedev_lecture/articles/?id=806 Sat, 24 Jun 2006 20:40:09 GMT http://www.gamedev.ru/community/gamedev_lecture/articles/?id=806 http://www.gamedev.ru/community/gamedev_lecture/forum/?id=1271 <p>Disclaimer: некоторые опечатки поправлены, некоторые реплики передвинуты. <a href="http://www.everfall.com/paste/id.php?5unzv6q8h390">полный лог</a></p> <p>[21:01] &lt;ShTiRLiC&gt; <b>Итак, что же такое Symbian OS?</b> Это полноценная 32-битная операционная система, многозадачная, с разделением времени процессов <br />[21:02] &lt;ShTiRLiC&gt; Работает она на смартфонах и некоторых КПК <br />[21:02] &lt;ShTiRLiC&gt; В основном, Симбиан ставится на смартфоны Nokia, также Ericsson <br />[21:02] &lt;ShTiRLiC&gt; Симбиан на рынке смартфонов охватывает порядка 60-70% рынка <br />[21:02] &lt;ShTiRLiC&gt; Для сравнения, WinMobile - 20% <br />[21:03] &lt;ShTiRLiC&gt; Собственно, я в лекции не буду рассматривать подробно создание UI <br />[21:03] &lt;ShTiRLiC&gt; Потому что в играх он все равно графический</p> <p>[21:03] &lt;ShTiRLiC&gt; <b>Немного про SDK</b> <br />[21:03] &lt;ShTiRLiC&gt; Его можно скачать на сайте <a href="http://forum.nokia.com">http://forum.nokia.com</a>, весит 145 метров <br />[21:04] &lt;ShTiRLiC&gt; да, у меня Nokia 6630, и именно отталкиваясь от поддерживаемого им Симбиана я буду отталкиваться <br />[21:04] &lt;ShTiRLiC&gt; У меня стоит Symbian 8.0a, на довольно известных Nokia N-Gage - Symbian 6 <br />[21:04] &lt;ShTiRLiC&gt; Между ними на устройствах Symbian 7.0s <br />[21:04] &lt;ShTiRLiC&gt; Еще замечу, что связь у меня не очень стабильная, и я могу вылетать <br />[21:05] &lt;ShTiRLiC&gt; Так, значит про SDK <br />[21:05] &lt;ShTiRLiC&gt; Он реализован в виде огромной системы классов <br />[21:05] &lt;ShTiRLiC&gt; Совсем непривычно, да? <br />[21:05] &lt;ShTiRLiC&gt; В знакомых большинству системах SDK - всего лишь набор функций в C-стиле <br />[21:05] &lt;ShTiRLiC&gt; Отсюда специфика разработки приложений под Symbian</p> <p>[21:06] &lt;ShTiRLiC&gt; Начнем с <b>первого типа программ - EXE</b> <br />[21:06] &lt;ShTiRLiC&gt; Эти программы все консольные, то есть работают в текстовом режиме <br />[21:06] &lt;ShTiRLiC&gt; На эмуляторе их легко создавать, т.к. там по сути то же самое, что и в программах на C - одна главная функция и операторы вывода в консоль <br />[21:08] &lt;ShTiRLiC&gt; Примеры будут преимущественно из SDK <br />[21:08] &lt;ShTiRLiC&gt; Итак, Hello World для консоли <br />[21:08] &lt;ShTiRLiC&gt; Вас, возможно, удивит его вид, т.к. отличия от DOS найти сложно <br />[21:09] &lt;ShTiRLiC&gt; Ну и вообще от консоли <br />[21:09] &lt;ShTiRLiC&gt; <a href="http://www.everfall.com/paste/id.php?fedt6qjtyovi">http://www.everfall.com/paste/id.php?fedt6qjtyovi</a> <br />[21:09] &lt;ShTiRLiC&gt; Вот так всё примитивно <br />[21:09] &lt;ShTiRLiC&gt; Однако, запустить такую программу на телефоне весьма затруднительно <br />[21:09] &lt;ShTiRLiC&gt; По крайней мере, у меня ничего не вышло =) <br />[21:10] &lt;ShTiRLiC&gt; Дело в том, что в формате EXE обычно создаются сервисы - не имеющие интерфейса (UI имею в виду), работающие в фоне <br />[21:10] &lt;ShTiRLiC&gt; В загруженной ОСи, в которой еще ничего не запущено, работает порядка 64 процессов <br />[21:10] &lt;ShTiRLiC&gt; Почти все эти программы - консольные <br />[21:10] &lt;ShTiRLiC&gt; Нас они не очень интересуют, т.к. игры там писать довольно сложно =)</p> <p>[21:11] &lt;ShTiRLiC&gt; Поэтому закроем эту тему и перейдем к <b>более интересному виду приложения - .APP</b> <br />[21:11] &lt;ShTiRLiC&gt; Аппы - это визуальные приложения <br />[21:11] &lt;ShTiRLiC&gt; На самом деле, они не являются истинно исполняемыми файлами, т.к. банально не имеют точки входа =) <br />[21:12] &lt;ShTiRLiC&gt; APP - это DLL <br />[21:12] &lt;ShTiRLiC&gt; UI фреймворк симбиана вызывает определенные экспортированные функции из этой DLL, получая в ответ необходимые <u>объекты</u> <br />[21:13] &lt;ShTiRLiC&gt; Повторю, что в симбиане вся работа приложения построена на объектах, никто не даст вам вызвать какие-либо функции напрямую <br />[21:13] &lt;ShTiRLiC&gt; Минимальная APP-программа (далее - просто программа) состоит из 4-х классов <br />[21:14] &lt;ShTiRLiC&gt; И вообще, вся система работы симбиан-программы построена по концепции UI-Документ-Вид <br />[21:14] &lt;ShTiRLiC&gt; Собственно, это три основные класса <br />[21:14] &lt;ShTiRLiC&gt; Еще один класс - это т.н. ядро (я называю его так) <br />[21:14] &lt;ShTiRLiC&gt; Ядро создает <u>документ</u> <br />[21:14] &lt;ShTiRLiC&gt; В ядре должны содержаться 4 функции <br />[21:15] &lt;ShTiRLiC&gt; (кстати, минимальная программа легко создается визардом нового приложения, так что вам не придется писать эту рутину руками) <br />[21:15] &lt;ShTiRLiC&gt; Кратенько перечислю, что они делают, без названий <br />[21:16] &lt;ShTiRLiC&gt; Также ща закину исходник на everfall <br />[21:16] &lt;ShTiRLiC&gt; <a href="http://www.everfall.com/paste/id.php?worqeq998ob6">http://www.everfall.com/paste/id.php?worqeq998ob6</a> <br />[21:16] &lt;ShTiRLiC&gt; Пожалуйста, следите за исходником <br />[21:17] &lt;ShTiRLiC&gt; Метод AppDllUid должен вернуть UID приложения <br />[21:17] &lt;ShTiRLiC&gt; UID - это уникальный номер, который есть у каждой программы <br />[21:17] &lt;ShTiRLiC&gt; Собственно, в целях тестирования можно вбить что-нибудь, не входящее в диапазоны системных UID'ов <br />[21:18] &lt;ShTiRLiC&gt; Но при релизе необходимо бесплатно запросить у Symbian Ltd. уникальный UID (соответственно его названию =)) <br />[21:18] &lt;ShTiRLiC&gt; Дают обычно пачками, сразу 10-20 штук <br />[21:18] &lt;ShTiRLiC&gt; Просто если в системе будет более одного UID'а, возникнут проблемы <br />[21:18] &lt;ShTiRLiC&gt; Далее <br />[21:19] &lt;ShTiRLiC&gt; CreateDocumentL() - этот метод вызывается фреймворком Symbian <br />[21:19] &lt;ShTiRLiC&gt; Приложение должно создать и вернуть в ответ указатель на документ приложения <br />[21:19] &lt;ShTiRLiC&gt; Так, вкратце про документы <br />[21:19] &lt;ShTiRLiC&gt; Документ - объект хранения данных, например, сейвов или действительно документов <br />[21:20] &lt;ShTiRLiC&gt; В принципе, в наших целях он использоваться не будет <br />[21:20] &lt;ShTiRLiC&gt; Все данные лучше грузить руками через сервер файловой системы <br />[21:20] &lt;ShTiRLiC&gt; Еще сразу объясню, что такое CSymbianPrjDocument::NewL() <br />[21:20] &lt;ShTiRLiC&gt; Ну, как видно из названия, это статический метод создания <br />[21:21] &lt;ShTiRLiC&gt; Буква L означает, что функция может вызвать исключение (например, если нет памяти) <br />[21:21] &lt;ShTiRLiC&gt; Но исключения тут называются &quot;ливами&quot; (Leave) <br />[21:21] &lt;ShTiRLiC&gt; Просто стандартные эксепшны С++ оказались очень прожорливыми до памяти, и был придуман другой, экономичный механизм <br />[21:21] &lt;ShTiRLiC&gt; Хотя и более кривой =) <br />[21:22] &lt;ShTiRLiC&gt; Но об этом попозже <br />[21:22] &lt;ShTiRLiC&gt; В качестве параметра передается указатель на объект приложения <br />[21:22] &lt;ShTiRLiC&gt; Стоит отметить, что в предыдущих двух методах мы работали с классом CSymbianPrjApp <br />[21:23] &lt;ShTiRLiC&gt; Однако его еще надо создать <br />[21:23] &lt;ShTiRLiC&gt; Функция NewApplication(), которая, как видно из префикса, является экспортируемой, вызывается фреймворком <br />[21:23] &lt;ShTiRLiC&gt; В ответ приложение создает класс ядра (т.н. мной) и отдает фреймворку <br />[21:24] &lt;ShTiRLiC&gt; В принципе, функция NewApplication() является единственной явно экспортируемой из нашей DLL (APP) <br />[21:24] &lt;ShTiRLiC&gt; Дальше объекты создаются по цепочке <br />[21:24] &lt;ShTiRLiC&gt; Так, ну и последняя функция E32Dll() <br />[21:25] &lt;ShTiRLiC&gt; Она должна вернуть код ошибки, всегда возвращает KErrNone <br />[21:25] &lt;ShTiRLiC&gt; Хм, ну она тоже экспортируемая =) <br />[21:25] &lt;ShTiRLiC&gt; Итак, у нас создан документ <br />[21:25] &lt;ShTiRLiC&gt; Ща закину исходник класса документа <br />[21:26] &lt;ShTiRLiC&gt; Кстати, .h закидывать надо для понимания, от чего унаследованы эти мои классы? <br />[21:26] &lt;ShTiRLiC&gt; Хм <br />[21:27] &lt;ShTiRLiC&gt; Ну ладно, потом <br />[21:27] &lt;ShTiRLiC&gt; <a href="http://www.everfall.com/paste/id.php?zh0qslssrncl">http://www.everfall.com/paste/id.php?zh0qslssrncl</a> <br />[21:27] &lt;ShTiRLiC&gt; Тут расписан класс документа <br />[21:27] &lt;ShTiRLiC&gt; Он практически пуст, за исключением двухстадийного конструктора <br />[21:27] &lt;ShTiRLiC&gt; Поступила просьба выложить хедеры <br />[21:27] &lt;ShTiRLiC&gt; Ща объясню про конструктор и выложу</p> <p>[21:28] &lt;ShTiRLiC&gt; Итак, в симбиане многое сделано не по-человечески <br />[21:28] &lt;ShTiRLiC&gt; В силу ограниченной оперативной памяти (у меня, к примеру, 10 Мб всего, из них 2 заняты системой) <br />[21:28] &lt;ShTiRLiC&gt; Хотя может там и больше RAM <br />[21:29] &lt;ShTiRLiC&gt; Неважно <br />[21:29] &lt;ShTiRLiC&gt; Стек на каждый поток - всего 8 Кб <br />[21:29] &lt;ShTiRLiC&gt; Так что на локальных переменных стоит экономить <br />[21:29] &lt;ShTiRLiC&gt; По этим причинам создание любого объекта происходит в две стадии <br />[21:30] &lt;ShTiRLiC&gt; Товарищи замечают, что в j2me 300 Кбайт за счастье <br />[21:30] &lt;ShTiRLiC&gt; Объясняю, что в симбиане весь код нативный, да и объектов зачастую побольше <br />[21:30] &lt;ShTiRLiC&gt; Но в общем-то запустить 2-3 массивных проги вполне реально <br />[21:31] &lt;ShTiRLiC&gt; Ну что ж, я все-таки попробую объяснить про двухстадийные конструкторы =) <br />[21:31] &lt;ShTiRLiC&gt; Для создания объектов в Симбиане не принято использовать new, т.к. все объекты должны наследовать от CBase и иметь дефолтный конструктор приватным <br />[21:32] &lt;ShTiRLiC&gt; Для создания используется фабрика NewL (или NewLC, разницу поясню позже) <br />[21:32] &lt;ShTiRLiC&gt; Смотрим в код, читаем мое пояснение <br />[21:32] &lt;ShTiRLiC&gt; У нас мало памяти, и её всегда может не хватить для создания нового объекта <br />[21:32] &lt;ShTiRLiC&gt; Это неминуемо вызовет Leave (далее лив), т.е. исключение <br />[21:33] &lt;ShTiRLiC&gt; Для перехвата ливов можно ставить трапы (аналог catch) или ловушки <br />[21:33] &lt;ShTiRLiC&gt; Но я с этим не работал, честно говоря <br />[21:33] &lt;ShTiRLiC&gt; Итак, на первой стадии двухфазного конструктора мы создаем объект простым new <br />[21:34] &lt;ShTiRLiC&gt; Поступил вопрос, что же я там такое создам в 8 метрах <br />[21:34] &lt;ShTiRLiC&gt; Что ж, мы рассматриваем исключительно игры, так что игровые объекты могут быть больших размеров <br />[21:35] &lt;ShTiRLiC&gt; То есть, я может быть захочу создать большой массив, инициализированный нулями <br />[21:35] &lt;ShTiRLiC&gt; Или создам класс-контейнер с заранее выделенной памятью <br />[21:35] &lt;ShTiRLiC&gt; Статический массив, грубо говоря</p><p><a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=806&amp;page=2">Продолжение</a></p> http://www.gamedev.ru/community/gamedev_lecture/blog/?id=804 Fri, 23 Jun 2006 19:16:21 GMT http://www.gamedev.ru/community/gamedev_lecture/blog/?id=804 <p>В субботу, 24.06.06, в 21:00 MSK состоится лекция <b>ShTiRLiC</b>-а, посвященная разработке под платформу Symbian.</p> http://www.gamedev.ru/community/gamedev_lecture/articles/?id=799 Fri, 16 Jun 2006 20:51:13 GMT http://www.gamedev.ru/community/gamedev_lecture/articles/?id=799 http://www.gamedev.ru/community/gamedev_lecture/forum/?id=1238 <p>Disclaimer: некоторые опечатки поправлены, некоторые реплики передвинуты.</p> <p>&lt;DaGGeR&gt; Значит как я это делаю. На уберправильность не претендую, но работает хорошо. <br />&lt;DaGGeR&gt; Два основных понятия в игровой логике это Мир и Актор. <br />&lt;DaGGeR&gt; Мир представляет собой класс который как ни странно менеджит игровой мир. <br />&lt;DaGGeR&gt; Он умеет: 1. создавать акторов через фабрики <br />&lt;DaGGeR&gt; 2. Апдейтиться через deltatime изменяя свои параметры (там гравитацию поменять, и т.д) <br />&lt;DaGGeR&gt; 3. Апдейтить Акторов <br />&lt;DaGGeR&gt; 4. Убивать Акторов</p> <p>&lt;DaGGeR&gt; Теперь про акторов <br />&lt;DaGGeR&gt; Актор это базовый класс от которого наследуются все объекты в игровом мире. <br />&lt;DaGGeR&gt; Актор может быть создан только миром через фабрику <br />&lt;DaGGeR&gt; Актор умеет: <br />&lt;DaGGeR&gt; 1. Апдейтиться по прошествию deltatime <br />&lt;DaGGeR&gt; 2. Сообщать о своем состоянии миру <br />&lt;DaGGeR&gt; Например в актора попала ракета. <br />&lt;DaGGeR&gt; Он убит и должен исчезнуть. <br />&lt;DaGGeR&gt; Он выставляет у себя cпециальный параметр LifeTime=0 <br />&lt;DaGGeR&gt; и мир в следующий проход удаляет его <br />&lt;DaGGeR&gt; Конечно можно сделать чтобы мир сам при обработке столкновения актора с ракетой обработал это событие и удалил актора <br />&lt;DaGGeR&gt; но при этом теряется гибкость. <br />&lt;Cote-Duke&gt; Должен согласиться с Дагом. <br />&lt;DaGGeR&gt; С другой стороны в моей реализации актор обязан знать что с ним столкнулось и как на это реагировать <br />&lt;DaGGeR&gt; но все решается дефолтной реакцией + расширения на акторов, на которых он должен както особенно реагировать</p> <p>&lt;DaGGeR&gt; Так вот <br />&lt;DaGGeR&gt; как это сейчас реализовано. <br />&lt;DaGGeR&gt; щас псевдокод набросаю <br />&lt;DaGGeR&gt; пока можно вопросы если вдруг есть <br />&lt;DaGGeR&gt; :)) <br />&lt;Cote-Duke&gt; Могу сказать что это классика. В своей версии я ещё добавил workgroups для акторов (entity) что-бы они могли апдейтиться в разные промежутки времени с разной частотой. (fixed time step)</p> <p>&lt;kas&gt; раскрой тему разного апдейта <br />&lt;ShTiRLiC&gt; Что-то мне как-то примитивной схема показалась... <br />&lt;ShTiRLiC&gt; Обычно сложнее описывают <br />&lt;Cote-Duke&gt; Simplicty the genius. <br />&lt;ShTiRLiC&gt; Или я путаю логику игры со структурой движка?.. <br />&lt;ShTiRLiC&gt; Не, ну это понятно <br />&lt;_ShaMan_&gt; это в общих чертах <br />&lt;kas&gt; я видать пропустил <br />&lt;kas&gt; но ето для какого жанра? <br />&lt;Cote-Duke&gt; Я думаю почти для любого. <br />&lt;ShTiRLiC&gt; В данном случае не рассмотрена подробная классификация акторов <br />&lt;kas&gt; ну, чем ето лучше чем скажем саморегаца в мире и из какихнить скриптов там создаваться <br />&lt;ShTiRLiC&gt; Поэтому такое базовое деление - да, для любого <br />&lt;kas&gt; или ешё чего <br /># kas нивидит мегобонуса</p> <p>&lt;kas&gt; подробная класификация не интересна, ибо ето личный конкретный случай <br />&lt;DaGGeR&gt; кас <br />&lt;kas&gt; ась <br />&lt;DaGGeR&gt; это ты пытаешся скатиться к единичным случаям <br />&lt;kas&gt; м? <br />&lt;DaGGeR&gt; а я говорю о базовой концепции <br />&lt;kas&gt; не понял про единичные случаи <br />&lt;DaGGeR&gt; скриптовый актор у меня наследуется от базового и хорошо живет <br />&lt;kas&gt; ну, тогда определено надо какихто подробностей</p> <p>&lt;DaGGeR&gt; <a href="http://www.everfall.com/paste/id.php?5qqh3r51n9fp">http://www.everfall.com/paste/id.php?5qqh3r51n9fp</a> <br />&lt;DaGGeR&gt; вот так примерно выглядит основной функционал мира <br />&lt;DaGGeR&gt; <a href="http://www.everfall.com/paste/id.php?wbf9tz9kdust">http://www.everfall.com/paste/id.php?wbf9tz9kdust</a> <br />&lt;DaGGeR&gt; а вот так - актор <br />&lt;DaGGeR&gt; есть несколько тонких моментов <br />&lt;DaGGeR&gt; например если програмер решил удалить актора в ручную а не выставлять ему лайфтайм <br />&lt;DaGGeR&gt; в таком случае у меня актор в деструкторе сам сообщает миру, что &quot;не жди меня мама...&quot; <br />&lt;DaGGeR&gt; и мир вычеркивает его из списка живых не дожидаясь следующего тика</p> <p>&lt;DaGGeR&gt; сейчас как временная мера реализована саморегистрация приблудных акторов в конструкторе <br />&lt;DaGGeR&gt; не зря же там World* передается <br />&lt;DaGGeR&gt; но я потихоньку от таких беспризорников избавляюсь</p> <p>&lt;DaGGeR&gt; вот собственно и все <br />&lt;DaGGeR&gt; абстрактно но работоспособно хоть в 2д аркаде хоть в гоночном симуляторе <br />&lt;DaGGeR&gt; я уложился в 15 минут? :)</p> http://www.gamedev.ru/community/gamedev_lecture/articles/sh Tue, 13 Jun 2006 21:50:37 GMT http://www.gamedev.ru/community/gamedev_lecture/articles/sh http://www.gamedev.ru/community/gamedev_lecture/forum/?id=1245 <p>оригинальный лог:&nbsp; <a href="http://www.everfall.com/paste/id.php?20f4zp1hf2y9">http://www.everfall.com/paste/id.php?20f4zp1hf2y9</a></p> <p>&lt;MiF&gt; давай <br />&lt;MiF&gt; вещай уже <br />&lt;xmvlad&gt; надо тогда дисклеймер хотя бы написать чтоб касег не волновался.. <br />&lt;Zeux&gt; пиши свой дисклеймер <br />&lt;xmvlad&gt; ладно в общем :) данное повествование является разжовыванием теоретических основ SH для тех кто как и <br />&nbsp; я пропускал матан, в достаточно мере что бы их не знать :) <br />&lt;xmvlad&gt; 1. линейное пространство <br />&lt;xmvlad&gt; в общем линейным пространством является все что угодно удовлетворяющее следующим аксиомам: <br />&lt;xmvlad&gt; <a href="http://en.wikipedia.org/wiki/Vector_space" rel="nofollow">http://en.wikipedia.org/wiki/Vector_space</a> <br />&lt;xmvlad&gt; 1. ассоциативность сложения векторов то есть (a + b) + c = a + (b + c) <br />&lt;xmvlad&gt; 2. коммутативность a + b = b + a <br />&lt;xmvlad&gt; 3. существования нуля, то есть для каждого элемента v принадлежащему V (векторному пространству) <br />&nbsp; существует элемент z такой что v + z = v <br />&lt;xmvlad&gt; и т.д далее для жаждущих ссылка в википедию <br />&lt;xmvlad&gt; суть в следующим: одним из примеров линейного пространства может являтся функциональное пространство <br />&lt;xmvlad&gt; то есть если мы возьмем множество векторных функций f(x), g(x)... Fi(x), то они так же будут являтся линейным пространством <br />&lt;xmvlad&gt; <a href="http://en.wikipedia.org/wiki/Functional_space" rel="nofollow">http://en.wikipedia.org/wiki/Functional_space</a> <br />&lt;xmvlad&gt; теперь вводим в данном линейном пространстве скалярное произведение <br />&lt;xmvlad&gt; аксиомы скалярного произведения <a href="http://en.wikipedia.org/wiki/Inner_product_space" rel="nofollow">http://en.wikipedia.org/wiki/Inner_product_space</a>, то есть проще говоря <br />&nbsp; это обобщение &quot;геометрического&quot; dot product для линейных пространств <br />&lt;xmvlad&gt; по просьбе cppg: <a href="http://ru.wikipedia.org/wiki/Линейное_пространство" rel="nofollow">http://ru.wikipedia.org/wiki/Линейное_пространство</a> <br />&lt;cppg&gt; добавлю, перевод: <a href="http://ru.wikipedia.org/wiki/Векторное_пространство" rel="nofollow">http://ru.wikipedia.org/wiki/Векторное_пространство</a> <br />&lt;xmvlad&gt; <a href="http://ru.wikipedia.org/wiki/Скалярное_произведение" rel="nofollow">http://ru.wikipedia.org/wiki/Скалярное_произведение</a> <br />&lt;xmvlad&gt; теперь, одна теорема которая нам нужна <br />&lt;xmvlad&gt; Пусть S подпространство в эвклидовом пространстве V, и (e1, ..., ei) ортонормированный базис для S. Если x принадлежит V, тогда элемент s = sum(i = 1, n) (x, ei) * ei - проекция x на S <br />&lt;xmvlad&gt; значит такая теорема: проекция x на S ближе к x (ближе в смысле нормы), чем любой другой элемент принадлежащий S <br />&lt;xmvlad&gt; все, с мутью покончили <br />&lt;xmvlad&gt; значит берем функциональнольно пространство и вводим в нем следующее скалярное произведение: <br />&lt;xmvlad&gt; (f, g) = integral f(x) * g(x) dx <br />&lt;xmvlad&gt; как можно убедится удовлетворяет всем аксиомам для скалярного произведения <br />&lt;xmvlad&gt; базисом этого функционального пространства могут являтся - сферические гармоники <br />&lt;xmvlad&gt; сферические гармоники принадлежат к семейству ортогональных полиномов <br />&lt;xmvlad&gt; то есть, (f, g) = 0 если f != g, и (f, f) = 1 <br />&lt;xmvlad&gt; SH(spherical harmonics) задаются на поверхности сферы, то есть x = f(a, b), где a,b - сферические <br />&nbsp; координаты некоторой точки на поверхности сферы <br />&lt;xmvlad&gt; тогда, любую функцию заданную на поверхности сферы мы можем задать линейной комбинацией базисных <br />&nbsp; функций, то есть <br />&lt;xmvlad&gt; f_aprox(a, b) = s0 * y1 + s1 * y1 + s2 * y2 + .. + si * yi <br />&lt;xmvlad&gt; если мы берем конечное число гармоник, то есть &quot;обрезаем&quot; высокие частоты мы получаем лишь некоторую <br />&nbsp; апроксимацию <br />&lt;xmvlad&gt; наша f_aprox и будет проекцией f (элемента функционального пространства) в базис SH <br />&lt;xmvlad&gt; при этом в соответствии с теоремой, эта проекция является наилучшим приближением f в базисе SH <br />&lt;xmvlad&gt; проще говоря, что нам надо - посчитать s0.. si, для этого в соответсвии с определением проецируем f на <br />&nbsp; базис SH, то есть считаем si = (f, yi)&nbsp; для i = 0..n <br />&lt;xmvlad&gt; или по нашему определению скалярного умножения si = интеграл по поверхности сферы (f(s) * yi(s)) ds <br />&lt;xmvlad&gt; зная si, мы можем восстановить нашу функцию f, некоторую апроксимацию, выше написана формула <br />&lt;xmvlad&gt; но это не главное <br />&lt;xmvlad&gt; если у нас есть две функции f и g, которые мы спроецировали в базис SH тогда <br />&lt;xmvlad&gt; в силу ортогональности базисных функций то есть все термы i != g равны 0, остальные i = i, 1 <br />&lt;xmvlad&gt; интеграл по поверхности сферы f(s) * g(s) ds = fs0 * gs0 + fs1 * gs1 + .. + fsi * gsi <br />&lt;xmvlad&gt; то есть просто дот продукт коэффициентов <br />&lt;xmvlad&gt; как это обычно используют <br />&lt;xmvlad&gt; возьмем меш, зададим вокруг каждой вершины функцию f(s), если c направления s - приходит лучик, f(s) <br />&nbsp; == 1 если нет f(s) == 0 <br />&lt;xmvlad&gt; то есть задаем для каждой вершины объекта oclussion для всех возможных направлений (поверхность сферы) <br />&lt;xmvlad&gt; вторая функция, g, задает &quot;источник освещения&quot;, то же самое только для каждого направления s g(s) == 1 <br />&nbsp; есть лучик g(s)== 0 нет лучика <br />&lt;xmvlad&gt; теперь если взять интеграл по поверхности сферы произведения этих двух функий f и g, получим <br />&nbsp; количество освещения достигающего вершину <br />&lt;xmvlad&gt; а интеграл это всего лишь дот продукт как было выше расписано <br />&lt;xmvlad&gt; таким образом считаем во время препроцессинга повершинно f <br />&lt;xmvlad&gt; раз в кадр считаем проекцию освещения в SH базис - g, а затем в шейдере - дот продукт - количестов <br />&nbsp; освещения (интеграл по поверхности сферы) <li>DobroKOT всё про разложение понял, дальше как это применяется для освещения втыкает.</li> <br />&lt;DobroKOT&gt; xmvlad, что такое f? <br />&lt;DobroKOT&gt; каким освещением рисовать пиксель на экране? <li>DobroKOT тупит, наверное...</li> <br />&lt;DobroKOT&gt; воть хочу блинна, например... <br />&lt;DobroKOT&gt; сорри, away, метро закрывается в час. <br />&lt;xmvlad&gt; DobroKOT: f - освещение <br />&lt;xmvlad&gt; то есть если хочется цветного их должно быть три штуки :) <br />&lt;xmvlad&gt; DobroKOT: освещение повершинное <br />&lt;xmvlad&gt; учитывается только диффузная составляющая (интеграл по поверхности сферы) без спекуляра <br />&lt;xmvlad&gt; но суть в том что f - можно поретрейсить и закодить туда self-shadowing от объекта <br />&lt;DobroKOT&gt; xmvlad, я что-то не понимаю. <br />&lt;xmvlad&gt; да что я забыл сказать, там где было про проецирование в базис, интеграл, можно посчитать и аналитически (если функция простая) или при помощи монте-карло (рейтрейсинг по сцене) <br />&lt;xmvlad&gt; DobroKOT: говори что %) <br />&lt;DobroKOT&gt; почему нельзя в offline тупо посчитать освещённость? <br />&lt;DobroKOT&gt; каждой вершины? <br />&lt;DobroKOT&gt; тупо lightmap ? <br />&lt;DobroKOT&gt; что дают SH ? <br />&lt;xmvlad&gt; смотри <br />&lt;Zeux&gt; DobroKOT, освещенность относительно статического источника? <br />&lt;DobroKOT&gt; если &quot;учитывается только диффузная составляющая&quot; <br />&lt;xmvlad&gt; одну часть f - мы считаем в офлайне повершинно - это локальный occlusion или вобще что угодно <br />&lt;xmvlad&gt; вторую часть g - мы можем посчитать покадрово, освещение то есть <br />&lt;xmvlad&gt; а затем в шейдере уже посчитать интеграл по поверхности сферы произведения этих функций - дот продуктом <br />&lt;xmvlad&gt; при этом g у нас будет не повершинно а для всего объекта <br />&lt;DobroKOT&gt; что такое oclusion для уровня типа quake1 ? ведь любая точка в этом уровне - внутри уровня? <br />&lt;DobroKOT&gt; f - это что? <li>dR|drunk is now known as dR|phone</li> <br />&lt;xmvlad&gt; DobrKOT: occlusion для некоторого объекта :) <br />&lt;xmvlad&gt; f - это функция на поверхности сферы, то есть проекция в SH <br />&lt;DobroKOT&gt; что такое f? <br />&lt;DobroKOT&gt; если считать что гармоник нет, (бесконечная точность и тп) как она используется для освещения? <br />&lt;xmvlad&gt; DobroKOT: функция заданная на поверхности сферы, occlusion то есть <br />&lt;xmvlad&gt; повершинно <br />&lt;DobroKOT&gt; на выпуклом объекте oclusion везде будет - полусфера? <br />&lt;DobroKOT&gt; точнее, сфера с одним полушарием - 1, и вторым - 0 ? <br />&lt;xmvlad&gt; DobroKOT: ага <br />&lt;DobroKOT&gt; а это же дико разрывная функция. <br />&lt;DobroKOT&gt; она хорошо приближается гармониками? <br />&lt;xmvlad&gt; но с оклюжен это простейший случай, можно закодировать что угодно, любую функцию освещения %) <br />&lt;xmvlad&gt; DobroKOT: ну дык будут &quot;мягкие тени&quot; =) вобще нужен препроцессинг, вроде размытия гаусом <br />&lt;DobroKOT&gt; как полагается считать f для замкнутого уровня типа кваки? <br />&lt;xmvlad&gt; не, я имеле ввиду, что считать надо для объекта какого-нить <br />&lt;xmvlad&gt; то есть для области внутри которой не будет источника света <br />&lt;DobroKOT&gt; хорошо, умеем считать интеграл в шейдере быстро и приближённо. <br />&lt;DobroKOT&gt; а как задаётся g ? <br />&lt;DobroKOT&gt; вообще как задаются источнки света в этом методе? <br />&lt;xmvlad&gt; а g как хочеш считай =) но суть в том что это опять же функция на поверхности сферы <br />&lt;DobroKOT&gt; ну вот пусть два точечных источника... <br />&lt;DobroKOT&gt; ага, в каждой вершине можно задать как dot(n, l1) + dot(n, l2) ... <br />&lt;xmvlad&gt; DobroKOT: нет :) <br />&lt;DobroKOT&gt; а как? <br />&lt;xmvlad&gt; мы сразу все освещение проецируем в базис SH <br />&lt;DobroKOT&gt; g - одна на все вершины? <br />&lt;xmvlad&gt; ага <br />&lt;xmvlad&gt; и поэтому фейк :) <br />&lt;DobroKOT&gt; ага, тогда n можно подставить как точку сферы. <li>DobroKOT не понимает, как метод который не может осветить кубическую комнату с одним точечным источником света является супер-методом.</li> <br />&lt;DobroKOT&gt; а почему он крутой? <br />&lt;DobroKOT&gt; что он позволяет? <br />&lt;xmvlad&gt; DobroKOT: да он говно, просто этого никто не знает =) <br />&lt;DobroKOT&gt; неее! <br />&lt;DobroKOT&gt; сначала скажи почему хороший. <br />&lt;DobroKOT&gt; вот я туплю и не понимаю, для чего его применять. <br />&lt;DobroKOT&gt; а, типа g можно сделать&nbsp; сложной, да? <br />&lt;xmvlad&gt; DobroKOT: да <br />&lt;xmvlad&gt; да для любого динамического освещения только фейковым оно будет <br />&lt;xmvlad&gt; то есть вопрос в том - на сколько это будет фейково</p><p><a href="http://www.gamedev.ru/community/gamedev_lecture/articles/sh?page=2">Продолжение</a></p> http://www.gamedev.ru/community/gamedev_lecture/blog/?id=776 Thu, 01 Jun 2006 21:15:04 GMT http://www.gamedev.ru/community/gamedev_lecture/blog/?id=776 <p>Выложен лог прошедшей лекции <a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=29">Постмортем игры &quot;Трюкмания&quot;</a> (лектор - <b>Jihar</b>).</p> http://www.gamedev.ru/community/gamedev_lecture/articles/?id=775 Thu, 01 Jun 2006 20:57:07 GMT http://www.gamedev.ru/community/gamedev_lecture/articles/?id=775 http://www.gamedev.ru/community/gamedev_lecture/forum/?id=1199 <p>Disclaimer: некоторые опечатки поправлены, некоторые реплики передвинуты. <a href="http://www.everfall.com/paste/id.php?jefbf12tw82s">полный лог</a></p> <p>[21:40] &lt;Jihar_&gt; ок. меня кличут Жихарь, работаю в фирме KVision <br />[21:40] &lt;Jihar_&gt; не так давно мы закончили свой первый проект - Трюкмания : гонки экстремалов, издатель Акелла <br />[21:41] &lt;Jihar_&gt; игра - аркадные гонки в абстрактном городе <br />[21:41] &lt;Jihar_&gt; разработка велась примерно 3 года, из них почти 2 с моим участием <br />[21:42] &lt;Jihar_&gt; движок - свой, написанный можно сказать с нуля <br />[21:42] &lt;Jihar_&gt; когда я пришел работать в фирму, костяк уже был готов <br />[21:42] &lt;Jihar_&gt; я думаю интересно будет именно программная часть? <br />[21:43] &lt;Jihar_&gt; ошибок у нас было много, первый проект все таки...</p> <p>[21:43] &lt;Jihar_&gt; итак, самое главное <br />[21:43] &lt;Jihar_&gt; постановка задач. это примерно 90% успеха и от этого зависит скорость разработки <br />[21:44] &lt;Jihar_&gt; приведу пример - была у меня задача, написать утилитку для артистов, аля артист менеджер для удобной работы <br />[21:44] &lt;Jihar_&gt; те чтобы она могда выгрузить модель\статику в наш формат, сконвертить текстуры, также конвертить пачку моделей\миров <br />[21:45] &lt;Jihar_&gt; затем стали добавляться фичи - проверки текстур например (есть ли одинаковые текстуры с разными именами, миррор\скейл) <br />[21:46] &lt;Jihar_&gt; таких фич захотелось очень много, в результате сейчас эта утилита хоть и работает, но улучшать ее очень сложно <br />[21:46] &lt;Jihar_&gt; надеюсь мысль понятна - когда пишешь для себя, сроки разработки не сильно волнуют <br />[21:47] &lt;Jihar_&gt; когда пишешь с учетом сроков - лучше периодически (когда еще не поздно) тратить время на рефакторинг, это время очень быстро окупится <br />[21:47] &lt;Jihar_&gt; прописные истины, да. но как всегда про такие истины и забывают...</p> <p>[21:50] &lt;Jihar_&gt; проект на самом деле очень технологичный. изначально в игре было больше фич (фичекат подлый), и сейчас база очень солидная <br />[21:50] &lt;Jihar_&gt; процесс достаточно обычно у нас построен - есть база (в трюкмании ВСС, сейчас свн) <br />[21:50] &lt;Jihar_&gt; коменты - доксиген стайл, свой стиль кодирования <br />[21:51] &lt;Jihar_&gt; пробовали кучу различных таск трекеров, баг трекеров итд, до сих пор находимся в поиске идеального решения</p> <p>[21:53] &lt;xmvlad&gt; тулсет свой был или в максе? <br />[21:53] &lt;Jihar_&gt; тулсет на самом деле достаточно разнообразный <br />[21:54] &lt;Jihar_&gt; например расставить модельки в мире - можно их расставить в максе, при выгрузке плагин выцепит модельки отдельно. можно расстаивть модельки в движке</p> <p>[21:54] &lt;kas&gt; можешь про арт пайплайн рассказать, коль уж о тулсете заговорили? <br />[21:54] &lt;kas&gt; т.е. путь от набота триуглов в максе до модельки в игре <br />[21:54] &lt;Jihar_&gt; осноной пакет - 3ds max <br />[21:55] &lt;Jihar_&gt; есть возможность юзать и майю <br />[21:55] &lt;Jihar_&gt; значит модели, миры проходят через плагины к этим программам. сейчас это практически монстры - встроено большое количество проверок геометрии <br />[21:56] &lt;Jihar_&gt; миры после выгрузки из DCC проходят доп обработку - расчет лайтмепов <br />[21:56] &lt;Jihar_&gt; эту доп обработку можно запустить и при выгрзуке из DCC <br />[21:57] &lt;Jihar_&gt; ну те старались все автоматизировать, чтобы не сильно напрягать моделлеров. в том числе и проверки для этого - достаточно просто артисты находят различные ошибки в геометрии, некоторые советы по оптимизации моделей <br />[21:58] &lt;Jihar_&gt; для своих форматов есть различные утилиты - например для моделей редактор моделей - отредактить какие-то свойства, поиграться с цветами итд итп (это же можно делать и в плагине для DCC)</p> <p>[21:58] &lt;kas&gt; ето один мегаридактор? или несколько маленьких? <br />[21:59] &lt;Jihar_&gt; можно сказать это сборная солянка - т.е. часть возможностей есть и в виде отдельных утилит, они же доступны из плагиноы <br />[21:59] &lt;Jihar_&gt; те артист настраивает модельку, она ушла в производство. чтобы затем изменить какие-то игровые свой-ва не надо ее выгружать заново <br />[22:00] &lt;Jihar_&gt; в том же редакторе моделей настраиваются машины. с физикой куча наворотов конечно. например расчет экспериментов - после настройки можно посмотреть графики (начиная с бангальных разгон до 100 км\ч) <br />[22:01] &lt;Jihar_&gt; есть те же тесты физики - их куча на самом деле, проверяющих различные параметры. те разгон до 100 км\ч - берем значение теоретическое, ставим машину на землю и смотрим за сколько она реально разгоняется. сравниваем.. так тестятся почти все параметры физики (а их у нас много:))</p> <p>[22:01] &lt;kas&gt; физика своя? <br />[22:01] &lt;Jihar_&gt; физика полностью своя, да</p> <p>[22:02] &lt;Jihar_&gt; редаткора миров своего нету (те возможность создания геометрии в своей тулзе) <br />[22:03] &lt;Jihar_&gt; но есть различные вспомогательные утилиты - для расстановки моделей например, редактирования карт АИ</p> <p>[22:02] &lt;kas&gt; а сколько кодеров было и как они распределены были? <br />[22:03] &lt;Jihar_&gt; кодеров - по разному в разное время <br />[22:03] &lt;Jihar_&gt; закончили проект - нас было трое, один на физике и рендере в основном, второй на аи, и третий я :)</p> <p>[22:04] &lt;kas&gt; а гейдизайнеров/дизайнеров? <br />[22:04] &lt;Jihar_&gt; геймдизайнер один, артистов до 20 человек было <br />[22:05] &lt;Jihar_&gt; текучка артистов большая была, т.к. найти профи в твери сложновато (да и програмеров тоже, как и всех остальных) <br />[22:05] &lt;Jihar_&gt; поэтому артистов учили по несколько месяцев, смотрели что получается ну итд <br />[22:05] &lt;Jihar_&gt; некоторые артисты работают сейчас в москве :)</p> <p>[22:06] &lt;kas&gt; расскажи про интероп <br />[22:07] &lt;kas&gt; ну, т.е. как от гейдизайнера доходило до простого негра, процесс <br />[22:08] &lt;Jihar_&gt; ну это итеративный процесс <br />[22:08] &lt;Jihar_&gt; есть задание - делаем трек, такие-то параметры <br />[22:08] &lt;Jihar_&gt; сначала делается чертеж трека с дорогами, зданиями итд <br />[22:08] &lt;Jihar_&gt; после нескольких итераций этот чертеж утверждается, попадает в разработку моделлеру <br />[22:09] &lt;Jihar_&gt; моделлер собсно моделит статику - те дороги, здания <br />[22:09] &lt;Jihar_&gt; затем этот тре подвергается заселению моделями <br />[22:10] &lt;Jihar_&gt; на всех этапах само собой есть влияние геймдизайнера - те что надо поправить, что не так <br />[22:10] &lt;Jihar_&gt; где не удобно гонять к примеру <br />[22:10] &lt;Jihar_&gt; несколько треков (на мой взгляд интереных) не попали в игру - сложно гонять на них было, обычному игроку не понравилось бы <br />[22:11] &lt;Jihar_&gt; по трекам создавались списки нужных зданий\моделей само собой, на этом этапе мог подключаться другой моделлер <br />[22:11] &lt;Jihar_&gt; практиковали разработку треков по кускам - те один делает этот кусок, другой этот <br />[22:11] &lt;Jihar_&gt; но очень сложно - различается все-таки стиль, не просто потом это объединять, в текущем проекте один трек делает один артист практически на 100%</p> <p>[22:11] &lt;kas&gt; а как ето всё разруливалось? <br />[22:11] &lt;kas&gt; т.е. не было генерального плана у каждого на весь проект? <br />[22:11] &lt;kas&gt; а по мере необходимости? <br />[22:12] &lt;Jihar_&gt; про генеральный план артистов сложно сказать, думаю он часто корректировался :) <br />[22:12] &lt;Jihar_&gt; появлялись затыки само собой перидически, переброска людей на узкие места итд <br />[22:13] &lt;Jihar_&gt; разруливолась не так просто как кажется конечно... количество арта у нас было очень большое <br />[22:13] &lt;Jihar_&gt; и с каждым днем все больше :) <br />[22:14] &lt;Jihar_&gt; были люди, которые отвечали за арт. не за его создание, а за его обработку <br />[22:14] &lt;Jihar_&gt; они можно сказать одобряли арт с технической точки зрения и поддерживали общую базу арта в нужном виде</p> <p>[22:14] &lt;kas&gt; а очень большое ето сколько? икак контролировали? под вершионингом лежало? <br />[22:15] &lt;Jihar_&gt; под вершионингом не лежало, артисты мутили это сами (сейчас пытаемся научить черепахе) <br />[22:15] &lt;Jihar_&gt; очень большое - несколько тысяч моделей, несколько тысяч текстур <br />[22:15] &lt;Jihar_&gt; больше десяти :)</p> <p>[22:15] &lt;neteraser&gt; Jihar: какие были нововведения в девпроцессе и чем обусловлены? <br />[22:16] &lt;Jihar_&gt; нововведения периодически появлялись, да. в основном подстройка под людей <br />[22:15] &lt;Jihar_&gt; те изначальная схема была слишком строгой, ее постоянно ослабляли для комфорта людей</p> <p>[22:15] &lt;neteraser&gt; Jihar: физика чисто игровая ? <br />[22:16] &lt;Jihar_&gt; физика - что значит чисто игровая? <br />[22:17] &lt;Jihar_&gt; физика машины у нас проработана почти до болтиков</p> <p>[22:17] &lt;neteraser&gt; сколько у вас кода ушло? будете выкидывать или мигрировать? <br />[22:18] &lt;Jihar_&gt; кода чисто специфичного не так уж и много <br />[22:18] &lt;Jihar_&gt; специфичного м\именно для трюкмании, а не для гонок <br />[22:18] &lt;Jihar_&gt; сейчас как раз глобальный рефакторинг у нас <br />[22:19] &lt;Jihar_&gt; некоторые системы не будутзатрагиваться (например рендер), некоторые с нуля переписаны, некоторые разбиты на части <br />[22:19] &lt;Jihar_&gt; например класс СМашина у нас очень толстый <br />[22:19] &lt;neteraser&gt; а CCamera? <br />[22:21] &lt;Jihar_&gt; классы камер разбиты достаточно хорошо <br />[22:21] &lt;Jihar_&gt; тем более различных камер куча <br />[22:21] &lt;Jihar_&gt; разные камеры в движке (аля полетать), в встроенных утилитах, камера машины другая <br />[22:21] &lt;Jihar_&gt; динаические камеры на треках - тоже другие</p> <p>[22:19] &lt;neteraser&gt; сколько всего кода в мб и миллионовстрок? <br />[22:20] &lt;Jihar_&gt; код в метрах щас померю <br />[22:20] &lt;Jihar_&gt; всего 14 метров чисто игрового кода <br />[22:20] &lt;Jihar_&gt; без учета утилит <br />[22:21] &lt;neteraser&gt; немало</p><p><a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=775&amp;page=2">Продолжение</a></p> http://www.gamedev.ru/community/gamedev_lecture/articles/?id=761 Sat, 13 May 2006 17:01:21 GMT http://www.gamedev.ru/community/gamedev_lecture/articles/?id=761 http://www.gamedev.ru/community/gamedev_lecture/forum/?id=128676 <p>Disclaimer: некоторые опечатки поправлены. <a href="http://www.everfall.com/paste/id.php?dtxqn5vywyrb">полный лог</a></p> <p>[23:04:58] &lt;coolace&gt; значит захотелось как то раз GUI сделать 1 раз и так чтобы его юзать везде <br />[23:05:52] &lt;coolace&gt; для этого нужно было придумать как например не париться с внедрением новых контролов в редактор будующий <br />[23:06:42] &lt;coolace&gt; вобщем нужен был рефлекшн новых контролов <br />[23:07:33] &lt;coolace&gt; для этого сделана была система свойств, с которыми контрол работет и может предоставлять их полный список <br />[23:08:18] &lt;coolace&gt; с именами и типами чтобы в редакторе автоматически заполнять панель редактирования выбранного контрола <br />[23:09:10] &lt;coolace&gt; причем сам контрол для своих вычислений использует те же самые свойства <br />[23:09:55] &lt;coolace&gt; свойства добавляются динамически в вектор и потом по имени можно его получить <br />[23:10:49] &lt;coolace&gt; не особо это хорошо можно переделать, но пока так суть в том чтобы все свойства контрола <br />[23:11:32] &lt;coolace&gt; не какие то промежуточные состояния а именно то что однозначное его инициализирует рефлектилось <br />[23:13:03] &lt;coolace&gt; значит так же сделаны обработчики событий, те их список тоже можно получить и к каждому привязать пользовательский обработчик <br />[23:14:18] &lt;coolace&gt; пользовательский обработчик это функтор(в макросы обернутый для простоты), который регистрируется в системе и при надобности получается его копия <br />[23:14:44] &lt;coolace&gt; к ней биндятся параметры если они нужны и исполнятся <br />[23:15:39] &lt;coolace&gt; обработка сообщений(событий) состороны контрола состоит из 3х этапов <br />[23:16:00] &lt;coolace&gt; а не рано еще про это :) <br />[23:17:04] &lt;coolace&gt; терминологии не много которую я буду использовать <br />[23:18:16] &lt;coolace&gt; процессор сообщения - функция которая обрабатывает сообщение на низком уровне <br />[23:18:54] &lt;coolace&gt; пример: ProcessClick() <br />[23:20:21] &lt;coolace&gt; обработчик - вирт функция которую можно переопределить если нужно в потомке изменять некие промежуточные данные <br />[23:20:41] &lt;coolace&gt; пример OnClick <br />[23:21:24] &lt;coolace&gt; пользовательский обработчик - то что рулит игрой или тем чем нужно <br />[23:22:11] &lt;coolace&gt; вот значит в принципе промежуточный кровень можно убрать, но иногда удобным оказалось <br />[23:22:23] &lt;coolace&gt; например в кнопках <br />[23:22:39] &lt;coolace&gt; те менять текстуру принаведении <br />[23:23:38] &lt;coolace&gt; процессоры сообщений регистрируются в классе и биндятся к определенным типам сообщений <br />[23:24:29] &lt;coolace&gt; извлекают из них параметры и параметры эти передают пользовательскому и системному обработчику <br />[23:24:55] &lt;coolace&gt; здесь же проводится валидация этих параметров <br />[23:25:09] &lt;coolace&gt; все понятно пока?</p> <p>[23:25:39] &lt;coolace&gt; значит как приходят сообщения.... <br />[23:26:00] &lt;R|lecture&gt; можешь пример простой менюшки (контрола) и обработчика в коде изобразить? было бы понятнее глядя на код, я думаю <br />[23:26:08] &lt;R|lecture&gt; извини, что перебиваю <br />[23:26:27] &lt;coolace&gt; могу щас <br />[23:27:21] &lt;coolace&gt; void DefaultAction::Execute() <br />[23:27:21] &lt;coolace&gt; { <br />[23:27:21] &lt;coolace&gt;&nbsp; ActionParameters::action_parameters_list::const_iterator i; <br />[23:27:21] &lt;coolace&gt;&nbsp; for(i = input_parameters.GetParameters().begin(); i != input_parameters.GetParameters().end(); ++i) <br />[23:27:21] &lt;coolace&gt;&nbsp; { <br />[23:27:22] &lt;coolace&gt;&nbsp; &nbsp; if (i-&gt;name == &quot;action_name&quot;) <br />[23:27:24] &lt;coolace&gt;&nbsp; &nbsp; { <br />[23:27:26] &lt;coolace&gt;&nbsp; &nbsp; &nbsp; std::string report_string = &quot;Не найден обработчик с именем: &quot; + boost::get&lt;std::string&gt;(i-&gt;value); <br />[23:27:28] &lt;coolace&gt;&nbsp; &nbsp; &nbsp; GUI_LOG_2(&quot;DefaultAction::Execute(): &quot;, report_string); <br />[23:27:30] &lt;coolace&gt;&nbsp; &nbsp; } <br />[23:27:32] &lt;coolace&gt;&nbsp; } <br />[23:27:34] &lt;coolace&gt; } <br />[23:27:38] &lt;R|lecture&gt; лучше было, конечно, в everfall.com/paste <br />[23:27:49] &lt;coolace&gt; понимаю :) <br />[23:27:57] &lt;coolace&gt; щас <br />[23:30:37] &lt;coolace&gt; <a href="http://www.everfall.com/paste/id.php?iq2qece9qm09">http://www.everfall.com/paste/id.php?iq2qece9qm09</a> <br />[23:30:46] &lt;coolace&gt; во разобрался <br />[23:32:17] &lt;coolace&gt; значит там лежит код пользовательского обработчика типа открывающего окно, он нигде не используется ибо код устарел но выглядит это именно так <br />[23:32:57] &lt;coolace&gt; в качестве тела такой вещи пишется любой пользовательский код вобщем <br />[23:33:13] &lt;coolace&gt; все это оформляем в макрос <br />[23:33:36] &lt;coolace&gt; для компактности так сказать <br />[23:34:24] &lt;coolace&gt; вот на чем я остановился <br />[23:36:12] &lt;coolace&gt; так вот приходят сообщения <br />[23:37:04] &lt;coolace&gt; раньше они передавались по дереву контролов пока не будут обработаны и всплавали <br />[23:37:30] &lt;coolace&gt; контролы организованы как composite <br />[23:37:54] &lt;coolace&gt; пришел к выводу что такой метод передачи лажа полная <br />[23:38:59] &lt;coolace&gt; сейчас все по другому, в случае пользовательского сообщения мы его отправляем по имени либо по указателю <br />[23:39:15] &lt;coolace&gt; имена могут быть не уникальны <br />[23:39:51] &lt;coolace&gt; поэтому иногда лучше по указателю, хотя это доступно только на низком уровне <br />[23:40:21] &lt;coolace&gt; в случае с инпутом все интереснее <br />[23:40:39] &lt;coolace&gt; мы их отправляем &quot;по координатам&quot; :) <br />[23:41:25] &lt;coolace&gt; конечно не прямо так, а находим самый верхний приемщик инпута и ему по указателю флем сообщение <br />[23:42:16] &lt;coolace&gt; это можно кешировать так что время приема сообщения именно тем кто его должет принять станет константным <br />[23:43:10] &lt;coolace&gt; раньше сообщения были асинхронными те складывались в очередь а потом вся очередь обрабатывалась <br />[23:43:38] &lt;coolace&gt; опыт показал что лажа это... <br />[23:44:05] &lt;coolace&gt; непонятно откуда пришло битое сообщение например <br />[23:44:30] &lt;coolace&gt; вот теперь сообщения синхронны <br />[23:44:48] &lt;coolace&gt; обрабатывается сразу после закрытия <br />[23:45:27] &lt;coolace&gt; и записывать их можно а потом проигрывать <br />[23:45:36] &lt;coolace&gt; так же как и раньше <br />[23:46:18] &lt;coolace&gt; + временные задержки равномерно распределены а не так что пришло 1000 сообщений и игра подвисла <br />[23:46:35] &lt;coolace&gt; только из за цикла :)</p> <p>[23:47:23] &lt;coolace&gt; вопросы по поводу сообщений есть? я щас код покажу <br />[23:49:53] &lt;coolace&gt; <a href="http://www.everfall.com/paste/id.php?6o6fceispxkz">http://www.everfall.com/paste/id.php?6o6fceispxkz</a> <br />[23:49:57] &lt;coolace&gt; вот пример <br />[23:51:43] &lt;coolace&gt; это на самом деле обернутое сообщение на изменение свойств <br />[23:52:02] &lt;coolace&gt; но смысл всегда такой же <br />[23:52:43] &lt;coolace&gt; те открыли сообщение - набили его параметрами - закрыли сообщение <br />[23:53:18] &lt;coolace&gt; в момент закрытия оно обрабатывается <br />[23:54:11] &lt;coolace&gt; <a href="http://www.everfall.com/paste/id.php?kw5zqcvfw11b">http://www.everfall.com/paste/id.php?kw5zqcvfw11b</a> <br />[23:54:27] &lt;coolace&gt; это сообщение от мыши в чистом виде <br />[23:55:20] &lt;coolace&gt; пауза 3 мин перекур, дальше про свойства подробно</p> <p>[23:55:44] &lt;Zeux&gt; вопросы, пожелания <br />[23:58:05] &lt;coolace&gt; ну если нет вопосов то продолжаем <br />[23:59:30] &lt;coolace&gt; свойства содержит в себе значение, имя, и связи с другими свойствами других контролов <br />[00:00:30] &lt;coolace&gt; с именем и значением все понятно, а вот зачем нужны связи и динамическое добавление совйств хотябы в редакторе рассморю подробно <br />[23:57:14] &lt;coolace&gt; значит классическая проблема всех систем с которыми я работал до этого (3 штуки) <br />[23:57:58] &lt;coolace&gt; это то что программисту игровому нужно знать тип контрола и метод для задания того или иного параметра <br />[23:59:16] &lt;coolace&gt; а это значит тесное переплетение вобщем то низкоуровнего кода GUI в стиле FindContol(&quot;label_armor&quot;)-&gt;SetCaption(armor) <br />[23:59:40] &lt;coolace&gt; с игровым <br />[00:00:07] &lt;coolace&gt; вот чтобы решить проблему сделал так <br />[00:00:40] &lt;coolace&gt; в данном примере еще и имя окна надо знать <br />[00:02:24] &lt;coolace&gt; в моем случае тоже имя окна и имя свойства которое представляет собой игровой термин добавляется и связывается с низкоуровневым именетм свойства конкретного контрола ужее в редакторе <br />[00:03:21] &lt;coolace&gt; можно написать его описание и генерить документацию и код полной поддержки окна останется только параметры передать и все <br />[00:04:23] &lt;coolace&gt; они сами попадут куда нужно, а куда нужно может меняться часто и меняет это сборщик окон без какого бы то нибыло вмешательства программиста <br />[00:04:43] &lt;coolace&gt; главное чтобы имена и типы совпадали <br />[00:05:13] &lt;coolace&gt; хотя типы могут и не совпадать а связь идти через какой либо фильтрл <br />[00:07:20] &lt;coolace&gt; вот пример сгенереного кода <br />[00:07:21] &lt;coolace&gt; <a href="http://www.everfall.com/paste/id.php?015r8okp7m88">http://www.everfall.com/paste/id.php?015r8okp7m88</a> <br />[00:08:21] &lt;coolace&gt; это облегчило жизнь просто охренеть как если честно <br />[00:08:56] &lt;coolace&gt; еще больше облегчило жизнь когда это заработало в связке с шаблонами <br />[00:09:27] &lt;coolace&gt; шаблон - готовая сборка компонент которая много где используется <br />[00:10:05] &lt;coolace&gt; те у шаблона есть связанные свойства с его внутренними компонентами, которые тоже могут быть шаблонами <br />[00:10:26] &lt;coolace&gt; и свзь может быть с из связанными свойствами :) <br />[00:10:56] &lt;coolace&gt; все это в конечном итоге выводится в свойства окна <br />[00:11:43] &lt;coolace&gt; про шаблоны интересно послушать или и так все ясно? <br />[00:13:36] &lt;coolace&gt; ладно пока расскажу про абстрагирование от движка и локализацию, потом про шаблоны если кого заинтересует <br />[00:14:56] &lt;coolace&gt; значит абстрагирование это нужно понятно зачем... вобщем хотел вытянуть из прошлого проекта некий код гуя и понял что это невозможно из за дикого переплетения <br />[00:15:13] &lt;coolace&gt; его с низкоуровневым кодом рендера и инпута <br />[00:15:38] &lt;coolace&gt; значит абстрагироваться решил так.. <br />[00:15:52] &lt;coolace&gt; паттерн bridge <br />[00:16:35] &lt;coolace&gt; + пустые реализации интерфейсов задаваемые по умолчанию <br />[00:17:07] &lt;coolace&gt; для того чтобы если вдруг нету звуковой реализации то подсовывалать пустышка</p><p><a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=761&amp;page=2">Продолжение</a></p> http://www.gamedev.ru/community/gamedev_lecture/blog/?id=736 Wed, 26 Apr 2006 13:32:26 GMT http://www.gamedev.ru/community/gamedev_lecture/blog/?id=736 <p>Выложены логи двух прошедших недавно лекций.</p> <p>* <a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=26">Реализация физики на основе интегрирования Верлета</a> (Лекторы - <b>new</b>, <b>Joric</b>) <li><a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=27">GUI</a> (Лектор - <b>Sark7</b>)</p></li> http://www.gamedev.ru/community/gamedev_lecture/articles/?id=735 Wed, 26 Apr 2006 13:28:49 GMT http://www.gamedev.ru/community/gamedev_lecture/articles/?id=735 http://www.gamedev.ru/community/gamedev_lecture/forum/?id=1154 <p>Disclaimer: некоторые опечатки поправлены, некоторые реплики передвинуты. <a href="http://www.everfall.com/paste/id.php?6vj3j70yuki0">полный лог</a></p> <p>[13:42] &lt;Sark7&gt; значецо, хотим мы гуи <br />[13:43] &lt;Sark7&gt; и чтобы ексендабельный был <br />[13:43] &lt;Sark7&gt; и чтобы по возможности как можно более кроссплатформенный/апи <br />[13:43] &lt;Sark7&gt; не в смысле работать на всех платформах, а уменьшить зависимость от апи/системы <br />[13:43] &lt;Sark7&gt; первое что приходит в голову <br />[13:44] &lt;Sark7&gt; это html <br />[13:44] &lt;Sark7&gt; ну и xml в той же степени <br />[13:44] &lt;Sark7&gt; на самом деле, это единственно реальный вариант <br />[13:44] &lt;Sark7&gt; и адобе, и мозилла, и мс это понимают, поэтому предложили свои варианты gui markup langs <br />[13:45] &lt;Sark7&gt; причина этого <br />[13:45] &lt;Sark7&gt; что абсолютный (ручной) лайоут контролов - зло <br />[13:45] &lt;Sark7&gt; абсолютное <br />[13:45] &lt;Sark7&gt; слишком многое надо учесть чтобы такой лайоут нормально работал на всех разрешениях, dpi, шрифтах итд <br />[13:46] &lt;Sark7&gt; мне вот лично очень понравился SWT <br />[13:46] &lt;Sark7&gt; это такая gui библиотека для явы в eclipse <br />[13:46] &lt;Sark7&gt; я брал ее за основу <br />[13:46] &lt;Sark7&gt; итак <br />[13:46] &lt;Sark7&gt; есть контрол <br />[13:47] &lt;Sark7&gt; у него есть методы Layout() и Draw(UIRenderer& renderer) <br />[13:47] &lt;Sark7&gt; события рассмотрим позже <br />[13:47] &lt;Sark7&gt; в контроле Layout() ничего не делает <br />[13:47] &lt;Sark7&gt; как и Draw <br />[13:48] &lt;Sark7&gt; есть контейнер <br />[13:48] &lt;Sark7&gt; наследуется от контрола, и их хранит <br />[13:48] &lt;Sark7&gt; у него Layout() выполняет работу по расстановке контролов <br />[13:49] &lt;Sark7&gt; это так сказать база <br />[13:49] &lt;Sark7&gt; что такое UIRenderer <br />[13:50] &lt;Sark7&gt; у него есть методы по отрисовке основных виджетов и графических примитивов <br />[13:50] &lt;Sark7&gt; чтобы когда мы захотели поменять стиль контролов, нам пришлось бы только сменить рендерер <br />[13:50] &lt;Sark7&gt; есть Window который наследуется от контейнера <br />[13:51] &lt;Sark7&gt; он как раз и выполняет основную работу <br />[13:51] &lt;Sark7&gt; и посылает нужным контролам сообщения <br />[13:52] &lt;Sark7&gt; идеальная модель для сообщений - это event sinking/bubbling <br />[13:52] &lt;Sark7&gt; т.е. сначала событие как бы тонет <br />[13:52] &lt;Sark7&gt; т.е. идет от парента к чайлду <br />[13:53] &lt;Sark7&gt; на этом этапе парент может обработать его и далее оно тонуть не будет <br />[13:53] &lt;Sark7&gt; после того как событие достигло дна <br />[13:53] &lt;Sark7&gt; т.е. собственно таргет контрола для которого событие предназначалось <br />[13:53] &lt;Sark7&gt; оно начинает всплывать <br />[13:54] &lt;Sark7&gt; и идет от чайлда к паренту <br />[13:54] &lt;Sark7&gt; на этом этапе, если событие пришло к паренту, он знает, что никакой из чайлдов его не обработал <br />[13:55] &lt;Sark7&gt; и может действовать соответственно <br />[13:55] &lt;Sark7&gt; сообщения я лично разделил на три категории <br />[13:56] &lt;Sark7&gt; MouseEvent, KeyEvent и CommandEvent <br />[13:56] &lt;Sark7&gt; ну из названий понятно что они делают ) <br />[13:56] &lt;Sark7&gt; соотв. в контроле имеется три методы on(MouseEvent&), on(KeyEvent)&, on(CommandEvent&) <br />[13:56] &lt;Sark7&gt; это базисные <br />[13:57] &lt;Sark7&gt; ладно, может кто чо спросить хочет )</p> <p>[13:58] &lt;Anubis|tea&gt; про евенты понятно... не понял самое начало правда <br />[13:58] &lt;Anubis|tea&gt; про маркап <br />[13:58] &lt;Anubis|tea&gt; чем он помогает от ручного лэйаута... и какой он тогда, если не ручной <br />[13:59] &lt;Sark7&gt; он автоматический</p> <p>[13:58] &lt;Sark7&gt; такая модель гуи легко переносится на data-driven <br />[13:59] &lt;Sark7&gt; в этом пойнт</p> <p>[13:59] &lt;cppg&gt; да, кто контролы двигает? <br />[13:59] &lt;Sark7&gt; у контролов есть стиль <br />[13:59] &lt;Sark7&gt; это как css стиль у элемента в html <br />[13:59] &lt;Sark7&gt; он определяет как контрол будет позиционироваться в контейнере <br />[14:00] &lt;Sark7&gt; и вообще его внешний вид <br />[14:00] &lt;Sark7&gt; т.е. его align, font-size, overflow... практически весь css</p> <p>[14:00] &lt;Anubis|tea&gt; а, то есть есть набор контролов, и аффтаматам, как в броузере, определяеццо как он рисоваццо будет?</p> <p>[14:01] &lt;Anubis|tea&gt; гм... а речь о гуи для игр? там ведь дизайнер хочет контролировать все на свете, как, где, что и зачем, каким цветом рисуецца <br />[14:01] &lt;Sark7&gt; что именно ненравицо? <br />[14:01] &lt;Anubis|tea&gt; с точностью до пикселей как будет нарисовано.. или нет? <br />[14:01] &lt;Sark7&gt; веб-дизайнеры все прекрасно контролируют с помощью html/css <br />[14:02] &lt;Zeux&gt; у веб дизайнеров есть опции алигнмента по позиции <br />[14:02] &lt;Zeux&gt; в том самом html/css <br />[14:03] &lt;Sark7&gt; что еще за алигнмент по позиции? ) <br />[14:03] &lt;Zeux&gt; ну, хочу текст в позиции 100, 100 <br />[14:03] &lt;Sark7&gt; ну, есть абсолютное позиционирование конечно <br />[14:03] &lt;Zeux&gt; то что ты называешь абсолютным лейаутом <br />[14:03] &lt;Sark7&gt; и у меня ) <br />[14:03] &lt;Sark7&gt; будет тоже, да <br />[14:04] &lt;Zeux&gt; вопрос в том <br />[14:04] &lt;Zeux&gt; как будет авто лейаут <br />[14:04] &lt;Zeux&gt; сочетаться с абсолютным лейаутом <br />[14:04] &lt;Zeux&gt; и не съедет ли все <br />[14:04] &lt;Sark7&gt; замечательно <br />[14:04] &lt;Sark7&gt; как он в html сочетается <br />[14:05] &lt;Sark7&gt; на самом деле абсолютное позиционирование контрола нужно в очень редких случаях <br />[14:05] &lt;Sark7&gt; лого там нарисовать чтобы висело на месте итд <br />[14:05] &lt;Zeux&gt; в html он сочетается так <br />[14:05] &lt;Zeux&gt; что страницы во всех браузерах выглядят по-разному</p> <p>[14:04] &lt;_Anubis_&gt; ну ладно, проехали :) надо обдумать.. просто я не вижу, почему дизайнерам самим все не расставить на экране. и дать им возможность подрисовать для разных разрешений если где что некрасиво смотрицца. <br />[14:04] &lt;cppg&gt; патамушта разные разрешения надо <br />[14:04] &lt;cppg&gt; любые размеры окна, скажем <br />[14:05] &lt;cppg&gt; имхо надо всё указывать в координатах float 0.0...1.0 и не париться с размерами окон и пикселями <br />[14:05] &lt;_Anubis_&gt; цппг - разрешения вполней фиксированые ведь.. их не много и чаще фсего с фиксированым аспектом <br />[14:05] &lt;Sark7&gt; _Anubis_, размеры окон <br />[14:06] &lt;cppg&gt; _Anubis_, их много во-первых, во-вторых незачем делать десять раз то, что можно сделать один раз <br />[14:06] &lt;_Anubis_&gt; цппг - так я так и имел ввиду, блин <br />[14:06] &lt;_Anubis_&gt; просто при некоторых может там ченить съехать <br />[14:07] &lt;cppg&gt; АА вруби и не сьедет <br />[14:07] &lt;Sark7&gt; как бы оно не сьехало, оно нормально будет выглядеть <br />[14:07] &lt;Sark7&gt; в отличие от ручного лайоута <br />[14:06] &lt;_Anubis_&gt; я имел ввиду дать возможность подправить руками там где не нравицца</p> <p>[14:07] &lt;Zeux&gt; координаты от 0 до 1 - это здорово <br />[14:07] &lt;Zeux&gt; но шрифты масштабировать не стоит <br />[14:07] &lt;Zeux&gt; так что все равно делать кучу шрифтов <br />[14:07] &lt;Zeux&gt; под разные разрешения <br />[14:07] &lt;cppg&gt; текстурные шрифты отлично ложаццо на это <br />[14:07] &lt;Zeux&gt; cppg, если рисовать крупные надписи - ложатся <br />[14:07] &lt;Zeux&gt; если мелкие - нет <br />[14:07] &lt;cppg&gt; ну вруби trilinear? <br />[14:08] &lt;Zeux&gt; ага, и будет все размыто <br />[14:08] &lt;Zeux&gt; т.е. если есть фиксированный размер шрифта <br />[14:08] &lt;Zeux&gt; то можно аккуратно попадать тексель в пиксель <br />[14:08] &lt;Zeux&gt; и делать чтобы можно было читать <br />[14:08] &lt;cppg&gt; ну вапще да <br />[14:08] &lt;cppg&gt; ну для мелких надо отдельный фонт делать, да</p> <p>[14:08] &lt;Sark7&gt; шрифтами управляет UIRenderer... он и выбирает нужный шрифт в зависимости от <br />[14:08] &lt;Sark7&gt; или масштабирует какой есть если нету нужного</p> <p>[14:08] &lt;_Anubis_&gt; не зря же консольный шрифт в кваке той же меняецца по размеру на экране в зависимости от разрешения</p> <p>[14:08] &lt;Zeux&gt; но вообще конечно для каждого разрешения делать раскладку контролов по экрану - это об стену <br />[14:08] &lt;Zeux&gt; правда (!) <br />[14:08] &lt;Zeux&gt; об стену дизайнерам, а не программистам :)</p> <p>[14:09] &lt;Sark7&gt; так <br />[14:09] &lt;Sark7&gt; как происходит собственно отправка событий в Window <br />[14:09] &lt;Sark7&gt; Window приходит сообщение (от WindowManager, я про него позже расскажу) <br />[14:10] &lt;Sark7&gt; для MouseEvent <br />[14:10] &lt;Sark7&gt; Window находит контрол в котором находится мышь <br />[14:11] &lt;Sark7&gt; и отправляет сначала parent2child затем child2parent <br />[14:11] &lt;Sark7&gt; на самом деле немного сложнее, потому что есть еще leave/enter события, но в принципе одинаково <br />[14:11] &lt;Sark7&gt; для KeyEvent <br />[14:12] &lt;Sark7&gt; Window держит фокусный контрол <br />[14:12] &lt;Sark7&gt; которому и шлет событие от клавиатуры <br />[14:12] &lt;Sark7&gt; Command вообще тривиально и зависит от <br />[14:12] &lt;Sark7&gt; так, расскажу про UIRenderer <br />[14:13] &lt;Sark7&gt; он и обеспечивает некий промежуточный слой между рендер-апи и собственно гуи <br />[14:13] &lt;Sark7&gt; у него есть методы для отрисовки основных виджетов <br />[14:13] &lt;Sark7&gt; типа DrawSlider, DrawCheckbox итд <br />[14:13] &lt;Sark7&gt; на самом деле это необязательно, но нужно если мы хотим total theming <br />[14:14] &lt;Sark7&gt; и методы для отрисовки примитивов - квады, треугольники, текст <br />[14:14] &lt;Sark7&gt; контрол передает в эти методы _желаемые_ параметры вывода <br />[14:14] &lt;Sark7&gt; UIRenderer выбирает актуальные <br />[14:14] &lt;Sark7&gt; и рисует <br />[14:15] &lt;Sark7&gt; например <br />[14:15] &lt;Sark7&gt; текстуры тоже абстрагированы <br />[14:16] &lt;Sark7&gt; контрол передает в методы UIRenderer имя текстуры/хендл <br />[14:16] &lt;Sark7&gt; это нужно например, если у нас атласинг для гуи <br />[14:16] &lt;Sark7&gt; и текстуры виртуализированы ) <br />[14:17] &lt;Sark7&gt; про WindowManager <br />[14:17] &lt;Sark7&gt; он управляет собственно окнами <br />[14:17] &lt;Sark7&gt; есть список окон <br />[14:17] &lt;Sark7&gt; наверху этого списка - модальное окно <br />[14:17] &lt;Sark7&gt; т.е. сообщения посылаются лишь одному окну, первому в списке <br />[14:18] &lt;Sark7&gt; мультиоконность реализуется через MultiWindow <br />[14:18] &lt;Sark7&gt; которое собственно наследуется он окна, но управляет несколькими окнами в себе</p><p><a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=735&amp;page=2">Продолжение</a></p> http://www.gamedev.ru/community/gamedev_lecture/articles/?id=720 Thu, 20 Apr 2006 20:54:29 GMT http://www.gamedev.ru/community/gamedev_lecture/articles/?id=720 http://www.gamedev.ru/community/gamedev_lecture/forum/?id=1146 <p>Disclaimer: некоторые опечатки поправлены, некоторые реплики передвинуты.</p> <p>[23:04:11] &lt;new&gt; В общем сразу скажу, что лекция в большенстве своего объёма построена на материалах статьи Advanced Character Physics <br />[23:04:29] &lt;new&gt; автор Thomas Jakobsen (<a href="http://www.gamasutra.com/resource_guide/20030121/jacobson_01.shtml">http://www.gamasutra.com/resource_guide/20030121/jacobson_01.shtml</a>) <br />[23:04:57] &lt;new&gt; её перевод может быть найден в формате DOC здесь <a href="http://www.l1f.nm.ru/download/AdvancedCharacterPhysics.rar">http://www.l1f.nm.ru/download/AdvancedCharacterPhysics.rar</a> <br />[23:05:09] &lt;new&gt; автор перевода Антон Ткачёв <br />[23:05:23] &lt;new&gt; остальные ссылки в конце лекции <br />[23:05:51] &lt;new&gt; Цель лекции рассказать основы бодробнее, чем в оригинальной статье <br />[23:06:44] &lt;new&gt; приобщить &quot;новичков&quot; к физике на основе этого метода и показать что физика может быть проста в реализации</p> <p> <br />[23:07:41] &lt;new&gt; Основой структуры данного метода является система частиц <br />[23:08:20] &lt;new&gt; в привычной формулировке для каждой частицы системы хранится её текущее положение и скорость <br />[23:08:33] &lt;new&gt; pos_new = pos + vel*dt <br />[23:08:33] &lt;new&gt; vel_new = vel + accel*dt <br />[23:08:33] &lt;new&gt; Это простое объединение Эйлера <br />[23:10:14] &lt;new&gt; таким образом считается положение и скорость на новом шаге(pos_new и vel_new) через предыдущий (pos и vel) <br />[23:10:50] &lt;new&gt; Метод с использованием интегрирования Верлющей, т.е. <br />[23:10:57] &lt;new&gt; pos_new = 2*pos - pos_last + a*dt*dt <br />[23:10:57] &lt;new&gt; pos_last = pos <br />[23:12:18] &lt;new&gt; где (pos_last-pos) является аналогом скорости при постоянном времени шага <br />[23:14:09] &lt;new&gt; то-есть pos + (pos-pos_last)*1(ед. времета предпологает хранение предыдущей и текущей координаты для получения следуени) + a*dt*dt <br />[23:15:36] &lt;new&gt; таким образом система не зависит от явного значения скорости и становится более стабильной <br />[23:16:07] &lt;new&gt; уже исходя из написанного выше можно написать простую систему частиц <br />[23:16:13] &lt;new&gt; <a href="http://www.everfall.com/paste/id.php?8nblk7hk1mhg">http://www.everfall.com/paste/id.php?8nblk7hk1mhg</a> <br />[23:18:22] &lt;new&gt; функция AccumulateForces накапливает силовые состовляющие для каждой частицы, пока что это действует только сила гравитации <br />[23:18:56] &lt;new&gt; функция Verlet() делает то, что описано выше <br />[23:19:06] &lt;new&gt; сразу упомяну об оптимизации <br />[23:21:11] &lt;new&gt; здесь можно использовать 3 массива (pos_new, pos и pos_last) и не менять местами значения в массивах, а менять местами сами массивы <br />[23:24:37] &lt;new&gt; Сразу же можно собрать и посмотреть в действии простую систему частиц, добавив несколько частиц с разными положениями и предыдущими положениями (pos_last = pos-vel), где vel - желаемая вами скорость частицы <br />[23:28:01] &lt;new&gt; и ограничив координаты частиц кубом <a href="http://www.everfall.com/paste/id.php?dcvzxmlkhad2">http://www.everfall.com/paste/id.php?dcvzxmlkhad2</a> <br />[23:29:41] &lt;new&gt; теперь запустив систему мы должны увидеть как частицы летят по параболе и при ударе в стенку вооброжаемого куба перестают перемещаться в сторону норамали <br />[23:30:04] &lt;new&gt; причём не отменяя перемещения в остальных направлениях <br />[23:32:00] &lt;new&gt; Теперь добавим связь между частицами. <br />[23:34:21] &lt;new&gt; Под связью будем понимать обсолютно нерастяжимый стержень с определённой длиной <br />[23:36:31] &lt;new&gt; То-есть если &quot;связаны&quot; 2 частицы, то условием связи будет |part1.pos-part2.pos| = constrain.length <br />[23:40:00] &lt;new&gt; таким образом необходимо будет найти длину вектора, отнять её от длины связи <br />[23:40:33] &lt;new&gt; (длину вектора (part1.pos-part2.pos) ) <br />[23:41:47] &lt;new&gt; получим расстояние, на которое надо переместить партиклы на встречу друг к другу (или друг от друга) <br />[23:42:38] &lt;new&gt; делим это расстояние на длину вектора - получаем какая это часть от исходного вектора <br />[23:44:21] &lt;new&gt; если это найденное значение =diff, а сам вектор delta, то партиклы нужно переместить на +0.5*delta*diff и -0.5*delta*diff <br />[23:46:52] &lt;new&gt; <a href="http://www.everfall.com/paste/id.php?kg654bsepuy5">http://www.everfall.com/paste/id.php?kg654bsepuy5</a> <br />[23:48:03] &lt;new&gt; для нахождения длины вектора необходимо находить квадратный корень <br />[23:49:33] &lt;new&gt; Даже при не большой точности вычисления квадратного корня система не выйдет из равновесия <br />[23:49:46] &lt;new&gt; из-за не явного хранения скорости <br />[23:51:21] &lt;new&gt; используя формулу Тейлора (находим только функцию 1-го порядка ряда) <br />[23:53:03] &lt;new&gt; можно упростить всё выражение <a href="http://www.everfall.com/paste/id.php?45hmot1k5g80">http://www.everfall.com/paste/id.php?45hmot1k5g80</a> <br />[23:54:17] &lt;new&gt; restlength нам известна заранее, по этому можно кешировать значение restlength*restlength</p> <p> <br />[23:54:36] &lt;_Winnie&gt; а где-то можно будет увидеть программу-демонстрашку целиком ? с примитивным выводом на GLUT или даже может быть вообще без графики, которую легко самому прилепить? <br />[23:55:02] &lt;new&gt; да, в конце лекции будут полезные ссылки <br />[23:55:15] &lt;new&gt; хотя давайте сейчас <br />[23:55:35] &lt;new&gt; я покурить схожу - вы пока посмотрите, ато нудно как-то получается...</p> <p> <br />[23:55:50] &lt;new&gt; <b>Полезные ссылки:</b> <br />[23:55:50] &lt;new&gt; &quot;Advanced Character Physics&quot; (Thomas Jakobsen) <a href="http://www.gamasutra.com/resource_guide/20030121/jacobson_01.shtml">http://www.gamasutra.com/resource_guide/20030121/jacobson_01.shtml</a> <br />[23:55:50] &lt;new&gt; &quot;Продвинутая физика персонажей&quot; перевод предыдущей (Антон Ткачёв) &lt;в DOC формате&gt; <a href="http://www.l1f.nm.ru/download/AdvancedCharacterPhysics.rar">http://www.l1f.nm.ru/download/AdvancedCharacterPhysics.rar</a> <br />[23:55:50] &lt;new&gt; &quot;Простой метод Верлетной интеграции с поправкой времени&quot; (Джонатан &quot;одинокий носок&quot; Даммер) <a href="http://1wd.ru/ru/fm/translat/tcv-rus.htm">http://1wd.ru/ru/fm/translat/tcv-rus.htm</a> <br />[23:55:50] &lt;new&gt; Демки с исходниками <a href="http://www.members.lycos.co.uk/olivierrenault/">http://www.members.lycos.co.uk/olivierrenault/</a> <br />[23:55:50] &lt;new&gt; Convex hull (физика со схожими принцыпами) <a href="http://www.rowlhouse.co.uk/jiggle/">http://www.rowlhouse.co.uk/jiggle/</a></p> <p> <br />[23:56:03] &lt;_Winnie&gt; new а то что ты сказал - это только для стержня или может быть применено для произвольной системы между частицами? <br />[23:56:22] &lt;_Winnie&gt; *произвольной системы связей между <br />[23:57:05] &lt;new&gt; То, что написано выше, приминимо только для нерастяжимых стержней <br />[23:57:07] &lt;Innochenti&gt; э, стоп. В Jiggle совершенно другой подход. <br />[23:58:04] &lt;new&gt; Innochenti там схожий принцып в том смысле, что выпуклые объекты выталкиваются из объектов, в которые они попали <br />[23:58:07] &lt;Innochenti&gt; там физика по след. документу Eran Guendelman - Nonconvex Rigid Bodies with Stacking.pdf <br />[23:58:12] &lt;new&gt; и только в том <br />[23:58:44] &lt;new&gt; ну да, не пояснил <br />[23:59:19] &lt;new&gt; _Winnie но система легко расширяется для реализации любых связей</p><p><a href="http://www.gamedev.ru/community/gamedev_lecture/articles/?id=720&amp;page=2">Продолжение</a></p>