Движок C++.Форум

Что вы хотите знать о разработке кроссплатформенного движка на C++. (комментарии) (5 стр)

Страницы: 14 5 6 79 Следующая »
#60
0:57, 12 дек 2014

the_siv
> Для принятия такого важного решения надо досконально изучить движок:
> плюсы/минусы, что есть/чего нет. Есть описание хоть в каком-то виде? Я не
> только для себя спрашиваю - если ты утверждаешь, что уже сейчас на нём можно
> написать полноценную игру, то может кто-то станет уже сейчас использовать твой
> двиг в том виде как он есть сейчас.
Боюсь описания пока нету, я планирую до февраля месяца сделать сборку(в основном это выделить питон фреймворк) которую можно будет показывать людям и не стесняться :)
Я могу обсудить в скайпе, желательно в устной форме - так сказать небольшую презентацию, с написанием и описанием у меня вечные проблемы (
Я надеюсь на это что будут, потому что последние полгода ознакомился с многими конкурентами и был удивлен "как мало нужно для счастья"

> Так эта, а чего перестал развивать движок? И почему вдруг возникла идея возобновить работы? И зачем тебе вообще я?
наоборот интенсивно развиваю. Зачем? ну я так понял что есть желание сделать двиг, вот и предложил взять за базу, один я просто не доведу его до "массы людей"

#61
11:01, 12 дек 2014

foxes
Ни чё не пойму: ты утверждаешь что не зависимо от column-major/row-major матрица передаётся в шейдер одинаково (занимая 3 регистра float4) или наоборот?

#62
11:21, 12 дек 2014

the_siv
> передаётся в шейдер одинаково
да
the_siv
> занимая 3 регистра float4
нет - зависит от column-major/row-major

память column-major ( "C/C++" float array[12] ):
{  0,   1,   2,   3,   4,   5,   6,   7,   8,   9,  10,  11}
{0.0, 0.4, 0.8, 0.1, 0.5, 0.9, 0.2, 0.6, 1.0, 0.3, 0.7, 1.1}
нумерация элементов в матрице шейдера column-major (память column-major):
{ 11,  12,  13,  21,  22,  23,  31,  32,  33,  41,  42,  43}
нумерация элементов в матрице шейдера row-major (память column-major):
{ 11,  21,  31,  12,  22,  32,  13,  23,  33,  14,  24,  34}

-- vec3 rez=matrix*v - дает одинаковый результат column-major/row-major --
разная реализация из за обращения к элементам матрицы:

пример умножения вектора на матрицу column-major (память column-major):
rez.x=m11*v.x+m21*v.y+m31*v.z+m41*v.w
rez.y=m12*v.x+m22*v.y+m32*v.z+m42*v.w
rez.z=m13*v.x+m23*v.y+m33*v.z+m43*v.w
масштабирование и сложение 4 регистров (vec3 rez=r1*v.x+r2*v.y+r3*v.z+r4*v.w;)

пример умножения вектора на матрицу row-major (память column-major):
rez.x=m11*v.x+m12*v.y+m13*v.z+m14*v.w
rez.y=m21*v.x+m22*v.y+m23*v.z+m24*v.w
rez.z=m31*v.x+m32*v.y+m33*v.z+m34*v.w
скалярное умножение 3 регистров (vec3 rez=vec3(dot(v,r1),dot(v,r2),dot(v,r3));)

Раздели понятия: "загрузка матрицы в шейдер" всегда column-major (без регистров), и "загрузка матрицы в регистры в шейдере" column-major/row-major.

#63
13:04, 12 дек 2014

foxes
>> "загрузка матрицы в шейдер" всегда column-major (без регистров)
пруф линк можно?

#64
13:40, 12 дек 2014

Это то в чем заключался вопрос!
foxes
> Возможно это относится только к внутренним вычислениям не относящимся к хранению матрицы в памяти?
Поскольку
>а просто использовал row_major float4x4 mat;
Для тебя ни чего не меняло, кроме количества регистров.

Но в документации MSDN и сдесь:
http://www.gamedev.net/topic/508048-do-you-use-cg-or-cgfx/
> So to sum it up, the order of multiplication in mul intrinsic depends on the packing order of the matrix operand its operating on. The packing order, in turn, not only depends on the > #pragmapack_matrix directive or the row_major/col_major keywords, but is also dependent on the API call you make to bind the matrix (SetMatrix vs. SetMatrixTranspose in HLSL > FX, cgSetMatrixParameterfr vs. cgSetMatrixParameterfc in CgFX) since row-major and column-major matrices are transposes of one another. It's possible to set the packing order in a way so both languages use the same mul( vector, matrix ) ordering, albeit at the cost of a small performance penalty.

Говорится именно о том что это влияет только на внешнюю передачу данных и не влияет на внутреннюю ориентацию матрицы в шейдере. А также на снижение производительности при использовании дополнительной внешней операции транспонирования матрицы если API языка имеет отличную ориентацию от расчетов в шейдере.
Хотя стандартно для интерфейсов GL и DX (пример glLoadMatrix) это column-major.

То есть если считать матрицу float m[16]; glGetFloatv(GL_MODELVIEW_MATRIX, m); и передать ее в шейдер где ориентация входного параметра row-major, То gl_ModelViewMatrix и переданная матрица это будут две разные матрицы.

#65
13:52, 12 дек 2014

Сделал пример:
Передаю всегда одну и ту же матрицу в константный буфер:

 0x00f8e7b8 {1.00000000, 2.00000000, 0.000000000, 0.000000000, 0.000000000, 1.00000000, 0.000000000, ...}

Смотрю в студии в графическом дебагере:
для

cbuffer ConstantBuffer2 : register( b1 )
{
  row_major float4x4 Mat;
}

регистры

cb1[0] = x = 1.000000000, y = 2.000000000, z = 0.000000000, w = 0.000000000 
cb1[1] = x = 0.000000000, y = 1.000000000, z = 0.000000000, w = 0.000000000 
cb1[2] = x = 0.000000000, y = 0.000000000, z = 1.000000000, w = 0.000000000 
cb1[3] = x = 0.000000000, y = 0.000000000, z = 0.000000000, w = 1.000000000 

для

cbuffer ConstantBuffer2 : register( b1 )
{
  column_major float4x4 Mat;
}

регистры

cb1[0] = x = 1.000000000, y = 2.000000000, z = 0.000000000, w = 0.000000000 
cb1[1] = x = 0.000000000, y = 1.000000000, z = 0.000000000, w = 0.000000000 
cb1[2] = x = 0.000000000, y = 0.000000000, z = 1.000000000, w = 0.000000000 
cb1[3] = x = 0.000000000, y = 0.000000000, z = 0.000000000, w = 1.000000000 

Вывод: никто ничего не подменяет - как передаёшь, так и получаешь, меняется только математика в шейдере.

#66
14:18, 12 дек 2014

Тобиш, в последствии когда шейдер производит умножение он по разному считывает в операционные регистры значение из константных регистров.
"загрузка матрицы в шейдер" всегда column-major (в константные регистры), и "загрузка матрицы в регистры в шейдере" column-major/row-major (из константных в операционные регистры).

#67
14:21, 12 дек 2014

да

#68
23:02, 16 дек 2014

lookid
Кину-ка я за the_siv-ом в догонку...

> 1) Асинхронная загрузка ресурсов
Откровенно и честно - это незачем. Надо двигаться в сторону связных структур данных и POD/FLAT-храния. Загрузка таких ресурсов легка аки перышко.
Парой слов : твой файл данных - это буфер подкачки, в котором все уже размещено, а после маппинга (не чтения, а маппинга) в ОП остается только восстановить указатели из индексов.

> 2) Data Oriented Design, Entity-Component system
DDP/COP/ECS/ESP - темы это старые, T-Machine (Адам Мартин) первые свои доклады об этом еще в 2001 году делал. Но на поверхность они всплыли, почему-то, лишь недавно... Это странно, по моему.
Основная идея COP/ECS/ESP - это парадигма разумного замещения принципов наследования принципами декомпозиции и агрегации данных на фоне очень строгого разделения сущностей кода и данных.
Более детально описывать, думаю, не стоит. Вот материалы по памяти...
http://entity-systems.wikidot.com/
http://gamadu.com/artemis/
http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-… pment-part-1/
http://t-machine.org/index.php/2007/11/11/entity-systems-are-the-… pment-part-2/
http://t-machine.org/index.php/2007/12/22/entity-systems-are-the-… pment-part-3/
http://t-machine.org/index.php/2008/03/13/entity-systems-are-the-… -mmos-part-4/
http://t-machine.org/index.php/2009/10/26/entity-systems-are-the-… -mmos-part-5/
http://t-machine.org/index.php/2010/05/09/entity-system-1-javaandroid/
http://habrahabr.ru/post/197920/
http://habrahabr.ru/company/wargaming/blog/245321/
http://habrahabr.ru/post/219007/

https://github.com/alecthomas/entityx
https://github.com/TTimo/es_core
https://github.com/perky/FEZ
https://github.com/richardlord/Ash
https://github.com/dava/dava.framework

Канонический ECS движок - это штука хорошая, но экстремальная и перегруженная. К такому экстремизму стремиться - мое мнение - не стоит. В большей части случаев хватит Артемиса. Это самый прямой и достойный, из универсальных, двиг. Если при контакте с Артемисом возникает идиосинкразия, то лучше написать свой (строго под задачу, строго по требованиям) ECS/CO/ES движок. Эти сущности просты в реализации.

> 3) Евенты, Скриптинг (lua, python)
Этот вопрос относится к религиозным и холиварным. Выбор скриптового языка - задача требующая обоснованного решения, обоснование же это обязано выводиться для каждого уникального случая отдельно.
Я использовал только LUA без надстроек. Ожидаемые тебования и необходимые возможности практически всегда сходились только к этому скрипту.
Плюсы : скорость работы, прозрачность стека и стейта машины, удобность синтаксиса, легкость вхождения в язык, леко построить надсистему своих операций.
Минусы : внешний интефейс либы староват, приходится делать надсистему (хоть это и легко, хоть это и плюс) для своих операций.

Был опыт создания и внедрения C-Based языка со своим транслятором и машиной. Опыт был удачным, с тех пор осталось желание "повторить и улучшить"; работа с LUA его не уменьшила.

> 4) AI-system. Ползающие по Катмолу-Роме, стиринг и прочее из Programming Game
Тоже все понятно: надо только прочитать «Искусственный интеллект в компьютерных играх» Алекса Шампандара, как все вопросы об использовании сторонних AI либ отвалятся сами.
Опять же, каждое решене должно быть взвешено и оценено. Если рамки требований позволяют натянуть результат на имеющуюся либу - в добрый путь. Иначе: сучим рукава и смазываем клаву. Попотеть придется.

> AI by Example
Туда-же, к Алексу.

> 5) UI
Ответит Александр Друзь. :)
UI - это не часть движка, это надслой движка - тоже движок, отдельный. Структура базового движка не завистит от структуры движка UI.
Складывать это в одну кучу - это признак. Лично мне подобные этому признаки резко не нравятся.

> 6) Партиклы, тира CreateParticle(TYPE, Pos1, Pos2, Easing, void (*callBack)(void))
Зачем? На уровне плюсов? Боже упаси. Такого на плюсах быть не должно. В скрипте с радостью, в плюсах - нет.
Это тоже неприятный мне признак.

> 7) Анимации, типа CreateAnimation(Object, Easing, t_params, void (*callBack)(void)), t_patams = (f_time, pos_begin, pos_end ...)
Зачем? На уровне плюсов? Боже упаси. Такого на плюсах быть не должно. В скрипте с радостью, в плюсах - нет.

#69
23:23, 16 дек 2014

the_siv
> Если серьёзно, то начинать надо с математики.
> Надо найти математическую библиотеку, которая...

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

Я прочитал всю ветку обсуждений, но интересным для себя нашел только эти два поста.
Если кому интересно, могу попробовать ответить на возникшие/имеющиеся вопросы.

#70
5:26, 17 дек 2014

Stain
> Откровенно и честно - это незачем.
Расскажи это инженерам которые уже жопу порвали над тем что бы ускорять один процессор, и уже перебираются на 16+ процессоров, а пока ты будешь писать мне ответ, уже будет и 32+ процессоров. По этому давай вливайся в архитектуру и подходы мультипроцессоров, а то глядишь и НОКИА обгонит твой движок по производительности. Идеальный подход это loadingless когда ты подсказываешь своему Префетчер-менеджеру что и когда подгрузить, ты только навел мышку, или в ввел в ББ-треад к "переходу" как уже началась подгрузка "окна"/"сцены"
Так что мимо

Я даже не говорю про Апдейт сцены в асинхронном режиме.

Stain
> DDP/COP/ECS/ESP - темы это старые
Они не старые они вечные, и тут только вкус и цвет фломастеров

Stain
> Этот вопрос относится к религиозным и холиварным.
Определенно факт. Синтаксис питона бесподобен, но его "слонячесть" иногда мешает спокойно спать, не более. Но да без холивара не обойтись

Stain
> Зачем? На уровне плюсов? Боже упаси. Такого на плюсах быть не должно. В скрипте
> с радостью, в плюсах - нет.
> Это тоже неприятный мне признак.
Какие плюсы? какие скрипты? 90-е. Как я обожаю программистов которые считают что они боги-контента, вы еще давайте Фотошоп зафигачте сами. Это контент - точка. Другой вопрос откуда вы его берете, поделка, лицензируете Астралакс или другие библы.

Stain
> Зачем? На уровне плюсов? Боже упаси.
After Effect? 3D max - нет не слышали? изучайте что-то кроме ноутпада, динозавры ;)

Stain
> Начинать стоит - мое мнение - с базовых операций. ;) Ввод/вывод, потоки, файлы
Правильная мысль, начинать движок нужно с того, с чего его могут украсть - сделать "платформу" для своего. дальше мясо

#71
11:25, 17 дек 2014

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

#72
16:47, 18 дек 2014

Stain
> UI - это не часть движка, это надслой движка - тоже движок, отдельный.
> Структура базового движка не завистит от структуры движка UI.
> Складывать это в одну кучу - это признак. Лично мне подобные этому признаки
> резко не нравятся.
В продолжении этому можно развить тему, поскольку уже непосредственные инструментальные элементы, в которые входят часть анимации, тирейны, колайдеры (разновидности) и прочие механизмы тоже по сути являются над слоем самого движка как и UI. Думаю из трех составных: API - при помощи которого написан движек, структура архитектура движка, и инструменты (интерфейс) API движка. Это уже относится к последнему. Вопрос конечно о каком уровне UI говорится. Ведь UI как элементы графического интерфейса могут реализовываться параллельно, не зависимо от Архитектуры движка, на одном и том же API с ним, так и при помощи инструментов API самого движка. Или UI как редактор проекта - то тут можно брать вообще все что угодно, будет самостоятельный проект.
Stain
> Зачем? На уровне плюсов?
А как базовое Api с чего то скрипты должны брать. Это уже математика привязанная к конкретному объекту, ни чего сверх естественного нет, используется ли это в скриптах или языке.
IROV..
> After Effect? 3D max - нет не слышали?
Хорошие инструменты. А связь какая?

#73
17:03, 18 дек 2014

foxes
> А связь какая?
Очень даже прямая :)
Анимация это тоже "контент", и надо сразу думать об этом

#74
17:27, 18 дек 2014

IROV..
То есть чисто портируемость ресурсов и не больше.
IROV..
> и надо сразу думать об этом
Ну это вопрос общего базового API, че тут думать? Переварит ли движек все что в редакторе набилдили? Ну не будет у него пары функций/формата - доделают, вопрос расширяемости функционала и гибкости архитектуры - вот над этим надо думать, поскольку относятся к вопросам проектирования. И это уже было озвучено.

Страницы: 14 5 6 79 Следующая »
Движок C++.Форум

Тема в архиве.