ZLOI_DED, не переживай, большая часть концепций и алгоритмов уже продуманы и часть даже расписана на бумаге. Просто все делается шаг за шагом и постепенно улучшается - вчера был прототип, едва справляющийся со своими функциями, а дальше его модули будут постепенно заменяться на нормальные.
Делать чанки больше нельзя по нескольким причинам, в первую очередь это связано с особенностями передачи данных на GPU, но не только. Вместо этого в один файл будет записываться много чанков - в начале таблица смещений, по которой можно найти нужный чанк, а дальше сами чанки. Для начала сойдет, а потом надо будет заменить на еще более интересную штуку, слегка похожую на виртуальную файловую систему.
А вот хранить список сохраненных чанков это уже немного лишнее - карта ведь бесконечная и список этот будет расширяться до бесконечности - есть смысл хранить только список загруженных чанков и флаг наличия в них изменений чтобы не выгружать на диск чанки, которые не изменились в сравнении с сохраненной версией.
Что касается создания радиуса вокруг игрока, в котором хранятся загруженные чанки это мало чем принципиально отличается от видимых камерой чанков, если только не заниматься загрузкой-выгрузкой в отдельном потоке - тогда действительно имеет смысл хранить буфер чанков вокруг области видимости чтобы не тормозить передвижение камеры на время загрузки новых чанков.
Ну и напоследок - зачем нужна приоритезированная выгрузка чанков? Ради возможности иметь работающие машины или еще что-то, требующее наличия загруженного чанка на большом расстоянии от игрока. Например, представь себе вагонетку, которая ездит по рельсам и перевозит грузы. Если выгружать все, что слишком далеко от игрока, то вагонетка уткнется в край и просто остановится до тех пор, пока не будут загружены чанки дальше, а если в наличии будет интеллектуальная система выгрузки чанков, то для вагонетки будут загружаться чанки по пути ее следования и если вагонеток по этому пути будет ездить много и часто, то система не будет пытаться выгрузить эти чанки без крайней необходимости. Аналогично для любых других действий, происходящих на границе загруженной области - принудительная выгрузка всего, что находится вне области приведет к загрузке-выгрузке активных чанков на границе каждый такт до тех пор, пока не закончится процесс, требующий загрузки дополнительных чанков или не выгрузятся все чанки, связанные с этим процессом (тогда процесс будет заморожен и возобновится после загрузки).
Obelick, сыграв пару матчей ты даже не соберешь стартовые классовые карты, которые даются за набор уровней героем. А уж если ты сунулся сходу без карт против игроков или ботов-экспертов, то кто тебе виноват кроме тебя самого?
Хм... проведя небольшое исследование, пришел к выводу, что на вторую и далее страницы не попадают записи без комментариев, в то время как с остальными все в порядке. Более того, "пропавшие" ресурсы так и не появились на дальних страницах, в то время как созданные позже, но с комментариями, исправно отображаются.
Для чистоты эксперимента осталось дождаться пока мой висящий сейчас на первой странице ресурс уйдет на вторую - в одно время было создано два ресурса и в одном добавлен комментарий. Первый ресурс уже пропал без вести.
upd:
теория подтверждена - на вторую страницу ресурсы без комментариев не проходят, с комментариями - проходят исправно.
alexprey, по идее партикл-эмиттер с диким количеством частиц - это же не в режиме реального времени обсчитывается, а предназначено для постобработки видео.
ZLOI_DED, ты наверно удивишься, но я уже прошел через предложенный тобой велосипед и отбросил его как слишком ресурсоемкий.
Более того, есть более эффективная реализация этого метода, которую я упоминал - процедурно генерируется модель из N*N вершин, где каждая вершина соответствует желаемому пикселю, затем с этой моделью можно работать напрямую через вершинный буфер. Настройки рендеринга для этой геометрии выставляются так, чтобы каждая вершина отрисовывалась как точка. И последний штрих - применяется 2д-проекция, которая в обычных условиях используется для GUI, превращающая 1 единицу расстояния на сцене в 1 пиксель.
Получаем поверхность, цвет которой мы можем редактировать напрямую. Получается довольно неплохо, если не считать того, что перекраска каждой вершины ложится полностью на CPU. Хуже всего, что при желании покрасить такую поверхность текстурой, текстуру придется парсить на CPU попиксельно, после чего повершинно применять цвет к вершине. Такие затраты CPU позволительны когда вся поверхность может быть загружена в память, а изменения поверхности происходят довольно редко, но когда речь идет о бесконечной карте, которая загружается и выгружается по мере необходимости, начинается настоящий ад.
RSQR, ладно, не мое это дело - обсудим тундра ли получилась когда будет готовая работа. Ты лучше скажи, симуляция снега будет или как обычно бегаем по монолитной текстуре снега?
RSQR, лично я не набрасывался, просто констатировал факт что заявлена тундра, а на скриншотах ей и не пахнет. У меня у самого когда-то была идея запилить сурвивал в тундре, правда не только в зимней, но я как прикинул какой это ад делать симуляцию ветра, снега и болот, так сразу и расхотелось.
Кет, считай то-же самое что и массив 2D текстур одинакового размера, только еще со смешиванием между слоями. На практике применяются довольно редко и жрут порядочно ресурсов. Массивы текстур появились позже и не на всем железе поддерживаются, но работают быстрее, да и смешивание между слоями не всегда нужно.
icedragoxx, а для тундры деревьев неприлично много, рельеф слишком неровный, да и хвойные деревья не то чтобы очень часто в тундре увидеть можно, искусственные посадки не в счет.
ZLOI_DED, общая идея в том, что каждый пиксель задан одним байтом - id матерала, эти данные запекаются в одноканальную текстуру размером 128*128, затем текстура натягивается на простой меш такого-же размера. Соответственно, карта разбивается на фрагменты, каждому из которых соответствует меш с текстурой. Ну и следующим шагом шейдер разбирает пришедшую ему текстуру и по материалу и координатам назначает пикселям цвета из общего атласа.
Меш, естественно, реализован не моделью, а программно. Еще я пробовал всякие извращения вроде того, чтобы задавать каждый пиксель на экране вершиной в модели без полигонов или считать цвета пикселей на CPU - и то и другое довольно болезненно.
Потом пришлось немного усложнить систему, добавив по два байта на пиксель и, соответственно, переключившись на трехканальную текстуру для передачи данных. Эти два байта используются для хранения смещения по текстуре, за счет чего и реализованы те самые "пни", о которых ты спрашивал. В перспективе возможен переход на четырехканальную текстуру и, соответственно, добавление еще одного байта на пиксель, но это уже для красивостей, без которых вполне можно обойтись.
Естественно, сцена клипается по вьюпорту камеры, плюс текстуры для передачи данных реюзаются, а не хранятся постоянно. Ну и находящиеся слишком далеко фрагменты карты нужно выгружать на диск т.к. память не резиновая.
С одноканальной текстурой для передачи данных это вообще самолет, а вот с трехканальной уже тяжелее, хотя тяжелее всего генерация мира, конечно, даже такая простая, как в тестовом варианте.
На скрине "непонятная фигня" у тебя это камни? Или пни? И если это пни, почему они повёрнуты срезом к нам? :D
Это просто тестовая текстура для проверки функционала правильной покраски частей поверхности, вставленных со смещением. Если честно, я не знаю что это было изначально, до того как я вырезал этот фрагмент, кажется каменный пол с куском колонны - текстуры то по большей части из числа свободно распространяемых. Кстати, надо будет указать этот момент при следующем обновлении главной.
Что касается заточенных под 2д движков - все дело в том, что у меня довольно специфичные требования за счет того, что поверхность состоит не из тайлов, а из отдельных пикселей, которые потом красятся текстурой и заточенные под работу со спрайтами движки мне здесь мало чем помогут.
ZLOI_DED, прошу прощения, но во-первых это был ответ на вопрос другому человеку, а во-вторых я не спрашивал совета по движкам.
Slick, насколько мне известно, не поддерживает необходимые мне функции, а может и поддерживает, но тогда там слишком туго с онлайн документацией.
Libgdx это вообще фреймворк общего назначения для работы с OpenGL и работа с 2д графикой в нем мало отличается от того, как это происходит в JMonkeyEngine, может чуть меньше костылей.
Обратите внимание, кол-во прямых переходов практически не изменилось, в то время как кол-во входов через поисковые системы резко упало. Что-то мне подсказывает, что дело тут в смене домена, хотя я могу ошибаться т.к. не помню дату когда был окончательно отключен старый домен.
» Requested Eternity / отчет за 29.05.2014
» Hearthstone / Наши игроки
» Requested Eternity / отчет за 29.05.2014
» Hearthstone / Наши игроки
» Hearthstone / Общее обсуждение
» Requested Eternity / Взрывай-разрушай
Ред. prog
» Администрация XGM / Ресурсы просто так пропадают из ленты
теория подтверждена - на вторую страницу ресурсы без комментариев не проходят, с комментариями - проходят исправно.
Созданный в то же время ресурс xgm.guru/p/etreq/124826 в ленте отсутствует.
» Peon Defender / Peon Defender
» Requested Eternity / отчет за 23.05.2014
» Requested Eternity / отчет за 20.05.2014
» Процедурная нереальность / Горим
» Requested Eternity / Requested Eternity
» 2ndra / 2ndra
» 2ndra / 2ndra
» 2ndra / 2ndra
» 2ndra / 2ndra
» Requested Eternity / отчет за 22.05.2014
» 2ndra / 2ndra
» 2ndra / 2ndra
» Requested Eternity / Requested Eternity
» God of light's web-log / [Хочу научиться делать игры]
Ред. prog
» Requested Eternity / Requested Eternity
» Администрация XGM / Ресурсы просто так пропадают из ленты
» Requested Eternity / Requested Eternity
Ред. prog
» Tiodor's Art / XGM статистика. Как интересно