Обсуждаем, какой движок самый плохой - здесь.
Токсим, срёмся, диагностируем шизофрению и объявляем крысу в хате тоже здесь.
Бесконечный тред для свободного общения.
Токсим, срёмся, диагностируем шизофрению и объявляем крысу в хате тоже здесь.
Бесконечный тред для свободного общения.
>>18973 (Del)
ключевое слово - без екс. сталкиваясь с проблемой оптимизации, екс архитектура перестает быть екс
это очевидно, когда ты с нуля пишешь екс игру, не используя готовый движок с прикрученным где-то сбоку ексом
ключевое слово - без екс. сталкиваясь с проблемой оптимизации, екс архитектура перестает быть екс
это очевидно, когда ты с нуля пишешь екс игру, не используя готовый движок с прикрученным где-то сбоку ексом
>>18974
Что?
Простой вопрос - каким образом концепция ецс(ентити, компонент система) накладывает ограничения на оптимизацию?
Пример?
Покажи такую оптимизацию, которая вынуждает ецс перестать следовать канонам ецс.
Какая разница готовый движок или твой личный? Это как то меняет концепцию ецс?
Что?
Простой вопрос - каким образом концепция ецс(ентити, компонент система) накладывает ограничения на оптимизацию?
> сталкиваясь с проблемой оптимизации, екс архитектура перестает быть екс
Пример?
Покажи такую оптимизацию, которая вынуждает ецс перестать следовать канонам ецс.
> это очевидно, когда ты с нуля пишешь екс игру, не используя готовый движок с прикрученным где-то сбоку ексом
Какая разница готовый движок или твой личный? Это как то меняет концепцию ецс?
>>18975
в готовом не ECS движке архитектура уже не ECS. ECS там это просто гиммик
в настоящей ECS архитектуре всё делается через ECS
в том числе рендеринг объектов. подтянул все рендераблы, отрендерил
подтянул все физически сущности, отсимулировал столкновения
и т.д.
>Какая разница готовый движок или твой личный?
в готовом не ECS движке архитектура уже не ECS. ECS там это просто гиммик
в настоящей ECS архитектуре всё делается через ECS
в том числе рендеринг объектов. подтянул все рендераблы, отрендерил
подтянул все физически сущности, отсимулировал столкновения
и т.д.
>>18982
Ецс это архитектура в которой есть такие сущности: ентити компонент систем.
Если программный код оргагизован в соответствии с этой концепцией, то его логично назвать ецс.
В чем противоречия юнитевского ецс или беви этоц концепции?
Ты сказал? Лол.
А если у меня в игре кор геймплей логика сделана на ецс, логика интерфейса на MVP, контролы интерфейса на юнитевской компонентной системе, рендер и физика вообще проприетарная хуйня с совершенно другим проектированием и использованием статики и синглтонов, то получается у меня игра сделана ни на ооп, ни на ецс, а и то и другое там - гиммик и нещитова?
А на что влияет то что нечто является нещитовым гиммиком? У этого есть негативные стороны помимо того, что ты скажешь, что это гиммик?
То есть если я прочитаю какую-то статаью по ецс с примером реализации какой-то механики - применить я это не смогу потому что у меня "не ецс, а гиммик"?
Или если я прочитаю про вариант организации фабрики для попапов - соответственно тоже не смогу применить потому что у меня и не ооп толком?
Кстати а вот мы сделали например и рендер, и физику, и геймплей, флоу игровой на ецс например. Но чтобы проиграть звук - надо дернуть нативное апи. А в нативном апи там ваще не ецс, а кривой косой набор функций. Значит тоже не ецс уже?
Нет никакой "настоящей ецс архитектуры", да и вообще какой либо ещё, есть набор абстрактных идей и конкретных практик по организации кода.
Если ты какими-то из них пользуешься для реализации какого-то кода, то ты модешь сказать что ты им пользуешься и это другому программисту даст в общих чертах понимание устроцства твоего проекта. А также позволит тебе посмотреть какие-то ещё практики и идеи по поддержке этого подхода и применить их.
Обрати внимание на аыделенное жирным - какого-то кода.
Ты можешь всю игру сделать на ецс, можешь кор геймплей, а можешь и вовсе какие-то фрагменты геймплея. Это никоим обращом не менчет то, что этот кусок кода можно впринципе попытаться классифицировать и это даст результат.
А какие-то понятия существующие в вакууме и твой вердикт гиммик или не гиммик не играет роли
> в готовом не ECS движке архитектура уже не ECS. ECS там это просто гиммик
Ецс это архитектура в которой есть такие сущности: ентити компонент систем.
Если программный код оргагизован в соответствии с этой концепцией, то его логично назвать ецс.
В чем противоречия юнитевского ецс или беви этоц концепции?
> в настоящей ECS архитектуре всё делается через ECS
> в том числе рендеринг объектов. подтянул все рендераблы, отрендерил
> подтянул все физически сущности, отсимулировал столкновения
> и т.д.
Ты сказал? Лол.
А если у меня в игре кор геймплей логика сделана на ецс, логика интерфейса на MVP, контролы интерфейса на юнитевской компонентной системе, рендер и физика вообще проприетарная хуйня с совершенно другим проектированием и использованием статики и синглтонов, то получается у меня игра сделана ни на ооп, ни на ецс, а и то и другое там - гиммик и нещитова?
А на что влияет то что нечто является нещитовым гиммиком? У этого есть негативные стороны помимо того, что ты скажешь, что это гиммик?
То есть если я прочитаю какую-то статаью по ецс с примером реализации какой-то механики - применить я это не смогу потому что у меня "не ецс, а гиммик"?
Или если я прочитаю про вариант организации фабрики для попапов - соответственно тоже не смогу применить потому что у меня и не ооп толком?
Кстати а вот мы сделали например и рендер, и физику, и геймплей, флоу игровой на ецс например. Но чтобы проиграть звук - надо дернуть нативное апи. А в нативном апи там ваще не ецс, а кривой косой набор функций. Значит тоже не ецс уже?
Нет никакой "настоящей ецс архитектуры", да и вообще какой либо ещё, есть набор абстрактных идей и конкретных практик по организации кода.
Если ты какими-то из них пользуешься для реализации какого-то кода, то ты модешь сказать что ты им пользуешься и это другому программисту даст в общих чертах понимание устроцства твоего проекта. А также позволит тебе посмотреть какие-то ещё практики и идеи по поддержке этого подхода и применить их.
Обрати внимание на аыделенное жирным - какого-то кода.
Ты можешь всю игру сделать на ецс, можешь кор геймплей, а можешь и вовсе какие-то фрагменты геймплея. Это никоим обращом не менчет то, что этот кусок кода можно впринципе попытаться классифицировать и это даст результат.
А какие-то понятия существующие в вакууме и твой вердикт гиммик или не гиммик не играет роли
>>18982
Ецс это архитектура в которой есть такие сущности: ентити компонент систем.
Если программный код оргагизован в соответствии с этой концепцией, то его логично назвать ецс.
В чем противоречия юнитевского ецс или беви этоц концепции?
Ты сказал? Лол.
А если у меня в игре кор геймплей логика сделана на ецс, логика интерфейса на MVP, контролы интерфейса на юнитевской компонентной системе, рендер и физика вообще проприетарная хуйня с совершенно другим проектированием и использованием статики и синглтонов, то получается у меня игра сделана ни на ооп, ни на ецс, а и то и другое там - гиммик и нещитова?
А на что влияет то что нечто является нещитовым гиммиком? У этого есть негативные стороны помимо того, что ты скажешь, что это гиммик?
То есть если я прочитаю какую-то статаью по ецс с примером реализации какой-то механики - применить я это не смогу потому что у меня "не ецс, а гиммик"?
Или если я прочитаю про вариант организации фабрики для попапов - соответственно тоже не смогу применить потому что у меня и не ооп толком?
Кстати а вот мы сделали например и рендер, и физику, и геймплей, флоу игровой на ецс например. Но чтобы проиграть звук - надо дернуть нативное апи. А в нативном апи там ваще не ецс, а кривой косой набор функций. Значит тоже не ецс уже?
Нет никакой "настоящей ецс архитектуры", да и вообще какой либо ещё, есть набор абстрактных идей и конкретных практик по организации кода.
Если ты какими-то из них пользуешься для реализации какого-то кода, то ты модешь сказать что ты им пользуешься и это другому программисту даст в общих чертах понимание устроцства твоего проекта. А также позволит тебе посмотреть какие-то ещё практики и идеи по поддержке этого подхода и применить их.
Обрати внимание на аыделенное жирным - какого-то кода.
Ты можешь всю игру сделать на ецс, можешь кор геймплей, а можешь и вовсе какие-то фрагменты геймплея. Это никоим обращом не менчет то, что этот кусок кода можно впринципе попытаться классифицировать и это даст результат.
А какие-то понятия существующие в вакууме и твой вердикт гиммик или не гиммик не играет роли
> в готовом не ECS движке архитектура уже не ECS. ECS там это просто гиммик
Ецс это архитектура в которой есть такие сущности: ентити компонент систем.
Если программный код оргагизован в соответствии с этой концепцией, то его логично назвать ецс.
В чем противоречия юнитевского ецс или беви этоц концепции?
> в настоящей ECS архитектуре всё делается через ECS
> в том числе рендеринг объектов. подтянул все рендераблы, отрендерил
> подтянул все физически сущности, отсимулировал столкновения
> и т.д.
Ты сказал? Лол.
А если у меня в игре кор геймплей логика сделана на ецс, логика интерфейса на MVP, контролы интерфейса на юнитевской компонентной системе, рендер и физика вообще проприетарная хуйня с совершенно другим проектированием и использованием статики и синглтонов, то получается у меня игра сделана ни на ооп, ни на ецс, а и то и другое там - гиммик и нещитова?
А на что влияет то что нечто является нещитовым гиммиком? У этого есть негативные стороны помимо того, что ты скажешь, что это гиммик?
То есть если я прочитаю какую-то статаью по ецс с примером реализации какой-то механики - применить я это не смогу потому что у меня "не ецс, а гиммик"?
Или если я прочитаю про вариант организации фабрики для попапов - соответственно тоже не смогу применить потому что у меня и не ооп толком?
Кстати а вот мы сделали например и рендер, и физику, и геймплей, флоу игровой на ецс например. Но чтобы проиграть звук - надо дернуть нативное апи. А в нативном апи там ваще не ецс, а кривой косой набор функций. Значит тоже не ецс уже?
Нет никакой "настоящей ецс архитектуры", да и вообще какой либо ещё, есть набор абстрактных идей и конкретных практик по организации кода.
Если ты какими-то из них пользуешься для реализации какого-то кода, то ты модешь сказать что ты им пользуешься и это другому программисту даст в общих чертах понимание устроцства твоего проекта. А также позволит тебе посмотреть какие-то ещё практики и идеи по поддержке этого подхода и применить их.
Обрати внимание на аыделенное жирным - какого-то кода.
Ты можешь всю игру сделать на ецс, можешь кор геймплей, а можешь и вовсе какие-то фрагменты геймплея. Это никоим обращом не менчет то, что этот кусок кода можно впринципе попытаться классифицировать и это даст результат.
А какие-то понятия существующие в вакууме и твой вердикт гиммик или не гиммик не играет роли
>>18988
да. твоя игра - ООП с незначительными вкраплениями ECS
хочешь познать настоящий ECS - пиши с нуля игру на ECS, без движков. в процессе 95% твоего ECS кода перейдет в категорию "это на ECS не делается, ECS не для этого"
> А если у меня в игре кор геймплей логика сделана на ецс, логика интерфейса на MVP, контролы интерфейса на юнитевской компонентной системе, рендер и физика вообще проприетарная хуйня с совершенно другим проектированием и использованием статики и синглтонов, то получается у меня игра сделана ни на ооп, ни на ецс, а и то и другое там - гиммик и нещитова?
да. твоя игра - ООП с незначительными вкраплениями ECS
хочешь познать настоящий ECS - пиши с нуля игру на ECS, без движков. в процессе 95% твоего ECS кода перейдет в категорию "это на ECS не делается, ECS не для этого"
>>18993
Хорошо. Так а минусы будут?
Мой основной вопрос был - хорошо, не ецс а гиммик. А на что это влияет?
Дополнительный вопрос(к оригинальному твоему посту) - какие проблемы с производительностью заложены в концепции ецс и как отсутствие ецс помогает их обойти?
Ведь "это на ецс не делается" это как правило не вопрос производителньости, а вопрос архитектуры, фабрики с диаем это не то чтобы более быстроее решение, чем ецс
Хорошо. Так а минусы будут?
Мой основной вопрос был - хорошо, не ецс а гиммик. А на что это влияет?
Дополнительный вопрос(к оригинальному твоему посту) - какие проблемы с производительностью заложены в концепции ецс и как отсутствие ецс помогает их обойти?
Ведь "это на ецс не делается" это как правило не вопрос производителньости, а вопрос архитектуры, фабрики с диаем это не то чтобы более быстроее решение, чем ецс
>>18995
ни на что не влияет. я же не писал, что екс это плохо. это как настоящая стейт машина: хочется где-то применить, но постоянно хуйня какая-то возникает, и в итоге проще выкинуть и переписать без неё
екс это про итерирование по массивам, и чем оно более дробное и изолированное - тем ексней. ты теряешь в производительности из-за постоянного итерирования по близким по смыслу массивам в разных системах. ну или склеивать в одну гигасистему, которая имеет гигантский апдейт метод с кучей проверок внутри. это противоречит философии екс
ни на что не влияет. я же не писал, что екс это плохо. это как настоящая стейт машина: хочется где-то применить, но постоянно хуйня какая-то возникает, и в итоге проще выкинуть и переписать без неё
> какие проблемы с производительностью заложены в концепции ецс и как отсутствие ецс помогает их обойти?
екс это про итерирование по массивам, и чем оно более дробное и изолированное - тем ексней. ты теряешь в производительности из-за постоянного итерирования по близким по смыслу массивам в разных системах. ну или склеивать в одну гигасистему, которая имеет гигантский апдейт метод с кучей проверок внутри. это противоречит философии екс
>>18999
Нет, я спрашивал что влияет гиммик или не гиммик. Ты говоришь - в движке там не настоящий ецс, а гиммик. Я и спрашиваю - а на что это влияет?
Вот я говорю например - на ецс можно заебись производителньости достигать, в юнити ецс фреймворк очень производительный.
Ты отвечаешь - там ецс это гиммик и не настоящий ецс. Ну... э... и что? В чем ценность термина гиммик, что он должен обозначать, в чем его смысл?
Блен, ну я не понимаю просто тебя.
Нету ничего настоящего. Есть просто идеи и практики и всё, и не более.
Игрушечнач стецт машина, или настоящая - эта терминология не имеет смысла. Если какая то часть кода похода на стейт машину - то эта часть кода похоже на стейт машину и скорее всего правильно будет её называть стецт машиной при общении с другими программистами и поиске каких-то решений проблем или полезных практик.
Ты же не будешь искать "как в гиммике игрушечной стейт машине сделать контроллер анимаций персонажа"? Нет конечно.
Поэтому и наличие этого термина - бесполезно. Поэтому я и не понимаю твоего исходного сообщения
Давай вспомним вообще с чего все началось - ты сказал на ецс хуево делать оптимизацию.
Я уточнил что именно
Ты сказал - нуу выборку по данным
Я сказал - да нет, заебись, на ецс можно дод реализовать и выборки будут перыормить также как проход по линейному массиву
Ты ответил - это не настоящий ецс, а гиммик
Эаэаээаээа
Это в чем вообще смысл того что ты пишешь? Я НЕ ПОНИМАЮ
У меня простая позиуия - если что-то выглядит как х, любой фрагмент кода, то оно выглядит как х. Называть этт не намтоящим потому что другой кусок кода в проекте не выглядит так - просто бред
А ты уверен? То что ты описал - добровольный путь к кеш миссам и невозможность многопотока.
И главный вопрос - ок, отказываемся от ецс, чем твое решение будет производительнее в итерировании? У тебя точно также будет вопрос итерирования по разным сущностям абсолютно такой же, хоть ецс хоть ооп хоть что ты выдумаешь.
> ни на что не влияет. я же не писал, что екс это плохо.
Нет, я спрашивал что влияет гиммик или не гиммик. Ты говоришь - в движке там не настоящий ецс, а гиммик. Я и спрашиваю - а на что это влияет?
Вот я говорю например - на ецс можно заебись производителньости достигать, в юнити ецс фреймворк очень производительный.
Ты отвечаешь - там ецс это гиммик и не настоящий ецс. Ну... э... и что? В чем ценность термина гиммик, что он должен обозначать, в чем его смысл?
> это как настоящая стейт машина
Блен, ну я не понимаю просто тебя.
Нету ничего настоящего. Есть просто идеи и практики и всё, и не более.
Игрушечнач стецт машина, или настоящая - эта терминология не имеет смысла. Если какая то часть кода похода на стейт машину - то эта часть кода похоже на стейт машину и скорее всего правильно будет её называть стецт машиной при общении с другими программистами и поиске каких-то решений проблем или полезных практик.
Ты же не будешь искать "как в гиммике игрушечной стейт машине сделать контроллер анимаций персонажа"? Нет конечно.
Поэтому и наличие этого термина - бесполезно. Поэтому я и не понимаю твоего исходного сообщения
Давай вспомним вообще с чего все началось - ты сказал на ецс хуево делать оптимизацию.
Я уточнил что именно
Ты сказал - нуу выборку по данным
Я сказал - да нет, заебись, на ецс можно дод реализовать и выборки будут перыормить также как проход по линейному массиву
Ты ответил - это не настоящий ецс, а гиммик
Эаэаээаээа
Это в чем вообще смысл того что ты пишешь? Я НЕ ПОНИМАЮ
У меня простая позиуия - если что-то выглядит как х, любой фрагмент кода, то оно выглядит как х. Называть этт не намтоящим потому что другой кусок кода в проекте не выглядит так - просто бред
> ты теряешь в производительности из-за постоянного итерирования по близким по смыслу массивам в разных системах. ну или склеивать в одну гигасистему, которая имеет гигантский апдейт метод с кучей проверок внутри.
А ты уверен? То что ты описал - добровольный путь к кеш миссам и невозможность многопотока.
И главный вопрос - ок, отказываемся от ецс, чем твое решение будет производительнее в итерировании? У тебя точно также будет вопрос итерирования по разным сущностям абсолютно такой же, хоть ецс хоть ооп хоть что ты выдумаешь.
>>18999
Нет, я спрашивал что влияет гиммик или не гиммик. Ты говоришь - в движке там не настоящий ецс, а гиммик. Я и спрашиваю - а на что это влияет?
Вот я говорю например - на ецс можно заебись производителньости достигать, в юнити ецс фреймворк очень производительный.
Ты отвечаешь - там ецс это гиммик и не настоящий ецс. Ну... э... и что? В чем ценность термина гиммик, что он должен обозначать, в чем его смысл?
Блен, ну я не понимаю просто тебя.
Нету ничего настоящего. Есть просто идеи и практики и всё, и не более.
Игрушечнач стецт машина, или настоящая - эта терминология не имеет смысла. Если какая то часть кода похода на стейт машину - то эта часть кода похоже на стейт машину и скорее всего правильно будет её называть стецт машиной при общении с другими программистами и поиске каких-то решений проблем или полезных практик.
Ты же не будешь искать "как в гиммике игрушечной стейт машине сделать контроллер анимаций персонажа"? Нет конечно.
Поэтому и наличие этого термина - бесполезно. Поэтому я и не понимаю твоего исходного сообщения
Давай вспомним вообще с чего все началось - ты сказал на ецс хуево делать оптимизацию.
Я уточнил что именно
Ты сказал - нуу выборку по данным
Я сказал - да нет, заебись, на ецс можно дод реализовать и выборки будут перыормить также как проход по линейному массиву
Ты ответил - это не настоящий ецс, а гиммик
Эаэаээаээа
Это в чем вообще смысл того что ты пишешь? Я НЕ ПОНИМАЮ
У меня простая позиуия - если что-то выглядит как х, любой фрагмент кода, то оно выглядит как х. Называть этт не намтоящим потому что другой кусок кода в проекте не выглядит так - просто бред
А ты уверен? То что ты описал - добровольный путь к кеш миссам и невозможность многопотока.
И главный вопрос - ок, отказываемся от ецс, чем твое решение будет производительнее в итерировании? У тебя точно также будет вопрос итерирования по разным сущностям абсолютно такой же, хоть ецс хоть ооп хоть что ты выдумаешь.
> ни на что не влияет. я же не писал, что екс это плохо.
Нет, я спрашивал что влияет гиммик или не гиммик. Ты говоришь - в движке там не настоящий ецс, а гиммик. Я и спрашиваю - а на что это влияет?
Вот я говорю например - на ецс можно заебись производителньости достигать, в юнити ецс фреймворк очень производительный.
Ты отвечаешь - там ецс это гиммик и не настоящий ецс. Ну... э... и что? В чем ценность термина гиммик, что он должен обозначать, в чем его смысл?
> это как настоящая стейт машина
Блен, ну я не понимаю просто тебя.
Нету ничего настоящего. Есть просто идеи и практики и всё, и не более.
Игрушечнач стецт машина, или настоящая - эта терминология не имеет смысла. Если какая то часть кода похода на стейт машину - то эта часть кода похоже на стейт машину и скорее всего правильно будет её называть стецт машиной при общении с другими программистами и поиске каких-то решений проблем или полезных практик.
Ты же не будешь искать "как в гиммике игрушечной стейт машине сделать контроллер анимаций персонажа"? Нет конечно.
Поэтому и наличие этого термина - бесполезно. Поэтому я и не понимаю твоего исходного сообщения
Давай вспомним вообще с чего все началось - ты сказал на ецс хуево делать оптимизацию.
Я уточнил что именно
Ты сказал - нуу выборку по данным
Я сказал - да нет, заебись, на ецс можно дод реализовать и выборки будут перыормить также как проход по линейному массиву
Ты ответил - это не настоящий ецс, а гиммик
Эаэаээаээа
Это в чем вообще смысл того что ты пишешь? Я НЕ ПОНИМАЮ
У меня простая позиуия - если что-то выглядит как х, любой фрагмент кода, то оно выглядит как х. Называть этт не намтоящим потому что другой кусок кода в проекте не выглядит так - просто бред
> ты теряешь в производительности из-за постоянного итерирования по близким по смыслу массивам в разных системах. ну или склеивать в одну гигасистему, которая имеет гигантский апдейт метод с кучей проверок внутри.
А ты уверен? То что ты описал - добровольный путь к кеш миссам и невозможность многопотока.
И главный вопрос - ок, отказываемся от ецс, чем твое решение будет производительнее в итерировании? У тебя точно также будет вопрос итерирования по разным сущностям абсолютно такой же, хоть ецс хоть ооп хоть что ты выдумаешь.
>>19004
настоящая стейт машина - машина, которая возвращает другой стейт, удаляя старый стейт. дискретная стейт машина. но в реальной задаче ты начинаешь серить туда костылями с иерархиями, стеками, глобальными переменными, до тех пор, пока не задашься вопросом - а нахуя мне этот гиммик, если без него будет проще и лучше? это и есть определение гиммиковости
гиммиковый екс - когда ты в ущерб архитектуре организовываешь себе екс песочницу, где играешься в екс, потихоньку вытаскивая оттуда свой бывший ексным код в категорию модулей которые "не подходят для екс". заметь как ты сразу задефолтился про "гуй, рендеринг, скрипты" что не надо это делать на екс. хотя как ты это решил? прочитал как другие так пишут? или сам пробовал? в юнити с прикрученным сбоку екс плагином ты не мог этого сделать. а значит прочитал как другие так говорят, и повторяешь за другими. только вне движка можно сделать полноценный проект на екс. потому что екс это компетенция движка, а не игры
>эта терминология не имеет смысла
настоящая стейт машина - машина, которая возвращает другой стейт, удаляя старый стейт. дискретная стейт машина. но в реальной задаче ты начинаешь серить туда костылями с иерархиями, стеками, глобальными переменными, до тех пор, пока не задашься вопросом - а нахуя мне этот гиммик, если без него будет проще и лучше? это и есть определение гиммиковости
гиммиковый екс - когда ты в ущерб архитектуре организовываешь себе екс песочницу, где играешься в екс, потихоньку вытаскивая оттуда свой бывший ексным код в категорию модулей которые "не подходят для екс". заметь как ты сразу задефолтился про "гуй, рендеринг, скрипты" что не надо это делать на екс. хотя как ты это решил? прочитал как другие так пишут? или сам пробовал? в юнити с прикрученным сбоку екс плагином ты не мог этого сделать. а значит прочитал как другие так говорят, и повторяешь за другими. только вне движка можно сделать полноценный проект на екс. потому что екс это компетенция движка, а не игры
>>19009
Вот, всё, ты дал чёткое определение. С этим можно работать.
А вот тут ты сильно ошибаешься.
"В ущерб архитектуре" - а где ущерб? А в ущерб ли? А может не в ущерб? Как ты понял, что в ущерб, и что там у меня? А может быть я применяю ецс там где нужно?
Это тоже очень странное утверждение.
Мне кажется, надо делать задачу таким способом, который для нее подходит.
Подходит ецс - делай на ецс. Не подходит ецс - делай не на ецс.
Если в процессе выяснилось, что не подходит - ну, можно порефакторить, если время на это есть и оно того стоит.
Ну, я не ждунище, у меня есть какой-то опыт. Мой опыт мне подсказывает это.
Может у тебя есть хороший вариант реализации гуя на ецс. Мне она не известна и есть проблемы которые мне кажется будут у такого подхода.
Лол. Мог. Что угодно можно. А в чем проблема?
Просто обычно берут лучший доступный инструмент под задачу, а не задачу натягивают на инструмент.
Под инструментом я разумеется подразумеваю не либу которую можно подключить, а набор практик и архитектурных решений, которыми можно оперировать для решения задачи.
По поводу этого выше ответил
У тебя в движке доступен язык программирования, на котором ты можешь написать что угодно.
"Полноценный проект на ецс". А я например делаю не полноценный. И что?
В чём смысл этого утверждения? Какую полезную смысловую нагрузку оно несёт?
Грань между движком и игрой размыта. Где кончается движок и начинается игра? Тупейший вопрос в обсуждаемом нами вопросе.
Движок закрыт, где начинается проприетарщина - там и кончается игра, да? Так лол, у тебя есть язык программирования, на котором ты можешь написать что угодно.
Это какое-то переливание из пустого в порожнее. Это настоящий ецс, это игрушечный, а это гиммик, а это полноценный ецс.
Да поебать вообще как ты это называешь так то.
Ты мне вот на главный вопрос ответь лучше, мне только жто было интересно
>>19004
>>18995
И давай сразу определимся, мы смотрим ограниченную задачу организации игровой логики. Нам совершенно похуй что там с другими частями игры, и настоящий это ецс или инрушечный, вот мы сделали геймплей на ецс и в нем все на ецс. Ты говоришь, ецс накладывает ограничения по оптимизации. Какие и как не-ецс поможет? Ты упомянал итерирования по разным сущностям - я тебе ответил, что на ецс ты можешь сделать так, что будешь итерировать по линейным массивам без каких то проверок. Есть какой то вариант итерации быстрее и он не доступен с ецс, но доступен без ецс?
Ток не надо опять про мегасистему с ифами как пример вырождения ецс ради оптимизации плиз, это не то что несерьезно, это просто пиздец и выстрел себе в хуй с точки зрения оптимизации будет.
> - а нахуя мне этот гиммик, если без него будет проще и лучше? это и есть определение гиммиковости
Вот, всё, ты дал чёткое определение. С этим можно работать.
> гиммиковый екс - когда ты в ущерб архитектуре организовываешь себе екс песочницу, где играешься в екс
А вот тут ты сильно ошибаешься.
"В ущерб архитектуре" - а где ущерб? А в ущерб ли? А может не в ущерб? Как ты понял, что в ущерб, и что там у меня? А может быть я применяю ецс там где нужно?
> потихоньку вытаскивая оттуда свой бывший ексным код в категорию модулей которые "не подходят для екс".
Это тоже очень странное утверждение.
Мне кажется, надо делать задачу таким способом, который для нее подходит.
Подходит ецс - делай на ецс. Не подходит ецс - делай не на ецс.
Если в процессе выяснилось, что не подходит - ну, можно порефакторить, если время на это есть и оно того стоит.
> заметь как ты сразу задефолтился про "гуй, рендеринг, скрипты" что не надо это делать на екс. хотя как ты это решил?
> прочитал как другие так пишут? или сам пробовал?
Ну, я не ждунище, у меня есть какой-то опыт. Мой опыт мне подсказывает это.
Может у тебя есть хороший вариант реализации гуя на ецс. Мне она не известна и есть проблемы которые мне кажется будут у такого подхода.
> в юнити с прикрученным сбоку екс плагином ты не мог этого сделать.
Лол. Мог. Что угодно можно. А в чем проблема?
Просто обычно берут лучший доступный инструмент под задачу, а не задачу натягивают на инструмент.
Под инструментом я разумеется подразумеваю не либу которую можно подключить, а набор практик и архитектурных решений, которыми можно оперировать для решения задачи.
> а значит прочитал как другие так говорят, и повторяешь за другими.
По поводу этого выше ответил
> только вне движка можно сделать полноценный проект на екс.
У тебя в движке доступен язык программирования, на котором ты можешь написать что угодно.
"Полноценный проект на ецс". А я например делаю не полноценный. И что?
В чём смысл этого утверждения? Какую полезную смысловую нагрузку оно несёт?
> потому что екс это компетенция движка, а не игры
Грань между движком и игрой размыта. Где кончается движок и начинается игра? Тупейший вопрос в обсуждаемом нами вопросе.
Движок закрыт, где начинается проприетарщина - там и кончается игра, да? Так лол, у тебя есть язык программирования, на котором ты можешь написать что угодно.
Это какое-то переливание из пустого в порожнее. Это настоящий ецс, это игрушечный, а это гиммик, а это полноценный ецс.
Да поебать вообще как ты это называешь так то.
Ты мне вот на главный вопрос ответь лучше, мне только жто было интересно
>>19004
> И главный вопрос - ок, отказываемся от ецс, чем твое решение будет производительнее в итерировании? У тебя точно также будет вопрос итерирования по разным сущностям абсолютно такой же, хоть ецс хоть ооп хоть что ты выдумаешь.
>>18995
> какие проблемы с производительностью заложены в концепции ецс и как отсутствие ецс помогает их обойти?
И давай сразу определимся, мы смотрим ограниченную задачу организации игровой логики. Нам совершенно похуй что там с другими частями игры, и настоящий это ецс или инрушечный, вот мы сделали геймплей на ецс и в нем все на ецс. Ты говоришь, ецс накладывает ограничения по оптимизации. Какие и как не-ецс поможет? Ты упомянал итерирования по разным сущностям - я тебе ответил, что на ецс ты можешь сделать так, что будешь итерировать по линейным массивам без каких то проверок. Есть какой то вариант итерации быстрее и он не доступен с ецс, но доступен без ецс?
Ток не надо опять про мегасистему с ифами как пример вырождения ецс ради оптимизации плиз, это не то что несерьезно, это просто пиздец и выстрел себе в хуй с точки зрения оптимизации будет.
>>19009
Вот, всё, ты дал чёткое определение. С этим можно работать.
А вот тут ты сильно ошибаешься.
"В ущерб архитектуре" - а где ущерб? А в ущерб ли? А может не в ущерб? Как ты понял, что в ущерб, и что там у меня? А может быть я применяю ецс там где нужно?
Это тоже очень странное утверждение.
Мне кажется, надо делать задачу таким способом, который для нее подходит.
Подходит ецс - делай на ецс. Не подходит ецс - делай не на ецс.
Если в процессе выяснилось, что не подходит - ну, можно порефакторить, если время на это есть и оно того стоит.
Ну, я не ждунище, у меня есть какой-то опыт. Мой опыт мне подсказывает это.
Может у тебя есть хороший вариант реализации гуя на ецс. Мне она не известна и есть проблемы которые мне кажется будут у такого подхода.
Лол. Мог. Что угодно можно. А в чем проблема?
Просто обычно берут лучший доступный инструмент под задачу, а не задачу натягивают на инструмент.
Под инструментом я разумеется подразумеваю не либу которую можно подключить, а набор практик и архитектурных решений, которыми можно оперировать для решения задачи.
По поводу этого выше ответил
У тебя в движке доступен язык программирования, на котором ты можешь написать что угодно.
"Полноценный проект на ецс". А я например делаю не полноценный. И что?
В чём смысл этого утверждения? Какую полезную смысловую нагрузку оно несёт?
Грань между движком и игрой размыта. Где кончается движок и начинается игра? Тупейший вопрос в обсуждаемом нами вопросе.
Движок закрыт, где начинается проприетарщина - там и кончается игра, да? Так лол, у тебя есть язык программирования, на котором ты можешь написать что угодно.
Это какое-то переливание из пустого в порожнее. Это настоящий ецс, это игрушечный, а это гиммик, а это полноценный ецс.
Да поебать вообще как ты это называешь так то.
Ты мне вот на главный вопрос ответь лучше, мне только жто было интересно
>>19004
>>18995
И давай сразу определимся, мы смотрим ограниченную задачу организации игровой логики. Нам совершенно похуй что там с другими частями игры, и настоящий это ецс или инрушечный, вот мы сделали геймплей на ецс и в нем все на ецс. Ты говоришь, ецс накладывает ограничения по оптимизации. Какие и как не-ецс поможет? Ты упомянал итерирования по разным сущностям - я тебе ответил, что на ецс ты можешь сделать так, что будешь итерировать по линейным массивам без каких то проверок. Есть какой то вариант итерации быстрее и он не доступен с ецс, но доступен без ецс?
Ток не надо опять про мегасистему с ифами как пример вырождения ецс ради оптимизации плиз, это не то что несерьезно, это просто пиздец и выстрел себе в хуй с точки зрения оптимизации будет.
> - а нахуя мне этот гиммик, если без него будет проще и лучше? это и есть определение гиммиковости
Вот, всё, ты дал чёткое определение. С этим можно работать.
> гиммиковый екс - когда ты в ущерб архитектуре организовываешь себе екс песочницу, где играешься в екс
А вот тут ты сильно ошибаешься.
"В ущерб архитектуре" - а где ущерб? А в ущерб ли? А может не в ущерб? Как ты понял, что в ущерб, и что там у меня? А может быть я применяю ецс там где нужно?
> потихоньку вытаскивая оттуда свой бывший ексным код в категорию модулей которые "не подходят для екс".
Это тоже очень странное утверждение.
Мне кажется, надо делать задачу таким способом, который для нее подходит.
Подходит ецс - делай на ецс. Не подходит ецс - делай не на ецс.
Если в процессе выяснилось, что не подходит - ну, можно порефакторить, если время на это есть и оно того стоит.
> заметь как ты сразу задефолтился про "гуй, рендеринг, скрипты" что не надо это делать на екс. хотя как ты это решил?
> прочитал как другие так пишут? или сам пробовал?
Ну, я не ждунище, у меня есть какой-то опыт. Мой опыт мне подсказывает это.
Может у тебя есть хороший вариант реализации гуя на ецс. Мне она не известна и есть проблемы которые мне кажется будут у такого подхода.
> в юнити с прикрученным сбоку екс плагином ты не мог этого сделать.
Лол. Мог. Что угодно можно. А в чем проблема?
Просто обычно берут лучший доступный инструмент под задачу, а не задачу натягивают на инструмент.
Под инструментом я разумеется подразумеваю не либу которую можно подключить, а набор практик и архитектурных решений, которыми можно оперировать для решения задачи.
> а значит прочитал как другие так говорят, и повторяешь за другими.
По поводу этого выше ответил
> только вне движка можно сделать полноценный проект на екс.
У тебя в движке доступен язык программирования, на котором ты можешь написать что угодно.
"Полноценный проект на ецс". А я например делаю не полноценный. И что?
В чём смысл этого утверждения? Какую полезную смысловую нагрузку оно несёт?
> потому что екс это компетенция движка, а не игры
Грань между движком и игрой размыта. Где кончается движок и начинается игра? Тупейший вопрос в обсуждаемом нами вопросе.
Движок закрыт, где начинается проприетарщина - там и кончается игра, да? Так лол, у тебя есть язык программирования, на котором ты можешь написать что угодно.
Это какое-то переливание из пустого в порожнее. Это настоящий ецс, это игрушечный, а это гиммик, а это полноценный ецс.
Да поебать вообще как ты это называешь так то.
Ты мне вот на главный вопрос ответь лучше, мне только жто было интересно
>>19004
> И главный вопрос - ок, отказываемся от ецс, чем твое решение будет производительнее в итерировании? У тебя точно также будет вопрос итерирования по разным сущностям абсолютно такой же, хоть ецс хоть ооп хоть что ты выдумаешь.
>>18995
> какие проблемы с производительностью заложены в концепции ецс и как отсутствие ецс помогает их обойти?
И давай сразу определимся, мы смотрим ограниченную задачу организации игровой логики. Нам совершенно похуй что там с другими частями игры, и настоящий это ецс или инрушечный, вот мы сделали геймплей на ецс и в нем все на ецс. Ты говоришь, ецс накладывает ограничения по оптимизации. Какие и как не-ецс поможет? Ты упомянал итерирования по разным сущностям - я тебе ответил, что на ецс ты можешь сделать так, что будешь итерировать по линейным массивам без каких то проверок. Есть какой то вариант итерации быстрее и он не доступен с ецс, но доступен без ецс?
Ток не надо опять про мегасистему с ифами как пример вырождения ецс ради оптимизации плиз, это не то что несерьезно, это просто пиздец и выстрел себе в хуй с точки зрения оптимизации будет.
>>19030
тем что ты не итерируешься и не подготавливаешь себе екс-песочницу чтобы поексииться по ней
ну что поделать, если не хочешь 50 тысяч раз итерироваться по всему миру, сначала чтобы сделать всем пук, а затем чтобы сделать всем среньк?. и ведь каждый кадр нужно пересобирать эти массивы для ексенья по ним, потому что мир динамический и игрок двигается, загружает-выгружает чанки и т.д.
> чем твое решение будет производительнее в итерировании?
тем что ты не итерируешься и не подготавливаешь себе екс-песочницу чтобы поексииться по ней
>Ток не надо опять про мегасистему с ифами как пример вырождения ецс ради оптимизации плиз
ну что поделать, если не хочешь 50 тысяч раз итерироваться по всему миру, сначала чтобы сделать всем пук, а затем чтобы сделать всем среньк?. и ведь каждый кадр нужно пересобирать эти массивы для ексенья по ним, потому что мир динамический и игрок двигается, загружает-выгружает чанки и т.д.
>>18868 (Del)
Причем тут быстрота екс и скорость билда, ты точно связан с программированием хоть как-то?
У bevy 300 либ зависимостей, поэтому первый билд идет долго, потом это все закешируется и при повторный билд будет быстрый.
А екс там и правда летает.
Причем тут быстрота екс и скорость билда, ты точно связан с программированием хоть как-то?
У bevy 300 либ зависимостей, поэтому первый билд идет долго, потом это все закешируется и при повторный билд будет быстрый.
А екс там и правда летает.
>>19031
Цепяюсь к словам, но че это за бред?
То есть твой тезис "не ецс лучше ецс тем что ты там не итерируешься"? А как ты там обрабатываешь свои игровые сущности?
В чем заключается "подготовка ецс песочницы"?
Ну это просто ты не знаешь как можно ецс под капотом устроить.
А я тебе уже выше писал как в дотсе сделано, там не надо делать такого каждый кадр. >>18973 (Del)
Это в целом довольно очевидный подход, думаю почти везде так и сделано.
При подгрузке-выгрузке действительно будут структурные изменения. Но неросредственно при добавлении уничтожении ентитей, а не каждый кадр, для этих структурных изменений тоже есть варианты как сделать, чтобы было не слишком дорого. И само собой никакой полной пересборки тут нету.
А без ецс получается можно сделать бесплатную подгрузку и выгрузку? Как?
Кстати
Хоть это и по сути не релевантно ецсу, но... А ты уверен что пересборка каких-то данных каждый кадр будет обязательно того не стоить?
Типа если у тебя много динамичных объектов в игре и надо делать операции связанные с поиском объектов в разных областях, то в начале кадра заполнить структуру данных типа квадтри будет выгодно, например, если таких операций много за кадр. Быстрее, чем этого не делать, и все объекты перкбирать, чтобы нацти ближайший.
> тем что ты не итерируешься
Цепяюсь к словам, но че это за бред?
То есть твой тезис "не ецс лучше ецс тем что ты там не итерируешься"? А как ты там обрабатываешь свои игровые сущности?
> и не подготавливаешь себе екс-песочницу чтобы поексииться по ней
В чем заключается "подготовка ецс песочницы"?
> ну что поделать, если не хочешь 50 тысяч раз итерироваться по всему миру, сначала чтобы сделать всем пук, а затем чтобы сделать всем среньк?. и ведь каждый кадр нужно пересобирать эти массивы для ексенья по ним
Ну это просто ты не знаешь как можно ецс под капотом устроить.
А я тебе уже выше писал как в дотсе сделано, там не надо делать такого каждый кадр. >>18973 (Del)
Это в целом довольно очевидный подход, думаю почти везде так и сделано.
> потому что мир динамический и игрок двигается, загружает-выгружает чанки и т.д.
При подгрузке-выгрузке действительно будут структурные изменения. Но неросредственно при добавлении уничтожении ентитей, а не каждый кадр, для этих структурных изменений тоже есть варианты как сделать, чтобы было не слишком дорого. И само собой никакой полной пересборки тут нету.
А без ецс получается можно сделать бесплатную подгрузку и выгрузку? Как?
Кстати
> и ведь каждый кадр нужно пересобирать эти массивы для ексенья по ним
Хоть это и по сути не релевантно ецсу, но... А ты уверен что пересборка каких-то данных каждый кадр будет обязательно того не стоить?
Типа если у тебя много динамичных объектов в игре и надо делать операции связанные с поиском объектов в разных областях, то в начале кадра заполнить структуру данных типа квадтри будет выгодно, например, если таких операций много за кадр. Быстрее, чем этого не делать, и все объекты перкбирать, чтобы нацти ближайший.
>>618624 (OP)
Сап аноны. Появилась идея сделать игру. Игра должна быть трёхмерной и при этом нетребовательной к железу, с графикой уровня Crab Game, может чуть лучше. При этом должна быть мультиплеерной. Мультиплеер на аренах, не опенворлд.
Программировать умею, но только на Scheme читал сикп в прошлом и больше ничего
Я так понимаю лучше всего взять юнити?
Сап аноны. Появилась идея сделать игру. Игра должна быть трёхмерной и при этом нетребовательной к железу, с графикой уровня Crab Game, может чуть лучше. При этом должна быть мультиплеерной. Мультиплеер на аренах, не опенворлд.
Программировать умею, но только на Scheme читал сикп в прошлом и больше ничего
Я так понимаю лучше всего взять юнити?
>>19167
Либо юнити, либо анрил, пох
Либо юнити, либо анрил, пох
>>19113
в том что тебе нужны структуры данных по которым ты будешь итерироваться в своем типа ексе. эти структуры нужно обновлять каждый кадр. ООП движок делает свои куллинги и оптимизации, а потом сверху на это еще раз делает вторую работу, чтобы побегать по сущностям ексом. у тебя игра делает две работы. в настоящей екс архитектуре делается одна работа. через екс.
>В чем заключается "подготовка ецс песочницы"?
в том что тебе нужны структуры данных по которым ты будешь итерироваться в своем типа ексе. эти структуры нужно обновлять каждый кадр. ООП движок делает свои куллинги и оптимизации, а потом сверху на это еще раз делает вторую работу, чтобы побегать по сущностям ексом. у тебя игра делает две работы. в настоящей екс архитектуре делается одна работа. через екс.
>>19175
Хз, я не знаю, это троллинг или что
Нет, не нужно.
И как это работает я уже описал в посте, который я линканул >>18973 (Del) и дополнительные пояснения про структурные изменения тут >>19113 перепечатывать не имеет смысла
Если не понятно что-то в этом объяснении или считаешь где-то там будет лишняя работа - процитируй и обоснуй почему.
Такой шизобред, пиздец.
У тебя в абсолютно любой игре будет сначала обработка игровой логики, потом рендеринг.
Абсолютно в любой игре у тебя по состоянию на конец игры будет набор каких-то данных, которые должен обработать графический движок и транслировать это в картинку.
Расскажи мне вот что:
В чем различия рендеринга, откуда берется оверхед, в подходе "с прикрученным сбоку ецс" и "тру ецс" или вовсе "не ецс", если в результате обработки игровой логики у тебя формируется одинаковый набор данных для графического движка?
В гиммик ецсе у тебя у тебя в структуре лежат данные описывающие нужную модель и материал и позицию... и в тру ецсе у тебя тоже самое. И не в ецсе у тебя точно также будет модель и материал в какой-то структур лежать.
Каким образом использование не гиммик ецс позволяет тут что то ускорить? Где будет повторная работа?
Хз, я не знаю, это троллинг или что
> эти структуры нужно обновлять каждый кадр
Нет, не нужно.
И как это работает я уже описал в посте, который я линканул >>18973 (Del) и дополнительные пояснения про структурные изменения тут >>19113 перепечатывать не имеет смысла
Если не понятно что-то в этом объяснении или считаешь где-то там будет лишняя работа - процитируй и обоснуй почему.
> ООП движок делает свои куллинги и оптимизации, а потом сверху на это еще раз делает вторую работу, чтобы побегать по сущностям ексом. у тебя игра делает две работы.
Такой шизобред, пиздец.
У тебя в абсолютно любой игре будет сначала обработка игровой логики, потом рендеринг.
Абсолютно в любой игре у тебя по состоянию на конец игры будет набор каких-то данных, которые должен обработать графический движок и транслировать это в картинку.
Расскажи мне вот что:
В чем различия рендеринга, откуда берется оверхед, в подходе "с прикрученным сбоку ецс" и "тру ецс" или вовсе "не ецс", если в результате обработки игровой логики у тебя формируется одинаковый набор данных для графического движка?
В гиммик ецсе у тебя у тебя в структуре лежат данные описывающие нужную модель и материал и позицию... и в тру ецсе у тебя тоже самое. И не в ецсе у тебя точно также будет модель и материал в какой-то структур лежать.
Каким образом использование не гиммик ецс позволяет тут что то ускорить? Где будет повторная работа?
>>19179
там ответ в стиле "где брать деньги? у мамки в кошельке!". ты на уровне юзера не понимаешь, что эти массивы нужно обновлять каждый кадр и при изменениях мира во время кадра
две работы происходят когда ты дважды обрабатываешь объекты, сначала в обычной парадигме, затем в екс. в настоящем екс ты всё делаешь через екс
>процитируй и обоснуй почему
там ответ в стиле "где брать деньги? у мамки в кошельке!". ты на уровне юзера не понимаешь, что эти массивы нужно обновлять каждый кадр и при изменениях мира во время кадра
две работы происходят когда ты дважды обрабатываешь объекты, сначала в обычной парадигме, затем в екс. в настоящем екс ты всё делаешь через екс
>>19181
ЗАЧЕЕЕЕМ
У меня есть массив entityData[] в нем лежат данные ентити.
Что мне с ним надо делать каждый кадр и зачем? Нахуя?
Если говорить о более практичном примере, то будет несколько массивов под каждыы архетип и если говоорить про юнити там внутри еще будет разметка по чанкам, но глобально ничего не меняется - массивы точно также не требуют никаких изменений из кадра в кадр.
Структурные изменения я упомянал. Никакой полной пересборки массивов там нихуя не будет.
И вопрос очень интересный на эту тему я уже поднимал выше - а без ецс у тебя если новые какие то хрени появились или исчезли в игре в реалтайме - у тебя твои любые структуры данных бесплатно обновятся?
Давай конкретику. Что значит "обрабатываются"?
Настоящий ецс и гиммик ецс делают условно абсолютно идентичные вещи:
цикл по ентитям1
ентити.ДуЛогик1() - модификация данных в структуре
цикл по ентитям2
ентити.ДуЛогик2() - модификация данных в структуре
цикл по ентитям
ентити.Дроу() - генерация дроу коллов по данным в структуре или иная обработка перед отрисовкой(пометки надо ли рендерить и т.п.)
Покажи мне где тут будет "обработка в обычной парадигме" для гиммик ецс по сравнению с тру ецс?
Также давай рассмотрим и не ецс подход
- вот для примера выше - у нас есть две каких то совершенно разных сущности в игре и и те и те надо нарисовать.
Какой мы можем сделать более эффективный вариант для этого чем "прочитать данные в структуре, поменять данные в структуре связанные с графикой и сгенерить дроу коллы"?
Просто судя по твоему примеру с мегасистемой, мне кажется, что у тебя есть огромное заблуждение ты считаешь что это заебись насрать ифами лишь бы лишней итерации по циклу не было, хотя на деле это руинит предикт процессора и с таким подходом тебе недоступна многопоточность - как минимум дроу коллы надо генерить когда все уже подготовлено и это можно распараллелить, а с таким подходом ты убиваешь эту возможность.
Я уж молчу про то, что ты можешь ну если уж так хочешь например взять юнити с гиммик ецс даже не дотс... и сделать там чтобы был один проход по массиву и в нем сразу все обрабатывалось как тебе нужно, сначала логика потом рендер. И абсолбтно ни в одном варианте не будет никаких лишних прослоек.
Концепции ецс это не противоречит и технически без проблем реализуемо.
> там ответ в стиле "где брать деньги? у мамки в кошельке!". ты на уровне юзера не понимаешь, что эти массивы нужно обновлять каждый кадр
> во время кадра
ЗАЧЕЕЕЕМ
У меня есть массив entityData[] в нем лежат данные ентити.
Что мне с ним надо делать каждый кадр и зачем? Нахуя?
Если говорить о более практичном примере, то будет несколько массивов под каждыы архетип и если говоорить про юнити там внутри еще будет разметка по чанкам, но глобально ничего не меняется - массивы точно также не требуют никаких изменений из кадра в кадр.
> и при изменениях мира
Структурные изменения я упомянал. Никакой полной пересборки массивов там нихуя не будет.
И вопрос очень интересный на эту тему я уже поднимал выше - а без ецс у тебя если новые какие то хрени появились или исчезли в игре в реалтайме - у тебя твои любые структуры данных бесплатно обновятся?
> две работы происходят когда ты дважды обрабатываешь объекты, сначала в обычной парадигме, затем в екс
Давай конкретику. Что значит "обрабатываются"?
Настоящий ецс и гиммик ецс делают условно абсолютно идентичные вещи:
цикл по ентитям1
ентити.ДуЛогик1() - модификация данных в структуре
цикл по ентитям2
ентити.ДуЛогик2() - модификация данных в структуре
цикл по ентитям
ентити.Дроу() - генерация дроу коллов по данным в структуре или иная обработка перед отрисовкой(пометки надо ли рендерить и т.п.)
Покажи мне где тут будет "обработка в обычной парадигме" для гиммик ецс по сравнению с тру ецс?
Также давай рассмотрим и не ецс подход
- вот для примера выше - у нас есть две каких то совершенно разных сущности в игре и и те и те надо нарисовать.
Какой мы можем сделать более эффективный вариант для этого чем "прочитать данные в структуре, поменять данные в структуре связанные с графикой и сгенерить дроу коллы"?
Просто судя по твоему примеру с мегасистемой, мне кажется, что у тебя есть огромное заблуждение ты считаешь что это заебись насрать ифами лишь бы лишней итерации по циклу не было, хотя на деле это руинит предикт процессора и с таким подходом тебе недоступна многопоточность - как минимум дроу коллы надо генерить когда все уже подготовлено и это можно распараллелить, а с таким подходом ты убиваешь эту возможность.
Я уж молчу про то, что ты можешь ну если уж так хочешь например взять юнити с гиммик ецс даже не дотс... и сделать там чтобы был один проход по массиву и в нем сразу все обрабатывалось как тебе нужно, сначала логика потом рендер. И абсолбтно ни в одном варианте не будет никаких лишних прослоек.
Концепции ецс это не противоречит и технически без проблем реализуемо.
>>19181
ЗАЧЕЕЕЕМ
У меня есть массив entityData[] в нем лежат данные ентити.
Что мне с ним надо делать каждый кадр и зачем? Нахуя?
Если говорить о более практичном примере, то будет несколько массивов под каждыы архетип и если говоорить про юнити там внутри еще будет разметка по чанкам, но глобально ничего не меняется - массивы точно также не требуют никаких изменений из кадра в кадр.
Структурные изменения я упомянал. Никакой полной пересборки массивов там нихуя не будет.
И вопрос очень интересный на эту тему я уже поднимал выше - а без ецс у тебя если новые какие то хрени появились или исчезли в игре в реалтайме - у тебя твои любые структуры данных бесплатно обновятся?
Давай конкретику. Что значит "обрабатываются"?
Настоящий ецс и гиммик ецс делают условно абсолютно идентичные вещи:
цикл по ентитям1
ентити.ДуЛогик1() - модификация данных в структуре
цикл по ентитям2
ентити.ДуЛогик2() - модификация данных в структуре
цикл по ентитям
ентити.Дроу() - генерация дроу коллов по данным в структуре или иная обработка перед отрисовкой(пометки надо ли рендерить и т.п.)
Покажи мне где тут будет "обработка в обычной парадигме" для гиммик ецс по сравнению с тру ецс?
Также давай рассмотрим и не ецс подход
- вот для примера выше - у нас есть две каких то совершенно разных сущности в игре и и те и те надо нарисовать.
Какой мы можем сделать более эффективный вариант для этого чем "прочитать данные в структуре, поменять данные в структуре связанные с графикой и сгенерить дроу коллы"?
Просто судя по твоему примеру с мегасистемой, мне кажется, что у тебя есть огромное заблуждение ты считаешь что это заебись насрать ифами лишь бы лишней итерации по циклу не было, хотя на деле это руинит предикт процессора и с таким подходом тебе недоступна многопоточность - как минимум дроу коллы надо генерить когда все уже подготовлено и это можно распараллелить, а с таким подходом ты убиваешь эту возможность.
Я уж молчу про то, что ты можешь ну если уж так хочешь например взять юнити с гиммик ецс даже не дотс... и сделать там чтобы был один проход по массиву и в нем сразу все обрабатывалось как тебе нужно, сначала логика потом рендер. И абсолбтно ни в одном варианте не будет никаких лишних прослоек.
Концепции ецс это не противоречит и технически без проблем реализуемо.
> там ответ в стиле "где брать деньги? у мамки в кошельке!". ты на уровне юзера не понимаешь, что эти массивы нужно обновлять каждый кадр
> во время кадра
ЗАЧЕЕЕЕМ
У меня есть массив entityData[] в нем лежат данные ентити.
Что мне с ним надо делать каждый кадр и зачем? Нахуя?
Если говорить о более практичном примере, то будет несколько массивов под каждыы архетип и если говоорить про юнити там внутри еще будет разметка по чанкам, но глобально ничего не меняется - массивы точно также не требуют никаких изменений из кадра в кадр.
> и при изменениях мира
Структурные изменения я упомянал. Никакой полной пересборки массивов там нихуя не будет.
И вопрос очень интересный на эту тему я уже поднимал выше - а без ецс у тебя если новые какие то хрени появились или исчезли в игре в реалтайме - у тебя твои любые структуры данных бесплатно обновятся?
> две работы происходят когда ты дважды обрабатываешь объекты, сначала в обычной парадигме, затем в екс
Давай конкретику. Что значит "обрабатываются"?
Настоящий ецс и гиммик ецс делают условно абсолютно идентичные вещи:
цикл по ентитям1
ентити.ДуЛогик1() - модификация данных в структуре
цикл по ентитям2
ентити.ДуЛогик2() - модификация данных в структуре
цикл по ентитям
ентити.Дроу() - генерация дроу коллов по данным в структуре или иная обработка перед отрисовкой(пометки надо ли рендерить и т.п.)
Покажи мне где тут будет "обработка в обычной парадигме" для гиммик ецс по сравнению с тру ецс?
Также давай рассмотрим и не ецс подход
- вот для примера выше - у нас есть две каких то совершенно разных сущности в игре и и те и те надо нарисовать.
Какой мы можем сделать более эффективный вариант для этого чем "прочитать данные в структуре, поменять данные в структуре связанные с графикой и сгенерить дроу коллы"?
Просто судя по твоему примеру с мегасистемой, мне кажется, что у тебя есть огромное заблуждение ты считаешь что это заебись насрать ифами лишь бы лишней итерации по циклу не было, хотя на деле это руинит предикт процессора и с таким подходом тебе недоступна многопоточность - как минимум дроу коллы надо генерить когда все уже подготовлено и это можно распараллелить, а с таким подходом ты убиваешь эту возможность.
Я уж молчу про то, что ты можешь ну если уж так хочешь например взять юнити с гиммик ецс даже не дотс... и сделать там чтобы был один проход по массиву и в нем сразу все обрабатывалось как тебе нужно, сначала логика потом рендер. И абсолбтно ни в одном варианте не будет никаких лишних прослоек.
Концепции ецс это не противоречит и технически без проблем реализуемо.
>>19183
затем, что это нормально. враги убиваются, пули исчезают, игрок двигает камеру. и все массивы тебе нужно еще раз пересчитать, сделав двойную работу
затем, что это нормально. враги убиваются, пули исчезают, игрок двигает камеру. и все массивы тебе нужно еще раз пересчитать, сделав двойную работу
>>19186
При любом подходе это требует модификации существующих структур данных
Абсолютно никоим образом не влияет на структурные изменения на стороне ецс и любой другой организации твоей геймплейной логики. Все что можно закэшировать для рендеринга остается закешировано на том же самом месте
Что значит "пересчитать массив"?
> затем, что это нормально. враги убиваются, пули исчезают
При любом подходе это требует модификации существующих структур данных
> игрок двигает камеру
Абсолютно никоим образом не влияет на структурные изменения на стороне ецс и любой другой организации твоей геймплейной логики. Все что можно закэшировать для рендеринга остается закешировано на том же самом месте
> и все массивы тебе нужно еще раз пересчитать, сделав двойную работу
Что значит "пересчитать массив"?
>>19187
мне не нужны массивы архетипов и прочие кэши для екс, которые призваны сделать итерирование в екс дешевле. если я не применяю екс, мне не нужно это всё пересчитывать каждый кадр и пересобирать екс мир каждый раз когда я сдвинул камеру или заспавнил врага
мне не нужны массивы архетипов и прочие кэши для екс, которые призваны сделать итерирование в екс дешевле. если я не применяю екс, мне не нужно это всё пересчитывать каждый кадр и пересобирать екс мир каждый раз когда я сдвинул камеру или заспавнил врага
>>19188
А, хорошо, не вопрос.
А что тебе нужно?
Где у тебя твои игровые сущности хранятся и в каком виде?
Кэши в сообщение выше были упомянуты как закэшированные данные для ренлера. Иных упомянаний не было.
У тебя есть кусок говна с физикой, он может перемещаться если его пнуть.
Для оклюжен кулинга у тебя есть возможность сохранить то в каком чанке он лежит и пересчитывать это только при изменении позиции, чтобы не делать это кпждый раз.
С ецс ты при изменении его позиции пометишь что ему надо пересчитать чанк.
Без ецс ты при изменении его позиции пометишь, что ему надо пересчитать чанк.
Что мне надо дополнительно "кэшировать" для ецс, что не надо без ецс?
В сообщении выше уже было упомянуто, что структурные изменения происходят только при наличии спавна/удаления ентити в ецс, и точно такие же изменения тебя ожидают без ецс.
Также выше было упомянуто, что каждый кадр нет никаких обязательных действий связанных с модификацией структур данных и было предложено тебе привести пример если есть, а те что ты тут обозначил уже были разобраны в том посте)
> мне не нужны массивы архетипов
А, хорошо, не вопрос.
А что тебе нужно?
Где у тебя твои игровые сущности хранятся и в каком виде?
> и прочие кэши для екс
Кэши в сообщение выше были упомянуты как закэшированные данные для ренлера. Иных упомянаний не было.
У тебя есть кусок говна с физикой, он может перемещаться если его пнуть.
Для оклюжен кулинга у тебя есть возможность сохранить то в каком чанке он лежит и пересчитывать это только при изменении позиции, чтобы не делать это кпждый раз.
С ецс ты при изменении его позиции пометишь что ему надо пересчитать чанк.
Без ецс ты при изменении его позиции пометишь, что ему надо пересчитать чанк.
Что мне надо дополнительно "кэшировать" для ецс, что не надо без ецс?
> если я не применяю екс, мне не нужно это всё пересчитывать каждый кадр
> и пересобирать екс мир каждый раз когда я сдвинул камеру или заспавнил врага
В сообщении выше уже было упомянуто, что структурные изменения происходят только при наличии спавна/удаления ентити в ецс, и точно такие же изменения тебя ожидают без ецс.
Также выше было упомянуто, что каждый кадр нет никаких обязательных действий связанных с модификацией структур данных и было предложено тебе привести пример если есть, а те что ты тут обозначил уже были разобраны в том посте)
>>19192
а с гиммик екс придется сделать и то и другое
>С ецс ты при изменении его позиции пометишь что ему надо пересчитать чанк.
>Без ецс ты при изменении его позиции пометишь, что ему надо пересчитать чанк.
а с гиммик екс придется сделать и то и другое
>>19194
Нет, зачем?
Ты в гиммик ецс сделал пометку и сохранил координаты чанка, эти данные напрямую будут использовать при рендеринге.
Зачем еще раз это делать?
Нет, зачем?
Ты в гиммик ецс сделал пометку и сохранил координаты чанка, эти данные напрямую будут использовать при рендеринге.
Зачем еще раз это делать?
>>19195
затем что в екс мире еще раз закэшировано то, что закэшировано в ооп мире. то есть при удалении объекта в мире сначала почистить тут, затем почистить кэши в екс мире, всё пересчитать. 2 раза делается работа
затем что в екс мире еще раз закэшировано то, что закэшировано в ооп мире. то есть при удалении объекта в мире сначала почистить тут, затем почистить кэши в екс мире, всё пересчитать. 2 раза делается работа
>>19197
Что ещё за ооп мир?
У нам просто массив структур, больше нихуя нет.
Вот просто нах натурально пишешь коде у себя(либо эквивалент скодогенерирован за тебя в готовом фреймворке)
entityData1[] - ентити с компонентом позиция, урон, пуля, моделька, графика
entityData2[] - ентити с компонентами позиция, моделька, хп, датаврага, графика
Никаких нахуй оопов нет и в помине, просто эти 2 массива и больше ничего.
Что ещё за ооп мир?
У нам просто массив структур, больше нихуя нет.
Вот просто нах натурально пишешь коде у себя(либо эквивалент скодогенерирован за тебя в готовом фреймворке)
entityData1[] - ентити с компонентом позиция, урон, пуля, моделька, графика
entityData2[] - ентити с компонентами позиция, моделька, хп, датаврага, графика
Никаких нахуй оопов нет и в помине, просто эти 2 массива и больше ничего.
>>19198
вот настоящий екс это и есть то что "скодогенерировано за тебя" разрабом твоего плагина, а то что ты с точки зрения юзера не видишь что работа делается 2 раза - это специфика работы с плагином в не екс движке типа юнити
вот настоящий екс это и есть то что "скодогенерировано за тебя" разрабом твоего плагина, а то что ты с точки зрения юзера не видишь что работа делается 2 раза - это специфика работы с плагином в не екс движке типа юнити
>>19199
Окей.
Я беру юнити.
Я руками пишу буквы в коде:
entityData1[]
entityData2[]
Делаю цикл по 1, делаю в нем
позиция += пуля.скорость х дт
рендерДата.маркДирти = тру
Делаю цикл по 2, делаю в нем
иф (енеми.долженПойти)
{
позиция += пиздуй
рендерДата.маркДирти = тру
}
Делаю цикл по 1 и потом по 2 и делаю
иф (рендерДата.маркДирти)
{
рендерДата.чанк = считаю чанк
рендерДата.маркДирти = фолм
}
дроуМеш(рендерДата, меш) - который напрямую вызыввет графическое апи дайрект хэ
Зачем мне какой-то ооп мир тут нужен?
Какую он роль выполняет?
В какой момент будет задействован? Я же букыально делаю прямые вызовы методов.
Ты думаешь я должен заспавнить юнити геймобжект с компонентом меш чтобы модельку отрисовать?) Нет, я могу напрямую графиечское апи юзать, ну почти напрямую, в юнити довольно низкоуровневая обертка.
Кодогенерацией обычно обозначают автоматическую генерацию инфраструктурного бойлерплейт кода в конкретном проекте, а не "то что ращрабом сгенеиировано за тебя"(не уверен, что это вооьще значит? что разраб скодогенерировал)
Ну типа чтобы я руками не писал одно и тоже, оно само напишется. Для депенденси инжекшен еще юзают кодогенерацию например.
Окей.
Я беру юнити.
Я руками пишу буквы в коде:
entityData1[]
entityData2[]
Делаю цикл по 1, делаю в нем
позиция += пуля.скорость х дт
рендерДата.маркДирти = тру
Делаю цикл по 2, делаю в нем
иф (енеми.долженПойти)
{
позиция += пиздуй
рендерДата.маркДирти = тру
}
Делаю цикл по 1 и потом по 2 и делаю
иф (рендерДата.маркДирти)
{
рендерДата.чанк = считаю чанк
рендерДата.маркДирти = фолм
}
дроуМеш(рендерДата, меш) - который напрямую вызыввет графическое апи дайрект хэ
Зачем мне какой-то ооп мир тут нужен?
Какую он роль выполняет?
В какой момент будет задействован? Я же букыально делаю прямые вызовы методов.
Ты думаешь я должен заспавнить юнити геймобжект с компонентом меш чтобы модельку отрисовать?) Нет, я могу напрямую графиечское апи юзать, ну почти напрямую, в юнити довольно низкоуровневая обертка.
> скодогенерировано за тебя
Кодогенерацией обычно обозначают автоматическую генерацию инфраструктурного бойлерплейт кода в конкретном проекте, а не "то что ращрабом сгенеиировано за тебя"(не уверен, что это вооьще значит? что разраб скодогенерировал)
Ну типа чтобы я руками не писал одно и тоже, оно само напишется. Для депенденси инжекшен еще юзают кодогенерацию например.
>>19199
Окей.
Я беру юнити.
Я руками пишу буквы в коде:
entityData1[]
entityData2[]
Делаю цикл по 1, делаю в нем
позиция += пуля.скорость х дт
рендерДата.маркДирти = тру
Делаю цикл по 2, делаю в нем
иф (енеми.долженПойти)
{
позиция += пиздуй
рендерДата.маркДирти = тру
}
Делаю цикл по 1 и потом по 2 и делаю
иф (рендерДата.маркДирти)
{
рендерДата.чанк = считаю чанк
рендерДата.маркДирти = фолм
}
дроуМеш(рендерДата, меш) - который напрямую вызыввет графическое апи дайрект хэ
Зачем мне какой-то ооп мир тут нужен?
Какую он роль выполняет?
В какой момент будет задействован? Я же букыально делаю прямые вызовы методов.
Ты думаешь я должен заспавнить юнити геймобжект с компонентом меш чтобы модельку отрисовать?) Нет, я могу напрямую графиечское апи юзать, ну почти напрямую, в юнити довольно низкоуровневая обертка.
Кодогенерацией обычно обозначают автоматическую генерацию инфраструктурного бойлерплейт кода в конкретном проекте, а не "то что ращрабом сгенеиировано за тебя"(не уверен, что это вооьще значит? что разраб скодогенерировал)
Ну типа чтобы я руками не писал одно и тоже, оно само напишется. Для депенденси инжекшен еще юзают кодогенерацию например.
Окей.
Я беру юнити.
Я руками пишу буквы в коде:
entityData1[]
entityData2[]
Делаю цикл по 1, делаю в нем
позиция += пуля.скорость х дт
рендерДата.маркДирти = тру
Делаю цикл по 2, делаю в нем
иф (енеми.долженПойти)
{
позиция += пиздуй
рендерДата.маркДирти = тру
}
Делаю цикл по 1 и потом по 2 и делаю
иф (рендерДата.маркДирти)
{
рендерДата.чанк = считаю чанк
рендерДата.маркДирти = фолм
}
дроуМеш(рендерДата, меш) - который напрямую вызыввет графическое апи дайрект хэ
Зачем мне какой-то ооп мир тут нужен?
Какую он роль выполняет?
В какой момент будет задействован? Я же букыально делаю прямые вызовы методов.
Ты думаешь я должен заспавнить юнити геймобжект с компонентом меш чтобы модельку отрисовать?) Нет, я могу напрямую графиечское апи юзать, ну почти напрямую, в юнити довольно низкоуровневая обертка.
> скодогенерировано за тебя
Кодогенерацией обычно обозначают автоматическую генерацию инфраструктурного бойлерплейт кода в конкретном проекте, а не "то что ращрабом сгенеиировано за тебя"(не уверен, что это вооьще значит? что разраб скодогенерировал)
Ну типа чтобы я руками не писал одно и тоже, оно само напишется. Для депенденси инжекшен еще юзают кодогенерацию например.
>>19202
я не в курсе реализации твоего плагина. я исхожу из твоих же постулатов, что у тебя всё что не для екс вынесено за пределы екс. например, ожидаемо что управление подгрузкой уровней, рендеринг и физон делается движком. а то что ты пишешь это детские примеры екс из статьи "что такое екс".
я не в курсе реализации твоего плагина. я исхожу из твоих же постулатов, что у тебя всё что не для екс вынесено за пределы екс. например, ожидаемо что управление подгрузкой уровней, рендеринг и физон делается движком. а то что ты пишешь это детские примеры екс из статьи "что такое екс".
>>19202
хотя я даже не понимаю, зачем ты делаешь цикл по пустому массиву и что-то там исполняешь. ты создал пустой массив и итерируешься по пустому массиву? как это у тебя работает?
хотя я даже не понимаю, зачем ты делаешь цикл по пустому массиву и что-то там исполняешь. ты создал пустой массив и итерируешься по пустому массиву? как это у тебя работает?
>>19206
Это не реализацию плагина, это псевдокод который буду запускать на псевдокомпьютере
Предположим?
читать файл
подождать чтение файла
ентитиес1 = копировать(файл.данныеентитиес1)
Дроумеш(меш, позиция)
ентити.позишен = ассошиейтедРигидБади.позишен
Кстати знаешь есть еще всякие разные физические движки вроде хавок, бокс2д, физИкс? Они используются в юнити и во многих других движках, даже если игру с нуля пишут часто берут какой-то из них.
Каким образом их дружат с геймплейной логикой, как считаешь? Как думаешь, чем будет отличаться вариант подружить их с ецс или любым другим вариантом организации геймплея?
Или если мы например в компьют шейдере считаем фищику - как данные оттуда назад в в игру получить и как их туда запихать?
Да ничем нахуй, все что тебе надо сделать это проассоциировать айдишник объекта в этой физической ебале с твоим куском говна и копировать в кусок говна позицию проассоциированного с ним физического тела. Всё, вот весь оверхед.
А так, я даже свой физон писал в юнити. Я это уже несколько раз повторял - тебе доступен язык программирования. Ты можешь сделать им что угодно абсолютно.
Это минимизированный пример для демонстрации оверхеда при взаимодействии ецс-кора с разными системами.
Я же уже писал более общими словами, но ты отказывался что либо читать и понимать.
Я просто хз как тебе еще сказать, что если мы используем движок, то мы не обязаны все реализовывать только его средствами, что в том же юнити есть низкоуровневое апи для всего.
Более того, ты можешь даже юзать внешние системы без проблем как я приводил пример с физическими движками, можешь даже юзать юнити геймобжекты - это тоже рабочая практика, и делается это также как и интеграция физики куда угодно - проассоциировать твою какую то хуйню с сущеостью из другой какой то системы
Условно у тебя будет
struct BulletComponent
{
BulletView - геймобжект в юнити
Position
Speed
}
И оверхед тут тоже около нулевой так как это принципиально разные независимые сущности кроме одного момент - в BulletView надо скопировать позицию из BulletComponent.
Всё.
Никакое нахуй движение камерой никак не повлияет на буллетКомпонент.
Никакой окклюжен куллинг не будет влиять ни на что кроме БуллетВью.
Никакие массимвы не надо никак не пересчитывать ни кэшировать каждый кадр. Кор геймплей управляет всем, а не наоборот.
Отдельно хочу отметить гуи - абсолютно поебать свой ты движок пишешь, не свой, подружить ооп гуй с ецс кором это примитивнейшая задача с нулевым оверхедом для геймплейной части, тебе надо просто писать данные из геймплея в такю область памяти, откуда их сможет прочитать гуй. Всё.
>>19208
Хорошо! Дополню пример
entityData1[] entities1 = new entityData1[100];
for(int i = 0; i < 100; i++)
{
entities1 = new EnemyEntity(randomPos);
}
Пули заполнять не будем. Или надо, или ты скажешь "ну а попробуй пулю заспавнить или уничтожить надо перещитать все)))"?
Тогда я повторяю ставший уже вечным вопрос - а без ецс ты как пулю заспавнишь?
> я не в курсе реализации твоего плагина
Это не реализацию плагина, это псевдокод который буду запускать на псевдокомпьютере
> я исхожу из твоих же постулатов, что у тебя всё что не для екс вынесено за пределы екс
Предположим?
> например, ожидаемо что управление подгрузкой уровней
читать файл
подождать чтение файла
ентитиес1 = копировать(файл.данныеентитиес1)
> рендеринг
Дроумеш(меш, позиция)
> и физон делается движко
ентити.позишен = ассошиейтедРигидБади.позишен
Кстати знаешь есть еще всякие разные физические движки вроде хавок, бокс2д, физИкс? Они используются в юнити и во многих других движках, даже если игру с нуля пишут часто берут какой-то из них.
Каким образом их дружат с геймплейной логикой, как считаешь? Как думаешь, чем будет отличаться вариант подружить их с ецс или любым другим вариантом организации геймплея?
Или если мы например в компьют шейдере считаем фищику - как данные оттуда назад в в игру получить и как их туда запихать?
Да ничем нахуй, все что тебе надо сделать это проассоциировать айдишник объекта в этой физической ебале с твоим куском говна и копировать в кусок говна позицию проассоциированного с ним физического тела. Всё, вот весь оверхед.
А так, я даже свой физон писал в юнити. Я это уже несколько раз повторял - тебе доступен язык программирования. Ты можешь сделать им что угодно абсолютно.
> а то что ты пишешь это детские примеры екс из статьи "что такое екс".
Это минимизированный пример для демонстрации оверхеда при взаимодействии ецс-кора с разными системами.
Я же уже писал более общими словами, но ты отказывался что либо читать и понимать.
Я просто хз как тебе еще сказать, что если мы используем движок, то мы не обязаны все реализовывать только его средствами, что в том же юнити есть низкоуровневое апи для всего.
Более того, ты можешь даже юзать внешние системы без проблем как я приводил пример с физическими движками, можешь даже юзать юнити геймобжекты - это тоже рабочая практика, и делается это также как и интеграция физики куда угодно - проассоциировать твою какую то хуйню с сущеостью из другой какой то системы
Условно у тебя будет
struct BulletComponent
{
BulletView - геймобжект в юнити
Position
Speed
}
И оверхед тут тоже около нулевой так как это принципиально разные независимые сущности кроме одного момент - в BulletView надо скопировать позицию из BulletComponent.
Всё.
Никакое нахуй движение камерой никак не повлияет на буллетКомпонент.
Никакой окклюжен куллинг не будет влиять ни на что кроме БуллетВью.
Никакие массимвы не надо никак не пересчитывать ни кэшировать каждый кадр. Кор геймплей управляет всем, а не наоборот.
Отдельно хочу отметить гуи - абсолютно поебать свой ты движок пишешь, не свой, подружить ооп гуй с ецс кором это примитивнейшая задача с нулевым оверхедом для геймплейной части, тебе надо просто писать данные из геймплея в такю область памяти, откуда их сможет прочитать гуй. Всё.
>>19208
> хотя я даже не понимаю, зачем ты делаешь цикл по пустому массиву и что-то там исполняешь. ты создал пустой массив и итерируешься по пустому массиву? как это у тебя работает?
Хорошо! Дополню пример
entityData1[] entities1 = new entityData1[100];
for(int i = 0; i < 100; i++)
{
entities1 = new EnemyEntity(randomPos);
}
Пули заполнять не будем. Или надо, или ты скажешь "ну а попробуй пулю заспавнить или уничтожить надо перещитать все)))"?
Тогда я повторяю ставший уже вечным вопрос - а без ецс ты как пулю заспавнишь?
>>19206
Это не реализацию плагина, это псевдокод который буду запускать на псевдокомпьютере
Предположим?
читать файл
подождать чтение файла
ентитиес1 = копировать(файл.данныеентитиес1)
Дроумеш(меш, позиция)
ентити.позишен = ассошиейтедРигидБади.позишен
Кстати знаешь есть еще всякие разные физические движки вроде хавок, бокс2д, физИкс? Они используются в юнити и во многих других движках, даже если игру с нуля пишут часто берут какой-то из них.
Каким образом их дружат с геймплейной логикой, как считаешь? Как думаешь, чем будет отличаться вариант подружить их с ецс или любым другим вариантом организации геймплея?
Или если мы например в компьют шейдере считаем фищику - как данные оттуда назад в в игру получить и как их туда запихать?
Да ничем нахуй, все что тебе надо сделать это проассоциировать айдишник объекта в этой физической ебале с твоим куском говна и копировать в кусок говна позицию проассоциированного с ним физического тела. Всё, вот весь оверхед.
А так, я даже свой физон писал в юнити. Я это уже несколько раз повторял - тебе доступен язык программирования. Ты можешь сделать им что угодно абсолютно.
Это минимизированный пример для демонстрации оверхеда при взаимодействии ецс-кора с разными системами.
Я же уже писал более общими словами, но ты отказывался что либо читать и понимать.
Я просто хз как тебе еще сказать, что если мы используем движок, то мы не обязаны все реализовывать только его средствами, что в том же юнити есть низкоуровневое апи для всего.
Более того, ты можешь даже юзать внешние системы без проблем как я приводил пример с физическими движками, можешь даже юзать юнити геймобжекты - это тоже рабочая практика, и делается это также как и интеграция физики куда угодно - проассоциировать твою какую то хуйню с сущеостью из другой какой то системы
Условно у тебя будет
struct BulletComponent
{
BulletView - геймобжект в юнити
Position
Speed
}
И оверхед тут тоже около нулевой так как это принципиально разные независимые сущности кроме одного момент - в BulletView надо скопировать позицию из BulletComponent.
Всё.
Никакое нахуй движение камерой никак не повлияет на буллетКомпонент.
Никакой окклюжен куллинг не будет влиять ни на что кроме БуллетВью.
Никакие массимвы не надо никак не пересчитывать ни кэшировать каждый кадр. Кор геймплей управляет всем, а не наоборот.
Отдельно хочу отметить гуи - абсолютно поебать свой ты движок пишешь, не свой, подружить ооп гуй с ецс кором это примитивнейшая задача с нулевым оверхедом для геймплейной части, тебе надо просто писать данные из геймплея в такю область памяти, откуда их сможет прочитать гуй. Всё.
>>19208
Хорошо! Дополню пример
entityData1[] entities1 = new entityData1[100];
for(int i = 0; i < 100; i++)
{
entities1 = new EnemyEntity(randomPos);
}
Пули заполнять не будем. Или надо, или ты скажешь "ну а попробуй пулю заспавнить или уничтожить надо перещитать все)))"?
Тогда я повторяю ставший уже вечным вопрос - а без ецс ты как пулю заспавнишь?
> я не в курсе реализации твоего плагина
Это не реализацию плагина, это псевдокод который буду запускать на псевдокомпьютере
> я исхожу из твоих же постулатов, что у тебя всё что не для екс вынесено за пределы екс
Предположим?
> например, ожидаемо что управление подгрузкой уровней
читать файл
подождать чтение файла
ентитиес1 = копировать(файл.данныеентитиес1)
> рендеринг
Дроумеш(меш, позиция)
> и физон делается движко
ентити.позишен = ассошиейтедРигидБади.позишен
Кстати знаешь есть еще всякие разные физические движки вроде хавок, бокс2д, физИкс? Они используются в юнити и во многих других движках, даже если игру с нуля пишут часто берут какой-то из них.
Каким образом их дружат с геймплейной логикой, как считаешь? Как думаешь, чем будет отличаться вариант подружить их с ецс или любым другим вариантом организации геймплея?
Или если мы например в компьют шейдере считаем фищику - как данные оттуда назад в в игру получить и как их туда запихать?
Да ничем нахуй, все что тебе надо сделать это проассоциировать айдишник объекта в этой физической ебале с твоим куском говна и копировать в кусок говна позицию проассоциированного с ним физического тела. Всё, вот весь оверхед.
А так, я даже свой физон писал в юнити. Я это уже несколько раз повторял - тебе доступен язык программирования. Ты можешь сделать им что угодно абсолютно.
> а то что ты пишешь это детские примеры екс из статьи "что такое екс".
Это минимизированный пример для демонстрации оверхеда при взаимодействии ецс-кора с разными системами.
Я же уже писал более общими словами, но ты отказывался что либо читать и понимать.
Я просто хз как тебе еще сказать, что если мы используем движок, то мы не обязаны все реализовывать только его средствами, что в том же юнити есть низкоуровневое апи для всего.
Более того, ты можешь даже юзать внешние системы без проблем как я приводил пример с физическими движками, можешь даже юзать юнити геймобжекты - это тоже рабочая практика, и делается это также как и интеграция физики куда угодно - проассоциировать твою какую то хуйню с сущеостью из другой какой то системы
Условно у тебя будет
struct BulletComponent
{
BulletView - геймобжект в юнити
Position
Speed
}
И оверхед тут тоже около нулевой так как это принципиально разные независимые сущности кроме одного момент - в BulletView надо скопировать позицию из BulletComponent.
Всё.
Никакое нахуй движение камерой никак не повлияет на буллетКомпонент.
Никакой окклюжен куллинг не будет влиять ни на что кроме БуллетВью.
Никакие массимвы не надо никак не пересчитывать ни кэшировать каждый кадр. Кор геймплей управляет всем, а не наоборот.
Отдельно хочу отметить гуи - абсолютно поебать свой ты движок пишешь, не свой, подружить ооп гуй с ецс кором это примитивнейшая задача с нулевым оверхедом для геймплейной части, тебе надо просто писать данные из геймплея в такю область памяти, откуда их сможет прочитать гуй. Всё.
>>19208
> хотя я даже не понимаю, зачем ты делаешь цикл по пустому массиву и что-то там исполняешь. ты создал пустой массив и итерируешься по пустому массиву? как это у тебя работает?
Хорошо! Дополню пример
entityData1[] entities1 = new entityData1[100];
for(int i = 0; i < 100; i++)
{
entities1 = new EnemyEntity(randomPos);
}
Пули заполнять не будем. Или надо, или ты скажешь "ну а попробуй пулю заспавнить или уничтожить надо перещитать все)))"?
Тогда я повторяю ставший уже вечным вопрос - а без ецс ты как пулю заспавнишь?
>>19210
то есть ты всегда рендеришь все объекты в игре?
>Никакое нахуй движение камерой никак не повлияет на буллетКомпонент.
то есть ты всегда рендеришь все объекты в игре?
>>19212
Нет, с чего ты взял? Ты видишь в буллетКомпоненте какие либо данные связанные с рендерингом или оклюжен кулингом?
Я не вижу, я вижу только позицию и скорость.
Булет вью это ебаный адрес какой-то там хуйни в движке, геймобжект заспавненный в роп мире игры.
Каждый кадр надо к позиции прибавить скорсоть и сделать булетВью->позишен = позишен. Всё, больше ничего.
Не вадно вижу я булетВью, не вижу - это никакой роли на буллетКомпонент не оказывает. Рендеринг работает только на булетВью, и он да, будет участвовать в оклюжен кулинге, там заданы материал и меш, там даже есть какие то данные для рендеринга типа тот же маркДирти который мы выше упомянли. Точно также как без ецс он бы это делал.
>>19213
Нет, это на старте игры происходит.
А дальше по ходу игры в апдейте делаю циклы которые выше приводил
> то есть ты всегда рендеришь все объекты в игре?
Нет, с чего ты взял? Ты видишь в буллетКомпоненте какие либо данные связанные с рендерингом или оклюжен кулингом?
Я не вижу, я вижу только позицию и скорость.
Булет вью это ебаный адрес какой-то там хуйни в движке, геймобжект заспавненный в роп мире игры.
Каждый кадр надо к позиции прибавить скорсоть и сделать булетВью->позишен = позишен. Всё, больше ничего.
Не вадно вижу я булетВью, не вижу - это никакой роли на буллетКомпонент не оказывает. Рендеринг работает только на булетВью, и он да, будет участвовать в оклюжен кулинге, там заданы материал и меш, там даже есть какие то данные для рендеринга типа тот же маркДирти который мы выше упомянли. Точно также как без ецс он бы это делал.
>>19213
> ты каждый кадр перегенериваешь массив?
Нет, это на старте игры происходит.
А дальше по ходу игры в апдейте делаю циклы которые выше приводил
>>18975
ECS в принципе не приспособленная к оптимизации архитектура, тормознутая и поэтому в принципе не пригодная для разработки игр. Она хороша только в тупых демках типа миллион спрайтов в одну сторону двигать.
ECS в принципе не приспособленная к оптимизации архитектура, тормознутая и поэтому в принципе не пригодная для разработки игр. Она хороша только в тупых демках типа миллион спрайтов в одну сторону двигать.
>>19213
>>19215
Чтобы было проще
entityData1[] entities1 = new entityData1[100];
СтартИгры()
{
for(int i = 0; i < 100; i++)
{
entities1 = new EnemyEntity(randomPos);
}
}
Апдейт()
{
Делаю цикл по 1, делаю в нем
позиция += пуля.скорость х дт
рендерДата.маркДирти = тру
Делаю цикл по 2, делаю в нем
иф (енеми.долженПойти)
{
позиция += пиздуй
рендерДата.маркДирти = тру
}
Делаю цикл по 1 и потом по 2 и делаю
иф (рендерДата.маркДирти)
{
рендерДата.чанк = считаю чанк
рендерДата.маркДирти = фолм
}
дроуМеш(рендерДата, меш) - который напрямую вызыввет графическое апи дайрект хэ
}
> ты каждый кадр перегенериваешь массив?
>>19215
> > ты каждый кадр перегенериваешь массив?
> Нет, это на старте игры происходит.
Чтобы было проще
entityData1[] entities1 = new entityData1[100];
СтартИгры()
{
for(int i = 0; i < 100; i++)
{
entities1 = new EnemyEntity(randomPos);
}
}
Апдейт()
{
Делаю цикл по 1, делаю в нем
позиция += пуля.скорость х дт
рендерДата.маркДирти = тру
Делаю цикл по 2, делаю в нем
иф (енеми.долженПойти)
{
позиция += пиздуй
рендерДата.маркДирти = тру
}
Делаю цикл по 1 и потом по 2 и делаю
иф (рендерДата.маркДирти)
{
рендерДата.чанк = считаю чанк
рендерДата.маркДирти = фолм
}
дроуМеш(рендерДата, меш) - который напрямую вызыввет графическое апи дайрект хэ
}
>>19213
>>19215
Чтобы было проще
entityData1[] entities1 = new entityData1[100];
СтартИгры()
{
for(int i = 0; i < 100; i++)
{
entities1 = new EnemyEntity(randomPos);
}
}
Апдейт()
{
Делаю цикл по 1, делаю в нем
позиция += пуля.скорость х дт
рендерДата.маркДирти = тру
Делаю цикл по 2, делаю в нем
иф (енеми.долженПойти)
{
позиция += пиздуй
рендерДата.маркДирти = тру
}
Делаю цикл по 1 и потом по 2 и делаю
иф (рендерДата.маркДирти)
{
рендерДата.чанк = считаю чанк
рендерДата.маркДирти = фолм
}
дроуМеш(рендерДата, меш) - который напрямую вызыввет графическое апи дайрект хэ
}
> ты каждый кадр перегенериваешь массив?
>>19215
> > ты каждый кадр перегенериваешь массив?
> Нет, это на старте игры происходит.
Чтобы было проще
entityData1[] entities1 = new entityData1[100];
СтартИгры()
{
for(int i = 0; i < 100; i++)
{
entities1 = new EnemyEntity(randomPos);
}
}
Апдейт()
{
Делаю цикл по 1, делаю в нем
позиция += пуля.скорость х дт
рендерДата.маркДирти = тру
Делаю цикл по 2, делаю в нем
иф (енеми.долженПойти)
{
позиция += пиздуй
рендерДата.маркДирти = тру
}
Делаю цикл по 1 и потом по 2 и делаю
иф (рендерДата.маркДирти)
{
рендерДата.чанк = считаю чанк
рендерДата.маркДирти = фолм
}
дроуМеш(рендерДата, меш) - который напрямую вызыввет графическое апи дайрект хэ
}
>>19216
Хорошо.
Мы просто в 100 ебал делаем игру на ецс и выжимаем нереальный перформанс, учтем твое мнение в следующий раз.
Хорошо.
Мы просто в 100 ебал делаем игру на ецс и выжимаем нереальный перформанс, учтем твое мнение в следующий раз.
>>19215
то есть у тебя существует буллет компонент несуществующей уже пули? нихуевые у тебя утечки памяти должно быть
то есть дальше у тебя вся игра статична, ни новых врагов, ни новых пуль, никакого куллинга объектов?
>Нет, с чего ты взял? Ты видишь в буллетКомпоненте какие либо данные связанные с рендерингом или оклюжен кулингом?
то есть у тебя существует буллет компонент несуществующей уже пули? нихуевые у тебя утечки памяти должно быть
>Нет, это на старте игры происходит.
то есть дальше у тебя вся игра статична, ни новых врагов, ни новых пуль, никакого куллинга объектов?
>>19219
А хоче лайфтацм обсудить. Хорошо.
Только вопрос сразу некорректный
Еще раз - кор контролирует все. Мы создвли ентити пули в коре - тогда создали буллетВью. Уничтожили - тогда уничтожил и буллетВью.
Если пулю не видно - не значит что она должна перестать "существовать" лол, просто она скипается при рендеринге.
У тебя за кадром пули не летают?
Наверное летают, просто не рендерятся.
Децйствительео, происходит такое.
А без ецс ты бы как эту задачу решил?
Вот надо заспавнить пулю, а у нас не ецс. Что мы делаем? Или уничтожить.
Может я смогу этот способ в своеф игре на ецс применить?...)))))))
> то есть у тебя существует буллет компонент несуществующей уже пули? нихуевые у тебя утечки памяти должно быть
А хоче лайфтацм обсудить. Хорошо.
Только вопрос сразу некорректный
> то есть у тебя существует буллет компонент несуществующей уже пули?
Еще раз - кор контролирует все. Мы создвли ентити пули в коре - тогда создали буллетВью. Уничтожили - тогда уничтожил и буллетВью.
Если пулю не видно - не значит что она должна перестать "существовать" лол, просто она скипается при рендеринге.
У тебя за кадром пули не летают?
Наверное летают, просто не рендерятся.
> то есть дальше у тебя вся игра статична, ни новых врагов, ни новых пуль, никакого куллинга объектов?
Децйствительео, происходит такое.
А без ецс ты бы как эту задачу решил?
Вот надо заспавнить пулю, а у нас не ецс. Что мы делаем? Или уничтожить.
Может я смогу этот способ в своеф игре на ецс применить?...)))))))
>>19221
только что было 2 пустых массива, теперь уже появился некий волшебный контролирующий всё кор. а что такое кор? как он всё контролирует?
>кор контролирует все
только что было 2 пустых массива, теперь уже появился некий волшебный контролирующий всё кор. а что такое кор? как он всё контролирует?
>>19222
Хорошо, показывай игру. Будем мерить производительность.
Хорошо, показывай игру. Будем мерить производительность.
А еще ECS невменяемо отлаживать, на ECS невозможно написать нормальный гуй (поэтому ECS-шизики пишут эмуляцию отношений parent-child, лол), и невозможно сделать сетевую игру с rollback.
>>19223
А, тут небольшое недопонимание, сейчас все объясняю.
Кор - это наш ецс. То есть весь код что писал тут >>19217 это кор
Когда мы делаем вот это
Там внутри new EnemyEntity(randomPos) вот что происходит:
EnemyEntity(pos)
{
Position = pos;
Hp = 100;
EnemyView = Unity.ZapiliGameObjectVraga();
}
Когда мы убьем врага и удалим его из нашего массива мы сделаем
Unity.Destroy(entity.EnemyView);
> только что было 2 пустых массива, теперь уже появился некий волшебный контролирующий всё кор. а что такое кор? как он всё контролирует?
А, тут небольшое недопонимание, сейчас все объясняю.
Кор - это наш ецс. То есть весь код что писал тут >>19217 это кор
Когда мы делаем вот это
> СтартИгры()
> {
> for(int i = 0; i < 100; i++)
> {
> entities1 = new EnemyEntity(randomPos);
> }
> }
Там внутри new EnemyEntity(randomPos) вот что происходит:
EnemyEntity(pos)
{
Position = pos;
Hp = 100;
EnemyView = Unity.ZapiliGameObjectVraga();
}
Когда мы убьем врага и удалим его из нашего массива мы сделаем
Unity.Destroy(entity.EnemyView);
>>19225
Да, бывает не просто. Но не невозможно.
Ну я б тоже не писал. А зачем, если можно на ООП заебись сделать?
Пишут, но не для гуя.
Ты что?... ты... ку ку?
Ецс для этого и предназначен можно сказать. Это та задача, которую ебанешься делать без ецса
> А еще ECS невменяемо отлаживать
Да, бывает не просто. Но не невозможно.
> на ECS невозможно написать нормальный гуй
Ну я б тоже не писал. А зачем, если можно на ООП заебись сделать?
> (поэтому ECS-шизики пишут эмуляцию отношений parent-child, лол)
Пишут, но не для гуя.
> и невозможно сделать сетевую игру с rollback.
Ты что?... ты... ку ку?
Ецс для этого и предназначен можно сказать. Это та задача, которую ебанешься делать без ецса
>>19227
Это задача которая делается элементарно на оопе и через жопу на ецс.
Стреляем в игрока, он умирает, объект игрока деспавнится, пуля деспавнится, надо сделать откат, спавним пулю там где деспавнилась, игрока там где деспавнился, изи.
Что у нас в ецс? А, просто фарш разных компонентов. Как узнать что этот трансформ и этот меш относился к одному и их надо вернуть? Снова написав эмуляцию оопа, лол.
Это задача которая делается элементарно на оопе и через жопу на ецс.
Стреляем в игрока, он умирает, объект игрока деспавнится, пуля деспавнится, надо сделать откат, спавним пулю там где деспавнилась, игрока там где деспавнился, изи.
Что у нас в ецс? А, просто фарш разных компонентов. Как узнать что этот трансформ и этот меш относился к одному и их надо вернуть? Снова написав эмуляцию оопа, лол.
>>19226
но в твоем коре нет менеджмента массивов для екс, и ты просто из тумбочки берешь уже подготовленный екс мир и делаешь пук() и среньк() лайк э босс
ты никогда не удалял ничего и никуда, всегда рендеришь все объекты в игре (ну или скипаешь, но всё равно продолжаешь итерироваться по ним), а когда пуля улетает у тебя в массивах остаются буллет компоненты которые никуда не деваются
но в твоем коре нет менеджмента массивов для екс, и ты просто из тумбочки берешь уже подготовленный екс мир и делаешь пук() и среньк() лайк э босс
ты никогда не удалял ничего и никуда, всегда рендеришь все объекты в игре (ну или скипаешь, но всё равно продолжаешь итерироваться по ним), а когда пуля улетает у тебя в массивах остаются буллет компоненты которые никуда не деваются
>>19229
Цитирую то что я уже писал:
- Когда мы убьем врага и удалим его из нашего массива мы сделаем
Unity.Destroy(entity.EnemyView);
- А без ецс ты бы как эту задачу решил?
Вот надо заспавнить пулю, а у нас не ецс. Что мы делаем? Или уничтожить.
БЛЯЯЯЯТЬ НУ ХВАТИТ
Я просто уже хуй знает сколько раз одно и то же повторяю, ты прост игноришь и через 1 пост спрашиваешь
- У тебя за кадром пули не летают? Наверное летают, просто не рендерятся.
Когда пуля будет уничтожена с точки зрения геймдизайна - тогда она будет удалена. Если пуля за кадром - с точки зрения геймдизайна она жива.
Когда врежется - тогда удалим.
Обсудим удаление объектов в целом? Напиши, как удаляешь без ецс объекты. Всё ещё жду.
> но в твоем коре нет менеджмента массивов для екс, и ты просто из тумбочки берешь уже подготовленный екс мир и делаешь пук() и среньк() лайк э босс
Цитирую то что я уже писал:
- Когда мы убьем врага и удалим его из нашего массива мы сделаем
Unity.Destroy(entity.EnemyView);
- А без ецс ты бы как эту задачу решил?
Вот надо заспавнить пулю, а у нас не ецс. Что мы делаем? Или уничтожить.
> всегда рендеришь все объекты в игре (ну или скипаешь, но всё равно продолжаешь итерироваться по ним)
БЛЯЯЯЯТЬ НУ ХВАТИТ
Я просто уже хуй знает сколько раз одно и то же повторяю, ты прост игноришь и через 1 пост спрашиваешь
- У тебя за кадром пули не летают? Наверное летают, просто не рендерятся.
> а когда пуля улетает у тебя в массивах остаются буллет компоненты которые никуда не деваются
Когда пуля будет уничтожена с точки зрения геймдизайна - тогда она будет удалена. Если пуля за кадром - с точки зрения геймдизайна она жива.
Когда врежется - тогда удалим.
Обсудим удаление объектов в целом? Напиши, как удаляешь без ецс объекты. Всё ещё жду.
>>19233
то есть дропаем кэши и считаем заново. но ты вроде говорил, что этого не происходит? как так?
>Когда врежется - тогда удалим.
то есть дропаем кэши и считаем заново. но ты вроде говорил, что этого не происходит? как так?
>>19228
Как мы понимаем где они задеспавнились? И кто именно? Что надо заспавнить по новой?
Как думаешь, что мешает сделать тоже самое на ецс?
Бляяяяяяя
Связь сущностей - это простейшая задача. С ецс тебе ничто не мешает хранить те же данные, что ты и на ооп хуеп хранишь, только с этим в разы проще работать
> там где деспавнилась, игрока там где деспавнился, изи.
Как мы понимаем где они задеспавнились? И кто именно? Что надо заспавнить по новой?
Как думаешь, что мешает сделать тоже самое на ецс?
> Что у нас в ецс? А, просто фарш разных компонентов. Как узнать что этот трансформ и этот меш относился к одному и их надо вернуть? Снова написав эмуляцию оопа, лол.
Бляяяяяяя
Связь сущностей - это простейшая задача. С ецс тебе ничто не мешает хранить те же данные, что ты и на ооп хуеп хранишь, только с этим в разы проще работать
>>19235
Какие кэши? У нас 2 массива.
У нас кэшец никаких нет, поэтому ничего не чистим. Удаляем напрямую из массива.
Блин, наверное не самый удачный вариант да? А не подскажешь, как ты без ецс это делаешь? Наверное есть какие-то еще варианты простые это делать?
> то есть дропаем кэши и считаем заново.
Какие кэши? У нас 2 массива.
> но ты вроде говорил, что этого не происходит? как так?
У нас кэшец никаких нет, поэтому ничего не чистим. Удаляем напрямую из массива.
Блин, наверное не самый удачный вариант да? А не подскажешь, как ты без ецс это делаешь? Наверное есть какие-то еще варианты простые это делать?
Вот мы ебланы то, а)
>>19240
Это не вопрос о реализации или симуляции ооп.
Это вопрос о том "какая информация нужна чтобы понять что мы должны зареспавнить по новой"
Это не вопрос о реализации или симуляции ооп.
Это вопрос о том "какая информация нужна чтобы понять что мы должны зареспавнить по новой"
>>19241
Ну так а ты расскажи, как ты на ооп делаешь.
Или не на ооп, а как то ещё. Наверное там есть какие то такие структры данных, чтобы операции удаления и создания были дешевле, да?)
Ну так а ты расскажи, как ты на ооп делаешь.
Или не на ооп, а как то ещё. Наверное там есть какие то такие структры данных, чтобы операции удаления и создания были дешевле, да?)
>>19243
дропаю кэши, что поделать. ооп же не екс, где кэши не дропаются и всего лишь происходит удаление из массива
дропаю кэши, что поделать. ооп же не екс, где кэши не дропаются и всего лишь происходит удаление из массива
>>19242
В ооп я могу даже не деспавнить объект а поместить указатель на него в пул недавно удаленных, и скажем поставить булевый флажок внутри объекта что его сейчас не надо обрабатывать. При респавне просто добавить снова в массив обрабатываемых объектов и флажочек очистить.
Как примерно ты себе это на ецс представляешь? Для начала тебе нужно удалить каждый компонент объекта из каждого массива компонентов. Что может приводить к перестроению этих массивов. Или ты собираешься каждому компоненту заводить флажок или айдишник, чтобы разъебать этим кэш? Ну собственно как я и говорил ецс дрисня для геймдева не годится.
В ооп я могу даже не деспавнить объект а поместить указатель на него в пул недавно удаленных, и скажем поставить булевый флажок внутри объекта что его сейчас не надо обрабатывать. При респавне просто добавить снова в массив обрабатываемых объектов и флажочек очистить.
Как примерно ты себе это на ецс представляешь? Для начала тебе нужно удалить каждый компонент объекта из каждого массива компонентов. Что может приводить к перестроению этих массивов. Или ты собираешься каждому компоненту заводить флажок или айдишник, чтобы разъебать этим кэш? Ну собственно как я и говорил ецс дрисня для геймдева не годится.
>>19245
О! Да!?
Нихуя себе!
Блин а что если... а что если мы в ецс тоже флажок сделаем?...
Я сейчас пил воду, и я поперхнулся. Ты ебанутый такое писать?
Я думал мы друг друга понимаем, а ты не понял даже ничего.
Помнишь мы про 2 массива говорили?
В одном враги были, в другом пули?
А ты не задумался, почему у нас компонентов много разных, а массива всего 2?
Смотри, простой фокус.
Давай посмотрим на первый массив, что там лежит внутри по порядку:
[позиция][пуля][меш][флажок][позиция][пуля][меш][флажок]
Дошло?
>>19244
Так давай, я жду с самого начала этой хуйни пример. Как ты хранишь какие то объекты, как их создаешь, как удаляешь?
Потому что у тебя там либо реально ооп и все ебало в указателях, соответственно данные хранятся не линейно в памяти, и мы после этого сразу дружно с тобой ебашим бошками об стену с разбегу, а потом ебашим молотком по процессору за то что этот пидорас простаивает со своим бесполезным кешем и дохлым контроллером памяти который не вывозит такие фокусы.
Либо у тебя не ооп а какое умное решение с дата дривен дизайном и структуры данных ускоряющие эти операции. Я кстати неиронично думал что у тебя там этот вариант, но когда ты заговорил про ооп начал подозревать, что что-то тут не чисто.
> В ооп я могу даже не деспавнить объект а поместить указатель на него в пул недавно удаленных, и скажем поставить булевый флажок внутри объекта что его сейчас не надо обрабатывать. При респавне просто добавить снова в массив обрабатываемых объектов и флажочек очистить.
О! Да!?
Нихуя себе!
Блин а что если... а что если мы в ецс тоже флажок сделаем?...
> Как примерно ты себе это на ецс представляешь? Для начала тебе нужно удалить каждый компонент объекта из каждого массива компонентов.
Я сейчас пил воду, и я поперхнулся. Ты ебанутый такое писать?
Я думал мы друг друга понимаем, а ты не понял даже ничего.
Помнишь мы про 2 массива говорили?
В одном враги были, в другом пули?
А ты не задумался, почему у нас компонентов много разных, а массива всего 2?
Смотри, простой фокус.
Давай посмотрим на первый массив, что там лежит внутри по порядку:
[позиция][пуля][меш][флажок][позиция][пуля][меш][флажок]
Дошло?
> Что может приводить к перестроению этих массивов. Или ты собираешься каждому компоненту заводить флажок или айдишник, чтобы разъебать этим кэш? Ну собственно как я и говорил ецс дрисня для геймдева не годится.
>>19244
> дропаю кэши, что поделать. ооп же не екс, где кэши не дропаются и всего лишь происходит удаление из массива
Так давай, я жду с самого начала этой хуйни пример. Как ты хранишь какие то объекты, как их создаешь, как удаляешь?
Потому что у тебя там либо реально ооп и все ебало в указателях, соответственно данные хранятся не линейно в памяти, и мы после этого сразу дружно с тобой ебашим бошками об стену с разбегу, а потом ебашим молотком по процессору за то что этот пидорас простаивает со своим бесполезным кешем и дохлым контроллером памяти который не вывозит такие фокусы.
Либо у тебя не ооп а какое умное решение с дата дривен дизайном и структуры данных ускоряющие эти операции. Я кстати неиронично думал что у тебя там этот вариант, но когда ты заговорил про ооп начал подозревать, что что-то тут не чисто.
>>19245
О! Да!?
Нихуя себе!
Блин а что если... а что если мы в ецс тоже флажок сделаем?...
Я сейчас пил воду, и я поперхнулся. Ты ебанутый такое писать?
Я думал мы друг друга понимаем, а ты не понял даже ничего.
Помнишь мы про 2 массива говорили?
В одном враги были, в другом пули?
А ты не задумался, почему у нас компонентов много разных, а массива всего 2?
Смотри, простой фокус.
Давай посмотрим на первый массив, что там лежит внутри по порядку:
[позиция][пуля][меш][флажок][позиция][пуля][меш][флажок]
Дошло?
>>19244
Так давай, я жду с самого начала этой хуйни пример. Как ты хранишь какие то объекты, как их создаешь, как удаляешь?
Потому что у тебя там либо реально ооп и все ебало в указателях, соответственно данные хранятся не линейно в памяти, и мы после этого сразу дружно с тобой ебашим бошками об стену с разбегу, а потом ебашим молотком по процессору за то что этот пидорас простаивает со своим бесполезным кешем и дохлым контроллером памяти который не вывозит такие фокусы.
Либо у тебя не ооп а какое умное решение с дата дривен дизайном и структуры данных ускоряющие эти операции. Я кстати неиронично думал что у тебя там этот вариант, но когда ты заговорил про ооп начал подозревать, что что-то тут не чисто.
> В ооп я могу даже не деспавнить объект а поместить указатель на него в пул недавно удаленных, и скажем поставить булевый флажок внутри объекта что его сейчас не надо обрабатывать. При респавне просто добавить снова в массив обрабатываемых объектов и флажочек очистить.
О! Да!?
Нихуя себе!
Блин а что если... а что если мы в ецс тоже флажок сделаем?...
> Как примерно ты себе это на ецс представляешь? Для начала тебе нужно удалить каждый компонент объекта из каждого массива компонентов.
Я сейчас пил воду, и я поперхнулся. Ты ебанутый такое писать?
Я думал мы друг друга понимаем, а ты не понял даже ничего.
Помнишь мы про 2 массива говорили?
В одном враги были, в другом пули?
А ты не задумался, почему у нас компонентов много разных, а массива всего 2?
Смотри, простой фокус.
Давай посмотрим на первый массив, что там лежит внутри по порядку:
[позиция][пуля][меш][флажок][позиция][пуля][меш][флажок]
Дошло?
> Что может приводить к перестроению этих массивов. Или ты собираешься каждому компоненту заводить флажок или айдишник, чтобы разъебать этим кэш? Ну собственно как я и говорил ецс дрисня для геймдева не годится.
>>19244
> дропаю кэши, что поделать. ооп же не екс, где кэши не дропаются и всего лишь происходит удаление из массива
Так давай, я жду с самого начала этой хуйни пример. Как ты хранишь какие то объекты, как их создаешь, как удаляешь?
Потому что у тебя там либо реально ооп и все ебало в указателях, соответственно данные хранятся не линейно в памяти, и мы после этого сразу дружно с тобой ебашим бошками об стену с разбегу, а потом ебашим молотком по процессору за то что этот пидорас простаивает со своим бесполезным кешем и дохлым контроллером памяти который не вывозит такие фокусы.
Либо у тебя не ооп а какое умное решение с дата дривен дизайном и структуры данных ускоряющие эти операции. Я кстати неиронично думал что у тебя там этот вариант, но когда ты заговорил про ооп начал подозревать, что что-то тут не чисто.
>>19247
Что?
Это ецс!
Есть ентити, есть компоненты, есть системы.
У нас в нашем с тобой примере даже 3 системы получалось, одна пули двигает, другая врагов, третья рендерит.
Можно даже сделать такую умную систему.
Смотри
Я пишу
foreach(var pos in Ref<Position>())
{
}
И цикл будет по 2 массивам по очереди. Т.е. по всем массивам у которых есть позишен. Автоматически.
Или пишу
foreach(var pos in Ref<Bullet>())
{
}
И цикл будет только по массиву пуль. Потому что только там такоц компонент есть.
Видишь, я даже так и быть сделал тебе апи для выборки компонентов по типам.
Это что блять нахуй такое. Как можно ооп объект запихнуть в массив? Разве там не должен быть массив ссылок на ооп объекты?
Повторим: ецс - это архитектура. А не технические нюансы.
Что?
Это ецс!
Есть ентити, есть компоненты, есть системы.
У нас в нашем с тобой примере даже 3 системы получалось, одна пули двигает, другая врагов, третья рендерит.
Можно даже сделать такую умную систему.
Смотри
Я пишу
foreach(var pos in Ref<Position>())
{
}
И цикл будет по 2 массивам по очереди. Т.е. по всем массивам у которых есть позишен. Автоматически.
Или пишу
foreach(var pos in Ref<Bullet>())
{
}
И цикл будет только по массиву пуль. Потому что только там такоц компонент есть.
Видишь, я даже так и быть сделал тебе апи для выборки компонентов по типам.
> массив с ооп объектами
Это что блять нахуй такое. Как можно ооп объект запихнуть в массив? Разве там не должен быть массив ссылок на ооп объекты?
Повторим: ецс - это архитектура. А не технические нюансы.
>>19247
Что?
Это ецс!
Есть ентити, есть компоненты, есть системы.
У нас в нашем с тобой примере даже 3 системы получалось, одна пули двигает, другая врагов, третья рендерит.
Можно даже сделать такую умную систему.
Смотри
Я пишу
foreach(var pos in Ref<Position>())
{
}
И цикл будет по 2 массивам по очереди. Т.е. по всем массивам у которых есть позишен. Автоматически.
Или пишу
foreach(var pos in Ref<Bullet>())
{
}
И цикл будет только по массиву пуль. Потому что только там такоц компонент есть.
Видишь, я даже так и быть сделал тебе апи для выборки компонентов по типам.
Это что блять нахуй такое. Как можно ооп объект запихнуть в массив? Разве там не должен быть массив ссылок на ооп объекты?
Повторим: ецс - это архитектура. А не технические нюансы.
Что?
Это ецс!
Есть ентити, есть компоненты, есть системы.
У нас в нашем с тобой примере даже 3 системы получалось, одна пули двигает, другая врагов, третья рендерит.
Можно даже сделать такую умную систему.
Смотри
Я пишу
foreach(var pos in Ref<Position>())
{
}
И цикл будет по 2 массивам по очереди. Т.е. по всем массивам у которых есть позишен. Автоматически.
Или пишу
foreach(var pos in Ref<Bullet>())
{
}
И цикл будет только по массиву пуль. Потому что только там такоц компонент есть.
Видишь, я даже так и быть сделал тебе апи для выборки компонентов по типам.
> массив с ооп объектами
Это что блять нахуй такое. Как можно ооп объект запихнуть в массив? Разве там не должен быть массив ссылок на ооп объекты?
Повторим: ецс - это архитектура. А не технические нюансы.
>>19248
У тебя какая то хуерга которая хуже и ецс, и оопа.
Без технической составляющей нет смысла обсуждать перформанс, поскольку именно оттуда он и берется.
То что ты описывашь называется просто Structure of Arrays
https://en.wikipedia.org/wiki/AoS_and_SoA
В c++ это можно сделать бесплатно продолжая пользоваться мощью ооп https://github.com/crosetto/SoAvsAoS
И нет конечно массив может быть массивом объектов, не обязательно указателей. (только есть подозрение что в твоем коде указателей будет еще больше)
Твой код отличается от ецс тем, что ты не можешь делать некоторые энтити без компонентов. Смысл ецс в том что у тебя есть только один массив на компонент, чтобы можно было добавлять и убирать компоненты, например флаг "может летать", "может стрелять". У тебя же никакой экономии нет, потому что вхолостую будут перебираться все поля.
А от ооп отличается тем, что компилятор не сможет оптимизировать, например если у тебя системаА делает y += 5 и системаБ делает y -= gravity, то в ооп компилятор бы увидел что это относится к одному объекту и соптимизировал в y = y + 5 - gravity (что превращается в более быстрый машинный код с меньшим числом записей чтений).
У тебя какая то хуерга которая хуже и ецс, и оопа.
Без технической составляющей нет смысла обсуждать перформанс, поскольку именно оттуда он и берется.
То что ты описывашь называется просто Structure of Arrays
https://en.wikipedia.org/wiki/AoS_and_SoA
В c++ это можно сделать бесплатно продолжая пользоваться мощью ооп https://github.com/crosetto/SoAvsAoS
И нет конечно массив может быть массивом объектов, не обязательно указателей. (только есть подозрение что в твоем коде указателей будет еще больше)
Твой код отличается от ецс тем, что ты не можешь делать некоторые энтити без компонентов. Смысл ецс в том что у тебя есть только один массив на компонент, чтобы можно было добавлять и убирать компоненты, например флаг "может летать", "может стрелять". У тебя же никакой экономии нет, потому что вхолостую будут перебираться все поля.
А от ооп отличается тем, что компилятор не сможет оптимизировать, например если у тебя системаА делает y += 5 и системаБ делает y -= gravity, то в ооп компилятор бы увидел что это относится к одному объекту и соптимизировал в y = y + 5 - gravity (что превращается в более быстрый машинный код с меньшим числом записей чтений).
>>19249
Ецс - это арзитектура в которой есть ентити, компоненты и системы. В системах можно итерировать по разным наборам компонентов. Тут всё это есть.
Блять, да тут не в конкретной технической составляющей дело.
У нас весь затык в удалении и добавлении каких то игровых сущностей.
Ты на отрез отказываешься говорить как бы сделал это без ецс, хотя я тебя в каждом посте прошу это сделать.
Потому что в этом и кроется весь ответ.
Проблема работы с изменяемыми данными актуальна для чего угодно и там используются одни и те же решения, потому что она не характерна какой-то архитектуре, она характерна тому в каком виде хранятся твои данные.
Массив структур у тебя, структура массивов, линкед лист, хэш таблица, дерево, массив с кэширующим дерьмом, разбитый на чанки мир поверх любого из вариантов, любые - это всё работа с данными на низком уровне. Ты можешь любую ебалу наколдовать для своей архитектуры. Хоть ецс, хоть ооп, хоть вообще какая-то хуйня неведомая.
Ты не поверишь, есть даже ецс фреймворки, которые юзают референсы и хуй забивают на локальность данных. Цена - скорость итерации и кэш миссы, зато это развязывает им руки в гибкости и скорости структурных изменений, потому что когда у тебя реф а не индекс в линейной области памяти никакие структурные изменения тебе уже не устроят говняк.
Это не архитектурное решение. Есть же грань между архитектурой и технической реализацйией?
Я могу стракчер оф аррейс сделать, могу аррей оф стракчерз, могу в хэш таблицу ебануть, могу массив бакетов и методы с вычислением хэшей(ой, что это...), это ваще не имеет никакого отношения что я всем эти колдовством реализовываю. Это всё чисто внутренняя техническая реализация нужного мне апи, а не архитектура. Архитектура - это конечное апи которое используется.
Ецс и ооп описывают требования конечному апи(какие в нем идеи должны лежать), а не то что там внутри что щаставляет его работать.
Если я в конечном коде пишу системы и ентити какие то и итерируюсь по типам ентитей - знач эт ецс.
Как, нормально понаследовался, отполиморыизмился, ощутил всю мощь ооп?
Давай засинкаем определния, ооп будем называть ооп, с наследованием, полиморфизмом.
Если у тебя иная организауия конечного геймплейного кода, которач не подращумвеает наследование и полиморфизм, то будем смотреть что там и как.
Если это массив "объектов" то в чем отличие структурных изменений от моего гига ецс фреймворка с 2 массивами?)
Как компилятор может это увидеть в какой-то ситуации, в которой не увилит в системах?
Ну то есть смари, у тебя нечто делает у+= 5, нечто делает у-= гравити.
Эти инструкции в одном методе лежат? Или в разных? Как осуществляется туда заход, если в разных?
> У тебя какая то хуерга которая хуже и ецс, и оопа.
Ецс - это арзитектура в которой есть ентити, компоненты и системы. В системах можно итерировать по разным наборам компонентов. Тут всё это есть.
> Без технической составляющей нет смысла обсуждать перформанс, поскольку именно оттуда он и берется.
Блять, да тут не в конкретной технической составляющей дело.
У нас весь затык в удалении и добавлении каких то игровых сущностей.
Ты на отрез отказываешься говорить как бы сделал это без ецс, хотя я тебя в каждом посте прошу это сделать.
Потому что в этом и кроется весь ответ.
Проблема работы с изменяемыми данными актуальна для чего угодно и там используются одни и те же решения, потому что она не характерна какой-то архитектуре, она характерна тому в каком виде хранятся твои данные.
Массив структур у тебя, структура массивов, линкед лист, хэш таблица, дерево, массив с кэширующим дерьмом, разбитый на чанки мир поверх любого из вариантов, любые - это всё работа с данными на низком уровне. Ты можешь любую ебалу наколдовать для своей архитектуры. Хоть ецс, хоть ооп, хоть вообще какая-то хуйня неведомая.
Ты не поверишь, есть даже ецс фреймворки, которые юзают референсы и хуй забивают на локальность данных. Цена - скорость итерации и кэш миссы, зато это развязывает им руки в гибкости и скорости структурных изменений, потому что когда у тебя реф а не индекс в линейной области памяти никакие структурные изменения тебе уже не устроят говняк.
> То что ты описывашь называется просто Structure of Arrays
Это не архитектурное решение. Есть же грань между архитектурой и технической реализацйией?
Я могу стракчер оф аррейс сделать, могу аррей оф стракчерз, могу в хэш таблицу ебануть, могу массив бакетов и методы с вычислением хэшей(ой, что это...), это ваще не имеет никакого отношения что я всем эти колдовством реализовываю. Это всё чисто внутренняя техническая реализация нужного мне апи, а не архитектура. Архитектура - это конечное апи которое используется.
Ецс и ооп описывают требования конечному апи(какие в нем идеи должны лежать), а не то что там внутри что щаставляет его работать.
Если я в конечном коде пишу системы и ентити какие то и итерируюсь по типам ентитей - знач эт ецс.
> В c++ это можно сделать бесплатно продолжая пользоваться мощью ооп
Как, нормально понаследовался, отполиморыизмился, ощутил всю мощь ооп?
Давай засинкаем определния, ооп будем называть ооп, с наследованием, полиморфизмом.
Если у тебя иная организауия конечного геймплейного кода, которач не подращумвеает наследование и полиморфизм, то будем смотреть что там и как.
> И нет конечно массив может быть массивом объектов, не обязательно указателей. (только есть подозрение что в твоем коде указателей будет еще больше)
Если это массив "объектов" то в чем отличие структурных изменений от моего гига ецс фреймворка с 2 массивами?)
> например если у тебя системаА делает y += 5 и системаБ делает y -= gravity, то в ооп компилятор бы увидел что это относится к одному объекту и соптимизировал в y = y + 5 - gravity
Как компилятор может это увидеть в какой-то ситуации, в которой не увилит в системах?
Ну то есть смари, у тебя нечто делает у+= 5, нечто делает у-= гравити.
Эти инструкции в одном методе лежат? Или в разных? Как осуществляется туда заход, если в разных?
>>19249
Ецс - это арзитектура в которой есть ентити, компоненты и системы. В системах можно итерировать по разным наборам компонентов. Тут всё это есть.
Блять, да тут не в конкретной технической составляющей дело.
У нас весь затык в удалении и добавлении каких то игровых сущностей.
Ты на отрез отказываешься говорить как бы сделал это без ецс, хотя я тебя в каждом посте прошу это сделать.
Потому что в этом и кроется весь ответ.
Проблема работы с изменяемыми данными актуальна для чего угодно и там используются одни и те же решения, потому что она не характерна какой-то архитектуре, она характерна тому в каком виде хранятся твои данные.
Массив структур у тебя, структура массивов, линкед лист, хэш таблица, дерево, массив с кэширующим дерьмом, разбитый на чанки мир поверх любого из вариантов, любые - это всё работа с данными на низком уровне. Ты можешь любую ебалу наколдовать для своей архитектуры. Хоть ецс, хоть ооп, хоть вообще какая-то хуйня неведомая.
Ты не поверишь, есть даже ецс фреймворки, которые юзают референсы и хуй забивают на локальность данных. Цена - скорость итерации и кэш миссы, зато это развязывает им руки в гибкости и скорости структурных изменений, потому что когда у тебя реф а не индекс в линейной области памяти никакие структурные изменения тебе уже не устроят говняк.
Это не архитектурное решение. Есть же грань между архитектурой и технической реализацйией?
Я могу стракчер оф аррейс сделать, могу аррей оф стракчерз, могу в хэш таблицу ебануть, могу массив бакетов и методы с вычислением хэшей(ой, что это...), это ваще не имеет никакого отношения что я всем эти колдовством реализовываю. Это всё чисто внутренняя техническая реализация нужного мне апи, а не архитектура. Архитектура - это конечное апи которое используется.
Ецс и ооп описывают требования конечному апи(какие в нем идеи должны лежать), а не то что там внутри что щаставляет его работать.
Если я в конечном коде пишу системы и ентити какие то и итерируюсь по типам ентитей - знач эт ецс.
Как, нормально понаследовался, отполиморыизмился, ощутил всю мощь ооп?
Давай засинкаем определния, ооп будем называть ооп, с наследованием, полиморфизмом.
Если у тебя иная организауия конечного геймплейного кода, которач не подращумвеает наследование и полиморфизм, то будем смотреть что там и как.
Если это массив "объектов" то в чем отличие структурных изменений от моего гига ецс фреймворка с 2 массивами?)
Как компилятор может это увидеть в какой-то ситуации, в которой не увилит в системах?
Ну то есть смари, у тебя нечто делает у+= 5, нечто делает у-= гравити.
Эти инструкции в одном методе лежат? Или в разных? Как осуществляется туда заход, если в разных?
> У тебя какая то хуерга которая хуже и ецс, и оопа.
Ецс - это арзитектура в которой есть ентити, компоненты и системы. В системах можно итерировать по разным наборам компонентов. Тут всё это есть.
> Без технической составляющей нет смысла обсуждать перформанс, поскольку именно оттуда он и берется.
Блять, да тут не в конкретной технической составляющей дело.
У нас весь затык в удалении и добавлении каких то игровых сущностей.
Ты на отрез отказываешься говорить как бы сделал это без ецс, хотя я тебя в каждом посте прошу это сделать.
Потому что в этом и кроется весь ответ.
Проблема работы с изменяемыми данными актуальна для чего угодно и там используются одни и те же решения, потому что она не характерна какой-то архитектуре, она характерна тому в каком виде хранятся твои данные.
Массив структур у тебя, структура массивов, линкед лист, хэш таблица, дерево, массив с кэширующим дерьмом, разбитый на чанки мир поверх любого из вариантов, любые - это всё работа с данными на низком уровне. Ты можешь любую ебалу наколдовать для своей архитектуры. Хоть ецс, хоть ооп, хоть вообще какая-то хуйня неведомая.
Ты не поверишь, есть даже ецс фреймворки, которые юзают референсы и хуй забивают на локальность данных. Цена - скорость итерации и кэш миссы, зато это развязывает им руки в гибкости и скорости структурных изменений, потому что когда у тебя реф а не индекс в линейной области памяти никакие структурные изменения тебе уже не устроят говняк.
> То что ты описывашь называется просто Structure of Arrays
Это не архитектурное решение. Есть же грань между архитектурой и технической реализацйией?
Я могу стракчер оф аррейс сделать, могу аррей оф стракчерз, могу в хэш таблицу ебануть, могу массив бакетов и методы с вычислением хэшей(ой, что это...), это ваще не имеет никакого отношения что я всем эти колдовством реализовываю. Это всё чисто внутренняя техническая реализация нужного мне апи, а не архитектура. Архитектура - это конечное апи которое используется.
Ецс и ооп описывают требования конечному апи(какие в нем идеи должны лежать), а не то что там внутри что щаставляет его работать.
Если я в конечном коде пишу системы и ентити какие то и итерируюсь по типам ентитей - знач эт ецс.
> В c++ это можно сделать бесплатно продолжая пользоваться мощью ооп
Как, нормально понаследовался, отполиморыизмился, ощутил всю мощь ооп?
Давай засинкаем определния, ооп будем называть ооп, с наследованием, полиморфизмом.
Если у тебя иная организауия конечного геймплейного кода, которач не подращумвеает наследование и полиморфизм, то будем смотреть что там и как.
> И нет конечно массив может быть массивом объектов, не обязательно указателей. (только есть подозрение что в твоем коде указателей будет еще больше)
Если это массив "объектов" то в чем отличие структурных изменений от моего гига ецс фреймворка с 2 массивами?)
> например если у тебя системаА делает y += 5 и системаБ делает y -= gravity, то в ооп компилятор бы увидел что это относится к одному объекту и соптимизировал в y = y + 5 - gravity
Как компилятор может это увидеть в какой-то ситуации, в которой не увилит в системах?
Ну то есть смари, у тебя нечто делает у+= 5, нечто делает у-= гравити.
Эти инструкции в одном методе лежат? Или в разных? Как осуществляется туда заход, если в разных?
>>19246
да вот так и храню - враги, пули, всякие объекты
итерируюсь по ним, вызываю там апдейт. удаляю старое, добавляю новое
>Так давай, я жду с самого начала этой хуйни пример. Как ты хранишь какие то объекты, как их создаешь, как удаляешь?
да вот так и храню - враги, пули, всякие объекты
итерируюсь по ним, вызываю там апдейт. удаляю старое, добавляю новое
>>19251
А почему тогда мне так запретил? Вот, буквально ты говорил
Ну и да, камон, я также в ецс делать могу.
>>19217
Так и я так делаю!
Наверное ключевой вопрос - почему у меня ецс, а у тебя не ецс - а все дело в апи.
Нехитрыми манипуляциями, можно попилить код на компоненты и системы и сделать возможность выборки по типам компонентов, а под капотом будет тоже самое что и у тебя, просто апи доработано для соответствия ецс.
И еще раз повторим, что ецс это архитектурный паттерн.
> да вот так и храню - враги, пули, всякие объекты
> удаляю старое, добавляю новое
А почему тогда мне так запретил? Вот, буквально ты говорил
> мы не дропаем кэши, мы удаляем из массива. я тебя услышал и понял
Ну и да, камон, я также в ецс делать могу.
>>19217
> entityData1[] entities1 = new entityData1[100];
> итерируюсь по ним, вызываю там апдейт
Так и я так делаю!
Наверное ключевой вопрос - почему у меня ецс, а у тебя не ецс - а все дело в апи.
Нехитрыми манипуляциями, можно попилить код на компоненты и системы и сделать возможность выборки по типам компонентов, а под капотом будет тоже самое что и у тебя, просто апи доработано для соответствия ецс.
И еще раз повторим, что ецс это архитектурный паттерн.
>>19253
вот и я не понимаю, зачем ты в екс делаешь то что делается без екс, и делаешь это так, что это противоречит философии и архитектуре екс.
в екс парадигме всё делается атомарными системами типа ЭнемиПукСистем, ЭнемиСренькСистем, где происходит выборка по разным группам компонентов. эти выборки нужно закэшировать, чтобы избежать повторяющихся итераций. это в норме приводит к куче массивов которые ссылаются на одно и то же - иначе екс тупо будет еле пердеть, итерируясь по миллионам сущностей сотни раз за кадр. то есть у тебя не два массива как ты написал, думая, что это так работает, а тысячи. в динамичной игре это приведет к постоянным дропам этих кэшей и замедлению производительности.
вот и я не понимаю, зачем ты в екс делаешь то что делается без екс, и делаешь это так, что это противоречит философии и архитектуре екс.
в екс парадигме всё делается атомарными системами типа ЭнемиПукСистем, ЭнемиСренькСистем, где происходит выборка по разным группам компонентов. эти выборки нужно закэшировать, чтобы избежать повторяющихся итераций. это в норме приводит к куче массивов которые ссылаются на одно и то же - иначе екс тупо будет еле пердеть, итерируясь по миллионам сущностей сотни раз за кадр. то есть у тебя не два массива как ты написал, думая, что это так работает, а тысячи. в динамичной игре это приведет к постоянным дропам этих кэшей и замедлению производительности.
>>19254
НЕЕЕЕТ Не нужно!
Не не не не
Смари, смари, это гениально и просто. Ты не понял прикола.
У нас есть ентити с position, bullet, graphics - типа пульки летающие
Есть ентити с position, health, enemy, graphics - типа враги бегающие
Есть ентити с position, health, player, graphics - типа игрок
Теперь представь, мы сделали так:
Когда мы создаем пулю с этими 3 компонентами - под неё автоматически создасться массив если его нет, и в конец вставится пуля.
Когда создали врага - под врагов автоматически создаться массив ив конец положится враг.
Аналогично с игроками.
То есть чем больше вариантов наборов компонентов - тем больше массив.
Создадим какой то player bullet position graphics - что ж, под это создасться 4 массив.
Тут думаю вопросов нет.
А тепепь у нас все таки ецс, мы хотим сделать цикл по всем ентитям у которвх есть позиция и сделать гравитауию.
В клиентском коде мы берем и пишем:
foreach(var position in RefRW<Position>())
{
position.RefRW.y -= 10;
}
И вот эта вот запись обозначает то, что мы делаем цикл по всем нашим 3 массивам.
Теперь хотим пули подвинуть вперед
Берем и:
foreach(var (position, bullet) in RefRW<Position>, RefRW<Bullet>())
{
position.RefRW += bullet.speed;
}
И оно пройдется только по 1 массиву с пулями.
Важные моментв:
1. Нам ничего не нужно апдейтить, кешировать каждый кадр, у нас есть эти 3 массива - каждый содержит уникальные данные. Всё, больше ничего не нужно
То есть это эквивалент твоих
bullet[] bullets
enemy[] enemies
player[] players
2. На этапе компиляции мы знаем какие массивы нам нужны для каждой выборки. В рантайме нам ничего вычислять и определять не нужно.
Скажкм, смотрим исходники, видим - ага (буллет, позишен) будет индекс 1, (позишен) индекс 2, там где у нас цикл по позишен будет цикл по массивы[2], а там где цикл по (пощишен, буллет) будет цикл по массивы[1]. Ток офысеты там надо прибавить к адресам чтобы получить смещение для компонента.
Опять же - кодогенерацией это очень легко достижимо.
Получается, что под капотом там ровно тоже самое что и у тебя.
Всё что отличается - конечное апи - у тебя напрямую массивы и явно заведенные типы, тут такие конструкты из набора "компонентов" и возможность итерировать по выборке такиз компонентов.
По факту это уже квалифицируется как ецс, потому что есть компоненты, есть системы, есть ентити.
Ну и где проблемы с производительностью?
Ну а если мы говорим про дотс, то там ещё интереснее, там данные не просто в массивах лежат, а разбиты на чанки фиксированных размеров, и там системы выполняются в автоматическом режиме, подстраиваясь под чтение и запись других систем с заданными ограничениями порядка, в итоге получается так, что у тебя и каждая система по отдельности может работать в многопотоке, оьрабатывая сразу несколько ентитей сразу, и несколько систем сразу могут работать олнвоременно, если они друг друга не блокируют, и вот это уже сила.
> где происходит выборка по разным группам компонентов. эти выборки нужно закэшировать
НЕЕЕЕТ Не нужно!
> приводит к куче массивов которые ссылаются на одно и то же - иначе екс тупо будет еле пердеть, итерируясь по миллионам сущностей сотни раз за кадр. то есть у тебя не два массива как ты написал, думая, что это так работает, а тысячи.
Не не не не
Смари, смари, это гениально и просто. Ты не понял прикола.
У нас есть ентити с position, bullet, graphics - типа пульки летающие
Есть ентити с position, health, enemy, graphics - типа враги бегающие
Есть ентити с position, health, player, graphics - типа игрок
Теперь представь, мы сделали так:
Когда мы создаем пулю с этими 3 компонентами - под неё автоматически создасться массив если его нет, и в конец вставится пуля.
Когда создали врага - под врагов автоматически создаться массив ив конец положится враг.
Аналогично с игроками.
То есть чем больше вариантов наборов компонентов - тем больше массив.
Создадим какой то player bullet position graphics - что ж, под это создасться 4 массив.
Тут думаю вопросов нет.
А тепепь у нас все таки ецс, мы хотим сделать цикл по всем ентитям у которвх есть позиция и сделать гравитауию.
В клиентском коде мы берем и пишем:
foreach(var position in RefRW<Position>())
{
position.RefRW.y -= 10;
}
И вот эта вот запись обозначает то, что мы делаем цикл по всем нашим 3 массивам.
Теперь хотим пули подвинуть вперед
Берем и:
foreach(var (position, bullet) in RefRW<Position>, RefRW<Bullet>())
{
position.RefRW += bullet.speed;
}
И оно пройдется только по 1 массиву с пулями.
Важные моментв:
1. Нам ничего не нужно апдейтить, кешировать каждый кадр, у нас есть эти 3 массива - каждый содержит уникальные данные. Всё, больше ничего не нужно
То есть это эквивалент твоих
bullet[] bullets
enemy[] enemies
player[] players
2. На этапе компиляции мы знаем какие массивы нам нужны для каждой выборки. В рантайме нам ничего вычислять и определять не нужно.
Скажкм, смотрим исходники, видим - ага (буллет, позишен) будет индекс 1, (позишен) индекс 2, там где у нас цикл по позишен будет цикл по массивы[2], а там где цикл по (пощишен, буллет) будет цикл по массивы[1]. Ток офысеты там надо прибавить к адресам чтобы получить смещение для компонента.
Опять же - кодогенерацией это очень легко достижимо.
Получается, что под капотом там ровно тоже самое что и у тебя.
Всё что отличается - конечное апи - у тебя напрямую массивы и явно заведенные типы, тут такие конструкты из набора "компонентов" и возможность итерировать по выборке такиз компонентов.
По факту это уже квалифицируется как ецс, потому что есть компоненты, есть системы, есть ентити.
Ну и где проблемы с производительностью?
Ну а если мы говорим про дотс, то там ещё интереснее, там данные не просто в массивах лежат, а разбиты на чанки фиксированных размеров, и там системы выполняются в автоматическом режиме, подстраиваясь под чтение и запись других систем с заданными ограничениями порядка, в итоге получается так, что у тебя и каждая система по отдельности может работать в многопотоке, оьрабатывая сразу несколько ентитей сразу, и несколько систем сразу могут работать олнвоременно, если они друг друга не блокируют, и вот это уже сила.
>>19254
НЕЕЕЕТ Не нужно!
Не не не не
Смари, смари, это гениально и просто. Ты не понял прикола.
У нас есть ентити с position, bullet, graphics - типа пульки летающие
Есть ентити с position, health, enemy, graphics - типа враги бегающие
Есть ентити с position, health, player, graphics - типа игрок
Теперь представь, мы сделали так:
Когда мы создаем пулю с этими 3 компонентами - под неё автоматически создасться массив если его нет, и в конец вставится пуля.
Когда создали врага - под врагов автоматически создаться массив ив конец положится враг.
Аналогично с игроками.
То есть чем больше вариантов наборов компонентов - тем больше массив.
Создадим какой то player bullet position graphics - что ж, под это создасться 4 массив.
Тут думаю вопросов нет.
А тепепь у нас все таки ецс, мы хотим сделать цикл по всем ентитям у которвх есть позиция и сделать гравитауию.
В клиентском коде мы берем и пишем:
foreach(var position in RefRW<Position>())
{
position.RefRW.y -= 10;
}
И вот эта вот запись обозначает то, что мы делаем цикл по всем нашим 3 массивам.
Теперь хотим пули подвинуть вперед
Берем и:
foreach(var (position, bullet) in RefRW<Position>, RefRW<Bullet>())
{
position.RefRW += bullet.speed;
}
И оно пройдется только по 1 массиву с пулями.
Важные моментв:
1. Нам ничего не нужно апдейтить, кешировать каждый кадр, у нас есть эти 3 массива - каждый содержит уникальные данные. Всё, больше ничего не нужно
То есть это эквивалент твоих
bullet[] bullets
enemy[] enemies
player[] players
2. На этапе компиляции мы знаем какие массивы нам нужны для каждой выборки. В рантайме нам ничего вычислять и определять не нужно.
Скажкм, смотрим исходники, видим - ага (буллет, позишен) будет индекс 1, (позишен) индекс 2, там где у нас цикл по позишен будет цикл по массивы[2], а там где цикл по (пощишен, буллет) будет цикл по массивы[1]. Ток офысеты там надо прибавить к адресам чтобы получить смещение для компонента.
Опять же - кодогенерацией это очень легко достижимо.
Получается, что под капотом там ровно тоже самое что и у тебя.
Всё что отличается - конечное апи - у тебя напрямую массивы и явно заведенные типы, тут такие конструкты из набора "компонентов" и возможность итерировать по выборке такиз компонентов.
По факту это уже квалифицируется как ецс, потому что есть компоненты, есть системы, есть ентити.
Ну и где проблемы с производительностью?
Ну а если мы говорим про дотс, то там ещё интереснее, там данные не просто в массивах лежат, а разбиты на чанки фиксированных размеров, и там системы выполняются в автоматическом режиме, подстраиваясь под чтение и запись других систем с заданными ограничениями порядка, в итоге получается так, что у тебя и каждая система по отдельности может работать в многопотоке, оьрабатывая сразу несколько ентитей сразу, и несколько систем сразу могут работать олнвоременно, если они друг друга не блокируют, и вот это уже сила.
> где происходит выборка по разным группам компонентов. эти выборки нужно закэшировать
НЕЕЕЕТ Не нужно!
> приводит к куче массивов которые ссылаются на одно и то же - иначе екс тупо будет еле пердеть, итерируясь по миллионам сущностей сотни раз за кадр. то есть у тебя не два массива как ты написал, думая, что это так работает, а тысячи.
Не не не не
Смари, смари, это гениально и просто. Ты не понял прикола.
У нас есть ентити с position, bullet, graphics - типа пульки летающие
Есть ентити с position, health, enemy, graphics - типа враги бегающие
Есть ентити с position, health, player, graphics - типа игрок
Теперь представь, мы сделали так:
Когда мы создаем пулю с этими 3 компонентами - под неё автоматически создасться массив если его нет, и в конец вставится пуля.
Когда создали врага - под врагов автоматически создаться массив ив конец положится враг.
Аналогично с игроками.
То есть чем больше вариантов наборов компонентов - тем больше массив.
Создадим какой то player bullet position graphics - что ж, под это создасться 4 массив.
Тут думаю вопросов нет.
А тепепь у нас все таки ецс, мы хотим сделать цикл по всем ентитям у которвх есть позиция и сделать гравитауию.
В клиентском коде мы берем и пишем:
foreach(var position in RefRW<Position>())
{
position.RefRW.y -= 10;
}
И вот эта вот запись обозначает то, что мы делаем цикл по всем нашим 3 массивам.
Теперь хотим пули подвинуть вперед
Берем и:
foreach(var (position, bullet) in RefRW<Position>, RefRW<Bullet>())
{
position.RefRW += bullet.speed;
}
И оно пройдется только по 1 массиву с пулями.
Важные моментв:
1. Нам ничего не нужно апдейтить, кешировать каждый кадр, у нас есть эти 3 массива - каждый содержит уникальные данные. Всё, больше ничего не нужно
То есть это эквивалент твоих
bullet[] bullets
enemy[] enemies
player[] players
2. На этапе компиляции мы знаем какие массивы нам нужны для каждой выборки. В рантайме нам ничего вычислять и определять не нужно.
Скажкм, смотрим исходники, видим - ага (буллет, позишен) будет индекс 1, (позишен) индекс 2, там где у нас цикл по позишен будет цикл по массивы[2], а там где цикл по (пощишен, буллет) будет цикл по массивы[1]. Ток офысеты там надо прибавить к адресам чтобы получить смещение для компонента.
Опять же - кодогенерацией это очень легко достижимо.
Получается, что под капотом там ровно тоже самое что и у тебя.
Всё что отличается - конечное апи - у тебя напрямую массивы и явно заведенные типы, тут такие конструкты из набора "компонентов" и возможность итерировать по выборке такиз компонентов.
По факту это уже квалифицируется как ецс, потому что есть компоненты, есть системы, есть ентити.
Ну и где проблемы с производительностью?
Ну а если мы говорим про дотс, то там ещё интереснее, там данные не просто в массивах лежат, а разбиты на чанки фиксированных размеров, и там системы выполняются в автоматическом режиме, подстраиваясь под чтение и запись других систем с заданными ограничениями порядка, в итоге получается так, что у тебя и каждая система по отдельности может работать в многопотоке, оьрабатывая сразу несколько ентитей сразу, и несколько систем сразу могут работать олнвоременно, если они друг друга не блокируют, и вот это уже сила.
>>19259
Всратый кал, непригодный к использованию в игровых движках. Ты поли каунт видишь, или тебе это ни о чем не говорит?
Чтобы это можно было использовать, придется заново сделать лоуполи руками.
Это можно использовать максимум в качестве рефа, который можно покрутить, по которому ты потом будешь с нуля делать нормальную модель.
Всратый кал, непригодный к использованию в игровых движках. Ты поли каунт видишь, или тебе это ни о чем не говорит?
Чтобы это можно было использовать, придется заново сделать лоуполи руками.
Это можно использовать максимум в качестве рефа, который можно покрутить, по которому ты потом будешь с нуля делать нормальную модель.
>>19259
Будто расплавило замок.
Будто расплавило замок.
>>19259
Какашка. Буквально.
Какашка. Буквально.
>>19250
Нет, у тебя нет независимых компонентов.
Ты же сам пишешь что у тебя фиксировано
[позиция][пуля][меш][флажок][позиция][пуля][меш][флажок]
А значит ты не можешь сделать
[позиция][пуля][меш][флажок][позиция][меш][флажок][позиция][пуля][щит][меш]
По сути у тебя есть только объекты с 4 полями.
Лично меня ты не спрашивал, с тобой тут не один анон спорит. В ооп для этого есть композиция.
Ну так ты сам себя и разъебываешь - ты то писал что у тебя перформанс именно благодаря ецс архитектуре. А тут сам признаешься что это не свойство архитектуры.
Компилятор знает что это один объект, поэтому и оптимизирует.
Когда ты итерируешь по компонентам, компилятор никак не сможет узнать, что в рантайме на этом кадре 5-й компонент в одном массиве это тот же игровой объект что 7-й компонент во втором.
Эквилибристика, типа игнорируешь что у тебя не екц, но если я не пользуюсь наследованием то у меня не ооп. Нет, у меня ооп потому что есть объект, который группирует поля данных и методы.
МОгу подытожить - прирост производительности в ецс ты бы увидел только на 10000+ однотипных объектах делающих однотипное действие. Типа солдатики в стратегии маршируют одинаково. Если ты тот анон который говорил про 16 или 32 игровых персонажа в кадре - ты никакого прироста от ецс (который у тебя и не ецс, на самом деле, а вариант оопа в котором ты возможно даже мешаешь компилятору оптимизировать) - просто никак получить не сможешь.
>Ецс - это арзитектура в которой есть ентити, компоненты и системы. В системах можно итерировать по разным наборам компонентов. Тут всё это есть.
Нет, у тебя нет независимых компонентов.
Ты же сам пишешь что у тебя фиксировано
[позиция][пуля][меш][флажок][позиция][пуля][меш][флажок]
А значит ты не можешь сделать
[позиция][пуля][меш][флажок][позиция][меш][флажок][позиция][пуля][щит][меш]
По сути у тебя есть только объекты с 4 полями.
>Ты на отрез отказываешься говорить как бы сделал это без ецс, хотя я тебя в каждом посте прошу это сделать.
Лично меня ты не спрашивал, с тобой тут не один анон спорит. В ооп для этого есть композиция.
>есть даже ецс фреймворки, которые юзают референсы и хуй забивают на локальность данных. Цена - скорость итерации и кэш миссы
Ну так ты сам себя и разъебываешь - ты то писал что у тебя перформанс именно благодаря ецс архитектуре. А тут сам признаешься что это не свойство архитектуры.
>у тебя нечто делает у+= 5, нечто делает у-= гравити. Эти инструкции в одном методе лежат? Или в разных?
Компилятор знает что это один объект, поэтому и оптимизирует.
Когда ты итерируешь по компонентам, компилятор никак не сможет узнать, что в рантайме на этом кадре 5-й компонент в одном массиве это тот же игровой объект что 7-й компонент во втором.
>которач не подращумвеает наследование и полиморфизм, то будем смотреть что там и как.
Эквилибристика, типа игнорируешь что у тебя не екц, но если я не пользуюсь наследованием то у меня не ооп. Нет, у меня ооп потому что есть объект, который группирует поля данных и методы.
МОгу подытожить - прирост производительности в ецс ты бы увидел только на 10000+ однотипных объектах делающих однотипное действие. Типа солдатики в стратегии маршируют одинаково. Если ты тот анон который говорил про 16 или 32 игровых персонажа в кадре - ты никакого прироста от ецс (который у тебя и не ецс, на самом деле, а вариант оопа в котором ты возможно даже мешаешь компилятору оптимизировать) - просто никак получить не сможешь.
>>19255
ECS итерирует не по энтити, а по компонентам, вот где твое заблуждение.
Производительность у тебя теряется в нескольких местах:
1. Если бы ты итерировал по компонентам, то в кэш влезало бы в 4 раза больше игровых объектов. А так у тебя через кэш каждый раз протискивается весь объект.
2. Если ты будешь испольовать ецс как настоящий ецс, а не как эрзац-пародию, то ты будешь добавлять-удалять компоненты энтитям динамически, (ну например хотим сделать юнит неуязвимым- удаляем компонент health) а значит тебе придется перетасовывать массивы, ведь объект придется удалить из массива номер 3 и перенести в массив номер 4.
тебе надо было просто сразу сказать что у тебя говнюнити, мы бы на тебя просто время не тратили, потому что все знают что там не ецс, а пародия.
ECS итерирует не по энтити, а по компонентам, вот где твое заблуждение.
Производительность у тебя теряется в нескольких местах:
1. Если бы ты итерировал по компонентам, то в кэш влезало бы в 4 раза больше игровых объектов. А так у тебя через кэш каждый раз протискивается весь объект.
2. Если ты будешь испольовать ецс как настоящий ецс, а не как эрзац-пародию, то ты будешь добавлять-удалять компоненты энтитям динамически, (ну например хотим сделать юнит неуязвимым- удаляем компонент health) а значит тебе придется перетасовывать массивы, ведь объект придется удалить из массива номер 3 и перенести в массив номер 4.
тебе надо было просто сразу сказать что у тебя говнюнити, мы бы на тебя просто время не тратили, потому что все знают что там не ецс, а пародия.
>>19328
Могу. Добавляю новый массив, под капотом. Тут все описано. Заебало одно и тоже пересказывать >>19255
Ну так может написал бы тогда сейчас вместо этого ответа "ыыы ты меня не спрашивал"? Спрашиваю сейчас, че.
Давай пример псевдокода. Мне кажется оно у тебя там нихуя не соптимизирует и у тебя слишком далекая связь чтобы компилятор мог это вывести.
Если у тебя последовательно идут вызовы monster.ApplyGravity(), monster.Move() то так можно вывести, но ты также можешь сделать в ецс.
В десятый раз повторяю, объекты и все их данные существуют в единственной копии.
Вот тебе например определение ецс
https://en.m.wikipedia.org/wiki/Entity_component_system
Покажи противоречия
Ооп традиционно называют вот что
https://en.m.wikipedia.org/wiki/Object-oriented_programming
Покажи где у тебя есть наследование и полиморфизм которые являются ключевой идеей ооп
И да, в этом проблемы нет, ооп там, ецс, просто есть довольно конкретные определения общепринятые и я писал в их терминологии. Ты начал говорить, что у меня не та терминология, а не я, хотя как выяснилось как раз твои определения не соответствуют общепринятым.
Ецс - это архитектурный паттерн.
Исходный тезис был в том, что он плохо ложится на производительность и есть много издержек лишних.
Мой ответ в том, что нет, ецс можно совершенно разными способами внутри реализовать, в том числе точно такими же как ты сделал бы это без ецс, и как таковых заведомых проблем с производительностью ецс архитектура не несёт.
Говоря о практике, есть ецс фреймворки с которыми можно сравнительно легко достичь очень большой производительности, засчет распараллеливания итераций по большому числу ентитей, распараллеливанию систем(несколько неблокирующих будут работать одновременно). Каких-то других общих практик достичь такого - нету. Только долгое изобретение своего кастомного варианта под кокнретную игру, с поиском всех вариантов как это соптимищировать.
Помимо этого я выше заявлял:
1. Использование ецс в готовом движке не несёт лишнего заведомого оверхеда, у тебя полныц контроль с точки зрения программирования что ты делаешь
2. Связь любых двух систем делается схожими методами, как ецс можео подружить со сторонним физическим движком, так и любую игру можео подружить со сторонним физическим движком
3. Ецс не обязательно предполагает какие-то обязательные расчёты каждый кадр, есть реализации ецс с 0 оверхедом в кадре
4. Нет никакого лишнего оверхеда для куллинга и повторного выполненич той же работы
На это как таковых ответов не вижу, можешь линкануть или написать, если не согласен.
>>19330
Что это предложение значит?
Концепция ецс предполагает в клиентском коде возможность итераций по заданному набору компонентов. У меня это реализовано.
Действительно, есть такое. А ты уверен, что это даст больший проигрыш, чем нарушение предикта процессором засчет бранчинга и большего набора инструкций и разнородности ввполнчемых операций?
Я - нет.
Ещё и есть непонятки с многопотоком, потому что отделение операций на простве и взаимонеблокирующие позволчет многое параллелить, в отличии от твоего нагромождения логики в одном месте, что в любом случае будет блокировать выполнение логики в другом местк пока этот объект не обработается.
И в ооооочередной раз прошу тебя рассказать, как бы ты решал схожую проблему без ецс.
(С ецс те же самые практики применимы, а также и некоторые другие)
Поебать что за движок, выше я также уже много раз говорил, что у тебя есть ЯП чтобы реализовать что угодно в чем угодно.
А что по юнити - там как раз самый трушный ецс какой можно себе представить(следуя твоему же определению, я же до сих пор твержу, что ецс это архитектурный паттерн а не твои маня фантазии о внутреннем устройстве) с наверное самым большим перформансом на рынке.
> Ты же сам пишешь что у тебя фиксировано
> [позиция][пуля][меш][флажок][позиция][пуля][меш][флажок]
> А значит ты не можешь сделать
> [позиция][пуля][меш][флажок][позиция][меш][флажок][позиция][пуля][щит][меш]
> По сути у тебя есть только объекты с 4 полями.
Могу. Добавляю новый массив, под капотом. Тут все описано. Заебало одно и тоже пересказывать >>19255
> Лично меня ты не спрашивал, с тобой тут не один анон спорит. В ооп для этого есть композиция.
Ну так может написал бы тогда сейчас вместо этого ответа "ыыы ты меня не спрашивал"? Спрашиваю сейчас, че.
> Компилятор знает что это один объект, поэтому и оптимизирует.
Давай пример псевдокода. Мне кажется оно у тебя там нихуя не соптимизирует и у тебя слишком далекая связь чтобы компилятор мог это вывести.
Если у тебя последовательно идут вызовы monster.ApplyGravity(), monster.Move() то так можно вывести, но ты также можешь сделать в ецс.
> Когда ты итерируешь по компонентам, компилятор никак не сможет узнать, что в рантайме на этом кадре 5-й компонент в одном массиве это тот же игровой объект что 7-й компонент во втором.
В десятый раз повторяю, объекты и все их данные существуют в единственной копии.
> Эквилибристика, типа игнорируешь что у тебя не екц
Вот тебе например определение ецс
https://en.m.wikipedia.org/wiki/Entity_component_system
Покажи противоречия
> но если я не пользуюсь наследованием то у меня не ооп
> Нет, у меня ооп потому что есть объект, который группирует поля данных и методы.
Ооп традиционно называют вот что
https://en.m.wikipedia.org/wiki/Object-oriented_programming
Покажи где у тебя есть наследование и полиморфизм которые являются ключевой идеей ооп
И да, в этом проблемы нет, ооп там, ецс, просто есть довольно конкретные определения общепринятые и я писал в их терминологии. Ты начал говорить, что у меня не та терминология, а не я, хотя как выяснилось как раз твои определения не соответствуют общепринятым.
> МОгу подытожить - прирост производительности в ецс ты бы увидел только на 10000+ однотипных объектах делающих однотипное действие. Типа солдатики в стратегии маршируют одинаково. Если ты тот анон который говорил про 16 или 32 игровых персонажа в кадре - ты никакого прироста от ецс (который у тебя и не ецс, на самом деле, а вариант оопа в котором ты возможно даже мешаешь компилятору оптимизировать) - просто никак получить не сможешь.
Ецс - это архитектурный паттерн.
Исходный тезис был в том, что он плохо ложится на производительность и есть много издержек лишних.
Мой ответ в том, что нет, ецс можно совершенно разными способами внутри реализовать, в том числе точно такими же как ты сделал бы это без ецс, и как таковых заведомых проблем с производительностью ецс архитектура не несёт.
Говоря о практике, есть ецс фреймворки с которыми можно сравнительно легко достичь очень большой производительности, засчет распараллеливания итераций по большому числу ентитей, распараллеливанию систем(несколько неблокирующих будут работать одновременно). Каких-то других общих практик достичь такого - нету. Только долгое изобретение своего кастомного варианта под кокнретную игру, с поиском всех вариантов как это соптимищировать.
Помимо этого я выше заявлял:
1. Использование ецс в готовом движке не несёт лишнего заведомого оверхеда, у тебя полныц контроль с точки зрения программирования что ты делаешь
2. Связь любых двух систем делается схожими методами, как ецс можео подружить со сторонним физическим движком, так и любую игру можео подружить со сторонним физическим движком
3. Ецс не обязательно предполагает какие-то обязательные расчёты каждый кадр, есть реализации ецс с 0 оверхедом в кадре
4. Нет никакого лишнего оверхеда для куллинга и повторного выполненич той же работы
На это как таковых ответов не вижу, можешь линкануть или написать, если не согласен.
>>19330
> ECS итерирует не по энтити, а по компонентам, вот где твое заблуждение.
Что это предложение значит?
Концепция ецс предполагает в клиентском коде возможность итераций по заданному набору компонентов. У меня это реализовано.
> Производительность у тебя теряется в нескольких местах:
> 1. Если бы ты итерировал по компонентам, то в кэш влезало бы в 4 раза больше игровых объектов. А так у тебя через кэш каждый раз протискивается весь объект.
Действительно, есть такое. А ты уверен, что это даст больший проигрыш, чем нарушение предикта процессором засчет бранчинга и большего набора инструкций и разнородности ввполнчемых операций?
Я - нет.
Ещё и есть непонятки с многопотоком, потому что отделение операций на простве и взаимонеблокирующие позволчет многое параллелить, в отличии от твоего нагромождения логики в одном месте, что в любом случае будет блокировать выполнение логики в другом местк пока этот объект не обработается.
> 2. Если ты будешь испольовать ецс как настоящий ецс, а не как эрзац-пародию, то ты будешь добавлять-удалять компоненты энтитям динамически, (ну например хотим сделать юнит неуязвимым- удаляем компонент health) а значит тебе придется перетасовывать массивы, ведь объект придется удалить из массива номер 3 и перенести в массив номер 4.
И в ооооочередной раз прошу тебя рассказать, как бы ты решал схожую проблему без ецс.
(С ецс те же самые практики применимы, а также и некоторые другие)
> тебе надо было просто сразу сказать что у тебя говнюнити, мы бы на тебя просто время не тратили, потому что все знают что там не ецс, а пародия.
Поебать что за движок, выше я также уже много раз говорил, что у тебя есть ЯП чтобы реализовать что угодно в чем угодно.
А что по юнити - там как раз самый трушный ецс какой можно себе представить(следуя твоему же определению, я же до сих пор твержу, что ецс это архитектурный паттерн а не твои маня фантазии о внутреннем устройстве) с наверное самым большим перформансом на рынке.
>>19328
Могу. Добавляю новый массив, под капотом. Тут все описано. Заебало одно и тоже пересказывать >>19255
Ну так может написал бы тогда сейчас вместо этого ответа "ыыы ты меня не спрашивал"? Спрашиваю сейчас, че.
Давай пример псевдокода. Мне кажется оно у тебя там нихуя не соптимизирует и у тебя слишком далекая связь чтобы компилятор мог это вывести.
Если у тебя последовательно идут вызовы monster.ApplyGravity(), monster.Move() то так можно вывести, но ты также можешь сделать в ецс.
В десятый раз повторяю, объекты и все их данные существуют в единственной копии.
Вот тебе например определение ецс
https://en.m.wikipedia.org/wiki/Entity_component_system
Покажи противоречия
Ооп традиционно называют вот что
https://en.m.wikipedia.org/wiki/Object-oriented_programming
Покажи где у тебя есть наследование и полиморфизм которые являются ключевой идеей ооп
И да, в этом проблемы нет, ооп там, ецс, просто есть довольно конкретные определения общепринятые и я писал в их терминологии. Ты начал говорить, что у меня не та терминология, а не я, хотя как выяснилось как раз твои определения не соответствуют общепринятым.
Ецс - это архитектурный паттерн.
Исходный тезис был в том, что он плохо ложится на производительность и есть много издержек лишних.
Мой ответ в том, что нет, ецс можно совершенно разными способами внутри реализовать, в том числе точно такими же как ты сделал бы это без ецс, и как таковых заведомых проблем с производительностью ецс архитектура не несёт.
Говоря о практике, есть ецс фреймворки с которыми можно сравнительно легко достичь очень большой производительности, засчет распараллеливания итераций по большому числу ентитей, распараллеливанию систем(несколько неблокирующих будут работать одновременно). Каких-то других общих практик достичь такого - нету. Только долгое изобретение своего кастомного варианта под кокнретную игру, с поиском всех вариантов как это соптимищировать.
Помимо этого я выше заявлял:
1. Использование ецс в готовом движке не несёт лишнего заведомого оверхеда, у тебя полныц контроль с точки зрения программирования что ты делаешь
2. Связь любых двух систем делается схожими методами, как ецс можео подружить со сторонним физическим движком, так и любую игру можео подружить со сторонним физическим движком
3. Ецс не обязательно предполагает какие-то обязательные расчёты каждый кадр, есть реализации ецс с 0 оверхедом в кадре
4. Нет никакого лишнего оверхеда для куллинга и повторного выполненич той же работы
На это как таковых ответов не вижу, можешь линкануть или написать, если не согласен.
>>19330
Что это предложение значит?
Концепция ецс предполагает в клиентском коде возможность итераций по заданному набору компонентов. У меня это реализовано.
Действительно, есть такое. А ты уверен, что это даст больший проигрыш, чем нарушение предикта процессором засчет бранчинга и большего набора инструкций и разнородности ввполнчемых операций?
Я - нет.
Ещё и есть непонятки с многопотоком, потому что отделение операций на простве и взаимонеблокирующие позволчет многое параллелить, в отличии от твоего нагромождения логики в одном месте, что в любом случае будет блокировать выполнение логики в другом местк пока этот объект не обработается.
И в ооооочередной раз прошу тебя рассказать, как бы ты решал схожую проблему без ецс.
(С ецс те же самые практики применимы, а также и некоторые другие)
Поебать что за движок, выше я также уже много раз говорил, что у тебя есть ЯП чтобы реализовать что угодно в чем угодно.
А что по юнити - там как раз самый трушный ецс какой можно себе представить(следуя твоему же определению, я же до сих пор твержу, что ецс это архитектурный паттерн а не твои маня фантазии о внутреннем устройстве) с наверное самым большим перформансом на рынке.
> Ты же сам пишешь что у тебя фиксировано
> [позиция][пуля][меш][флажок][позиция][пуля][меш][флажок]
> А значит ты не можешь сделать
> [позиция][пуля][меш][флажок][позиция][меш][флажок][позиция][пуля][щит][меш]
> По сути у тебя есть только объекты с 4 полями.
Могу. Добавляю новый массив, под капотом. Тут все описано. Заебало одно и тоже пересказывать >>19255
> Лично меня ты не спрашивал, с тобой тут не один анон спорит. В ооп для этого есть композиция.
Ну так может написал бы тогда сейчас вместо этого ответа "ыыы ты меня не спрашивал"? Спрашиваю сейчас, че.
> Компилятор знает что это один объект, поэтому и оптимизирует.
Давай пример псевдокода. Мне кажется оно у тебя там нихуя не соптимизирует и у тебя слишком далекая связь чтобы компилятор мог это вывести.
Если у тебя последовательно идут вызовы monster.ApplyGravity(), monster.Move() то так можно вывести, но ты также можешь сделать в ецс.
> Когда ты итерируешь по компонентам, компилятор никак не сможет узнать, что в рантайме на этом кадре 5-й компонент в одном массиве это тот же игровой объект что 7-й компонент во втором.
В десятый раз повторяю, объекты и все их данные существуют в единственной копии.
> Эквилибристика, типа игнорируешь что у тебя не екц
Вот тебе например определение ецс
https://en.m.wikipedia.org/wiki/Entity_component_system
Покажи противоречия
> но если я не пользуюсь наследованием то у меня не ооп
> Нет, у меня ооп потому что есть объект, который группирует поля данных и методы.
Ооп традиционно называют вот что
https://en.m.wikipedia.org/wiki/Object-oriented_programming
Покажи где у тебя есть наследование и полиморфизм которые являются ключевой идеей ооп
И да, в этом проблемы нет, ооп там, ецс, просто есть довольно конкретные определения общепринятые и я писал в их терминологии. Ты начал говорить, что у меня не та терминология, а не я, хотя как выяснилось как раз твои определения не соответствуют общепринятым.
> МОгу подытожить - прирост производительности в ецс ты бы увидел только на 10000+ однотипных объектах делающих однотипное действие. Типа солдатики в стратегии маршируют одинаково. Если ты тот анон который говорил про 16 или 32 игровых персонажа в кадре - ты никакого прироста от ецс (который у тебя и не ецс, на самом деле, а вариант оопа в котором ты возможно даже мешаешь компилятору оптимизировать) - просто никак получить не сможешь.
Ецс - это архитектурный паттерн.
Исходный тезис был в том, что он плохо ложится на производительность и есть много издержек лишних.
Мой ответ в том, что нет, ецс можно совершенно разными способами внутри реализовать, в том числе точно такими же как ты сделал бы это без ецс, и как таковых заведомых проблем с производительностью ецс архитектура не несёт.
Говоря о практике, есть ецс фреймворки с которыми можно сравнительно легко достичь очень большой производительности, засчет распараллеливания итераций по большому числу ентитей, распараллеливанию систем(несколько неблокирующих будут работать одновременно). Каких-то других общих практик достичь такого - нету. Только долгое изобретение своего кастомного варианта под кокнретную игру, с поиском всех вариантов как это соптимищировать.
Помимо этого я выше заявлял:
1. Использование ецс в готовом движке не несёт лишнего заведомого оверхеда, у тебя полныц контроль с точки зрения программирования что ты делаешь
2. Связь любых двух систем делается схожими методами, как ецс можео подружить со сторонним физическим движком, так и любую игру можео подружить со сторонним физическим движком
3. Ецс не обязательно предполагает какие-то обязательные расчёты каждый кадр, есть реализации ецс с 0 оверхедом в кадре
4. Нет никакого лишнего оверхеда для куллинга и повторного выполненич той же работы
На это как таковых ответов не вижу, можешь линкануть или написать, если не согласен.
>>19330
> ECS итерирует не по энтити, а по компонентам, вот где твое заблуждение.
Что это предложение значит?
Концепция ецс предполагает в клиентском коде возможность итераций по заданному набору компонентов. У меня это реализовано.
> Производительность у тебя теряется в нескольких местах:
> 1. Если бы ты итерировал по компонентам, то в кэш влезало бы в 4 раза больше игровых объектов. А так у тебя через кэш каждый раз протискивается весь объект.
Действительно, есть такое. А ты уверен, что это даст больший проигрыш, чем нарушение предикта процессором засчет бранчинга и большего набора инструкций и разнородности ввполнчемых операций?
Я - нет.
Ещё и есть непонятки с многопотоком, потому что отделение операций на простве и взаимонеблокирующие позволчет многое параллелить, в отличии от твоего нагромождения логики в одном месте, что в любом случае будет блокировать выполнение логики в другом местк пока этот объект не обработается.
> 2. Если ты будешь испольовать ецс как настоящий ецс, а не как эрзац-пародию, то ты будешь добавлять-удалять компоненты энтитям динамически, (ну например хотим сделать юнит неуязвимым- удаляем компонент health) а значит тебе придется перетасовывать массивы, ведь объект придется удалить из массива номер 3 и перенести в массив номер 4.
И в ооооочередной раз прошу тебя рассказать, как бы ты решал схожую проблему без ецс.
(С ецс те же самые практики применимы, а также и некоторые другие)
> тебе надо было просто сразу сказать что у тебя говнюнити, мы бы на тебя просто время не тратили, потому что все знают что там не ецс, а пародия.
Поебать что за движок, выше я также уже много раз говорил, что у тебя есть ЯП чтобы реализовать что угодно в чем угодно.
А что по юнити - там как раз самый трушный ецс какой можно себе представить(следуя твоему же определению, я же до сих пор твержу, что ецс это архитектурный паттерн а не твои маня фантазии о внутреннем устройстве) с наверное самым большим перформансом на рынке.
>>19328
Это типа ты ответил? Как композиция решает проблему добавления или удаления игровой сущеости?
> >Ты на отрез отказываешься говорить как бы сделал это без ецс, хотя я тебя в каждом посте прошу это сделать.
> Лично меня ты не спрашивал, с тобой тут не один анон спорит. В ооп для этого есть композиция.
Это типа ты ответил? Как композиция решает проблему добавления или удаления игровой сущеости?
>>19359
Чел, это не ецс, и тем более не трушный ецс и тем более не самый производительный - самый есть только на с++ и расте, куча либ.
Еще раз повторяю, у самой по себе архитектуры ецс прироста перформанса нет, хз откуда ты это выдумал. Она может быть только у реализации, а у тебя реализация медленнее и тру ецс, и ооп с оптимизацией через SoA. (Но правда в том что на реальных данных ецс и сам превратится в тыкву) Возьми напиши бенчи и померяй, а так ты просто маркетологовые мантры повторяешь.
ООП с SoA.
У тебя ровно такое же нагромождение, так как у тебя не ецс, а массив объектов.
Нет, в ецс ты так сделать не можешь, там будет только два последовательных цикла по несвязанным (с точки зрения компилятора) между собой компонентам.
Чел, это не ецс, и тем более не трушный ецс и тем более не самый производительный - самый есть только на с++ и расте, куча либ.
Еще раз повторяю, у самой по себе архитектуры ецс прироста перформанса нет, хз откуда ты это выдумал. Она может быть только у реализации, а у тебя реализация медленнее и тру ецс, и ооп с оптимизацией через SoA. (Но правда в том что на реальных данных ецс и сам превратится в тыкву) Возьми напиши бенчи и померяй, а так ты просто маркетологовые мантры повторяешь.
> Каких-то других общих практик достичь такого - нету.
ООП с SoA.
>Ещё и есть непонятки с многопотоком, потому что отделение операций на простве и взаимонеблокирующие позволчет многое параллелить, в отличии от твоего нагромождения логики в одном месте, что в любом случае будет блокировать выполнение логики в другом местк пока этот объект не обработается.
У тебя ровно такое же нагромождение, так как у тебя не ецс, а массив объектов.
>последовательно идут вызовы monster.ApplyGravity(), monster.Move() то так можно вывести, но ты также можешь сделать в ецс.
Нет, в ецс ты так сделать не можешь, там будет только два последовательных цикла по несвязанным (с точки зрения компилятора) между собой компонентам.
>>19364
Определение ецс я тебе скидывал. Противоречий ему ты не привёл.
Что такое трушный ецс я вообще не знаю.
А мы о чем говорим? О моем псевдокоде которым я имитировал твой "ооп" и подсвеичаал идентичность проблем и внутреннего устройства, или о юнити ецс?
Если о втором - а ты сравнивал производительность юнити ецс с беви или еще какими-то реализациями?
А я говорил это где то? Процитируй плиз.
Я говорил что у ецс нету заложенных ее дизайне решений которые убивают производительность.
А также в свою очередь есть варианты реализации ецс с которыми можно достичь очень большой производительности, по сравнению со многими другими подходами.
Не знаю, с чего ты взял это. Я из раза в раз твержу что это архитектура, а не внутренняя реализация.
Какая именно? Моя ебала с тремя массивами? Как ты понял что медленнее?
Так выше ты сам уже говорил, что можно компоненты хранить в массивах.
Крч, твой "ооп" это вырожденный "ецс", где 1 компонент = 1 тип объекта, с абсолютно идентичной внутренней реализаций, 1 в 1.
Давай ещё раз просто зафиксируем, чтобы это точно бвл не не твой ответ и мы понимали кто о чем говорит:
1. Напиши как у тебя хранятся игровые сущности. Массив структур? Структура массивов?
2. Как происходит удаление и создание сущности
Вот у нас есть например пуля летающая и враги бегающие. Напиши пример для них.
А я тебе напишу апи которое будет соответстчовать определению ецс и работать с твоей реализацией)
Я хз как тебе еще сказать, что внутри там может быть ровно тоже самое что и у тебя.
Вот абсолютно любую структуру данных напиши, я тебе заебашу апи и скажу какой кодогенератор надо сделать чтобы оно выглядело в соответствии с определением ецс.
Давай сделаю тебе ецс где внутри будет СоА)
Напиши пример с пульками и врагами. Давай.
Подожди подожди, как это так?
Я могу сделать систему, которая для каждого "ентити" делает позишен += гравити и это распараллелится.
Могу пойти дальше, и сделать систему, которая будет отнимать хп от горения юнитов или отравления. И она будет работать параллельно с предыдущей системой, потому что они не блокируют друг друга.
А дальше будет система проверки коллизий - вот она уже дождется когда все позишены подвинутся от гравитации и отработает.
У тебя как это реализовано бы было?
Если у тебя все в одном методе или потенциальео оптимизируемо в 1 метод, то и не будет у тебя никакого многопотока.
Пример очевидео примитивный, на пратике у нас параллельно каждый юнит может считать пути и принимать решения, и это все будет параллельно работать с полетом пуль и параллельно например с системой горения травы какой нибудь. Или с десчток мелких систем паралелльно крутиться будут каждая в своем потоке.
Если что-то оптимизируемо в 1 метод автоматически, то это можно вручную оптимизировать также в 1 метод в системе, вот про что я.
> Чел, это не ецс, и тем более не трушный ецс
Определение ецс я тебе скидывал. Противоречий ему ты не привёл.
Что такое трушный ецс я вообще не знаю.
>тем более не самый производительный - самый есть только на с++ и расте, куча либ.
А мы о чем говорим? О моем псевдокоде которым я имитировал твой "ооп" и подсвеичаал идентичность проблем и внутреннего устройства, или о юнити ецс?
Если о втором - а ты сравнивал производительность юнити ецс с беви или еще какими-то реализациями?
> Еще раз повторяю, у самой по себе архитектуры ецс прироста перформанса нет
А я говорил это где то? Процитируй плиз.
Я говорил что у ецс нету заложенных ее дизайне решений которые убивают производительность.
А также в свою очередь есть варианты реализации ецс с которыми можно достичь очень большой производительности, по сравнению со многими другими подходами.
> хз откуда ты это выдумал
Не знаю, с чего ты взял это. Я из раза в раз твержу что это архитектура, а не внутренняя реализация.
> Она может быть только у реализации, а у тебя реализация медленнее и тру ецс
Какая именно? Моя ебала с тремя массивами? Как ты понял что медленнее?
> и ооп с оптимизацией через SoA
Так выше ты сам уже говорил, что можно компоненты хранить в массивах.
Крч, твой "ооп" это вырожденный "ецс", где 1 компонент = 1 тип объекта, с абсолютно идентичной внутренней реализаций, 1 в 1.
Давай ещё раз просто зафиксируем, чтобы это точно бвл не не твой ответ и мы понимали кто о чем говорит:
1. Напиши как у тебя хранятся игровые сущности. Массив структур? Структура массивов?
2. Как происходит удаление и создание сущности
Вот у нас есть например пуля летающая и враги бегающие. Напиши пример для них.
А я тебе напишу апи которое будет соответстчовать определению ецс и работать с твоей реализацией)
>. (Но правда в том что на реальных данных ецс и сам превратится в тыкву) Возьми напиши бенчи и померяй, а так ты просто маркетологовые мантры повторяешь.
Я хз как тебе еще сказать, что внутри там может быть ровно тоже самое что и у тебя.
Вот абсолютно любую структуру данных напиши, я тебе заебашу апи и скажу какой кодогенератор надо сделать чтобы оно выглядело в соответствии с определением ецс.
> ООП с SoA.
Давай сделаю тебе ецс где внутри будет СоА)
Напиши пример с пульками и врагами. Давай.
> У тебя ровно такое же нагромождение, так как у тебя не ецс, а массив объектов.
Подожди подожди, как это так?
Я могу сделать систему, которая для каждого "ентити" делает позишен += гравити и это распараллелится.
Могу пойти дальше, и сделать систему, которая будет отнимать хп от горения юнитов или отравления. И она будет работать параллельно с предыдущей системой, потому что они не блокируют друг друга.
А дальше будет система проверки коллизий - вот она уже дождется когда все позишены подвинутся от гравитации и отработает.
У тебя как это реализовано бы было?
Если у тебя все в одном методе или потенциальео оптимизируемо в 1 метод, то и не будет у тебя никакого многопотока.
Пример очевидео примитивный, на пратике у нас параллельно каждый юнит может считать пути и принимать решения, и это все будет параллельно работать с полетом пуль и параллельно например с системой горения травы какой нибудь. Или с десчток мелких систем паралелльно крутиться будут каждая в своем потоке.
> Нет, в ецс ты так сделать не можешь, там будет только два последовательных цикла по несвязанным (с точки зрения компилятора) между собой компонентам.
Если что-то оптимизируемо в 1 метод автоматически, то это можно вручную оптимизировать также в 1 метод в системе, вот про что я.
>>19364
Определение ецс я тебе скидывал. Противоречий ему ты не привёл.
Что такое трушный ецс я вообще не знаю.
А мы о чем говорим? О моем псевдокоде которым я имитировал твой "ооп" и подсвеичаал идентичность проблем и внутреннего устройства, или о юнити ецс?
Если о втором - а ты сравнивал производительность юнити ецс с беви или еще какими-то реализациями?
А я говорил это где то? Процитируй плиз.
Я говорил что у ецс нету заложенных ее дизайне решений которые убивают производительность.
А также в свою очередь есть варианты реализации ецс с которыми можно достичь очень большой производительности, по сравнению со многими другими подходами.
Не знаю, с чего ты взял это. Я из раза в раз твержу что это архитектура, а не внутренняя реализация.
Какая именно? Моя ебала с тремя массивами? Как ты понял что медленнее?
Так выше ты сам уже говорил, что можно компоненты хранить в массивах.
Крч, твой "ооп" это вырожденный "ецс", где 1 компонент = 1 тип объекта, с абсолютно идентичной внутренней реализаций, 1 в 1.
Давай ещё раз просто зафиксируем, чтобы это точно бвл не не твой ответ и мы понимали кто о чем говорит:
1. Напиши как у тебя хранятся игровые сущности. Массив структур? Структура массивов?
2. Как происходит удаление и создание сущности
Вот у нас есть например пуля летающая и враги бегающие. Напиши пример для них.
А я тебе напишу апи которое будет соответстчовать определению ецс и работать с твоей реализацией)
Я хз как тебе еще сказать, что внутри там может быть ровно тоже самое что и у тебя.
Вот абсолютно любую структуру данных напиши, я тебе заебашу апи и скажу какой кодогенератор надо сделать чтобы оно выглядело в соответствии с определением ецс.
Давай сделаю тебе ецс где внутри будет СоА)
Напиши пример с пульками и врагами. Давай.
Подожди подожди, как это так?
Я могу сделать систему, которая для каждого "ентити" делает позишен += гравити и это распараллелится.
Могу пойти дальше, и сделать систему, которая будет отнимать хп от горения юнитов или отравления. И она будет работать параллельно с предыдущей системой, потому что они не блокируют друг друга.
А дальше будет система проверки коллизий - вот она уже дождется когда все позишены подвинутся от гравитации и отработает.
У тебя как это реализовано бы было?
Если у тебя все в одном методе или потенциальео оптимизируемо в 1 метод, то и не будет у тебя никакого многопотока.
Пример очевидео примитивный, на пратике у нас параллельно каждый юнит может считать пути и принимать решения, и это все будет параллельно работать с полетом пуль и параллельно например с системой горения травы какой нибудь. Или с десчток мелких систем паралелльно крутиться будут каждая в своем потоке.
Если что-то оптимизируемо в 1 метод автоматически, то это можно вручную оптимизировать также в 1 метод в системе, вот про что я.
> Чел, это не ецс, и тем более не трушный ецс
Определение ецс я тебе скидывал. Противоречий ему ты не привёл.
Что такое трушный ецс я вообще не знаю.
>тем более не самый производительный - самый есть только на с++ и расте, куча либ.
А мы о чем говорим? О моем псевдокоде которым я имитировал твой "ооп" и подсвеичаал идентичность проблем и внутреннего устройства, или о юнити ецс?
Если о втором - а ты сравнивал производительность юнити ецс с беви или еще какими-то реализациями?
> Еще раз повторяю, у самой по себе архитектуры ецс прироста перформанса нет
А я говорил это где то? Процитируй плиз.
Я говорил что у ецс нету заложенных ее дизайне решений которые убивают производительность.
А также в свою очередь есть варианты реализации ецс с которыми можно достичь очень большой производительности, по сравнению со многими другими подходами.
> хз откуда ты это выдумал
Не знаю, с чего ты взял это. Я из раза в раз твержу что это архитектура, а не внутренняя реализация.
> Она может быть только у реализации, а у тебя реализация медленнее и тру ецс
Какая именно? Моя ебала с тремя массивами? Как ты понял что медленнее?
> и ооп с оптимизацией через SoA
Так выше ты сам уже говорил, что можно компоненты хранить в массивах.
Крч, твой "ооп" это вырожденный "ецс", где 1 компонент = 1 тип объекта, с абсолютно идентичной внутренней реализаций, 1 в 1.
Давай ещё раз просто зафиксируем, чтобы это точно бвл не не твой ответ и мы понимали кто о чем говорит:
1. Напиши как у тебя хранятся игровые сущности. Массив структур? Структура массивов?
2. Как происходит удаление и создание сущности
Вот у нас есть например пуля летающая и враги бегающие. Напиши пример для них.
А я тебе напишу апи которое будет соответстчовать определению ецс и работать с твоей реализацией)
>. (Но правда в том что на реальных данных ецс и сам превратится в тыкву) Возьми напиши бенчи и померяй, а так ты просто маркетологовые мантры повторяешь.
Я хз как тебе еще сказать, что внутри там может быть ровно тоже самое что и у тебя.
Вот абсолютно любую структуру данных напиши, я тебе заебашу апи и скажу какой кодогенератор надо сделать чтобы оно выглядело в соответствии с определением ецс.
> ООП с SoA.
Давай сделаю тебе ецс где внутри будет СоА)
Напиши пример с пульками и врагами. Давай.
> У тебя ровно такое же нагромождение, так как у тебя не ецс, а массив объектов.
Подожди подожди, как это так?
Я могу сделать систему, которая для каждого "ентити" делает позишен += гравити и это распараллелится.
Могу пойти дальше, и сделать систему, которая будет отнимать хп от горения юнитов или отравления. И она будет работать параллельно с предыдущей системой, потому что они не блокируют друг друга.
А дальше будет система проверки коллизий - вот она уже дождется когда все позишены подвинутся от гравитации и отработает.
У тебя как это реализовано бы было?
Если у тебя все в одном методе или потенциальео оптимизируемо в 1 метод, то и не будет у тебя никакого многопотока.
Пример очевидео примитивный, на пратике у нас параллельно каждый юнит может считать пути и принимать решения, и это все будет параллельно работать с полетом пуль и параллельно например с системой горения травы какой нибудь. Или с десчток мелких систем паралелльно крутиться будут каждая в своем потоке.
> Нет, в ецс ты так сделать не можешь, там будет только два последовательных цикла по несвязанным (с точки зрения компилятора) между собой компонентам.
Если что-то оптимизируемо в 1 метод автоматически, то это можно вручную оптимизировать также в 1 метод в системе, вот про что я.
>>19365
Не точно, вроде уже сеньор.
По моему композиция это термин из ООП обозначающий вид отношения между двумя сущностями. Операции удаления и вставки с технической точки зрения оно не задаёт.
А нам тут нужна структура данных с операциями вставки и удаления.
Не точно, вроде уже сеньор.
По моему композиция это термин из ООП обозначающий вид отношения между двумя сущностями. Операции удаления и вставки с технической точки зрения оно не задаёт.
А нам тут нужна структура данных с операциями вставки и удаления.
4,8 Мб, mp4,512x512, 0:19
>>18606 (Del)
Дык это нищета полная сейчас, поэтому он их и получает. Это те же 60к 3 года назад, инфляция всё съела.
Вы ещё в копейках считайте тогда, если вам главное чтобы цифра побольше была. Какие же вы нахуй гои ЛОЛ.
>Сейчас курьер 120+ получает
Дык это нищета полная сейчас, поэтому он их и получает. Это те же 60к 3 года назад, инфляция всё съела.
Вы ещё в копейках считайте тогда, если вам главное чтобы цифра побольше была. Какие же вы нахуй гои ЛОЛ.
>>19443
по всем мировым методикам экономика России в 2025 году на четвёртом месте по ППС, тут не отвертишься
по всем мировым методикам экономика России в 2025 году на четвёртом месте по ППС, тут не отвертишься
>>19444
Годотя помолчи пж
Годотя помолчи пж
>>19444
Это абсолютное значение, а надо смотреть на душу населения.
ППС тоже не такой просто показатель, он показывает цену на какую-то продуктовую корзину и некоторый набор товаров. Но какие конкретно товары(булка из подвала или свежевыпченная из муки высшего сорта?) и насколько это реальные цены - это вопрос.
Еда и товары первой необходимости это в любом слусае не первая статья расходов, на технику больше потратишь, а она по ППС не считается.
>>19440
Это тоже очень тупое заявление. Может, ты просто неправильно выразился. У валюты нет покупательной способности, это не её характеристика.
> по всем мировым методикам экономика России в 2025 году на четвёртом месте по ППС, тут не отвертишься
Это абсолютное значение, а надо смотреть на душу населения.
ППС тоже не такой просто показатель, он показывает цену на какую-то продуктовую корзину и некоторый набор товаров. Но какие конкретно товары(булка из подвала или свежевыпченная из муки высшего сорта?) и насколько это реальные цены - это вопрос.
Еда и товары первой необходимости это в любом слусае не первая статья расходов, на технику больше потратишь, а она по ППС не считается.
>>19440
> так дело не в цифрах, а в покупательной способности
> у рубля она одна из лучших в мире
Это тоже очень тупое заявление. Может, ты просто неправильно выразился. У валюты нет покупательной способности, это не её характеристика.
>>19456
И не только это, но еще и расслоение дозодов по регионам и социальным группам может сильно сбивать с толку.
Зарплата средяя наверное 100к все будет, а медиана то всего 50к.
> Это абсолютное значение, а надо смотреть на душу населения.
И не только это, но еще и расслоение дозодов по регионам и социальным группам может сильно сбивать с толку.
Зарплата средяя наверное 100к все будет, а медиана то всего 50к.
>>19466
Тебе ссылочку на росстат прислать?
Сравнивать абсолютный размер экономики это очевидный идиотизм, в индии экономика еще больше чем в расиюшке, только там в 10 раз больше человек живут. Поехал бы в индию?
Тебе ссылочку на росстат прислать?
Сравнивать абсолютный размер экономики это очевидный идиотизм, в индии экономика еще больше чем в расиюшке, только там в 10 раз больше человек живут. Поехал бы в индию?
почему в юнити убрали поддержку жабаскрипта? В сравнении с сишарпом код получается красивше и понятнее.
мимо пишу на unity 2
мимо пишу на unity 2
10-15 млн треугольников на кадр - уже может начаться нагрузка на геометрию наравне с пиксельным пайплайном. всё что ниже - это, считай, бесплатно. дроуколлы куда страшнее
>>19544
Жаваскрипт динамически типизированный и намного менее развитый в плане удобства работы с ООП, поэтому реальную игру на нем крайне тяжело писать будет.
Ну и производительность тоже у него сомнительная.
Жаваскрипт динамически типизированный и намного менее развитый в плане удобства работы с ООП, поэтому реальную игру на нем крайне тяжело писать будет.
Ну и производительность тоже у него сомнительная.
Покажите такой же бесплатный ассент на хрюдоте
https://assetstore.unity.com/packages/vfx/tentacles-vfx-urp-303497
https://assetstore.unity.com/packages/vfx/tentacles-vfx-urp-303497
>>19573
Это школьный курс геометрии, любой GODотер напишет генератор подобной хуйни за пару часов.
Это школьный курс геометрии, любой GODотер напишет генератор подобной хуйни за пару часов.
>>19578
NDA
NDA
>>19601
-Раздался голос юнитичма из под шконки, но годотобоги и анрилобоги его не расслышали и продолжили обоссывать.
-Раздался голос юнитичма из под шконки, но годотобоги и анрилобоги его не расслышали и продолжили обоссывать.
1,2 Мб, webm,600x466, 0:07
>>19603
вы наблюдаете как конченый омеган пытается примазаться к ребятам покруче
>годотобоги и анрилобоги
вы наблюдаете как конченый омеган пытается примазаться к ребятам покруче
121 Кб, 600x788>>19603
Увы, так называемые "гуньдотбоги", находятся в самом низу движковой цепочки. Соответственно - они "боги" только в рамках так назваемого своего свинарника.
Даже хрюни выше находятся.
>годотобоги
Увы, так называемые "гуньдотбоги", находятся в самом низу движковой цепочки. Соответственно - они "боги" только в рамках так назваемого своего свинарника.
Даже хрюни выше находятся.
>>19650
Он должен быть платным
Он должен быть платным
Что можете посоветовать попробовать из движков без граф. редактора? До этого любил поиграться с Bevy но это меня заебало конкретно - каждые четыре месяца выходит новая говно версия которая ломает нахуй все, ужасный просто блять уродский API и пидорское сообщество (не удивительно - Раст же).
>>19608
Так анрил и годот - братушки, эпики подкидывают денюжку, программисты контрибьютят в исходники.
Так анрил и годот - братушки, эпики подкидывают денюжку, программисты контрибьютят в исходники.
>>19657
Годот. Там есть режим где просто пишешь код, рисуешь все что хочешь кодом, без всяких сцен и нод.
Годот. Там есть режим где просто пишешь код, рисуешь все что хочешь кодом, без всяких сцен и нод.
26 Кб, 285x225>>19597
в чем скам-то?
в чем скам-то?
>>19658
Братушки только потому, что свинья сначала спиздила люмен из другого движка, попутно поглядывая на годотный SDFGI. Чёт там мутное было такое.
Так что не всё так хорошо для годотей как им хотелось бы.
Братушки только потому, что свинья сначала спиздила люмен из другого движка, попутно поглядывая на годотный SDFGI. Чёт там мутное было такое.
Так что не всё так хорошо для годотей как им хотелось бы.
>>19657
Ezengine, там редактор есть, но опциональный, можно использовать code first подход
Ezengine, там редактор есть, но опциональный, можно использовать code first подход
104 Кб, 231x330Есть идея игры, не вдаваясь в подробности мне требуется движок который сможет осилить огромное количество векторной математики в один кадр - с этим справится любой движок или есть рекомендации взять конкретный?
>>19687
Либо Israel Engine, либо свой. Либо какой-то из тех где есть C++ и можно переделать под себя по исходникам.
Либо Israel Engine, либо свой. Либо какой-то из тех где есть C++ и можно переделать под себя по исходникам.
>>19692
для начала покажи все свои проекты, аккаунты, игры и т.д, перед тем как свою вафельницу открывать
>Либо какой-то из тех где есть C++
для начала покажи все свои проекты, аккаунты, игры и т.д, перед тем как свою вафельницу открывать
>>19687
Любой кроме годота.
На юнити есть дотс для такого, на анриле можешь модуль на плюсах написать, на беви даже можно сделать с его параллельным ексом.
Только годот не вывезет, там на каждые два драв колла по пропуку
Любой кроме годота.
На юнити есть дотс для такого, на анриле можешь модуль на плюсах написать, на беви даже можно сделать с его параллельным ексом.
Только годот не вывезет, там на каждые два драв колла по пропуку
>>19687
Любой, где есть векторизация и многопоточность. Любой движок с с++ или юнити с джоб систем и берст.
Любой, где есть векторизация и многопоточность. Любой движок с с++ или юнити с джоб систем и берст.
>>19687
так тебе наверное GPGPU нужон, а не движок (вернее движок пойдет любой, лишь бы был доступ к GPGPU)
>мне требуется движок который сможет осилить огромное количество векторной математики в один кадр
так тебе наверное GPGPU нужон, а не движок (вернее движок пойдет любой, лишь бы был доступ к GPGPU)
>>19723
Нет там никаких проблем.
Нет там никаких проблем.
>>19710
Пиздаболище. В годоте есть компьют шейдеры, и есть MultiMesh Instance.
Пиздаболище. В годоте есть компьют шейдеры, и есть MultiMesh Instance.
>>19820
Зачем тебе опенворлд, клоун? У тебя 300 артистов сидит на зарплате? Ты не потянешь.
Удел инди делать маленькие камерные игры.
Зачем тебе опенворлд, клоун? У тебя 300 артистов сидит на зарплате? Ты не потянешь.
Удел инди делать маленькие камерные игры.
Опять решил написать мини движок для веба. Чтоб легко вставлять интерфейс и генерить миры.
Это самый обычный бесплатный ассет на юнити, покажите теперь на хрюдоте
https://github.com/VahidSN/CrowdEvade
https://github.com/VahidSN/CrowdEvade
Пизда вашим треугольникам, 3Д пиксели уже здесь:
Photorealistic ray-traced micro-voxel fps engine https://github.com/milgra/qubatron
Photorealistic ray-traced micro-voxel fps engine https://github.com/milgra/qubatron
>>19944
Такой то перефорс от хрюнити свиньи.
Такой то перефорс от хрюнити свиньи.
1,1 Мб, 1806x627>>20117
Ну такое себе.
Ну такое себе.
>>20116
Какие воксели в 21 веке, чел, все состоит из волн, тут подкрадывается гауссиан сплаттинг+ ИИ
https://www.youtube.com/watch?v=hUVfAVjsfL4
Какие воксели в 21 веке, чел, все состоит из волн, тут подкрадывается гауссиан сплаттинг+ ИИ
https://www.youtube.com/watch?v=hUVfAVjsfL4
>>20149
Текстовые модели типа чат гпт
Генерация изображений текст ту имедж
Текст ту спич
Нейрофильтры для изображений и видео(апскейл, цветокоррекция, следование до точкой)
Апскейл DLSS/FSR
Текстовые модели типа чат гпт
Генерация изображений текст ту имедж
Текст ту спич
Нейрофильтры для изображений и видео(апскейл, цветокоррекция, следование до точкой)
Апскейл DLSS/FSR
17 Кб, 734x144оправдывайтесь
пропуки добили чела
https://www.reddit.com/r/godot/comments/1kdp57g/my_first_steam_release_after_55_years_of_gamedev/
пропуки добили чела
https://www.reddit.com/r/godot/comments/1kdp57g/my_first_steam_release_after_55_years_of_gamedev/
>>20155
ок, это годнота. в немалой степени из-за шиттификации поисковиков - раньше просто гораздо больше полезной информации извлекалось через поиск
давай по чесноку. это всё еще генерирует хуйню. до сих пор
вообще не знаю о чем речь
ок, но литералли технологии 20 летней давности (madVR).
>Текстовые модели типа чат гпт
ок, это годнота. в немалой степени из-за шиттификации поисковиков - раньше просто гораздо больше полезной информации извлекалось через поиск
>Генерация изображений текст ту имедж
>Текст ту спич
давай по чесноку. это всё еще генерирует хуйню. до сих пор
> Нейрофильтры для изображений и видео(апскейл, цветокоррекция, следование за точкой)
вообще не знаю о чем речь
>Апскейл DLSS/FSR
ок, но литералли технологии 20 летней давности (madVR).
>>20156 щас прибежит годотя и будет доказывать с апломбом пукнет, что это мол skill issue а если писать на C++ и переписать render server, то всё будет летать
>>20149
Апскейлер аниме для видеоплееров.
Апскейлер аниме для видеоплееров.
>>20160
Очевидно шкилл ишью, раз чел взял 4-ку вместо тройки, не знает как пропукивать шейдеры, не удивлюсь если у него там трава без оптимизаций по одной травинке рисуется. Еще о многом говорит что он заявляет 5 летний опыт, при этом его "фиксы" после релиза - судорожно переключать один рендер на другой? Потестить заранее не? Потренироваться на каком нибудь джеме релизить игру не? В конце концов, ну не разбираешься - пойди в W4 за платной консультацией, где то же на сайте годота написано что такая опция всегда есть.
Очевидно шкилл ишью, раз чел взял 4-ку вместо тройки, не знает как пропукивать шейдеры, не удивлюсь если у него там трава без оптимизаций по одной травинке рисуется. Еще о многом говорит что он заявляет 5 летний опыт, при этом его "фиксы" после релиза - судорожно переключать один рендер на другой? Потестить заранее не? Потренироваться на каком нибудь джеме релизить игру не? В конце концов, ну не разбираешься - пойди в W4 за платной консультацией, где то же на сайте годота написано что такая опция всегда есть.
>>20159
Ну смотря для каких целей.
Текст ту имедж норм чтобы каких то рефов нагенерить, даже не полноценных концептов, а просто ориентиров для этапа препродакшена чтобы у всех видение более. До ии это были просто скринв из других игр, теперь к ним добавились(не заместили, что важно) картинки из ии.
Еще норм для коммунити менеджеров всяких и генерации изображений с малой ценностью. Вот у нас например юзают для для объявлений в компании, просто чтобы чуть более живо выглядело чем просто текст. Вот для таких мелочей, где хорошо бы картинку вставить, но не искать кринж в гугле.
Это надо у видемонтажеров поспрашивать и тех кто изображения обрабатывает. Точно знаю что есть то что я перечислил, но там вроде много всяких нейроинструментов облегчающих жизнь. Удаление фона вот ещё.
Расскажешь подробнее? Судя по гуглу это это что-то связанное с декодированием и рантайм обработкой видео.
Не уврен, что оно позволяет получить такой же по качеству эффект как длсс/фср и применимо в реалтайм играх. Апскейл до ии в целом очень слабый был даже для изображений, я гуглил варианты еще незадолго до ии бума.
> давай по чесноку. это всё еще генерирует хуйню. до сих пор
Ну смотря для каких целей.
Текст ту имедж норм чтобы каких то рефов нагенерить, даже не полноценных концептов, а просто ориентиров для этапа препродакшена чтобы у всех видение более. До ии это были просто скринв из других игр, теперь к ним добавились(не заместили, что важно) картинки из ии.
Еще норм для коммунити менеджеров всяких и генерации изображений с малой ценностью. Вот у нас например юзают для для объявлений в компании, просто чтобы чуть более живо выглядело чем просто текст. Вот для таких мелочей, где хорошо бы картинку вставить, но не искать кринж в гугле.
> вообще не знаю о чем речь
Это надо у видемонтажеров поспрашивать и тех кто изображения обрабатывает. Точно знаю что есть то что я перечислил, но там вроде много всяких нейроинструментов облегчающих жизнь. Удаление фона вот ещё.
> ок, но литералли технологии 20 летней давности (madVR).
Расскажешь подробнее? Судя по гуглу это это что-то связанное с декодированием и рантайм обработкой видео.
Не уврен, что оно позволяет получить такой же по качеству эффект как длсс/фср и применимо в реалтайм играх. Апскейл до ии в целом очень слабый был даже для изображений, я гуглил варианты еще незадолго до ии бума.
>>20169
по поводу концептов и картинок в блоги согласен. я скорее говорил об ассетах и собственно энд-юзер контенте
20 лет назад один гик обучил апскейлер для видеоплееров, который благодаря видяхе работал в полу-реалтайме на видео (всё равно нужна буфферизация и заглядывание в будущие кадры). картинка была чуть лучше чем при апскейле обычными интерполяторами типа бикубика и ланцоша, четче контуры в аниме, детальней лица. в принципе то же самое что делает длсс сегодня в играх
по поводу концептов и картинок в блоги согласен. я скорее говорил об ассетах и собственно энд-юзер контенте
>Расскажешь подробнее?
20 лет назад один гик обучил апскейлер для видеоплееров, который благодаря видяхе работал в полу-реалтайме на видео (всё равно нужна буфферизация и заглядывание в будущие кадры). картинка была чуть лучше чем при апскейле обычными интерполяторами типа бикубика и ланцоша, четче контуры в аниме, детальней лица. в принципе то же самое что делает длсс сегодня в играх
>>20156
он шиз, у него охуенно мало рефандов (норма 15-20%). краши и тормоза люди указывают просто потому что думают, что нужно указать серьезную причину, а то вдруг габен зажмет деньги и не рефанднет, если они честно скажут, что им жалко денег за такой геймплей
он шиз, у него охуенно мало рефандов (норма 15-20%). краши и тормоза люди указывают просто потому что думают, что нужно указать серьезную причину, а то вдруг габен зажмет деньги и не рефанднет, если они честно скажут, что им жалко денег за такой геймплей
>>20261
он уже как минимум 1000$ нафармил и продолжает фармить, а ты сидишь тут и терпишь
он уже как минимум 1000$ нафармил и продолжает фармить, а ты сидишь тут и терпишь
>>20274
какие деньжищи
какие деньжищи
>>20156
Я тоже хотел запостить потролить говнотей, но потом прочёл что у него 11% рефандов и чёт пукнул с него. Для индихуйни это пиздатый показатель.
Я тоже хотел запостить потролить говнотей, но потом прочёл что у него 11% рефандов и чёт пукнул с него. Для индихуйни это пиздатый показатель.
47 Кб, 996x241>>20156
Ну чтож, подождем...
Ну чтож, подождем...
58 Кб, 1086x315>>20156
Получается, неплохая реклама Годоту.
Чел сделал неплохую 3д игру за 3 месяца. При этом параллельно разрабатывая еще одну более крупную.
Малаца, приноси еще таких успешных историй.
(На пропуки игрокам похер, непохер только шизикам в движкосрач треде)
Получается, неплохая реклама Годоту.
Чел сделал неплохую 3д игру за 3 месяца. При этом параллельно разрабатывая еще одну более крупную.
Малаца, приноси еще таких успешных историй.
(На пропуки игрокам похер, непохер только шизикам в движкосрач треде)
>>20156
Сто раз говорили, если планируете выпускать игру в стим - берите юнити/анрил, точка. Не за их фичи, не за крутой рендер - это все вторично. В первую очередь за мощную базу совместимости, гарантию того, что на любом железе ваша игра будет работать плюс минус одинаково ожидаемо. Они эту базу совместимости копили десятилетия, вплоть до наличия в коде фиксов под конкретные версии дров конкретных видюх.
В гадотя энжине этого нет и не будет. Не удивляйтесь, если у рандомной части игроков будут инвертированные цвета или тупо краши.
В вашем самописном бздотя энжине ситуация будет еще в разы хуже, чем в годоте, просто будет 80% рефандов из-за крашей, а не 10.
Определитесь сразу, вы хотите пукать или делать игры и издавать их. Если хотите пукать - Пожалуйста, годотя, бевя, викед, хуикед, все к вашим услугам, можете хоть с нуля писать на сдл, подрачивая при этом вприсядку.
Но если хотите выпускать игры - только Юнити и анрил.
Сто раз говорили, если планируете выпускать игру в стим - берите юнити/анрил, точка. Не за их фичи, не за крутой рендер - это все вторично. В первую очередь за мощную базу совместимости, гарантию того, что на любом железе ваша игра будет работать плюс минус одинаково ожидаемо. Они эту базу совместимости копили десятилетия, вплоть до наличия в коде фиксов под конкретные версии дров конкретных видюх.
В гадотя энжине этого нет и не будет. Не удивляйтесь, если у рандомной части игроков будут инвертированные цвета или тупо краши.
В вашем самописном бздотя энжине ситуация будет еще в разы хуже, чем в годоте, просто будет 80% рефандов из-за крашей, а не 10.
Определитесь сразу, вы хотите пукать или делать игры и издавать их. Если хотите пукать - Пожалуйста, годотя, бевя, викед, хуикед, все к вашим услугам, можете хоть с нуля писать на сдл, подрачивая при этом вприсядку.
Но если хотите выпускать игры - только Юнити и анрил.
>>20156
Забавно, что в тред пришел разраб halls of torment и сказал, что у него на говноти траблы на rtx видюхах.
Просто загуглите скрины игры, чтобы понимать абсурд ситуации (там графин хуже чем в первом Диабло)
Не это ли вершина идиократии, когда на видюхе за шестизначные деньги не работает игра с графикой хуже, чем делали в девяностых?
Чтобы такое случилось, достаточно просто выбрать говнот в качестве движка
>>20307
Так и есть, скил ишью это когда ты из-за отсутствия скилла решаешь, что инвестировать время в говнот это хорошая идея
Забавно, что в тред пришел разраб halls of torment и сказал, что у него на говноти траблы на rtx видюхах.
Просто загуглите скрины игры, чтобы понимать абсурд ситуации (там графин хуже чем в первом Диабло)
Не это ли вершина идиократии, когда на видюхе за шестизначные деньги не работает игра с графикой хуже, чем делали в девяностых?
Чтобы такое случилось, достаточно просто выбрать говнот в качестве движка
>>20307
Так и есть, скил ишью это когда ты из-за отсутствия скилла решаешь, что инвестировать время в говнот это хорошая идея
>>20339
какие-то ебанутые одебилившие от бесконечного потребления соевики, нахуя вы драйвера обновляете? я 1 раз при установке винды скачивают самые последние и когда винда сама решает примерно раз в год - никогда никаких проблем не было
какие-то ебанутые одебилившие от бесконечного потребления соевики, нахуя вы драйвера обновляете? я 1 раз при установке винды скачивают самые последние и когда винда сама решает примерно раз в год - никогда никаких проблем не было
>>20328
Маняфантазии веруна в маркетинговые мурзилки швятой говнюнити, которая на деле обычный глюкодром, виснущий на любом железе.
Маняфантазии веруна в маркетинговые мурзилки швятой говнюнити, которая на деле обычный глюкодром, виснущий на любом железе.
>>20333
Нейронки тоже глючат на последних видяхах, а на ранних нет. Да и со свежими ААА играми такое пишут. Что, ААА играм тоже годот мешает?
Нейронки тоже глючат на последних видяхах, а на ранних нет. Да и со свежими ААА играми такое пишут. Что, ААА играм тоже годот мешает?
>>20405
Годот просто говно. А инвестиции времени/денег в него - инвестиции в говно.
Лучше бы эпики крайтекам которые банкроты занесли на допил своего движка, а не хуяну.
Т.к эти хотя-бы в прошлом были ебейшими разрабами движков, а Хуян - просто дегенерат какой-то.
Гляди и годоти были бы не годоти - а срунишки, которые умнее юнити и анрильщиков вместе взятых.
Годот просто говно. А инвестиции времени/денег в него - инвестиции в говно.
Лучше бы эпики крайтекам которые банкроты занесли на допил своего движка, а не хуяну.
Т.к эти хотя-бы в прошлом были ебейшими разрабами движков, а Хуян - просто дегенерат какой-то.
Гляди и годоти были бы не годоти - а срунишки, которые умнее юнити и анрильщиков вместе взятых.
>>20424
Годот топ.
Годот топ.
>>20438
сначала доделаю несколько проектов для стима и возможно когда-нибудь, если начну делать нормальную игру, то попробую, может повезёт
сначала доделаю несколько проектов для стима и возможно когда-нибудь, если начну делать нормальную игру, то попробую, может повезёт
>>20260
бля, а я как дурак всегда писал, что игра не понравилась и всё
>если они честно скажут, что им жалко денег за такой геймплей
бля, а я как дурак всегда писал, что игра не понравилась и всё
>>20627
ну на саппорт они могли нанять миллион индийский или пакистанских мартышек, но да, скорее всего они чисто для статистики дают выбирать причины
а зная, как вообще в Вольво работают, то даже на эту самую статистику им похуй
ну на саппорт они могли нанять миллион индийский или пакистанских мартышек, но да, скорее всего они чисто для статистики дают выбирать причины
а зная, как вообще в Вольво работают, то даже на эту самую статистику им похуй
>>20627
Пару лет назад вскрылась темка, что сотрудники сапорта стима могли получать доступы к аккаунтам. Они находили заброшенные аккаунты со скинами и выводили их.
Так вот эти сотрудники были из левых контор. Вэлв подрядчиков нанимает. Когда это вскрылось они саппорту из левых контор функционал урезали.
Пару лет назад вскрылась темка, что сотрудники сапорта стима могли получать доступы к аккаунтам. Они находили заброшенные аккаунты со скинами и выводили их.
Так вот эти сотрудники были из левых контор. Вэлв подрядчиков нанимает. Когда это вскрылось они саппорту из левых контор функционал урезали.
>>20726
Лолблять этот сраный волк заебал уже, я не говнотя и не юнипитек, но постить видос 5-летней давности это уже ни в какие ворота.
Лолблять этот сраный волк заебал уже, я не говнотя и не юнипитек, но постить видос 5-летней давности это уже ни в какие ворота.
>>20740
идея волка актуальна всегда
идея волка актуальна всегда
209 Кб, 736x732>>20742
Это пиздэу.
Это пиздэу.
>>20742
Очевидно эти видосы юнитя и снимает.
Очевидно эти видосы юнитя и снимает.
>>20754
Ну и? Сотня мешей врагов + ГГ + колесо + домики, то есть объектов больше чем на видео с волком, а проблем нет, почему так?
Ну и? Сотня мешей врагов + ГГ + колесо + домики, то есть объектов больше чем на видео с волком, а проблем нет, почему так?
Бля мне захотелось даже взять свои ассеты с уровня который я сделал в урине и запихать в годот - посмотреть сдюжит ли он.
>>20757
ты наверное на топовом конфиге запускал
ты наверное на топовом конфиге запускал
201 Кб, mp4,398x360, 0:02
>>20742
Это пиздец. хахахахах
Это пиздец. хахахахах
Понял что нет смысла делать тяжёлый движок. Сделал простую аркаду - люди начали играть и донатить.
>>1019519 →
годотям такое не снилось, чтобы книжки бесплатные, максимум документацию сделают нищую, которая устаревает в моменте выхода, а всё остальное на этом нищем движке вообще платное делают, потому что на играх не заработать, приходится курсы продавать
годотям такое не снилось, чтобы книжки бесплатные, максимум документацию сделают нищую, которая устаревает в моменте выхода, а всё остальное на этом нищем движке вообще платное делают, потому что на играх не заработать, приходится курсы продавать
>>20910
юнитям и не снилось, чтобы исходники были бесплатные, и как что работает можно сразу посмотреть и самому дописать все что хочешь. и тысячи бесплатных ассетов с исходным кодом, бери пользуйся. и тысячи бесплатных видео на ютубе. но юнитя мерит какими то своими категориями, если не склонировали что то с юнити то плоха.
юнитям и не снилось, чтобы исходники были бесплатные, и как что работает можно сразу посмотреть и самому дописать все что хочешь. и тысячи бесплатных ассетов с исходным кодом, бери пользуйся. и тысячи бесплатных видео на ютубе. но юнитя мерит какими то своими категориями, если не склонировали что то с юнити то плоха.
>>20911
больные фантазии долбоёба
>как что работает можно сразу посмотреть и самому дописать все что хочешь
больные фантазии долбоёба
>>20911
реально хочешь сравниить количество туториалов на ютубе у юнети и годити?
у юнети бесплатных ассетов столько, сколько у годоти не будет никогда
эта хуйня нужна только студиям, которые сталкиваются с какими-то ограничениями в специфических своих задачах, нужна буквальна единицам, миллионам других разработчиков открытые кишки не нужны
> тысячи бесплатных видео на ютубе
реально хочешь сравниить количество туториалов на ютубе у юнети и годити?
>тысячи бесплатных ассетов с исходным кодом
у юнети бесплатных ассетов столько, сколько у годоти не будет никогда
> самому дописать все что хочешь
эта хуйня нужна только студиям, которые сталкиваются с какими-то ограничениями в специфических своих задачах, нужна буквальна единицам, миллионам других разработчиков открытые кишки не нужны
>>20914
лол, юнитя даже представить себе такое не может.
лол, юнитя даже представить себе такое не может.
>>20916
похуй у хрюнити просто тонна мусорных туториалов записанных ради просмотров. хороших будет сравнимый порядок
тем более нет смысла париться по такому вопросу. главное что на основные системы есть.
понятно как в юнете чего то не нашлось сразу началось ненужно.
>реально хочешь сравниить количество туториалов на ютубе у юнети и годити?
похуй у хрюнити просто тонна мусорных туториалов записанных ради просмотров. хороших будет сравнимый порядок
>у юнети бесплатных ассетов столько, сколько у годоти не будет никогда
тем более нет смысла париться по такому вопросу. главное что на основные системы есть.
>не нужно
понятно как в юнете чего то не нашлось сразу началось ненужно.
>>20919
но ведь твой первый аргумент был про количество, а качество уже другой вопрос(тут кстати годотя тоже не блещет)
не нужно, понял тебя
ну это реально нужно только единицам, и то половина из них покупает платную поддержку у создателей, чтобы те сделали так, как надо
>похуй у хрюнити просто тонна мусорных туториалов записанных ради просмотров. хороших будет сравнимый порядок
но ведь твой первый аргумент был про количество, а качество уже другой вопрос(тут кстати годотя тоже не блещет)
>тем более нет смысла париться по такому вопросу. главное что на основные системы есть.
не нужно, понял тебя
>понятно как в юнете чего то не нашлось сразу началось ненужно.
ну это реально нужно только единицам, и то половина из них покупает платную поддержку у создателей, чтобы те сделали так, как надо
>>20925
тише, малютка, у тебя нихуя нет, кроме пиздежа на двче
тише, малютка, у тебя нихуя нет, кроме пиздежа на двче
Хуан Линецкий кстати нацик. Он закрыл свой Твиттер, потому что обратили внимания на его высказывания.
>>20954
вряд ли. до этого он ни в чем подобном замечен не был
в последний раз окукливался когда его захуесосили, когда он покрывал своих вокот-соевичков из дискорда
вряд ли. до этого он ни в чем подобном замечен не был
в последний раз окукливался когда его захуесосили, когда он покрывал своих вокот-соевичков из дискорда
палю быдлу убийцу хрюдота
https://github.com/godlikepanos/anki-3d-engine
https://github.com/godlikepanos/anki-3d-engine
>>20957
Кстати, да, было такое. Тогда его движок потерял часть преданных фанатов.
>когда он покрывал своих вокот-соевичков из дискорда
Кстати, да, было такое. Тогда его движок потерял часть преданных фанатов.
>>19179
Аноны, а как вы живёте в этой ecs хуйне если простой советский выстрел и попадание происходит следующим путем
Инпутвент OnPlayerShoot()->playerentity.addcomponent<shootdata>()->итерация системы shootdata->createentityBullet()->итерация системы bullet()->targetentity.addcomponent<hitcomponent>()->итерация системы по двум признакам (healthcomponent, hitcomponent)->decreasehealth()
И кстати, чё по многопотоку? Как отследить что компонент только появился, либо только что был удалён? Насколько тяжело жить без возможности иметь 2 компонента одного типа на одной сущности?
Аноны, а как вы живёте в этой ecs хуйне если простой советский выстрел и попадание происходит следующим путем
Инпутвент OnPlayerShoot()->playerentity.addcomponent<shootdata>()->итерация системы shootdata->createentityBullet()->итерация системы bullet()->targetentity.addcomponent<hitcomponent>()->итерация системы по двум признакам (healthcomponent, hitcomponent)->decreasehealth()
И кстати, чё по многопотоку? Как отследить что компонент только появился, либо только что был удалён? Насколько тяжело жить без возможности иметь 2 компонента одного типа на одной сущности?
>>20981
Очередной Фалька?
Очередной Фалька?
>>20989
"Вы просто не умеете её правильно готовить"©
На самом деле я прошел все стадии решения этих проблем и понял что оригинальный "pure" ecs потому и является таким обоссаным говном, потому я написал свой собственный велосипед на полностью многопоточной основе(а щас под полную асинхронщину рефакторю), с компонентом, решающим проблему мультикомпонентности 1 типа, с designed by contracts системами(контрактами), где блокировки на чтение обеспечивают фиксацию наличия или отсутствия определенных компонентов на время выполнения контракта(кода системы) у объектов контракта (сущностей) на основе readwritelockslim, что в итоге позволяет мне городить очень хитрый огород с системами, которые могут обрабатывать не каждый отдельный компонент сущности, а коллекции сущностей в целом. Разве что у меня нет возможности делать компоненты-структуры, потому что придется дублировать код раз, проблемы с сериализацией - два. Но мне сам архитектурный подход ecs нравится, потому я срезал его углы и смирился с недостатками полученного результата. Отлаживать как и любую другую многопоточку трудно, но обычно, если все дробить на контракты - проблем не возникает. Но это и не ecs уже совсем))
"Вы просто не умеете её правильно готовить"©
На самом деле я прошел все стадии решения этих проблем и понял что оригинальный "pure" ecs потому и является таким обоссаным говном, потому я написал свой собственный велосипед на полностью многопоточной основе(а щас под полную асинхронщину рефакторю), с компонентом, решающим проблему мультикомпонентности 1 типа, с designed by contracts системами(контрактами), где блокировки на чтение обеспечивают фиксацию наличия или отсутствия определенных компонентов на время выполнения контракта(кода системы) у объектов контракта (сущностей) на основе readwritelockslim, что в итоге позволяет мне городить очень хитрый огород с системами, которые могут обрабатывать не каждый отдельный компонент сущности, а коллекции сущностей в целом. Разве что у меня нет возможности делать компоненты-структуры, потому что придется дублировать код раз, проблемы с сериализацией - два. Но мне сам архитектурный подход ecs нравится, потому я срезал его углы и смирился с недостатками полученного результата. Отлаживать как и любую другую многопоточку трудно, но обычно, если все дробить на контракты - проблем не возникает. Но это и не ecs уже совсем))
>>20989
Ну, например Овердроч полностью на екс построен
https://www.youtube.com/watch?v=W3aieHjyNvw
https://www.youtube.com/watch?v=odSBJ49rzDo
>сказки про ецс это сказки
Ну, например Овердроч полностью на екс построен
https://www.youtube.com/watch?v=W3aieHjyNvw
https://www.youtube.com/watch?v=odSBJ49rzDo
>>20993
А ты овердроч делаешь? Или у тебя есть косарь сотрудников которые могут копошиться во всех этих последовательностях хитросплетений операций над компонентами? У меня кстати перед лицом есть пример такого проекта как TankiX, который авторы ещё до появления dots написали на полностью ecs основе, все от ui до физики было написано на ecs в юнити, и который закрылся ещё имея 2-3к игроков знаешь почему? Потому что его было нереально поддерживать не в убыток даже при таком уровне донатящего онлайна. И впоследствии авторы отказались от ecs парадигмы в рамках своих оставшихся проектов. С dots ситуация конечно улучшилась, хотя бы не нужно тратить бабло на поддержку самого фреймворка, но его болячки раздувающие кодовую базу никуда не делись.
А ты овердроч делаешь? Или у тебя есть косарь сотрудников которые могут копошиться во всех этих последовательностях хитросплетений операций над компонентами? У меня кстати перед лицом есть пример такого проекта как TankiX, который авторы ещё до появления dots написали на полностью ecs основе, все от ui до физики было написано на ecs в юнити, и который закрылся ещё имея 2-3к игроков знаешь почему? Потому что его было нереально поддерживать не в убыток даже при таком уровне донатящего онлайна. И впоследствии авторы отказались от ecs парадигмы в рамках своих оставшихся проектов. С dots ситуация конечно улучшилась, хотя бы не нужно тратить бабло на поддержку самого фреймворка, но его болячки раздувающие кодовую базу никуда не делись.
846 Кб, 1771x977>>20993
прикольно
прикольно
>>20995
а зачем эти шизики всё делали на екс? с какой целью? ради мифических пико секунд в скорости? вот ещё один хороший пример, какой-то ёбнутый анальник нахуевертил хуеты, исполнил свои влажные мечты и убил этим проект, потому что никто другой не смог разобраться в его дерьме
а зачем эти шизики всё делали на екс? с какой целью? ради мифических пико секунд в скорости? вот ещё один хороший пример, какой-то ёбнутый анальник нахуевертил хуеты, исполнил свои влажные мечты и убил этим проект, потому что никто другой не смог разобраться в его дерьме
>>20995
Нет. Но я делаю сетевую игру. Уже вторую. Первая была на обычном ООП и это была боль. С ECS это совершенно другой уровень. Я могу добавлять любые фишки и мне не нужно дрочиться с синхронизацией (только роллбеки учитывать кое-где) и я могу всё тестировать локально с ботами. Если бы мне пришлось делать это "по старинке", то я бы охуел. Теперь буду делать сетевые игры на ECS.
Хотя для сингловой игры я бы не стал использовать ECS, ибо профиты от этого не получишь.
>А ты овердроч делаешь?
Нет. Но я делаю сетевую игру. Уже вторую. Первая была на обычном ООП и это была боль. С ECS это совершенно другой уровень. Я могу добавлять любые фишки и мне не нужно дрочиться с синхронизацией (только роллбеки учитывать кое-где) и я могу всё тестировать локально с ботами. Если бы мне пришлось делать это "по старинке", то я бы охуел. Теперь буду делать сетевые игры на ECS.
Хотя для сингловой игры я бы не стал использовать ECS, ибо профиты от этого не получишь.
>>20989
Потому что он неопытен в ецсе?
>>20984
Никто не будет добавлять и удклять компоненты с ентитей в рантайме так частр
1. Система считывающая инпут и задающая реакцию игроку.
Итерация по (Пушкам, Игроку) Пушка.Стрельба = Инпут.НажалаЛкм
2. Система пушкострел
Инютеерация по Пушкам
Если стрельба - спавним префаб пули.
Пуля.Позиция = вычислитьПозициюДляПули();
3. На префабе пули уже висит компонент содержащий урон, мы этот параметр сразу в Пуля доьавиои
4. СистемаПули - Итерация По Пулям
Если Пуля врезвлась в коллайдер
То удаляем пулю, создаем ентити демеджРеквест, таргет коллаыдер, урон = урон пули
5. Система нанесения урона
Итерация по демедж реквестам
Если демеджРеквест.Таргет есть компонент хп, то наносим урона
Удалчем демедж реквесты
Ецс это не обязателньо многопоточность.
Конкретно в юнити многопоток в ецсе есть, там он работает через джоб систему и автоматически паралллелит код в зависимости от того где ты читаешь данные и где пишешь в данные, ну и условиц порядка выполнения которые задашь. Если 2 системы читают те же данные, то будут параллельно работать.
Потому что он неопытен в ецсе?
>>20984
> Инпутвент OnPlayerShoot()->playerentity.addcomponent<shootdata>()->итерация системы shootdata->createentityBullet()->итерация системы bullet()->targetentity.addcomponent<hitcomponent>()->итерация системы по двум признакам (healthcomponent, hitcomponent)->decreasehealth()
Никто не будет добавлять и удклять компоненты с ентитей в рантайме так частр
1. Система считывающая инпут и задающая реакцию игроку.
Итерация по (Пушкам, Игроку) Пушка.Стрельба = Инпут.НажалаЛкм
2. Система пушкострел
Инютеерация по Пушкам
Если стрельба - спавним префаб пули.
Пуля.Позиция = вычислитьПозициюДляПули();
3. На префабе пули уже висит компонент содержащий урон, мы этот параметр сразу в Пуля доьавиои
4. СистемаПули - Итерация По Пулям
Если Пуля врезвлась в коллайдер
То удаляем пулю, создаем ентити демеджРеквест, таргет коллаыдер, урон = урон пули
5. Система нанесения урона
Итерация по демедж реквестам
Если демеджРеквест.Таргет есть компонент хп, то наносим урона
Удалчем демедж реквесты
> И кстати, чё по многопотоку? Как отследить что компонент только появился, либо только что был удалён?
Ецс это не обязателньо многопоточность.
Конкретно в юнити многопоток в ецсе есть, там он работает через джоб систему и автоматически паралллелит код в зависимости от того где ты читаешь данные и где пишешь в данные, ну и условиц порядка выполнения которые задашь. Если 2 системы читают те же данные, то будут параллельно работать.
>>20989
Потому что он неопытен в ецсе?
>>20984
Никто не будет добавлять и удклять компоненты с ентитей в рантайме так частр
1. Система считывающая инпут и задающая реакцию игроку.
Итерация по (Пушкам, Игроку) Пушка.Стрельба = Инпут.НажалаЛкм
2. Система пушкострел
Инютеерация по Пушкам
Если стрельба - спавним префаб пули.
Пуля.Позиция = вычислитьПозициюДляПули();
3. На префабе пули уже висит компонент содержащий урон, мы этот параметр сразу в Пуля доьавиои
4. СистемаПули - Итерация По Пулям
Если Пуля врезвлась в коллайдер
То удаляем пулю, создаем ентити демеджРеквест, таргет коллаыдер, урон = урон пули
5. Система нанесения урона
Итерация по демедж реквестам
Если демеджРеквест.Таргет есть компонент хп, то наносим урона
Удалчем демедж реквесты
Ецс это не обязателньо многопоточность.
Конкретно в юнити многопоток в ецсе есть, там он работает через джоб систему и автоматически паралллелит код в зависимости от того где ты читаешь данные и где пишешь в данные, ну и условиц порядка выполнения которые задашь. Если 2 системы читают те же данные, то будут параллельно работать.
Потому что он неопытен в ецсе?
>>20984
> Инпутвент OnPlayerShoot()->playerentity.addcomponent<shootdata>()->итерация системы shootdata->createentityBullet()->итерация системы bullet()->targetentity.addcomponent<hitcomponent>()->итерация системы по двум признакам (healthcomponent, hitcomponent)->decreasehealth()
Никто не будет добавлять и удклять компоненты с ентитей в рантайме так частр
1. Система считывающая инпут и задающая реакцию игроку.
Итерация по (Пушкам, Игроку) Пушка.Стрельба = Инпут.НажалаЛкм
2. Система пушкострел
Инютеерация по Пушкам
Если стрельба - спавним префаб пули.
Пуля.Позиция = вычислитьПозициюДляПули();
3. На префабе пули уже висит компонент содержащий урон, мы этот параметр сразу в Пуля доьавиои
4. СистемаПули - Итерация По Пулям
Если Пуля врезвлась в коллайдер
То удаляем пулю, создаем ентити демеджРеквест, таргет коллаыдер, урон = урон пули
5. Система нанесения урона
Итерация по демедж реквестам
Если демеджРеквест.Таргет есть компонент хп, то наносим урона
Удалчем демедж реквесты
> И кстати, чё по многопотоку? Как отследить что компонент только появился, либо только что был удалён?
Ецс это не обязателньо многопоточность.
Конкретно в юнити многопоток в ецсе есть, там он работает через джоб систему и автоматически паралллелит код в зависимости от того где ты читаешь данные и где пишешь в данные, ну и условиц порядка выполнения которые задашь. Если 2 системы читают те же данные, то будут параллельно работать.
Какие же юничуханы клоуны анальные ебаные, божемой. Мало того что с юниговнодвижком бороться надо чтобы хоть что-то на нем сделать, так теперь еще и с юнити как с компанией бодаться
https://www.reddit.com/r/gamedev/comments/1kiyh0m/unity_is_threatening_to_revoke_all_licenses_for/
https://www.reddit.com/r/gamedev/comments/1kiyh0m/unity_is_threatening_to_revoke_all_licenses_for/
>>21044
Тебе-то конечно нихуя не будет, ты нихуя не делаешь. А лохов которые умудряются на хуюните зарабатывать - подстригут как следует.
Тебе-то конечно нихуя не будет, ты нихуя не делаешь. А лохов которые умудряются на хуюните зарабатывать - подстригут как следует.
>>21043
Не, ну справедливости ради мы благодаря нему заработали намного больше $200к. Тут просто русское жлобство взыграло и не хочется платить за несколько лицензий.
Не, ну справедливости ради мы благодаря нему заработали намного больше $200к. Тут просто русское жлобство взыграло и не хочется платить за несколько лицензий.
>>21029
Ну во первых это не так часто происходит в этом случае, а во вторых - ты делаешь то же самое, просто логика ещё более припизднутая.
Многопотока нет, понял принял.
>>21015
ебли. Кстати, а как вы ограничиваете какие сущности какие компоненты могут видеть? Как оптимизируете трафик? Конечно, по сетевой синхронизации ecs значительно опережает аналоги, но вот эта припизднутая слабосвязанная логика моя самая огромная претензия к ecs, с этими соплями можно иметь дело, но только в команде.
>Никто не будет добавлять и удклять компоненты с ентитей в рантайме так частр
Ну во первых это не так часто происходит в этом случае, а во вторых - ты делаешь то же самое, просто логика ещё более припизднутая.
>Если демеджРеквест.Таргет есть компонент хп, то наносим урона
Многопотока нет, понял принял.
>>21015
>С ECS это совершенно другой уровень
ебли. Кстати, а как вы ограничиваете какие сущности какие компоненты могут видеть? Как оптимизируете трафик? Конечно, по сетевой синхронизации ecs значительно опережает аналоги, но вот эта припизднутая слабосвязанная логика моя самая огромная претензия к ecs, с этими соплями можно иметь дело, но только в команде.
>>21045
У нас компания международная на 200+ ебал, никому нихуя не делаю за юнити персонал
У нас компания международная на 200+ ебал, никому нихуя не делаю за юнити персонал
>>21047
Добавление и удаление компонентов всегда хуйня
Не обязательно чтобы всё было распараллелено. Да и можно и это в многопотоке сделать компонентЛукапом
> Ну во первых это не так часто происходит в этом случае, а во вторых - ты делаешь то же самое, просто логика ещё более припизднутая.
Добавление и удаление компонентов всегда хуйня
> Многопотока нет, понял принял.
Не обязательно чтобы всё было распараллелено. Да и можно и это в многопотоке сделать компонентЛукапом
>>21037
Хорошо что я делаю на СВОЕМ движке.
И на своем языке.
пришлось сделать свой чтоб не спиздили движок. Он же на жс и хтмл
Зато делать игры на нем очень легко. Тупо вбил что надо и готово.
Хорошо что я делаю на СВОЕМ движке.
И на своем языке.
пришлось сделать свой чтоб не спиздили движок. Он же на жс и хтмл
Зато делать игры на нем очень легко. Тупо вбил что надо и готово.
>>21050
А что произойдет, когда лукап отработает, войдёт в метод обработки, а компонент в этот момент удалится из другого треда?
>компонентЛукапом
А что произойдет, когда лукап отработает, войдёт в метод обработки, а компонент в этот момент удалится из другого треда?
>>21052
Почитай док, там все расписано же.
Между синк поинтами(структурными изменениями) системы параллельно работают.
Чтобы сделать структурные изменения без синк поинта, используют ентити комманд буффер(есть многопоточное апи) и все что в него заложено проигрывают потом когда это нужно.
> А что произойдет, когда лукап отработает, войдёт в метод обработки, а компонент в этот момент удалится из другого треда?
Почитай док, там все расписано же.
Между синк поинтами(структурными изменениями) системы параллельно работают.
Чтобы сделать структурные изменения без синк поинта, используют ентити комманд буффер(есть многопоточное апи) и все что в него заложено проигрывают потом когда это нужно.
>>21049
Хорошо, не верь
Хорошо, не верь
>>21053
Это значит только одно - вас ожидают вот такие приятные побочные эффекты от использования очереди синхронизации
https://youtu.be/0ldiCi80gE4
Или любых других copy on write форматов воздействия на данные.
Это значит только одно - вас ожидают вот такие приятные побочные эффекты от использования очереди синхронизации
https://youtu.be/0ldiCi80gE4
Или любых других copy on write форматов воздействия на данные.
>>21053
Ну окей, даже без дока, как оно по твоему работает? Мне просто интересно твое мнение. А ещё можешь задуматься, а как оно разруливает ситуации как в видео, если в этот буффер пишутся только команды, которые зависят от контекста, но не включают его в себя.
>ентити комманд буффер
Ну окей, даже без дока, как оно по твоему работает? Мне просто интересно твое мнение. А ещё можешь задуматься, а как оно разруливает ситуации как в видео, если в этот буффер пишутся только команды, которые зависят от контекста, но не включают его в себя.
>>21058
https://docs.unity3d.com/Packages/com.unity.entities@1.4/manual/systems-scheduling-jobs.html
>>21059
Я уже выше всё написал - паралелльно выполняются системы не конфликтующие друг с другом, и делают это в промежутках между структурными изменениями.
Если две системы читают один данные - можно параллельно.
Если одна система пишет одни данные, а другие не читают их - можно параллельно.
Если нет - они не будут работать параллельно.
Очевидно, в буфер не пишутся команды, которые зависят от контекста.
Надо создать ентити - ваще вскм пох.
Одна система читает данные каких то ентити, а другая их удаляет - похуй, реальное удаление будет после плейбека команд, а не в комент регистрации команды на удаление. Но скорее всего у тебя срань с порядком систем и логикой если такая ситуация.
https://docs.unity3d.com/Packages/com.unity.entities@1.4/manual/systems-scheduling-jobs.html
>>21059
Я уже выше всё написал - паралелльно выполняются системы не конфликтующие друг с другом, и делают это в промежутках между структурными изменениями.
Если две системы читают один данные - можно параллельно.
Если одна система пишет одни данные, а другие не читают их - можно параллельно.
Если нет - они не будут работать параллельно.
> если в этот буффер пишутся только команды, которые зависят от контекста
Очевидно, в буфер не пишутся команды, которые зависят от контекста.
Надо создать ентити - ваще вскм пох.
Одна система читает данные каких то ентити, а другая их удаляет - похуй, реальное удаление будет после плейбека команд, а не в комент регистрации команды на удаление. Но скорее всего у тебя срань с порядком систем и логикой если такая ситуация.
>>21060
https://docs.unity3d.com/Packages/com.unity.entities@1.0/manual/systems-entity-command-buffer-playback.html
Емае, все ещё хуже чем я ожидал. Да это же мой любимый многопоточный код однопоточного исполнения, где чтобы не обосраться придется нумеровать каждый пук и без блокировок строить таким образом синхронизацию. Ну-ну, пахнет производительно, а главное удобно.
https://docs.unity3d.com/Packages/com.unity.entities@1.0/manual/systems-entity-command-buffer-playback.html
Емае, все ещё хуже чем я ожидал. Да это же мой любимый многопоточный код однопоточного исполнения, где чтобы не обосраться придется нумеровать каждый пук и без блокировок строить таким образом синхронизацию. Ну-ну, пахнет производительно, а главное удобно.
>>21060
Не, скорее у меня реальный многопоток, а не гадание на кофейной гуще, правильный ли я порядок команд выбрал. Впрочем конечно тут вопрос технологии а не принципов, мне удобно так, вашей команде так.
>Но скорее всего у тебя срань с порядком систем и логикой если такая ситуация.
Не, скорее у меня реальный многопоток, а не гадание на кофейной гуще, правильный ли я порядок команд выбрал. Впрочем конечно тут вопрос технологии а не принципов, мне удобно так, вашей команде так.
>>21061
Ты ваще не о том думаешь, сразу заспойлерю, тебе самому нумеровать ничего не нужно, прям там нижк пример есть - джоба предоставит тебе цифру.
Ты ваще не о том думаешь, сразу заспойлерю, тебе самому нумеровать ничего не нужно, прям там нижк пример есть - джоба предоставит тебе цифру.
>>21065
Давай, будем ждать.
Нужна какая-то демка, чтобы было явно видно как ты хендлишь удаление и создание объектов, и порядок логики, что вот сначала одно должно отработать, потом другое.
Давай, будем ждать.
Нужна какая-то демка, чтобы было явно видно как ты хендлишь удаление и создание объектов, и порядок логики, что вот сначала одно должно отработать, потом другое.
>>21066
Сущность - только контейнер, компоненты, да хендлятся, добавление, удаление, изменение
Порядка логики нет. Я фиксирую состояние определенного набора компонентов у сущност(и/ей) и/или отсутствие определенного набора компонентов, и любая попытка изменить состояние хоть одного из элементов состояния этого набора присущего сущности которая попала в выполняющийся контракт будет висеть в блокировке до завершения контрактов, запросивших на чтение наборы, куда входит та часть которую я хочу изменить (удалить, изменить, добавить). Хотя в случае с деньгами или скоростью или любым другим не особенно важным компонентом - я могу его изменять напрямую а не через changecomponent (иммутабельный подход к редактированию компонентов), если того пожелаю. Вот в принципе и все. При таком подходе я теряю не так много процессорного времени на ожидания, чем если буду формировать очередность выполнения или на все вешать блокировки, что по сути аналог ручного управления очередью выполнения.
>хендлишь удаление и создание объектов
Сущность - только контейнер, компоненты, да хендлятся, добавление, удаление, изменение
>порядок логики
Порядка логики нет. Я фиксирую состояние определенного набора компонентов у сущност(и/ей) и/или отсутствие определенного набора компонентов, и любая попытка изменить состояние хоть одного из элементов состояния этого набора присущего сущности которая попала в выполняющийся контракт будет висеть в блокировке до завершения контрактов, запросивших на чтение наборы, куда входит та часть которую я хочу изменить (удалить, изменить, добавить). Хотя в случае с деньгами или скоростью или любым другим не особенно важным компонентом - я могу его изменять напрямую а не через changecomponent (иммутабельный подход к редактированию компонентов), если того пожелаю. Вот в принципе и все. При таком подходе я теряю не так много процессорного времени на ожидания, чем если буду формировать очередность выполнения или на все вешать блокировки, что по сути аналог ручного управления очередью выполнения.
>>21068
Ну и ко всему этому - я могу выполнять код пока происходит удаление/замена/добавление компонента, что то вроде AddOrUpdate у concurrentdictionary, на которых частично в общем и строится контрактный подход. Остальные компоненты не блокируются, только попавшие в контракт/в такой метод.
Ну и ко всему этому - я могу выполнять код пока происходит удаление/замена/добавление компонента, что то вроде AddOrUpdate у concurrentdictionary, на которых частично в общем и строится контрактный подход. Остальные компоненты не блокируются, только попавшие в контракт/в такой метод.
>>21071
Поподробнее
Поподробнее
>>21037
Уже понятно что юнити и как бренд и как движок ВСЕ, кабанчики просто пытаются выжать из клиентов по-максимуму и свалить.
Уже понятно что юнити и как бренд и как движок ВСЕ, кабанчики просто пытаются выжать из клиентов по-максимуму и свалить.
6,5 Мб, 2544x4000>>21037
Прикиньте иметь успешный движок, устоявшийся бренд, который десятилетие ассоциировался как тот самый движок для индюков, но проебать эту репутацию одним тупым ходом, а потом вместо того чтобы медленно собирать по кусочкам проёбанную репутацию продолжать наступать на грабли.
Прикиньте иметь успешный движок, устоявшийся бренд, который десятилетие ассоциировался как тот самый движок для индюков, но проебать эту репутацию одним тупым ходом, а потом вместо того чтобы медленно собирать по кусочкам проёбанную репутацию продолжать наступать на грабли.
>>21037
ебанарий решил, что если он известный разработчик, то соблюдать условия лицензии необязательно, и поплатился за это. так будет с каждым. быть добру!
ебанарий решил, что если он известный разработчик, то соблюдать условия лицензии необязательно, и поплатился за это. так будет с каждым. быть добру!
4,1 Мб, mp4,640x360, 2:46
Почему безыгорки так распереживались за движок с которым они даже не работают)
>>21100
Главное не плачь потом когда очередной корпорации (Нинтендо например) опять чего-то покажется и она тебе иск выдаст на десяток другой лимонов. Особенно если она про это проведает ещё до релиза потому что у тебя на компе будет стоять их малварь, которая будет каждый твой пук отправлять на изучение непонятно кому.
>так будет с каждым. быть добру!
Главное не плачь потом когда очередной корпорации (Нинтендо например) опять чего-то покажется и она тебе иск выдаст на десяток другой лимонов. Особенно если она про это проведает ещё до релиза потому что у тебя на компе будет стоять их малварь, которая будет каждый твой пук отправлять на изучение непонятно кому.
>>21104
Ну тебе то безыгнорнику терять кроме собственных оков может и нечего. Но если такие поползновения с безапеляционной установкой малвари на компьютер со стороны компаний продолжатся - рано или поздно и за твоими оковами придут.
Ну тебе то безыгнорнику терять кроме собственных оков может и нечего. Но если такие поползновения с безапеляционной установкой малвари на компьютер со стороны компаний продолжатся - рано или поздно и за твоими оковами придут.
>>21104
Ну тебе то безыгнорнику терять кроме собственных оков может и нечего. Но если такие поползновения с безапеляционной установкой малвари на компьютер со стороны компаний продолжатся - рано или поздно и за твоими оковами придут.
Ну тебе то безыгнорнику терять кроме собственных оков может и нечего. Но если такие поползновения с безапеляционной установкой малвари на компьютер со стороны компаний продолжатся - рано или поздно и за твоими оковами придут.
Аноны я уже 50раз посмотрел трейдеры гта 6.
Вопрос.
1) Как они делают чтобы грязь на стеклах и корпусах машин появлялась процедурно? Вот естт базовая 3д модель машины сделанная в блендере. А как на ее краску добавлять пыль , царапки, а как повреждения рассчитывать сминания крыльев и дверей?
2) И как работает рей трейсинг в плане окрашивания отражённого света? Откуда компьютер берет данные о цвете 3д модели импортированной в движок и как преобразует отраженный свет накладывая "фильтр" цвета от чего от оотразился!?
3) Вопрос.
Можно ли сделать все как в гта не имея бюджета в миллиард и 2000 спецов. Но имея скажем отлаженный продакшн пайплайн с использвоанием ИИ в плане создания 3д моделей, текстур и все наполенния мира
Вопрос.
1) Как они делают чтобы грязь на стеклах и корпусах машин появлялась процедурно? Вот естт базовая 3д модель машины сделанная в блендере. А как на ее краску добавлять пыль , царапки, а как повреждения рассчитывать сминания крыльев и дверей?
2) И как работает рей трейсинг в плане окрашивания отражённого света? Откуда компьютер берет данные о цвете 3д модели импортированной в движок и как преобразует отраженный свет накладывая "фильтр" цвета от чего от оотразился!?
3) Вопрос.
Можно ли сделать все как в гта не имея бюджета в миллиард и 2000 спецов. Но имея скажем отлаженный продакшн пайплайн с использвоанием ИИ в плане создания 3д моделей, текстур и все наполенния мира
>>21113
Конечно можно, в рокстар же дебилы ретрограды работают, ведь уже давно появилась нейронка которая сможет написать шейдер освещения тысяч на 100 строк без единой ошибки, разработать архитектуру с оатимизациями путём всяческих SIMD и паралелизацией с минимальным cachemiss, обернет вся тяжёлые для вычисления (например деформации меша) в computeshader и попутно ещё и оптимизированых и правильных 3д моделей с анимациями нагенерирует. Появилась ведь?!?
>Можно ли сделать все как в гта не имея бюджета в миллиард и 2000 спецов. Но имея скажем отлаженный продакшн пайплайн с использвоанием ИИ в плане создания 3д моделей, текстур и все наполенния мира
Конечно можно, в рокстар же дебилы ретрограды работают, ведь уже давно появилась нейронка которая сможет написать шейдер освещения тысяч на 100 строк без единой ошибки, разработать архитектуру с оатимизациями путём всяческих SIMD и паралелизацией с минимальным cachemiss, обернет вся тяжёлые для вычисления (например деформации меша) в computeshader и попутно ещё и оптимизированых и правильных 3д моделей с анимациями нагенерирует. Появилась ведь?!?
>>21037
А вас еще года два назад в треде предупреждали что такое будет с хрюнити где хаб стучиться онлаен и спрашивает у барина можно ли запуститься.
Одна из основных причин переходить на годот - ты им владеешь у себя на компе, по лицензии у тебя и движок и исходники.
А вас еще года два назад в треде предупреждали что такое будет с хрюнити где хаб стучиться онлаен и спрашивает у барина можно ли запуститься.
Одна из основных причин переходить на годот - ты им владеешь у себя на компе, по лицензии у тебя и движок и исходники.
>>21120
Вот бы сейчас выдавать тейки 10 летней давности... В то время как уже вышли тысячи игр на годоте.
Вот бы сейчас выдавать тейки 10 летней давности... В то время как уже вышли тысячи игр на годоте.
>>21117
соблюдать условия лицензии обязательно всем, не только пользователям юнити, тупица
соблюдать условия лицензии обязательно всем, не только пользователям юнити, тупица
>>21135
кретин, корпораты могут взять и отозвать лицензию или вписать условия по которым ты станешь неугодным. с опенсорсом это невозможно.
кретин, корпораты могут взять и отозвать лицензию или вписать условия по которым ты станешь неугодным. с опенсорсом это невозможно.
>>21137
Их хуй у тебя во рту. Ты даже не заметил.
Их хуй у тебя во рту. Ты даже не заметил.
>>21135
А ты чем читал? Они пишут что все условия соблюли. И что им предъявили за челов, которые не работают на юнити, или которым оплачивали про на время работы, или вообще левым челам которые зареганы в том же офисном здании. Сама по себе ситуация, что ты должен доказывать что не верблюд, при том что только что заплатил десятки тысяч долларов - лол.
А ты чем читал? Они пишут что все условия соблюли. И что им предъявили за челов, которые не работают на юнити, или которым оплачивали про на время работы, или вообще левым челам которые зареганы в том же офисном здании. Сама по себе ситуация, что ты должен доказывать что не верблюд, при том что только что заплатил десятки тысяч долларов - лол.
>>21117
Сотни тысяч разработчиков пользуются юнити годами и никаких проблем. Только у безыгорной маньки лицензии какие то отбирают
Сотни тысяч разработчиков пользуются юнити годами и никаких проблем. Только у безыгорной маньки лицензии какие то отбирают
32 Кб, 986x170>>21144
Все эти сотни тысяч разработчиков без проблем сейчас с тобой в одной комнате?
У любого могут отобрать.
Все эти сотни тысяч разработчиков без проблем сейчас с тобой в одной комнате?
У любого могут отобрать.
>>21146
Ну не прям в одной комнате, но в одном слаке.
>>21147
У него доход на миллионы долларов исчисляется, чего ты так переживаешь за то что он 20к долларов платит?
Все вопросы с лицензиями сначала урегулируются в досудебном порядке, если никак, то через суд. Скорее всего они там уже со всем разобрались давно.
Ну не прям в одной комнате, но в одном слаке.
>>21147
У него доход на миллионы долларов исчисляется, чего ты так переживаешь за то что он 20к долларов платит?
Все вопросы с лицензиями сначала урегулируются в досудебном порядке, если никак, то через суд. Скорее всего они там уже со всем разобрались давно.
>>21148
Лол. Сейчас бы бегать по судам доказывать что ты правильно все барину подписал, потому что у барина на тебя бот или индус сагрился. Ебануться. Юнитя почему вы такие терпилы?
Лол. Сейчас бы бегать по судам доказывать что ты правильно все барину подписал, потому что у барина на тебя бот или индус сагрился. Ебануться. Юнитя почему вы такие терпилы?
>>21151
То ли дело доказывать барину опенсорса 3 года что без uuid работа с ресурсами в движке будет говном неюзабельным и ловить баны за недостаточную инклюзивность.
То ли дело доказывать барину опенсорса 3 года что без uuid работа с ресурсами в движке будет говном неюзабельным и ловить баны за недостаточную инклюзивность.
Компьютеры стагнировали. Значительно меньших задержек не будет как из-за софта, так и из-за архитектуры, так и из-за физических принципов работы. Я думаю всё же стоит за основу брать готовые инструменты для создания инструментов создания интерактивного контента, даже если результат не особо хорош будет. Ведь действительно много времени стоит уделелять созданию фотонных компьютеров. Даже если образования пока нет, его получить можно с теми же усилиями, что создание движка на уровне анрила. А потом в некой лаборатории делать компьютер, монитор и устройства ввода фотонные без электроники. В какую сторону стоит развивать движкостроительство? Каковы перспективы фотонных компьютеров, помимо меньших задержек и большей частоты кадров?
>>21152
Мне не нужны uuid ресурсов. На баны мне похуй, я не пользуюсь хуиттерами, на программу это не влияет.
Мне не нужны uuid ресурсов. На баны мне похуй, я не пользуюсь хуиттерами, на программу это не влияет.
>>21161
Конечно. Поэтому ты не используй юнити, чтобы тоже в такую ситуацию не попасть. Бери лучше народный годот.
Конечно. Поэтому ты не используй юнити, чтобы тоже в такую ситуацию не попасть. Бери лучше народный годот.
2 Мб, 3840x2160Скрин из трейлера гта 6.
1 пик спарва сверху внимание на логотип бара. Куча деталей , каждая свою тень обрастывает. Есть идеи как они это реаллизовали наиболее cost effective способом? Если все такое отдать на откуп лучам то это же пиздец, 4080 нужна минимум. Как думаете каким способом они это сделали, чтобы пс5 тянула в 1440р? ну там 3д параллакс текстуры все такое. я не разбираюсь но хочу разобарться и сделать уже свою гта спб на уровне гта 6
1 пик спарва сверху внимание на логотип бара. Куча деталей , каждая свою тень обрастывает. Есть идеи как они это реаллизовали наиболее cost effective способом? Если все такое отдать на откуп лучам то это же пиздец, 4080 нужна минимум. Как думаете каким способом они это сделали, чтобы пс5 тянула в 1440р? ну там 3д параллакс текстуры все такое. я не разбираюсь но хочу разобарться и сделать уже свою гта спб на уровне гта 6
>>21167
Годот.
Годот.
>>21167
Есть, для мод-лоуполи 3Д очень много аналогичных движков, даже на С#, для 2Д годот, гамак, для ААА юнити никогда не годился, тут анрил всегда доминировал.
Есть, для мод-лоуполи 3Д очень много аналогичных движков, даже на С#, для 2Д годот, гамак, для ААА юнити никогда не годился, тут анрил всегда доминировал.
>>21165
ты ебучая безмозглая тварь понимаешь, что рассматриваешь зализанный трейлер, а не игру?
ты ебучая безмозглая тварь понимаешь, что рассматриваешь зализанный трейлер, а не игру?
>>20984
Шутдата уже есть до того как игрок выстрелил вообще-то.
Ну да. У тебя везде так будет, включая говдот.
? Шизик? Это что и нахуя? Всё это создаётся на предыдущем этапе.
Ну ничего себе, надо коллизии для пуль считать оказывается и хп убавлять. Только в ECS наверное такое происходит!
ЮИ кстати, чё по многопотоку?
Слишком зависит от реализации. В любом случае всё не может быть многопоточным, какие-то операции полюбому будут зависеть друг от друга.
Флагами.
Никто не говорил что так делать нельзя, зависит от реализации, в любом случае можно скрыть за композицией.
>playerentity.addcomponent<shootdata>()
Шутдата уже есть до того как игрок выстрелил вообще-то.
>итерация системы shootdata->createentityBullet()
Ну да. У тебя везде так будет, включая говдот.
>итерация системы bullet() targetentity.addcomponent<hitcomponent>()
? Шизик? Это что и нахуя? Всё это создаётся на предыдущем этапе.
>итерация системы по двум признакам (healthcomponent, hitcomponent)->decreasehealth()
Ну ничего себе, надо коллизии для пуль считать оказывается и хп убавлять. Только в ECS наверное такое происходит!
ЮИ кстати, чё по многопотоку?
Слишком зависит от реализации. В любом случае всё не может быть многопоточным, какие-то операции полюбому будут зависеть друг от друга.
>Как отследить что компонент только появился, либо только что был удалён?
Флагами.
>Насколько тяжело жить без возможности иметь 2 компонента одного типа на одной сущности?
Никто не говорил что так делать нельзя, зависит от реализации, в любом случае можно скрыть за композицией.
>>21184
ого а зчекм так грубо?!
\
трейлер капчурился с пс5(дата релиза 4.5 г назад, железоуровня 2019) в рил тайме
ого а зчекм так грубо?!
\
трейлер капчурился с пс5(дата релиза 4.5 г назад, железоуровня 2019) в рил тайме
>>21189
Дятел, даже читать твои кукареки не буду, или пиши нормально и конкретно как ты это видишь или нахуй иди. Чел выше написал как он это видит, будь как он, уважай собеседника.
Ясно, многопотока ты не видел
Ну если без многопотока то в целом и похуй и даже извращаться так как я описал не нужно, но флаги все равно хуйня, методы нужны.
Дятел, даже читать твои кукареки не буду, или пиши нормально и конкретно как ты это видишь или нахуй иди. Чел выше написал как он это видит, будь как он, уважай собеседника.
>Слишком зависит от реализации. В любом случае всё не может быть многопоточным, какие-то операции полюбому будут зависеть друг от друга.
Ясно, многопотока ты не видел
>Флагами
Ну если без многопотока то в целом и похуй и даже извращаться так как я описал не нужно, но флаги все равно хуйня, методы нужны.
>>21199
ты опять обосрался, в оригинале нет этого
https://store.steampowered.com/app/1208260/Hentai_Vs_Furries/
ты опять обосрался, в оригинале нет этого
https://store.steampowered.com/app/1208260/Hentai_Vs_Furries/
>>21198
Дык ты хуйню спрашиваешь детскую, а потом ноешь лол.
Пиздец, просто пиздец.
Дык ты хуйню спрашиваешь детскую, а потом ноешь лол.
>флаги все равно хуйня, методы нужны.
Пиздец, просто пиздец.
>>21204
Я-то? Впрочем как я уже намекнул - многопоточный и однопоточный ecs это два разных ecs, с разницей не в пропасть а в Марианскую впадину. Потому тебе и непонятно что я такое изобразил, а вот другому анону понятно. Можешь вкатиться как нибудь, будет интересно.
У тебя все ещё впереди, не бери в голову.
>ноешь
Я-то? Впрочем как я уже намекнул - многопоточный и однопоточный ecs это два разных ecs, с разницей не в пропасть а в Марианскую впадину. Потому тебе и непонятно что я такое изобразил, а вот другому анону понятно. Можешь вкатиться как нибудь, будет интересно.
>Пиздец, просто пиздец.
У тебя все ещё впереди, не бери в голову.
>>21209
Я тут дополню такой момент - в некоторых ецс(лео, морпех для юнити) видел такой подход - юзаем всё как обычный однопоточный ецс, ни о чём не запариваемся, но: отдельные системы, которые не будут ни с чем конфликтовать и не предполагают каких то изменений структурных, запускаем в многопоточном режиме.
Вот бегают у тебя тысячи юнитов в стратежке например и у нас есть система которая управляет куда они бегут - и мы берём пилим это на батчи и каждый в отдельный поток пихаем. И система ждёт когда оно всё прокрутится.
Даже если их меньше 1000 всё равно профитно будет, для каких то тяжёлых штук.
Разумеется потоки все заранее созданы в нужном количестве и простаивают, и задачу сразу пилим на такое число батчей чтобы каждому поровну дать и не юзать никакую синхронизацию между ними.
Чисто с практической точки зрения это очень эффективно, потому что профит хороший и реализовать не сложно в уже сформированном наговнокоженном проекте чтобы самое жрущее место оптимизировать.
> многопоточный и однопоточный ecs это два разных ecs, с разницей не в пропасть а в Марианскую впадину
Я тут дополню такой момент - в некоторых ецс(лео, морпех для юнити) видел такой подход - юзаем всё как обычный однопоточный ецс, ни о чём не запариваемся, но: отдельные системы, которые не будут ни с чем конфликтовать и не предполагают каких то изменений структурных, запускаем в многопоточном режиме.
Вот бегают у тебя тысячи юнитов в стратежке например и у нас есть система которая управляет куда они бегут - и мы берём пилим это на батчи и каждый в отдельный поток пихаем. И система ждёт когда оно всё прокрутится.
Даже если их меньше 1000 всё равно профитно будет, для каких то тяжёлых штук.
Разумеется потоки все заранее созданы в нужном количестве и простаивают, и задачу сразу пилим на такое число батчей чтобы каждому поровну дать и не юзать никакую синхронизацию между ними.
Чисто с практической точки зрения это очень эффективно, потому что профит хороший и реализовать не сложно в уже сформированном наговнокоженном проекте чтобы самое жрущее место оптимизировать.
>>21203
Есть. Это же говнюнити.
Есть. Это же говнюнити.
>>21215
ЕЦС тут вообще не причём, это просто многопоточка. Ты больше кода пиши и меньше шизы читай.
>Вот бегают у тебя тысячи юнитов в стратежке например и у нас есть система которая управляет куда они бегут - и мы берём пилим это на батчи и каждый в отдельный поток пихаем. И система ждёт когда оно всё прокрутится.
ЕЦС тут вообще не причём, это просто многопоточка. Ты больше кода пиши и меньше шизы читай.
>>21239
ЕЦС тут причём, потому что параллелим не задачу в вакууме, а итерацию по сущностям.
ЕЦС тут причём, потому что параллелим не задачу в вакууме, а итерацию по сущностям.
>>21250
ЕЦС реализуем и без параллелизма, ты тупой походу и не знаешь о чём несёшь вообще.
ЕЦС реализуем и без параллелизма, ты тупой походу и не знаешь о чём несёшь вообще.
>>21266
Можно без параллелизма. А можно и с паралеллизмом. Можно с паралеллизмом систем. А можно с паралеллизмом в итерациях.
А ещё можно просто буквы читать научиться, либо гуглить если не понятно о чём речь.
Можно без параллелизма. А можно и с паралеллизмом. Можно с паралеллизмом систем. А можно с паралеллизмом в итерациях.
А ещё можно просто буквы читать научиться, либо гуглить если не понятно о чём речь.
>>21268
вот и начни
>А ещё можно просто буквы читать научиться, либо гуглить если не понятно о чём речь.
вот и начни
>>21266
Только ЕЦС нахуй не нужен ни с параллелизмом, не без параллелизма, потому что не подходит для геймдева. А параллелизм и без него замечательно работает.
Только ЕЦС нахуй не нужен ни с параллелизмом, не без параллелизма, потому что не подходит для геймдева. А параллелизм и без него замечательно работает.
>>21320
Аргументируешь? Однопоточный ecs самая идеальная для геймдева архитектура, хотябы потому что даёт слабосвязанность какая DI даже не снится. А поскольку нет нужды синхронизироваться - можно вертеть компонентами и сущностями как только поделаешь.
>не подходит для геймдева
Аргументируешь? Однопоточный ecs самая идеальная для геймдева архитектура, хотябы потому что даёт слабосвязанность какая DI даже не снится. А поскольку нет нужды синхронизироваться - можно вертеть компонентами и сущностями как только поделаешь.
>>21323
Так связанность мало куда денется, а вот компилятор ее уже оптимизировать не сможет.
Так связанность мало куда денется, а вот компилятор ее уже оптимизировать не сможет.
>>21323
связность есть, просто она неявная и спрятана в строгом порядке работы с данными. это накладывает кучу ограничений на архитектуру систем и приводит к непредвиденным ошибкам в других системах при рефакторинге
связность есть, просто она неявная и спрятана в строгом порядке работы с данными. это накладывает кучу ограничений на архитектуру систем и приводит к непредвиденным ошибкам в других системах при рефакторинге
>>21326
Если нет многопоточки - порядок и его строгость не имеют никакого значения, потому что нет ничего что могло бы разрушить детерминизм. А значит внутри систем можно устраивать содомию из любых логических конструкций поверх горизонтальной природы ecs, не заботясь об их устойчивости, что приводит к уменьшению их количества(систем), улучшению их читабельности и облегчает кодовую базу на компоненты-флаги и сущности-флаги.
Тут я согласен, базовые реализации ecs запрещают прямое наследование путём запрета на несколько компонентов единовременно в пределах одной сущности, но это не значит что это нерешаемая проблема. Лично я создал специальный компонент-базу данных, который позволяет легко обходить эту проблему.
Ну если следовать теории по ecs - такая ситуация просто не должна возникать, потому что на существование компонента определённого типа обычно реагирует только одна система, напрямую с ним связанная, неправильная работа 1 системы конечно может за собой потянуть остальные, но эта связь не проблема ecs, а естественная реакция архитектуры при подобном подходе, которую многие бы вписали ей в плюс. Но поскольку обсуждаем не сферический пример в вакууме, да ещё и не многопоточный - сложность поиска ошибки практически нулевая, обнаруживается немедленно и быстро устраняется, потому что нерушимый детерминизм очереди выполнения. А если не размазывать системы - ошибка локализуется ещё быстрее.
>строгом порядке
Если нет многопоточки - порядок и его строгость не имеют никакого значения, потому что нет ничего что могло бы разрушить детерминизм. А значит внутри систем можно устраивать содомию из любых логических конструкций поверх горизонтальной природы ecs, не заботясь об их устойчивости, что приводит к уменьшению их количества(систем), улучшению их читабельности и облегчает кодовую базу на компоненты-флаги и сущности-флаги.
>связность есть, просто она неявная
Тут я согласен, базовые реализации ecs запрещают прямое наследование путём запрета на несколько компонентов единовременно в пределах одной сущности, но это не значит что это нерешаемая проблема. Лично я создал специальный компонент-базу данных, который позволяет легко обходить эту проблему.
>приводит к непредвиденным ошибкам в других системах при рефакторинге
Ну если следовать теории по ecs - такая ситуация просто не должна возникать, потому что на существование компонента определённого типа обычно реагирует только одна система, напрямую с ним связанная, неправильная работа 1 системы конечно может за собой потянуть остальные, но эта связь не проблема ecs, а естественная реакция архитектуры при подобном подходе, которую многие бы вписали ей в плюс. Но поскольку обсуждаем не сферический пример в вакууме, да ещё и не многопоточный - сложность поиска ошибки практически нулевая, обнаруживается немедленно и быстро устраняется, потому что нерушимый детерминизм очереди выполнения. А если не размазывать системы - ошибка локализуется ещё быстрее.
>>21326
Ну а по поводу очевидных плюсов ecs подхода против стандартного ООП - всегда имеем легкодоступную модель данных, не требующую контейнеров, наглядное представление в памяти благодаря возможностям ecs фреймворков логгировать структуру сущностей и их графа связей через нодовую систему в красивую картинку, лёгкий способ сериализации мира, всегда легко горизонтально расширяемую архитектуру и возможность отслеживать и реагировать на любое изменение в модели данных(реакция на добавление, удаление, изменение). Всего этого можно достичь и при стандартном подходе, но это будет всякий раз велосипединг горизонтали архитектуры проекта, а DI контейнеры не обеспечивают гибкости ecs
Ну а по поводу очевидных плюсов ecs подхода против стандартного ООП - всегда имеем легкодоступную модель данных, не требующую контейнеров, наглядное представление в памяти благодаря возможностям ecs фреймворков логгировать структуру сущностей и их графа связей через нодовую систему в красивую картинку, лёгкий способ сериализации мира, всегда легко горизонтально расширяемую архитектуру и возможность отслеживать и реагировать на любое изменение в модели данных(реакция на добавление, удаление, изменение). Всего этого можно достичь и при стандартном подходе, но это будет всякий раз велосипединг горизонтали архитектуры проекта, а DI контейнеры не обеспечивают гибкости ecs
>>21333
Делакм ентити с демедж реквестом
Делаем систему которая наносит урон по демедж реквесту
Делаем систему которая спавнит партикл хита по демедж реквесту
Делаем систему которая чистит демедж реквесты
Нужен тут порядок? Или не нужен? Можно посчистить демедж реквесты сразу после создания?
> порядок и его строгость не имеют никакого значения
Делакм ентити с демедж реквестом
Делаем систему которая наносит урон по демедж реквесту
Делаем систему которая спавнит партикл хита по демедж реквесту
Делаем систему которая чистит демедж реквесты
Нужен тут порядок? Или не нужен? Можно посчистить демедж реквесты сразу после создания?
>>21335
так екс не гибкий, любой маломальский сложный проект приводит к переписыванию всего екс кода в кор и выносу за пределы екс всех систем
так екс не гибкий, любой маломальский сложный проект приводит к переписыванию всего екс кода в кор и выносу за пределы екс всех систем
>>21338
Ты эту шизу уже выше писал и просто выдумал её.
Почему у нас на проекте ничего из ецса не выночится и не переписывается?
Почему в проде куча игр на ецсе есть?
Ты эту шизу уже выше писал и просто выдумал её.
Почему у нас на проекте ничего из ецса не выночится и не переписывается?
Почему в проде куча игр на ецсе есть?
>>21333
речь о причинно-следственной связи. связность даст ошибку еще на этапе компиляции. хорошо написанный екс просто тихо пойдет по пизде, потому что связь не через ссылки, а через мысли у программиста в голове
речь о причинно-следственной связи. связность даст ошибку еще на этапе компиляции. хорошо написанный екс просто тихо пойдет по пизде, потому что связь не через ссылки, а через мысли у программиста в голове
>>21339
потому что у вас гиммик, а не екс, объяснял уже
настоящий екс пишется с нуля, без движка
ссылочку на статистику
потому что у вас гиммик, а не екс, объяснял уже
настоящий екс пишется с нуля, без движка
> почему в проде куча игр на ецсе есть?
ссылочку на статистику
>>21337
Анон описывал многопотоковый подход, и я его выше по реплаю того анона тоже описывал. Все эти промежуточные стадии - плоды попыток сделать параллелизм в рамках многопоточной среды и не обосраться, потому что я не могу просто взять и спросить сущность, а есть ли у неё такой-то компонент, потому что в тот момент когда произойдёт if(entity.has component){дальнейший код} - при выполнении дальнейшего кода может оказаться что у сущности уже нет запрашиваемого компонента, а система переходит в режим undefined behavior. Потому такая хитровыебаная цепочка действий чтобы все свести к 1 системе применяющей к здоровью эффекты наложенные этими всеми реквестами и которая монопольно управляет компонентом здоровья, но эффекты при этом могут собираться без синхронизации и в любом порядке путём создания вот такой хуйни.
Но я повторюсь, всё это нужно только в рамках многопоточной среды, в однопотоке все это можно упрощать и композировать до предела, просто потому что нет нужды выжимать параллелизм.
Анон описывал многопотоковый подход, и я его выше по реплаю того анона тоже описывал. Все эти промежуточные стадии - плоды попыток сделать параллелизм в рамках многопоточной среды и не обосраться, потому что я не могу просто взять и спросить сущность, а есть ли у неё такой-то компонент, потому что в тот момент когда произойдёт if(entity.has component){дальнейший код} - при выполнении дальнейшего кода может оказаться что у сущности уже нет запрашиваемого компонента, а система переходит в режим undefined behavior. Потому такая хитровыебаная цепочка действий чтобы все свести к 1 системе применяющей к здоровью эффекты наложенные этими всеми реквестами и которая монопольно управляет компонентом здоровья, но эффекты при этом могут собираться без синхронизации и в любом порядке путём создания вот такой хуйни.
Но я повторюсь, всё это нужно только в рамках многопоточной среды, в однопотоке все это можно упрощать и композировать до предела, просто потому что нет нужды выжимать параллелизм.
>>21340
Думаешь обычный код так не умеет? И он пойдёт по пизде ровно настолько, насколько ты залоггировал. В отличии от дерева ООП, в ecs ты можешь буквально логгировать каждый чих и каждый пук изменения модели данных, и слово каждый тут не преувеличение. Ты по логам можешь восстанавливать состояние мира буквально пошагово, действие за действием и совершенно бесплатно, без смс и без геморроя. А если захочешь помочь ecs сообществу - можешь ещё и написать аддон к какому нибудь ecs который бы мог из таких зазипленых логов восстанавливать мир и видеть ошибку в реальном времени, чего не даст сделать ни одна пиздатейшая ООП архитектура
>тихо пойдет по пизде
Думаешь обычный код так не умеет? И он пойдёт по пизде ровно настолько, насколько ты залоггировал. В отличии от дерева ООП, в ecs ты можешь буквально логгировать каждый чих и каждый пук изменения модели данных, и слово каждый тут не преувеличение. Ты по логам можешь восстанавливать состояние мира буквально пошагово, действие за действием и совершенно бесплатно, без смс и без геморроя. А если захочешь помочь ecs сообществу - можешь ещё и написать аддон к какому нибудь ecs который бы мог из таких зазипленых логов восстанавливать мир и видеть ошибку в реальном времени, чего не даст сделать ни одна пиздатейшая ООП архитектура
>>21342
Да ты нихуя не объяснил, ты в итоге слился с обсуждений гиммиковости и пошёл обсуждать перформанс, но и там неудача - когда я тебе предложил накидать псевдокод твоего гига оптимизированного решения - ты ответил кек пук.
Овервотч 2, стендофф, уже достаточно.
> потому что у вас гиммик, а не екс, объяснял уже
Да ты нихуя не объяснил, ты в итоге слился с обсуждений гиммиковости и пошёл обсуждать перформанс, но и там неудача - когда я тебе предложил накидать псевдокод твоего гига оптимизированного решения - ты ответил кек пук.
> ссылочку на статистику
Овервотч 2, стендофф, уже достаточно.
565 Кб, 1771x977>>21348
ну для начала давай список ваших систем и компонент вот так
можешь через чатгпт пропустить чтоб имена заменила синонимично
ну для начала давай список ваших систем и компонент вот так
можешь через чатгпт пропустить чтоб имена заменила синонимично
>>21337
Еще месяц назад выяснили что он пишет не на ecs, он пишет на своих костылях которые просто называет ецс, при этом если бы он просто переписал это на ооп с композицией, все работало бы быстрее, потому что он не мешал бы компилятору находить happy codepath.
Еще месяц назад выяснили что он пишет не на ecs, он пишет на своих костылях которые просто называет ецс, при этом если бы он просто переписал это на ооп с композицией, все работало бы быстрее, потому что он не мешал бы компилятору находить happy codepath.
>>21348
В овервотче было 10 на 10 игроков
В оверотче два только 5 на 5
Я ничего не путаю?
Какая то антиреклама ецс вышла.
Если что, 5 на 5 было в контрстрайке на технологиях 1999 года.
В овервотче было 10 на 10 игроков
В оверотче два только 5 на 5
Я ничего не путаю?
Какая то антиреклама ецс вышла.
Если что, 5 на 5 было в контрстрайке на технологиях 1999 года.
>>21356
Пруфы будут? Да и дело не в производительности, а в скорости разработки и степени переиспользования кода, где на мой вкус ecs нет равных, а это имхо - главные для индюка показатели крутости технологии.
>все работало бы быстрее
Пруфы будут? Да и дело не в производительности, а в скорости разработки и степени переиспользования кода, где на мой вкус ecs нет равных, а это имхо - главные для индюка показатели крутости технологии.
>>21357
Всё путаешь.
Овервотч = овервотч 2
Мы про число игроков говорим или чё?
Был тезис, что ецс не пригоден для игры, я привёл в пример успешные масштабные игры на ецс. Видимо, его непригодность для игр никак не помешала сделать успешные продукты
Всё путаешь.
Овервотч = овервотч 2
> Если что, 5 на 5 было в контрстрайке на технологиях 1999 года.
Мы про число игроков говорим или чё?
Был тезис, что ецс не пригоден для игры, я привёл в пример успешные масштабные игры на ецс. Видимо, его непригодность для игр никак не помешала сделать успешные продукты
>>21359
Да уже неоднократно приводил ассемблерные листинги, ты не читал что ли?
Переиспользование в ооп ничем отличаться не будет, у тебя же не ецс, значит ты просто можешь перенести код систем в функции объектов и все станет еще удобнее.
Да уже неоднократно приводил ассемблерные листинги, ты не читал что ли?
Переиспользование в ооп ничем отличаться не будет, у тебя же не ецс, значит ты просто можешь перенести код систем в функции объектов и все станет еще удобнее.
>>21365
Чел, 5 на 5 это не масштабная игра. Масштабная это 10000+, там где ецс имеет хоть какие то преимущества хотя бы в теории (хотя на практике их не будет).
Чел, 5 на 5 это не масштабная игра. Масштабная это 10000+, там где ецс имеет хоть какие то преимущества хотя бы в теории (хотя на практике их не будет).
>>21367
Масштабная игра или не масштабная игра это не то сколько на сколько игроков.
Это то, насколько это объемный продукт с точки зрения реализованного контента, сколько там всевозможных механик. Если много и игра поддерживается долгое время, значит видимо использованный подход с точки зрения архитектуры пригоден к расширению.
Производительность это отдельный вопрос, и могу только сказать, что для максимальной производительности на мобилках часто берут именно ецс на практике.
Масштабная игра или не масштабная игра это не то сколько на сколько игроков.
Это то, насколько это объемный продукт с точки зрения реализованного контента, сколько там всевозможных механик. Если много и игра поддерживается долгое время, значит видимо использованный подход с точки зрения архитектуры пригоден к расширению.
Производительность это отдельный вопрос, и могу только сказать, что для максимальной производительности на мобилках часто берут именно ецс на практике.
>>21366
В каком месте оно станет удобнее то? Теорема Эскобара будет. Ты не понял о каком переиспользовании речь. А речь о архитектуре проекта. В случае ООП её костяк непереносной между проектами, а значит производство каждого проекта в рамках студии становится дороже, а его рефакторинг в случае каких либо серьёзных структурных изменений (например превращение дьяблоида в пошаговую РПГ/замена поселения на ферму) - займёт куда более бешеное время, потому что придётся менять все - структуры хранения мобов, управления объектами поселения, вводить новые виды стыковок между прокачкой поселения и местом игры, пересвязывать настройки и переделывать сохранения, переделывать тесты. Тем временем в ecs достаточно модифицировать компоненты так чтобы они на уровне данных отвечали потребностям геймплея, с помощью систем имея возможность получать компоненты с сущностями готовыми по фильтрам - уже сократить работу на сшивание кусков данных для обработки и переделать системы каждая из которых не является частью сшитого монолита данные+код, которой она будет в ООП( и даже не рассказывай что не будет) а являет собой код отдельно от данных, что во-первых ограничивает бурную фантазию, а во вторых - делает все модульным и легкосвязываемым с тем, с чем связываться ранее не планировалось, ведь для связывания просто надо отредачить фильтр компонентов.
Не читал и не буду. Ну сколько там было отставание на запрос данных из массива, на полмилисекунды или на 1 милисекунду? Это все претензии по медленности ecs или ещё что-то есть? Интересует что-то более существенное чем кешмисы которые даже бюджетный современный телефон не заметит.
>перенести код систем в функции объектов и все станет еще удобнее.
В каком месте оно станет удобнее то? Теорема Эскобара будет. Ты не понял о каком переиспользовании речь. А речь о архитектуре проекта. В случае ООП её костяк непереносной между проектами, а значит производство каждого проекта в рамках студии становится дороже, а его рефакторинг в случае каких либо серьёзных структурных изменений (например превращение дьяблоида в пошаговую РПГ/замена поселения на ферму) - займёт куда более бешеное время, потому что придётся менять все - структуры хранения мобов, управления объектами поселения, вводить новые виды стыковок между прокачкой поселения и местом игры, пересвязывать настройки и переделывать сохранения, переделывать тесты. Тем временем в ecs достаточно модифицировать компоненты так чтобы они на уровне данных отвечали потребностям геймплея, с помощью систем имея возможность получать компоненты с сущностями готовыми по фильтрам - уже сократить работу на сшивание кусков данных для обработки и переделать системы каждая из которых не является частью сшитого монолита данные+код, которой она будет в ООП( и даже не рассказывай что не будет) а являет собой код отдельно от данных, что во-первых ограничивает бурную фантазию, а во вторых - делает все модульным и легкосвязываемым с тем, с чем связываться ранее не планировалось, ведь для связывания просто надо отредачить фильтр компонентов.
>Да уже неоднократно приводил ассемблерные листинги, ты не читал что ли?
Не читал и не буду. Ну сколько там было отставание на запрос данных из массива, на полмилисекунды или на 1 милисекунду? Это все претензии по медленности ecs или ещё что-то есть? Интересует что-то более существенное чем кешмисы которые даже бюджетный современный телефон не заметит.
>>21368
Так там вряд ли больше механик чем в каких нибудь древних дотах.
Вообще ничего не значит, я играю в ММО которой 20 лет и там все добавляют контент и механики, и там точно ООП. Когда большая фирма они что угодно будут поддерживать просто посадив людей. Типа было бы вообще охуеть если бы ецс не тянул даже 5 на 5, но вот с 10 на 10 уже вопросы.
Во первых слишком громкое заявление, где пруфы, где статистика, названия всех тайтлов и процентное соотношение ко всем остальным мобилкам? Во вторых, у тебя магическое мышление, поскольку ты считаешь что ецс сам по себе дает какой то прирост производительности, хотя это уже было разъебано в треде.
>Это то, насколько это объемный продукт с точки зрения реализованного контента, сколько там всевозможных механик.
Так там вряд ли больше механик чем в каких нибудь древних дотах.
>Если много и игра поддерживается долгое время, значит видимо использованный подход с точки зрения архитектуры пригоден к расширению.
Вообще ничего не значит, я играю в ММО которой 20 лет и там все добавляют контент и механики, и там точно ООП. Когда большая фирма они что угодно будут поддерживать просто посадив людей. Типа было бы вообще охуеть если бы ецс не тянул даже 5 на 5, но вот с 10 на 10 уже вопросы.
>для максимальной производительности на мобилках часто берут именно ецс на практике.
Во первых слишком громкое заявление, где пруфы, где статистика, названия всех тайтлов и процентное соотношение ко всем остальным мобилкам? Во вторых, у тебя магическое мышление, поскольку ты считаешь что ецс сам по себе дает какой то прирост производительности, хотя это уже было разъебано в треде.
>>21369
Да никак ты не превратишь дьяблоид в пошаговую игру при ецс, лол. Я именно этим и занимался, в результате проще все оказалось выкинуть и переписать. Писать пошаг на ецс это кстати тоже ад, еще один минус. Остальное какой то бред, что там у тебя такое в ооп случиться со структурой что ее нельзя скопировать в другой проект? Во-вторых у тебя в ецс будет такой же монолит, тебе сто раз уже объяснили что у тебя куча связей в порядке систем. Ну и как вишенка на торте, если у тебя телефон легко переваривает кэшмисы, то это означает что ецс вообще нахуй не нужна.
Да никак ты не превратишь дьяблоид в пошаговую игру при ецс, лол. Я именно этим и занимался, в результате проще все оказалось выкинуть и переписать. Писать пошаг на ецс это кстати тоже ад, еще один минус. Остальное какой то бред, что там у тебя такое в ооп случиться со структурой что ее нельзя скопировать в другой проект? Во-вторых у тебя в ецс будет такой же монолит, тебе сто раз уже объяснили что у тебя куча связей в порядке систем. Ну и как вишенка на торте, если у тебя телефон легко переваривает кэшмисы, то это означает что ецс вообще нахуй не нужна.
>>21369
И кстати говоря, мой спич выше все ещё про однопоточный ecs. Если вводить в строй настоящий многопоточный ecs, и не дотс с пародией на многопоточность в виде ручного управления порядком выполнения систем, а настоящий многопоток где основа обеспечения детерминизма это DbC компоненты+сущность - эта связка станет равной по производительности самому оптимизированому ООП потому что будет устранена проблема синхронизации состояний сущностей в рамках кода, фиксирующих это состояние, что даст мощный буст за счёт бесплатного для мозга многопотока из коробки, что ускорит разработку ещё сильнее, не будет сильного расхода на ожидающие блокировки и будет вся мощь фильтров по компонентам и управляемости каждым винтиком-компонентом системы в целом. Короче круто будет, а кто не верит пусть дальше изображает олдфага сколько влезет
>Да уже неоднократно приводил ассемблерные листинги, ты не читал что ли?
И кстати говоря, мой спич выше все ещё про однопоточный ecs. Если вводить в строй настоящий многопоточный ecs, и не дотс с пародией на многопоточность в виде ручного управления порядком выполнения систем, а настоящий многопоток где основа обеспечения детерминизма это DbC компоненты+сущность - эта связка станет равной по производительности самому оптимизированому ООП потому что будет устранена проблема синхронизации состояний сущностей в рамках кода, фиксирующих это состояние, что даст мощный буст за счёт бесплатного для мозга многопотока из коробки, что ускорит разработку ещё сильнее, не будет сильного расхода на ожидающие блокировки и будет вся мощь фильтров по компонентам и управляемости каждым винтиком-компонентом системы в целом. Короче круто будет, а кто не верит пусть дальше изображает олдфага сколько влезет
>>21370
Что такое дот. Дота? Ну, поиграй в овервотч, хз.
Мой тезис "на ецс можно делать игры, на нём сделаны некоторые успешные и масштабные проекты"
Твой ответ "а вот ммо 20 летенее на оопе!" - это просто сразу минус, логическая ошибка. Второй ответ "посади большую команду, они что угодно сделают" - значит ты со мной согласен, на ецс можно делать игры, а твой тезис, что нельзя, был обманом?
Жирно
Я не собираю точную статистику, я говорю что при поиске вакансий часто встречаю компании, которые делают игры на ецс. По моим ощущениям часто. Достаточно часто,
Нет, у меня как раз нет проблем с мышлением, это у тебя встречаются логические ошибки и вкладывание слов в рот сейчас например. Где я говорил что ецс сам по себе даёт буст по перформансу? Я выше в треде писал, что можно организовать код в соответствии с ецс, который под капотом будет идентичен твоему специализированному спер производительному решению.
Просто сама архитектура будет ецс, и это закладывает определенные правила написания кода, возможность переиспользовать другой ецс код и возможность изучать и применять какие то подходы в реализации механик на ецс, возможность найти разрабочиков которым код будет привычен. Т.е. чисто с практическоц точки зрения могут быть профиты.
> Так там вряд ли больше механик чем в каких нибудь древних дотах.
Что такое дот. Дота? Ну, поиграй в овервотч, хз.
> Вообще ничего не значит, я играю в ММО которой 20 лет и там все добавляют контент и механики, и там точно ООП. Когда большая фирма они что угодно будут поддерживать просто посадив людей.
Мой тезис "на ецс можно делать игры, на нём сделаны некоторые успешные и масштабные проекты"
Твой ответ "а вот ммо 20 летенее на оопе!" - это просто сразу минус, логическая ошибка. Второй ответ "посади большую команду, они что угодно сделают" - значит ты со мной согласен, на ецс можно делать игры, а твой тезис, что нельзя, был обманом?
> Типа было бы вообще охуеть если бы ецс не тянул даже 5 на 5, но вот с 10 на 10 уже вопросы.
Жирно
> Во первых слишком громкое заявление, где пруфы, где статистика, названия всех тайтлов и процентное соотношение ко всем остальным мобилкам?
Я не собираю точную статистику, я говорю что при поиске вакансий часто встречаю компании, которые делают игры на ецс. По моим ощущениям часто. Достаточно часто,
> Во вторых, у тебя магическое мышление, поскольку ты считаешь что ецс сам по себе дает какой то прирост производительности, хотя это уже было разъебано в треде.
Нет, у меня как раз нет проблем с мышлением, это у тебя встречаются логические ошибки и вкладывание слов в рот сейчас например. Где я говорил что ецс сам по себе даёт буст по перформансу? Я выше в треде писал, что можно организовать код в соответствии с ецс, который под капотом будет идентичен твоему специализированному спер производительному решению.
Просто сама архитектура будет ецс, и это закладывает определенные правила написания кода, возможность переиспользовать другой ецс код и возможность изучать и применять какие то подходы в реализации механик на ецс, возможность найти разрабочиков которым код будет привычен. Т.е. чисто с практическоц точки зрения могут быть профиты.
>>21371
АААА, так это у тебя не получилось, ну что ж, раз даже у тебя не получилось значит все ясно с этим ecs, игрушка дьявола получается.
Кек, как тут можно обосраться вообще не понимаю, даже немного любопытно.
Нету блять никаких связей в порядке систем в однопоточном ecs, ты жопой что-либо читаешь? Мне похуй в каком порядке они выполнятся потому что они всегда выполняются в одинаковом порядке и мне не нужно этот порядок никак формировать, я пишу изначально системы так чтобы они друг на друга не влияли, однопоток позволяет. Ты вообще ecs пробовал-то? Или маняфантазируешь?
>Да никак ты не превратишь дьяблоид в пошаговую игру при ецс, лол. Я именно этим и занимался, в результате проще все оказалось выкинуть и переписать.
АААА, так это у тебя не получилось, ну что ж, раз даже у тебя не получилось значит все ясно с этим ecs, игрушка дьявола получается.
>Писать пошаг на ецс это кстати тоже ад, еще один минус.
Кек, как тут можно обосраться вообще не понимаю, даже немного любопытно.
>тебе сто раз уже объяснили что у тебя куча связей в порядке систем
Нету блять никаких связей в порядке систем в однопоточном ecs, ты жопой что-либо читаешь? Мне похуй в каком порядке они выполнятся потому что они всегда выполняются в одинаковом порядке и мне не нужно этот порядок никак формировать, я пишу изначально системы так чтобы они друг на друга не влияли, однопоток позволяет. Ты вообще ecs пробовал-то? Или маняфантазируешь?
>>21371
Я хз как упороться надо, чтобы писать пошаговую игру на ецс, лол. Давай еще суп вилкой есть а потом пиздеть что вилка хуйня.
Это очень решается продуманными группами систем и определением порядка групп.
Другими словами, задача переноса ецс кода из одно проекта в другой заключается в определении порядка систем и всё, остальное копипаст без изменений.
Довольно низкая цена, не?
> ты не превратишь дьяблоид в пошаговую игру при ецс, лол. Я именно этим и занимался, в результате проще все оказалось выкинуть и переписать.
Я хз как упороться надо, чтобы писать пошаговую игру на ецс, лол. Давай еще суп вилкой есть а потом пиздеть что вилка хуйня.
> Во-вторых у тебя в ецс будет такой же монолит, тебе сто раз уже объяснили что у тебя куча связей в порядке систем.
Это очень решается продуманными группами систем и определением порядка групп.
Другими словами, задача переноса ецс кода из одно проекта в другой заключается в определении порядка систем и всё, остальное копипаст без изменений.
Довольно низкая цена, не?
>>21375
Думаю, он говорит про ситуации в стиле - одна система хочет иметь результат другой чтобы на него отреагировать.
Например насрал ванфрейм ивентами и почистил - и есть система которой они нужны, и она должна отработать до очистки ван фрнймов.
Но решается это проблема не сложно.
> Нету блять никаких связей в порядке систем в однопоточном ecs, ты жопой что-либо читаешь? Мне похуй в каком порядке они выполнятся потому что они всегда выполняются в одинаковом порядке и мне не нужно этот порядок никак формировать, я пишу изначально системы так чтобы они друг на друга не влияли, однопоток позволяет. Ты вообще ecs пробовал-то? Или маняфантазируешь?
Думаю, он говорит про ситуации в стиле - одна система хочет иметь результат другой чтобы на него отреагировать.
Например насрал ванфрейм ивентами и почистил - и есть система которой они нужны, и она должна отработать до очистки ван фрнймов.
Но решается это проблема не сложно.
>>21377
Тогда стоит следовать старому мудрому правилу - действовать согласно теории. А согласно теории - систем делающих разные действия относительно одного и того же набора данных быть не должно. А если таковых систем не будет - не придётся решать роняя кал подобные проблемы.
>Например насрал ванфрейм ивентами и почистил - и есть система которой они нужны, и она должна отработать до очистки ван фрнймов.
Тогда стоит следовать старому мудрому правилу - действовать согласно теории. А согласно теории - систем делающих разные действия относительно одного и того же набора данных быть не должно. А если таковых систем не будет - не придётся решать роняя кал подобные проблемы.
>>21374
У тебя постоянно логическая ошибка на ошибке, например: ты пишешь что я где-то писал, что на ецс невозможно сделать игру - а я писал, что ецс не пригоден для использования игр. Ну вот например некоторые и в Экселе игры делают, (да собственно я на какой то твг отправлял game of life в гуглдоках) но это не значит что он для них пригоден.
Или например, из того что ейчарка вписала новый очередной баззворд в вакансию, ты делаешь вывод что ецс реально используется на работе в этой фирме. Ну и так далее.
У тебя постоянно логическая ошибка на ошибке, например: ты пишешь что я где-то писал, что на ецс невозможно сделать игру - а я писал, что ецс не пригоден для использования игр. Ну вот например некоторые и в Экселе игры делают, (да собственно я на какой то твг отправлял game of life в гуглдоках) но это не значит что он для них пригоден.
Или например, из того что ейчарка вписала новый очередной баззворд в вакансию, ты делаешь вывод что ецс реально используется на работе в этой фирме. Ну и так далее.
>>21378
Это невозможно в любой хоть сколько то нетривиальной игре. Ну вот банально говоря о пошаговой игре - есть урон от атак, есть урон от дебаффа, есть урон от окружения, есть регенерация, вот и приехали.
Это невозможно в любой хоть сколько то нетривиальной игре. Ну вот банально говоря о пошаговой игре - есть урон от атак, есть урон от дебаффа, есть урон от окружения, есть регенерация, вот и приехали.
>>21377
События - это еще одно слабое место ецс. Которое хуево сочетается с параллелизмом и кэш локальностью.
События - это еще одно слабое место ецс. Которое хуево сочетается с параллелизмом и кэш локальностью.
ООП не ООП, это гиммик
настощий ООП только в smalltalk
настощий ООП только в smalltalk
>>21384
А ещё можно создать компонент, хранящий эффекты-делегаты с метаданными времени последнего применения под временные дебафы, применяемые одной системой. А напихивать туда делегаты можно прям из игрового процесса, потому что ecs отработает в конце кадра, ведь я надеюсь ты не пишешь на ecs всё, включая игровое представление сущностей? Если пишешь то ты сам себе злобный Буратино конечно. На dots таким заниматься можно, но на то он и dots
>есть урон от атак, есть урон от дебаффа, есть урон от окружения, есть регенерация
А ещё можно создать компонент, хранящий эффекты-делегаты с метаданными времени последнего применения под временные дебафы, применяемые одной системой. А напихивать туда делегаты можно прям из игрового процесса, потому что ecs отработает в конце кадра, ведь я надеюсь ты не пишешь на ecs всё, включая игровое представление сущностей? Если пишешь то ты сам себе злобный Буратино конечно. На dots таким заниматься можно, но на то он и dots
>>21385
Если я правильно помню - событий в ecs нет вообще, entity components system как бы. События это придумка как подружить ужа с ежом в виде клиента-сервера или ecs ядра мира и mvc его представления игроку, которая в dots отсутствует по причине ненадобности.
>События - это еще одно слабое место ецс. Которое хуево сочетается с параллелизмом и кэш локальностью.
Если я правильно помню - событий в ecs нет вообще, entity components system как бы. События это придумка как подружить ужа с ежом в виде клиента-сервера или ecs ядра мира и mvc его представления игроку, которая в dots отсутствует по причине ненадобности.
>>21165
Параллакс и бамп, очевидно же. Печально, что на волосах артефакты дизеринга. Это автоматически значит, что весь графон в игре проклят и будет гостинг, блюр и полный пиздос. Но судя по текстуре чела с банкой, количество аккумулируемых кадров и биасы выставлены на минимум. Не идеально тоже, но лучше так. Судя по плоской нигерше на заднем плане, с освещением тоже полный пиздец. Края теней рваные, то есть это рендеринг карты глубины из камеры, а не RT.
Параллакс и бамп, очевидно же. Печально, что на волосах артефакты дизеринга. Это автоматически значит, что весь графон в игре проклят и будет гостинг, блюр и полный пиздос. Но судя по текстуре чела с банкой, количество аккумулируемых кадров и биасы выставлены на минимум. Не идеально тоже, но лучше так. Судя по плоской нигерше на заднем плане, с освещением тоже полный пиздец. Края теней рваные, то есть это рендеринг карты глубины из камеры, а не RT.
поедите ли на фесты движков?
Unity Industry User Day | May 14th | Brighton, UK
Nordic Game 2025 | May 20th - 23rd | Malmö, Sweden
Unreal Fest 2025 | June 2nd - 5th | Orlando, USA
Game Access Conference | June 6th - 7th | Brno, Czech Republic
AWE 2025 | June 10th - 12th | California, USA
Unity Industry User Day | May 14th | Brighton, UK
Nordic Game 2025 | May 20th - 23rd | Malmö, Sweden
Unreal Fest 2025 | June 2nd - 5th | Orlando, USA
Game Access Conference | June 6th - 7th | Brno, Czech Republic
AWE 2025 | June 10th - 12th | California, USA
>>21392
Ну так ты сам подвтвердил что ецс не подходит для игровых сущностей, то есть не подходит для разработки игр.
Ну так ты сам подвтвердил что ецс не подходит для игровых сущностей, то есть не подходит для разработки игр.
Что то меня заебало делать движок. Слишком много проблем если делать универсальный.
>>21383
Это была бы не логическая, а фактическая ошибка.
Ведь ошибка заключается не построении логики, а в превирании факта с мрей стороны.
Но в данном случае это даже не фактическая ошибка, а дрочь терминологии. "Не возможно", "Не пригоден".
Совершенно очевидно что я отвечаю не с точки зрения физической возможности делать игры на ецс(это и иак понятно что что угодно можно сделать), а с точки зрения практической жизнеспомобности написания игры на ецс(слово пригоден, как ты выше написал).
Если тебе было не очевидно(что странно, ведь явно мы не физическую возможность сделать игру на ецс обсуждали, что обсуждать было бы бессмысленно, ясен хуй ответ да, пвторюсь), то я сейчас тебе это говорю.
Пока что 100% соответствия на моей прратике(т.е. у меня инфа не только исходя из прочтения вакансий). Даде больше - иногда на ецс пишут там, где ецс в вакансии не упомянут.
Отдельно отмечу, что ецс в требованиях сужает воронку кандидатов, как базз ворд не лучшая идея.
> У тебя постоянно логическая ошибка на ошибке, например: ты пишешь что я где-то писал, что на ецс невозможно сделать игру - а я писал, что ецс не пригоден для использования игр
Это была бы не логическая, а фактическая ошибка.
Ведь ошибка заключается не построении логики, а в превирании факта с мрей стороны.
Но в данном случае это даже не фактическая ошибка, а дрочь терминологии. "Не возможно", "Не пригоден".
Совершенно очевидно что я отвечаю не с точки зрения физической возможности делать игры на ецс(это и иак понятно что что угодно можно сделать), а с точки зрения практической жизнеспомобности написания игры на ецс(слово пригоден, как ты выше написал).
Если тебе было не очевидно(что странно, ведь явно мы не физическую возможность сделать игру на ецс обсуждали, что обсуждать было бы бессмысленно, ясен хуй ответ да, пвторюсь), то я сейчас тебе это говорю.
> Или например, из того что ейчарка вписала новый очередной баззворд в вакансию, ты делаешь вывод что ецс реально используется на работе в этой фирме.
Пока что 100% соответствия на моей прратике(т.е. у меня инфа не только исходя из прочтения вакансий). Даде больше - иногда на ецс пишут там, где ецс в вакансии не упомянут.
Отдельно отмечу, что ецс в требованиях сужает воронку кандидатов, как базз ворд не лучшая идея.
>>21385
Блиннн 5% игровой логики без параллелизма и кеш локальностиэто вообше пиздежь к слову
>>21394
А? Нет. Чтобы подрузить ецс ядро с чем то никакие события не неоьходимы. И уж события в терминологии ецс(компоненты живущие 1 кадр) точно не нужны
Блиннн 5% игровой логики без параллелизма и кеш локальностиэто вообше пиздежь к слову
>>21394
> События это придумка как подружить ужа с ежом в виде клиента-сервера или ecs ядра мира и mvc его представления игроку
А? Нет. Чтобы подрузить ецс ядро с чем то никакие события не неоьходимы. И уж события в терминологии ецс(компоненты живущие 1 кадр) точно не нужны
>>21414
даже в Томск?
даже в Томск?
>>21412
Да у меня нет цели никого убеждать, лол) Сидите дрочите свой mvc или mvvm или контейнеры или собственные велосипеды или что вы там дрочите, декомпозируйте, пишите интерфейсы и занимайтесь прочим говнецом. Ты в очередной раз отказываешься читать буквы, не пытаешься вникнуть в какие виды ecs бывают, зачем они бывают. Конечно, я тебя отлично понимаю, на данный момент технология не коробочная совершенно(дотс), требует усилий, детские болячки не решены в большинстве либ, требуется экспертиза, а читать мануалы по ecs с официальной теорией вообще вредно для продукта. Но я уже решил все её проблемы, осталась только одна - моё решение ещё не доведено до совершенства(нету асинхронщины, только потоки, библиотека не раздроблена на части и не готова к plug and play, не готова к web билдам) и я бы и хотел показать что ecs может быть другим, но к сожалению не сегодня и не сейчас. А сейчас может и правда учитывая специфику и ограниченность большинства либ по функционалу стоит писать по старинке, если ты не хочешь вникать в особенности приготовления ecs проектов и изобретать подходы к агрегации данных в рамках ecs. Но даже в моём решении чтобы писать интерфейс на ecs - надо быть олигофреном. Даже управление представлениями сущностей я лучше отдам на откуп движку, чем буду совать его в ecs, потому что не нужно намеренно стрелять себе в ногу и забивать гвозди микроскопом. Такое разделение удобно, просто надо понять как его приготовить и не обосраться.
Да у меня нет цели никого убеждать, лол) Сидите дрочите свой mvc или mvvm или контейнеры или собственные велосипеды или что вы там дрочите, декомпозируйте, пишите интерфейсы и занимайтесь прочим говнецом. Ты в очередной раз отказываешься читать буквы, не пытаешься вникнуть в какие виды ecs бывают, зачем они бывают. Конечно, я тебя отлично понимаю, на данный момент технология не коробочная совершенно(дотс), требует усилий, детские болячки не решены в большинстве либ, требуется экспертиза, а читать мануалы по ecs с официальной теорией вообще вредно для продукта. Но я уже решил все её проблемы, осталась только одна - моё решение ещё не доведено до совершенства(нету асинхронщины, только потоки, библиотека не раздроблена на части и не готова к plug and play, не готова к web билдам) и я бы и хотел показать что ecs может быть другим, но к сожалению не сегодня и не сейчас. А сейчас может и правда учитывая специфику и ограниченность большинства либ по функционалу стоит писать по старинке, если ты не хочешь вникать в особенности приготовления ecs проектов и изобретать подходы к агрегации данных в рамках ecs. Но даже в моём решении чтобы писать интерфейс на ecs - надо быть олигофреном. Даже управление представлениями сущностей я лучше отдам на откуп движку, чем буду совать его в ecs, потому что не нужно намеренно стрелять себе в ногу и забивать гвозди микроскопом. Такое разделение удобно, просто надо понять как его приготовить и не обосраться.
>>21419
А ну давай, расскажи как ты будешь сигнализировать клиенту о том что мир изменился, или как клиент будет давать понять серверу что что-то произошло в локальном ecs. Как оттранслируешь локальный инпут клиента другим членам сессии?
>А? Нет. Чтобы подрузить ецс ядро с чем то никакие события не неоьходимы.
А ну давай, расскажи как ты будешь сигнализировать клиенту о том что мир изменился, или как клиент будет давать понять серверу что что-то произошло в локальном ecs. Как оттранслируешь локальный инпут клиента другим членам сессии?
637 Кб, 852x1344>>21427
в бразилии
в бразилии
36 Кб, 1016x249>>21427
В США.
В США.
950 Кб, 1600x1600в следующем году ФлешКон в Воронеже >>968613 (OP)
>>21408
хули там делать?
хули там делать?
>>21422
Че за рандомный набор слов.
Обычно на уровне инфраструктуры ецса нетворк поддерживают.
SendToServer()
ReceiveDataFromServer()
Что ты вообще под событиями подразумеваешь? Мне кажется ты сам выдумал этому какой-то смысл, сам вложил слова мне какие то и сам споришь с выдуманной тобой же позицией.
Че за рандомный набор слов.
> А ну давай, расскажи как ты будешь сигнализировать клиенту о том что мир изменился
Обычно на уровне инфраструктуры ецса нетворк поддерживают.
> или как клиент будет давать понять серверу что что-то произошло в локальном ecs.
SendToServer()
>Как оттранслируешь локальный инпут клиента другим членам сессии?
ReceiveDataFromServer()
Что ты вообще под событиями подразумеваешь? Мне кажется ты сам выдумал этому какой-то смысл, сам вложил слова мне какие то и сам споришь с выдуманной тобой же позицией.
>>21463
Хуйню они поддерживают. Как сделать так чтобы компонент здоровья конкретной сущности увидел один набор клиентских сущностей, а второй набор его не увидел?
Вот, можешь ознакомиться что они там поддерживают
https://github.com/RevenantX/LiteEntitySystem
Не будешь ли так любезен расшифровать для меня аббревиатуру RPC? Или объяснить разницу между RPC и событиями.
Ты же никогда не делал мультиплеер ecs, да? Угу, примерно так будет называться событие/процедура, прилетающая с сервера и приносящая обновление локального мира и обратно, но не только они будут существовать. К примеру я у себя инпут синхронизирую в обход ecs, потому что так тупо быстрее и никакая йоба ecs синхронизация не сможет ее обогнать, а саму ecs обновляю постфактум.
>Обычно на уровне инфраструктуры ецса нетворк поддерживают.
Хуйню они поддерживают. Как сделать так чтобы компонент здоровья конкретной сущности увидел один набор клиентских сущностей, а второй набор его не увидел?
>Что ты вообще под событиями подразумеваешь?
Вот, можешь ознакомиться что они там поддерживают
https://github.com/RevenantX/LiteEntitySystem
Не будешь ли так любезен расшифровать для меня аббревиатуру RPC? Или объяснить разницу между RPC и событиями.
>ReceiveDataFromServer()
>SendToServer()
Ты же никогда не делал мультиплеер ecs, да? Угу, примерно так будет называться событие/процедура, прилетающая с сервера и приносящая обновление локального мира и обратно, но не только они будут существовать. К примеру я у себя инпут синхронизирую в обход ecs, потому что так тупо быстрее и никакая йоба ecs синхронизация не сможет ее обогнать, а саму ecs обновляю постфактум.
>>21469
Хз, у тебя каша в голове.
Смотри о чем был разговор
>>21377
>>21385
И тут в контексте этого внезапно ты начинаешь что то срать про мультиплеер и рпц. Причем выше еще говорил что то про мвц. Я просто хуй знает что это, к чему это.
Отличный вопрос, у меня есть вопрос еще лучше - откуда у тебя вообще такой вопрос встал?
>>21469
Про детерминизм и роллбеки не слышал?
Хз, у тебя каша в голове.
Смотри о чем был разговор
>>21377
> Думаю, он говорит про ситуации в стиле - одна система хочет иметь результат другой чтобы на него отреагировать.
> Например насрал ванфрейм ивентами и почистил - и есть система которой они нужны, и она должна отработать до очистки ван фрнймов.
>>21385
> События - это еще одно слабое место ецс. Которое хуево сочетается с параллелизмом и кэш локальностью.
И тут в контексте этого внезапно ты начинаешь что то срать про мультиплеер и рпц. Причем выше еще говорил что то про мвц. Я просто хуй знает что это, к чему это.
> Или объяснить разницу между RPC и событиями.
Отличный вопрос, у меня есть вопрос еще лучше - откуда у тебя вообще такой вопрос встал?
>>21469
> К примеру я у себя инпут синхронизирую в обход ecs, потому что так тупо быстрее и никакая йоба ecs синхронизация не сможет ее обогнать, а саму ecs обновляю постфактум.
Про детерминизм и роллбеки не слышал?
>>21473
Ладно
Про потребность синхронизировать инпут в рамках 10мс-пинг_клиентов_мс у всех клиентов сессии слышал? Или на вопрос про 200мс лаг инпута будешь про роллбеки рассказывать?
>Хз, у тебя каша в голове. мням пук
Ладно
>Про детерминизм и роллбеки не слышал?
Про потребность синхронизировать инпут в рамках 10мс-пинг_клиентов_мс у всех клиентов сессии слышал? Или на вопрос про 200мс лаг инпута будешь про роллбеки рассказывать?
>>21478
Что?
Что?
Я не понимаю, ты жирно тралешь или что? Игра работает локально полностью детерминированно, на сераер шлется инпут игроков с временными метками, с сервера приходят все инпуты с временными метками, при несоответствии предикту делается откат и ресимулияции с новвм инпутом.
Я хуй знает что тут у тебя за особая магия с инпутом в обход ецс и какой оно выигрышь дает(никакой), я хуй знает что за шизу ты несешь тут, возможно ты просто криво выражаешься(что вполне ожидаемо по тому как ты с ван фрейм компонентов ввел терсин собвтия, а потом забыл про ван фрецм компоненты и стал говорить что события это как рпц но не рпц, я хз че ты несешь)
> Про потребность синхронизировать инпут в рамках 10мс-пинг_клиентов_мс у всех клиентов сессии слышал?
Что?
> Или на вопрос про 200мс лаг инпута будешь про роллбеки рассказывать?
Что?
Я не понимаю, ты жирно тралешь или что? Игра работает локально полностью детерминированно, на сераер шлется инпут игроков с временными метками, с сервера приходят все инпуты с временными метками, при несоответствии предикту делается откат и ресимулияции с новвм инпутом.
Я хуй знает что тут у тебя за особая магия с инпутом в обход ецс и какой оно выигрышь дает(никакой), я хуй знает что за шизу ты несешь тут, возможно ты просто криво выражаешься(что вполне ожидаемо по тому как ты с ван фрейм компонентов ввел терсин собвтия, а потом забыл про ван фрецм компоненты и стал говорить что события это как рпц но не рпц, я хз че ты несешь)
Сетевой екс двиг и как он работает
https://www.photonengine.com/quantum
https://www.photonengine.com/quantum
>>21479
Не хочу скатываться в "ты тралиш, нет ты тралиш", лучше просто ответь, делал ли сетевой ecs и если да то какой? Просто любопытно.
Не хочу скатываться в "ты тралиш, нет ты тралиш", лучше просто ответь, делал ли сетевой ecs и если да то какой? Просто любопытно.
До сих пор находятся люди, которые не понимают ецс? Пиздец просто, сто лет прошло. Давно пора признать, что ецс это не для людей сделано. Даёт профит в производительности игры? Отлично, делаешь системы на ецс, оборачиваешь поверх адекватным ооп, работаешь. Всё. Другого применения для него нет.
>>21482
Не дает. Нет реального сценария где ецс дал бы ускорение. Он хорош только в синтетическом бенчмарке где ничего не происходит. Если у тебя меньше 10000 однотипных юнитов - ускорения нет. Если у тебя юниты с каким то сложным поведением или сильно различаются по компонентам - ускорения нет. Если у тебя вообще что-то больше чем тривиальная логика - появляется связность, начинает хериться кэш и ускорения нет. Хочешь события - они убивают ускорение. Если ты пишешь по тру ецс, то ускорение съедается необходимостью постоянно перетасовывать массивы компонентов добавлением-удалением. Если ты начинаешь костылять, у тебя получается самодельный недо-ооп, который будет медленнее оопа, потому что компилятор не может эффективно оптимизировать то, что относится к разным компонентам, но разным энтитям. И бонусом у тебя нет вменяемого дебага, вместо него портянки логов компонентов, нет сетевого роллбека, тебе надо костылять вместо удаления отдельное хранилище (и опять перетасосвывать массивчики).
Все что надо знать - ецс непригоден для разработки игр, никакой производительности он не дает, но некоторые начали использовать его как маркетинговый баззворд, когда это намного эффективнее было бы сделать просто на ООП + SoA.
Не дает. Нет реального сценария где ецс дал бы ускорение. Он хорош только в синтетическом бенчмарке где ничего не происходит. Если у тебя меньше 10000 однотипных юнитов - ускорения нет. Если у тебя юниты с каким то сложным поведением или сильно различаются по компонентам - ускорения нет. Если у тебя вообще что-то больше чем тривиальная логика - появляется связность, начинает хериться кэш и ускорения нет. Хочешь события - они убивают ускорение. Если ты пишешь по тру ецс, то ускорение съедается необходимостью постоянно перетасовывать массивы компонентов добавлением-удалением. Если ты начинаешь костылять, у тебя получается самодельный недо-ооп, который будет медленнее оопа, потому что компилятор не может эффективно оптимизировать то, что относится к разным компонентам, но разным энтитям. И бонусом у тебя нет вменяемого дебага, вместо него портянки логов компонентов, нет сетевого роллбека, тебе надо костылять вместо удаления отдельное хранилище (и опять перетасосвывать массивчики).
Все что надо знать - ецс непригоден для разработки игр, никакой производительности он не дает, но некоторые начали использовать его как маркетинговый баззворд, когда это намного эффективнее было бы сделать просто на ООП + SoA.
>>21485
А с ооп и соа есть?)
> Если у тебя вообще что-то больше чем тривиальная логика - появляется связность, начинает хериться кэш и ускорения нет.
А с ооп и соа есть?)
>>21485
Я на долбоёба похож делать 10к юнитов не на хаках гпу? Оно всё равно сдохнет.
>10000 однотипных юнитов
Я на долбоёба похож делать 10к юнитов не на хаках гпу? Оно всё равно сдохнет.
>>21489
Сколько максимум программистов над игрой однвоременно работали? Много из этих игр были на ооп + соа? На ецс игры делал сам или в команде?
> 50+ по работе, 20 своих, 2 на ецс.
Сколько максимум программистов над игрой однвоременно работали? Много из этих игр были на ооп + соа? На ецс игры делал сам или в команде?
>>21493
К чему этот вопрос? Программистов 7-9 максимум в одном офисе, но все же обычно разделение по направлениям по 1-2 чела. На ооп были все, лол. Соа - как оптимизация, да. На ецс делал сам чтобы посмотреть а чего это за технология которую все пиарят, потыкал прототипы на entt, flecs, еще каких то, кажется gaia и entityX, на шарпах entitas и leo (еще старую), до свельто уже не добрался поскольку к этому времени убедился что ецс говно, поискал сообщения разных программеров из крупных студий и они пишут в целом то же самое, после чего и плюнул.
К чему этот вопрос? Программистов 7-9 максимум в одном офисе, но все же обычно разделение по направлениям по 1-2 чела. На ооп были все, лол. Соа - как оптимизация, да. На ецс делал сам чтобы посмотреть а чего это за технология которую все пиарят, потыкал прототипы на entt, flecs, еще каких то, кажется gaia и entityX, на шарпах entitas и leo (еще старую), до свельто уже не добрался поскольку к этому времени убедился что ецс говно, поискал сообщения разных программеров из крупных студий и они пишут в целом то же самое, после чего и плюнул.
>>21489
Но я и не собираюсь делать это для десяти тысяч юнитов, я же не долбоёб. Если прямо нужно подсчитать движение для роя, то я подсчитаю N путей и буду их использовать каждый раз с разбросом либо усреднением.
>ты же не собираешься игровую логику там считать (бафы-дебафы-аое урон-бихевиор три)
Но я и не собираюсь делать это для десяти тысяч юнитов, я же не долбоёб. Если прямо нужно подсчитать движение для роя, то я подсчитаю N путей и буду их использовать каждый раз с разбросом либо усреднением.
>>21496
Ну пути это пути, не говоря о том что если динамическое окружение, как часто у тебя пути перестанут быть актуальными. А про геймплей, со сплешами от аое взрывов то что будешь делать?
Ну пути это пути, не говоря о том что если динамическое окружение, как часто у тебя пути перестанут быть актуальными. А про геймплей, со сплешами от аое взрывов то что будешь делать?
>>21498
Но имея десять тысяч юнитов мне всё ещё не нужно иметь десять тысяч путей. Десять, не больше. Даже если окружение процедурно изменяется каждый кадр, это остаётся неизменным.
Скорее всего предварительно рассчитаю поля расстояний для юнитов и буду использовать их почти бесплатно. Либо буду использовать вычислительный шейдер на гпу, там это просчитается за полнаносекунды даже для десяти тысяч объектов.
>часто у тебя пути перестанут быть актуальными.
Но имея десять тысяч юнитов мне всё ещё не нужно иметь десять тысяч путей. Десять, не больше. Даже если окружение процедурно изменяется каждый кадр, это остаётся неизменным.
>со сплешами от аое взрывов
Скорее всего предварительно рассчитаю поля расстояний для юнитов и буду использовать их почти бесплатно. Либо буду использовать вычислительный шейдер на гпу, там это просчитается за полнаносекунды даже для десяти тысяч объектов.
>>21499
Во первых я тебе написал что на мобилке гпу не будет за полнаносекунды считать.
Во вторых ну посчитаешь ты что-то на гпу, тебе надо еще это на цпу перегнать чтобы сохранить новые значения хп. Или ты собрался всю игру на гпу писать, лол?
Во первых я тебе написал что на мобилке гпу не будет за полнаносекунды считать.
Во вторых ну посчитаешь ты что-то на гпу, тебе надо еще это на цпу перегнать чтобы сохранить новые значения хп. Или ты собрался всю игру на гпу писать, лол?
>>21503
Так я же не конченный идиот делать 10 тысяч объектов на мобилке. Там это не вывезет ничего - ни цпу, ни гпу. Сомневаюсь, что даже рендер 10 тысяч объектов на экране будет работать со вменяемой скоростью. Так что мобилки можно не рассматривать вообще.
Вычислительные шейдеры для этого и существуют.
>на мобилке
Так я же не конченный идиот делать 10 тысяч объектов на мобилке. Там это не вывезет ничего - ни цпу, ни гпу. Сомневаюсь, что даже рендер 10 тысяч объектов на экране будет работать со вменяемой скоростью. Так что мобилки можно не рассматривать вообще.
>это на цпу перегнать
Вычислительные шейдеры для этого и существуют.
>>21504
Принято.
Вообще то максимальный прирост будет если возвращать на цпу ничего не надо, и передавать результат уже дальше в графический шейдер для отображения.
>не нужно
Принято.
>Вычислительные шейдеры для этого и существуют.
Вообще то максимальный прирост будет если возвращать на цпу ничего не надо, и передавать результат уже дальше в графический шейдер для отображения.
>>21506
Может, и не нужно - хуй ты увидишь 10к объектов на экране мобилки. Но речь не о том. Такое количество "честных" объектов убьёт мобилку, рендер не вывезет, даже если логика будет оптимизирована.
Да я в курсе, но хп всё равно нужно как-то возвращать. Чисто в теории можно дамаг наносить на текстуру и в фоне гонять между цп и гпу, будет быстро. Если ещё запечь анимации в текстуры, то в цпу и возвращать не придётся. Но здесь гпу мобилки уже обосрётся, потому что ветвления + тысячи объектов.
>>не нужно
Может, и не нужно - хуй ты увидишь 10к объектов на экране мобилки. Но речь не о том. Такое количество "честных" объектов убьёт мобилку, рендер не вывезет, даже если логика будет оптимизирована.
>максимальный прирост будет если возвращать на цпу ничего не надо
Да я в курсе, но хп всё равно нужно как-то возвращать. Чисто в теории можно дамаг наносить на текстуру и в фоне гонять между цп и гпу, будет быстро. Если ещё запечь анимации в текстуры, то в цпу и возвращать не придётся. Но здесь гпу мобилки уже обосрётся, потому что ветвления + тысячи объектов.
68 Кб, 814x739>соа
это хватит для эффективного использования этого паттерна? никогда им не пользовался
6 Кб, 481x255>>21554
Тебе нейрокалич какую то другую херню расшифровал.
Ну вот например https://github.com/Cysharp/StructureOfArraysGenerator
Тебе нейрокалич какую то другую херню расшифровал.
Ну вот например https://github.com/Cysharp/StructureOfArraysGenerator
>>21561
Если бы ты хотел игру сделать, взял бы Годот,
а на говнюнити ты ничего не сделаешь, будешь просто хаб взад вперед переустанавливать.
Если бы ты хотел игру сделать, взял бы Годот,
а на говнюнити ты ничего не сделаешь, будешь просто хаб взад вперед переустанавливать.
Как же я ненавижу темпоральные эффекты. Написал скрипт, который уничтожает темпоральное накопление для RT теней просто потому, что я их ненавижу. Хуже всего в этом планет уринал энжин, он без темпоральных эффектов не работает вообще.
>>21562
А зачем переустанавливать хаб? Я его как установил где-то в 2018 году, так и не удалял. К тому же, им не обязательно пользоваться.
А зачем переустанавливать хаб? Я его как установил где-то в 2018 году, так и не удалял. К тому же, им не обязательно пользоваться.
>>21628
У меня только за год дважды слетал логин, а без логина и без лицензии ты получишь дулю вместо редактора. Так что без хаба никуда.
У меня только за год дважды слетал логин, а без логина и без лицензии ты получишь дулю вместо редактора. Так что без хаба никуда.
>>21627
Годот удали сразу полюбишь
Годот удали сразу полюбишь
>>21631
Таков печальный удел Юнити-петуха, если завтра в eula добавят пункт, что для доступа к хабу нужно выслать фото с флажком в анусе, ты грустно вздохнешь и пойдешь выполнять.
Таков печальный удел Юнити-петуха, если завтра в eula добавят пункт, что для доступа к хабу нужно выслать фото с флажком в анусе, ты грустно вздохнешь и пойдешь выполнять.
>>21686
делай игры и играй в них, зачем тебе стим?
делай игры и играй в них, зачем тебе стим?
>>21686
Откуда у тебя время играть в игры? Я вот с трудом нахожу час-другой после работы поковырять анрил/блендер, ни о каких играх речи не идет, хотя бывает хочется во что-то залипнуть, но понимаю что тогда вообще ничего не буду успевать
Откуда у тебя время играть в игры? Я вот с трудом нахожу час-другой после работы поковырять анрил/блендер, ни о каких играх речи не идет, хотя бывает хочется во что-то залипнуть, но понимаю что тогда вообще ничего не буду успевать
У меня нет времени на написание движка, я должен программировать и зарабатывать бабки
>>21717
Кстати, одна из самых успешных инди-игр от отечественных разработчиков. По деньгам наверное квартиру в Мухосрани можно с такой прибыли купить.
Я сам даже играл и ничего не тормозило. Скорее всего это старый билд в котором автор не прикрутил оклюжн куллинг к стенам зданий и прочей геометрии и десятки мобов тупо рендерятся пока их не видно. Но он все починил после того как игра взлетела.
Кстати, одна из самых успешных инди-игр от отечественных разработчиков. По деньгам наверное квартиру в Мухосрани можно с такой прибыли купить.
Я сам даже играл и ничего не тормозило. Скорее всего это старый билд в котором автор не прикрутил оклюжн куллинг к стенам зданий и прочей геометрии и десятки мобов тупо рендерятся пока их не видно. Но он все починил после того как игра взлетела.
>>21717
У этой игры в стиме отзывов столько, что годоти даже если в голема соберутся не соберут столько.
Это судьба годота - быть пропукивающим и никому не нужным. А игры на юнити даже с пропуком купят. Тем более что пофиксить все изи.
>Не хрюнити
У этой игры в стиме отзывов столько, что годоти даже если в голема соберутся не соберут столько.
Это судьба годота - быть пропукивающим и никому не нужным. А игры на юнити даже с пропуком купят. Тем более что пофиксить все изи.
>>21721
Это даже не близко к успеху.
> Кстати, одна из самых успешных инди-игр от отечественных разработчиков. По деньгам наверное квартиру в Мухосрани можно с такой прибыли купить.
Это даже не близко к успеху.
>>21727
Так это норм игра, хоть и на годоте.
Много таких популярных игр на годоте как круелти? Единицы скорее.
А на юнити процент таких игр больше в разы.
ENA: Dream BBQ вышла в этом году, и отзывов уже больше чем у Круелти.
Так это норм игра, хоть и на годоте.
Много таких популярных игр на годоте как круелти? Единицы скорее.
А на юнити процент таких игр больше в разы.
ENA: Dream BBQ вышла в этом году, и отзывов уже больше чем у Круелти.
>>21669 (Del)
Годот такое не потянет.
Годот такое не потянет.
>>21720
Я из вкусвилла ем готовое как правило, а завтраки просто готовить. Убирается клининг. За сексом хожу по шлюхам. Вот так и живу.
Я из вкусвилла ем готовое как правило, а завтраки просто готовить. Убирается клининг. За сексом хожу по шлюхам. Вот так и живу.
Sup, срачеры /gd/. Более уместного треда для своего вопроса я не нашёл, так что извините, если не туда и в глаза ебусь.
К сути. Ищу простой движок под свою хотелку. 31 годик, гуманитарий к технарю 80/20, нулевой опыт кодинга и работы с движками. Есть та самая ИДЕЯ, есть навык чтения и письма, есть потребность рассказывать истории. Хочу сделать свою условно простенькую, текстовую сюжетную РПГ/адвенчуру без лишних изъёбств. Осознаю свою ничтожность перед силой кода, потому запросы имею весьма скромные:
- возможность более-менее наглядно (для себя) создавать ветвистые сюжетные цепочки с выбором вариантов кнопочками при минимальном знании языков вроде C# и Java (в идеале, вообще без);
- удобное отслеживание выборов, переменных, статистик, желательно "из коробки" или простым способом, чтобы даже я смог реализовать всякие там проверки, простую настройку имени/внешности игрового персонажа как пример;
- человеческий UI с возможностью настройки кнопочек и менюшек криворуким аутистом, и вообще презентация игры на уровне чуть повыше, чем старые текстовые квесты и "choose your own adventure" книжки.
Необязательные, но приятные хотелки:
- примитивный ролевой элемент прокачки, левелапа, статы-навыки как простые проверки на их наличие в сценах, без рандома;
- возможность малой кровью добавить 2D графику уровня визуальных новелл, cutouts/задники/карту, если вдруг получится их сделать.
Да-да, я не шутил, я абсолютный хлебушек. Мои запросы - очевидный примитив, но как хлебушку мне хотелось бы меньше ебать себе мозги изучением кода, вижу в этом лишь необходимый инструмент. Готов осваивать азы по мере необходимости, но сомневаюсь, что смогу эффективно сделать что-то сложнее диалоговых скриптов. Думать о вещах вроде полноценной формульной боёвки, пошаговки по клеточкам, мини-игр мне в одиночку бессмысленно, помощи тоже не будет, потому для первой попытки масштаб ставлю минимальным. Интерактивный фикшен/RPG. Отталкиваюсь от своих сильных сторон - начитанный, могу писать тексты, прописывать персонажей и сюжеты. English is not a problem.
В курсе текстовых движков типа Twine, попробовал самые популярные текстовки на нём, но там видимо прям совсем спартанские возможности. Боюсь, часть моих хотелок будет работать только через костыли (ролевой элемент), часть вообще не будет (возможная в моих мечтах графика), UI хотелось бы более дружелюбный, а охват публики даже с моими несуществующими целями будет единичный.
Юнити наверняка перебор, разве что там есть простецкие готовые шаблоны для всего того, что мне нужно. Что остаётся? RenPy? Godot? PRGМахеры? Свой вариант? Что анон считает более дружелюбным движком под простые игрушки, для абсолютного казуала?
О целях, для контекста: планов на монетизацию нет никаких, только свободный доступ, к раскрутке дальше форумов и борд тоже не стремлюсь. Зачем делаю? Потому что. Надоело пробивать лицо рукой от типичных сюжетов, персонажей всяких визуальных новелл, текстовых RPG. Всегда хотел реализовать внутреннего рассказчика. В идеале смогу из этого сделать достойную демку своих навыков, чтобы было, что показать в будущем возможным единомышленникам или с чем постучаться в чей-то проект на правах хобби.
И конечно, я как-нибудь справлюсь с поисками и без Двача. Но было бы приятно услышать обоснованное мнение уважаемых людей. Может, кто-то забавлялся подобным или видел готовую реализацию.
К сути. Ищу простой движок под свою хотелку. 31 годик, гуманитарий к технарю 80/20, нулевой опыт кодинга и работы с движками. Есть та самая ИДЕЯ, есть навык чтения и письма, есть потребность рассказывать истории. Хочу сделать свою условно простенькую, текстовую сюжетную РПГ/адвенчуру без лишних изъёбств. Осознаю свою ничтожность перед силой кода, потому запросы имею весьма скромные:
- возможность более-менее наглядно (для себя) создавать ветвистые сюжетные цепочки с выбором вариантов кнопочками при минимальном знании языков вроде C# и Java (в идеале, вообще без);
- удобное отслеживание выборов, переменных, статистик, желательно "из коробки" или простым способом, чтобы даже я смог реализовать всякие там проверки, простую настройку имени/внешности игрового персонажа как пример;
- человеческий UI с возможностью настройки кнопочек и менюшек криворуким аутистом, и вообще презентация игры на уровне чуть повыше, чем старые текстовые квесты и "choose your own adventure" книжки.
Необязательные, но приятные хотелки:
- примитивный ролевой элемент прокачки, левелапа, статы-навыки как простые проверки на их наличие в сценах, без рандома;
- возможность малой кровью добавить 2D графику уровня визуальных новелл, cutouts/задники/карту, если вдруг получится их сделать.
Да-да, я не шутил, я абсолютный хлебушек. Мои запросы - очевидный примитив, но как хлебушку мне хотелось бы меньше ебать себе мозги изучением кода, вижу в этом лишь необходимый инструмент. Готов осваивать азы по мере необходимости, но сомневаюсь, что смогу эффективно сделать что-то сложнее диалоговых скриптов. Думать о вещах вроде полноценной формульной боёвки, пошаговки по клеточкам, мини-игр мне в одиночку бессмысленно, помощи тоже не будет, потому для первой попытки масштаб ставлю минимальным. Интерактивный фикшен/RPG. Отталкиваюсь от своих сильных сторон - начитанный, могу писать тексты, прописывать персонажей и сюжеты. English is not a problem.
В курсе текстовых движков типа Twine, попробовал самые популярные текстовки на нём, но там видимо прям совсем спартанские возможности. Боюсь, часть моих хотелок будет работать только через костыли (ролевой элемент), часть вообще не будет (возможная в моих мечтах графика), UI хотелось бы более дружелюбный, а охват публики даже с моими несуществующими целями будет единичный.
Юнити наверняка перебор, разве что там есть простецкие готовые шаблоны для всего того, что мне нужно. Что остаётся? RenPy? Godot? PRGМахеры? Свой вариант? Что анон считает более дружелюбным движком под простые игрушки, для абсолютного казуала?
О целях, для контекста: планов на монетизацию нет никаких, только свободный доступ, к раскрутке дальше форумов и борд тоже не стремлюсь. Зачем делаю? Потому что. Надоело пробивать лицо рукой от типичных сюжетов, персонажей всяких визуальных новелл, текстовых RPG. Всегда хотел реализовать внутреннего рассказчика. В идеале смогу из этого сделать достойную демку своих навыков, чтобы было, что показать в будущем возможным единомышленникам или с чем постучаться в чей-то проект на правах хобби.
И конечно, я как-нибудь справлюсь с поисками и без Двача. Но было бы приятно услышать обоснованное мнение уважаемых людей. Может, кто-то забавлялся подобным или видел готовую реализацию.
Sup, срачеры /gd/. Более уместного треда для своего вопроса я не нашёл, так что извините, если не туда и в глаза ебусь.
К сути. Ищу простой движок под свою хотелку. 31 годик, гуманитарий к технарю 80/20, нулевой опыт кодинга и работы с движками. Есть та самая ИДЕЯ, есть навык чтения и письма, есть потребность рассказывать истории. Хочу сделать свою условно простенькую, текстовую сюжетную РПГ/адвенчуру без лишних изъёбств. Осознаю свою ничтожность перед силой кода, потому запросы имею весьма скромные:
- возможность более-менее наглядно (для себя) создавать ветвистые сюжетные цепочки с выбором вариантов кнопочками при минимальном знании языков вроде C# и Java (в идеале, вообще без);
- удобное отслеживание выборов, переменных, статистик, желательно "из коробки" или простым способом, чтобы даже я смог реализовать всякие там проверки, простую настройку имени/внешности игрового персонажа как пример;
- человеческий UI с возможностью настройки кнопочек и менюшек криворуким аутистом, и вообще презентация игры на уровне чуть повыше, чем старые текстовые квесты и "choose your own adventure" книжки.
Необязательные, но приятные хотелки:
- примитивный ролевой элемент прокачки, левелапа, статы-навыки как простые проверки на их наличие в сценах, без рандома;
- возможность малой кровью добавить 2D графику уровня визуальных новелл, cutouts/задники/карту, если вдруг получится их сделать.
Да-да, я не шутил, я абсолютный хлебушек. Мои запросы - очевидный примитив, но как хлебушку мне хотелось бы меньше ебать себе мозги изучением кода, вижу в этом лишь необходимый инструмент. Готов осваивать азы по мере необходимости, но сомневаюсь, что смогу эффективно сделать что-то сложнее диалоговых скриптов. Думать о вещах вроде полноценной формульной боёвки, пошаговки по клеточкам, мини-игр мне в одиночку бессмысленно, помощи тоже не будет, потому для первой попытки масштаб ставлю минимальным. Интерактивный фикшен/RPG. Отталкиваюсь от своих сильных сторон - начитанный, могу писать тексты, прописывать персонажей и сюжеты. English is not a problem.
В курсе текстовых движков типа Twine, попробовал самые популярные текстовки на нём, но там видимо прям совсем спартанские возможности. Боюсь, часть моих хотелок будет работать только через костыли (ролевой элемент), часть вообще не будет (возможная в моих мечтах графика), UI хотелось бы более дружелюбный, а охват публики даже с моими несуществующими целями будет единичный.
Юнити наверняка перебор, разве что там есть простецкие готовые шаблоны для всего того, что мне нужно. Что остаётся? RenPy? Godot? PRGМахеры? Свой вариант? Что анон считает более дружелюбным движком под простые игрушки, для абсолютного казуала?
О целях, для контекста: планов на монетизацию нет никаких, только свободный доступ, к раскрутке дальше форумов и борд тоже не стремлюсь. Зачем делаю? Потому что. Надоело пробивать лицо рукой от типичных сюжетов, персонажей всяких визуальных новелл, текстовых RPG. Всегда хотел реализовать внутреннего рассказчика. В идеале смогу из этого сделать достойную демку своих навыков, чтобы было, что показать в будущем возможным единомышленникам или с чем постучаться в чей-то проект на правах хобби.
И конечно, я как-нибудь справлюсь с поисками и без Двача. Но было бы приятно услышать обоснованное мнение уважаемых людей. Может, кто-то забавлялся подобным или видел готовую реализацию.
К сути. Ищу простой движок под свою хотелку. 31 годик, гуманитарий к технарю 80/20, нулевой опыт кодинга и работы с движками. Есть та самая ИДЕЯ, есть навык чтения и письма, есть потребность рассказывать истории. Хочу сделать свою условно простенькую, текстовую сюжетную РПГ/адвенчуру без лишних изъёбств. Осознаю свою ничтожность перед силой кода, потому запросы имею весьма скромные:
- возможность более-менее наглядно (для себя) создавать ветвистые сюжетные цепочки с выбором вариантов кнопочками при минимальном знании языков вроде C# и Java (в идеале, вообще без);
- удобное отслеживание выборов, переменных, статистик, желательно "из коробки" или простым способом, чтобы даже я смог реализовать всякие там проверки, простую настройку имени/внешности игрового персонажа как пример;
- человеческий UI с возможностью настройки кнопочек и менюшек криворуким аутистом, и вообще презентация игры на уровне чуть повыше, чем старые текстовые квесты и "choose your own adventure" книжки.
Необязательные, но приятные хотелки:
- примитивный ролевой элемент прокачки, левелапа, статы-навыки как простые проверки на их наличие в сценах, без рандома;
- возможность малой кровью добавить 2D графику уровня визуальных новелл, cutouts/задники/карту, если вдруг получится их сделать.
Да-да, я не шутил, я абсолютный хлебушек. Мои запросы - очевидный примитив, но как хлебушку мне хотелось бы меньше ебать себе мозги изучением кода, вижу в этом лишь необходимый инструмент. Готов осваивать азы по мере необходимости, но сомневаюсь, что смогу эффективно сделать что-то сложнее диалоговых скриптов. Думать о вещах вроде полноценной формульной боёвки, пошаговки по клеточкам, мини-игр мне в одиночку бессмысленно, помощи тоже не будет, потому для первой попытки масштаб ставлю минимальным. Интерактивный фикшен/RPG. Отталкиваюсь от своих сильных сторон - начитанный, могу писать тексты, прописывать персонажей и сюжеты. English is not a problem.
В курсе текстовых движков типа Twine, попробовал самые популярные текстовки на нём, но там видимо прям совсем спартанские возможности. Боюсь, часть моих хотелок будет работать только через костыли (ролевой элемент), часть вообще не будет (возможная в моих мечтах графика), UI хотелось бы более дружелюбный, а охват публики даже с моими несуществующими целями будет единичный.
Юнити наверняка перебор, разве что там есть простецкие готовые шаблоны для всего того, что мне нужно. Что остаётся? RenPy? Godot? PRGМахеры? Свой вариант? Что анон считает более дружелюбным движком под простые игрушки, для абсолютного казуала?
О целях, для контекста: планов на монетизацию нет никаких, только свободный доступ, к раскрутке дальше форумов и борд тоже не стремлюсь. Зачем делаю? Потому что. Надоело пробивать лицо рукой от типичных сюжетов, персонажей всяких визуальных новелл, текстовых RPG. Всегда хотел реализовать внутреннего рассказчика. В идеале смогу из этого сделать достойную демку своих навыков, чтобы было, что показать в будущем возможным единомышленникам или с чем постучаться в чей-то проект на правах хобби.
И конечно, я как-нибудь справлюсь с поисками и без Двача. Но было бы приятно услышать обоснованное мнение уважаемых людей. Может, кто-то забавлялся подобным или видел готовую реализацию.
>>21741
Ren py - 100%. Тупо из-за количества гайдов для него.
Мб tuesday js, но на нём вроде нет серьезных игр.
Ren py - 100%. Тупо из-за количества гайдов для него.
Мб tuesday js, но на нём вроде нет серьезных игр.
>>21734
Так на годоте игр мало, значит и процент успешных выше.
И твоя игра на Годоте может стать мега успешной.
Так на годоте игр мало, значит и процент успешных выше.
И твоя игра на Годоте может стать мега успешной.
>>21741
Ну да, там все довольно просто разобраться. В РАЗЫ проще чем в юнити. И туториалы намного более качественные.
>Godot
Ну да, там все довольно просто разобраться. В РАЗЫ проще чем в юнити. И туториалы намного более качественные.
>>21741
Я случайно удалил гитхаб с кодом своего движка. Лолллл
Он был говном, но как раз для лёгких игр. А так конечно лучше Рен пи если ты полный 0. Тупо напиши best visual novel rpg engine.
>Свой вариант
Я случайно удалил гитхаб с кодом своего движка. Лолллл
Он был говном, но как раз для лёгких игр. А так конечно лучше Рен пи если ты полный 0. Тупо напиши best visual novel rpg engine.
>>21741
Unity + Yarn - это даст все возможности хрюнпи, но ты неограничен питухоном и хрюнпи, а значит можно создать буквально что угодно
>текстовую сюжетную РПГ/адвенчуру
Unity + Yarn - это даст все возможности хрюнпи, но ты неограничен питухоном и хрюнпи, а значит можно создать буквально что угодно
единственная проблема - придётся самим писать API для вызова функций из ярна
>>21761
пытался воспользоваться ярном да так и забил. мне кажется, не-кодеру будет сложно в этом ярне разобраться
я в итоге написал свою систему диалогов с node-редактором, но я ж программист
если ваша игра чисто нарративная, сделайте сначала прототип истории в каком-нибудь Twine или любом РПГ-мейкере, даже самом древнем
пытался воспользоваться ярном да так и забил. мне кажется, не-кодеру будет сложно в этом ярне разобраться
я в итоге написал свою систему диалогов с node-редактором, но я ж программист
если ваша игра чисто нарративная, сделайте сначала прототип истории в каком-нибудь Twine или любом РПГ-мейкере, даже самом древнем
187 Кб, 1324x730ещё и версия 3 вышла 13 часов назад - это судьба
https://github.com/YarnSpinnerTool/YarnSpinner/releases
https://github.com/YarnSpinnerTool/YarnSpinner/releases
>>21742
>>21749
>>21753
>>21754
>>21760
>>21761
>>21765
>>21781
>>21813
Честно, не ожидал с десяток адекватных ответов и примечаний. Добра всем и чаю с пироженками, ну или пива с мясом.
Пока накидываю сами нарративные ветки, персонажей, наверное рискну свободным временем и попробую поковырять Unity + Yarn. Я же не совсем тупенький, вдруг справлюсь? Опыт будет полезен в будущем, мне кажется. Если нет, то всегда остаются Godot и RenPy. Twine для прототипа тоже хорошая мысль, уже думал об этом.
>>21749
>>21753
>>21754
>>21760
>>21761
>>21765
>>21781
>>21813
Честно, не ожидал с десяток адекватных ответов и примечаний. Добра всем и чаю с пироженками, ну или пива с мясом.
Пока накидываю сами нарративные ветки, персонажей, наверное рискну свободным временем и попробую поковырять Unity + Yarn. Я же не совсем тупенький, вдруг справлюсь? Опыт будет полезен в будущем, мне кажется. Если нет, то всегда остаются Godot и RenPy. Twine для прототипа тоже хорошая мысль, уже думал об этом.
>>21741
вот это еще глянь. имхо идеальный инструмент для твоих задач
https://instead.hugeping.ru
а еще прикольно, что от нашего разраба
вот это еще глянь. имхо идеальный инструмент для твоих задач
https://instead.hugeping.ru
а еще прикольно, что от нашего разраба
>>21878
Да, норм, аросто юзай чат гпт или дип сик, это очень сильная вещь для новичков, прям вбивай любые вопросы, он в целом приемлимо подскажет и по коду и по разумности каких то реализаций
> Пока накидываю сами нарративные ветки, персонажей, наверное рискну свободным временем и попробую поковырять Unity + Yarn. Я же не совсем тупенький, вдруг справлюсь?
Да, норм, аросто юзай чат гпт или дип сик, это очень сильная вещь для новичков, прям вбивай любые вопросы, он в целом приемлимо подскажет и по коду и по разумности каких то реализаций
126 Кб, 600x593>>21923
Шикарная весчь для написания прототипа.
Шикарная весчь для написания прототипа.
>>21925
Какой содомит эту обложку приделал.
Какой содомит эту обложку приделал.
38 Кб, 1003x118насколько пиздатая фича?
>>21945
Но не для всех
Но не для всех
>>22028
Пять лет назад ты легко мог играть в фортнайт. А сейчас даже не факт, что он вообще запустится. RT ядер нет, так что будет фоллбек люмена на софтварный RT. А нанит просто уничтожит твою пропускную способность. Короче с твоей видюхой в КП2077 поиграть, чем в это.
>>22029
Ох уж этот коупинг.
>у меня 960, ебало моё представил?
Пять лет назад ты легко мог играть в фортнайт. А сейчас даже не факт, что он вообще запустится. RT ядер нет, так что будет фоллбек люмена на софтварный RT. А нанит просто уничтожит твою пропускную способность. Короче с твоей видюхой в КП2077 поиграть, чем в это.
>>22029
Ох уж этот коупинг.
>>22030
нанит на мобилках работает, какой люмен?
то есть ты не в курсе, что мониторинг делает дропы? значит ты просто некомпетентен
нанит на мобилках работает, какой люмен?
>коупинг
то есть ты не в курсе, что мониторинг делает дропы? значит ты просто некомпетентен
>>22031
фикс. в общем, ни нанит, ни люмен не являются обязательной фичей рендера
>фортнит на мобилках работает, какой люмен?
фикс. в общем, ни нанит, ни люмен не являются обязательной фичей рендера
>>22029
это годот дропы делает, 100%
я заметил, что годот даже если не запущен, а просто лежит в папке, то тихонько подсирает всем приложениям и делает пропуки
у меня было две версии годота - третья и четвёртая, соответственно, пропуков в 2 раза больше
только когда я удалил годоты и почистил реестр, дропы прекратились
это годот дропы делает, 100%
я заметил, что годот даже если не запущен, а просто лежит в папке, то тихонько подсирает всем приложениям и делает пропуки
у меня было две версии годота - третья и четвёртая, соответственно, пропуков в 2 раза больше
только когда я удалил годоты и почистил реестр, дропы прекратились
3,8 Мб, 3046x1713>>22033
Задокументированное явление. Старайтесь не устанавливать годот даже из любопытства. Одна установка и ваш компьютер скомпрометирован навсегда.
Задокументированное явление. Старайтесь не устанавливать годот даже из любопытства. Одна установка и ваш компьютер скомпрометирован навсегда.
98 Кб, 850x850>>22042
Грязные инсинуации!
Грязные инсинуации!
>>22042
Опять годот в штаны говна залил, чтож такое....
>Засирает комп юнити хабами и эпик ланчерами, которые буквально были пойманы за руку постоянными сливами данных барину
Опять годот в штаны говна залил, чтож такое....
>>22050
Это другое, пынямать надо
Это другое, пынямать надо
если интересно кому и кто хочет поиграть с ярном, базовый хороший семпл
https://github.com/desplesda/YarnSpinnerDialogueInterruptions/tree/main/Assets/Samples/Yarn%20Spinner/3.0.0-beta1/Samples
https://github.com/desplesda/YarnSpinnerDialogueInterruptions/tree/main/Assets/Samples/Yarn%20Spinner/3.0.0-beta1/Samples
Какое ставить разрешение игрового экрана? 16 9? На компе выглядит нормально, на мобиле черные полосы (логично).
Если поставить 21 9, то часть экрана отрезается.
Если поставить 21 9, то часть экрана отрезается.
>>22126
Адаптивное.
Адаптивное.
>>22153
Да пох, он для говдота, а им никто не пользуется. Для юнити твоего говнодиалоджика нет.
Да пох, он для говдота, а им никто не пользуется. Для юнити твоего говнодиалоджика нет.
>>22156
это самая обычная игра на юнити использующая ярн, покажи теперь что-то близкое на хрюдоте
https://steamdb.info/app/1562430/
это самая обычная игра на юнити использующая ярн, покажи теперь что-то близкое на хрюдоте
https://steamdb.info/app/1562430/
>>22189
Да ни при каком разрешении черных полос быть не должно, вот и думай в эту сторону. Чем их заполнить.
Да ни при каком разрешении черных полос быть не должно, вот и думай в эту сторону. Чем их заполнить.
>>22157
могу показать самую обычную игру на юнити, использующую Articy Draft - Disco Elysium
а что может показать хрюдот? хрюкающего волка?
могу показать самую обычную игру на юнити, использующую Articy Draft - Disco Elysium
а что может показать хрюдот? хрюкающего волка?
>>22207
и разрабы выбрали идти по пути наименьшего сопротивления, почему хрюдоти так не могут - загадка
и разрабы выбрали идти по пути наименьшего сопротивления, почему хрюдоти так не могут - загадка
30 Кб, 1241x168>>22239
и подрубили йоба-фреймворк на 999 гигабайт, вместо того, чтобы написать 3 строчки кода? лол!
и подрубили йоба-фреймворк на 999 гигабайт, вместо того, чтобы написать 3 строчки кода? лол!
>>22247
ты щас любое приложение на телефон, а на компуктере это не критично, сколько юнити, сколько уринал тянут говна за собой, которое невозможно отключить и которое возможно никогда даже не будет использовано
>и подрубили йоба-фреймворк на 999 гигабайт
ты щас любое приложение на телефон, а на компуктере это не критично, сколько юнити, сколько уринал тянут говна за собой, которое невозможно отключить и которое возможно никогда даже не будет использовано
Покажите игру на говдоти с диалогами уровня Диско Элизиум.
Казалось бы, ещё в играх 80-ых годов были диалоги, неужели говдот не может в технологии 40-летней давности?
Казалось бы, ещё в играх 80-ых годов были диалоги, неужели говдот не может в технологии 40-летней давности?
>>22254
чтоб были простыни соевой каломании? такого нет. на годоте выпускают только базированные игры типа хрюкающего волка, энвайронмент сторителлингом, который не нуждается в диалогах
чтоб были простыни соевой каломании? такого нет. на годоте выпускают только базированные игры типа хрюкающего волка, энвайронмент сторителлингом, который не нуждается в диалогах
>>21923
ты читал?
-Все сгенерированные активы и скрипты будут содержать метаданные (т.е. данные EXIF), которые указывают: "Этот актив был сгенерирован с помощью ИИ"
-Ваша ответственность заключается в том, чтобы определить соответствующие декларации на основе ИИ для магазинов приложений, платформ распространения и конечных пользователей, когда вы отправляете коммерческий проект, использующий генеративный ИИ.
Model and Provide
GPT-series from Azure Open AI Services
GPT-models are used at various stages in the Assistant pipeline.
Llama-series from Meta Platforms, Inc
за результат будешь им авторские отчислять?
как регулируется (лицензируеться) контент?
представь ебало когда стим или сонька не пропустит?
хуй знает короч
ты читал?
-Все сгенерированные активы и скрипты будут содержать метаданные (т.е. данные EXIF), которые указывают: "Этот актив был сгенерирован с помощью ИИ"
-Ваша ответственность заключается в том, чтобы определить соответствующие декларации на основе ИИ для магазинов приложений, платформ распространения и конечных пользователей, когда вы отправляете коммерческий проект, использующий генеративный ИИ.
Model and Provide
GPT-series from Azure Open AI Services
GPT-models are used at various stages in the Assistant pipeline.
Llama-series from Meta Platforms, Inc
за результат будешь им авторские отчислять?
как регулируется (лицензируеться) контент?
представь ебало когда стим или сонька не пропустит?
хуй знает короч
>>22261
они не пропускали когда только нейро бум начался, щас они уже анально и юридически подготовились и стали пропускать
>представь ебало когда стим
они не пропускали когда только нейро бум начался, щас они уже анально и юридически подготовились и стали пропускать
>>22263
всегда пропускали. один раз удолили какой-то слоп, явно сгенерированный нелицензионной нейромоделью
всегда пропускали. один раз удолили какой-то слоп, явно сгенерированный нелицензионной нейромоделью
>>22261
А с какой радости? Продукция ИИ не может иметь какие либо копирайты, уже четырежды обсосаная и высранная тема. И весь этот текст это Филькина грамота которой можно постараться, потому что те кто тренируют или в противном случае будут обязаны доказать владение над всеми входными данными датасета, что невозможно.
>за результат будешь им авторские отчислять?
А с какой радости? Продукция ИИ не может иметь какие либо копирайты, уже четырежды обсосаная и высранная тема. И весь этот текст это Филькина грамота которой можно постараться, потому что те кто тренируют или в противном случае будут обязаны доказать владение над всеми входными данными датасета, что невозможно.
>>22261
тут просто прописано, что это твоя обязанность явно указать использование ИИ на площадках, которые этого требуют
копирайт на сам контент принадлежит тебе
тут просто прописано, что это твоя обязанность явно указать использование ИИ на площадках, которые этого требуют
копирайт на сам контент принадлежит тебе
220 Кб, 1295x942Хотите шутку?
Пидарас прискакал в годот-тред, его там проткнули и он заткнулся. Хаха!
Пидарас прискакал в годот-тред, его там проткнули и он заткнулся. Хаха!
>>22408
Мне - похуй
Я делю и хочу делать игры ради денег и искусства, я умею программировать, но я не программист, я не хочу и мне не нужно делать свой движок, это застопорит меня и никак мне не поможет достигнуть моих целей, я беру уже готовое и меняю под себя, а если ты ещё сбилдил свою игру в на юнити в моно - я спизжу и твой код
>нахрюк жирного порка
Мне - похуй
Я делю и хочу делать игры ради денег и искусства, я умею программировать, но я не программист, я не хочу и мне не нужно делать свой движок, это застопорит меня и никак мне не поможет достигнуть моих целей, я беру уже готовое и меняю под себя, а если ты ещё сбилдил свою игру в на юнити в моно - я спизжу и твой код
>>22414
Это правда, в Годоте оно охуенное.
Это правда, в Годоте оно охуенное.
>>22404
Коробочный неткод везде говно. Фотон не просто так существует. А, на годоте его ж нет. Ну тем хуже годоту, тогда действительно кроме ёбли вручную через .net core как шизик написал делать нечего.
Коробочный неткод везде говно. Фотон не просто так существует. А, на годоте его ж нет. Ну тем хуже годоту, тогда действительно кроме ёбли вручную через .net core как шизик написал делать нечего.
>>22408
Все так и есть. Я уже 5й движок делаю.
Проебался с 4м психанал и удалил часть движка, а она нужная.
Так что сейчас буду делать 5й, но мелкий. Мини сайз. Только база для веб игр. Быстро сделаю пошаговую стратегию.
Все так и есть. Я уже 5й движок делаю.
Проебался с 4м психанал и удалил часть движка, а она нужная.
Так что сейчас буду делать 5й, но мелкий. Мини сайз. Только база для веб игр. Быстро сделаю пошаговую стратегию.
Мой тир лист.
1. Unity
2. Unreal
3. Godot
Что-то может новое появилось, чтобы годот вообще из тир листа ушёл?
1. Unity
2. Unreal
3. Godot
Что-то может новое появилось, чтобы годот вообще из тир листа ушёл?
>>22427
Очередная проприетарная залупа где тебе отключат лицензию, нахуй надо.
Есть селфхостед SpacetimeDB
Есть обычный аддон неткода на гдскрипте, и никакой нет кор не понадобится.
Очередная проприетарная залупа где тебе отключат лицензию, нахуй надо.
Есть селфхостед SpacetimeDB
Есть обычный аддон неткода на гдскрипте, и никакой нет кор не понадобится.
>>22430
Мой топ за последние лет 20:
1. Dark Basic
2. RPG Maker 2000/XP
3. AGS
4. Game maker
5. Unity
Defold и Cocos Creator смотрятся неплохо для небольших игр и веба, но пока не убийцы.
Мой топ за последние лет 20:
1. Dark Basic
2. RPG Maker 2000/XP
3. AGS
4. Game maker
5. Unity
Defold и Cocos Creator смотрятся неплохо для небольших игр и веба, но пока не убийцы.
>>22432
Свидетель отзыва лицензий юнити, ты?
Свидетель отзыва лицензий юнити, ты?
>>22412
Сценаристика такого слова нет не имеет. Имеет выбор движка менеджментом или инди-разработчиком: этот движок имеет такие и такие инструменты, с ним удобно будет делать такие диалоги, вот примеры выпущенных игр.
Кстати, ZaUm распался аж на 5 команд и они сейчас делают 5 идейных продолжений DE. Сколько из них на годоте?
Сценаристика такого слова нет не имеет. Имеет выбор движка менеджментом или инди-разработчиком: этот движок имеет такие и такие инструменты, с ним удобно будет делать такие диалоги, вот примеры выпущенных игр.
Кстати, ZaUm распался аж на 5 команд и они сейчас делают 5 идейных продолжений DE. Сколько из них на годоте?
Я вспомнил, почему на годоте нет игр с большими диалогами. Там каждая буква рендерится отдельным дроу коллом, тексты уровня DE годот просто не сможет отрисовать.
120 Кб, 764x879вот эта дота на минималках использует миррор, для юнити можно найти не один десяток сетевых движков, у хрюдота такого богатства - никогда не будет
https://store.steampowered.com/app/2790090/Sirocco/
https://store.steampowered.com/app/2790090/Sirocco/
>>22427
А чем хуже? У годота свой фотон есть, ENet называется. Не говоря о том что у шарпа самого сетевых либ столько что можно обмазываться и дрочить и без фотона, есть еще кому денег дать за матчмейкинг, не говоря о том что эта хуйня нужна только мобильным сессионкам, потому что на пк шалун с читенжином начнет обнулять всем кайф. Как годот наконец дочинит мобильные проблемы - придут разрабы а значит и фотон тоже портируют, так что заглядывайте позже.
Мимо шарпист со скрина со своим неткод велосипедом
>Ну тем хуже годоту
А чем хуже? У годота свой фотон есть, ENet называется. Не говоря о том что у шарпа самого сетевых либ столько что можно обмазываться и дрочить и без фотона, есть еще кому денег дать за матчмейкинг, не говоря о том что эта хуйня нужна только мобильным сессионкам, потому что на пк шалун с читенжином начнет обнулять всем кайф. Как годот наконец дочинит мобильные проблемы - придут разрабы а значит и фотон тоже портируют, так что заглядывайте позже.
Мимо шарпист со скрина со своим неткод велосипедом
>>22440
не придут, юнити - это стабильность проверенная годами
>Как годот наконец дочинит мобильные проблемы - придут разрабы
не придут, юнити - это стабильность проверенная годами
>>22441
А дно у этой стабильности есть? А то что ни год то снизу стучит. Впрочем для могильного гейминга и правда хорош, остальное на урине лучше делать, а как годот дочинится - посмотрим на битву жабы с гадюкой
>не придут, юнити - это стабильность проверенная годами
А дно у этой стабильности есть? А то что ни год то снизу стучит. Впрочем для могильного гейминга и правда хорош, остальное на урине лучше делать, а как годот дочинится - посмотрим на битву жабы с гадюкой
>>22443
Если годот вдруг чудом "дочнинится", он станет проприетарным, лол. Годотькам останется форкать последний паблик релиз с пропуками и менять лого.
Если годот вдруг чудом "дочнинится", он станет проприетарным, лол. Годотькам останется форкать последний паблик релиз с пропуками и менять лого.
Просто нахуй пизда. Представьте себе, что пишете вы шейдер. Обычный такой DX11\12 шейдеркод, сначала семплинг текстр из буферов рендера, потом два кернела - один для вычислений, второй для генерации текстуры. Всё нормально. Начинаешь отладку. Сука, какой-то глитч, когда небольшое изменение положения камеры разъёбывает твой эффект в говно. Проверяешь матрицы. Всё ок. Проверяешь математику. Всё хорошо. Меняешь функции на другие, с более сложной логикой. Там всё тоже нормально. Но глитч, сука, он как мразь, он никуда не девается и ебёт тебе мозги. Проверяешь десятый раз. Твой код уже засран миллиардом закомментированных строк и десятками функций, которые были опробованы - и не помогли. Уровень опизденевания невозможно измерить, ты готов рвать волосы на заднице. Все цифры сходятся, всё должно быть хорошо.
И всё просто заканчивается, когда понимаешь, что глитч этот не касается рендера игровой камерой. У неё всё идентичное с камерой сцены, от клипов до матриц. Но глитч есть в сцене - и его нет в игре.
Вот за такие вещи я одновременно люблю движок - он позволяет мне это делать. Но и ненавижу, потому что под капотом там какой-то ёбаный пиздец, который понять блядь невозможно, нужно запомнить.
И всё просто заканчивается, когда понимаешь, что глитч этот не касается рендера игровой камерой. У неё всё идентичное с камерой сцены, от клипов до матриц. Но глитч есть в сцене - и его нет в игре.
Вот за такие вещи я одновременно люблю движок - он позволяет мне это делать. Но и ненавижу, потому что под капотом там какой-то ёбаный пиздец, который понять блядь невозможно, нужно запомнить.
>>22451
На ПК он уже дочинился ещё с 3.6, разве что в 4 пока турбулентность из-за потока фич, как заморозятся на переход к 5 годоту - станет стабильным, как сейчас тройка. Сижу на тройке моно, полёт нормальный. Не могу сказать что у движка уровень юньки по удобству, но в целом пользоваться приятно, если нет желания связываться с юнькой и достаточно мозгов чтобы хотябы читать код движка. Движок бля бздодь в хорошем смысле, но не без ньюансов, а по поводу возможности закрыться за пейволом - ну мей би, жаль будет.
На ПК он уже дочинился ещё с 3.6, разве что в 4 пока турбулентность из-за потока фич, как заморозятся на переход к 5 годоту - станет стабильным, как сейчас тройка. Сижу на тройке моно, полёт нормальный. Не могу сказать что у движка уровень юньки по удобству, но в целом пользоваться приятно, если нет желания связываться с юнькой и достаточно мозгов чтобы хотябы читать код движка. Движок бля бздодь в хорошем смысле, но не без ньюансов, а по поводу возможности закрыться за пейволом - ну мей би, жаль будет.
>>22439
Видимо у хрюнити тут как с туториалами - их куча, а качество кал. Чем тебе поможет много плохих либ, нужна то всего одна хорошая.
Видимо у хрюнити тут как с туториалами - их куча, а качество кал. Чем тебе поможет много плохих либ, нужна то всего одна хорошая.
>>22438
И что? Даже если бы это было так, любой комп и мобила потянули бы. Это тебе было показано еще лет 5 назад в треде. Когда ты носился с картинкой а там сколько было фпс, 30 при полной заполненности экрана буквами.
И что? Даже если бы это было так, любой комп и мобила потянули бы. Это тебе было показано еще лет 5 назад в треде. Когда ты носился с картинкой а там сколько было фпс, 30 при полной заполненности экрана буквами.
>>22440
Не припомню чтобы на мобиле что то ломалось.
Не припомню чтобы на мобиле что то ломалось.
>>22477
Ну вот сейчас 5 студий делают каждая своё продолжение, и вроде бы опять не на годоте.
Ну вот сейчас 5 студий делают каждая своё продолжение, и вроде бы опять не на годоте.
>>22482
спокуха, проще уже готовые исходники взять и переделать
спокуха, проще уже готовые исходники взять и переделать
>>22482
Замкнутое колесо Самсары.
Сначала нечто захватывает рынок.
Потом его сложно выдавить с рынка, потому что "ну в прошлый раз же выбрали говно, пожрем еще"
Замкнутое колесо Самсары.
Сначала нечто захватывает рынок.
Потом его сложно выдавить с рынка, потому что "ну в прошлый раз же выбрали говно, пожрем еще"
>>22491
Вообще годот не лучше юнити, поэтому он его никогда не выдавит. Максимум что он выдавит - это жидкого.
Такая вот жесткая правда. Был бы годот не говном - его бы не обсирали тут 24/7.
Вообще годот не лучше юнити, поэтому он его никогда не выдавит. Максимум что он выдавит - это жидкого.
Такая вот жесткая правда. Был бы годот не говном - его бы не обсирали тут 24/7.
>>22439
С этой игры кстати проиграл, трейлер начался с "игра была 15 лет в разработке" и я тут же понял какое нахуй засохшее каловое говно ща будет.
С этой игры кстати проиграл, трейлер начался с "игра была 15 лет в разработке" и я тут же понял какое нахуй засохшее каловое говно ща будет.
>>22492
Конечно годот хуже юнити! Но всего процентов на 5-10. Что говорит не в пользу юнити, учитывая что на нее слиты много миллиардов, а годот запилен в основном десятком энтузиастов, лол. А может практически все то же.
Конечно годот хуже юнити! Но всего процентов на 5-10. Что говорит не в пользу юнити, учитывая что на нее слиты много миллиардов, а годот запилен в основном десятком энтузиастов, лол. А может практически все то же.
>>22492
А то что ты его тут один "обсираешь тут 24/7" - ну так ты шиз с кучей свободного времени. Правда, обычно все твои "обсирания" оказываются под себя и тут же опровергаются.
А то что ты его тут один "обсираешь тут 24/7" - ну так ты шиз с кучей свободного времени. Правда, обычно все твои "обсирания" оказываются под себя и тут же опровергаются.
>>22482
Честно звучит как антиреклама юните, раз для такой простенькой игры на этом движке понадобилось СТОЛЬКО разрабов, что их набралось на 5 крупных студий.
>>22439
И этих туда же, 15 лет разработки на юнете, какая там команда, 20 тел?
Прям слоган - на юнете игру займет у вас 15 лет и получите целых 600 отзывов (для F2P).
Честно звучит как антиреклама юните, раз для такой простенькой игры на этом движке понадобилось СТОЛЬКО разрабов, что их набралось на 5 крупных студий.
>>22439
И этих туда же, 15 лет разработки на юнете, какая там команда, 20 тел?
Прям слоган - на юнете игру займет у вас 15 лет и получите целых 600 отзывов (для F2P).
210 Кб, 1885x904для достоверности даже намешал буковки в лабелах
>>22495
ребята заняты вшиванием стиллеров и шпионов в свой рантайм вместо фич, пынямать надо.
ребята заняты вшиванием стиллеров и шпионов в свой рантайм вместо фич, пынямать надо.
>>22503
тут уже печальнее, если врубать аутлайн и тень (по факту шейдеры) то будет по 3 дравкола на 1 лабел без учета количества символов. Но вот большой обьем лабелов будет больно лупить. В конце концов можно юзать шрифты с обводкой, как вариант. Ну и richtextlabel хорошо себя показал, там конечно на каждую ноду нужен дравкол но нет оверхеда на обводку и тени.
тут уже печальнее, если врубать аутлайн и тень (по факту шейдеры) то будет по 3 дравкола на 1 лабел без учета количества символов. Но вот большой обьем лабелов будет больно лупить. В конце концов можно юзать шрифты с обводкой, как вариант. Ну и richtextlabel хорошо себя показал, там конечно на каждую ноду нужен дравкол но нет оверхеда на обводку и тени.
>>19657
Че реально настолько плохо? А то я всё хотел раст опробовать, но просто бесцельно ничего делать не могу, поэтому хотел выбрать попенсорс в котором можно будет копаться, контрибьютить даже возможно. И я уже считай bevy выбрал и был готов вот вот приступить
> каждые четыре месяца выходит новая говно версия которая ломает нахуй все, ужасный просто блять уродский API и пидорское сообщество (не удивительно - Раст же).
Че реально настолько плохо? А то я всё хотел раст опробовать, но просто бесцельно ничего делать не могу, поэтому хотел выбрать попенсорс в котором можно будет копаться, контрибьютить даже возможно. И я уже считай bevy выбрал и был готов вот вот приступить
>>22438
Они хотя бы есть. В хрюнити сначала надо скачивать кнопки и устанавливать всякие текст меш про, соглашаясь с анальными лицензиями. (А без установки Unity может вывести только 16250 символов, лол)
Они хотя бы есть. В хрюнити сначала надо скачивать кнопки и устанавливать всякие текст меш про, соглашаясь с анальными лицензиями. (А без установки Unity может вывести только 16250 символов, лол)
>>22509
Пиздец копиум.
Хрюнити при этом всё ровно лучше чем гоньдоут. Игр похожих на элизиум - на годоте никогда не будет. Самая графонистая игра на гуньдоте PVKK или как там её там - до сих пор не вышла.
РоадТуВосток замедлился в разработке и просто шекели гребет с патреона.
На хрюнити он прямо как бешеный клепал обновы, а на годоте плывет черепашими темпами. Ебало Фина представили от погружения в этот "замечательный" движок?))))
>Они хотя бы есть. В хрюнити сначала надо скачивать кнопки
Пиздец копиум.
Хрюнити при этом всё ровно лучше чем гоньдоут. Игр похожих на элизиум - на годоте никогда не будет. Самая графонистая игра на гуньдоте PVKK или как там её там - до сих пор не вышла.
РоадТуВосток замедлился в разработке и просто шекели гребет с патреона.
На хрюнити он прямо как бешеный клепал обновы, а на годоте плывет черепашими темпами. Ебало Фина представили от погружения в этот "замечательный" движок?))))
>>22521
Лоооол, а что хрюнитя не вывезла 3д? В диско элизиуме вместо графония отрендереные задники, какое же позорище.
Лоооол, а что хрюнитя не вывезла 3д? В диско элизиуме вместо графония отрендереные задники, какое же позорище.
>>22493
>>22497
это скорее всего маркетинговый трюк, по типу "основано на реальных событиях", я поиграл, мне понравилось, правда игра вышла абсолютно без защиты и я сделал, чтобы я мог видеть всех сквозь туман, отключил всю логику связанную с погодой и погодными эффектами и бустанул +20 фпс, ебало моё представили?
>>22497
>15 лет
это скорее всего маркетинговый трюк, по типу "основано на реальных событиях", я поиграл, мне понравилось, правда игра вышла абсолютно без защиты и я сделал, чтобы я мог видеть всех сквозь туман, отключил всю логику связанную с погодой и погодными эффектами и бустанул +20 фпс, ебало моё представили?
вот пруф, они ещё используют систему загрузки разных настроек для прода, для редактора и т.д, и там есть такие интересные переменные, даже блядь с ними пускает играть против реальных людей
>>22497
а мне кажется это ещё нормально, тем более игра в раннем доступе, а такие игры в стиме не получают такого же продвижения как игры без этой пометки, так что в теории, она на релизе может хайпануть
>>22497
>600 отзывов (для F2P).
а мне кажется это ещё нормально, тем более игра в раннем доступе, а такие игры в стиме не получают такого же продвижения как игры без этой пометки, так что в теории, она на релизе может хайпануть
>>22523
Юнити вывезла отрендеренный задник, а годотя бы не смогла.
Олсо это artistic choice, почитай интервью с создателями. Задники не просто отрендеренные, а нарисованные вручную, с использованием 3д-болванок.
Юнити вывезла отрендеренный задник, а годотя бы не смогла.
Олсо это artistic choice, почитай интервью с создателями. Задники не просто отрендеренные, а нарисованные вручную, с использованием 3д-болванок.
>>22496
годот обсирает каждый, кто попробовал им пользоваться и столкнулся с неразрешимыми проблемами
раньше это было делать можно в годот-треде, но потом вахтёр озверел и стал сверкать сракой от каждого попуска годота, в итоге вместо вопрос-ответ там только аниме-картинки и называние друг друга няшами, а про технические проблемы говорить нельзя
кстати модератор, похоже, забил на эту доску, так что можно снова обсуждать годот в годот-треде
годот обсирает каждый, кто попробовал им пользоваться и столкнулся с неразрешимыми проблемами
раньше это было делать можно в годот-треде, но потом вахтёр озверел и стал сверкать сракой от каждого попуска годота, в итоге вместо вопрос-ответ там только аниме-картинки и называние друг друга няшами, а про технические проблемы говорить нельзя
кстати модератор, похоже, забил на эту доску, так что можно снова обсуждать годот в годот-треде
>>22533
Если брать жанр 2д и годот 3.6 глес2 - у него из неразрешимых проблем остаются только интерполяция физики (не завезли) и отсутствие некоторых юнити-фич, которые придется писать самому (нарезка спрайтшитов в спрайт листинги, например), и на этом список неразрешимостей завершается. Если делать проект в рамках апи gles2 учитывая его особенности и недостатки (и не забывать про недостатки гднатив, например рейкастить надо передвигаемой нодой а не физическим апи) - можно без проблем релизиться на все платформы и все везде будет работать и примеров тому уже не мало. Ну не юнити, да, не юнити, но все не так плохо.
Если брать жанр 2д и годот 3.6 глес2 - у него из неразрешимых проблем остаются только интерполяция физики (не завезли) и отсутствие некоторых юнити-фич, которые придется писать самому (нарезка спрайтшитов в спрайт листинги, например), и на этом список неразрешимостей завершается. Если делать проект в рамках апи gles2 учитывая его особенности и недостатки (и не забывать про недостатки гднатив, например рейкастить надо передвигаемой нодой а не физическим апи) - можно без проблем релизиться на все платформы и все везде будет работать и примеров тому уже не мало. Ну не юнити, да, не юнити, но все не так плохо.
>>22545
там нет нормальных шейдеров с кастомными рендер пассами - до сих пор нельзя правильный эффект прозрачности без перекрытия сделать
там неразрешимые глюки рэгдолла, когда человечки просто перестают рендерится или их пидорасит на пол-экрана - причём это случается только с некоторыми моделями
там пропуки даже на самых простых сценах, микрофризы - хз отчего, я не стал разбираться и забил
там нет нормальных шейдеров с кастомными рендер пассами - до сих пор нельзя правильный эффект прозрачности без перекрытия сделать
там неразрешимые глюки рэгдолла, когда человечки просто перестают рендерится или их пидорасит на пол-экрана - причём это случается только с некоторыми моделями
там пропуки даже на самых простых сценах, микрофризы - хз отчего, я не стал разбираться и забил
>>22533
Ну и забыл дописать, есть еще одна неразрешимая но разрешаемая проблема (и уже частично решенная) - рекламные аддоны, но тут все зависит не от годот.
Ну и забыл дописать, есть еще одна неразрешимая но разрешаемая проблема (и уже частично решенная) - рекламные аддоны, но тут все зависит не от годот.
>>22521
Если оно выйдет каким то чудом то 100% будет андерделиверед даже в случае юньки. А шизик еще и на годот перешел, да.
Очевидно он просто гоев лет 5 будет доить.
>РоадТуВосток
Если оно выйдет каким то чудом то 100% будет андерделиверед даже в случае юньки. А шизик еще и на годот перешел, да.
Очевидно он просто гоев лет 5 будет доить.
>>22546
Я же говорю, если брать только 2д, с 3д я не работаю, рендерпассы вроде как есть, можно несколько шейдеров на материал навесить, вот и рендерпассы
Ну жди когда дойдут до перехода на годот 5 и попробуй снова вкатиться в 4, думаю пофиксят и апи стабилизируется, если конечно в 3.6 уже не пофиксили, она вышла только прошлой осенью
Там есть профайлер как в юнити, видно каждый чих, у меня никаких микрофризов нет. Для 3д я знаю что физика отвратительная и полуживая, но я писал только за 2д.
Я же говорю, если брать только 2д, с 3д я не работаю, рендерпассы вроде как есть, можно несколько шейдеров на материал навесить, вот и рендерпассы
>там неразрешимые глюки рэгдолла
Ну жди когда дойдут до перехода на годот 5 и попробуй снова вкатиться в 4, думаю пофиксят и апи стабилизируется, если конечно в 3.6 уже не пофиксили, она вышла только прошлой осенью
>там пропуки даже на самых простых сценах, микрофризы - хз отчего, я не стал разбираться и забил
Там есть профайлер как в юнити, видно каждый чих, у меня никаких микрофризов нет. Для 3д я знаю что физика отвратительная и полуживая, но я писал только за 2д.
>>22549
трюки с буффером глубины нельзя провернуть таким образом
можно выйти из положения только с помощью создания отдельного вьюпорта - но там на каждый объект потребуется свой вьюпорт, это шиза
вот если проблему можно закрыть только таким костылём, это значит, что проблема всё ещё есть
я с 2014 года жду, надоело
>Я же говорю, если брать только 2д, с 3д я не работаю, рендерпассы вроде как есть, можно несколько шейдеров на материал навесить, вот и рендерпассы
трюки с буффером глубины нельзя провернуть таким образом
можно выйти из положения только с помощью создания отдельного вьюпорта - но там на каждый объект потребуется свой вьюпорт, это шиза
вот если проблему можно закрыть только таким костылём, это значит, что проблема всё ещё есть
>Ну жди когда дойдут до перехода на годот 5
я с 2014 года жду, надоело
>>22443
Не дочинится он, пока Хуан и его дружки - главные. Смысл движка в сборе донатов, а не в создании игр. Если бы движок был бы настолько хорош, он бы конкурировал с Юнити уже в 2014 году.
Все эти секты уровня "Я потрогал Юнити, неудобно, потрогал Годот, теперь удобно" не производят игры. Их смысл - завлечь людей в ловушку швятого попенсорса, чтобы работать на аргентинского барина, которых с таких лошков будет побирать донаты и инвестиции в свою шарашку.
Не дочинится он, пока Хуан и его дружки - главные. Смысл движка в сборе донатов, а не в создании игр. Если бы движок был бы настолько хорош, он бы конкурировал с Юнити уже в 2014 году.
Все эти секты уровня "Я потрогал Юнити, неудобно, потрогал Годот, теперь удобно" не производят игры. Их смысл - завлечь людей в ловушку швятого попенсорса, чтобы работать на аргентинского барина, которых с таких лошков будет побирать донаты и инвестиции в свою шарашку.
>>22495
Повторить всегда проще, когда все ошибки были учтены первопроходцами.
Только вот говнот по причине своих нод и решений аргентинской парочки геев никогда не будет быстрее даже Юнити на 3D проектах чуточку сложнее чем лоуполи слоп.
Повторить всегда проще, когда все ошибки были учтены первопроходцами.
Только вот говнот по причине своих нод и решений аргентинской парочки геев никогда не будет быстрее даже Юнити на 3D проектах чуточку сложнее чем лоуполи слоп.
>>22590
Ноды тут при чем? Создашь в юнити 100к геймобжектов с 1 компонентом? А в годоте можно. Ты даже не знаешь как эти ноды обосрать потому что ты их никогда не видел.
>>22589
Ты годот 1.0 вообще видел? Это был кривой кусок gtk говна, которое ещё и периодически падало супротив тогдашней Unity4-Unity5 с форой развития в 6 лет и имеющий только 2д.
По поводу донатов - ну не кидай донаты в годот, донать контрибам коммитящим нужные тебе фичи напрямую. Что, не хочешь? А че так? Я лично вообще ни копейки не вдонатил, просто юзаю и годот просто работает в той области где я знаю его преимущества и недостатки.
Ноды тут при чем? Создашь в юнити 100к геймобжектов с 1 компонентом? А в годоте можно. Ты даже не знаешь как эти ноды обосрать потому что ты их никогда не видел.
>>22589
>конкурировал с Юнити уже в 2014 году
Ты годот 1.0 вообще видел? Это был кривой кусок gtk говна, которое ещё и периодически падало супротив тогдашней Unity4-Unity5 с форой развития в 6 лет и имеющий только 2д.
По поводу донатов - ну не кидай донаты в годот, донать контрибам коммитящим нужные тебе фичи напрямую. Что, не хочешь? А че так? Я лично вообще ни копейки не вдонатил, просто юзаю и годот просто работает в той области где я знаю его преимущества и недостатки.
И вот казалось бы, сейчас юнити срёт в штаны по кд, конкурентам бы напрячься да урвать у неё кусок рынка. Но все мы видим этот блядский цирк не первый год, лол, все понимаем, чем это кончится
>>22607
да, тебе показалось, в штаны насрал только ты
это оказалось абсолютно нежизнеспособной системой разработки софта, типа "сетецентричной тактики по стандартам НАТО", которая годится только против кучки бармалеев в тапочках, а в реальном конфликте рулят большие дивизии с управлением из генштаба
>И вот казалось бы,
да, тебе показалось, в штаны насрал только ты
> донать контрибам коммитящим нужные тебе фичи напрямую
это оказалось абсолютно нежизнеспособной системой разработки софта, типа "сетецентричной тактики по стандартам НАТО", которая годится только против кучки бармалеев в тапочках, а в реальном конфликте рулят большие дивизии с управлением из генштаба
>>22607
Пока что был только подливный пердеж, они были в шаге от сранья в штаны но удержались. Им надо как-то совсем мощно оподливиться, например срезать 100к в год с персоналки до условных 20-50к или ввести ещё более конечную вещь чем runtime fee, тогда уже конкурентам имеет смысл напрягаться чтобы умаслить триврядчиков и казичников, которых процентов 70 от всех юзеров юнити, а до тех пор за всех будет тянуть лямку только Хуан со своими твиттерскими прихлебателями.
Пока что был только подливный пердеж, они были в шаге от сранья в штаны но удержались. Им надо как-то совсем мощно оподливиться, например срезать 100к в год с персоналки до условных 20-50к или ввести ещё более конечную вещь чем runtime fee, тогда уже конкурентам имеет смысл напрягаться чтобы умаслить триврядчиков и казичников, которых процентов 70 от всех юзеров юнити, а до тех пор за всех будет тянуть лямку только Хуан со своими твиттерскими прихлебателями.
>>22609
Подливным пердежом было то, что они начинали десятки пакетов и фичей - и бросили их. Подливный пердёж это их система террейна, которая получила со времён какой там, четвёртой юнити, одно обновление. Подливный пердёж это пачка разных гуи-систем. И да, подлива - это всё ещё дерьмо. Я бы даже назвал подливой то, что сейчас есть три системы рендеринга и самая быстрая из них не поддерживается. А продвинутая HD имеет меньше гибкости, чем универсальная, при этом у URP с HDRP разные апи и нет паритета по функциям. Это уже подлива, но ещё не обосрамс. Только вот это далеко не самое хуёвое, что случалось с движком. И юнити может себе позволить эту подливу, потому что альтернатив физически не существует. Если они введут хуйню о которой ты говоришь, то это уже не обсёр, это добровольный роскомнадзор движка его владельцами.
Подливным пердежом было то, что они начинали десятки пакетов и фичей - и бросили их. Подливный пердёж это их система террейна, которая получила со времён какой там, четвёртой юнити, одно обновление. Подливный пердёж это пачка разных гуи-систем. И да, подлива - это всё ещё дерьмо. Я бы даже назвал подливой то, что сейчас есть три системы рендеринга и самая быстрая из них не поддерживается. А продвинутая HD имеет меньше гибкости, чем универсальная, при этом у URP с HDRP разные апи и нет паритета по функциям. Это уже подлива, но ещё не обосрамс. Только вот это далеко не самое хуёвое, что случалось с движком. И юнити может себе позволить эту подливу, потому что альтернатив физически не существует. Если они введут хуйню о которой ты говоришь, то это уже не обсёр, это добровольный роскомнадзор движка его владельцами.
>>22612
Всё что ты перечислил - хуйня на общем фоне. Если бы они даже с этим не обосрались - то там бы уже анрилу было бы пора на помойку, что уж говорить про другие движки.
Всё что ты перечислил - хуйня на общем фоне. Если бы они даже с этим не обосрались - то там бы уже анрилу было бы пора на помойку, что уж говорить про другие движки.
>>22595
Если всю логику нод переписать на скрипты? Можно. Так и в юньке можно.
>Создашь в юнити 100к геймобжектов с 1 компонентом? Да.
>А в годоте можно.
Если всю логику нод переписать на скрипты? Можно. Так и в юньке можно.
>>22614
Ну покажи, только не 100к а предельные значения по одному и другому движку, так сказать защита от тредриппера
Ну покажи, только не 100к а предельные значения по одному и другому движку, так сказать защита от тредриппера
>>22615
Долго будешь самоподдувать?
Долго будешь самоподдувать?
>>22613
Так я и говорю, что это не самое хуёвое, что случалось. И юнити может себе позволить хуйню такого плана. Хотя общую картину это портит. А вот рантайм фи уже херня посерьёзнее. Если бы у юнити реально были конкуренты, они бы получили приток пользователей. Да даже разные проёбы с рандомным отзывом лицензий могли бы сыграть роль.
Кстати, уже давно правда, вкидывал в тредис опыты по количеству объектов между всей троицей. Юнити с годотом вывозят примерно одно количество, но годот тогда разъебало, умерла вся система освещения и что-то ещё, уже точно не помню. На уе фпс упал практически в начале опыта, на считанных десятках объектов.
Мне ещё тогда начали затирать, про "чтобы ускорить - выброси все стандартные системы, всю хуйню, напиши заново, оптимизируй", лол.
Так я и говорю, что это не самое хуёвое, что случалось. И юнити может себе позволить хуйню такого плана. Хотя общую картину это портит. А вот рантайм фи уже херня посерьёзнее. Если бы у юнити реально были конкуренты, они бы получили приток пользователей. Да даже разные проёбы с рандомным отзывом лицензий могли бы сыграть роль.
Кстати, уже давно правда, вкидывал в тредис опыты по количеству объектов между всей троицей. Юнити с годотом вывозят примерно одно количество, но годот тогда разъебало, умерла вся система освещения и что-то ещё, уже точно не помню. На уе фпс упал практически в начале опыта, на считанных десятках объектов.
Мне ещё тогда начали затирать, про "чтобы ускорить - выброси все стандартные системы, всю хуйню, напиши заново, оптимизируй", лол.
>>22612
DOTS, il2cpp, burst - не брошены и даже доведены до релиза, а это не пердящие наниты требующие железа которое ещё не произвели, чтобы не лагать, а столь важные средства для выжимания из проца всех соков под геймплей. Конвейеры рендеринга - проблема, но это цена за клозед сурс которую приходится платить, потому что если из урины можно физически вырезать лишнее, то вот в юнити только жричедали. Пачка гуи систем - цена за большой объём проектов от них зависящих, где некоторый код не видел редактуры с 5 юнити, а развивать гуй все же надо, но это не проблема. Реальная проблема - когда уже бляд неткор, сколько можно тащить моно.
По террейну - тебе террейнов мало в ассетсторе? Там такое есть что даже не верится что это реально.
>десятки пакетов и фичей - и бросили их.
DOTS, il2cpp, burst - не брошены и даже доведены до релиза, а это не пердящие наниты требующие железа которое ещё не произвели, чтобы не лагать, а столь важные средства для выжимания из проца всех соков под геймплей. Конвейеры рендеринга - проблема, но это цена за клозед сурс которую приходится платить, потому что если из урины можно физически вырезать лишнее, то вот в юнити только жричедали. Пачка гуи систем - цена за большой объём проектов от них зависящих, где некоторый код не видел редактуры с 5 юнити, а развивать гуй все же надо, но это не проблема. Реальная проблема - когда уже бляд неткор, сколько можно тащить моно.
По террейну - тебе террейнов мало в ассетсторе? Там такое есть что даже не верится что это реально.
>>22622
Как же я проигрывал, когда тесты показывали, что рендеринг всего говна в лоб быстрее нанитов. Это просто ахуй.
Вырезал в пакеты и все довольны. Но нет.
А с неткором проблем вообще не вижу, выбрал в настройках проекта совместимость и ни в чём себе не отказываю. Но я энивей ненавижу залупу вроде linq, потому меня не напрягает, что нет современного сахарка.
По сути, юнити тоже можно кастомизировать очень сильно. Только делается это оверрайдом стандартной херни. Лично у меня часто оказывается, что гибкость юнити позволяет делать больше, чем УЕ без влезания в сорцы. Чисто ради справедливости - хуй кто в них полезет.
Когда последний спрашивал "чё самое крутое по террейнам" - мне сказали гайя. Она накручена поверх дефолтного террейна, лол.
>>22625
Да, завайпали пиздец. Вчера вообще 6 было.
>не пердящие наниты требующие железа которое ещё не произвели
Как же я проигрывал, когда тесты показывали, что рендеринг всего говна в лоб быстрее нанитов. Это просто ахуй.
>Пачка гуи систем - цена за большой объём проектов от них зависящих
Вырезал в пакеты и все довольны. Но нет.
А с неткором проблем вообще не вижу, выбрал в настройках проекта совместимость и ни в чём себе не отказываю. Но я энивей ненавижу залупу вроде linq, потому меня не напрягает, что нет современного сахарка.
>если из урины можно физически вырезать лишнее, то вот в юнити только жричедали
По сути, юнити тоже можно кастомизировать очень сильно. Только делается это оверрайдом стандартной херни. Лично у меня часто оказывается, что гибкость юнити позволяет делать больше, чем УЕ без влезания в сорцы. Чисто ради справедливости - хуй кто в них полезет.
>По террейну - тебе террейнов мало в ассетсторе?
Когда последний спрашивал "чё самое крутое по террейнам" - мне сказали гайя. Она накручена поверх дефолтного террейна, лол.
>>22625
>Скорость борды: 4 п./час
Да, завайпали пиздец. Вчера вообще 6 было.
214 Кб, 400x388>>22668
>гибкость юнити позволяет делать больше, чем УЕ без влезания в сорцы. Чисто ради справедливости - хуй кто в них полезет.
>>22668
Например?
>Лично у меня часто оказывается, что гибкость юнити позволяет делать больше, чем УЕ без влезания в сорцы.
Например?
>>22706
Например около года назад я начал заниматься процедурными скелетами. В юнити есть меканим, например, очевидно что при модификации скелета отваливаются запеченные кривые трансформаций и меканим больше не может анимировать скелет. Но можно сделать ребинд, после чего аниматор подхватит те кости, о которых ему известно, есть доступ к самим кривым и многим другим вещам. Этого недостаточно, но это хорошая стартовая точка. Анрил при рантайм удалении костей просто крашил весь движок, то есть у меня не было возможности даже начать. Да, меканим не может работать с моей системой, сейчас в ней около трёхсот динамических костей. Но гибкость юнити позволяет мне начать реализовывать то, что я хочу, в худшем случае просто ничего не произойдёт. В анриле же для таких вещей мне бы потребовался доступ к исходному коду.
Например около года назад я начал заниматься процедурными скелетами. В юнити есть меканим, например, очевидно что при модификации скелета отваливаются запеченные кривые трансформаций и меканим больше не может анимировать скелет. Но можно сделать ребинд, после чего аниматор подхватит те кости, о которых ему известно, есть доступ к самим кривым и многим другим вещам. Этого недостаточно, но это хорошая стартовая точка. Анрил при рантайм удалении костей просто крашил весь движок, то есть у меня не было возможности даже начать. Да, меканим не может работать с моей системой, сейчас в ней около трёхсот динамических костей. Но гибкость юнити позволяет мне начать реализовывать то, что я хочу, в худшем случае просто ничего не произойдёт. В анриле же для таких вещей мне бы потребовался доступ к исходному коду.
>>22714
В урине нет апи для удаления костей в рантайме насколько я знаю, я хз как ты даже умудрился это сделать, но ты можешь их скрыть и убрать влияние на другие кости. Алсо двачну анона выше, что ты пытался сделать то?
В урине нет апи для удаления костей в рантайме насколько я знаю, я хз как ты даже умудрился это сделать, но ты можешь их скрыть и убрать влияние на другие кости. Алсо двачну анона выше, что ты пытался сделать то?
>>22717
>>22719
Так процедурные скелеты задача-то. Было дано, что движки плохо справляются большим количеством объектов. Даже отключённые жрут перформанс. Если такой процедурный объект один - это похуй. В задачу входит поддержка десятков, в идеале - сотен таких скелетов. Если каждый содержит по три сотни костей, то я в дерьме. Однако ни один скелет не требует всех костей одновременно. Так что мне нужна система, которая сможет анимировать скелет с непостоянным количеством костей, смешивать анимации, отслеживать существующие, добавленные и удалённые кости.
В итоге есть константные кости с постоянными кривыми и два типа дополнительных костей. Первый тип анимируется полностью процедурно, для вторых в аниматор производится инъекция кривых. И никакого доступа к исходникам у меня нет.
Да уже не помню, но это точно не сложно было, у меня пара минут ушло тогда. Я охуел, что движок крашнулся даже без воспроизведения анимации.
>>22719
Так процедурные скелеты задача-то. Было дано, что движки плохо справляются большим количеством объектов. Даже отключённые жрут перформанс. Если такой процедурный объект один - это похуй. В задачу входит поддержка десятков, в идеале - сотен таких скелетов. Если каждый содержит по три сотни костей, то я в дерьме. Однако ни один скелет не требует всех костей одновременно. Так что мне нужна система, которая сможет анимировать скелет с непостоянным количеством костей, смешивать анимации, отслеживать существующие, добавленные и удалённые кости.
В итоге есть константные кости с постоянными кривыми и два типа дополнительных костей. Первый тип анимируется полностью процедурно, для вторых в аниматор производится инъекция кривых. И никакого доступа к исходникам у меня нет.
>я хз как ты даже умудрился это сделать
Да уже не помню, но это точно не сложно было, у меня пара минут ушло тогда. Я охуел, что движок крашнулся даже без воспроизведения анимации.
>>22734
Ок, а для чего это всё?
>Так процедурные скелеты задача-то. Было дано, что движки плохо справляются большим количеством объектов. Даже отключённые жрут перформанс. Если такой процедурный объект один - это похуй. В задачу входит поддержка десятков, в идеале - сотен таких скелетов. Если каждый содержит по три сотни костей, то я в дерьме. Однако ни один скелет не требует всех костей одновременно. Так что мне нужна система, которая сможет анимировать скелет с непостоянным количеством костей, смешивать анимации, отслеживать существующие, добавленные и удалённые кости.
>В итоге есть константные кости с постоянными кривыми и два типа дополнительных костей. Первый тип анимируется полностью процедурно, для вторых в аниматор производится инъекция кривых. И никакого доступа к исходникам у меня нет.
Ок, а для чего это всё?
>>22734
анрил удаляет кости, которых нет в скине
они в редакторе скелетал меша отображаются блекло-сереньким
анрил удаляет кости, которых нет в скине
они в редакторе скелетал меша отображаются блекло-сереньким
Можно ли на гондоте онли визуально скриптить или всё равно придётся где-то ручками писать?
Вот констракт заебись, там ничего писать не надо, но бля, он сосёт по оптимизации и возможностям, штмл хули
Вот констракт заебись, там ничего писать не надо, но бля, он сосёт по оптимизации и возможностям, штмл хули
>>22675
Ну и где великие мобильные хиты на гуньдоте?
Десять лет швабодки работать на аргентинского барина. Итоги.
Ну и где великие мобильные хиты на гуньдоте?
Десять лет швабодки работать на аргентинского барина. Итоги.
>>22786
зачем? тебе блядь весь мир даёт нейронки, учи-дрочи-делай что хочешь, нет, я буду кушать кал
>онли визуально скриптить
зачем? тебе блядь весь мир даёт нейронки, учи-дрочи-делай что хочешь, нет, я буду кушать кал
>>22788
РКН уже до гугла добрался? Хитов мало, можно считать по пальцам, типа того же бротато, но они есть, а значит 2д мобилки на годоте жизнеспособные. А что студии выбирают юнити по ряду причин - ну пускай, никто не осуждает, кроме отьявленных шизоидов с годотом головного мозга.
РКН уже до гугла добрался? Хитов мало, можно считать по пальцам, типа того же бротато, но они есть, а значит 2д мобилки на годоте жизнеспособные. А что студии выбирают юнити по ряду причин - ну пускай, никто не осуждает, кроме отьявленных шизоидов с годотом головного мозга.
77 Кб, 740x740>>22801
>Это стандартный подход для большинства игр с возможностью замены экипировки
>рантайм удаление костей
>>22852
ты не в состоянии описать свою задачу и пишешь вместо неё то, что к ней не относится?
> Это даже никак не относится к задаче
ты не в состоянии описать свою задачу и пишешь вместо неё то, что к ней не относится?
>>22854
Как в этом поможет статическое удаление костей? Никак. Это не поможет анимировать скелет с непостоянным количеством костей, это просто сделает количество костей константным и заморозит их. Так что твоё решение не относится к задаче, не делает её решение ни на шаг ближе и фактически только мешает её достижению.
>система, которая сможет анимировать скелет с непостоянным количеством костей, смешивать анимации, отслеживать существующие, добавленные и удалённые кости.
Как в этом поможет статическое удаление костей? Никак. Это не поможет анимировать скелет с непостоянным количеством костей, это просто сделает количество костей константным и заморозит их. Так что твоё решение не относится к задаче, не делает её решение ни на шаг ближе и фактически только мешает её достижению.
>>22858
что значит не поможет анимировать скелет с непостоянным количеством костей? берешь скелет, проигрываешь на нем анимацию. скелет анимируется, если в этой анимации есть кости из этого скелета. это так работает в движке
что значит не поможет анимировать скелет с непостоянным количеством костей? берешь скелет, проигрываешь на нем анимацию. скелет анимируется, если в этой анимации есть кости из этого скелета. это так работает в движке
Какой консенсус по love2d? Выглядит просто, весело, без лишнего говняка. В чем подводные камни?
>>22860
В том что их нет. Крутой движок.
В том что их нет. Крутой движок.
>>22852
Никто так не делает блять, хуесосина, иначе бы у тебя не было проблем сделать так в двух самых популярных движках. Ты мне хочешь сказать что в 100500 играх на анриле где есть смена экипировки перелопачивали сорс код ради этой фичи что ли? Иди нахуй долбоёбина.
>Cтандарт, хули. Все так делают, кроме беседки.
Никто так не делает блять, хуесосина, иначе бы у тебя не было проблем сделать так в двух самых популярных движках. Ты мне хочешь сказать что в 100500 играх на анриле где есть смена экипировки перелопачивали сорс код ради этой фичи что ли? Иди нахуй долбоёбина.
>>22871
Вот это долбоёб подорвался.
>>22872
Смешнее всего, что это работало из коробки в третьем УЕ, работает без проблем в крайэнжине. Но с четвёртой версии УЕ деградировал по фичам. Да, все так делают, это стандарт, делать по-другому просто противоестественно. Но уе4-5 это другой разговор. Юнити прикрутили animation rigging tools, чтобы у них это тоже работало, но там уже по цене удовольствия вопросики. Так что, технически, это работает в каждом движке, кроме современного УЕ.
Вот это долбоёб подорвался.
>>22872
Смешнее всего, что это работало из коробки в третьем УЕ, работает без проблем в крайэнжине. Но с четвёртой версии УЕ деградировал по фичам. Да, все так делают, это стандарт, делать по-другому просто противоестественно. Но уе4-5 это другой разговор. Юнити прикрутили animation rigging tools, чтобы у них это тоже работало, но там уже по цене удовольствия вопросики. Так что, технически, это работает в каждом движке, кроме современного УЕ.
>>22880
Эх. Пиздатый двиг был. Жаль сейчас в застое, и на нём можно только пердолингом заниматься.
>работает без проблем в крайэнжине
Эх. Пиздатый двиг был. Жаль сейчас в застое, и на нём можно только пердолингом заниматься.
гедачер два года пытался решить стандартную задачу, которая из коробки решена в движке, и не справился
>>22890
Да хуй знает, у меня от него было ощущение, что его делали пришельцы для пришельцев, которые ничего не знают о землянах. Он даже не поддерживал импорт fbx, когда я в нём ковырялся. Да, он на порядок круче анрила и вообще охуенный, что по графике, что по возможностям, но порог входа сомнительный. Так что пердолюсь с юнити, вариантов других нет.
Отдельно лолирую с дауна, который так и не понял, что я делаю и почему это не та хуйня, о которой он пишет.
Со скелетами закончил давно, не хотелось rigging tools трогать, фактически это перезапись меканима, по перформансу дороже. На днях взялся за портирование SVOGI. Видел платный ассет с реализацией, 80 баксов. Как-то перебор, мне кажется. Особенно если учесть, что это порт фришного кода с легаси рендеринга.
Да хуй знает, у меня от него было ощущение, что его делали пришельцы для пришельцев, которые ничего не знают о землянах. Он даже не поддерживал импорт fbx, когда я в нём ковырялся. Да, он на порядок круче анрила и вообще охуенный, что по графике, что по возможностям, но порог входа сомнительный. Так что пердолюсь с юнити, вариантов других нет.
Отдельно лолирую с дауна, который так и не понял, что я делаю и почему это не та хуйня, о которой он пишет.
Со скелетами закончил давно, не хотелось rigging tools трогать, фактически это перезапись меканима, по перформансу дороже. На днях взялся за портирование SVOGI. Видел платный ассет с реализацией, 80 баксов. Как-то перебор, мне кажется. Особенно если учесть, что это порт фришного кода с легаси рендеринга.
>>22895
Проклятие безыгорности
Гедаче не сможет сделать даже инди хоррор из ассетов, потом будет плакать что движок говна в жопу залил
Проклятие безыгорности
Гедаче не сможет сделать даже инди хоррор из ассетов, потом будет плакать что движок говна в жопу залил
>>22880
По-моему ты пиздишь
>Смешнее всего, что это работало из коробки в третьем УЕ, работает без проблем в крайэнжине
По-моему ты пиздишь
>>22898
Движок - sdohnahui. Даже бурги которые в дискорде-крайтеков предупреждают об этом.
Поэтому лучше анрил выбирать, чем что-то такое.
Для меня юнити - не варик. Для задач на будущее не подходит. Мне надо плюсы и знания в урине, т.к наклёвывается команда на интересный и большой проект.
Интересно, можно-ли так-же его портировать в анрил или нет. Надо разобраться.
>но порог входа сомнительный
Движок - sdohnahui. Даже бурги которые в дискорде-крайтеков предупреждают об этом.
Поэтому лучше анрил выбирать, чем что-то такое.
>Так что пердолюсь с юнити, вариантов других нет.
Для меня юнити - не варик. Для задач на будущее не подходит. Мне надо плюсы и знания в урине, т.к наклёвывается команда на интересный и большой проект.
>SVOGI
Интересно, можно-ли так-же его портировать в анрил или нет. Надо разобраться.
Открыл стим опять играть не в чего.
Хули вы игры не делаете? В стиме одно дерьмо. Или это ваше?
Хули вы игры не делаете? В стиме одно дерьмо. Или это ваше?
>>22932
не делаем. точно не наше
не делаем. точно не наше
>>22906
Ты сейчас охуеешь, но третий анрил даже умел сшивать скиннед меши по швам и не проёбывать при этом скиннинг. Конечно, это было доступно только господам, оплатившим платный доступ. Без плоти - соси.
>>22912
Там была залупа, что кастомные схемы освещения выпилили к хуям в какой-то версии. Был челик, который пилил освещение для растительности, с рассеиванием, корректным окклюженом и другими фишками. В итоге ему обновой перекрыли кислород и он бросил. Вроде, говорили, что собираются вернуть, но вернули или нет - хуй знает. А так доступно, конечно, только сорцы перелопать сначала. Как раз кресты подтянешь, если не ебанёшься в процессе.
Ты сейчас охуеешь, но третий анрил даже умел сшивать скиннед меши по швам и не проёбывать при этом скиннинг. Конечно, это было доступно только господам, оплатившим платный доступ. Без плоти - соси.
>>22912
>можно-ли так-же его портировать в анрил или нет.
Там была залупа, что кастомные схемы освещения выпилили к хуям в какой-то версии. Был челик, который пилил освещение для растительности, с рассеиванием, корректным окклюженом и другими фишками. В итоге ему обновой перекрыли кислород и он бросил. Вроде, говорили, что собираются вернуть, но вернули или нет - хуй знает. А так доступно, конечно, только сорцы перелопать сначала. Как раз кресты подтянешь, если не ебанёшься в процессе.
>>22940
он и сейчас умеет
он и сейчас умеет
>>22940
Мда блять. Не просто так мне знакомые говорили, что с 4кой странные вещи начали происходить после её релиза. Некоторые студии даже на 3ке остались сидеть и её допиливать, вместо перехода на 4ку. Поскольку 4ка была пиздецом каким-то.
Найсс, возьму на вооружение. Спасибо.
>третий анрил
Мда блять. Не просто так мне знакомые говорили, что с 4кой странные вещи начали происходить после её релиза. Некоторые студии даже на 3ке остались сидеть и её допиливать, вместо перехода на 4ку. Поскольку 4ка была пиздецом каким-то.
>А так доступно, конечно, только сорцы перелопать сначала. Как раз кресты подтянешь, если не ебанёшься в процессе.
Найсс, возьму на вооружение. Спасибо.
>>22955
Хуан сам своё говно копай.
Хуан сам своё говно копай.
>>22945
Лол. Была такая хуйня, студии, которые плотно на трёшке сидели - сидели на ней, по сути, до прошлого года. Да и эти ограничения пытаются обходить наёбом, а не реализацией того, что было в уе3. Гибкости поменьше стало.
Ну а хули, я таких советов надаю - охуеешь. Сам-то я в сорцы уе хуй полезу, нахуй надо, блядь. Редактирование исходников отрезает тебе обновление движка. Выход - пилить надо плагин. Но обновления апи сломают твой плагин к хуям. Выход - лезть в сорцы. А в них лезть нахуй надо.
>Некоторые студии даже на 3ке остались сидеть и её допиливать
Лол. Была такая хуйня, студии, которые плотно на трёшке сидели - сидели на ней, по сути, до прошлого года. Да и эти ограничения пытаются обходить наёбом, а не реализацией того, что было в уе3. Гибкости поменьше стало.
>Найсс, возьму на вооружение.
Ну а хули, я таких советов надаю - охуеешь. Сам-то я в сорцы уе хуй полезу, нахуй надо, блядь. Редактирование исходников отрезает тебе обновление движка. Выход - пилить надо плагин. Но обновления апи сломают твой плагин к хуям. Выход - лезть в сорцы. А в них лезть нахуй надо.
>>22966
оно сейчас работает. просто недоумок опять не осилил изкоробочный функционал, и по старинке пошел "перелопачивать сорцы". что бы это не значило. успехом у него это никогда не оканчивается
оно сейчас работает. просто недоумок опять не осилил изкоробочный функционал, и по старинке пошел "перелопачивать сорцы". что бы это не значило. успехом у него это никогда не оканчивается
Что за дебилы гонят на роуд-ту-восток?
https://www.youtube.com/watch?v=9PeXZleBq4M
Блядь хейтерам только дай повод кого-нибудь обосрать. Потреблядки. Видел таких что им вообще никакие игры не нравятся, и они обвиняют в этом игры, а не то что они сухари ебаные, и ничто не способно принести им радость.
https://www.youtube.com/watch?v=9PeXZleBq4M
Блядь хейтерам только дай повод кого-нибудь обосрать. Потреблядки. Видел таких что им вообще никакие игры не нравятся, и они обвиняют в этом игры, а не то что они сухари ебаные, и ничто не способно принести им радость.
>>23091
выблядский дегенерат, делать 5+ лет игру это не гейм дев - это мошенничество и дойка таких же выблядских дегенератов типа тебя
выблядский дегенерат, делать 5+ лет игру это не гейм дев - это мошенничество и дойка таких же выблядских дегенератов типа тебя
>>23127
пока ты будешь дрочить ноды и связи, я за секунду скопипащу ответ от нейронки и вставлю в иде, а визуальный скриптинг - это проблемы умственно отсталых
пока ты будешь дрочить ноды и связи, я за секунду скопипащу ответ от нейронки и вставлю в иде, а визуальный скриптинг - это проблемы умственно отсталых
>>23122
Как тебе другая ситуация.
1. Собираешь деньги на игру краудфандингом. Потом подтягиваются инвесторы.
2. Делаешь игру 13 лет. За первые 5 тратишь "на разработку" очка 200 миллионов долларов. Игры всё ещё нет.
3. Лохи вводят в существующие игры микротранзакции. Ты вводишь в несуществующую игру макротранзакции. Человек может задонатить десятки тысяч долларов за картинку в профиле на сайте и не получить больше нихуя.
Как тебе такое, анон с двощей?
>делать 5+ лет игру это не гейм дев - это мошенничество
Как тебе другая ситуация.
1. Собираешь деньги на игру краудфандингом. Потом подтягиваются инвесторы.
2. Делаешь игру 13 лет. За первые 5 тратишь "на разработку" очка 200 миллионов долларов. Игры всё ещё нет.
3. Лохи вводят в существующие игры микротранзакции. Ты вводишь в несуществующую игру макротранзакции. Человек может задонатить десятки тысяч долларов за картинку в профиле на сайте и не получить больше нихуя.
Как тебе такое, анон с двощей?
>>23091
https://www.youtube.com/watch?v=9PeXZleBq4M
А что он собственно показал нового? То что на хрюнити делается аналогично делается скриптами, или-же на урине делается даже ещё банальнее - блюпринтами?
Нахуя эти извращения на движке, который очевидно не имеет и не будет иметь какие-то продвинутые системы чего-либо?
Что это если не мошенничество? Он выстрелил благодаря юнити, и в хайпе смены монетизации от юнитеков, которые очевидно попустились и поменяли обратно как было.
А если послушать его планы на игру - годот для реализации чего-то подобного - банально не жизнеспособен.
Он на юнити уже имел эту систему полу-готовую, а теперь дрочит на этом годоте велосипеды для макак с патреона, словно это прям пиздец невиданные технологии.
С таким подходом он будет её делать 5+ лет, если не больше.
>Что за дебилы гонят на роуд-ту-восток?
https://www.youtube.com/watch?v=9PeXZleBq4M
А что он собственно показал нового? То что на хрюнити делается аналогично делается скриптами, или-же на урине делается даже ещё банальнее - блюпринтами?
Нахуя эти извращения на движке, который очевидно не имеет и не будет иметь какие-то продвинутые системы чего-либо?
Что это если не мошенничество? Он выстрелил благодаря юнити, и в хайпе смены монетизации от юнитеков, которые очевидно попустились и поменяли обратно как было.
А если послушать его планы на игру - годот для реализации чего-то подобного - банально не жизнеспособен.
Он на юнити уже имел эту систему полу-готовую, а теперь дрочит на этом годоте велосипеды для макак с патреона, словно это прям пиздец невиданные технологии.
С таким подходом он будет её делать 5+ лет, если не больше.
Сегодня проверял топ игр по движкам.
Почему на рпгмейкере самые популярные игры это ВНки, а рпгшек так считай и нет.
Почему на рпгмейкере самые популярные игры это ВНки, а рпгшек так считай и нет.
>>23138
Он делает ебучий клон сталкача, не новый red faction, не гонки где нужна физика и деформация тачек, не майнкрафт (хотя майн можно сделать), не дарк соулс с боевыми анимациями и красочными боссами, не гта и не скайрим. Он делает шутер блять, в лесопромзоне с графоном уровня ЗП, и используя шарп. Если годот сам по себе не обосрется (например на некоторых устройствах будет крашить или типа того) - то в этой ситуации при даже не слишком больших навыках сложно обосраться. Террейны есть, стримить ресурсы не надо, если учесть некоторые проблемы типа рейкастов - проблем ваще не ожидается.
>на движке, который очевидно не имеет и не будет иметь какие-то продвинутые системы
Он делает ебучий клон сталкача, не новый red faction, не гонки где нужна физика и деформация тачек, не майнкрафт (хотя майн можно сделать), не дарк соулс с боевыми анимациями и красочными боссами, не гта и не скайрим. Он делает шутер блять, в лесопромзоне с графоном уровня ЗП, и используя шарп. Если годот сам по себе не обосрется (например на некоторых устройствах будет крашить или типа того) - то в этой ситуации при даже не слишком больших навыках сложно обосраться. Террейны есть, стримить ресурсы не надо, если учесть некоторые проблемы типа рейкастов - проблем ваще не ожидается.
>>23146
Насколько я помню, у него там все террейны - это 3д меш с масками для текстур.
Может конечно поменял уже, но, это не точно.
>Террейны есть
Насколько я помню, у него там все террейны - это 3д меш с масками для текстур.
Может конечно поменял уже, но, это не точно.
>>23146
Двачую, что такого в этой игре? Выглядит обычно.
Двачую, что такого в этой игре? Выглядит обычно.
стало бесплатным (дерьмо)
https://assetstore.unity.com/packages/tools/physics/cloth-dynamics-194408
https://assetstore.unity.com/packages/tools/physics/cloth-dynamics-194408
1,5 Мб, 1920x1080>>23091
Проходил мимо, глянул и проиграл. Судя по видео — игра про хвойные деревья. Тысячи их. И. И блять. Это одно и то же ебучее дерево, размноженное как вот тот куст в супер марио. Посмотрите на пикрелейтед. Деревья занимают приличный такой процент экранной площади и выглядят просто как говно. Это не маленькая деталь вроде камушка под деревом или гусенички на дереве. Нет. Это основное визуальное наполнение. Ну как так можно!
Проходил мимо, глянул и проиграл. Судя по видео — игра про хвойные деревья. Тысячи их. И. И блять. Это одно и то же ебучее дерево, размноженное как вот тот куст в супер марио. Посмотрите на пикрелейтед. Деревья занимают приличный такой процент экранной площади и выглядят просто как говно. Это не маленькая деталь вроде камушка под деревом или гусенички на дереве. Нет. Это основное визуальное наполнение. Ну как так можно!
>>23182
Так это лоды. Посмотри на крайние правые деревья, там видно, что это две плоскости по углом 90 градусов. Так-то можно понять, если челик просто закинул в проект лишь бы что нибудь на время разработки, потому дерево одно. И что выкрутил дальность лодов на минимум, чтобы не ебало пеку.
Так это лоды. Посмотри на крайние правые деревья, там видно, что это две плоскости по углом 90 градусов. Так-то можно понять, если челик просто закинул в проект лишь бы что нибудь на время разработки, потому дерево одно. И что выкрутил дальность лодов на минимум, чтобы не ебало пеку.
>>23146
Чувак настолько дегенерат, что не использует occlusion culling.
Это можно узнать с помощью gdsdecomp, который раскрывает твою сцену и скрипты на раз-два.
Чувак настолько дегенерат, что не использует occlusion culling.
Это можно узнать с помощью gdsdecomp, который раскрывает твою сцену и скрипты на раз-два.
251 Кб, 380x505>>23287
самый омерзительный ублюдок в педовуде, я ему дал погоняло "шлакоблок" за его ублюдское ебало
самый омерзительный ублюдок в педовуде, я ему дал погоняло "шлакоблок" за его ублюдское ебало
>>23287
Он его и не включал, ведь это надо ЧИТАТЬ ДОКУМЕНТАЦИЮ! Невозможное дело для современного человека.
Он его и не включал, ведь это надо ЧИТАТЬ ДОКУМЕНТАЦИЮ! Невозможное дело для современного человека.
Как же я проебался со своим движком для ВНок. Просто смешно и стыдно. не буду писать в чем была проблема.
Переделаю на днях на стандарт. Правда мне он сейчас не нужен больше, но все же.
Переделаю на днях на стандарт. Правда мне он сейчас не нужен больше, но все же.
>>23324
даже неудивительно, как мне кажется, в этом деле нужен большой скилл не только в паттернах, но и архитектуре, то есть, если ты хуй моржовый скилл боксовый или любой другой - это только приведёт на помойку
>Как же я проебался со своим движком
даже неудивительно, как мне кажется, в этом деле нужен большой скилл не только в паттернах, но и архитектуре, то есть, если ты хуй моржовый скилл боксовый или любой другой - это только приведёт на помойку
>>23324
Достижение уровня GD разблокировано - обосраться с рендерингом статической картинки.
Достижение уровня GD разблокировано - обосраться с рендерингом статической картинки.
>>23331
Не, картинка норм отображалась. Как и развилка и доп элементы.
Я даже нескольких игр по 2-5 часов написал на нем. Проблема в том что он был сделан чисто для меня.
Сейчас потребовалось сделать его доступ для всех и доработать за бабло. Мне хватит на месяц, но тут я понял что проебался. Нужно было посмотреть как работают другие движки. Лол
Так то для простых веб игр он норм. Все настроено.
А вот для драг энд дроп новелок это не подойдёт, слишком заморочено и без знания кодинга не обойтись.
Я сейчас немного проигрался с чужим движком и понял как было нужно сделать. На выходных перепишу. Там делов на два дня.
Не, картинка норм отображалась. Как и развилка и доп элементы.
Я даже нескольких игр по 2-5 часов написал на нем. Проблема в том что он был сделан чисто для меня.
Сейчас потребовалось сделать его доступ для всех и доработать за бабло. Мне хватит на месяц, но тут я понял что проебался. Нужно было посмотреть как работают другие движки. Лол
Так то для простых веб игр он норм. Все настроено.
А вот для драг энд дроп новелок это не подойдёт, слишком заморочено и без знания кодинга не обойтись.
Я сейчас немного проигрался с чужим движком и понял как было нужно сделать. На выходных перепишу. Там делов на два дня.
>>23386
Ну так хули ты как маленький. Наверни сверху кода, который будет понятнее для всех непричастных. Всегда так делаю. Запилил монструозный монолит, который людей посмотревших сойдут с ума? Соевый пидорок не может понять, что делать и почему нет интерфейсов? Не беда. Пилишь поверх парочку абстракций с интерфейсами, декоуплингом и прочей хернёй. Которая под капотом всё равно обращается к твоему коду, написанному в пограничном состоянии между припадком вдохновения и просвещённым маразмом. У меня как-то был крестовый плагин, который делал работу, и обёртка на шарпах поверх. И было две функции, которые нужно было вызывать, если хочешь, чтобы эта хуйня работала. Зачем и почему - не знал даже я. То есть я знал, что они делают, но зачем я это сделал оставалось вопросом. На деле первая выделяла байт, а вторая замещала его. Фактически, булева переменная, только прямиком из дурки. И если оно не в том положении - то нихуя не работает. Можешь себе представить, как люто я рофлил, разглядывая написанный поверх код, строго по бест практисес, с паттернами, красивый, аккуратный и все дела. Фабрики, сука, сервис локаторы и ещё хуй знает, что ещё. А под этим всем крестовый плагин - фактически одна ёбаная стена кода, на которую смотреть не просто страшно, а натурально больно.
Ну так хули ты как маленький. Наверни сверху кода, который будет понятнее для всех непричастных. Всегда так делаю. Запилил монструозный монолит, который людей посмотревших сойдут с ума? Соевый пидорок не может понять, что делать и почему нет интерфейсов? Не беда. Пилишь поверх парочку абстракций с интерфейсами, декоуплингом и прочей хернёй. Которая под капотом всё равно обращается к твоему коду, написанному в пограничном состоянии между припадком вдохновения и просвещённым маразмом. У меня как-то был крестовый плагин, который делал работу, и обёртка на шарпах поверх. И было две функции, которые нужно было вызывать, если хочешь, чтобы эта хуйня работала. Зачем и почему - не знал даже я. То есть я знал, что они делают, но зачем я это сделал оставалось вопросом. На деле первая выделяла байт, а вторая замещала его. Фактически, булева переменная, только прямиком из дурки. И если оно не в том положении - то нихуя не работает. Можешь себе представить, как люто я рофлил, разглядывая написанный поверх код, строго по бест практисес, с паттернами, красивый, аккуратный и все дела. Фабрики, сука, сервис локаторы и ещё хуй знает, что ещё. А под этим всем крестовый плагин - фактически одна ёбаная стена кода, на которую смотреть не просто страшно, а натурально больно.
а можно было взять sugarcube и если нужно обернуть в электрон и выпустить в стиме или вк плее
206 Кб, 596x637>>23492
Чё ты ожидал от сотни индусов? Что они тебе рабочий код выкатят? Щаз.
Чё ты ожидал от сотни индусов? Что они тебе рабочий код выкатят? Щаз.
>>23492
делаю веб-приложение копилотом для кореша
в общем, оказалось, что всё, что пишут про ИИ (что он всех заменит и т.д.) - всё это время никто не признавался, что это говорили веб-макаки, и речь шла строго про веб-макак, просто веб-макаки распространяют это на всех, чтобы не обидно было
реально, стоило ненамного сменить профиль, и я познал всю мощь ИИ. до этого он только обсирался, и годился сделать 30 строк бойлерплейта, не более
в вебмакакинге эта хуйня реально умеет срать кодом на фреймворках, сотнями строк. я прям почувствовал в коде месяцы ЗНАНИЙ, которые я сэкономил
жаль что любые правки приводят к увеличению кодобазы, у этой хуйни прям плохо с рефактором, поверх старых костылей начинает лепить новые костыли чтобы отменить поведение, которое само же и задало. ну и лимит познаний довольно быстро достигается. основной скелет насрать может, как до фич доходит или правки багов, начинает срать бесполезными фиксами "+25 -2", раздувая кодобазу бесполезным кодом который ничего не делает
делаю веб-приложение копилотом для кореша
в общем, оказалось, что всё, что пишут про ИИ (что он всех заменит и т.д.) - всё это время никто не признавался, что это говорили веб-макаки, и речь шла строго про веб-макак, просто веб-макаки распространяют это на всех, чтобы не обидно было
реально, стоило ненамного сменить профиль, и я познал всю мощь ИИ. до этого он только обсирался, и годился сделать 30 строк бойлерплейта, не более
в вебмакакинге эта хуйня реально умеет срать кодом на фреймворках, сотнями строк. я прям почувствовал в коде месяцы ЗНАНИЙ, которые я сэкономил
жаль что любые правки приводят к увеличению кодобазы, у этой хуйни прям плохо с рефактором, поверх старых костылей начинает лепить новые костыли чтобы отменить поведение, которое само же и задало. ну и лимит познаний довольно быстро достигается. основной скелет насрать может, как до фич доходит или правки багов, начинает срать бесполезными фиксами "+25 -2", раздувая кодобазу бесполезным кодом который ничего не делает
>>23571
Обожаю читать их посты. Там самомнение 10/10.
Особенно у крупных разрабов.
В итоге оказывается что простой генератор сайтов на ноде быстрее ихних аналоговнетов на разных языках. Который написан на простом js (запрещен в веб комьюнити) и занимает сотню строк.
>веб-макаки
Обожаю читать их посты. Там самомнение 10/10.
Особенно у крупных разрабов.
>Мой код на языкенейм для backend самый быстрый, лучший, гениальный
>Врешь! Это мой язык лучше
>А у меня есть фреймворк! Я построил на нем приложение ухаха!
В итоге оказывается что простой генератор сайтов на ноде быстрее ихних аналоговнетов на разных языках. Который написан на простом js (запрещен в веб комьюнити) и занимает сотню строк.
Мысли об SDL3?
>>23575
На чём? Ни одного voxel движка нет. А воксель плагины к юнити/уе5/годоту превращают всё в страшные полигоны, из за чего всё лагает тормозит и выглядит как гавно. Вот.
На чём? Ни одного voxel движка нет. А воксель плагины к юнити/уе5/годоту превращают всё в страшные полигоны, из за чего всё лагает тормозит и выглядит как гавно. Вот.
>>23586
ебало дауна представили? делай саи воксели, игр на юнити воксельных - дохуя
ебало дауна представили? делай саи воксели, игр на юнити воксельных - дохуя
>на два дровколла один пропук
Никакого пропука в годоте нет! В годоте раньше были пропуки. Сейчас в годот едут коммиты. работает чекап и реактивный кодинг. Активно работает смена релизов. Речи о глубоком пропуке не идёт. Пропук конечно попадается, но на очень ограниченном круге задач. Проекты удерживаем, дравколлы туда не пустили, стоим крепко. Попукиваем, но в пределах разумного.
мимо ОП годотреда, старший ОПуполномоченный
https://github.com/godotengine/godot/pull/106645
Одна из причин пропуков современных движков - бесконечный понос компилируемых шейдеров, а этот мужик их только добавляет.
Одна из причин пропуков современных движков - бесконечный понос компилируемых шейдеров, а этот мужик их только добавляет.
48 Кб, 1227x407>>618624 (OP)
Пипец, зашел сюда, тут похоже чатик из двух-трех спорщиков о чем-то своем, тянущийся много тредов.
По теме: просто делал что-то на анриле какое-то время, и недавно опять поставил юнити после долгого перерыва. Я конечно не профессионал, просто делюсь мнением, возможно поверхностным.
Если человек хочет фотореализма, крутого графона, вот этого всего, то это - Unreal. Если бы я поставил задачу делать игру в таком ключе, то однозначно выбрал бы его, но... эти реалистичные, детальные ассеты делать сложно, долго и скучно. В реалистичную локацию просятся реалистичные люди. Есть метахьюман, но даже с ним сложно добиться приятного результата. Делать реалистичных людей, чтобы они не выглядели кадаврами - та еще задача. Так что как для соло разработчика который не хочет делать просто ассет флип, это будет занимать очень много времени и сил.
Так как времена изменились, появились ИИ, то я подумал покрутить опять юнити. И действительно оказалось, что в юнити с возможностями ИИ открываются интересные перспективы делать стилизованную графику. Менее трудоемкую в исполнении с большей творческой свободой. Анрил, сколько бы там ни было действительно мощных встроенных инструментов, такое впечатление, что диктует свою эстетику играм.
Правда вот эти URP-HDRP, все усложнили в последнее время. Это штуки чисто для суровых кодеров, а для обывал от них вроде нет никакой пользы, но юнити чуть ли не угрозами заставляет тебя их использовать.
В общем, реализм - Unreal. Стилизация и творческая свобода - Unity. Такое у меня пока впечатление.
Годо поставил, но ничего в нем не понял. Это про запас.
Пипец, зашел сюда, тут похоже чатик из двух-трех спорщиков о чем-то своем, тянущийся много тредов.
По теме: просто делал что-то на анриле какое-то время, и недавно опять поставил юнити после долгого перерыва. Я конечно не профессионал, просто делюсь мнением, возможно поверхностным.
Если человек хочет фотореализма, крутого графона, вот этого всего, то это - Unreal. Если бы я поставил задачу делать игру в таком ключе, то однозначно выбрал бы его, но... эти реалистичные, детальные ассеты делать сложно, долго и скучно. В реалистичную локацию просятся реалистичные люди. Есть метахьюман, но даже с ним сложно добиться приятного результата. Делать реалистичных людей, чтобы они не выглядели кадаврами - та еще задача. Так что как для соло разработчика который не хочет делать просто ассет флип, это будет занимать очень много времени и сил.
Так как времена изменились, появились ИИ, то я подумал покрутить опять юнити. И действительно оказалось, что в юнити с возможностями ИИ открываются интересные перспективы делать стилизованную графику. Менее трудоемкую в исполнении с большей творческой свободой. Анрил, сколько бы там ни было действительно мощных встроенных инструментов, такое впечатление, что диктует свою эстетику играм.
Правда вот эти URP-HDRP, все усложнили в последнее время. Это штуки чисто для суровых кодеров, а для обывал от них вроде нет никакой пользы, но юнити чуть ли не угрозами заставляет тебя их использовать.
В общем, реализм - Unreal. Стилизация и творческая свобода - Unity. Такое у меня пока впечатление.
Годо поставил, но ничего в нем не понял. Это про запас.
>>23655
Этот миф давно не релевантен. Анрил для красивых статических кадров, юнити для реализма или стилизации. Анрил сделал большую ставку на темпоральное сглаживание всего кадра, у юнити это делается внутри каждого отдельного компонента, что немного повышает нагрузку, но снижает артефакты на сотню раз. Так что юнити это про реализм и качество картинки ещё с демки с лесом. А то и раньше. Временной призрак, враги, да каждая новая демка юнити - про реализм. И они охуенны.
>реализм - Unreal. Стилизация и творческая свобода - Unity.
Этот миф давно не релевантен. Анрил для красивых статических кадров, юнити для реализма или стилизации. Анрил сделал большую ставку на темпоральное сглаживание всего кадра, у юнити это делается внутри каждого отдельного компонента, что немного повышает нагрузку, но снижает артефакты на сотню раз. Так что юнити это про реализм и качество картинки ещё с демки с лесом. А то и раньше. Временной призрак, враги, да каждая новая демка юнити - про реализм. И они охуенны.
>>23674
Я спорить не буду, потому что толком не знаю, как с реализмом в юнити дела обстоят, изначально рассматривал его как движок для стилизации. Но TAA в юнити мне не понравился по этому я использую MSAA. В анриле тоже есть forward и в нем можно включить MSAA, но анрил конечно заточен на deferred.
Почему я говорю, что анрил - про реализм, так это потому что это чувствуется во всех его фичах и нововведениях. Эта ветка выбрана для прокачки. Там даже tone mapping тяжело отключить.
Мне нравятся там тени, virtual shadow maps. Они ведут себя как настоящие. Шедеры кожи, волос. Все это для реалистичных людей хорошо работает. Карты освещения запекаются на GPU. Ну, про нанайты и люмен я думаю говорить не стоит, все и так знают.
Минусы: все эти люмены и TAA артефактят страшно, и вообще вся картинка как будто переоптимизирована. В unity такое впечатление, что картинка выглядит чище. Даже если сравнивать отключив все навороты.
Я спорить не буду, потому что толком не знаю, как с реализмом в юнити дела обстоят, изначально рассматривал его как движок для стилизации. Но TAA в юнити мне не понравился по этому я использую MSAA. В анриле тоже есть forward и в нем можно включить MSAA, но анрил конечно заточен на deferred.
Почему я говорю, что анрил - про реализм, так это потому что это чувствуется во всех его фичах и нововведениях. Эта ветка выбрана для прокачки. Там даже tone mapping тяжело отключить.
Мне нравятся там тени, virtual shadow maps. Они ведут себя как настоящие. Шедеры кожи, волос. Все это для реалистичных людей хорошо работает. Карты освещения запекаются на GPU. Ну, про нанайты и люмен я думаю говорить не стоит, все и так знают.
Минусы: все эти люмены и TAA артефактят страшно, и вообще вся картинка как будто переоптимизирована. В unity такое впечатление, что картинка выглядит чище. Даже если сравнивать отключив все навороты.
>>23674
попизди, чтобы такие демки делать самому, надо как минимум хай левел скиллы иметь, дохуя моделить, дохуя анимировать и дохуя кода писать
>каждая новая демка юнити - про реализм
попизди, чтобы такие демки делать самому, надо как минимум хай левел скиллы иметь, дохуя моделить, дохуя анимировать и дохуя кода писать
Аналитик: Apple может присматриваться к покупке Unity для компенсации проигрыша в суде с Epic Games
В начале мая стало известно о победе Epic Games над Apple в апелляционном суде в США: корпорации запретили взимать комиссию с платежей, идущих вне App Store. Аналитик Aldora Йост ван Дрюнен (Joost van Dreunen) считает, что теперь Apple может обдумывать ряд стратегий для снижения ущерба. Одна из них — покупка Unity.
В начале мая стало известно о победе Epic Games над Apple в апелляционном суде в США: корпорации запретили взимать комиссию с платежей, идущих вне App Store. Аналитик Aldora Йост ван Дрюнен (Joost van Dreunen) считает, что теперь Apple может обдумывать ряд стратегий для снижения ущерба. Одна из них — покупка Unity.
>>23677
Почему? Удобно настраивается, менее агрессивен по дефолту, так что меньше проблем с темпоральным размазыванием.
В юнити все текстуры можно стримить, называется SVT. Тени тоже можно запекать на гпу, но есть и рейтрейсинг, и патч трейсинг. Да, про наниты и люмен лучше не говорить, их производительность подходит для архивиза, но не для игр.
Можно накинуть тех же агрессивных ТАА, сверху зерно, шарп, моушн блюр, тонмеппинг и абберации. Получишь то же самое, что в анриле. Но зачем?
>>23678
Демки можно скачивать себе, если что. Так что, как минимум, проблема кода решена. А моделить, ты думаешь, чтобы сделать свою пиздатую демку на анриле тебе модели не нужны? Кубы волшебным образом превратятся в хай поли машины, людей и так далее?
>TAA в юнити мне не понравился
Почему? Удобно настраивается, менее агрессивен по дефолту, так что меньше проблем с темпоральным размазыванием.
>virtual shadow maps
В юнити все текстуры можно стримить, называется SVT. Тени тоже можно запекать на гпу, но есть и рейтрейсинг, и патч трейсинг. Да, про наниты и люмен лучше не говорить, их производительность подходит для архивиза, но не для игр.
>картинка выглядит чище
Можно накинуть тех же агрессивных ТАА, сверху зерно, шарп, моушн блюр, тонмеппинг и абберации. Получишь то же самое, что в анриле. Но зачем?
>>23678
Демки можно скачивать себе, если что. Так что, как минимум, проблема кода решена. А моделить, ты думаешь, чтобы сделать свою пиздатую демку на анриле тебе модели не нужны? Кубы волшебным образом превратятся в хай поли машины, людей и так далее?
>>23680
Он съедает тонкие линии при движении. В анриле этого не происходит, а мне это критично.
Это был наоборот комплемент юнити, мне не нравится, что у анрила даже с отключенным всем как будто ощущается грязноватой картинка. Разумеется я отключаю всё безобразие.
>Почему?
Он съедает тонкие линии при движении. В анриле этого не происходит, а мне это критично.
>Можно накинуть тех же агрессивных ТАА, сверху зерно, шарп, моушн блюр, тонмеппинг и абберации. Получишь то же самое, что в анриле. Но зачем?
Это был наоборот комплемент юнити, мне не нравится, что у анрила даже с отключенным всем как будто ощущается грязноватой картинка. Разумеется я отключаю всё безобразие.
>>23680
Тем не менее их пихают уже везде. Тот же SH2 использует люмен.
>Да, про наниты и люмен лучше не говорить, их производительность подходит для архивиза, но не для игр.
Тем не менее их пихают уже везде. Тот же SH2 использует люмен.
>>23682
Чисто технически, ТАА так и должен работать. Это же усреднение пикселей, фактически, если пикселей слишком мало - они стираются. Можешь попробовать включить векторы движения, если ещё не. Иногда помогает. И есть файл в пакете Runtime\PostProcessing\Shaders\TemporalAntialiasing.hlsl. Можно переписать алгоритм, если сильно упороться, но сути ТАА это не изменит.
Лично мне в юнити не хватает разве что SDF теней. Но SDF есть в Visual Effect Graph, рендерятся в 3D текстуры.
>>23683
И можешь загуглить, сколько жалоб на перформанс SH2 есть. Самый эффективный совет - запускать с флагом D11. С этим флагом уе выключает виртуальные карты теней, хардварный RT, наниты и ещё бог знает, что ещё. Но SH2 чувствует себя намного лучше.
>Он съедает тонкие линии при движении.
Чисто технически, ТАА так и должен работать. Это же усреднение пикселей, фактически, если пикселей слишком мало - они стираются. Можешь попробовать включить векторы движения, если ещё не. Иногда помогает. И есть файл в пакете Runtime\PostProcessing\Shaders\TemporalAntialiasing.hlsl. Можно переписать алгоритм, если сильно упороться, но сути ТАА это не изменит.
Лично мне в юнити не хватает разве что SDF теней. Но SDF есть в Visual Effect Graph, рендерятся в 3D текстуры.
>>23683
И можешь загуглить, сколько жалоб на перформанс SH2 есть. Самый эффективный совет - запускать с флагом D11. С этим флагом уе выключает виртуальные карты теней, хардварный RT, наниты и ещё бог знает, что ещё. Но SH2 чувствует себя намного лучше.
>>23685
Логично, но в анриле как-то этого избежали. Может гляну вектора, хотя я не помню чтобы там были какие-то настройки. В принципе после анрила я просто не хочу видеть эти размазывающиеся эффекты и для стилизованной игры с относительно легкой графикой думаю MSAA будет идеально.
Это по-моему поведение теней которое у анриловских virtual shadow map как раз.
>Чисто технически, ТАА так и должен работать.
Логично, но в анриле как-то этого избежали. Может гляну вектора, хотя я не помню чтобы там были какие-то настройки. В принципе после анрила я просто не хочу видеть эти размазывающиеся эффекты и для стилизованной игры с относительно легкой графикой думаю MSAA будет идеально.
>Лично мне в юнити не хватает разве что SDF теней.
Это по-моему поведение теней которое у анриловских virtual shadow map как раз.
>>23690
Другие алгоритмы, хули. Анрил вложился в полноэкранный агрессивный ТАА. Юнити на него ставку не делали, у них темпоральная аккумуляция напрямую, скажем, внутри RT теней. Получаешь гостинг теней, но не всего кадра. Тоже хуёво, но не настолько. Да и совсем без темпоральной дрисни оно не работает нигде.
В юнити можно ещё покрутить base blend factor в ТАА, это, по сути, та же крутилка, что в уе preserve details. Сколько информации от кадра смешивать.
Понятное дело, что ничего лучше SMAA просто не существует, но оно не так дёшево, как ТАА. И чем больше полигонов, тем оно дороже.
ТАА-fatigue, лол.
Виртуальные текстуры это просто стриминг текстур из RAM в VRAM. А SDF это алгоритм генерации этих текстур. В анриле SDF используется для дальних теней, на сколько я знаю.
>в анриле как-то этого избежали.
Другие алгоритмы, хули. Анрил вложился в полноэкранный агрессивный ТАА. Юнити на него ставку не делали, у них темпоральная аккумуляция напрямую, скажем, внутри RT теней. Получаешь гостинг теней, но не всего кадра. Тоже хуёво, но не настолько. Да и совсем без темпоральной дрисни оно не работает нигде.
В юнити можно ещё покрутить base blend factor в ТАА, это, по сути, та же крутилка, что в уе preserve details. Сколько информации от кадра смешивать.
Понятное дело, что ничего лучше SMAA просто не существует, но оно не так дёшево, как ТАА. И чем больше полигонов, тем оно дороже.
>я просто не хочу видеть эти размазывающиеся эффекты
ТАА-fatigue, лол.
>у анриловских virtual shadow
Виртуальные текстуры это просто стриминг текстур из RAM в VRAM. А SDF это алгоритм генерации этих текстур. В анриле SDF используется для дальних теней, на сколько я знаю.
>>23694
Ну я говорю про характеристики самих теней, я точно не понимаю технологию, которую они используют, там это не называется SDF. наверно они используют какие-то свои модификации shadow map в virtual texture, но суть в том, что они - как это раньше называлось area shadow, размываются вдоль по мере удаления от источника тени, грубо говоря у ног тень четкая, а голова уже размытая. Ну и от формы источника сета зависят. Примерно как настоящие тени от трассировки лучей. При этом они не требуют рейтрейсинга.
Я так понял тебе же таких теней не хватает в юнити?
Кроме того люмен это не только свет, но и отражения похожие на рейтрейсинг, но упрощенные, чего в большинстве случае хватает.
>Виртуальные текстуры это просто стриминг текстур из RAM в VRAM. А SDF это алгоритм генерации этих текстур. В анриле SDF используется для дальних теней, на сколько я знаю.
Ну я говорю про характеристики самих теней, я точно не понимаю технологию, которую они используют, там это не называется SDF. наверно они используют какие-то свои модификации shadow map в virtual texture, но суть в том, что они - как это раньше называлось area shadow, размываются вдоль по мере удаления от источника тени, грубо говоря у ног тень четкая, а голова уже размытая. Ну и от формы источника сета зависят. Примерно как настоящие тени от трассировки лучей. При этом они не требуют рейтрейсинга.
Я так понял тебе же таких теней не хватает в юнити?
Кроме того люмен это не только свет, но и отражения похожие на рейтрейсинг, но упрощенные, чего в большинстве случае хватает.
374 Кб, 1909x1001>>23696
Короче смотри. Что делает юнити и большинство других движков для теней:
1. Рендерит из источника света текстуру
2. Накладывает её
Текстура рендерится с каскадами, чем дальше от камеры - тем ниже разрешение карты теней. Выглядит это как текстура, разделённая на N частей, где каждая часть это каскад со всё меньшим разрешением пиксель\метр.
А вот Virtual texture shadowing, оно же Sparse Virtual Shadow Maps работает вообще по-другому.
1. Сцена делится на тайлы
2. Тень рендерится для каждого тайла. Выглядит это, как N отдельных текстур
3. Всё это хранится в RAM
4. При необходимости подсасывается в VRAM
Это позволяет использовать тени более высокого разрешения без необходимости задирать разрешение карты теней в потолок и\или обрезать их дальность отрисовки. Из минусов, семплинг большего количества текстур и съедание пропускной способности RAM\VRAM.
Но всё это относится к хранению и загрузке текстур. Не к тому, как они рендерятся. Теперь идём к самой мякотке.
SDF, они же Signed Distance Fields. Для каждого объекта генерируется трёхмерная текстура, в которой положительные значения - внутри объекта, отрицательные снаружи, а нули это поверхность. Соответственно, семплируя эту текстуру можно получить значение дистанции до объекта, а ещё можно использовать марширующие лучи. То есть у нас уже фактически готовое АО нахуй. Маршировка лучей относительно дёшева, так что это подходит для дешёвых теней в том числе. Для VR. Качество страдает, потому что обычно получаются очень мягкие тени, возможна протечка света если разрешение карты SDF недостаточное. И вот анрил использует SDF тени для дальних объектов. В паре с виртуальными текстурами это относительно неплохо может работать, но пока что виртуальные текстуры пиздец, как ебут. И будут ебать ещё долго, потому что семплинг множества текстур и перегонка RAM\VRAM это не бесплатно.
Юнити же умеет генерировать SDF хоть для скинмешей в рилтайме, учитывая все трансформации и анимации. Не бесплатно, дорого, но жить можно. Пересчёт SDF текстур вообще дорогой, но для статик мешей можно их сгенерировать заранее. И вот именно таких теней мне не хватает.
Хуйня. Зависит от размеров источника света, заходишь в свой дирекшонал лайт и крутишь angular diameter. Всё, размыто около головы, чётко около ног. Совсем не та залупа, о которой я толкую.
Потому что люмен если не видит хардварного RT - переключается на софтварный, просто с низким разрешением. Люмен это всегда RT.
Короче смотри. Что делает юнити и большинство других движков для теней:
1. Рендерит из источника света текстуру
2. Накладывает её
Текстура рендерится с каскадами, чем дальше от камеры - тем ниже разрешение карты теней. Выглядит это как текстура, разделённая на N частей, где каждая часть это каскад со всё меньшим разрешением пиксель\метр.
А вот Virtual texture shadowing, оно же Sparse Virtual Shadow Maps работает вообще по-другому.
1. Сцена делится на тайлы
2. Тень рендерится для каждого тайла. Выглядит это, как N отдельных текстур
3. Всё это хранится в RAM
4. При необходимости подсасывается в VRAM
Это позволяет использовать тени более высокого разрешения без необходимости задирать разрешение карты теней в потолок и\или обрезать их дальность отрисовки. Из минусов, семплинг большего количества текстур и съедание пропускной способности RAM\VRAM.
Но всё это относится к хранению и загрузке текстур. Не к тому, как они рендерятся. Теперь идём к самой мякотке.
SDF, они же Signed Distance Fields. Для каждого объекта генерируется трёхмерная текстура, в которой положительные значения - внутри объекта, отрицательные снаружи, а нули это поверхность. Соответственно, семплируя эту текстуру можно получить значение дистанции до объекта, а ещё можно использовать марширующие лучи. То есть у нас уже фактически готовое АО нахуй. Маршировка лучей относительно дёшева, так что это подходит для дешёвых теней в том числе. Для VR. Качество страдает, потому что обычно получаются очень мягкие тени, возможна протечка света если разрешение карты SDF недостаточное. И вот анрил использует SDF тени для дальних объектов. В паре с виртуальными текстурами это относительно неплохо может работать, но пока что виртуальные текстуры пиздец, как ебут. И будут ебать ещё долго, потому что семплинг множества текстур и перегонка RAM\VRAM это не бесплатно.
Юнити же умеет генерировать SDF хоть для скинмешей в рилтайме, учитывая все трансформации и анимации. Не бесплатно, дорого, но жить можно. Пересчёт SDF текстур вообще дорогой, но для статик мешей можно их сгенерировать заранее. И вот именно таких теней мне не хватает.
>размываются вдоль по мере удаления от источника тени
Хуйня. Зависит от размеров источника света, заходишь в свой дирекшонал лайт и крутишь angular diameter. Всё, размыто около головы, чётко около ног. Совсем не та залупа, о которой я толкую.
>люмен это не только свет, но и отражения похожие на рейтрейсинг
Потому что люмен если не видит хардварного RT - переключается на софтварный, просто с низким разрешением. Люмен это всегда RT.
374 Кб, 1909x1001>>23696
Короче смотри. Что делает юнити и большинство других движков для теней:
1. Рендерит из источника света текстуру
2. Накладывает её
Текстура рендерится с каскадами, чем дальше от камеры - тем ниже разрешение карты теней. Выглядит это как текстура, разделённая на N частей, где каждая часть это каскад со всё меньшим разрешением пиксель\метр.
А вот Virtual texture shadowing, оно же Sparse Virtual Shadow Maps работает вообще по-другому.
1. Сцена делится на тайлы
2. Тень рендерится для каждого тайла. Выглядит это, как N отдельных текстур
3. Всё это хранится в RAM
4. При необходимости подсасывается в VRAM
Это позволяет использовать тени более высокого разрешения без необходимости задирать разрешение карты теней в потолок и\или обрезать их дальность отрисовки. Из минусов, семплинг большего количества текстур и съедание пропускной способности RAM\VRAM.
Но всё это относится к хранению и загрузке текстур. Не к тому, как они рендерятся. Теперь идём к самой мякотке.
SDF, они же Signed Distance Fields. Для каждого объекта генерируется трёхмерная текстура, в которой положительные значения - внутри объекта, отрицательные снаружи, а нули это поверхность. Соответственно, семплируя эту текстуру можно получить значение дистанции до объекта, а ещё можно использовать марширующие лучи. То есть у нас уже фактически готовое АО нахуй. Маршировка лучей относительно дёшева, так что это подходит для дешёвых теней в том числе. Для VR. Качество страдает, потому что обычно получаются очень мягкие тени, возможна протечка света если разрешение карты SDF недостаточное. И вот анрил использует SDF тени для дальних объектов. В паре с виртуальными текстурами это относительно неплохо может работать, но пока что виртуальные текстуры пиздец, как ебут. И будут ебать ещё долго, потому что семплинг множества текстур и перегонка RAM\VRAM это не бесплатно.
Юнити же умеет генерировать SDF хоть для скинмешей в рилтайме, учитывая все трансформации и анимации. Не бесплатно, дорого, но жить можно. Пересчёт SDF текстур вообще дорогой, но для статик мешей можно их сгенерировать заранее. И вот именно таких теней мне не хватает.
Хуйня. Зависит от размеров источника света, заходишь в свой дирекшонал лайт и крутишь angular diameter. Всё, размыто около головы, чётко около ног. Совсем не та залупа, о которой я толкую.
Потому что люмен если не видит хардварного RT - переключается на софтварный, просто с низким разрешением. Люмен это всегда RT.
Короче смотри. Что делает юнити и большинство других движков для теней:
1. Рендерит из источника света текстуру
2. Накладывает её
Текстура рендерится с каскадами, чем дальше от камеры - тем ниже разрешение карты теней. Выглядит это как текстура, разделённая на N частей, где каждая часть это каскад со всё меньшим разрешением пиксель\метр.
А вот Virtual texture shadowing, оно же Sparse Virtual Shadow Maps работает вообще по-другому.
1. Сцена делится на тайлы
2. Тень рендерится для каждого тайла. Выглядит это, как N отдельных текстур
3. Всё это хранится в RAM
4. При необходимости подсасывается в VRAM
Это позволяет использовать тени более высокого разрешения без необходимости задирать разрешение карты теней в потолок и\или обрезать их дальность отрисовки. Из минусов, семплинг большего количества текстур и съедание пропускной способности RAM\VRAM.
Но всё это относится к хранению и загрузке текстур. Не к тому, как они рендерятся. Теперь идём к самой мякотке.
SDF, они же Signed Distance Fields. Для каждого объекта генерируется трёхмерная текстура, в которой положительные значения - внутри объекта, отрицательные снаружи, а нули это поверхность. Соответственно, семплируя эту текстуру можно получить значение дистанции до объекта, а ещё можно использовать марширующие лучи. То есть у нас уже фактически готовое АО нахуй. Маршировка лучей относительно дёшева, так что это подходит для дешёвых теней в том числе. Для VR. Качество страдает, потому что обычно получаются очень мягкие тени, возможна протечка света если разрешение карты SDF недостаточное. И вот анрил использует SDF тени для дальних объектов. В паре с виртуальными текстурами это относительно неплохо может работать, но пока что виртуальные текстуры пиздец, как ебут. И будут ебать ещё долго, потому что семплинг множества текстур и перегонка RAM\VRAM это не бесплатно.
Юнити же умеет генерировать SDF хоть для скинмешей в рилтайме, учитывая все трансформации и анимации. Не бесплатно, дорого, но жить можно. Пересчёт SDF текстур вообще дорогой, но для статик мешей можно их сгенерировать заранее. И вот именно таких теней мне не хватает.
>размываются вдоль по мере удаления от источника тени
Хуйня. Зависит от размеров источника света, заходишь в свой дирекшонал лайт и крутишь angular diameter. Всё, размыто около головы, чётко около ног. Совсем не та залупа, о которой я толкую.
>люмен это не только свет, но и отражения похожие на рейтрейсинг
Потому что люмен если не видит хардварного RT - переключается на софтварный, просто с низким разрешением. Люмен это всегда RT.
>>23708
ух баля, я посмотрел на эту картинку и возбудился! сейчас побегу делать игру
>global-sdf-prev[...].png
ух баля, я посмотрел на эту картинку и возбудился! сейчас побегу делать игру
>>23655
Нахер твоё заморское гавно. Мы в новом мире, щас на отечественных технологиях все сидят. Наш движок!
Нахер твоё заморское гавно. Мы в новом мире, щас на отечественных технологиях все сидят. Наш движок!
>>23727
это ж сколько моделек по 60 бачей понадобится что бы игру полноценную состряпать?
уже готов сотню микрокредитов взять?
это ж сколько моделек по 60 бачей понадобится что бы игру полноценную состряпать?
уже готов сотню микрокредитов взять?
Сами учите свои языки, мне пох на языки, визуал скрипты рулят.
>>23739
Мы тут не за этим
Мы тут не за этим
>>618624 (OP)
Все движки говно, надо писать на графических фреймворках
Все движки говно, надо писать на графических фреймворках
>>23679
неплохой наброс для подъема акций, лол
неплохой наброс для подъема акций, лол
>>23921
как жс макака скажу что нихуя блять, разве только что-то пиздец простое, иначе ты охуеешь писать свои тулзы. Лучше любой движок брать с готовыми тулзами который может выдавать веб билд, будь то годот, юнити или хоть даже ебите энгин
>Легче на хтмл + жс написать тоже самое и это будет работать у всех.
как жс макака скажу что нихуя блять, разве только что-то пиздец простое, иначе ты охуеешь писать свои тулзы. Лучше любой движок брать с готовыми тулзами который может выдавать веб билд, будь то годот, юнити или хоть даже ебите энгин
>>23841
поволжский движок
https://github.com/thunder-engine/thunder
ThunderEngine-android.7z
88.9 MB 2025-03-27T07:32:36Z
ThunderEngine-ios-arm64.7z
18.7 MB 2025-03-27T07:32:35Z
ThunderEngine-linux-x86_64.7z
59.2 MB 2025-03-27T07:32:30Z
ThunderEngine-macosx-arm64.7z
40.6 MB 2025-03-27T07:32:32Z
ThunderEngine-tvos-arm64.7z
18.7 MB 2025-03-27T07:32:34Z
ThunderEngine-webgl-x86.7z
5.77 MB 2025-03-27T07:32:39Z
ThunderEngine-windows-x64.7z
32.2 MB 2025-03-27T07:32:28Z
Source code (zip)
2025-03-27T07:12:40Z
Source code (tar.gz)
поволжский движок
https://github.com/thunder-engine/thunder
ThunderEngine-android.7z
88.9 MB 2025-03-27T07:32:36Z
ThunderEngine-ios-arm64.7z
18.7 MB 2025-03-27T07:32:35Z
ThunderEngine-linux-x86_64.7z
59.2 MB 2025-03-27T07:32:30Z
ThunderEngine-macosx-arm64.7z
40.6 MB 2025-03-27T07:32:32Z
ThunderEngine-tvos-arm64.7z
18.7 MB 2025-03-27T07:32:34Z
ThunderEngine-webgl-x86.7z
5.77 MB 2025-03-27T07:32:39Z
ThunderEngine-windows-x64.7z
32.2 MB 2025-03-27T07:32:28Z
Source code (zip)
2025-03-27T07:12:40Z
Source code (tar.gz)
>>23956
не знаешь - не лезь
не знаешь - не лезь
>>24018
Про сложные и простые языки пишут только хуесосы(то есть ты) которые ничего серьезного в жизни не писали. Основная проблема это не язык, а решение конкретной задачи под конкретную проблему так чтобы не насрать в штаны будущему себе.
>Я сам постоянно пишу на жс, это очень простой язык. Намного легче чем go или c.
Про сложные и простые языки пишут только хуесосы(то есть ты) которые ничего серьезного в жизни не писали. Основная проблема это не язык, а решение конкретной задачи под конкретную проблему так чтобы не насрать в штаны будущему себе.
жс это как луа кста. давно заметил, что между ними много общего, в жс любой объект это ассоциативный массив, тоже самое и в луа, где нет объектов, вместо них таблицы, ака ассоциативные массивы. далее динамическая типизация. ну и всё, поэтому их юзание примерно одинаковое.
>>24030
алсо жс это буквально браузерный дсл, если бы нетскейп рили решили заюзать лишп, то вебговно бы сейчас было на лишпе, или могли бы сделать другой дсл, похожий на смл или апл, но хотели сделать быстро и просто, поэтому сделали жс, может жс сейчас и тогда сильно отличаются, но кор составляющая думаю не изменилась.
алсо жс это буквально браузерный дсл, если бы нетскейп рили решили заюзать лишп, то вебговно бы сейчас было на лишпе, или могли бы сделать другой дсл, похожий на смл или апл, но хотели сделать быстро и просто, поэтому сделали жс, может жс сейчас и тогда сильно отличаются, но кор составляющая думаю не изменилась.
двежок писать рили тяжко, это же надо весь тулинг писать и библивотеки. пока есть только либа для линала, жипег импортер (только соф1), импортер обж файлов, импортер вав (надо сделать хотяб мп3, там наверное такие же принципы как с жипегом) и это только для одного ебучего куба. из этого только библевотекай для маняматики можно флексить, тк там имхо пиздато сделал, с проверкой возможности операций в комплтайме, типа перемножение матриц и кросспродукт. можно было бы даже ни жыдхаб выложить, если бы не О3 произведение матриц, штрассен вроде только 2.7 даёт, для показательной функции вроде значимо, но придётся лишиться комплтайм проверки, тк с женериками компилятору похуй, что M,N кейс и M = N = 2^K кейс разные. для этого надо какие-то констрейнты, а это уже ёбка с компилятором, проще дропнуть компл тайм фичу, но тогда всё переделывать и выйдет дженерик хуйня, которой не пофлексить. зато 2.7 для квадратных 2^K матриц, поэтому похуй. ну и впадлу, поэтому похуй.
>>24056
Чувак, ты с ума сошёл? Когда движок пишут, никто с нуля библиотеки не пишет. Всегда берут готовые и дописывают. Никто не изобретает всё с нуля, кроме рендера и "клея" между либами. Если так упёрлось улучшательство - берут либу и её дописывают, но не переделывают с нуля.
Писать свои либы - это удел сеньоров на зарплате, как это было с автором Jolt Physics и авторами либы с векторной математикой в Dagor Engine.
Ты похож на синьора, которому платят, чтобы он копался в говне, в котором по-настоящему разбираются два с половиной человека? Нет.
Научись разбираться в чужом коде, это будет гораздо более ценным приобретением, тогда ты сможешь с меньшими усилиями достичь большего. А иначе ты будешь вечно на этапе движков ранних нулевых, только твой одноколёсный велосипед будет ещё вечно падать и спотыкаться на ровном месте.
Будучи подобным "универсалом" ты никогда не напишешь движок с аналогом Havok и SteamAudio.
Чувак, ты с ума сошёл? Когда движок пишут, никто с нуля библиотеки не пишет. Всегда берут готовые и дописывают. Никто не изобретает всё с нуля, кроме рендера и "клея" между либами. Если так упёрлось улучшательство - берут либу и её дописывают, но не переделывают с нуля.
Писать свои либы - это удел сеньоров на зарплате, как это было с автором Jolt Physics и авторами либы с векторной математикой в Dagor Engine.
Ты похож на синьора, которому платят, чтобы он копался в говне, в котором по-настоящему разбираются два с половиной человека? Нет.
Научись разбираться в чужом коде, это будет гораздо более ценным приобретением, тогда ты сможешь с меньшими усилиями достичь большего. А иначе ты будешь вечно на этапе движков ранних нулевых, только твой одноколёсный велосипед будет ещё вечно падать и спотыкаться на ровном месте.
Будучи подобным "универсалом" ты никогда не напишешь движок с аналогом Havok и SteamAudio.
>>24066
я пишу
когда делал движок на C, написал библиотеки для чтения ini-файлов, для логгирования, для загрузки PNG, и матричную математику
на этом силы и движок закончились
ещё можете посмотреть курсы Casey Muratori, у него всё по олдскулу, без библиотек
я пишу
когда делал движок на C, написал библиотеки для чтения ini-файлов, для логгирования, для загрузки PNG, и матричную математику
на этом силы и движок закончились
ещё можете посмотреть курсы Casey Muratori, у него всё по олдскулу, без библиотек
если у вас цель делать движок - вы делаете движок и не делаете игру, тут всё просто
16 Кб, 952x229очередная годнота попалась в рекомендациях и как обычно делал чел, который уже походу помер
https://github.com/psydack/uimgui
https://github.com/psydack/uimgui
>>24019
У меня дохуя софта. Даже аналог Фотошопа есть с эффектами и умным удалением. Все свое, без библиотек .
Генераторы сайтов, умные дополнения для браузера.
>>24019
Дай угадаю. Ты пиздишь готовый код из интернета.
>которые ничего серьезного в жизни не писали
У меня дохуя софта. Даже аналог Фотошопа есть с эффектами и умным удалением. Все свое, без библиотек .
Генераторы сайтов, умные дополнения для браузера.
>>24019
>решение конкретной задачи под конкретную проблему
Дай угадаю. Ты пиздишь готовый код из интернета.
>>24369
Если у тебя нет игры, то её не могут отобрать. А ловко ты это придумал.
Если у тебя нет игры, то её не могут отобрать. А ловко ты это придумал.
Шизик блядь бампующий
>>19516
Выбор инструмента - просто потому что любишь раст - очень инженерненько.
Раст так нагнул, выбив всю любовь, что пришлось переписать все на юнити. А так как нечего толком не было сделано на любимом бойлерплейтном расте, переписали на настоящий движок всего за 6 недель.
Когда уже нейронка их заменит?
Выбор инструмента - просто потому что любишь раст - очень инженерненько.
Раст так нагнул, выбив всю любовь, что пришлось переписать все на юнити. А так как нечего толком не было сделано на любимом бойлерплейтном расте, переписали на настоящий движок всего за 6 недель.
Когда уже нейронка их заменит?
Ebitengine.
Гоферы свой движок пилят на го. Мнение? Го не позволяет в циклической импорт, как вообще кодить, то
Гоферы свой движок пилят на го. Мнение? Го не позволяет в циклической импорт, как вообще кодить, то
>>24632
Этот язык умер. Даже со всеми деньгами гугла он не взлетел.
Предлагаю форкнуть его, назвать Gos и переписать на нём Госуслуги. Тогда будущее появится.
>Go
Этот язык умер. Даже со всеми деньгами гугла он не взлетел.
Предлагаю форкнуть его, назвать Gos и переписать на нём Госуслуги. Тогда будущее появится.
>>24632
Уже обсуждали. Никто итт не знает язык. Пробовал какую то мини игры на мобиле, она лагала. Значит для мобил не подходит.
Уже обсуждали. Никто итт не знает язык. Пробовал какую то мини игры на мобиле, она лагала. Значит для мобил не подходит.
9 Кб, 190x441>>24633
Если отсортировать от 1000 звезд на гитхламе, то го входит в топ языков. Это, наверное самый активный из новых языков (или само-плюсуемый).
Если отсортировать от 1000 звезд на гитхламе, то го входит в топ языков. Это, наверное самый активный из новых языков (или само-плюсуемый).
>>24636
Линка
https://github.com/search?q=stars%3A%3E1000&type=repositories
забавно как работает мозг у местных фотошоперов, если они про технологию не слышали, значит она мертва, тем временем капитал кода Го уже догоняет джаву
Линка
https://github.com/search?q=stars%3A%3E1000&type=repositories
забавно как работает мозг у местных фотошоперов, если они про технологию не слышали, значит она мертва, тем временем капитал кода Го уже догоняет джаву
>>24638
Плохо живется, когда ты звездобол?
Плохо живется, когда ты звездобол?
>>24640
это не так
это не так
>>24634
Там у этой херни настолько примитивный и топорный синтаксис, что даже местные школьники осилят за неделю
>Никто итт не знает язык.
Там у этой херни настолько примитивный и топорный синтаксис, что даже местные школьники осилят за неделю
>>24652
purrnet who? and when? and why?
purrnet who? and when? and why?
Бля, как же обосрутся пшеки с уринал энжином, это будет эпично. Жаль только ждать ещё долго, лол. Нанитные деревья, вообще охуеть. Эта залупа еле пердит с тремя мешами, а они сотню туда засунули и затирают, что это работает на PS5. Конечно, именно поэтому весь ролик пререндер. Конечно.
>>24677
Да они и без урины обосрались в своё время на релизе ведьмак3 так-то. Чо уж тут.
Релизная версия ведьмака3 по сравнению с трейлерами испытала на себе все прелести даунгрейда и вырезни.
Чзх, Вавра был прав когда говорил про ведьмак в контексте урины на интервью?
Останется молиться лишь на то, что это была просто постановка и всё будет иначе.
Да они и без урины обосрались в своё время на релизе ведьмак3 так-то. Чо уж тут.
Релизная версия ведьмака3 по сравнению с трейлерами испытала на себе все прелести даунгрейда и вырезни.
Чзх, Вавра был прав когда говорил про ведьмак в контексте урины на интервью?
Останется молиться лишь на то, что это была просто постановка и всё будет иначе.
>>24682
Пока что нечего даунгрейдить, потому что игровых демо не было. Это было техдемо движка, которое к игре не относится. Это важный момент на самом деле. Они могут показывать техдемо с каждой фичей по отдельности, но собрать это в кучу? И чтобы не было 0.1 фпс? Успехов.
Про старые интервью есть это.
Но это уже устарело, потому что кое-что у них уже есть. Вопрос в том, как это работает и работает ли вообще.
Пока что нечего даунгрейдить, потому что игровых демо не было. Это было техдемо движка, которое к игре не относится. Это важный момент на самом деле. Они могут показывать техдемо с каждой фичей по отдельности, но собрать это в кучу? И чтобы не было 0.1 фпс? Успехов.
Про старые интервью есть это.
>В наши дни невозможно дать интервью без того, чтобы кто-то не переврал его и не раздул из него фальшивую полемику. Год назад я говорил о слабых и сильных сторонах игровых движков. Результат? Заголовки в духе «Вавра говорит, что The Witcher 4 находится в производственном аду». Нет, я этого не говорил. Извините.
>А теперь CD Projekt перешли на Unreal, хотя, на мой взгляд, у них был хороший собственный движок. Я говорил кое с кем, чье имя не могу назвать, и я спросил его, что там по Unreal. "Отлично, у нас есть кое-что готовое, например, ландшафты". А я спросил: "Ну а что там по открытому миру?". И он мне ответил: "Пока ничего".
Но это уже устарело, потому что кое-что у них уже есть. Вопрос в том, как это работает и работает ли вообще.
>>24689
они перешли на анрил через пару лет после начала разработки киберпанка 2077, где-то в 2017. вавра некомпетентный долбоёб, чья первая игра работала хуже киберпанка 2077 на релизе, и это без лучей и нанитов. и с его интервью люди ошибочно делают вывод будто сидипроджект только сейчас на анрил пересели в 2024 и сидят смотрят туторы как там делать игры. на самом деле ведьмак 4 уже глубоко в продакшне. то что они показали это и есть контент игры, просто обосранный декалями и дроуколлами и порендеренный не в реалтайме, как они всегда делали
другое дело, что использование нанита и лучей это в принципе удар по яйцам любой оптимизации. просто достаточно не юзать их, и в принципе сносная производительность будет. склеил hism дроуколлы и всё летает на 1060 в 60 фпс. а вот это придется оптимизировать. но спецы у них есть, которые глубоко шарят в движке и в видеокартах
они перешли на анрил через пару лет после начала разработки киберпанка 2077, где-то в 2017. вавра некомпетентный долбоёб, чья первая игра работала хуже киберпанка 2077 на релизе, и это без лучей и нанитов. и с его интервью люди ошибочно делают вывод будто сидипроджект только сейчас на анрил пересели в 2024 и сидят смотрят туторы как там делать игры. на самом деле ведьмак 4 уже глубоко в продакшне. то что они показали это и есть контент игры, просто обосранный декалями и дроуколлами и порендеренный не в реалтайме, как они всегда делали
другое дело, что использование нанита и лучей это в принципе удар по яйцам любой оптимизации. просто достаточно не юзать их, и в принципе сносная производительность будет. склеил hism дроуколлы и всё летает на 1060 в 60 фпс. а вот это придется оптимизировать. но спецы у них есть, которые глубоко шарят в движке и в видеокартах
>>24707
Не то, чтобы есть.
Many veteran developers who worked on previous projects like "The Witcher 3" have left CD Projekt Red to form their own studios. While some key figures like Piotr Tomsiński (Director of Technology) and Maciej Sawitus (Lead Multiplayer Programmer) remain, many have moved on, including those who have started new studios like Rebel Wolves
Проиграл с того, что у них вообще лид по мультиплееру есть. Лучи хуйня. Кожаный их ускоряет хардварно, с каждым поколением они всё быстрее. А вот нанит залупа другая, он софтварный полностью и быстрее никогда не станет. То же самое с люменом, он слишком медленный по дизайну. Редам придётся перепиливать половину движка и делать форк. Но УЕ из коробки не подходит для игр, даже эпики сделали отдельный форк, чтобы на нём пилить фортнайт, так что здесь ничего неожиданного.
>спецы у них есть
Не то, чтобы есть.
Many veteran developers who worked on previous projects like "The Witcher 3" have left CD Projekt Red to form their own studios. While some key figures like Piotr Tomsiński (Director of Technology) and Maciej Sawitus (Lead Multiplayer Programmer) remain, many have moved on, including those who have started new studios like Rebel Wolves
Проиграл с того, что у них вообще лид по мультиплееру есть. Лучи хуйня. Кожаный их ускоряет хардварно, с каждым поколением они всё быстрее. А вот нанит залупа другая, он софтварный полностью и быстрее никогда не станет. То же самое с люменом, он слишком медленный по дизайну. Редам придётся перепиливать половину движка и делать форк. Но УЕ из коробки не подходит для игр, даже эпики сделали отдельный форк, чтобы на нём пилить фортнайт, так что здесь ничего неожиданного.
>>24694
А чо мне терпеть то? Я тоже на урина5 сижу, только не использую наниты и мне норм.
А чо мне терпеть то? Я тоже на урина5 сижу, только не использую наниты и мне норм.
>>24708
в английском языке это слово применяется когда хочется спизднуть о чем-то чего ты не знаешь, но не оказаться фактическим пиздаболом
ясно, шиз
> Many
в английском языке это слово применяется когда хочется спизднуть о чем-то чего ты не знаешь, но не оказаться фактическим пиздаболом
>УЕ из коробки не подходит для игр
ясно, шиз
>>24707
Ну тут 50 на 50. Если бы KCD был на ue4-5, они бы перепилили его под себя и игра выглядела бы всё ровно хорошо. Но в урине нет (SVOGI) и это большой минус.
Поэтому насколько это на уровне фантазии - большой вопрос.
Сруенжин даже в виде форка от вавры сейчас в плане графики устарел прилично уже.
Для цельной картинки - норм, как и любая старая игра.
Оптимизация в KCD2 - моё почтение, даже на калькуляторах потянет.
Аналогичная игра на уе5 будет пердеть в таких-же условиях.
> вавра некомпетентный долбоёб
Ну тут 50 на 50. Если бы KCD был на ue4-5, они бы перепилили его под себя и игра выглядела бы всё ровно хорошо. Но в урине нет (SVOGI) и это большой минус.
Поэтому насколько это на уровне фантазии - большой вопрос.
Сруенжин даже в виде форка от вавры сейчас в плане графики устарел прилично уже.
Для цельной картинки - норм, как и любая старая игра.
Оптимизация в KCD2 - моё почтение, даже на калькуляторах потянет.
Аналогичная игра на уе5 будет пердеть в таких-же условиях.
>>24714
не могу вспомнить ни одной фичи, про которую сегодня можно было бы сказать - это устарело, и нынче заменено на другую технологию. типа FXAA или раннего SSAO с ореолами вокруг головы. что ты имеешь в виду?
> Сруенжин даже в виде форка от вавры сейчас в плане графики устарел прилично уже
не могу вспомнить ни одной фичи, про которую сегодня можно было бы сказать - это устарело, и нынче заменено на другую технологию. типа FXAA или раннего SSAO с ореолами вокруг головы. что ты имеешь в виду?
1,1 Мб, 1280x720>типа FXAA
Код из раннего FXAA, до улучшений качества и резкости, используется в каждом первом ТАА. Например, в анрил энжине. Так что нельзя сказать, что FXAA устарел полностью.
SSAO с ореолами был временной хернёй во всех играх буквально. Но у крайтека SSAO был очень качественный.
Технически, крайтековский движок на голову превосходит всё существующее. Может, кроме фростбайта. Но его слабость - в его силе. Сейчас используют трассировку лучей, хардварно ускоренную. А воксели программные. Потому могут быть медленнее. Но лучи никогда не создавались для рилтайма не работают без темпоральной аккумуляции, потому даже в теории не способны создавать чёткую картинку без размытия, гостинга, и т.д. А воксели могут.
>>24715
Если так подумать, так и есть. В плане целостной картинки в старых играх - все хорошо даже сейчас. И иногда даже лучше, чем в большинстве современных игр.
Поэтому про "устарела" - эт слишком громко сказано было.
Вспомнил просто "The Order 1886", который на момент релиза казался каким-то нереальнографонистым. А поиграв недавно и понял - мнение с тех пор не поменялось. Игра круто сделана, хотя это старичек которому уже 10 лет.
>про которую сегодня можно было бы сказать - это устарело
Если так подумать, так и есть. В плане целостной картинки в старых играх - все хорошо даже сейчас. И иногда даже лучше, чем в большинстве современных игр.
Поэтому про "устарела" - эт слишком громко сказано было.
Вспомнил просто "The Order 1886", который на момент релиза казался каким-то нереальнографонистым. А поиграв недавно и понял - мнение с тех пор не поменялось. Игра круто сделана, хотя это старичек которому уже 10 лет.
Зачем вы делаете движка с нуля для 2д игр? Используйте gdevelop или тот же phaser.
Godot так вообще топ.
Godot так вообще топ.
помню покупал банд с ассетами где-то за 2к, там был ассет JU TPS 2, так эти выблядские гнилые хуесосы выпилили эту версию из ассет стора и сделали JU TPS 3, интересно, в уринальном ассет сторе так же разводят гоев и фармят баблос?
856 Кб, 1115x1126Тим Суини пишет, что Unreal Engine перейдёт к координатам Left-Up-Forward, начиная с UEFN, а потом и в UE5-6 постепенно с помощью настроек в интерфейсе и вспомогательных функций/макросов для облегчения перехода.
Это позволит согласовать Unreal с Y-Up стандартами USD и glTF.
«Лучшим временем для внесения этих изменений был 1995 год, но я считаю, что сейчас тоже хорошая возможность, с запуском Scene Graph в UEFN».
Это позволит согласовать Unreal с Y-Up стандартами USD и glTF.
«Лучшим временем для внесения этих изменений был 1995 год, но я считаю, что сейчас тоже хорошая возможность, с запуском Scene Graph в UEFN».
61 Кб, 1237x387>>24779
Если ты действительно покупал этот ассет, то ты можешь его скачать с ассетстора и использовать его.
>там был ассет JU TPS 2
Если ты действительно покупал этот ассет, то ты можешь его скачать с ассетстора и использовать его.
3,6 Мб, mp4,1920x1080, 0:15
Ну как вы там потомки, годотя уже стала нормальным движком для игр?
>>24819
о, это же тот самый реквест игры от кирилла в 2015 году "комары, пчёлы, мухи"
о, это же тот самый реквест игры от кирилла в 2015 году "комары, пчёлы, мухи"
>>24819
Соулс лайк
Соулс лайк
ПИШЕШЬ ШЕЙДЕР
@
МАТРИЦЫ КАКОЕ-ТО ГОВНО
@
ПРОБУЕШЬ ВСЕ МАТРИЦЫ, КОТОРЫЕ ДОСТУПНЫ
@
ВСЕ КАКОЕ-ТО ГОВНО
@
НИХУЯ НЕ РАБОТАЕТ
@
ПРОЁБЫВАЕШЬ ДВА ДНЯ НИХУЯ НЕ ПОНИМАЯ
@
НЕ ПОНИМАЕШЬ В МАТРИЦАХ НИХУЯ, НО МОЖЕШЬ КОДИТЬ
@
ВРУЧНУЮ КОНСТРУИРУЕШЬ МАТРИЦЫ
@
ЗАЕБИСЬ
@
ЧЕРЕЗ ПАРУ ДНЕЙ ПИШЕШЬ ДРУГОЙ ШЕЙДЕР
@
ШЛЁШЬ БУФЕРЫ В GPU\CPU
@
НИХУЯ НЕ РАБОТАЕТ
@
ПОТОМУ ЧТО РЕНДЕРИНГ АСИНХРОННЫЙ
@
ПИШЕШЬ БЕЗОПАСНЫЙ БУФЕР
@
ДОХОДИШЬ ДО МАТРИЦ
@
НИХУЯ НЕ РАБОТАЕТ
@
ПРОЁБЫВАЕШЬ ЕЩЁ ТРИ ДНЯ
@
ПОНИМАЕШЬ, ЧТО МАТРИЦЫ ПРАВИЛЬНЫЕ
@
ПРОСТО ОНИ В ПРОСТРАНСТВЕ ОТНОСИТЕЛЬНО КАМЕРЫ
@
ВСТАЛ И ЗАКУРИЛ
@
МАТРИЦЫ КАКОЕ-ТО ГОВНО
@
ПРОБУЕШЬ ВСЕ МАТРИЦЫ, КОТОРЫЕ ДОСТУПНЫ
@
ВСЕ КАКОЕ-ТО ГОВНО
@
НИХУЯ НЕ РАБОТАЕТ
@
ПРОЁБЫВАЕШЬ ДВА ДНЯ НИХУЯ НЕ ПОНИМАЯ
@
НЕ ПОНИМАЕШЬ В МАТРИЦАХ НИХУЯ, НО МОЖЕШЬ КОДИТЬ
@
ВРУЧНУЮ КОНСТРУИРУЕШЬ МАТРИЦЫ
@
ЗАЕБИСЬ
@
ЧЕРЕЗ ПАРУ ДНЕЙ ПИШЕШЬ ДРУГОЙ ШЕЙДЕР
@
ШЛЁШЬ БУФЕРЫ В GPU\CPU
@
НИХУЯ НЕ РАБОТАЕТ
@
ПОТОМУ ЧТО РЕНДЕРИНГ АСИНХРОННЫЙ
@
ПИШЕШЬ БЕЗОПАСНЫЙ БУФЕР
@
ДОХОДИШЬ ДО МАТРИЦ
@
НИХУЯ НЕ РАБОТАЕТ
@
ПРОЁБЫВАЕШЬ ЕЩЁ ТРИ ДНЯ
@
ПОНИМАЕШЬ, ЧТО МАТРИЦЫ ПРАВИЛЬНЫЕ
@
ПРОСТО ОНИ В ПРОСТРАНСТВЕ ОТНОСИТЕЛЬНО КАМЕРЫ
@
ВСТАЛ И ЗАКУРИЛ
ПИШЕШЬ ШЕЙДЕР
@
МАТРИЦЫ КАКОЕ-ТО ГОВНО
@
ПРОБУЕШЬ ВСЕ МАТРИЦЫ, КОТОРЫЕ ДОСТУПНЫ
@
ВСЕ КАКОЕ-ТО ГОВНО
@
НИХУЯ НЕ РАБОТАЕТ
@
ПРОЁБЫВАЕШЬ ДВА ДНЯ НИХУЯ НЕ ПОНИМАЯ
@
НЕ ПОНИМАЕШЬ В МАТРИЦАХ НИХУЯ, НО МОЖЕШЬ КОДИТЬ
@
ВРУЧНУЮ КОНСТРУИРУЕШЬ МАТРИЦЫ
@
ЗАЕБИСЬ
@
ЧЕРЕЗ ПАРУ ДНЕЙ ПИШЕШЬ ДРУГОЙ ШЕЙДЕР
@
ШЛЁШЬ БУФЕРЫ В GPU\CPU
@
НИХУЯ НЕ РАБОТАЕТ
@
ПОТОМУ ЧТО РЕНДЕРИНГ АСИНХРОННЫЙ
@
ПИШЕШЬ БЕЗОПАСНЫЙ БУФЕР
@
ДОХОДИШЬ ДО МАТРИЦ
@
НИХУЯ НЕ РАБОТАЕТ
@
ПРОЁБЫВАЕШЬ ЕЩЁ ТРИ ДНЯ
@
ПОНИМАЕШЬ, ЧТО МАТРИЦЫ ПРАВИЛЬНЫЕ
@
ПРОСТО ОНИ В ПРОСТРАНСТВЕ ОТНОСИТЕЛЬНО КАМЕРЫ
@
ВСТАЛ И ЗАКУРИЛ
@
МАТРИЦЫ КАКОЕ-ТО ГОВНО
@
ПРОБУЕШЬ ВСЕ МАТРИЦЫ, КОТОРЫЕ ДОСТУПНЫ
@
ВСЕ КАКОЕ-ТО ГОВНО
@
НИХУЯ НЕ РАБОТАЕТ
@
ПРОЁБЫВАЕШЬ ДВА ДНЯ НИХУЯ НЕ ПОНИМАЯ
@
НЕ ПОНИМАЕШЬ В МАТРИЦАХ НИХУЯ, НО МОЖЕШЬ КОДИТЬ
@
ВРУЧНУЮ КОНСТРУИРУЕШЬ МАТРИЦЫ
@
ЗАЕБИСЬ
@
ЧЕРЕЗ ПАРУ ДНЕЙ ПИШЕШЬ ДРУГОЙ ШЕЙДЕР
@
ШЛЁШЬ БУФЕРЫ В GPU\CPU
@
НИХУЯ НЕ РАБОТАЕТ
@
ПОТОМУ ЧТО РЕНДЕРИНГ АСИНХРОННЫЙ
@
ПИШЕШЬ БЕЗОПАСНЫЙ БУФЕР
@
ДОХОДИШЬ ДО МАТРИЦ
@
НИХУЯ НЕ РАБОТАЕТ
@
ПРОЁБЫВАЕШЬ ЕЩЁ ТРИ ДНЯ
@
ПОНИМАЕШЬ, ЧТО МАТРИЦЫ ПРАВИЛЬНЫЕ
@
ПРОСТО ОНИ В ПРОСТРАНСТВЕ ОТНОСИТЕЛЬНО КАМЕРЫ
@
ВСТАЛ И ЗАКУРИЛ
неужели у нас научились в ААА
https://www.youtube.com/watch?v=dHGUBVYkdiw
https://www.youtube.com/watch?v=dHGUBVYkdiw
>>24924
Это не игровой процесс, а пререндер. Даже в нём навалили просто какое-то невообразимое количество DOF, чтобы скрыть всё, что можно. А движок всё тот же анрил, который работает так, что без ТАА - рендер разваливается на части. В игре будет ТАА, со всеми его проблемами и глитчами, потому что его не может не быть.
Это не игровой процесс, а пререндер. Даже в нём навалили просто какое-то невообразимое количество DOF, чтобы скрыть всё, что можно. А движок всё тот же анрил, который работает так, что без ТАА - рендер разваливается на части. В игре будет ТАА, со всеми его проблемами и глитчами, потому что его не может не быть.
>>24819
Делай
Делай
>>24924
Ты не на то обратил внимание. Вот реальный хидден гем:
https://www.youtube.com/watch?v=Ldb4yfUZXF4
Я, как любитель хорроров, в абсолютном восторге.
Ты не на то обратил внимание. Вот реальный хидден гем:
https://www.youtube.com/watch?v=Ldb4yfUZXF4
Я, как любитель хорроров, в абсолютном восторге.
170 Кб, mp4,278x482, 0:01
>>25006
она в разработке уже минимум 3 года, хотя в трейлерах не видно открытого мира, катсцен, только процедурные анимации и отрыв кусков мяса, которые они пиарили как что-то невероятное
она в разработке уже минимум 3 года, хотя в трейлерах не видно открытого мира, катсцен, только процедурные анимации и отрыв кусков мяса, которые они пиарили как что-то невероятное
248 Кб, 944x1888>>24652
Ебало аот компилятора представил? Можешь ознакомиться: https://docs.unity3d.com/6000.1/Documentation/Manual/scripting-restrictions.html
Ебало аот компилятора представил? Можешь ознакомиться: https://docs.unity3d.com/6000.1/Documentation/Manual/scripting-restrictions.html
341 Кб, 638x542>>25006
100% охуенности
100% охуенности
>>25008
Переоцениваешь данное поделие. Они так и не смогли сделать процедурку, там всё запеченная статика из 3D пакета.
> только процедурные анимации и отрыв кусков мяса, которые они пиарили как что-то невероятное
Переоцениваешь данное поделие. Они так и не смогли сделать процедурку, там всё запеченная статика из 3D пакета.
>>25117
База
База
>>25116
я не умею, не знаю и знать не хочу + я не знаю какие гайды хорошие для вката
>А чому сам не помоделишь, да не поанимируешь?
я не умею, не знаю и знать не хочу + я не знаю какие гайды хорошие для вката
у них походу какой-то анальник всё на ецс хочет перенести
https://unity.com/roadmap
https://unity.com/roadmap
>>25156
И уже давно. Но они, вроде, хотят чтобы под GO были ECS в итоге и плавно перейти на него полностью, так что это даже заебись в каком-то смысле.
И уже давно. Но они, вроде, хотят чтобы под GO были ECS в итоге и плавно перейти на него полностью, так что это даже заебись в каком-то смысле.
>>25204
А вот это уже шиза, кстати. Они разделяли URP и HDRP как могли. Чтоб ты понимал, в HDRP нет даже доступа к Render Graph, который во всём этом SRP рекламировался, как киллерфича.
А вот это уже шиза, кстати. Они разделяли URP и HDRP как могли. Чтоб ты понимал, в HDRP нет даже доступа к Render Graph, который во всём этом SRP рекламировался, как киллерфича.
Зачем вы делаете свои движки? Они никому не нужны. Делайте игры.
Но это не правда.
>Ряя нам так проще
Но это не правда.
>>25289
Потому что движок это реально просто. Думаешь, тут аноны пытаются новые горизонты компьютерной графики открыть? Нет. Просто сидишь и переписываешь алгоритмы с википедии. Это вам не геймдизайном заниматься.
Потому что движок это реально просто. Думаешь, тут аноны пытаются новые горизонты компьютерной графики открыть? Нет. Просто сидишь и переписываешь алгоритмы с википедии. Это вам не геймдизайном заниматься.
>>25289
Пилю движок внутри юнити. Ебанул куллинг, сейчас дописываю батчинг. И хули ты мне сделаешь?
Пилю движок внутри юнити. Ебанул куллинг, сейчас дописываю батчинг. И хули ты мне сделаешь?
41 Кб, 512x512делать тыгыдык или nagrizolich?
>>25429
второе может приносить в течении лет, думай
второе может приносить в течении лет, думай
>>25298
Если это было так просто, эти безыгорки смогли бы написать убивцу Юнити и Анрила, но что-то до сих пор не написали.
Правда в том, что на Педивикии описаны либо устаревшие, либо весьма тормозные алгоритмы для суперобщего случая, а реальные реализации с кучей подводной камней запрятаны в закромах студий.
И даже GDC здесь не поможет, если ты не знаешь математику на том же уровне, что и сеньоры на зарплате. Они-то выступают для таких же сеньоров, а не для недоучек вроде Хуана Линецкого.
Если это было так просто, эти безыгорки смогли бы написать убивцу Юнити и Анрила, но что-то до сих пор не написали.
Правда в том, что на Педивикии описаны либо устаревшие, либо весьма тормозные алгоритмы для суперобщего случая, а реальные реализации с кучей подводной камней запрятаны в закромах студий.
И даже GDC здесь не поможет, если ты не знаешь математику на том же уровне, что и сеньоры на зарплате. Они-то выступают для таких же сеньоров, а не для недоучек вроде Хуана Линецкого.
>>25511
Да хуй там. Это миллиард поддерживаемых рендеров и т.д. Я вот шейдеры пилю, на пекарне некрожелезо потянет, DX5+. Но для мобилочек это будет DX11 SM5, то есть ES 3.1. Современные мобилки потянут, более старые уже хуй. То есть нужен фоллбек для некроты, а мне лень. Плюс редактор, плюс сделать, чтобы даже идиот мог пользоваться и т.д. и т.п.
>написать убивцу Юнити и Анрила
Да хуй там. Это миллиард поддерживаемых рендеров и т.д. Я вот шейдеры пилю, на пекарне некрожелезо потянет, DX5+. Но для мобилочек это будет DX11 SM5, то есть ES 3.1. Современные мобилки потянут, более старые уже хуй. То есть нужен фоллбек для некроты, а мне лень. Плюс редактор, плюс сделать, чтобы даже идиот мог пользоваться и т.д. и т.п.
>>25511
Но ведь Фалько энджин уже написан!
>эти безыгорки смогли бы написать убивцу Юнити и Анрила, но что-то до сих пор не написали.
Но ведь Фалько энджин уже написан!
Посмотрел презентацию сидюков, въебал три дня и запилил свою реализацию подобного леса. Господи, как же это охуенно. Без программной децимации полигонов, конечно, но она и не нужна. Буквально миллионы полигонов можно рендерить. Ещё неделька на полировку, отладку и можно будет забрасывать код нахуй. Правда, трассировка лучей не работает, но мне как-то западло с ней разбираться, нужно шейдеркод писать и обновлять BVH регулярно, а это говно медленное, убьёт весь перформанс.
>>25540
Кому и кобыла база.
Кому и кобыла база.
мнение по данному существу?
>>25823
говноед говорит годот вкусненько
говноед говорит годот вкусненько
>>25823
Конеш вместо C# лучше освоить скрипто парашу написанную агрентинским пахомом. Не сделал игру - нечему тормозить.
Конеш вместо C# лучше освоить скрипто парашу написанную агрентинским пахомом. Не сделал игру - нечему тормозить.
>>25826
Так в годоте UniTask нету, потому за асинхронщину в нем реально надо пиздить
Так в годоте UniTask нету, потому за асинхронщину в нем реально надо пиздить
>>25832
Придется освоить потому что тяжелые вычисления в 4 годоте как ни странно лучше писать на гдс, потому что начиная с 4 версии он не зависит от гднатив и в целом работает достаточно быстро, хоть и писать на нем что-то сложнее скриптов для нод точно не стоит, лучше дружить с# как контроллер и гдс как некоторые тяжелые части представления
Придется освоить потому что тяжелые вычисления в 4 годоте как ни странно лучше писать на гдс, потому что начиная с 4 версии он не зависит от гднатив и в целом работает достаточно быстро, хоть и писать на нем что-то сложнее скриптов для нод точно не стоит, лучше дружить с# как контроллер и гдс как некоторые тяжелые части представления
>>25804
Это не плохо. Так то все языки достаточно лёгкие. Главное изучать как их правильно использовать. Я тут случайно создал улучшенный react для веба. Основную свою задачу он отрабатывает на ура.
Это не плохо. Так то все языки достаточно лёгкие. Главное изучать как их правильно использовать. Я тут случайно создал улучшенный react для веба. Основную свою задачу он отрабатывает на ура.
>>25823
Ну, пустт пилит на годоте если хочет
Ну, пустт пилит на годоте если хочет
>>25823
Так это безыгорный клоун, что с него взять.
Он игры не делал и не знает, как они делаются, но годот скачать мозгов хватило, поэтому будет верещать и копротивляться за аргентинского Пахома, в принципе не понимая и не осознавая что он несет.
Так это безыгорный клоун, что с него взять.
Он игры не делал и не знает, как они делаются, но годот скачать мозгов хватило, поэтому будет верещать и копротивляться за аргентинского Пахома, в принципе не понимая и не осознавая что он несет.
>>25511
А как ты напишешь убийцу анрила? Если анрил пилит целая команда уже почти 30 лет, это сотни и тысячи человеко-часов, огромный опыт нескольких поколений разработчиков, десятки реализованных и проданных на миллионные аудитории игр, которые позволили эпикам получить уникальный опыт и вложить его в последующие версии движка, это кодовая база, которая копилась и отваживалась десятилетиями.
Это просто невозможно повторить, простым смертным типа нас остается только пользоваться этим топовым инструментом для реализации своих идей, тут нечего больше выдумывать, анрил это просто топ.
Я тут недавно смотрел демки по фичам с процедурной генерацией, это просто вынос мозга, насколько это круто и технологично, даже не верится, что когда такое существует, находятся додики, которые в годоти пропукивают крутящиеся текстуры под полом, это просто разные вселенные.
А как ты напишешь убийцу анрила? Если анрил пилит целая команда уже почти 30 лет, это сотни и тысячи человеко-часов, огромный опыт нескольких поколений разработчиков, десятки реализованных и проданных на миллионные аудитории игр, которые позволили эпикам получить уникальный опыт и вложить его в последующие версии движка, это кодовая база, которая копилась и отваживалась десятилетиями.
Это просто невозможно повторить, простым смертным типа нас остается только пользоваться этим топовым инструментом для реализации своих идей, тут нечего больше выдумывать, анрил это просто топ.
Я тут недавно смотрел демки по фичам с процедурной генерацией, это просто вынос мозга, насколько это круто и технологично, даже не верится, что когда такое существует, находятся додики, которые в годоти пропукивают крутящиеся текстуры под полом, это просто разные вселенные.
>>25872
Чтобы убить анрил, нужно не движок разрабатывать, а физически убить руководство и основных держателей акций
Чтобы убить анрил, нужно не движок разрабатывать, а физически убить руководство и основных держателей акций
>>24819
Почему лягуха стреляет хуями?
Почему лягуха стреляет хуями?
>>25881
Норм движок без альтернатив если тебе надо C++ и ты не хочешь заниматься движкописьпись с нуля.
>Алло, анрил это калище.
Норм движок без альтернатив если тебе надо C++ и ты не хочешь заниматься движкописьпись с нуля.
>>25914
Для кого это говно сделано? Они видели что годот и его 2д корефан дефолд полностью бесплатны под максимально свободными лицензиями?
>дареному
>SAAS с месячной оплатой и шансом по желанию левой пятки автора остаться без лицензии или тебе ее не продлят
>андрюши нет
>гемблинг запрещён
Для кого это говно сделано? Они видели что годот и его 2д корефан дефолд полностью бесплатны под максимально свободными лицензиями?
>>25934
Не говоря уже о том что юнити имея в триллион нахуй больший функционал за 200 баксов дает возможность собираться под любое возможное старое и новое говно и делать практически любые игры которые только может потянуть индюк, на нормальном языке.
Не говоря уже о том что юнити имея в триллион нахуй больший функционал за 200 баксов дает возможность собираться под любое возможное старое и новое говно и делать практически любые игры которые только может потянуть индюк, на нормальном языке.
>>25940
Ты дурак или прикидываешься? Разницу между support и buy license осязаешь? Без ежемесячных 6 долларов в кассу ты на этом лохе не сможешь зарелизить платную игру, не говоря уже о том какой рак сам факт подписочности как таковой.
Ты дурак или прикидываешься? Разницу между support и buy license осязаешь? Без ежемесячных 6 долларов в кассу ты на этом лохе не сможешь зарелизить платную игру, не говоря уже о том какой рак сам факт подписочности как таковой.
581 Кб, 1220x2712>>25946
you should. Что такое "если можете", я хз, но по смыслу похоже на "заплатишь с профита". То есть как только твоя игра начнет продаваться крупно - к тебе придет с протянутой рукой эта хуйня и начнет трясти с тебя шекели. И да, я полностью прочитал их ебучую писанину по лицензиям.
Можно гемблинги, хентай, небо и даже аллаха
Никаких ебаных ограничений
Есть андроид
Поддержка нормальных языков
На список хитов уже давно не хватает всех пальцев включая 21
Признавайся, свою поделку сюда притащил и пиаришь?
you should. Что такое "если можете", я хз, но по смыслу похоже на "заплатишь с профита". То есть как только твоя игра начнет продаваться крупно - к тебе придет с протянутой рукой эта хуйня и начнет трясти с тебя шекели. И да, я полностью прочитал их ебучую писанину по лицензиям.
>олсо на годоте ты тоже не можешь зарелизить игру, но по другим причинам
Можно гемблинги, хентай, небо и даже аллаха
Никаких ебаных ограничений
Есть андроид
Поддержка нормальных языков
На список хитов уже давно не хватает всех пальцев включая 21
Признавайся, свою поделку сюда притащил и пиаришь?
>>25872
У тебя буквально существуют куча решений вроде Cryengine/Dagor и всякие middleware вроде Enlighten, PhysX, Umbra, всё уже решено за тебя.
Тебе не нужно это решать, если по какой-то причине Анрил не прёт. Я и говорю, что эти пердольки потому и пердольки, что по одиночке пишут проект, где нужен десяток синьоров.
У тебя буквально существуют куча решений вроде Cryengine/Dagor и всякие middleware вроде Enlighten, PhysX, Umbra, всё уже решено за тебя.
Тебе не нужно это решать, если по какой-то причине Анрил не прёт. Я и говорю, что эти пердольки потому и пердольки, что по одиночке пишут проект, где нужен десяток синьоров.
>>25540
Переношу из excel журнал склада в годот, 1С: Склад для лохов, игры для долбоёбов, вопросы?
Переношу из excel журнал склада в годот, 1С: Склад для лохов, игры для долбоёбов, вопросы?
>>25958
у меня там есть контент. правда твоя ссылка редиректит на
https://roadmap.luxeengine.com/tabs/1-current
у меня там есть контент. правда твоя ссылка редиректит на
https://roadmap.luxeengine.com/tabs/1-current
>>25957
Почему не асп+(блазор/реакт)? Ты ж по факту делаешь толстый клиент из-за чего потом придется переписывать, если это конечно не дипломная поделка. Еще и на говнокомпах не запустится или запустится только софтварно, что еще ухудшит скорость работы.
Почему не асп+(блазор/реакт)? Ты ж по факту делаешь толстый клиент из-за чего потом придется переписывать, если это конечно не дипломная поделка. Еще и на говнокомпах не запустится или запустится только софтварно, что еще ухудшит скорость работы.
>>25980
Так ты ебаться с годотом будешь дольше чем напишешь это на асп, где инструментарий есть под всё буквально с прицелом под твою задачу. 1с - тем более, кастомная конфигурация на управляемых формах тебе обойдется в неделю работы со всеми отчетами и можно будет это разворачивать в вебе в том числе. Заодно технологии подучишь, а не будешь воевать с лагающим юи годота не рассчитанным под такие задачи.
Так ты ебаться с годотом будешь дольше чем напишешь это на асп, где инструментарий есть под всё буквально с прицелом под твою задачу. 1с - тем более, кастомная конфигурация на управляемых формах тебе обойдется в неделю работы со всеми отчетами и можно будет это разворачивать в вебе в том числе. Заодно технологии подучишь, а не будешь воевать с лагающим юи годота не рассчитанным под такие задачи.
>>25965
потому что 1. автор шизик и 2. ничего кроме годота, не знает. первый движок и единственный
надо бы требовать у работников справку из ПНД, но видимо, ларёк "шаурма от Ашота", где трудится наш анончик, не может себе позволить такое
потому что 1. автор шизик и 2. ничего кроме годота, не знает. первый движок и единственный
надо бы требовать у работников справку из ПНД, но видимо, ларёк "шаурма от Ашота", где трудится наш анончик, не может себе позволить такое
я тоже как-то хотел использовать юнити для рендера кнопок и текста, ебало моё представили? а потом вспомнил, что можно всё захуячить на хтмл с жс и обернуть в электрон
>>25995
А че, с первого раза непонятно что элементы юи в игровых движках рендерятся не самым дешевым способом, а расчет привязок может дополнительно ухудшить состояние? Даже если бы мне было совсем нечего делать - я бы не стал так жестоко утилизировать свое время.
А че, с первого раза непонятно что элементы юи в игровых движках рендерятся не самым дешевым способом, а расчет привязок может дополнительно ухудшить состояние? Даже если бы мне было совсем нечего делать - я бы не стал так жестоко утилизировать свое время.
>>25992
А для чего тебе? На юнити есть свои прелести. Например это
https://github.com/XCharts-Team/XCharts
А для чего тебе? На юнити есть свои прелести. Например это
https://github.com/XCharts-Team/XCharts
>>25999
и чего? и что?
https://github.com/chartjs/Chart.js
если делать обычное приложение с текстом и картинками, то на игровых движках процесс разработки будет дольше идти, в вс код просто скачиваешь плагин лайв сервер, создаёшь хтмл файл, по нему правой кнопкой мыши и запускаешь сервер - всё нахуй, моментальные обновления при изменениях, всё быстрее, одни плюсы
и чего? и что?
https://github.com/chartjs/Chart.js
если делать обычное приложение с текстом и картинками, то на игровых движках процесс разработки будет дольше идти, в вс код просто скачиваешь плагин лайв сервер, создаёшь хтмл файл, по нему правой кнопкой мыши и запускаешь сервер - всё нахуй, моментальные обновления при изменениях, всё быстрее, одни плюсы
>>26000
текстовые квесты на годоте лагают, т.к. там каждая буква отрисовывается отдельным вызовом ррряяя это не так, в четвёртой версии пофиксили
текстовые квесты на годоте лагают, т.к. там каждая буква отрисовывается отдельным вызовом ррряяя это не так, в четвёртой версии пофиксили
>>25911
Очередная безыгорная пердотитя слепила кучку опенсорсных либ в один говняный глючный комок, и хочет за это денег по подписке, смешно
Очередная безыгорная пердотитя слепила кучку опенсорсных либ в один говняный глючный комок, и хочет за это денег по подписке, смешно
>>25956
Да это все фигня, развлекалово для пердотей
Инструментарий и рядом не стоит с тем, что дает анрил, особенно разрабу-одиночке или небольшой команде, когда каждый час на счету и ты либо делаешь игры, либо сливаешь время в пропукивание либ с гитхаба
> Cryengine/Dagor и всякие middleware вроде Enlighten, PhysX, Umbra
Да это все фигня, развлекалово для пердотей
Инструментарий и рядом не стоит с тем, что дает анрил, особенно разрабу-одиночке или небольшой команде, когда каждый час на счету и ты либо делаешь игры, либо сливаешь время в пропукивание либ с гитхаба
>>26005
нет, это не так
к тому же, это уже вторая версия движка
первая вышла в 2014 и была на Haxe https://github.com/snowkit/old-haxe-alpha
нет, это не так
к тому же, это уже вторая версия движка
первая вышла в 2014 и была на Haxe https://github.com/snowkit/old-haxe-alpha
>>26008
А сколько игр вышло на luxe с 2014 года, дай угадаю, ноль?
>>25911
https://anypercent.studio/team/
Это прямо комбо, 3 всратых транса-педераста делают движок. Еще и пытаются собирать деньги, не сделав ни одной игры на этом поделии. Как ты вообще смог отыскать настолько пидорский движок? Даже более пидорский чем wokot
А сколько игр вышло на luxe с 2014 года, дай угадаю, ноль?
>>25911
https://anypercent.studio/team/
Это прямо комбо, 3 всратых транса-педераста делают движок. Еще и пытаются собирать деньги, не сделав ни одной игры на этом поделии. Как ты вообще смог отыскать настолько пидорский движок? Даже более пидорский чем wokot
>>26009
С ВОЛКАМИ ЖИТЬ - ПО ВОЛЧЬИ ВЫТЬ!!!
С ВОЛКАМИ ЖИТЬ - ПО ВОЛЧЬИ ВЫТЬ!!!
>>26003
Где-то в разделе был чел когда-то, который пилил игоря, я у него как-то профилировал рендеринг. Вот у него так было. Только он пилил на движке от дума из 93 года, лол.
Решил тут уринал установить, охуел с того, что даже лаунчер лагает. Но потом посмотрел, не тормозит, просто эти калеки не вывезли плавный скролл. Контора рукожопов, всё через очко делают.
Где-то в разделе был чел когда-то, который пилил игоря, я у него как-то профилировал рендеринг. Вот у него так было. Только он пилил на движке от дума из 93 года, лол.
Решил тут уринал установить, охуел с того, что даже лаунчер лагает. Но потом посмотрел, не тормозит, просто эти калеки не вывезли плавный скролл. Контора рукожопов, всё через очко делают.
>>26014
лаунчер анрила это полный пиздец. так же известен как эпик гейм стор. причем он с 2014 такой, еще когда был лаунчером анрила, старого фортнита и ут2015
лаунчер анрила это полный пиздец. так же известен как эпик гейм стор. причем он с 2014 такой, еще когда был лаунчером анрила, старого фортнита и ут2015
3 Кб, 653x53>>26023
Двигло что-то тоже не лучше. На запуске жрал 10 гигов, через время уже 20. Большинство всей хуйни делает в один поток, приходится реально долго ждать, чтобы это говно раздуплилось. Зато может рендерить сцену. Но фпс скачет от 80 до 30 даже без движения камерой. Как-то всё печально пиздец.
Двигло что-то тоже не лучше. На запуске жрал 10 гигов, через время уже 20. Большинство всей хуйни делает в один поток, приходится реально долго ждать, чтобы это говно раздуплилось. Зато может рендерить сцену. Но фпс скачет от 80 до 30 даже без движения камерой. Как-то всё печально пиздец.
3 Кб, 722x41>>26049
распердится. первый запуск шейдеры компилируются, кэши кэшируются. 2,5 ГБ движок в базе кушает, остальное это ассеты в памяти
распердится. первый запуск шейдеры компилируются, кэши кэшируются. 2,5 ГБ движок в базе кушает, остальное это ассеты в памяти
32 Кб, 700x291>>26063
я после запуска хрюнити запускаю memreduct с такими настройками и оно чудесным образом выгружает дерьмо из оперативки, но есть шанс на краш (у меня пока не было)
я после запуска хрюнити запускаю memreduct с такими настройками и оно чудесным образом выгружает дерьмо из оперативки, но есть шанс на краш (у меня пока не было)
>>26067
ну это явный взлом
а вот софтом от него я бы какое-то время не пользовался, т.к. риск малвари вшитой
хуёво, симплволл крутая штука
ну это явный взлом
а вот софтом от него я бы какое-то время не пользовался, т.к. риск малвари вшитой
хуёво, симплволл крутая штука
>>26066
Да похуй на юнити, она всего 5 гигов жрёт. Хотя с ней другая беда, она стирает все ссылки на буферы, но не очищает их, так что у меня каждый релоад домейн память течёт. Хуй знает, что с этим делать.
Да похуй на юнити, она всего 5 гигов жрёт. Хотя с ней другая беда, она стирает все ссылки на буферы, но не очищает их, так что у меня каждый релоад домейн память течёт. Хуй знает, что с этим делать.
>>26068
Проверил вейбек машиной, как минимум с 24 апреля висит. Коммитов после этой даты дохуя. Плюс он в комментах придерживается той же точки зрения.
Проверил вейбек машиной, как минимум с 24 апреля висит. Коммитов после этой даты дохуя. Плюс он в комментах придерживается той же точки зрения.
>>26066
а что оно делает? забивает всю оперу, ждет когда операционка половину служб выгрузит в файл подкачки, потом освобождает?
>>26073
хуй знает. симплволлом лет 10 пользуюсь, этот казах раньше был в адеквате. и английский был нормальный у него
по-моему его акк кто-то увел, он там перманентно бодался с какими-то киберанархистами шизами
а что оно делает? забивает всю оперу, ждет когда операционка половину служб выгрузит в файл подкачки, потом освобождает?
>>26073
хуй знает. симплволлом лет 10 пользуюсь, этот казах раньше был в адеквате. и английский был нормальный у него
по-моему его акк кто-то увел, он там перманентно бодался с какими-то киберанархистами шизами
>>26074
ты щас если запустишь браузер, 20 разных вкладок или видео на ютубе посмотришь и закроешь браузер, то всякое остаточное дерьмо останется в ОЗУ и так со всем, мем редакт помогает это вычистить
>а что оно делает? забивает всю оперу, ждет когда операционка половину служб выгрузит в файл подкачки, потом освобождает?
ты щас если запустишь браузер, 20 разных вкладок или видео на ютубе посмотришь и закроешь браузер, то всякое остаточное дерьмо останется в ОЗУ и так со всем, мем редакт помогает это вычистить
>>26075
нет, по выходу из приложения память освобождаеется.
алсо, у тебя 8 гигов что ли? операционка делает кэши дллок, кэши нужны чтобы быстрее всё открывалось на горячую. рекомендую поставить больше оперы, а не дрочиться с виндой за гигабайты!
нет, по выходу из приложения память освобождаеется.
алсо, у тебя 8 гигов что ли? операционка делает кэши дллок, кэши нужны чтобы быстрее всё открывалось на горячую. рекомендую поставить больше оперы, а не дрочиться с виндой за гигабайты!
>>26007
А разработчики CoD, Battlefield, Doom, Wolfenstein, War Thunder этого не знают. Жаль, им твой ценный совет не пригодился.
А разработчики CoD, Battlefield, Doom, Wolfenstein, War Thunder этого не знают. Жаль, им твой ценный совет не пригодился.
Анрил на самом деле может дать профит только большой команде - им придётся писать только процентов 20-30 движка, а не 100. Для мелкой же команды профита нет, потому что 20 процентов движка переписывать это слишком дохуя, а без редактирования он к использованию непригоден.
67 Кб, 800x449ВЫШЕЛ ВЫШЕЛ ВЫШЕЛ!!!
Шикарно, лучший стал ещё лучше!
>The Open 3D Engine 25.05 release brings more improvements to its simulation capabilities, various Vulkan API improvements, continued performance and stability enhancements, overhauling the Trackview code, mature MGPU support, and other changes.
Шикарно, лучший стал ещё лучше!
>>26320
Пригоден. Только результат будет пиксельное инди хуинди хрючево, вроде псевдорегалии. Которое с одинаковым успехом может быть сделано как на юнити, так и на анриле. Да и на годоте тоже.
На данный момент больше вопросов к монетизации и лицензионному соглашению. А так же куда это все будет двигаться дальше. Челиков из юнити фаундейшн жаба давит, когда они видят доходы контор типа михуи с 9 нулями. И им очень хочется пропихнуть какой-нибудь метод, чтобы можно было поиметь со всех этих фритуплейных дрочилен какой-нибудь процент. Это отразится на всех. Первый раз не получилось. Все юнитиюзеры сидят как на иголках в ожидании следующего мува. У пользователей уе такого нет. Эпики сами делают успешную доильню. И еще держат магаз игор. Для них доход с движка - это лишь часть дохода. Их положение на рынке более стабильное, они более диверсифицированы. Им незачем крохоборствовать ценой потери репутации. Так же значительная часть контор, пользующихся уе, имеет экспертизу по созданию проприетарных движков. Те же сквари юзают для ремейков финалок уе, но они вполне могли бы делать их на своих движках, как новые номерные части. Если свиня совсем охуеет, то эти большие конторы достанут свою проприетарку и пошлют его нахуй. А конторы на юнити так не смогут. Большинству сразу же пизда настанет.
Пригоден. Только результат будет пиксельное инди хуинди хрючево, вроде псевдорегалии. Которое с одинаковым успехом может быть сделано как на юнити, так и на анриле. Да и на годоте тоже.
На данный момент больше вопросов к монетизации и лицензионному соглашению. А так же куда это все будет двигаться дальше. Челиков из юнити фаундейшн жаба давит, когда они видят доходы контор типа михуи с 9 нулями. И им очень хочется пропихнуть какой-нибудь метод, чтобы можно было поиметь со всех этих фритуплейных дрочилен какой-нибудь процент. Это отразится на всех. Первый раз не получилось. Все юнитиюзеры сидят как на иголках в ожидании следующего мува. У пользователей уе такого нет. Эпики сами делают успешную доильню. И еще держат магаз игор. Для них доход с движка - это лишь часть дохода. Их положение на рынке более стабильное, они более диверсифицированы. Им незачем крохоборствовать ценой потери репутации. Так же значительная часть контор, пользующихся уе, имеет экспертизу по созданию проприетарных движков. Те же сквари юзают для ремейков финалок уе, но они вполне могли бы делать их на своих движках, как новые номерные части. Если свиня совсем охуеет, то эти большие конторы достанут свою проприетарку и пошлют его нахуй. А конторы на юнити так не смогут. Большинству сразу же пизда настанет.
336 Кб, mp4,640x360, 0:04
>>26379
Проиграл нахуй. А спецов по их бздоте которых они разогнали чтобы нанять вместо них уринотерпавтов они достанут оттуда же? Эти конторы еще более зависимы чем инди, потому что для индусов выбор движков достаточно широк, включая бесплатные (разумеется они несравнимы с рыночными гигантами вроде юнити, но всё же позволяют делать игры категории 5-15$), то в случае ААААА - выбирать придется между 3 движками где есть готовые спецы - уепя, уеч, юнити и крайэнжин.
>Если свиня совсем охуеет, то эти большие конторы достанут свою проприетарку и пошлют его нахуй.
Проиграл нахуй. А спецов по их бздоте которых они разогнали чтобы нанять вместо них уринотерпавтов они достанут оттуда же? Эти конторы еще более зависимы чем инди, потому что для индусов выбор движков достаточно широк, включая бесплатные (разумеется они несравнимы с рыночными гигантами вроде юнити, но всё же позволяют делать игры категории 5-15$), то в случае ААААА - выбирать придется между 3 движками где есть готовые спецы - уепя, уеч, юнити и крайэнжин.
>>26379
А михуё всё, в домике. Есть китайский филиал юнити, который делает свою, китайскую версию движка. Известную, как Tuanjie engine. По сути, это 2022 LTS, но допиленный и улучшенный. Паритета по функциям нет, в нём есть некоторые фичи, недоступные даже юнити 6. Например, виртуальная геометрия а-ля наниты из УЕ. Давно есть и работает. Лицензируется он тоже абсолютно иначе. Например, ты покупаешь пул из 10 лицензий и в любое одновременное время 10 копий юнити могут пользоваться этой лицензией, без привязки к железу. Кто-то отключился - подключился другой комп с другим разработчиком.
Так вот, юнити чайна и михуё. Михуё владеет контрольным количеством акций компании, так что юнити не смотрит на доходы михуё. Юнити ничего не может сделать михуё, потому что михуё владеет юнити.
А михуё всё, в домике. Есть китайский филиал юнити, который делает свою, китайскую версию движка. Известную, как Tuanjie engine. По сути, это 2022 LTS, но допиленный и улучшенный. Паритета по функциям нет, в нём есть некоторые фичи, недоступные даже юнити 6. Например, виртуальная геометрия а-ля наниты из УЕ. Давно есть и работает. Лицензируется он тоже абсолютно иначе. Например, ты покупаешь пул из 10 лицензий и в любое одновременное время 10 копий юнити могут пользоваться этой лицензией, без привязки к железу. Кто-то отключился - подключился другой комп с другим разработчиком.
Так вот, юнити чайна и михуё. Михуё владеет контрольным количеством акций компании, так что юнити не смотрит на доходы михуё. Юнити ничего не может сделать михуё, потому что михуё владеет юнити.
>>26704
Лол он че на клаву смотрит чтобы печатать? Я думал все прогеры его уровня могут вслепую хуярить.
Лол он че на клаву смотрит чтобы печатать? Я думал все прогеры его уровня могут вслепую хуярить.
>>26711
Так он примерно с Дума перестал работать в одиночку, пора перестать его мифологизировать.
Так он примерно с Дума перестал работать в одиночку, пора перестать его мифологизировать.
>>26604
Делаю, но понимаю что зря. Лучше бы сразу на юнити делал.
Делаю, но понимаю что зря. Лучше бы сразу на юнити делал.
>>26704
за год дрочения клавы можно начать вслепую хуярить, хуете придумали образ короче
за год дрочения клавы можно начать вслепую хуярить, хуете придумали образ короче
>>26711
Так бывает с непривычной клавиатурой
Так бывает с непривычной клавиатурой
Что вам мешает вести уютный эмоционально окрашенный девложик и зарабатывать как успешный индюк?
https://www.youtube.com/watch?v=8skhP1U6FNE
https://www.youtube.com/watch?v=8skhP1U6FNE
>>26774
база
база
>>26782
не база
не база
можно на этих ваших движках делать игры про уничтожение жидокоммунистов? не думаю, у вас отберут движок, поэтому надо делать всё своё, они не смогут у вас ничего забрать. даже библиотеки нельзя будет использовать, их тоже отберут.
>>26907
Годот не отберут, лицензия не позволит. Просто хуан скажет что не отвечает за такое говно, уже один раз такие наезды на него были.
Годот не отберут, лицензия не позволит. Просто хуан скажет что не отвечает за такое говно, уже один раз такие наезды на него были.
>>26948
я лысый
я лысый
https://store.steampowered.com/app/3566840/Bleak_Haven/
Это соло инди проект на уепе. Покажите соло инди проект на годоте и юнете.
Это соло инди проект на уепе. Покажите соло инди проект на годоте и юнете.
>>26951
это ты на первом пике? дым от взрыва пиздец как выделяется, сразу видно, что готовый спизжен откуда-то и что тебя в этой игре впечатлило?
это ты на первом пике? дым от взрыва пиздец как выделяется, сразу видно, что готовый спизжен откуда-то и что тебя в этой игре впечатлило?
>>27019
Просто ебнутый ресентимент линуксоидов. Что угодно ебанутые сделают, лишь бы на нормальную ОС не пересесть. Смешно просто
Просто ебнутый ресентимент линуксоидов. Что угодно ебанутые сделают, лишь бы на нормальную ОС не пересесть. Смешно просто
>>27025
Насмешил. Мейнстримную, хомячок-френдли, корпоративно-легковстраиваемую, какую угодно но только не нормальную. Норма вообще понятие растяжимое. Для меня нормально выжимать из железа всё что у него есть но при этом иметь возможность жить скромно. Для моей мамы нормально когда не нужно думать, а просто запускать программы и побольше, чтобы еще в своп вылезти - вот тогда полный кайф.
>нормальную
Насмешил. Мейнстримную, хомячок-френдли, корпоративно-легковстраиваемую, какую угодно но только не нормальную. Норма вообще понятие растяжимое. Для меня нормально выжимать из железа всё что у него есть но при этом иметь возможность жить скромно. Для моей мамы нормально когда не нужно думать, а просто запускать программы и побольше, чтобы еще в своп вылезти - вот тогда полный кайф.
>>27019
Ты про Александр Егоров который зачем то скобки ставит вместо знаков?
Ты про Александр Егоров который зачем то скобки ставит вместо знаков?
Оказалось что я делал не движок, а аналог GDevelop. Пиздец
Единственный нормальный тред в гд, выхожу из него и как будто в психушке оказываюсь.
>>27261
Все ровно наоборот
Все ровно наоборот
>>26773
кстати говно совет. нужно делать именно игру мечты, а не ебучие бездушные кликеры.
потому что игру мечты можно клепать всю жизнь и получать дофамин, а на кликерах только выгоришь, и вместо геймдева, пойдешь на завод работать или в таксисты (и примеры таких есть)
ну и для рынка - индюки делающие игры мечты имеют ценность, а клепатели говна для гуглстора только мусором все засоряют.
примеры - даже какой-нибудь шизоид яндересимулятора в геймдеве имеет больше вес чем типичный мамкин бизнесмен яндекс стора, даже если последний вполне себе миллионы зарабатывает
>Что вам мешает вести уютный эмоционально окрашенный девложик и зарабатывать как успешный индюк?
кстати говно совет. нужно делать именно игру мечты, а не ебучие бездушные кликеры.
потому что игру мечты можно клепать всю жизнь и получать дофамин, а на кликерах только выгоришь, и вместо геймдева, пойдешь на завод работать или в таксисты (и примеры таких есть)
ну и для рынка - индюки делающие игры мечты имеют ценность, а клепатели говна для гуглстора только мусором все засоряют.
примеры - даже какой-нибудь шизоид яндересимулятора в геймдеве имеет больше вес чем типичный мамкин бизнесмен яндекс стора, даже если последний вполне себе миллионы зарабатывает
аноны, а я тут решил даунгрейднутся и делать игру как деды делали.
Я так подумал - я хочу игру в ретростиле. Не с еба графонием пыбыры и прочим. А что-нибудь в стиле первой кваки, с большими пикселями на полэкрана
но когда я начинаю что-то делать на opengl - я лезу в эти шейдеры, и тут надо тени, свет, всякие техники делать... надоело, так как слишком уводит от работы над проектом (вместо игры начинаю тени крутить)
сначала думал вообще софтрендер запилить, но потестил и понял что моих знаний не хватит чтобы вытянуть его на 60 фпс для того что я хочу в игре.
и тут мне внезапно вспомнилось - а ведь есть же древний ffp в openGL. Там же буквально есть все нужное для ретро - тени, свет, материал, туман
короче, начал ковырять - весело.
из забавного, узнал что в opengl 1.0 не было текстур - кекс. Они там были в виде расширения, а в стандарте не было. То есть наверняка существует видеокарта не умеющая в текстуры
текстуры появились в 1.1. также в 1.1 вместо begin-end появились vertex array (это по сути тоже самое begin-end, только сразу кидает весь массив верин, а не по одной).
кстати, странно что в то время уроки делали с begin-end если были эти массивы вершин
Я так подумал - я хочу игру в ретростиле. Не с еба графонием пыбыры и прочим. А что-нибудь в стиле первой кваки, с большими пикселями на полэкрана
но когда я начинаю что-то делать на opengl - я лезу в эти шейдеры, и тут надо тени, свет, всякие техники делать... надоело, так как слишком уводит от работы над проектом (вместо игры начинаю тени крутить)
сначала думал вообще софтрендер запилить, но потестил и понял что моих знаний не хватит чтобы вытянуть его на 60 фпс для того что я хочу в игре.
и тут мне внезапно вспомнилось - а ведь есть же древний ffp в openGL. Там же буквально есть все нужное для ретро - тени, свет, материал, туман
короче, начал ковырять - весело.
из забавного, узнал что в opengl 1.0 не было текстур - кекс. Они там были в виде расширения, а в стандарте не было. То есть наверняка существует видеокарта не умеющая в текстуры
текстуры появились в 1.1. также в 1.1 вместо begin-end появились vertex array (это по сути тоже самое begin-end, только сразу кидает весь массив верин, а не по одной).
кстати, странно что в то время уроки делали с begin-end если были эти массивы вершин
>>27261
Двачую.
Двачую.
>>27295
А во временя опенгл 1.0 уже был универсальный софт который запускался на рабочих станциях разных производителей?
А во временя опенгл 1.0 уже был универсальный софт который запускался на рабочих станциях разных производителей?
>>27314
используй жыэлтыэф
используй жыэлтыэф
>>27314
И в чём проблема?
И в чём проблема?
>>27396
Да блядь рендеринг всего, что угодно - дорого. Пытаюсь тут рендерить процедурную инстансированную растительность. Сука, дорого. Реально хоть на УЕ перекатывайся, там что ни делай - всегда низкий фпс, хоть вообще ничего не рендери, всё равно фпса нет. Так что можно смело накидывать говна в сцену. А тут чего-то накинул и сразу вентиляторы зажужжали, паника накатила, давай думать, хуле произошло и как с этим жить.
Да блядь рендеринг всего, что угодно - дорого. Пытаюсь тут рендерить процедурную инстансированную растительность. Сука, дорого. Реально хоть на УЕ перекатывайся, там что ни делай - всегда низкий фпс, хоть вообще ничего не рендери, всё равно фпса нет. Так что можно смело накидывать говна в сцену. А тут чего-то накинул и сразу вентиляторы зажужжали, паника накатила, давай думать, хуле произошло и как с этим жить.
>>27466
открой контору консультаций ааа студиям пдиз, тебе миллиарды геймеров будут благоджарны. да хотя бы даже аудитория фортнайта.
открой контору консультаций ааа студиям пдиз, тебе миллиарды геймеров будут благоджарны. да хотя бы даже аудитория фортнайта.
>>27488
Как оптимизацию делать секрета нет, проблема в том, что её надо делать и это затратно
Как оптимизацию делать секрета нет, проблема в том, что её надо делать и это затратно
>>27466
Ты его читэнжином сломал или что? У меня на пустой сцене не выше 75 фпс. С миллионами полигонов тоже же самые 75 фпс, но уже с рандомными просадками, хуй знает, почему
Ты его читэнжином сломал или что? У меня на пустой сцене не выше 75 фпс. С миллионами полигонов тоже же самые 75 фпс, но уже с рандомными просадками, хуй знает, почему
>>27488
в ААА считают что 60 фпс это припиздь этих так называемых "геймеров" и прочих токсичных сетевых сумасшедших, а у нормальных людей глаз выше 30 фпс не видит
в ААА считают что 60 фпс это припиздь этих так называемых "геймеров" и прочих токсичных сетевых сумасшедших, а у нормальных людей глаз выше 30 фпс не видит
>>27491
значит нужен движок где автоматом оптимизон.
в анриле пытались... а по факту на 4ом как раз много довольно быстрых игор
значит нужен движок где автоматом оптимизон.
в анриле пытались... а по факту на 4ом как раз много довольно быстрых игор
>>27498
Не, нихуя. Просто УЕ по какой-то причине не может в больший фпс. Я хуй знает, по чему и мне лень разбираться. Но когда пустая сцена рендерится в 75 фпс со статтерами, приходится жать альт+ф4 и забывать о движке навсегда. В целом, игры-то на нём идут точно так же, так что не моя проблема.
Не, нихуя. Просто УЕ по какой-то причине не может в больший фпс. Я хуй знает, по чему и мне лень разбираться. Но когда пустая сцена рендерится в 75 фпс со статтерами, приходится жать альт+ф4 и забывать о движке навсегда. В целом, игры-то на нём идут точно так же, так что не моя проблема.
>>27529
Значит, ты такой особенный, один на весь мир с машиной времени. Все жалуются, что уе статтерит даже в фортнайте, хотя казалось бы.
>У меня на фул ультрах 120 фпс во многих играх на уе
Значит, ты такой особенный, один на весь мир с машиной времени. Все жалуются, что уе статтерит даже в фортнайте, хотя казалось бы.
>>27531
Кто все? Пара сообщений это все?
Поищи на ютубе тестирование игр с нормальным мониторингом - это объективная статистика а не "ну все говорят)))"
Если ты решения оь испольщовании движка принимаешь в соответствии с "ну все говорят)))" то вряд ли ты разработкой игр всерьез занимаешься.
Кто все? Пара сообщений это все?
Поищи на ютубе тестирование игр с нормальным мониторингом - это объективная статистика а не "ну все говорят)))"
Если ты решения оь испольщовании движка принимаешь в соответствии с "ну все говорят)))" то вряд ли ты разработкой игр всерьез занимаешься.
>>27466
Это с каким железом такой фпс и что за настройки вообще?
Это с каким железом такой фпс и что за настройки вообще?
671 Кб, 3840x2160>>27533
Скачал, запустил. Фреймрейт рваный и в целом, низкий. Загуглил, сотни тысяч сообщений о том, что для уе это типично. Хули тут думать-то, движок не вывозит 720p без заиканий на 4090.
>решения оь испольщовании движка принимаешь в соответствии
Скачал, запустил. Фреймрейт рваный и в целом, низкий. Загуглил, сотни тысяч сообщений о том, что для уе это типично. Хули тут думать-то, движок не вывозит 720p без заиканий на 4090.
гои спок, время покупать новые гойкарты
>>27535
От разрешения рваность фреймрейта и статтеры никак не зависят абсолютно.
Если есть в 4к - будут и в 720р.
Рваный фреймрейт и статтеры могут быть только в таких случаях:
1. Упор в проц
2. Упор в пропускную способность оперативной памяии
3. Подгрузки с ожиданием с ссд
Ни на что из этого разрешение не влияет.
Почему ты пошёл в гугл, а не открыл профайлер?)
Почему ты о производительности судишь по редактору, а не билду, тоже не очень понятно.
Странности, странности.
Но я тебе даже заспойлерю - насколько мне известно, в уе с софтварным люменом есть проблемы при поворотах камеры и большом количестве объектов.
Вывод напрашивается сам собой, не так ли?
От разрешения рваность фреймрейта и статтеры никак не зависят абсолютно.
Если есть в 4к - будут и в 720р.
Рваный фреймрейт и статтеры могут быть только в таких случаях:
1. Упор в проц
2. Упор в пропускную способность оперативной памяии
3. Подгрузки с ожиданием с ссд
Ни на что из этого разрешение не влияет.
> Фреймрейт рваный и в целом, низкий. Загуглил
Почему ты пошёл в гугл, а не открыл профайлер?)
Почему ты о производительности судишь по редактору, а не билду, тоже не очень понятно.
Странности, странности.
Но я тебе даже заспойлерю - насколько мне известно, в уе с софтварным люменом есть проблемы при поворотах камеры и большом количестве объектов.
Вывод напрашивается сам собой, не так ли?
It's beginning...
>>27538
В январе эпики признавали, что у них есть пропуки с компиляцией шейдеров. И есть traversal статтеры, потому что уе не умеет в асинхронность. Ничего общего ни с упором в проц, ни в псп памяти, ни даже с ссд - это не имеет. Просто движок однопоточный и страдает из-за этого.
Так я увижу, что лагает вот конкретно у меня. При этом профайлер максимально неинформативный и выудить оттуда что-то та ещё задача. Гугл же по-быстрому ответил, что проблема фундаментальная, никаким профилированием не решается и движок статтерящий по дизайну.
>Рваный фреймрейт и статтеры могут быть только в таких случаях
В январе эпики признавали, что у них есть пропуки с компиляцией шейдеров. И есть traversal статтеры, потому что уе не умеет в асинхронность. Ничего общего ни с упором в проц, ни в псп памяти, ни даже с ссд - это не имеет. Просто движок однопоточный и страдает из-за этого.
>а не открыл профайлер
Так я увижу, что лагает вот конкретно у меня. При этом профайлер максимально неинформативный и выудить оттуда что-то та ещё задача. Гугл же по-быстрому ответил, что проблема фундаментальная, никаким профилированием не решается и движок статтерящий по дизайну.
>>27542
А потоки где? В жопе?)
Кажется, есть вполне конкретные пути этого избежать.
Многопоточность ты хотел сказать?
Ну посмотри сколько ядер игры на уе юзают.
Ну да. А тебе в чьей то другой причины статтеров надо искать, или в твоей?
Так по дизайну статеррящий, или у каждого свои проблемы как ты говоришь в предложении выше?
> Ничего общего ни с упором в проц, Просто движок однопоточный и страдает из-за этого.
А потоки где? В жопе?)
> есть пропуки с компиляцией шейдеров
Кажется, есть вполне конкретные пути этого избежать.
> И есть traversal статтеры, потому что уе не умеет в асинхронность
Многопоточность ты хотел сказать?
Ну посмотри сколько ядер игры на уе юзают.
> Так я увижу, что лагает вот конкретно у меня.
Ну да. А тебе в чьей то другой причины статтеров надо искать, или в твоей?
> движок статтерящий по дизайну.
Так по дизайну статеррящий, или у каждого свои проблемы как ты говоришь в предложении выше?
>>27543
Да пердит он из-за компиляции шейдеров, это база и фундамент. Избегать можно, но только предварительной компиляцией, а на такое нужны деньги. А еще натуральнейшая база любого программиста - "у меня на компьютере все ок, хз че там у пользователей не так, купите комп лучше" из уст какого нибудь маркетолуха/тимлида. И он будет совершенно прав, ведь у него большая часть шейдеров уже скомпилена и всё красиво. Но по итогу опять весь реддит засрали тем как фпс приседает со штангой в казалось бы совершенно не нагружающих моментах. Ну и конечно туман не скрывающий геометрию а просто проедающий фпс + наниты это клиника, лечится только инвазивным удалением макаки произведшей эдакое говно.
Да пердит он из-за компиляции шейдеров, это база и фундамент. Избегать можно, но только предварительной компиляцией, а на такое нужны деньги. А еще натуральнейшая база любого программиста - "у меня на компьютере все ок, хз че там у пользователей не так, купите комп лучше" из уст какого нибудь маркетолуха/тимлида. И он будет совершенно прав, ведь у него большая часть шейдеров уже скомпилена и всё красиво. Но по итогу опять весь реддит засрали тем как фпс приседает со штангой в казалось бы совершенно не нагружающих моментах. Ну и конечно туман не скрывающий геометрию а просто проедающий фпс + наниты это клиника, лечится только инвазивным удалением макаки произведшей эдакое говно.
>>27543
Эпики такого пути ещё не нашли, о чём сами же и говорили не так давно. И так как нет никого, кто знал бы движок лучше них, то и никто не нашёл.
Я хотел сказать именно то, что написал.
А смысл мне вылавливать конкретно мои статтеры? Я не отловлю таким образом статтеры у конечного пользователя, а это важнее, чем статтеры на машине разработчика.
>>27544
Сайлент хилл использует предварительную компиляцию. Но всё равно страдает от traversal статтеров и ещё хуй знает, от чего.
Технология очень хорошая, в реализациях от велосипедистов показывает очень достойный фпс. Странно, что у эпиков оно работает в обратную сторону.
>Кажется, есть вполне конкретные пути этого избежать.
Эпики такого пути ещё не нашли, о чём сами же и говорили не так давно. И так как нет никого, кто знал бы движок лучше них, то и никто не нашёл.
>Многопоточность ты хотел сказать
Я хотел сказать именно то, что написал.
> А тебе в чьей то другой причины статтеров надо искать, или в твоей?
А смысл мне вылавливать конкретно мои статтеры? Я не отловлю таким образом статтеры у конечного пользователя, а это важнее, чем статтеры на машине разработчика.
>>27544
>но только предварительной компиляцией
Сайлент хилл использует предварительную компиляцию. Но всё равно страдает от traversal статтеров и ещё хуй знает, от чего.
>наниты
Технология очень хорошая, в реализациях от велосипедистов показывает очень достойный фпс. Странно, что у эпиков оно работает в обратную сторону.
>>27546
их не нужно искать, они известны их два: или ты компилируешь шейдеры в процессе, или сразу. оба метода доступны как минимум с релизной версии 4 анрила (2014 год). эпики лишь могут сделать этот процесс быстрее и лучше, чем в других движках. и значит речь о том, что анрил делает (или будет делать) что-то лучше, чем делают другие движки
их не нужно искать, они известны их два: или ты компилируешь шейдеры в процессе, или сразу. оба метода доступны как минимум с релизной версии 4 анрила (2014 год). эпики лишь могут сделать этот процесс быстрее и лучше, чем в других движках. и значит речь о том, что анрил делает (или будет делать) что-то лучше, чем делают другие движки
>>27546
Ты хуйню какую то написал, асинхронность это понятие в ЯП.
Они у всех одинаковые будут.
> Я хотел сказать именно то, что написал.
Ты хуйню какую то написал, асинхронность это понятие в ЯП.
> А смысл мне вылавливать конкретно мои статтеры? Я не отловлю таким образом статтеры у конечного пользователя, а это важнее, чем статтеры на машине разработчика.
Они у всех одинаковые будут.
>>27548
окей, если это можно сделать, то где пример игры на 5 анриле в которой нет статтеринга?
окей, если это можно сделать, то где пример игры на 5 анриле в которой нет статтеринга?
Пиздец, вы погуглите list game engines, там и сука сотня, из них пол сотни бесплатных, для кого их делают? Игры на них вообще делают?
>>27595
но eyes не small, а narrow
но eyes не small, а narrow
>>27572
без индивидуального рассмотрения каждой проблемы - все игры на 5 анриле без статтеринга
без индивидуального рассмотрения каждой проблемы - все игры на 5 анриле без статтеринга
>>27578
ни для кого. есть куча движков, которые пилят уже по 20-30 лет, и на них практически нет игр, а те, что есть, чаще всего корявые поделки энтузиастов, сделанные по приколу ради идеи сделать игру на этом уебищном движке. юнижайн, панда3д, иррличт, копперкуб, дефолд, торк, езенжине, пико8, гздум, фалько, страйд. и прочая хуйня на коленке, которую тут форсят безыгорные-бездвижковые страдальцы
https://steamdb.info/tech/
ни для кого. есть куча движков, которые пилят уже по 20-30 лет, и на них практически нет игр, а те, что есть, чаще всего корявые поделки энтузиастов, сделанные по приколу ради идеи сделать игру на этом уебищном движке. юнижайн, панда3д, иррличт, копперкуб, дефолд, торк, езенжине, пико8, гздум, фалько, страйд. и прочая хуйня на коленке, которую тут форсят безыгорные-бездвижковые страдальцы
https://steamdb.info/tech/
>>27630
>>27631
попытки конкурировать с игровыми движками были. разрабы движка выпускали игры. поддерживают геймдевный тулинг, добавляют актуальные игровые платформы и сдк. и в целом активно поддерживают возможность использовать ПО как игровой движок
да и то для чего его применяют, технически от видеоигры ничем не отличается. те же яйца, просто называется по-другому
>>27636
этот прав
>>27631
попытки конкурировать с игровыми движками были. разрабы движка выпускали игры. поддерживают геймдевный тулинг, добавляют актуальные игровые платформы и сдк. и в целом активно поддерживают возможность использовать ПО как игровой движок
да и то для чего его применяют, технически от видеоигры ничем не отличается. те же яйца, просто называется по-другому
>>27636
этот прав
>>27629
Ебать, на хвалёном годоте ни одной нормальной игры, 2D инди гавно только, это прикол? Нахуй вы годот тогда пиарите?
Самый топ игр на cryengine сделан, он бесплатен, вот его надо брать.
И как в стимдб глянуть в инфе игры какой движ?
Ебать, на хвалёном годоте ни одной нормальной игры, 2D инди гавно только, это прикол? Нахуй вы годот тогда пиарите?
Самый топ игр на cryengine сделан, он бесплатен, вот его надо брать.
И как в стимдб глянуть в инфе игры какой движ?
>>27629
был актуальным движком Диснея до 2010 года, до 2020-ых использовался в аттракционах в Диснейленде и для обучения студентов в Carnegie Melon University, уже лет 15 как устарел
это рендерер, а не движок
это кал
имеет свою нишу - маленькие андроид и вебгл игры, хороший движок
когда-то был актуальным, сейчас сообщество пилит четвёртую версию, хз какой там прогресс
есть свой редактор и свой скриптовый язык
существует в двух ипостасях - torque 2d и torque 3d
есть потенциал
занимает свою нишу микродвижков
это движок для игр напотипо (sic) дума, занимает свою нишу
это не движок, а повод продавать бэклинки на сайте "сантехники Томска"
полноценный движок, но зачем он нужен, когда есть Unity?
> панда3д
был актуальным движком Диснея до 2010 года, до 2020-ых использовался в аттракционах в Диснейленде и для обучения студентов в Carnegie Melon University, уже лет 15 как устарел
> иррличт
это рендерер, а не движок
> копперкуб
это кал
>дефолд
имеет свою нишу - маленькие андроид и вебгл игры, хороший движок
>торк
когда-то был актуальным, сейчас сообщество пилит четвёртую версию, хз какой там прогресс
есть свой редактор и свой скриптовый язык
существует в двух ипостасях - torque 2d и torque 3d
>езенжине
есть потенциал
>пико8
занимает свою нишу микродвижков
>гздум
это движок для игр напотипо (sic) дума, занимает свою нишу
>фалько
это не движок, а повод продавать бэклинки на сайте "сантехники Томска"
>страйд
полноценный движок, но зачем он нужен, когда есть Unity?
>>27629
был актуальным движком Диснея до 2010 года, до 2020-ых использовался в аттракционах в Диснейленде и для обучения студентов в Carnegie Melon University, уже лет 15 как устарел
это рендерер, а не движок
это кал
имеет свою нишу - маленькие андроид и вебгл игры, хороший движок
когда-то был актуальным, сейчас сообщество пилит четвёртую версию, хз какой там прогресс
есть свой редактор и свой скриптовый язык
существует в двух ипостасях - torque 2d и torque 3d
есть потенциал
занимает свою нишу микродвижков
это движок для игр напотипо (sic) дума, занимает свою нишу
это не движок, а повод продавать бэклинки на сайте "сантехники Томска"
полноценный движок, но зачем он нужен, когда есть Unity?
> панда3д
был актуальным движком Диснея до 2010 года, до 2020-ых использовался в аттракционах в Диснейленде и для обучения студентов в Carnegie Melon University, уже лет 15 как устарел
> иррличт
это рендерер, а не движок
> копперкуб
это кал
>дефолд
имеет свою нишу - маленькие андроид и вебгл игры, хороший движок
>торк
когда-то был актуальным, сейчас сообщество пилит четвёртую версию, хз какой там прогресс
есть свой редактор и свой скриптовый язык
существует в двух ипостасях - torque 2d и torque 3d
>езенжине
есть потенциал
>пико8
занимает свою нишу микродвижков
>гздум
это движок для игр напотипо (sic) дума, занимает свою нишу
>фалько
это не движок, а повод продавать бэклинки на сайте "сантехники Томска"
>страйд
полноценный движок, но зачем он нужен, когда есть Unity?
>>27639
на первой страничке в карточке пишут движок, если распарсили
они движок определяют регулярками на базе имен файлов. некоторые движки не определяются (например, беви) или определяются с ошибками
на первой страничке в карточке пишут движок, если распарсили
они движок определяют регулярками на базе имен файлов. некоторые движки не определяются (например, беви) или определяются с ошибками
>>27629
На страйде есть относительно успешный по меркам остальных релиз, какой-то космосим. Выглядит честно на свои 5 баксов или сколько он там стоит. Дефолд как генератор html5 рекламы тоже сойдет. Остальное да, мусор без задач.
На страйде есть относительно успешный по меркам остальных релиз, какой-то космосим. Выглядит честно на свои 5 баксов или сколько он там стоит. Дефолд как генератор html5 рекламы тоже сойдет. Остальное да, мусор без задач.
>>27639
Там до 4 не было производительного 3д, только сейчас начал оформляться. Лучше скажи какой критерий нормальности у тебя для 3д игр. Вуконг? 3 витчер? Третий дарк?
Там до 4 не было производительного 3д, только сейчас начал оформляться. Лучше скажи какой критерий нормальности у тебя для 3д игр. Вуконг? 3 витчер? Третий дарк?
>>27548
Как видим, это не спасает от статтеров, СХ прекрасно это демонстрирует. Он делает прекомпиляцию, но статтерит. Возможно это связано с тем, что УЕ кеширует только четыре типа шейдеров. Возможно, с тем, что это не устраняет все остальные статтеры.
>>27561
Ты просто тупой.
>ли ты компилируешь шейдеры в процессе, или сразу.
Как видим, это не спасает от статтеров, СХ прекрасно это демонстрирует. Он делает прекомпиляцию, но статтерит. Возможно это связано с тем, что УЕ кеширует только четыре типа шейдеров. Возможно, с тем, что это не устраняет все остальные статтеры.
>>27561
>Ты хуйню какую то написал, асинхронность это понятие в ЯП.
Ты просто тупой.
>>27664
Нет, это ты тупой и пишешь слова значения которых не знаешь, так еще и то что ты подразумеваешь не соответствует действительности
> Ты просто тупой.
Нет, это ты тупой и пишешь слова значения которых не знаешь, так еще и то что ты подразумеваешь не соответствует действительности
>>27667
Расскажи что такое асинхронность и чем от многопотока отличается, как такой код выполняется вообще? Можешь в двух словах рассказать в чем собственно различия продвижения кода вперед по операциям в этих двух случаях, в предложение уложишься. Только без нейронок.
Расскажи что такое асинхронность и чем от многопотока отличается, как такой код выполняется вообще? Можешь в двух словах рассказать в чем собственно различия продвижения кода вперед по операциям в этих двух случаях, в предложение уложишься. Только без нейронок.
>>27669
Мне с самого начала было лень расписывать, а теперь так уж тем более, когда оппонент доказал полное непонимание вопроса. Главная проблема в синхронизации и её УЕ решает примерно никак, судя по заиканиям при загрузке и обновлении ресурсов. Асинхронности нет.
Мне с самого начала было лень расписывать, а теперь так уж тем более, когда оппонент доказал полное непонимание вопроса. Главная проблема в синхронизации и её УЕ решает примерно никак, судя по заиканиям при загрузке и обновлении ресурсов. Асинхронности нет.
>>27671
Тебе вообще другой анон ответил а не я лол.
Проблема в синхронизации чего? Как её можно не решить или решить?
Что за хуйню ты несешь?
Тебя выше правильно спросили про разницу асинхронности и многопоточности. Ты не понимаешь этого.
Тебе вообще другой анон ответил а не я лол.
> Главная проблема в синхронизации и её УЕ решает примерно никак, судя по заиканиям при загрузке и обновлении ресурсов.
Проблема в синхронизации чего? Как её можно не решить или решить?
Что за хуйню ты несешь?
> Асинхронности нет.
Тебя выше правильно спросили про разницу асинхронности и многопоточности. Ты не понимаешь этого.
>>27669
Асинхронность — это выполнение операций без блокировки потока (например, с колбэками или await), где одна задача может ждать I/O, пока выполняется другая, а многопоточность — это параллельное выполнение кода в разных потоках, где ОС переключает контекст между ними.
Разница в продвижении кода:
- В многопоточности код движется вперёд за счёт переключения между потоками (одновременно или псевдоодновременно).
- В асинхронности код движется вперёд за счёт переключения между задачами в одном потоке, когда одна задача ждёт, а другая использует CPU.
Коротко:
Многопоточность — параллелизм через потоки, асинхронность — кооперативная многозадачность в одном потоке.
Асинхронность — это выполнение операций без блокировки потока (например, с колбэками или await), где одна задача может ждать I/O, пока выполняется другая, а многопоточность — это параллельное выполнение кода в разных потоках, где ОС переключает контекст между ними.
Разница в продвижении кода:
- В многопоточности код движется вперёд за счёт переключения между потоками (одновременно или псевдоодновременно).
- В асинхронности код движется вперёд за счёт переключения между задачами в одном потоке, когда одна задача ждёт, а другая использует CPU.
Коротко:
Многопоточность — параллелизм через потоки, асинхронность — кооперативная многозадачность в одном потоке.
>>27664
и не должно. движок дает удочку, а не рыбу. если ты не умеешь ей пользоваться - это твоя проблема
>Как видим, это не спасает от статтеров
и не должно. движок дает удочку, а не рыбу. если ты не умеешь ей пользоваться - это твоя проблема
>>27675
Ты действительно тупой или притворяешься?
>Проблема в синхронизации чего? Как её можно не решить или решить?
Ты действительно тупой или притворяешься?
>>27572
В псевдорегалии нет статтеров
В псевдорегалии нет статтеров
По поводу шейдеров в уе
Большая часть материалов имеют общую структуру и там меняются лишь текстуры
Так в чем проблема сделать два-три материала и много инстансов с переключаемой текстурой?
Один материал для неживых предметов
Второй для органики с ссс
Третий для вфх с одной лишь прозрачностью и эмиссивом
Три шейдера на все случаи жизни блеать
Судя по всему, беда уе в том, что в нем свой шейдер на каждом объекте
Все из-за ебланов на блюпринтах, которые не понимают устройство своего движка
Большая часть материалов имеют общую структуру и там меняются лишь текстуры
Так в чем проблема сделать два-три материала и много инстансов с переключаемой текстурой?
Один материал для неживых предметов
Второй для органики с ссс
Третий для вфх с одной лишь прозрачностью и эмиссивом
Три шейдера на все случаи жизни блеать
Судя по всему, беда уе в том, что в нем свой шейдер на каждом объекте
Все из-за ебланов на блюпринтах, которые не понимают устройство своего движка
>>27685
Ты можешь дать й предложением предметныц ответ на поставленныц вопрос, вместо этого пишешь уже 2 сообщения с цирковоц клоунадой. Ну, продолжим.
Ты можешь дать й предложением предметныц ответ на поставленныц вопрос, вместо этого пишешь уже 2 сообщения с цирковоц клоунадой. Ну, продолжим.
>>27686
Проблема даже не в шейдерах, как таковых, а в их оптимизации. В DX 12 появились PSO, Pipeline State Object. Который включает в себя множество вещей, в том числе вертексы, пиксели и прочее. Для каждого объекта PSO - свой. Он не может быть построен универсально для каждого объекта, потому что архитектура GPU отличается. Ты можешь скомпилировать шейдеры заранее, но не можешь скомпилировать заранее PSO. И UE кеширует PSO, но только для четырёх видов шейдеров. То есть у тебя будет один шейдер, но PSO для куба с этим шейдером или для куска стены с этим же шейдером - будет отличаться. Что вызовет компиляцию PSO и статтер. И даже больше, эпики пытались сделать кеширование PSO, но так как для разных условий освещения и разной прочей херни нужны разные PSO, то они генерируют в пять раз больше кешей, чем на самом деле требуется. И это в пять раз дольше и, очевидно, усугубляет проблему. В данный момент есть предварительное кеширование PSO перед загрузкой, но только для четырёх типов шейдеров, это не устраняет проблему полностью. И только один из типов статтеров, от которых страдает УЕ.
>>27692
Прекращай позориться.
Проблема даже не в шейдерах, как таковых, а в их оптимизации. В DX 12 появились PSO, Pipeline State Object. Который включает в себя множество вещей, в том числе вертексы, пиксели и прочее. Для каждого объекта PSO - свой. Он не может быть построен универсально для каждого объекта, потому что архитектура GPU отличается. Ты можешь скомпилировать шейдеры заранее, но не можешь скомпилировать заранее PSO. И UE кеширует PSO, но только для четырёх видов шейдеров. То есть у тебя будет один шейдер, но PSO для куба с этим шейдером или для куска стены с этим же шейдером - будет отличаться. Что вызовет компиляцию PSO и статтер. И даже больше, эпики пытались сделать кеширование PSO, но так как для разных условий освещения и разной прочей херни нужны разные PSO, то они генерируют в пять раз больше кешей, чем на самом деле требуется. И это в пять раз дольше и, очевидно, усугубляет проблему. В данный момент есть предварительное кеширование PSO перед загрузкой, но только для четырёх типов шейдеров, это не устраняет проблему полностью. И только один из типов статтеров, от которых страдает УЕ.
>>27692
Прекращай позориться.
>>27686
так делать можно, материал в анриле это и есть база, которую ты можешь кастомизировать через инстансы
это не так. одинаковый шейдер наложенный на техничеки одинаковые объекты сгенерирует один шейдерный вариант. а в анриле это еще и склеится в один дроуколл
>>27696
тебя нейросеть подводит, ты сейчас полную хуйню написал
так делать можно, материал в анриле это и есть база, которую ты можешь кастомизировать через инстансы
>Судя по всему, беда уе в том, что в нем свой шейдер на каждом объекте
это не так. одинаковый шейдер наложенный на техничеки одинаковые объекты сгенерирует один шейдерный вариант. а в анриле это еще и склеится в один дроуколл
>>27696
тебя нейросеть подводит, ты сейчас полную хуйню написал
>>27698
Ебать долбоёб. Бегом читать документацию по УЕ, ты рассказываешь о том, в чём не шаришь.
>ты сейчас полную хуйню написал
Ебать долбоёб. Бегом читать документацию по УЕ, ты рассказываешь о том, в чём не шаришь.
>>27699
я понимаю, что ты пошуршал доками, нихуя там не понял и пошел ва-банк в надежде, что остальные тоже не разбираются и не увидят насколько ты далек от темы
я понимаю, что ты пошуршал доками, нихуя там не понял и пошел ва-банк в надежде, что остальные тоже не разбираются и не увидят насколько ты далек от темы
>>27702
Да нет, просто ты идиот и троллишь тупостью. А ещё не знаешь движок. Доки просто пруф того, что я и так знаю, в отличие от тебя, лол.
https://dev.epicgames.com/documentation/en-us/unreal-engine/optimizing-rendering-with-pso-caches-in-unreal-engine
Итого, PSO это не шейдер. Недостаточно поместить куб с нужным материалом под сцену и молиться, чтобы он скомпилировался. Нужен конкретно использующийся объект, потому что PSO включает в себя информацию о вершинах объекта, о параметрах материала и т.д. То есть два разных объекта с одним материалом будут генерировать разные PSO. И вызывать статтер.
Остальные типы шейдеров не поддерживают предварительное кеширование и будут вызывать статтеры. Это подтверждают сами эпики. Как и любой другой объект в памяти, PSO подвержен сборке сборщиком мусора, то есть один и тот же объект с одним и тем же материалом, но встреченный в разных частях уровня может и будет вызывать перекомпиляцию PSO. Да, это можно сгладить, заставив хранить N последних встреченных PSO, но если ассетов в игре много, то все хранить всё равно будет невозможно, потому что требуется множество разных PSO даже для одного объекта. Генерируется намного больше, чем на самом деле используется.
Чисто в теории этот уровень асинхронности должен устранять проблему статтеров. Проблема в том, что вызывается кеширование в момент появления объекта на экране, то есть рендеринг задерживается до завершения.
Эпики не считают статтеры меньше 20 мс проблемой, т.к их целевой фпс это 30.
Да нет, просто ты идиот и троллишь тупостью. А ещё не знаешь движок. Доки просто пруф того, что я и так знаю, в отличие от тебя, лол.
https://dev.epicgames.com/documentation/en-us/unreal-engine/optimizing-rendering-with-pso-caches-in-unreal-engine
Итого, PSO это не шейдер. Недостаточно поместить куб с нужным материалом под сцену и молиться, чтобы он скомпилировался. Нужен конкретно использующийся объект, потому что PSO включает в себя информацию о вершинах объекта, о параметрах материала и т.д. То есть два разных объекта с одним материалом будут генерировать разные PSO. И вызывать статтер.
>PSO precaching is currently implemented for the following global shader types:
>Slate
>Deferred Lights
>Cascade Particle Simulation
>Volumetric fog
Остальные типы шейдеров не поддерживают предварительное кеширование и будут вызывать статтеры. Это подтверждают сами эпики. Как и любой другой объект в памяти, PSO подвержен сборке сборщиком мусора, то есть один и тот же объект с одним и тем же материалом, но встреченный в разных частях уровня может и будет вызывать перекомпиляцию PSO. Да, это можно сгладить, заставив хранить N последних встреченных PSO, но если ассетов в игре много, то все хранить всё равно будет невозможно, потому что требуется множество разных PSO даже для одного объекта. Генерируется намного больше, чем на самом деле используется.
>By default, Unreal Engine uses a PSO precaching thread pool to compile the PSO asynchronously.
Чисто в теории этот уровень асинхронности должен устранять проблему статтеров. Проблема в том, что вызывается кеширование в момент появления объекта на экране, то есть рендеринг задерживается до завершения.
>A PSO compilation is marked as a hitch if the compilation took longer than a certain amount of milliseconds for the runtime PSO to be compiled. The default threshold is 20 milliseconds.
Эпики не считают статтеры меньше 20 мс проблемой, т.к их целевой фпс это 30.
53 Кб, 363x500>>27710
так а что поменялось в твоем аргументе? ты по-прежнему не понимаешь, о чем здесь речь, и генерируешь фрик-шоу через чатгпт
так а что поменялось в твоем аргументе? ты по-прежнему не понимаешь, о чем здесь речь, и генерируешь фрик-шоу через чатгпт
>>27718
Прекращай позориться.
>>27719
Про который из трёх, лол? Там столько всего нахуевертили, что по-быстрому не разберёшь. Что именно интересует-то? Юнити 6 добавили то же профилирование кеша PSO
https://www.youtube.com/watch?v=Zf5JobmI8L8
Только в отличие от UE, они не игнорируют дропы 20 мс, а считают худшее время кадра, среднее и лучшее. Это даёт более информативную статистику. В экспериментальном апи есть
https://docs.unity3d.com/6000.0/Documentation/ScriptReference/Experimental.Rendering.GraphicsStateCollection.html
Который позволяет управлять PSO вручную, в том числе сохранять на диск. Можно даже вызвать WarmUp, когда собрал коллекцию, но это не гарантирует прогрев всех вариантов PSO.
Прекращай позориться.
>>27719
Про который из трёх, лол? Там столько всего нахуевертили, что по-быстрому не разберёшь. Что именно интересует-то? Юнити 6 добавили то же профилирование кеша PSO
https://www.youtube.com/watch?v=Zf5JobmI8L8
Только в отличие от UE, они не игнорируют дропы 20 мс, а считают худшее время кадра, среднее и лучшее. Это даёт более информативную статистику. В экспериментальном апи есть
https://docs.unity3d.com/6000.0/Documentation/ScriptReference/Experimental.Rendering.GraphicsStateCollection.html
Который позволяет управлять PSO вручную, в том числе сохранять на диск. Можно даже вызвать WarmUp, когда собрал коллекцию, но это не гарантирует прогрев всех вариантов PSO.
>>27719
сразу спроси у чатгпт, больше толку будет. он оттуда копипастит
сразу спроси у чатгпт, больше толку будет. он оттуда копипастит
Делаю игру на 4 версии урины, есть ли смысл обновляться на 5.5 пока ещё можно обновиться? Слышал на 5ке производительность местами лучше чем 4. Какие подводные?
Ууу, бля. Короче про асинхронность.
Вот это в корне неправильно. У тебя может быть многопоток без асинхронности, однопоток без асинхронности или многопоток с асинхронностью. Прямой зависимости нихуя и нет. На педивикии есть хорошее определение асинхронности.
Асинхронность это парадигма. Это не потоки, один-два-много, даже не параллелизм или кооперативность.
Так вот, какого хуя компиляция PSO статтерит и на самом деле не асинхронная? А потому что, блядь, компиляция вызывается тогда, когда объект уже попал в кадр. Движок запускает хоть ебелион потоков для компиляции PSO, шейдеров, собачьей залупы. Но он не может отрендерить объект, так что основной поток блокируется до тех пор, пока PSO не будет готов. Блокируется. Это нарушает парадигму, хоть обмазывайся своими потоками до охуения. Настоящая асинхронность должна запускать компиляцию PSO в тихом режиме и сообщать потоку рендера, когда объект готов. И тогда рендер может его отобразить. Поток рендера при этом блокироваться не должен. Вот у нас и появилась асинхронность ебаная. А уж как оно будет реализовано - в одном потоке, в миллиарде - да поебать вообще. Абсолютно.
Вылезает другая загогулина. Если запускается компиляция тогда, когда объект уже в кадре, то его компиляция займёт несколько кадров и он появится внезапно, блядь, как снег в декабре. И хули делать? На уровне движка это всё решается в три строчки кода. Пять максимум. Кулинг здорового человека состоит из трёх этапов - грубая выборка, фруструм кулинг, оклюжн кулинг. Делаем грубую выборку, получаем объекты, которые потенциально могут попасть во фруструм. Их дохуя и больше, как правило. Юнити 5, насколько помню, скипал этот шаг вообще, потому я писал свои скрипты для грубой выборки, чтобы кулинг не сжирал весь фэпэс. Дальше берём наши ебаные плоскости окклюзии, шесть штук. Вкорячиваем сюда один дополнительный шаг - сдвигаем каждую плоскость по оси W на определённый коэффициент, для каждого свой. Зависит от темпа игры, если в ней крутишь башкой, как ебанутый, то бери побольше. Смекаете? Аккуратненько смещаем плоскость по нормали. У нас получился расширенный фруструм, в который попало больше, чем в итоге попадёт на экран. Теперь делаем обычный куллинг с обычными плейнами и из результатов первого куллинга вычитаем результаты второго. Это объекты, которые потенциально попадут на экран в течении нескольких кадров, но в данный момент в кадре не находятся. Дальше остаётся два списка объектов, один - сами догадаетесь какой - упёздывает на оклюжн кулинг и дальше на рендеринг. Остаются наши кандидаты на видимость. И вот уже для них нужно запустить компиляцию PSO. В фоне, без блокировочек. Если коэффициент расширения фруструма подобран верно или хотя бы с запасом - то к моменту попадания в действительный список рендеринга объекты уже готовы. Прогреты, прокомпилированы и надрочены. Пять ебаных строк кода.
>В асинхронности код движется вперёд за счёт переключения между задачами в одном потоке
Вот это в корне неправильно. У тебя может быть многопоток без асинхронности, однопоток без асинхронности или многопоток с асинхронностью. Прямой зависимости нихуя и нет. На педивикии есть хорошее определение асинхронности.
>Асинхронные действия — действия, выполненные в неблокирующем режиме, что позволяет основному потоку программы продолжить обработку
Асинхронность это парадигма. Это не потоки, один-два-много, даже не параллелизм или кооперативность.
Так вот, какого хуя компиляция PSO статтерит и на самом деле не асинхронная? А потому что, блядь, компиляция вызывается тогда, когда объект уже попал в кадр. Движок запускает хоть ебелион потоков для компиляции PSO, шейдеров, собачьей залупы. Но он не может отрендерить объект, так что основной поток блокируется до тех пор, пока PSO не будет готов. Блокируется. Это нарушает парадигму, хоть обмазывайся своими потоками до охуения. Настоящая асинхронность должна запускать компиляцию PSO в тихом режиме и сообщать потоку рендера, когда объект готов. И тогда рендер может его отобразить. Поток рендера при этом блокироваться не должен. Вот у нас и появилась асинхронность ебаная. А уж как оно будет реализовано - в одном потоке, в миллиарде - да поебать вообще. Абсолютно.
Вылезает другая загогулина. Если запускается компиляция тогда, когда объект уже в кадре, то его компиляция займёт несколько кадров и он появится внезапно, блядь, как снег в декабре. И хули делать? На уровне движка это всё решается в три строчки кода. Пять максимум. Кулинг здорового человека состоит из трёх этапов - грубая выборка, фруструм кулинг, оклюжн кулинг. Делаем грубую выборку, получаем объекты, которые потенциально могут попасть во фруструм. Их дохуя и больше, как правило. Юнити 5, насколько помню, скипал этот шаг вообще, потому я писал свои скрипты для грубой выборки, чтобы кулинг не сжирал весь фэпэс. Дальше берём наши ебаные плоскости окклюзии, шесть штук. Вкорячиваем сюда один дополнительный шаг - сдвигаем каждую плоскость по оси W на определённый коэффициент, для каждого свой. Зависит от темпа игры, если в ней крутишь башкой, как ебанутый, то бери побольше. Смекаете? Аккуратненько смещаем плоскость по нормали. У нас получился расширенный фруструм, в который попало больше, чем в итоге попадёт на экран. Теперь делаем обычный куллинг с обычными плейнами и из результатов первого куллинга вычитаем результаты второго. Это объекты, которые потенциально попадут на экран в течении нескольких кадров, но в данный момент в кадре не находятся. Дальше остаётся два списка объектов, один - сами догадаетесь какой - упёздывает на оклюжн кулинг и дальше на рендеринг. Остаются наши кандидаты на видимость. И вот уже для них нужно запустить компиляцию PSO. В фоне, без блокировочек. Если коэффициент расширения фруструма подобран верно или хотя бы с запасом - то к моменту попадания в действительный список рендеринга объекты уже готовы. Прогреты, прокомпилированы и надрочены. Пять ебаных строк кода.
Ууу, бля. Короче про асинхронность.
Вот это в корне неправильно. У тебя может быть многопоток без асинхронности, однопоток без асинхронности или многопоток с асинхронностью. Прямой зависимости нихуя и нет. На педивикии есть хорошее определение асинхронности.
Асинхронность это парадигма. Это не потоки, один-два-много, даже не параллелизм или кооперативность.
Так вот, какого хуя компиляция PSO статтерит и на самом деле не асинхронная? А потому что, блядь, компиляция вызывается тогда, когда объект уже попал в кадр. Движок запускает хоть ебелион потоков для компиляции PSO, шейдеров, собачьей залупы. Но он не может отрендерить объект, так что основной поток блокируется до тех пор, пока PSO не будет готов. Блокируется. Это нарушает парадигму, хоть обмазывайся своими потоками до охуения. Настоящая асинхронность должна запускать компиляцию PSO в тихом режиме и сообщать потоку рендера, когда объект готов. И тогда рендер может его отобразить. Поток рендера при этом блокироваться не должен. Вот у нас и появилась асинхронность ебаная. А уж как оно будет реализовано - в одном потоке, в миллиарде - да поебать вообще. Абсолютно.
Вылезает другая загогулина. Если запускается компиляция тогда, когда объект уже в кадре, то его компиляция займёт несколько кадров и он появится внезапно, блядь, как снег в декабре. И хули делать? На уровне движка это всё решается в три строчки кода. Пять максимум. Кулинг здорового человека состоит из трёх этапов - грубая выборка, фруструм кулинг, оклюжн кулинг. Делаем грубую выборку, получаем объекты, которые потенциально могут попасть во фруструм. Их дохуя и больше, как правило. Юнити 5, насколько помню, скипал этот шаг вообще, потому я писал свои скрипты для грубой выборки, чтобы кулинг не сжирал весь фэпэс. Дальше берём наши ебаные плоскости окклюзии, шесть штук. Вкорячиваем сюда один дополнительный шаг - сдвигаем каждую плоскость по оси W на определённый коэффициент, для каждого свой. Зависит от темпа игры, если в ней крутишь башкой, как ебанутый, то бери побольше. Смекаете? Аккуратненько смещаем плоскость по нормали. У нас получился расширенный фруструм, в который попало больше, чем в итоге попадёт на экран. Теперь делаем обычный куллинг с обычными плейнами и из результатов первого куллинга вычитаем результаты второго. Это объекты, которые потенциально попадут на экран в течении нескольких кадров, но в данный момент в кадре не находятся. Дальше остаётся два списка объектов, один - сами догадаетесь какой - упёздывает на оклюжн кулинг и дальше на рендеринг. Остаются наши кандидаты на видимость. И вот уже для них нужно запустить компиляцию PSO. В фоне, без блокировочек. Если коэффициент расширения фруструма подобран верно или хотя бы с запасом - то к моменту попадания в действительный список рендеринга объекты уже готовы. Прогреты, прокомпилированы и надрочены. Пять ебаных строк кода.
>В асинхронности код движется вперёд за счёт переключения между задачами в одном потоке
Вот это в корне неправильно. У тебя может быть многопоток без асинхронности, однопоток без асинхронности или многопоток с асинхронностью. Прямой зависимости нихуя и нет. На педивикии есть хорошее определение асинхронности.
>Асинхронные действия — действия, выполненные в неблокирующем режиме, что позволяет основному потоку программы продолжить обработку
Асинхронность это парадигма. Это не потоки, один-два-много, даже не параллелизм или кооперативность.
Так вот, какого хуя компиляция PSO статтерит и на самом деле не асинхронная? А потому что, блядь, компиляция вызывается тогда, когда объект уже попал в кадр. Движок запускает хоть ебелион потоков для компиляции PSO, шейдеров, собачьей залупы. Но он не может отрендерить объект, так что основной поток блокируется до тех пор, пока PSO не будет готов. Блокируется. Это нарушает парадигму, хоть обмазывайся своими потоками до охуения. Настоящая асинхронность должна запускать компиляцию PSO в тихом режиме и сообщать потоку рендера, когда объект готов. И тогда рендер может его отобразить. Поток рендера при этом блокироваться не должен. Вот у нас и появилась асинхронность ебаная. А уж как оно будет реализовано - в одном потоке, в миллиарде - да поебать вообще. Абсолютно.
Вылезает другая загогулина. Если запускается компиляция тогда, когда объект уже в кадре, то его компиляция займёт несколько кадров и он появится внезапно, блядь, как снег в декабре. И хули делать? На уровне движка это всё решается в три строчки кода. Пять максимум. Кулинг здорового человека состоит из трёх этапов - грубая выборка, фруструм кулинг, оклюжн кулинг. Делаем грубую выборку, получаем объекты, которые потенциально могут попасть во фруструм. Их дохуя и больше, как правило. Юнити 5, насколько помню, скипал этот шаг вообще, потому я писал свои скрипты для грубой выборки, чтобы кулинг не сжирал весь фэпэс. Дальше берём наши ебаные плоскости окклюзии, шесть штук. Вкорячиваем сюда один дополнительный шаг - сдвигаем каждую плоскость по оси W на определённый коэффициент, для каждого свой. Зависит от темпа игры, если в ней крутишь башкой, как ебанутый, то бери побольше. Смекаете? Аккуратненько смещаем плоскость по нормали. У нас получился расширенный фруструм, в который попало больше, чем в итоге попадёт на экран. Теперь делаем обычный куллинг с обычными плейнами и из результатов первого куллинга вычитаем результаты второго. Это объекты, которые потенциально попадут на экран в течении нескольких кадров, но в данный момент в кадре не находятся. Дальше остаётся два списка объектов, один - сами догадаетесь какой - упёздывает на оклюжн кулинг и дальше на рендеринг. Остаются наши кандидаты на видимость. И вот уже для них нужно запустить компиляцию PSO. В фоне, без блокировочек. Если коэффициент расширения фруструма подобран верно или хотя бы с запасом - то к моменту попадания в действительный список рендеринга объекты уже готовы. Прогреты, прокомпилированы и надрочены. Пять ебаных строк кода.
>>27774
Можно просто скомпилировать все возможные PSO заранее. У меня двигло так и делает.
Можно просто скомпилировать все возможные PSO заранее. У меня двигло так и делает.
>>27696
Нет. Для каждого сочетания шейдеров с возможными состоянием рендера (блендинг и всё такое). Если стена и куб используют тот же тип материала, тот же блендинг и всё такое - то PSO будет у них общее. Проблема движков типа UE в том что там триллион возможных PSO из за множества разных шейдеров, создаваемых художниками и ты их хуй заранее все скомплируешь.
>>27686
В нормальных движках так и делают. Но у тебя всё равно будут разные комбинации с блендингом и без, с альфа-тестом и без и так далее.
> Для каждого объекта PSO - свой.
Нет. Для каждого сочетания шейдеров с возможными состоянием рендера (блендинг и всё такое). Если стена и куб используют тот же тип материала, тот же блендинг и всё такое - то PSO будет у них общее. Проблема движков типа UE в том что там триллион возможных PSO из за множества разных шейдеров, создаваемых художниками и ты их хуй заранее все скомплируешь.
>>27686
В нормальных движках так и делают. Но у тебя всё равно будут разные комбинации с блендингом и без, с альфа-тестом и без и так далее.
>>27809
Начинай.
Начинай.
>>27800
д - дебил
>PSO включает в себя байткод вершин, так что если меши отличаются - то они не могут использовать общий PSO.
д - дебил
>>27816
Быстро идёшь читать справку по DX12 и прекращаешь троллинг тупостью. Или просто идёшь нахуй, мне похуй.
Быстро идёшь читать справку по DX12 и прекращаешь троллинг тупостью. Или просто идёшь нахуй, мне похуй.
>>27817
ту самую, которую ты сейчас лихорадочно шерудишь и пытаешься выдавать аргументы по теме, в которой нихуя не понимаешь?
ну открыл. вижу, где ты проебался, перепутав байткод шейдеров и вершинных лейаутов. действительно два абзаца рядом. действительно дурачку легко ошибиться, особенно когда английский на уровне селюка с тремя классами церковно-приходской
ту самую, которую ты сейчас лихорадочно шерудишь и пытаешься выдавать аргументы по теме, в которой нихуя не понимаешь?
ну открыл. вижу, где ты проебался, перепутав байткод шейдеров и вершинных лейаутов. действительно два абзаца рядом. действительно дурачку легко ошибиться, особенно когда английский на уровне селюка с тремя классами церковно-приходской
>>27800
Зачем террабайты? Тебе просто не надо иметь сотни тысяч PSO, достаточно несколько сотен. Беда анрыла в том что он универсален, в нём очень много материалов, а каждый материал создаёт сотни возможных PSO. В каком нибудь думе количество возможных PSO исчисляется всего лишь сотнями, они очень тщательно за этим следят.
Если форма вершин отличается. Если у тебя меши того же формата, с теми же шейдерами и прочими настройками - то к ним применим тот же PSO. У тебя формат вершин для стены и для куба разный? Скорее всего нет.
> Это же терабайты данных буквально.
Зачем террабайты? Тебе просто не надо иметь сотни тысяч PSO, достаточно несколько сотен. Беда анрыла в том что он универсален, в нём очень много материалов, а каждый материал создаёт сотни возможных PSO. В каком нибудь думе количество возможных PSO исчисляется всего лишь сотнями, они очень тщательно за этим следят.
> байткод вершин, так что если меши отличаются
Если форма вершин отличается. Если у тебя меши того же формата, с теми же шейдерами и прочими настройками - то к ним применим тот же PSO. У тебя формат вершин для стены и для куба разный? Скорее всего нет.
>>27826
Прекращай позориться.
>>27829
Затем, что PSO архитектурно зависим. Даже обновление драйвера делает PSO устаревшим. PSO для 1080 не работает на 3060. И так далее. Так что делаешь один материал, считаешь его количество PSO. Умножаешь на количество поддерживаемых видеокарт, умножаешь на количество драйверов и так далее. На консолях именно поэтому лага компиляции нет, всё собрано заранее. Но под мобилочки или пк это не работает, потому что данных пиздец, как много.
Прекращай позориться.
>>27829
>Зачем террабайты?
Затем, что PSO архитектурно зависим. Даже обновление драйвера делает PSO устаревшим. PSO для 1080 не работает на 3060. И так далее. Так что делаешь один материал, считаешь его количество PSO. Умножаешь на количество поддерживаемых видеокарт, умножаешь на количество драйверов и так далее. На консолях именно поэтому лага компиляции нет, всё собрано заранее. Но под мобилочки или пк это не работает, потому что данных пиздец, как много.
>>27833
Я по фразе
Почему-то решил, что ты про этап компиляции билда, лол. На старте-то да, это полезно.
Я по фразе
>Можно просто скомпилировать все возможные PSO заранее.
Почему-то решил, что ты про этап компиляции билда, лол. На старте-то да, это полезно.
>>27838
ты же дурачок с чатгпт, полный ноль в теме, неудивительно, что тебе приходят в голову дурацкие идеи
ты же дурачок с чатгпт, полный ноль в теме, неудивительно, что тебе приходят в голову дурацкие идеи
>>27839
И это пишет шиз, который позорится уже сообщений десять подряд, лол.
И это пишет шиз, который позорится уже сообщений десять подряд, лол.
>Подскажите вот что. У меня уровень, состоящий из пары тысяч сцен. В игре ок, шустро. В редакторе рендерится ок, шустро. Проблема - открытие этого уровня в редакторе, или переключение вкладок с уровня на что угодно и обратно, занимает секунд 5, без преувеличений, и при активной работе над ассетами приходится прыгать туда-сюда по вкладкам, въебывая кучу времени на подгрузку.
>Пробовал чистить кеш, пробовал скрывать ноды, пробовал сохранять их как подсцены. Единственное что помогает - полное удаление значительной части сцен, из которых сделан уровень. Может есть способ научить годот не выгружать вкладку при переключении из нее?
Ой, опять годот не потянул полноценную игру... Главное помните система нод ну ни разу не тормозная! На моей демке в 50 нод всё работает!
>>27900
Дурачок, в юнити вообще сцены непереключаемые и ничего, никто не воняет. И у анона скорее всего слишком много засунуто в сцену ресурсов, у меня многонодовые сцены нормально переклацываются в 3
Дурачок, в юнити вообще сцены непереключаемые и ничего, никто не воняет. И у анона скорее всего слишком много засунуто в сцену ресурсов, у меня многонодовые сцены нормально переклацываются в 3
>>27905
Я не понимаю, зачем настолько нагло пиздеть? Все же сразу видят, что долбоёб пиздит, но он всё равно пиздит. Разве что он совсем нихуя не знает.
>в юнити вообще сцены непереключаемые
Я не понимаю, зачем настолько нагло пиздеть? Все же сразу видят, что долбоёб пиздит, но он всё равно пиздит. Разве что он совсем нихуя не знает.
>>27909
Да все уже забили, пусть бесится
Да все уже забили, пусть бесится
>>27641
торк просрал рыночек из-за жадности
в свое время, он мог стать тем самым юнити, когда юнити не было. у них все было - юзерфрендли редактор, скрипты (в том числе на с++), доки, разные примеры от простых, до шутеров. Можно было буквально рыночек инди захавать
Но разрабам даже в голову не пришло сделать бесплатную инди лицензию.
что юнитеки хорошо сделали - это они провели революцию рыночка, пояснив что будущее, не за гигантами ААА студий, а за теми самыми школьниками клепающими хорорки вместо уроков (на чем юнити и набрал свою аудиторию и на десять лет потерял репутацию серьезного движка - когда школьники клепали ассетвлипы про выпрыгивающие кубы... но вот школьники выросли и теперь весь мир делает игры на юнити)
>когда-то был актуальным, сейчас сообщество пилит четвёртую версию, хз какой там прогресс
>есть свой редактор и свой скриптовый язык
>существует в двух ипостасях - torque 2d и torque 3d
торк просрал рыночек из-за жадности
в свое время, он мог стать тем самым юнити, когда юнити не было. у них все было - юзерфрендли редактор, скрипты (в том числе на с++), доки, разные примеры от простых, до шутеров. Можно было буквально рыночек инди захавать
Но разрабам даже в голову не пришло сделать бесплатную инди лицензию.
что юнитеки хорошо сделали - это они провели революцию рыночка, пояснив что будущее, не за гигантами ААА студий, а за теми самыми школьниками клепающими хорорки вместо уроков (на чем юнити и набрал свою аудиторию и на десять лет потерял репутацию серьезного движка - когда школьники клепали ассетвлипы про выпрыгивающие кубы... но вот школьники выросли и теперь весь мир делает игры на юнити)
>>27696
так вот это PSO тоже компилируется если что. и тоже не быстро.
на самом деле я например не понимаю - откуда блядь вообще возникли долгие компиляции шейдеров в vulkan/dx12 (и это не проблема ue - если писать свои поделки на вулкане - там тоже шейдеры пропукивает, это именно что-то в современных GAPI)
при том что в древнем opengl/dx11 тот же самый код шейдеров компилируется за наносекунды. до вулкана вообще никто из игроков не слышал что шейдеры надо компилить перед запуском игры
конечно еще может быть проблема что сейчас разрабы на шейдерах дохулион всего вычисляют - и пока там все скомпилируется... хз.
>В DX 12 появились PSO, Pipeline State Object.
так вот это PSO тоже компилируется если что. и тоже не быстро.
на самом деле я например не понимаю - откуда блядь вообще возникли долгие компиляции шейдеров в vulkan/dx12 (и это не проблема ue - если писать свои поделки на вулкане - там тоже шейдеры пропукивает, это именно что-то в современных GAPI)
при том что в древнем opengl/dx11 тот же самый код шейдеров компилируется за наносекунды. до вулкана вообще никто из игроков не слышал что шейдеры надо компилить перед запуском игры
конечно еще может быть проблема что сейчас разрабы на шейдерах дохулион всего вычисляют - и пока там все скомпилируется... хз.
>>28179
Очевидно, что они компилируются долго. Каждый PSO включает в себя шейдер в том числе, но не только его. То есть они жирнее шейдеров. И их компилируется больше, чем шейдеров. Так что логично, что это долго.
>так вот это PSO тоже компилируется если что. и тоже не быстро.
Очевидно, что они компилируются долго. Каждый PSO включает в себя шейдер в том числе, но не только его. То есть они жирнее шейдеров. И их компилируется больше, чем шейдеров. Так что логично, что это долго.
>>28264
Скам от гришакова
Скам от гришакова
>>28264
инфоцыган обещал вам заработок в геймдеве - инфоцыган слово сдержал
инфоцыган обещал вам заработок в геймдеве - инфоцыган слово сдержал
>>28201
Тогда почему можно включить дх11 в урине 5 и получить нормальный фпс без скачков ебанутых?
Тогда почему можно включить дх11 в урине 5 и получить нормальный фпс без скачков ебанутых?
>>28306
Потому что в DX11 нет PSO. А ещё отваливается половина люмена, наниты, виртуальные текстуры, RT и хуй знает, что ещё. Очевидно, что это самые проблемные и лагающие части УЕ, потому без них он себя чувствует намного лучше.
Потому что в DX11 нет PSO. А ещё отваливается половина люмена, наниты, виртуальные текстуры, RT и хуй знает, что ещё. Очевидно, что это самые проблемные и лагающие части УЕ, потому без них он себя чувствует намного лучше.
>>28310
д - дебил
д - дебил
>>28291
не ври, треугольник быстро делается. вот модели, камеры и т.д. требуют столько усилий, что можно небольшую игру сделать на готовом движке, с модельками, анимациями и звуками
не ври, треугольник быстро делается. вот модели, камеры и т.д. требуют столько усилий, что можно небольшую игру сделать на готовом движке, с модельками, анимациями и звуками
>>28315
на вулкане пока осилишь треугольник как раз 17 недель пройдёт (ну как минимум одна)
а модель это просто набор треугольников
библиотеки чтения моделей и анимаций уже есть, не понимаю, зачем изобретать велосипед - разве что если потом надо перевести их во внутренний формат движка
на вулкане пока осилишь треугольник как раз 17 недель пройдёт (ну как минимум одна)
а модель это просто набор треугольников
библиотеки чтения моделей и анимаций уже есть, не понимаю, зачем изобретать велосипед - разве что если потом надо перевести их во внутренний формат движка
>>28321
это библиотеки чтения данных, а не создания архитектуры и разбирания как всё должно работать. ты сам должен сначала навелосипедить анимацию и модель, всё настроить, а потом читать в них массивы данных при помощи этих библиотек
это библиотеки чтения данных, а не создания архитектуры и разбирания как всё должно работать. ты сам должен сначала навелосипедить анимацию и модель, всё настроить, а потом читать в них массивы данных при помощи этих библиотек
Плохие новости: Dragon Bones восстал из мёртвых
https://www.loongbones.com/
теперь он
1. облачный
2. платный
3. только на китайском
https://www.loongbones.com/
теперь он
1. облачный
2. платный
3. только на китайском
>>28348
это комплимент, основа гд это безыгорные безскилловые дебильные чатгпт шизики
но в первую очередь я имею отношение к нормальному софту, и не вынужден давиться калом, поэтому не в курсе про каждый кал
это комплимент, основа гд это безыгорные безскилловые дебильные чатгпт шизики
но в первую очередь я имею отношение к нормальному софту, и не вынужден давиться калом, поэтому не в курсе про каждый кал
162 Кб, 528x364>>28351
твой писюлек
твой писюлек
>>28349
Опять этот нобрейн чухан рвётся. Какой у тебя, если тебя рандомхуи с двача обоссали с головы до ног? Опыт в сосании хуёв разве что.
Опять этот нобрейн чухан рвётся. Какой у тебя, если тебя рандомхуи с двача обоссали с головы до ног? Опыт в сосании хуёв разве что.
>>28404
критикуя меня, ты критикуешь себя
критикуя меня, ты критикуешь себя