[quote author=SupLisEr Fox link=topic=363.msg9693#msg9693 date=1219930425]каким цветом подсвечивать лучше - красным, синим, зеленым, каким-то другим, или вообще без подсветки так и оставить?[/quote]<br />предоставить юзеру возможность самому решить этот вопрос&nbsp; ;)

Да, кстати, чуть не забыл. Интерфейс редактора делать на русском языке, или на инглише? А то, чую, бред на русском-то получится полный.

На английском, естественно.&nbsp; ;D

На настоящий момент очень сильно обновилась матлиба движка. Готовы вектора от 2D до 7D, есть мысли довести математику до 10D-векторов и 10D-матриц, дабы строить в редакторе десятимерные гиперкубы. Думаю, для полной загрузки ПК хватит и одного десятимерного гиперкуба. Впрочем, сейчас это - заготовки на будущее, некоторые из которых - на сильно далекое.<br /><br />Помимо прочего, я пытаюсь в матлибу добавить описание всем нам привычного измерения, часто выходящего на передний план - времени. Скажу сразу, что геморрой это нехилый, и для себя оно требует отдельного вектора, и разбиения самого себя на несколько зависимых измерений. При всем при этом, очевиден тот факт, что в реальности время нестабильно в скорости движения.<br /><br />Так же, идет активная работа над описанием брашей соответствующих числу измерений в n-мерных системах координат.&nbsp; Если получится реалтайм 10-мерный гиперкуб - закину сюда спешл-бенчмарком.&nbsp; ;)<br /><br />Так же, осуществил реструктуризацию движка. Математику сунул в одну DLL, логику игры в другую, звук в третью, сеть в четвертую, и так далее. Так же, по отдельной DLL выделил для нескольких рендеров. Это такие рендеры, как DirectX 9, DirectX10, OpenGL 3, каждый из которых независим от других. То есть, можно смело удалять рендер, который не заработает, движок ругнется на отсутствие библиотеки, и подгрузит наиболее подходящую для вашей системы. <br /><br />В EXE-файл я внес массу изменений, оставив ему только вызов библиотеки loader.dll, которая далее вызывает библиотеку игровой логики, а та уже все остальные, по необходимости. Получился отличный плацдарм для подключения к движку любых модулей. Сейчас я делаю упор на всем, чем только можно, постепенно наращивая движок мясом. <br /><br />В целом, движок получается почти что с поддержкой плагинов, вот только он эти самые плагины пока искать не умеет. Но я думаю, что и этому его скоро научу. Ориентировочно, его loader.dll будет искать в папке с собой папку plug-ins, а там файлы с расширением .dll, в которых будет вызывать как точку входа, процедуру ISPluginMain(), если не найдет,&nbsp; ругнется в лог-файл, и продолжит исследование остальных библиотек, там лежащих. Еще обдумываю поиск альтернативных точек входа в плагинах.<br /><br />Так же, обдумываю идею подкручивания к движку html-GUI. В html-файл мы пишем описание интерфейса пользователя, движок его читает, парсит, и строит интерфейс пользователя. Сложновато такие вещи писать с нуля, когда заранее не знаешь еще многого, и бОльшую часть времени просто переписываешь собственный код снова и снова.<br /><br />Игровую логику пытаюсь упрощать. В исходнике с монстром или оружием, мы определяем класс объекта, имя, файл со скриптом. При этом, все, что нужно написать в скрипте, оказывается огромным объемом информации (не в сказу попали, мол). Посему, я обдумываю, а так ли необходимы такие скрипты. Базис интерпретатора уже почти готов, стоит лишь вопрос целесообразности.<br /><br />Рассматриваю создание, и подключение к движку собственной SVN-системы. При этом, для ее подключения будет переработана загрузка движка тотально, то есть, те точки входа, которые будут использоваться в паблик релизах, выкладывающихся отдельно от SVиNки, в тех версиях окажутся недействительными. Это в максимальной комплектации SVиNки. В минимальной, там будет просто self-updater, который будет являться лишь плагином.<br />

Это что, про Quake 3 речь идёт?&nbsp; ;D<br /><br />Не уверен относительно модульной структуры движка, т.е. разбиения на библиотеки. Нужно чётко понимать, что никто не будет писать новые модули, а разбивать всё на модули просто из принципа это несерьёзный довод. Возможно, с графикой и возможны варианты, но прочие модули иных подсистем так и останутся в единичном экземпляре. Я вообще, против модульности в игровых приложениях, так или иначе они либо снижают производительность, либо игнорируют дополнительный функционал и изюминки API, на которых сидят. В некоторых случаях могут происходить ужасные вещи типа увеличения задержек. Нужно сместить акцент &quot;модулирования&quot; в сторону распараллеливания вычислительных процессов, т.е. выделение независимых друг от друга подсистем игры. Это уже серьёзный задел не то что на будущее, а на сегодняшние 2-4 ядерные процессоры. В будущем число ядер будет только расти.

Про модулизацию сейчас поясню.<br /><br />Во-первых, в модулях я редко использую какие-либо API. Я их не объявляю, если только это не WinAPI, API звука, растеризатора, или чего-то еще, без чего прожить просто невозможно.<br /><br />Во-вторых, все функции, исполняемые какими-либо API я вызываю только с тем расчетом, чтобы они выполняли строго то, что мне от них требуется сейчас, и далее просто дополняю теми функциями, которые когда-либо мне еще пригодятся в будущем.<br /><br />В-третьих, я не понимаю философии намешивания всего-всего-всего в одну кучу. В моем понимании, это и некрасиво, и не удобно. Если я намешаю всего в одну большую кучу, я начну завидовать Вальв, которые так расструктуризовали свой Source, что я там заблудился. Да и мне проще отделить рендер на DX10 от рендера на DX9, дабы заниматься каждым в отдельности. Это называется - котлеты отдельно, мухи отдельно. Да и определиться с тем, что мне нужно в модуле движка, а что нет, мне намного проще, держа математику отдельно от файловой системы и всего остального. Так же проще и наращивать функционал той же самой матлибы.<br /><br />Распараллеливание вычислительных процессов - я от него еще не отказывался.<br /><br /><br />Кстати сказать, сегодня я ознакомился с документацией от nVidia, описывающей технологию Direct3D 11. Я сильно удивился ее новшествам. Технология для тех, кто не умеет моделить - обновленный дисплейс. Я, конечно, когда Direct3D 11 SDK явится в Сеть, прикручу его рендер к движку, но особой выгоды от его использования там не вижу.

SDK мат.библиотеки, первый релиз. В себя включает только заголовочные файлы (те, с которыми проблем нет).<br />Релиз мат.библиотеки, №39. В себя включает скомпиленную DLL матлибы, LIB-файлы для подключения, и библиотеку экспортов.<br /><br />Поддерживается:<br />- Работа с многомерными векторами от 2D до 10D<br />- Работа с трехмерными матрицами<br /><br />Дорабатывается:<br />- Конвертер векторов<br />- Работа с матрицами, имеющими большее число измерений<br />- Работа с линиями<br />- Кватернионы<br /><br />Если есть какие-то замечания, и предложения - выкладывайте, я их приму к рассмотрению, если что-то непонятно - объясню, если что-то надо переделать (например, мне самому не очень-то нравится объявление которых векторов как классов), я этим займусь.

модульная структура - вещь отличная, но на практике много проектов начинают страдать от одного недостатка - для добавления новых фич в движок модули как ни странно - плохое решение. Плохое качество в том, что модули ограничены тем пространством функций, которое им дано. Этого пространства может и нехватить - и начинается куча самых распространенных ошибок когда модуль во время своих вычислений начинает предсказывать результат, который должен выдать другой модуль (что конечно не факт), либо как альтернатива модуль делает кучу запросов состояний от других модулей. Лишние вызовы функций, или глюки - в любом случае модули с этой точки зрения довольно опасны.<br />

VorteX<br />Спасибо, что развил мою мысль. Игры очень насыщены межмодульными связями и если количество связей превышает некий разумный предел, то модуль как &quot;чёрный ящик&quot; теряет смысл. Как пример, нельзя библиотеку вызывать в циклах, это не есть хорошо, этот подход точно не для игр. Драйверы как модуль это одно, там иного выхода нет, мы не пишем драйверы - а вот во внутреннем коде своей программы мы вольны делать всё что угодно. Но это не значит что правильно делать так, как хочется нам или как мы умеем. Главные требования к играм это прежде всего достижение минимально возможных задержек в &quot;нажал кнопку - получил результат&quot; (вспомним консоли с контролем на уровне мозжечка) и равномерная нагрузка на компоненты ПК. Если для игры и возможно условное разбиение на модули, то только на модули, содержащие солидную долю игровой логики, с явно выраженным и независимым от других модулей вычислительным потоком, чтобы в принципе виртуально растворить присутствие модуля.<br /><br />Следите за логикой: Модули &quot;меню&quot; и &quot;уровень&quot; могут эффективно сосуществовать друг с другом, а модули &quot;звук&quot;, &quot;логика&quot; и &quot;видео&quot; - нет. Если модуль &quot;логика&quot; разбить на асинхронные процессы &quot;логика-звук&quot; и &quot;логика-видео&quot;, то мы получим два модуля, которые способны эффективно разговарить друг с другом не на языке функций, а на языке !!!ДЕСКРИПТОРОВ!!! потоков - HANDLE.<br /><br />Вот моё ИМХО по модулям в играх ибо как раз развиваю свои домашние прожекты в сторону многопоточности. Я хотел бы отметить что открываются удивительные и невероятные возможности в программах именно из-за рассинхронизации контрольных точек потоков по времени. Это как новейшая физика в играх, она вызывает у меня этот WOW эффект, когда модуль физики живёт в своём собственном течении времени, а у игровой логики нет ни малейшего шанса предвидеть результат или предположить состояние модуля. Игровая логика вынуждена не командовать модулем физики, а именно на равных разговаривать с ним, просить его что-то сделать. Почувствуйте разницу в межмодульных связях между &quot;приказать&quot; и &quot;попросить&quot; и то, как это скажется на игровом процессе, и на ощущениях игрока. Появляется именно эффект интерактивности, когда каждый чих влияет на результаты игры, живой игры, а не упражнений на калькуляторе.

2willow: это как в сетевой игре, пакет прилетел, а может и не прилетел :) Клиент часть делает запрос и начинает предполагать положение объекта, а сервер ему через некоторое время обновленное положение высылает. В принципе по физике тут как раз очень хорошо получается - в фокусе подход constant framerate физики, которая X раз в секунду (а может и меньше) скидывает в буфер логики текущие положения объектов и данные по интерполяции.<br /><br />

а модули &quot;звук&quot;, &quot;логика&quot; и &quot;видео&quot; - нет. Если модуль &quot;логика&quot; разбить на асинхронные процессы &quot;логика-звук&quot; и &quot;логика-видео&quot;

А можно так, звук и логику - отдельными потоками - &quot;логика - игра&quot; (то есть сервер чать, геймплей логиа здесь) и &quot;логика - клиент&quot; (клиентская часть, спавнинг спецэффектов, получение пакетов от сервера, рендеринг видео и аудио, &nbsp;обработка серверных сообщений и проч.)<br /><br />

Спасибо, что развил мою мысль.

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