Комментарии проекта Requested Eternity
22

Главная страница

» Requested Eternity
2д-платформер с полной разрушаемостью мира, вплоть до отдельного пикселя. Разработка приостановлена.

Читать далее...
prog #1 - 5 лет назад 0
Голосов: +0 / -0
Проект можно официально считать замороженным. Причин две:
  1. наличие более перспективного проекта в разработке
  2. наличие нескольких технических заморочек, которые мне так и не удалось решить - вернусь к ним позже, на свежую голову
alexprey #2 - 6 лет назад 0
Голосов: +0 / -0
prog, пичально(
prog #3 - 6 лет назад 0
Голосов: +0 / -0
alexprey, к сожалению, подумываю о снятии с конкурса - очень тяжелый месяц на работе выпал. Продолжать разработку буду, но сперва нужно на работе разгрести завал - спать то тоже когда-то надо.
alexprey #4 - 6 лет назад 0
Голосов: +0 / -0
как проект? Развивается?
prog #5 - 6 лет назад 0
Голосов: +0 / -0
Эльрат, завал на работе он такой - вечно возникает в самый неподходящий момент. По плану у меня уже должна была быть готова базовая генерация мира, нормальный чанк-менеджмент, выгрузка карты на диск, кисти для редактирования мира, один игровой персонаж и физика столкновений. Вот когда будет работать хотя бы это - будут и скриншоты.
Эльрат #6 - 6 лет назад 0
Голосов: +0 / -0
prog, порадуй нас новыми ресурсами - только со скринами. Если будет норм выглядеть - добавим на главную.
prog #7 - 6 лет назад 0
Голосов: +0 / -0
ZLOI_DED, ты наверно удивишься, но я уже прошел через предложенный тобой велосипед и отбросил его как слишком ресурсоемкий.
Более того, есть более эффективная реализация этого метода, которую я упоминал - процедурно генерируется модель из N*N вершин, где каждая вершина соответствует желаемому пикселю, затем с этой моделью можно работать напрямую через вершинный буфер. Настройки рендеринга для этой геометрии выставляются так, чтобы каждая вершина отрисовывалась как точка. И последний штрих - применяется 2д-проекция, которая в обычных условиях используется для GUI, превращающая 1 единицу расстояния на сцене в 1 пиксель.
Получаем поверхность, цвет которой мы можем редактировать напрямую. Получается довольно неплохо, если не считать того, что перекраска каждой вершины ложится полностью на CPU. Хуже всего, что при желании покрасить такую поверхность текстурой, текстуру придется парсить на CPU попиксельно, после чего повершинно применять цвет к вершине. Такие затраты CPU позволительны когда вся поверхность может быть загружена в память, а изменения поверхности происходят довольно редко, но когда речь идет о бесконечной карте, которая загружается и выгружается по мере необходимости, начинается настоящий ад.
ZLOI_DED #8 - 6 лет назад 0
Голосов: +0 / -0
prog:
ZLOI_DED, общая идея в том, что каждый пиксель задан одним байтом - id матерала, эти данные запекаются в одноканальную текстуру размером 128*128, затем текстура натягивается на простой меш такого-же размера. Соответственно, карта разбивается на фрагменты, каждому из которых соответствует меш с текстурой. Ну и следующим шагом шейдер разбирает пришедшую ему текстуру и по материалу и координатам назначает пикселям цвета из общего атласа.
Меш, естественно, реализован не моделью, а программно. Еще я пробовал всякие извращения вроде того, чтобы задавать каждый пиксель на экране вершиной в модели без полигонов или считать цвета пикселей на CPU - и то и другое довольно болезненно.
Потом пришлось немного усложнить систему, добавив по два байта на пиксель и, соответственно, переключившись на трехканальную текстуру для передачи данных. Эти два байта используются для хранения смещения по текстуре, за счет чего и реализованы те самые "пни", о которых ты спрашивал. В перспективе возможен переход на четырехканальную текстуру и, соответственно, добавление еще одного байта на пиксель, но это уже для красивостей, без которых вполне можно обойтись.
Естественно, сцена клипается по вьюпорту камеры, плюс текстуры для передачи данных реюзаются, а не хранятся постоянно. Ну и находящиеся слишком далеко фрагменты карты нужно выгружать на диск т.к. память не резиновая.
С одноканальной текстурой для передачи данных это вообще самолет, а вот с трехканальной уже тяжелее, хотя тяжелее всего генерация мира, конечно, даже такая простая, как в тестовом варианте.
Велосипеды...)
У меня есть более простое предложение:
Всё пространство делится на чанки, в каждом из которых n-ное число треугольных полигонов (или квадратиков - 2х полигонов, ибо насколько я знаю в модерн опен гл режим дрова квадратами убрали). Именно полигонов, а не пикселей. С пикселями могут возникнуть проблемы при ресайзе окна и на разных разрешениях, если важен вид. (Хотя я честно немного не понял как это ты привязываешь это дело к пикселям 0_0)
Так вот. Там есть такая тема, называется батчинг. Можно много маленьких мешей в большие перегонять, с общей текстурой. Примерно как в майнкрафте делается. Так вот, делать как обычный воксельный двиг и не париться. Материалы задавать либо текстурами, если полигоны большие, либо, скорее всего в твоём случае - просто цветом, желательно без всяких этих материалов, если можно, а напрямую через LwGJL в VBO закидывать вертексы и цвета.
Надеюсь помог хоть чем-то)
prog #9 - 6 лет назад 0
Голосов: +0 / -0
ZLOI_DED, общая идея в том, что каждый пиксель задан одним байтом - id матерала, эти данные запекаются в одноканальную текстуру размером 128*128, затем текстура натягивается на простой меш такого-же размера. Соответственно, карта разбивается на фрагменты, каждому из которых соответствует меш с текстурой. Ну и следующим шагом шейдер разбирает пришедшую ему текстуру и по материалу и координатам назначает пикселям цвета из общего атласа.
Меш, естественно, реализован не моделью, а программно. Еще я пробовал всякие извращения вроде того, чтобы задавать каждый пиксель на экране вершиной в модели без полигонов или считать цвета пикселей на CPU - и то и другое довольно болезненно.
Потом пришлось немного усложнить систему, добавив по два байта на пиксель и, соответственно, переключившись на трехканальную текстуру для передачи данных. Эти два байта используются для хранения смещения по текстуре, за счет чего и реализованы те самые "пни", о которых ты спрашивал. В перспективе возможен переход на четырехканальную текстуру и, соответственно, добавление еще одного байта на пиксель, но это уже для красивостей, без которых вполне можно обойтись.
Естественно, сцена клипается по вьюпорту камеры, плюс текстуры для передачи данных реюзаются, а не хранятся постоянно. Ну и находящиеся слишком далеко фрагменты карты нужно выгружать на диск т.к. память не резиновая.
С одноканальной текстурой для передачи данных это вообще самолет, а вот с трехканальной уже тяжелее, хотя тяжелее всего генерация мира, конечно, даже такая простая, как в тестовом варианте.
ZLOI_DED #10 - 6 лет назад (изм. ) 0
Голосов: +0 / -0
prog:
На скрине "непонятная фигня" у тебя это камни? Или пни? И если это пни, почему они повёрнуты срезом к нам? :D
Это просто тестовая текстура для проверки функционала правильной покраски частей поверхности, вставленных со смещением. Если честно, я не знаю что это было изначально, до того как я вырезал этот фрагмент, кажется каменный пол с куском колонны - текстуры то по большей части из числа свободно распространяемых. Кстати, надо будет указать этот момент при следующем обновлении главной.
Что касается заточенных под 2д движков - все дело в том, что у меня довольно специфичные требования за счет того, что поверхность состоит не из тайлов, а из отдельных пикселей, которые потом красятся текстурой и заточенные под работу со спрайтами движки мне здесь мало чем помогут.
Из пикселей? Т.е. суть технологии как воксели только в 2D?
Ты получается работаешь с LWJGL напрямую или создал кастом меш (квадратик - 2 полигона) и на него мат цвет наносишь и составляешь композицию из них? Или как вообще? Если я угадал, то лучше делать их как можно ниже, чтобы не лагало... А то знавал я ребят, которые пытались воксели из моделей вылепить. Брали блендер, лепили там пирамиду (воксели хотели не кубиками, а пирамидками прям как чайные пакетики :D ) и вставляли в гейм... Вот я ржал-то)))
prog #11 - 6 лет назад (изм. ) 0
Голосов: +0 / -0
На скрине "непонятная фигня" у тебя это камни? Или пни? И если это пни, почему они повёрнуты срезом к нам? :D
Это просто тестовая текстура для проверки функционала правильной покраски частей поверхности, вставленных со смещением. Если честно, я не знаю что это было изначально, до того как я вырезал этот фрагмент, кажется каменный пол с куском колонны - текстуры то по большей части из числа свободно распространяемых. Кстати, надо будет указать этот момент при следующем обновлении главной.
Что касается заточенных под 2д движков - все дело в том, что у меня довольно специфичные требования за счет того, что поверхность состоит не из тайлов, а из отдельных пикселей, которые потом красятся текстурой и заточенные под работу со спрайтами движки мне здесь мало чем помогут.
ZLOI_DED #12 - 6 лет назад (изм. ) 0
Голосов: +0 / -0
prog:
ZLOI_DED, прошу прощения, но во-первых это был ответ на вопрос другому человеку, а во-вторых я не спрашивал совета по движкам.
Slick, насколько мне известно, не поддерживает необходимые мне функции, а может и поддерживает, но тогда там слишком туго с онлайн документацией.
Libgdx это вообще фреймворк общего назначения для работы с OpenGL и работа с 2д графикой в нем мало отличается от того, как это происходит в JMonkeyEngine, может чуть меньше костылей.
Я лишь прокомментировал. Или если другой человек спросил, то отвечать на твой ответ может только он? Если так, тогда прошу в ЛС. А здесь по-моему обсуждение проекта.
Хорошо, С другой стороны может ты и прав. Сейчас у jMonkeyEngine 3 преимущество над всеми аналогами. Пусть даже и заточенными под 2D.
Прости, действительно влез, не посмотрев положение вещей. Просто сразу бросилось в глаза то, что пилить 2D игру на 3D движке, особенно на яве, будет затратно для юзера. Хотя... гораздо легче тебе с эффектами будет и с шейдерами, тут ты прав. Думал что есть более заточенные под 2D аналоги на яве то...
На скрине "непонятная фигня" у тебя это камни? Или пни? И если это пни, почему они повёрнуты срезом к нам? :D
prog #13 - 6 лет назад 1
Голосов: +1 / -0
ZLOI_DED, прошу прощения, но во-первых это был ответ на вопрос другому человеку, а во-вторых я не спрашивал совета по движкам.
Slick, насколько мне известно, не поддерживает необходимые мне функции, а может и поддерживает, но тогда там слишком туго с онлайн документацией.
Libgdx это вообще фреймворк общего назначения для работы с OpenGL и работа с 2д графикой в нем мало отличается от того, как это происходит в JMonkeyEngine, может чуть меньше костылей.
ZLOI_DED #14 - 6 лет назад -1
Голосов: +0 / -1
prog:
nvc123, в описании указано какой движок юзается. Да, действительно, используется 3D движок в режиме ортогональной камеры плюс некоторые другие приемы, помогающие работать с 2D графикой. Одна из основных причин - я не нашел ни одного достаточно гибкого 2д движка, где была бы внятная поддержка шейдеров (думаю не нужно объяснять почему), а мне позарез была нужна возможность выгрузить часть вычислений на GPU.
Вообще посмотри этот список: lwjgl.org/wiki/index.php?title=Game_Engines_and_Libraries_Using_...
prog #15 - 6 лет назад 0
Голосов: +0 / -0
nvc123, в описании указано какой движок юзается. Да, действительно, используется 3D движок в режиме ортогональной камеры плюс некоторые другие приемы, помогающие работать с 2D графикой. Одна из основных причин - я не нашел ни одного достаточно гибкого 2д движка, где была бы внятная поддержка шейдеров (думаю не нужно объяснять почему), а мне позарез была нужна возможность выгрузить часть вычислений на GPU.
nvc123 #16 - 6 лет назад 0
Голосов: +0 / -0
ты говоришь что 2д но в отладке видно что идёт работа с трианглами и вершинами
или ты юзаешь 3д движок для 2д графики?
Aws #17 - 6 лет назад 0
Голосов: +0 / -0
непонятная фигня
Довольно-таки оригинально. Лого напомнило LSD Dream Emulator.
Uber #18 - 6 лет назад 0
Голосов: +0 / -0
Хоть какое, потом сможешь сменить.
prog #19 - 6 лет назад 0
Голосов: +0 / -0
Лого добавлено, правда совсем никакущее.
8

Внезапная постобработка

» Requested Eternity
В данный момент по крупицам копится контент для крупного обновления, которое не стыдно было бы показать на главную, но сегодня произошел небольшой прорыв, о котором я просто не могу не рассказать. Подробности внутри.

Читать далее...
Inflexible #1 - 6 лет назад 0
Голосов: +0 / -0
prog:
Ага. Что ж, ясно)
Посмотрим тогда, что дальше будет.
prog #2 - 6 лет назад 0
Голосов: +0 / -0
Inflexible, выглядит он и правда интересно, но не дает нужного мне результата - визуального выделения поверхностей. Это сейчас в фоне просто синий цвет, а в перспективе там скорее всего будет картинка в параллаксе и очень неприятно будет когда игроки будут путаться где земля, а где фоновая картинка.
Кроме того все эти эффекты вовсе не потеряны - их в любой момент можно будет задействовать где-нибудь еще, не говоря уже о том, что это очень ранняя промежуточная версия постобработки, а не окончательный вариант.
Inflexible #3 - 6 лет назад 0
Голосов: +0 / -0
"пробный фильтр - затемнение земли на границе с небом" лучше всех выглядело... непонятно, почему выбрал другой вариант.
ksi2 #4 - 6 лет назад 0
Голосов: +0 / -0
Пока не совсем понятно, ждем-с апов ^_^
prog #5 - 6 лет назад (изм. ) 0
Голосов: +0 / -0
alexprey, это тоже будет.
  • в реальных условиях генератор мира будет выдавать более интересный результат, чем сплошная стена.
  • в планах реализовать минимальное смешивание текстур чтобы переход от одной текстуры к другой выглядел более плавно.
  • теоретически можно прикрутить вариации, если первых двух пунктов не хватит для приличной картинки.
Но на самом деле именно выделение контуров было взято в качестве примера по двум причинам:
  • сейчас практически не реализовано разделение заднего и переднего слоев и один из способов это сделать заключается именно в выделении контура каким-либо способом.
  • выделение контура реализовать очень просто, а над всем остальным нужно уже подумать.
upd:
Небольшой эксперимент с фильтром на тему разделения слоев карты.
alexprey #6 - 6 лет назад 0
Голосов: +0 / -0
prog, тебе бы не границы подсвечивать, а придумать бы что-нибудь с землей, а то рябит в глазах от одинаковости.
1

А я еще живой, я розовый и теплый!

» Requested Eternity
Проект жив. Подробности внутри.

Читать далее...
Таранес #1 - 6 лет назад 0
Голосов: +2 / -2
А я еще живой, я розовый и теплый!
Ваша жизнь не ваша заслуга, а наша недоработка!
4

отчет за 29.05.2014

» Requested Eternity

29.05.2014

  • реализован прототип выгрузки фрагментов карты на диск

Читать далее...
Кет #1 - 6 лет назад (изм. ) 0
Голосов: +0 / -0
Ну и напоследок - зачем нужна приоритезированная выгрузка чанков? Ради возможности иметь работающие машины или еще что-то, требующее наличия загруженного чанка на большом расстоянии от игрока. Например, представь себе вагонетку, которая ездит по рельсам и перевозит грузы. Если выгружать все, что слишком далеко от игрока, то вагонетка уткнется в край и просто остановится до тех пор, пока не будут загружены чанки дальше, а если в наличии будет интеллектуальная система выгрузки чанков, то для вагонетки будут загружаться чанки по пути ее следования и если вагонеток по этому пути будет ездить много и часто, то система не будет пытаться выгрузить эти чанки без крайней необходимости.
Да, я вот в Майнкрафте как-то делал электрички — обнаружил, что там эта система работает плохо. На определённом расстоянии механизмы начинали рассинхронизироваться.
prog #2 - 6 лет назад 1
Голосов: +1 / -0
ZLOI_DED, не переживай, большая часть концепций и алгоритмов уже продуманы и часть даже расписана на бумаге. Просто все делается шаг за шагом и постепенно улучшается - вчера был прототип, едва справляющийся со своими функциями, а дальше его модули будут постепенно заменяться на нормальные.
Делать чанки больше нельзя по нескольким причинам, в первую очередь это связано с особенностями передачи данных на GPU, но не только. Вместо этого в один файл будет записываться много чанков - в начале таблица смещений, по которой можно найти нужный чанк, а дальше сами чанки. Для начала сойдет, а потом надо будет заменить на еще более интересную штуку, слегка похожую на виртуальную файловую систему.
А вот хранить список сохраненных чанков это уже немного лишнее - карта ведь бесконечная и список этот будет расширяться до бесконечности - есть смысл хранить только список загруженных чанков и флаг наличия в них изменений чтобы не выгружать на диск чанки, которые не изменились в сравнении с сохраненной версией.
Что касается создания радиуса вокруг игрока, в котором хранятся загруженные чанки это мало чем принципиально отличается от видимых камерой чанков, если только не заниматься загрузкой-выгрузкой в отдельном потоке - тогда действительно имеет смысл хранить буфер чанков вокруг области видимости чтобы не тормозить передвижение камеры на время загрузки новых чанков.
Ну и напоследок - зачем нужна приоритезированная выгрузка чанков? Ради возможности иметь работающие машины или еще что-то, требующее наличия загруженного чанка на большом расстоянии от игрока. Например, представь себе вагонетку, которая ездит по рельсам и перевозит грузы. Если выгружать все, что слишком далеко от игрока, то вагонетка уткнется в край и просто остановится до тех пор, пока не будут загружены чанки дальше, а если в наличии будет интеллектуальная система выгрузки чанков, то для вагонетки будут загружаться чанки по пути ее следования и если вагонеток по этому пути будет ездить много и часто, то система не будет пытаться выгрузить эти чанки без крайней необходимости. Аналогично для любых других действий, происходящих на границе загруженной области - принудительная выгрузка всего, что находится вне области приведет к загрузке-выгрузке активных чанков на границе каждый такт до тех пор, пока не закончится процесс, требующий загрузки дополнительных чанков или не выгрузятся все чанки, связанные с этим процессом (тогда процесс будет заморожен и возобновится после загрузки).
ZLOI_DED #3 - 6 лет назад (изм. ) 0
Голосов: +0 / -0
Ну ты блин даёшь... Столько заморачиваться над этим... ты же игру сделать не успеешь. Делай чанки больше, клади их в один файл через байтовую запись команд (т.е. вначале хедер, чтобы идентифицировать карту, потом - команда (1byte) и параметры). Не бери в голову все эти свои приоритеты - ни к чему хорошему это не приведёт. Вот храни в памяти список id или координат сохранённых чанков (чтобы каждый раз не загружать). Вот ты загрузил чанк в память, как только игрок из него вышел - проверяй его на наличие в этом списке и если его там нет - добавляй туда и на диск. Соответственно, те что за n-чанков - просто удаляй из памяти, а когда оно потребуется (а требоваться оно должно не при появлении в границе обзора, а за n-чанков до этого) - загружай с диска, но не удаляй. Вот и всё.
prog #4 - 6 лет назад 0
Голосов: +0 / -0
Надеюсь мне простят этот небольшой абуз, призванный противодействовать исчезновению ресурса из ленты в никуда после ухода с первой страницы.
1

отчет за 24.05.2014

» Requested Eternity

24.05.2014

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

Читать далее...
ksi2 #1 - 6 лет назад 0
Голосов: +0 / -0
Интересно, что вышло :)
3

Взрывай-разрушай

» Requested Eternity
Подборка скриншотов с результатами работы различных алгоритмов симуляции взрывов.

Читать далее...
prog #1 - 6 лет назад 0
Голосов: +0 / -0
Buulichkaa, сори, не уследил, сделано.
Buulichkaa #2 - 6 лет назад 0
Голосов: +0 / -0
убери эту тучу картинок из краткого, ужс же
ksi2 #3 - 6 лет назад 0
Голосов: +0 / -0
Отлично вышло)
1

отчет за 23.05.2014

» Requested Eternity

23.05.2014

  • выспался и разобрался почему не сработала передача информации о смещении в экранный фильтр
  • в свете новых данных возобновлена работа над экранным фильтром
  • задействована реализованная ранее возможность иметь двухслойную поверхность

Читать далее...
prog #1 - 6 лет назад 0
Голосов: +0 / -0
Прошу прощения за наглое искусственное поднятие ресурса в ленте, это все в экспериментальных целях чтобы проверить теорию, связанную вот в этим:
1

отчет за 20.05.2014

» Requested Eternity
В некоторых кругах бытует мнение, что писать короткие отчеты о сделанном за день это хорошая традиция.

20.05.2014

  • Принято решение вести отчеты. Ежедневные или не очень.
  • Реализована нормальная WASD камера для режима свободного полета.
  • Начата реализация экранного фильтра для пост-эффектов. подробнее
  • Перенесено две записи из блога в статьи для последующей доработки. подробнее
prog #1 - 6 лет назад 0
Голосов: +0 / -0
Прошу прощения за наглое искусственное поднятие ресурса в ленте, это все в экспериментальных целях чтобы проверить теорию, связанную вот в этим:
2

отчет за 22.05.2014

» Requested Eternity

22.05.2014

  • реализован экранный фильтр.
  • пришлось временно отказаться от использования экранного фильтра.
  • начата реализация выгрузки дальних фрагментов карты на жесткий диск.

Читать далее...
prog #1 - 6 лет назад 0
Голосов: +0 / -0
Кет, считай то-же самое что и массив 2D текстур одинакового размера, только еще со смешиванием между слоями. На практике применяются довольно редко и жрут порядочно ресурсов. Массивы текстур появились позже и не на всем железе поддерживаются, но работают быстрее, да и смешивание между слоями не всегда нужно.
Кет #2 - 6 лет назад 0
Голосов: +0 / -0
А что такое 3D-текстура?
2

Рендеринг: Фильтр или не фильтр

» Requested Eternity

Первичная версия после переноса из блога


Читать далее...
prog #1 - 6 лет назад 0
Голосов: +0 / -0
Mihahail, хороший свет на современных технологиях еще не умеет (разработки есть, но пока не в ядре движка), а вот сама работа с шейдерами там на высоте.
Mihahail #2 - 6 лет назад 0
Голосов: +0 / -0
Ктстаи, jmonkey умеет шейдеры?