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

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

Страницы: 14 5 6 7 8 9 Следующая »
#105
0:05, 19 дек 2014

Stain
> Не просто по техническим причинам, а в первую очередь чтоб ни у кого из команды
> (особенно новичков, джуниоров и *дизов) соблазна не возникло использовать этот
> код "в бою".
а вот это и есть то что я называю "мировозрением", то есть никаких технических проблем нет - просто партия запрещает!

#106
0:05, 19 дек 2014

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

#107
9:33, 19 дек 2014

https://github.com/thesiv/freeengine
обращаю ваше внимание, что лицензия не определена.

#108
15:59, 19 дек 2014

the_siv
Кстати. Можешь для всех, чтоб разночтений небыло, дать полновесное описание на лицензии?
Я прекрасно понимаю что это громадная писанина, ссылками отделываться неохота. Мне важно видеть именно понимание лицензий (скажем: GPL, MIT, Apache, BSD), а для этого нужна детализация лично переработанной информации.

#109
22:28, 19 дек 2014

Stain
Так в том-то и дело, что я не шарю в open-source лицензиях, как-то не было надобности во всём этом разбираться. Потому и не определена лицензия. Но не только по этому.
Вот есть сам движок, есть его модификации, есть проекты с использованием движка или модификаций. Надо решить:
- можно ли продавать движок/модификации/проекты;
- необходимо ли открывать исходники модификаций/проектов (у движка изначально исходники открыты, но тут тоже могут быть варианты);
На мой взгляд это основные моменты, которые должна обозначать лицензия. Хотя может что-то забыл.
Я считаю, что если нельзя продавать проекты, сделанные на движке, то движок сразу мёртв не родившись, а остальное под вопросом.

#110
23:31, 19 дек 2014

the_siv
Продавать надо позволить. Поэтому я и выдвинул примером эти четыре лицензии. Они допускают распространение кода в платных проектах при соблюдении некоторых условий.
Я тоже не эксперт в лицензиях, но кой-чего кое-где черпнуть успел... Чего черпнул, тем и делюсь. :)

MIT :
https://ru.wikipedia.org/wiki/Лицензия_MIT
Лицензия допускает любое распространение и модификацию исходного кода (включая и платные приложения на основе исходного кода) при указании копирайта и пометки об использовании исходного кода.
Лицензия никак не оговаривает методы использования третьими лицами имен разработчиков и/или копирайта в целях рекламы/саморекламы.
MIT совместима с GPLи BSD.

GPL:
https://ru.wikipedia.org/wiki/GNU_General_Public_License
Эта еденица уже интереснее. Фактически, по этой лицензии проект передается в общественное достояние (общественную собственность). Однако, авторство все равно остается за фактическими авторами.
GNU не допускает прямое использование кода в проприетаных проектах. Иными словами, проект, собранный с использованием GPL кода должен быть опубликован под той же GPL лицензией. GPL - штука заразная. :)

Имеется и модификация GPL лицензии - LGPL, в рамках которой допускается использование GPL кода в проприетарном проекте, в качестве "объекта динамического связывания" (или проще - динамической библиотеки).
При соблюдении условия открытости исходного кода, GPL будет совместима с BSD и MIT.

BSD:
https://ru.wikipedia.org/wiki/Лицензия_BSD
По своей сути, BSD - это надстройка на MIT, включающая в себя пункт об ограничении использования доброго имени создателей кода в рекламных или иных целях извлечения прибыли.

Полностью совместима с GPL и MIT.

Apache:
https://ru.wikipedia.org/wiki/Лицензия_Apache
Данная лицензия не ставит условием неизменность лицензии распространения программного обеспечения, и не настаивает даже на сохранении его бесплатного и открытого статуса. Единственным условием, накладываемым лицензией Apache, является информирование получателя о факте использования исходного кода. Таким образом, в противоположность copyleft-лицензиям, получатель модифицированной версии не обязательно получает все права, изначально предоставляемые лицензией Apache. (прям с вики скопировал, лучше и не придумаю)
Это крайне либеральная лицензия, накладываемая исключительно и только на покрываемый ей исходный код и снимающая практически все обязательства с третьих разработчиков.
Эта лицензия полностью несовместима с MIT, BSD и GPL.

Еще есть интересная статья с интересными вопросами по поводу открытых лицензий.
http://geektimes.ru/post/45878/

Я думаю, для движка лучше всего подойдет BSD или MIT. Выбор тут, по факту, стоит между использованием и неиспользованием всего одного пункта (об ограничениях использования имен в рекламных целях).

#111
22:42, 21 дек 2014

the_siv
> расскажи общее устройство движка как ты его видишь.

Был ли ты на Девпоинте в 2011 году? Меня туда нелегкая занесла. Там было много всякой фигни про веб-индустрию, сервера и браузеры, про яваскрипт и про пЕхЕпЕ... А еще там Был Андрей Аксенов. Да, этот человек нам более интересен. :)
У Андрея достаточно богатый опыт разработки игр, но, после неминуемой гибели Титаника российского геймдева, он ушел заниматься системой Sphinx - поисковым движком.
У него на девпоинте было два доклада, первый меня не интересовал. Второй же назывался "Прекращаем писать код". И вот к чему я вспомнил это все (Я вообще стал часто ссылаться на Андрея, т.к. этот его доклад хорош сам по себе).

Запустить видео по клику - Как делать игрыЗапустить видео по клику - Как делать игры

http://youtu.be/LodXWv234Kg?t=3m42s

Вот также и я. Я не знаю как должен выглядеть движок, я знаю как он выглядеть не должен. В смысле, как вдигло выглядеть не должно если двиглом хочется хоть в малой степени гордиться.
Архитектура ни в коем случае не должна быть похожа на cocos2d и прочие похожие. Мешать все на свете в одну кучу ни в коем случае нельзя.
Код не должен быть функционально-ориентированным более чем на 20%, меньше можно (как говаривала госпожа Беладонна), больше - ни-ни.
Архитектура ни в коем случае не должна быть похожа на MOAI (хоть я и уважаю это двигло, но также прекрасно вижу всю его неповоротливость).
Ни в коем случае не стоит увлекаться "шаблонами". Многие это делают, почти всегда это приводит к ужасам. ("шаблон" - это потому что многие люди шаблоном считают постулат или идиому. Различия между ними всеми шириной с Гудзон.)

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

#112
0:13, 22 дек 2014

Доклад хороший очень "по мне костюмчик сшит". Но с остальным могу поспорить вплоть до занимания противоположной точки зрения. Но не хочу, в лом надоел весь этот срачь во имя луны. Собственно моя точка зрения исходит из посыла той же лекции. В основном это зависит от конкретики и на конкретном примере ты вполне можешь со мной согласится. Потому что любое утверждение можно разглядеть более глубоко и понять что оно верно только на 50 процентов для половины случаев. Поэтому я бы не стал что то утверждать из за того что можно по разному организовать и саму разработку движка и его внутреннюю организацию и она вполне может быть адекватной удобной и применимой но в корне отличатся от любого утверждения.
Главное с чем бы я согласился это то что для задачи нужно что то утвердительное и в рамках ее проблем можно сказать что нужно, а что нет.
У меня вот код к примеру на 80% платформо зависим, как от ОС так и от железа, при том что 20% это его платформо не зависимая копия. И из всех 100% кода работает только 20%, но не те 20% которые платформо не зависимы, а микс из всего кода и возможно что для некоторых платформ его составляет код из области 80%. Но это только алгоритмическое ядро всего движка, то есть все 100% функционально-ориентированный код. И если развивать мысль как и мой движек, то в полном составе, благодаря внесению дополнительного/основного высокоуровневого функционала, эти 100% превратится в 20% и получится как ты и говорил.

Я делал некоторые тесты, что то на подобии исследования, и для себя пришел к выводу что в принципе весь код может быть процедурным, а непосредственное использование функций может быть обернуто через классы, при этом весь код конечного проекта/приложения написанный с использованием этого движка будет объектно-ориентированным. Возможно это не удобно для написания самого движка, но очень влияет на производительность и объем кода в лучшую сторону. При том что программист видя такой код, долго будет плеваться, быстренько все приведет к надлежащему приемлемому виду, потеряв в 2-10 раз от производительности и увеличив в 3 раза код (и в 10 раз бинарники), экспортировав из основной библиотеки вместо "C" функций классы "C++" или скомпилировав все обертки в отдельную библиотеку. Потом перепишет реализацию на полностью объектно-ориентированную реализацию где код будет плодится практически из ничего. И потом придет к тому что вспомнит лекцию о том как лучше не писать (Прекращаем писать код) и возможно забьет.

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

Ооооочень не хотел это все писать... но не удержался... Заранее согласен со всеми возражениями, но моя жопа видит все в таком ракурсе!

#113
0:43, 22 дек 2014

foxes
С твоего поста мне стало казаться что у тебя слабый/неудачный/плохой/отсутствует опыт мета-программирования и статического связывания. :)

Многие люди плюются на плюсы в угоду pure C, пеняя на то, что "никогда Вы не узнаете", что из честного ооп кода "нагенерили и как соптимизили".
Брехня. ООП код легко, при должной красивой организации, ложится в короткие и быстрые инструкции. И только неумелое использование инструментов может привести к описанным тобой результатам.
Поголовное использование функционального подхода, как правило, приводит к "типа-ооп" с функциями, обрабатывающими структуры, и со структурами, в которых лежат указатели на функции.
Это еще один признак, который я не переношу...

#114
1:24, 22 дек 2014

Ну все таки статическое связывание тут не причем, а вот громоздить все на сплошном OOП это не есть полный охват всех задач и уровней проектирования.
Да всякое бывало. Есть пример когда нужно отвязаться вообще от языка С при этом либка пишется на ООП C++, а используется где нибудь в С# ява или LUA. Переходы для разных подходов делать не гуд.
Stain
> приводит к "типа-ооп" с функциями
Ну нет ни к чему такому это не приводит, при правильной организации. Это собственно из класса "а да вы не знаете и не умеете". Как минимум это все оборачивается инлайнами. А вот возможность отрабатывать различные элементы обработки объекта с минимальным антуражем вокруг класса, это позволяет, для базовых элементов. В общем это надо видеть.

#115
3:55, 22 дек 2014

foxes
Вот скажи что ты тут делаешь, зачем тебе движок? ты же классический адепт вермишельного кода

#116
4:07, 22 дек 2014

Stain
Доклад хороший но это на уровне комеди-клаба, если ты вышел за рамки "кто-здесь?" и уже сдал пару проектов коммерческих.

Разработку движка нужно начинать с интерфейсов систем которые мы хотим имплементировать. Это позволит и параллелить работу, и делать позднею оптимизацию, и портирование, это очень и очень удобно.

так вот как определить какие системы и сервисы нужны? для этого нужно поставить цель, минспек - какую игру мы хотим на нем сделать?
давайте сделаем КрестикиНолики, цель ясна.

какие нужны для этого системы и сервисы? кто первый получит приз!)

#117
11:30, 22 дек 2014

foxes
> а используется где нибудь в С# ява или LUA.
А можно поподробнее про использование ООП C++ либок в LUA? :)

#118
12:15, 22 дек 2014

Stain
> А можно поподробнее про использование ООП C++ либок в LUA? :)
я думаю речь идет о luabind

#119
23:53, 22 дек 2014

Stain
> А можно поподробнее про использование ООП C++ либок в LUA? :)
А то типо документации ни где нету?
IROV..
> Вот скажи что ты тут делаешь, зачем тебе движок? ты же классический адепт
> вермишельного кода
Судя по всему теперь уже просто по ржать над людьми которые пишут только на OOП, или только на  процедурном языке, или только на скрипте и на друг друга смотрят как на аборигенов из параллельной реальности, с полной уверенностью что только такая реализация является центром вселенной. (Вот такая я забавная бяка)
IROV..
> я думаю речь идет о luabind
гы - вот собственно я и об этом, вам гораздо проще взять клон копию или другую известную/неведанную технологию обвить ее сверх высокими моральными качествами, вместо того чтобы реализовать или использовать простое решение. Поскольку использование этого простого решения в корне противоречит вашим постулатам.
Кроме того сам движек ориентируете как корневой элемент диктаторского влияния на прицип разработки программы, а это инструмент. И если мне как художнику кисточка будет рассказывать как лучше делать штрихи мазки и обводки, а в противном случае вообще перестанет рисовать, то наверно мало кто такой кисточкой что то сможет нарисовать. ( АААА говорящая кисточка - глюки :) )

Неужели не интересе движек позволяющий реализовать качественное программное обеспечение с учетом всех своих единоличных "фи"?

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