Войти
ПроектыФорумУтилиты

2D движок BME. (OpenSource - 13.09.2014) (29 стр)

Advanced: Тема повышенной сложности или важная.

Страницы: 125 26 27 28 29 30 Следующая »
#420
15:17, 23 апр. 2012

Хм.. Пичалька. Но если это не просто баги по недогляду, то это, как раз таки, конкретные вопросы по решению задачи. В данном случае - это задача обработки больших объёмов данных.
Либо, что скорее всего, это касается внутренней организации движка, а не его внешнего API. Если же это нахождение каких-то багов, то для данной стадии разработки это тоже приемлемо. Лишь бы API поменьше менялся (разве что расширялся).

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

Думаю, для таких случаев нужны отдельные нагрузочные тесты. Но, повторюсь, в моём видении это не должно влиять на API такого движка. Поправьте меня пожалуйста, если я чего-то не вижу и ошибаюсь.

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

Вообщем озадачил Николай... :) Сам готовлю движок для подобного рода проектов. Но пока что на нём делается time-management и таких проблем, разумеется, не возникает.
Можно поподробнее узнать о возникших проблемах? Или хотя бы выдвигаемых Вами требованиях к движку?
В чем именно там возникли проблемы? Это просто баги по недогляду или концептуальные ошибки/недостатки?
И я не совсем понимаю, какие могут возникнуть проблемы с отображением при увеличении нагрузки на объём картинок?
Мы же, надеюсь, сейчас не об обычных аппаратных ограничениях говорим? Ну и, опять же, не о просто допущенных ошибках в коде.

Хиддены, благо, пока не так сильно загружают видеокарту количеством отображаемых объектов. Текстуры - да, пузатые, но это вопрос предварительной подготовки. Скорее даже логическая задача (загрузка соседних сцен, умная выгрузка и т.д.)

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

P.S. Снова увлекаюсь большими объёмами поста - заканчиваю с этим :D

#421
15:22, 23 апр. 2012

MoonStone
> Очень и очень полезный рассказец получится, если Вы сможете уделить этому
> минутку-другую и рассказать, хотя бы вкратце, что за проблемы там всплыли ;-)
+1

#422
16:10, 23 апр. 2012

Ну разрешение одной проблемы поначалу зашло в тупик :)
Тесты загрузки реально показывали на всех 3 тестируемых движках одинаковые результаты
BME даже иногда выигрывал пару msec!
но вам не всегда нужны все 40 текстур уровня вам нужно только первые 4 и еще 36 в последствие и на этом фоне PlayFirst был далеко в впереди он грузил лучше и быстрее, вся проблема в том что там использовались потоки и текстуры грузились по принципу все что в начале нужно оно грузит остальное в очередь
и в момент надобности оно обычно уже в памяти от сюда и плавность.

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

Это скорее недочет движка просто это скорее то что было хорошо сделано в PF и не было в BME.

Это один из крупных так сказать нюансов в остальном оно либо решается быстро, либо решалось мною самим.

#423
16:34, 23 апр. 2012

Nikolay, спасибо большое за разъяснение. Я бы даже не по думал об этом. Решение грузить данные в заказанном порядке кажется мне очевидным :)
Хорошо, проблемой меньше.

MATov, ожидаем новых релизов! :)

#424
22:04, 23 апр. 2012

MoonStone
> А остальным пользователям данного движка можно будет рассчитывать на исходники?
> Хотя бы в будущем.
> Ну и какая-то определённость относительно лицензии появилась? Платный он иль
> бесплатный?

Тут пока так и не определился, с одной стороны хотелось бы в будущем хоть как-то монетизировать, для поддержания энтузиазма, так сказать, а с другой - хочется опенсорс. Варианта два рассматриваю:
1) Бесплатный для любого пользования, но без исходников, с платными исходниками и поддержкой.
2) Бесплатный + опенсорс с кнопочкой донейт (в который я особо не верю Изображение)

> коли нет общего доступа к исходникам, всё ещё важен вопрос готовности движка, как инструмента создания игры с нуля и до конца.
Все ближе к этому, текущая версия очень близка, но оно пока не готова для публичного доступа.

> И насколько движок готов пройти Quality Test у паблишеров?
учитывая что я на работе занимаюсь этими вопросами с рабочим движком, тут проблем не будет особых, если что всё пофиксится, но все равно - всё решается обычно на ходу, ибо каждый тест, обычно, новые нюансы показывает (по-умолчанию имеется в виду тесты 'фишей' как наиболее лютые)

> И ещё вот вспомнил: насколько двиг дружелюбен к невнимательным программистам? Логи там, сообщения о внутренних ошибках, забытых ресурсах?
всё есть, да.

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

> Решение грузить данные в заказанном порядке кажется мне очевидным :)
Николай говорил не про простую загрузку по требованию :) а про более хитрую систему, коротко её можно описать так:
1) Зовется функция CreateTexture дабы создать текстуру;
2) Она создается, но не загружается сразу, а падает в очередь другого потока и грузится _в фоне_;
3) При отправке на рендер или взятии размеров например и т.д (когда она уже реально нужна) скорее всего она уже будет готова и загружена, если нет, то ставится высший приоритет (банально в очереди загрузки на самый верх её и ждем пока загрузится (как в обычной загрузке по требованию))
Вот такая штука, которая есть в Playfirst SDK, но небыло в BME Изображение

> MATov, ожидаем новых релизов! :)
Спасибо, надеюсь скоро, наконец-то, увидит свет новая версия, которая опять разительно отличается в лучшую сторону от прошлой :)

Правка:
очепятки

#425
23:54, 23 апр. 2012

О, спасибо за оперативный ответ!

Первый вариант лицензии звучит очень и очень приятно: начинающие вполне могут втянуться в работу и с либами, а кто уже пощупал движок и решил пойти дальше, не поскупится и приобретет исходники. Всё таки разработчики, которые действительно осиливают доведения проектов до конца, отличаются наличием и совести в том числе. Ну и для развития своих проектов тоже будет полезно. :) Особенно, если туда будет входить подписка на хотя бы полугодовую поддержку, например. Фидбеки там, оперативное исправление багов, составление FAQ, если такие будут (а такие будут, если клиентская база соберётся :), ну и т.д. ;)

В целом и без этого коммерческого обвеса всё очень заманчиво. :)

С приоритетами загрузки текстур - хорошая мысль. А я просто выводил вакуум, пока не загрузятся. XD
На самом деле, немного смущает возможность возникновения таких ситуаций - привык, что данные если и загружаются в фоне, то всё равно всё организуется так, чтобы не было подгрузки в игровом процессе. Если и грузить, то в переходах между сценами (чтобы задержки вписывались), не убирать предыдущую сцену и прочие трюки, ну то есть всё приводить к схеме: если сцена отображается, значит все её данные уже загружены.
Но это, наверное, от того, что таких пузатых HO ещё не писал. С видео там, с огромным количеством данных для вложенных zoom-сцен и т.д. Не знаю пока, на какие ухищрения приходится идти в таких случаях. Да я чот и игр-то таких навскидку не назову (в этом жанре), чтобы сцену не уложить в загрузку :)

И ещё вопрос, если не секрет. Ты текстуры к POT приводишь сразу и без разговоров или смотришь на Caps'ы и если они не поддерживаются, то масштабируешь их?
Просто натыкался в сети не раз на разговоры о том, что некоторые видяхи говорят что держат NPOT, а сами сливают. Или держат, но при условии, что всё выводится в режиме CLAMP, что не критично, но не очень удобно в плане универсальности. Разумеется, самому не проверить, а на клиентах/игроках эксперименты ставить не хочется. Пока обозначил просто, чтобы художники всё рисовали в POT. Если забудут, то заработают лёгкое размытие. К слову сказать, вычитал, что Unity сразу масштабирует кладя на все POT/NPOT флажки, какие у неё там есть.

#426
11:13, 24 апр. 2012

MoonStone
> Да я чот и игр-то таких навскидку не назову (в этом жанре), чтобы сцену не
> уложить в загрузку :)

у нас такие все игры последние на работе, всякие разные ухищрения, хотя все сводится к одному и тому же - загружаем когда реально нужно и освобождаем когда не нужно)
много всяких видосов, анимаций, звуков и т.п и т.д.

> Ты текстуры к POT приводишь сразу и без разговоров или смотришь на Caps'ы и если они не поддерживаются, то масштабируешь их?
смотрю капсы и, если не поддерживается то привожу и не масштабирую, а дополняю черным.

> Просто натыкался в сети не раз на разговоры о том, что некоторые видяхи говорят что держат NPOT, а сами сливают.
есть такие, мобильные так почти все, например, но и на PC встречается на тестах.

ну а вообще это все просто бонусы, текстуры должны быть POD-размеров и хардварных форматов в атласах, тогда все будет хорошо.

#427
15:50, 18 июня 2012

Давно не отписывался, работа идет полным ходом, всё не могу точку поставить, что бы новую версию выкатить :)
Сайт временно упал, в скором воскрешу.

#428
3:23, 9 июля 2012

Как успехи?

#429
17:38, 10 сен. 2012

Как успехи?)

#430
17:52, 10 сен. 2012

Odin_KG
> Как успехи?

Yuko
> Как успехи?)

Да вот думаю о том, что нужен опенсорс, ибо bme-то пилю постоянно, а версии выкатить не могу, то есть, как и в прошлый раз писал, "всё не могу точку поставить" :)
Спасибо, что не забываете.

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

#431
16:10, 12 сен. 2012

MATov
Чудненько, только может для гд выложиш без
> - допиливаю самый критичные штуки
?
А то, боюсь, снова затянется на несколько месяцев, а глянуть интересно :)

Прошло более 2 лет
#432
21:04, 13 сен. 2014

Да уж...Давно я не заходил в эту тему и не ковырялся с BME :)
Забавно то, что я хоть и не занимался им давно, но всё лилею надежду, что когда-нить допилю его до удобоваримого состояния :)
Правда не понятно зачем, учитывая всякие юнити и еще 100500 движков.

Так вот чего зашел-то, выложил в опен-сорс то, что было на последний момент.
https://bitbucket.org/blackmatov/openbme

Правка:
Правда сэмплы не выложил, так как там какая-то каша.
И из солюшенов для сборки только cmake.

#433
21:08, 13 сен. 2014

MATov
> Правда не понятно зачем, учитывая всякие юнити и еще 100500 движков.
Это самый страшный демотиватор. Он мешает идти вперед больше, чем что либо остальное. Как говорится: самое трудное - это победить свой страх.

#434
0:11, 15 сен. 2014

  MATov, "ох, как я Вас понимаю!" )))

  Сам страдаю от похожей болезни - даже реакция на выход новых движков какая-то неправильная: немного депрессит, как вижу объявление о новом движке с кучей плюшек в описании)))
  Но стоит присмотреться и становится понятно, что то, что есть - часто бъёт мимо цели. Как специально косят и элементарные для геймдева вещи не реализуют. Так что нужны новые и простые движки, НУЖНЫ!
  Лёгких движков, как BME - раз-два и обчёлся. Хотя, если подумать, то и вовсе нет. Это либо большие комплексы, либо закрытые системы, либо сырые и готового продукта на них сразу не сделать.
  Так что в этом случае мне нравится позиция коллеги "как сделаю я - не сделает никто, но это понравится многим".
  Ещё похожие чувства возникают, когда смотришь на молодых талантов и понимаешь, что ты несколько уныловат на их фоне))) Но это ж не причина не творить. У хорошего произведения свои поклонники всегда найдутся!

  И не стоит забывать от такой вещи как опыт и своё, уникальное, долгими годами сформированное, видение решения задач.
  А именно это мне очень понравилось в BME (собственно, сильно похожие решения и у меня в движке)...

А потом я узнал, что это, возможно, из-за работы с одним движком в одной конторе. Про слонов ;) Я там не блеснул, конечно, но они мне, можно сказать, дали билет в геймдев, за что им просто безграничная благодарность!

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

Так я что хотел сказать-то... Дерзай, Матвей, дерзай! )) Твоя работа всё так же акутальна. Просто сезон такой был... невнятный :)
Вспоминая то, что уже сделано - тебе, кроме лакировки, документация нужна, да примеры. Чтобы порог вхождения для новичков понизить. И будет конфетка, а не двиг!

Страницы: 125 26 27 28 29 30 Следующая »
ПроектыФорумУтилиты

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