2д-платформер с полной разрушаемостью мира, вплоть до отдельного пикселя, начало разработки которого удивительным образом совпало с конкурсом Game Boom #2: Sandbox.
Язык разработки: Java
Используемый движок: JMonkeyEngine 3
Жанр: РПГ с элементами сандбокса и стратегии с непрямым управлением.
Классификация с точки зрения игровой камеры: сайд-скроллер, 2д-платформер
ZLOI_DED, ты наверно удивишься, но я уже прошел через предложенный тобой велосипед и отбросил его как слишком ресурсоемкий.
Более того, есть более эффективная реализация этого метода, которую я упоминал - процедурно генерируется модель из N*N вершин, где каждая вершина соответствует желаемому пикселю, затем с этой моделью можно работать напрямую через вершинный буфер. Настройки рендеринга для этой геометрии выставляются так, чтобы каждая вершина отрисовывалась как точка. И последний штрих - применяется 2д-проекция, которая в обычных условиях используется для GUI, превращающая 1 единицу расстояния на сцене в 1 пиксель.
Получаем поверхность, цвет которой мы можем редактировать напрямую. Получается довольно неплохо, если не считать того, что перекраска каждой вершины ложится полностью на CPU. Хуже всего, что при желании покрасить такую поверхность текстурой, текстуру придется парсить на CPU попиксельно, после чего повершинно применять цвет к вершине. Такие затраты CPU позволительны когда вся поверхность может быть загружена в память, а изменения поверхности происходят довольно редко, но когда речь идет о бесконечной карте, которая загружается и выгружается по мере необходимости, начинается настоящий ад.
ZLOI_DED, общая идея в том, что каждый пиксель задан одним байтом - id матерала, эти данные запекаются в одноканальную текстуру размером 128*128, затем текстура натягивается на простой меш такого-же размера. Соответственно, карта разбивается на фрагменты, каждому из которых соответствует меш с текстурой. Ну и следующим шагом шейдер разбирает пришедшую ему текстуру и по материалу и координатам назначает пикселям цвета из общего атласа.
Меш, естественно, реализован не моделью, а программно. Еще я пробовал всякие извращения вроде того, чтобы задавать каждый пиксель на экране вершиной в модели без полигонов или считать цвета пикселей на CPU - и то и другое довольно болезненно.
Потом пришлось немного усложнить систему, добавив по два байта на пиксель и, соответственно, переключившись на трехканальную текстуру для передачи данных. Эти два байта используются для хранения смещения по текстуре, за счет чего и реализованы те самые "пни", о которых ты спрашивал. В перспективе возможен переход на четырехканальную текстуру и, соответственно, добавление еще одного байта на пиксель, но это уже для красивостей, без которых вполне можно обойтись.
Естественно, сцена клипается по вьюпорту камеры, плюс текстуры для передачи данных реюзаются, а не хранятся постоянно. Ну и находящиеся слишком далеко фрагменты карты нужно выгружать на диск т.к. память не резиновая.
С одноканальной текстурой для передачи данных это вообще самолет, а вот с трехканальной уже тяжелее, хотя тяжелее всего генерация мира, конечно, даже такая простая, как в тестовом варианте.
Велосипеды...)
У меня есть более простое предложение:
Всё пространство делится на чанки, в каждом из которых n-ное число треугольных полигонов (или квадратиков - 2х полигонов, ибо насколько я знаю в модерн опен гл режим дрова квадратами убрали). Именно полигонов, а не пикселей. С пикселями могут возникнуть проблемы при ресайзе окна и на разных разрешениях, если важен вид. (Хотя я честно немного не понял как это ты привязываешь это дело к пикселям 0_0)
Так вот. Там есть такая тема, называется батчинг. Можно много маленьких мешей в большие перегонять, с общей текстурой. Примерно как в майнкрафте делается. Так вот, делать как обычный воксельный двиг и не париться. Материалы задавать либо текстурами, если полигоны большие, либо, скорее всего в твоём случае - просто цветом, желательно без всяких этих материалов, если можно, а напрямую через LwGJL в VBO закидывать вертексы и цвета.
ZLOI_DED, общая идея в том, что каждый пиксель задан одним байтом - id матерала, эти данные запекаются в одноканальную текстуру размером 128*128, затем текстура натягивается на простой меш такого-же размера. Соответственно, карта разбивается на фрагменты, каждому из которых соответствует меш с текстурой. Ну и следующим шагом шейдер разбирает пришедшую ему текстуру и по материалу и координатам назначает пикселям цвета из общего атласа.
Меш, естественно, реализован не моделью, а программно. Еще я пробовал всякие извращения вроде того, чтобы задавать каждый пиксель на экране вершиной в модели без полигонов или считать цвета пикселей на CPU - и то и другое довольно болезненно.
Потом пришлось немного усложнить систему, добавив по два байта на пиксель и, соответственно, переключившись на трехканальную текстуру для передачи данных. Эти два байта используются для хранения смещения по текстуре, за счет чего и реализованы те самые "пни", о которых ты спрашивал. В перспективе возможен переход на четырехканальную текстуру и, соответственно, добавление еще одного байта на пиксель, но это уже для красивостей, без которых вполне можно обойтись.
Естественно, сцена клипается по вьюпорту камеры, плюс текстуры для передачи данных реюзаются, а не хранятся постоянно. Ну и находящиеся слишком далеко фрагменты карты нужно выгружать на диск т.к. память не резиновая.
С одноканальной текстурой для передачи данных это вообще самолет, а вот с трехканальной уже тяжелее, хотя тяжелее всего генерация мира, конечно, даже такая простая, как в тестовом варианте.
Кет, считай то-же самое что и массив 2D текстур одинакового размера, только еще со смешиванием между слоями. На практике применяются довольно редко и жрут порядочно ресурсов. Массивы текстур появились позже и не на всем железе поддерживаются, но работают быстрее, да и смешивание между слоями не всегда нужно.
ETREQ
Комментарии проекта Requested Eternity
Взрывай-разрушай
отчет за 23.05.2014
23.05.2014
отчет за 20.05.2014
20.05.2014
Requested Eternity
У меня есть более простое предложение:
Всё пространство делится на чанки, в каждом из которых n-ное число треугольных полигонов (или квадратиков - 2х полигонов, ибо насколько я знаю в модерн опен гл режим дрова квадратами убрали). Именно полигонов, а не пикселей. С пикселями могут возникнуть проблемы при ресайзе окна и на разных разрешениях, если важен вид. (Хотя я честно немного не понял как это ты привязываешь это дело к пикселям 0_0)
отчет за 22.05.2014
22.05.2014