1) Определим компоненты

Хочется чтобы наши разработчики пользовались какими то стандартами а не изобретали велосипед сами, и чтобы мы общались на более понятном языке.
Поднимаю тему для того чтобы определить какие компоненты игровых движков нужны разработчикам, и какие части движков можно сделать компонентой !

Сразу приведу два предельных случая:
1)Дается сразу работающий движок тотже OGRE, Irrlight.
у каждого своя математика, свои форматы представления данных, свои объекты.
Пользователь либо решает пользовать это,  либо просто смотрит как примерно это сделано, либо выдирает нужные пару строк кода.
2)Пишется просто пример использования, или вообще статья которая только набрасывает общие штрихи.
Тут приходится переписывать все заново и под себя, разбираясь в каждом мелком аспекте.

Эти два случая существуют и сильно развиты, кругом полно статей и готовых движков и подсистем.
Middleware развит по сравнению с этим не так хорошо, хотя тут тоже прогресс значительный.
Причем каждый Middleware также страдает своим желанием написать все и вся для весомости так сказать.
Хочу чтобы Компонент выполнял тоько то что от него требуется и не давал кучу разных ненужных фитч.
Хотя понятно почему так происходит, ведь Middleware нужно еше и продать.

Я хотел бы видеть наш геймдев не только как форум и массив статей, но как набор некоторых компонент.
Создал тему именно для того чтобы определить какие компоненты могут быть выделенны
Приведу пару примеров
http://www.gamedev.ru/projects/forum/?id=8476
http://www.gamedev.ru/code/forum/?id=61507
Как видно есть люди которые примут на себя благородную задачу написания компонент!
В случае с библиотекой для скелетной анимацией компонент не выделен. Тоесть там есть код для экспорта и свой формат представления анимации, и это довольно жестко приковывает :(. Ведь как бы было здорово если бы можно было очень легко и приятно подключить+сконфигурировать себе скелету.

Мой request
math
geometry primitives(всякие алгоритмы с разделяющей осью, пересечения, разбиение пространства итд...)
geometry mander(всякие создания tangent binoraml, shadow volume geometry, optimizing ....)
scelet animation
tree generator
image generator

Кто что еще видит ? Предлагайте ?
Я не привожу такие веши как landscape, это второй порядок сложности. Тоесть спроектировать такую систему чтоб она удовлетворяла многим архисложно.
Хотя надеюсь и до таких дело дойдет.
ЗЫ geometry mander у меня в виде пригодном для опенсорса, только вот оптимизировать его надо, но это вопрос времени.

Тут скорее не вопрос количества доступных\качественных утилит, а вопрос грамотной проектировки asset pipeline таким образом, чтобы на любой "request" можно было как можно скорее дать полезный "response". Имхо, куча отдельных утилит - еще не программный пакет.

Мне не до конца понятна постоновка. А из того что я понял могу сказать, что не по адресу :-). Это сообщество "утиля", и вопросы разработки движка или компонентов приложения - это все же не по адресу.
Или я что-то не понял?

..bw

bw, компоненты конечно не утилиты, но более близкого сообщества все равно нет, поэтому сюда запостил.
Получился же stl, а почему бы не сделать чтото подобное для геймдева.
Ведь постоянно на форуме задают одни и теже вопросы, как перевести кватернион в матрицу, как найти точку пересечения линии с треугольником, как создать индексированную геометрию меша. Когда каждый напишет все с самого начало это конечно полезно, но както долго, и не максимально эффективно.

Crio, цель в создании библиотеки, так сказать джентельменского набора девелопера. Тоесть а в выделении тех кусков кода которые уже десятилетия переписываются каждым заново.

Пока что создание такой библиотеки игра в одни ворота, но это пока....

К сожалению в вопросах разработки компонент о которых ты говоришь не силен и вряд ли могу что-то предложить. К тому же я не работаю с Си или ++. Могу, например, посодействовать при переносе (портировании) кода с Си на Python или паскаль. Могу заниматься приложениями (утилем) или разработкой протоколов (сетевых или взаимодействия компонент/приложений).

..bw

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

Arxon
Не очень понял направление.
Например вот один из компонентов:
http://www.gamedev.ru/projects/forum/?id=68589
Достаточно универсален, если его портировать (bw?)

Mikle, под компонентами я имею ввиду более маленькие веши.
Иерархия такая
1)Движок
2)Подсистемы - Устройства : Графическая, Звуковая, Физическая, Система сущностей, Сетевая, ....
3)Компоненты: растеризация, определения пересечений, математика, и еше очень много всего
4)Методы-Функции-Классы
Представь что ктото захочет написать софтверную растеризацию в 2д например для создания карт нормалей( как в Nvidia Melody). Или например захочет игру, где можно подойти к игровому автомату( как в томже думе3) и поиграться в какую нить  2д игру(теже гоночки). Вопрос на сколько удобно будет взять твой движок ? эта самый важный вопрос. По ссылке ходил, но так скачать и посмотреть движок не удалось... :( поэтому ничего сказать не могу.
Мне бы понадобился компонент растеризации если бы он был оформлен в с++ template стиле, чтоб можно было запросто переопределять тип представления цвета(например путь цветом будет матрица 3х3, или вообще что угодно). Также была возможность добавлять свои аля шейдеры(не путать с компилируемыми шейдерами), тоже в template стиле. Реализация вывода графики под конкретную систему меня не особо интересует, но если она есть это плюс.
ForAll
Просто не раз уже сталкиваюсь с проблемой что люди пишут полезные вещи но заюзать их нормально нельзя
Поэтому и создал эту тему, чтоб люди таки выделяли нормальные компоненты которые могут пользовать не только они, а это сделать можно только сообща

Arxon
Видимо без скачивания по коментариям понять трудно, завтра выложу куда-нибудь в другое место.
>под компонентами я имею ввиду более маленькие веши
А мне казалось, что это у меня "более маленькая вещь", слово "движок" для нее не совсем подходит, это движок в таком же смысле, как им является OpenGL или D3D, только, естественно, гораздо скромнее.

Правка:
Сегодня нашел и выкладываю VB6 порт:
http://tuapse-mikle.narod.ru/SR2D_VB6.rar
380 кб.

То же под vb.net:
http://tuapse-mikle.narod.ru/SR2D_NET.rar
1200 кб.

Mikle, у тебя  скорее графическая подсистема, тоесть архитектурный уровень более высокий чем у тогоже gl, потому как библиотека не занимается только рисованием, а работает с обьектами которые рисуются, также умеет грузить изображения. Подсистема это не компонент, и так легко ее заюзать не получится, не со стороны кода а со стороны архитектуры.
Тоесть дело не в том сколько кода и какова его сложность, а в том какую часть архитектуры покрывает код. Если эта часть значительная то это подсистема, если маленькая то это компонент(в текущем контексте разговора).
Кстати почему нигде нет операции вращения ?

Arxon
"Библиотека не занимается только рисованием, а работает с обьектами которые рисуются, также умеет грузить изображения" - это уже ПОРТ конкретно на vb6, а под компонентом я имел ввиду только DLL, которая имеет уровень пониже, чем DX, где-то как и GL (просто набор нативных STDCall процедур). Ее можно использовать напрямую, но портировать удобнее.
>Кстати почему нигде нет операции вращения ?
А где оно в DirectDraw?
Для спрайтового движка на ректанглах это сложновато, вот масштабирование планируется.

Mikle, http://www.gamedev.net/reference/programming/features/gpgenesis6/page2.asp
член структуры эффектов dwRotationAngle
незнаю почему ты его не видел, может доков по бейсику+ddraw меньше.
>Для спрайтового движка на ректанглах это сложновато
я бы чесно говоря если бы взялся писать софтвар то бы написал все в самом общем виде причем сразу в 3д, и это было бы проше чем каждый раз писать трансформацию вращения потом сдвига, смешения текстурных координат( ведь у них тоже может быть вращение) итд.

Arxon
Зачем все это? Для этого есть D3D и OpenGL, с ними не поконкурируешь. Я пытался сделать универсальное решение для интерфейсной части (менюшки всякие и т. п.), достаточно красивые, но работающие независимо от того, соответствует железо требованиям проекта, или нет.

Mikle, мне не нравится выбранный тобой формат (динамическая библиотека и привязка к платформе). То как ты позиционируешь продукт, для интерфейса, для небольших (в смысле сложности) вешей и т.д. динамическая библиотека неудобна. Я бы поддержал проект, если бы ты сделал статическую библиотеку и предоставил возможность извне определять "контекст отрисовки" (грубо говоря область памяти), а все платформо зависимые вещи реализовал в отдельной статической библиотеке (вывод на экран, выделение памяти и т.д.). Тогда бы я даже взялся (возможно :-) за перенос твоей потехи на Linux и KolibriOS, а может и др. платформы.
Arxon, я думаю создавать компоненты именно в виде таких библиотек (.o) очень разумной идеей. Я вспомнил, чего бы мне хотелось получить от проекта, платформонезависимая реализация шрифтов, в том числе масштабируемых, реализация областей для усечения отрисовки, работу с геометрией. Минимальная привязка к платформе и, соответственно, максимальная портируемость. Сейчас меня больше интересует 2D, а точнее пользовательские интерфейсы. Не буду ходить вокруг да около, меня интересует все что я смогу перенести под KolibriOS, это у меня такой маленький пунктик :-).

p.s. Подчеркну что программная реализация алгоритмов мне более интересна. Программная т.е. без использования особенностей железа, которые можно получить только через драйвера.

..bw

bw, компоненты о которых я говорю должны быть 100% crossplatform & opensource, это больше чистая математика + работа с данными, поэтому никаких портов.
Если написать компонент софтверной графики правильно, то портом под winapi, direct draw, d3d, gl,  итд ...  будет является просто копирование, и каждый сделает это по своему, у кого-то может быть много окон, комуто нужно копировать только в определенные области итд. Так что порт тут будет даже вреден. Не стоит писать компонент для Ч, которые не смогут даше закрасить экран синим цветом. Компонент должен быть прост, НО не проше чем он есть на самом деле.
Насчет платформонезависимой реализации шрифтов, тут я не силен, юзаю bitmap шрифты. Есть библиотеки но они большие....
ForAll, выкладывайте свои требования, то что вы бы хотели видеть в виде компонента.