Вверх ↑
Этот топик читают: Гость
Ответов: 1778
Рейтинг: 121
#1: 2021-04-09 22:16:57 ЛС | профиль | цитата
Коллеги, чего то меня переклинело...
Ситуация такая:
Необязательная лирика.
Долго бился над проблемой как сделать процедурную генерацию сюжетов для книжек и игр.
Худо бедно с текстовым представлением получилось, но для игр совсем не подходит!
Даже для интерактивных текстовых приключений.
С другими формами передачи историй не получалось из-за большого объёма контента.
Нашёл форму такой передачи с процедурной генерацией карт и контента под сюжет. (кому интересно, расскажу и присоединяйтесь - дело интересное).
Это прототип на котором всё получается https://disk.yandex.ru/d/CWLtZypNxJjZYg , но ничего общего с sci-fi и особенно по графике это дело не подходит https://disk.yandex.ru/i/huRSfvFkR6mLEQ. Все истории будут проходить на картографическим корабле в дальнем космосе.
По этому решил доделать современный движок для этого дела, который делал для HiAsm.
По понятным причинам UE, Unity и другие монстры не подходят для этих целей.
Но пока всей этой лабудой занимался несколько лет, всё забыл как в HiAsm всё.
Вопрос такой:
Будет такой файл https://disk.yandex.ru/d/g1yFuLwyXJe7ZA - совсем не маленький будет (для нового пакета FPC тоже) и он будет юзаться в каждом компоненте движка.
Не будет ли увеличиваться объём кода из-за этого, или лучше разбить по компонентам?
Дело в том, что я хочу подключить скриптовый язык для удобства, а регистрировать все функции в нём удобней из одного такого файла, нежели из множества маленьких.

Редактировалось 6 раз(а), последний 2021-04-09 23:17:54
карма: 5

0
vip
#1.1контекстная реклама от партнеров
Ответов: 1967
Рейтинг: 630
#2: 2021-04-14 18:10:55 ЛС | профиль | цитата
flint2, думаю что не нужно разбивать по компонентам. Насколько разбираюсь разбиванием на компоненты, выигрыш в размере будет не существенный, а то и полностью отсутствовать. А вот проблем при разработке, доработке и т.п. будет в разы больше. Так что прописать:
uses RiBox3D.pas;
карма: 9

0
Ответов: 1778
Рейтинг: 121
#3: 2021-05-25 18:38:25 ЛС | профиль | цитата
Дело такое, чтоб тему поддержать, а то всё заглохло...
Давно пользуюсь таким 2D\3D движком https://disk.yandex.ru/d/2lfskB1uYZzUzg почитайте https://disk.yandex.ru/d/bMkhogOn65BBVg .
Короче, начал делать такую простыню https://disk.yandex.ru/d/db5YBwhH7c3e6Q (уже треть сделал), пока под пакет delphi, но хотелось бы и под FPC 2.6.0 чтобы пошло, потому что на C++ вряд-ли кто захочет перейти, а было-бы прекрасно иметь кроссплатфоменный HiAsm.
Короче, с типами ничего не напутал, в FPC будут работать? Вот родное: https://disk.yandex.ru/d/jqZQ2QL-3_62uQ .
( есть прекрасный кроссплатфоменный компилятор TCC_ Tiny C, есть не менее замечательный C++ Компилятор tcpp(многие кроссплатфоменные среды разработки на нём делают - штук пятнадцать, на нём можно и следующую кроссплатфоменнкю версию HiAsm сделать(верится с трудом). - на них сейчас и работаю, причём TCC_ Tiny можно пользовать как и скриптовый язык. И это не никому не нужный монстр VS, или mingw и ежи с ними).
Сама задумка:
То есть, пакет OpenGL годится лишь для лабораторных работ, чтобы понять суть - каши на нём не сваришь + тормоза.
Сам движок уже имеет фукции высшего порядка и не только графики, наверное они имеют место быть, но даже такими кубиками много не навоюешь.
Простыня нужна для того, чтобы прицепить скриптовый язык, в моём понимании LUA, или IC (про Барсик уже готово, но такое уже давно не носят (могу выложить)).
Чтобы можно было кубиками рисовать, нужны функции более высокого порядка.
Такие как: A* - (поиск пути с вариациями и штрафами http://theory.stanford.edu/~amitp/GameProgramming/), ИИ на цепях Маркова https://gamedev.ru/code/articles/Markov_chain_AI, а не конечные автоматы, тот-же json, хотя он в движке есть, но поднять на более абстрактные уровни, сценарии сцен, генерация Map, Abstract_Manager, Abstract_World, а не физика что в движке, диаграммы Вороного, с 2.5D тоже много чего можно поднять на более абстрактный уровнь https://gamedev.ru/projects/forum/?id=260824&m=5389496#m9. - 9 пост, равнопромежуточное преобразование кубической карты https://gamedev.ru/code/forum/?id=260463&page=3&m=5379968#m33 https://gamedev.ru/code/forum/?id=260463&page=3&m=5380026#m42 ...
(33 и 42 посты)
P.S.
Это я в приподнятом настроении с дачи приехал, дома никого нет в ближайшие до сентября...
Уже второй подход делаю, к этой теме.
Есть ли интерес у кого и кто помочь желает?
А то получится, вот MAV проделал огромный труд, и чё?
Правда это обёртка над GL и ... и всё!
Например вот такие штуки гннерируются в мгновение ока https://disk.yandex.ru/d/CWLtZypNxJjZYg
Тут не было задачи навести красоты, а была проба пера генерации сцены.
(Я увлекаюсь процедурной генерацией рассказов, а под них сценарий сцены, поведение юнитов и диалоги).
На самом деле на движке можно сделать тоже самое, что и на UE и Unity и при этом не попадаешь в их рабство.
Короче, можно сделать конфетку!

Редактировалось 9 раз(а), последний 2021-05-26 12:13:12
карма: 5

0
Ответов: 1778
Рейтинг: 121
#4: 2021-05-26 10:48:44 ЛС | профиль | цитата
sla8a, спасибо за отклик!
Вчера был в слишком приподнятом состоянии, лоханулся не поблагодарив.
Сейчас здоровье поправим и за работу.
Понимаю, что всю простыню смотреть - удовольствие ниже среднего.
По этому буду выкладывать отдельные функции с вопросами по типам.

Странное дело, все void, long int, unsigned int, просто int... в Бейсике проходят как простые Integer, а в LUA как float и всё работает. Там все типы динамические, смотря чего к чему присваиваешь.
Меня убивает монотонная работа, что 16 соток вскопать под картошку(намедни), что простыню писать!

Редактировалось 4 раз(а), последний 2021-05-26 11:50:47
карма: 5

0
Ответов: 4695
Рейтинг: 520
#5: 2021-05-27 16:38:33 ЛС | профиль | цитата
flint2, держи планку выше

https://youtu.be/oYxIGQRIR7Q

Редактировалось 1 раз(а), последний 2021-05-27 16:39:06
карма: 6
0
Ответов: 160
Рейтинг: 7
#6: 2021-05-28 15:40:44 ЛС | профиль | цитата
Студия
Привет пропажа
Флинт
Привет,где плавали пираты?

Редактировалось 1 раз(а), последний 2021-05-28 15:42:44
карма: 1

0
Ответов: 915
Рейтинг: 12
#7: 2021-06-05 22:42:34 ЛС | профиль | цитата
Black Shark Graphics Engine
(Полностью на паскале и вполне живой и развивается )
https://bshark.org/
Для текущей версии хайсма видимо придется сделать "DLL-обёртку" но не думаю, что это будет слишком уж сложно.

Редактировалось 1 раз(а), последний 2021-06-05 22:43:06
карма: 1

0
Ответов: 1778
Рейтинг: 121
#8: 2021-06-06 23:35:18 ЛС | профиль | цитата
flash1103
Привет!
Требуется настроение, чтобы всё красиво было.
Полуфабрикат не хочется выкладывать.
..., так королеву.
AlexKir
Ты не сердись, но такого https://bshark.org/ уже не носят.
По ходу дела, это обёртка над GL и движком назвать нельзя.
Движок - далеко не физика, шейдеры, частицы и графика...

Редактировалось 1 раз(а), последний 2021-06-06 23:59:01
карма: 5

0
Ответов: 915
Рейтинг: 12
#9: 2021-06-08 04:21:25 ЛС | профиль | цитата
flint2 писал(а):
Ты не сердись, но такого https://bshark.org/ уже не носят.

Ну ИМХО прелесть этого проекта в том что в первых он довольно новый( те же шейдеры поддерживает),а во вторых сравнительно и компактный и простой.Физика есть отдельно например тут https://github.com/BeRo1985/kraft, а если хочется "крутого API" у того же BeRo1985 уже давно есть pasvulkan https://github.com/BeRo1985/pasvulkan. Но честно говоря немного странно... Ведь даже Unity3D к Хайсму прикручивать ИМХО пошловато (Я уж молчу про Unreal Engine и ему подобных монстрах)

А что касается OpenGL то чем он полох, если половина игр все еще выпускается c поддержкой OpenGL? Для кроссплатформенных проектов альтернативы OpenGL (и его более новым расширениям ) вообще почти нет, для проектов на OpenVR альтернативы OpenGL еще меньше . )
Зы
Предвзятое отношение к OpenGL,извиняюсь за резкость, вообще из разряда снобизма вроде "Линукс не для игр" или "Мобильные платформы не для шутеров" . OpenGL просто прокладка между драйверами и прикладным софтом разница между возможностями ДиректХ, Вулкан и OpenGL всегда была исчезающе мала.

Вообщем вначале нужно задастся проектом уровня не ниже третьего дума и только потом можно честно рассуждать о "нехватке OpenGL" (Котрого кстати для и Дум 4 хватает, да более низкоуровневый Вулкан быстрее, но картинка вполне на одном уровне с OpenGL,а 124 fps на экране это если грубо 60 fps в VR, что для ВиАр(где обычно обновление экранчиков не выше 90 герц а у большинства шлемов вообще 60 герц) более чем нормально ! )
Дум4 OpenGL

Редактировалось 12 раз(а), последний 2021-06-08 10:55:38
карма: 1

0
Ответов: 1778
Рейтинг: 121
#10: 2021-06-08 12:53:32 ЛС | профиль | цитата
AlexKir
Unity3D к Хайсму прикручивать ИМХО пошловато (Я уж молчу про Unreal Engine и ему подобных монстрах)

Пусть бросит в меня камень тот, ко скажет, что это не так!
Все они самодостаточны и HiAsm, в той, или иной степени, уже есть внутри их самих.
Вообще задача нелёгкая скрестить ужа с ежом HiAsm и производительный игровой движок.
И дело совсем не в быстродейсвии графический части.
Да мы можем видеть в UE, Unity, UNIGINE различные Блупринты, которые решают примитивные задачи.
Но все они не движки, а среды разработки с сотнями плагинов, с одноимёнными движками внутри.
Конечно можно сделать отдельные кубики на кости, физику, ИИ, звук, деревья объектов, триггеры...
Но это всё будет выглядеть крайне неуклюже.
В том и заключается задача, чтобы сделать грамотную архитектуру, чтобы передача параметров и колбеки были максимально внутри движка, и минимально между кубиками.
Да, можно всё сделать в IC и будет всё шустро работать, но тога причём здесь HiAsm?
Стоит попробовать сделать пару - тройку разноплановых сцен с анимированными лесами, десятками триггеров и сотней персонажей со своими задачами и ИИ, динамическим освещением, а не со "статическими картинками https://disk.yandex.ru/d/Uo2eJ7LGscp8hA ", имеется в виду бестолковая анимация и циклы, то сразу станет ясно, что тысячей кубиков в схеме не обойтись.
Ну и скорострельность...
ДиректХ, Вулкан и OpenGL

Это всё графика и враперы к ним занимают незначительную часть в движках.

Что касается Дум 4, то я предлагаю движок покруче - попробуй!
В предлагаемом движке есть практически всё, что есть в HiAsm и даже чуть больше, кроме сетевых решений. Но это и не ММО-же.
Давай не будем рассматривать графику, с ней всё предельно просто, давай оценивать всё остальное - "суставы", A*, ИИ, 3D математика, тела (физика там только одна из частей), шарниры, лучи...
с OpenGL,а 124 fps на экране это если грубо 60 fps в VR, что для ВиАр(где обычно обновление экранчиков не выше 90 герц а у большинства шлемов вообще 60 герц) более чем нормально ! )

VR и шлемы субстанция тёмная и хорошо будет, что на 10 000 хоть одному человеку будет интересно. Но и на всякий случай есть в движке такой API.
Ну опять-жо, это графика.

Редактировалось 6 раз(а), последний 2021-06-08 14:18:14
карма: 5

0
Ответов: 915
Рейтинг: 12
#11: 2021-06-09 16:12:24 ЛС | профиль | цитата
flint2 писал(а):
И дело совсем не в быстродейсвии графический части.

Ура! Хоть кто-то это понимает.
То теперь нужно сделать следующий шаг и понять, что не так важно каким именно образом достигается качественная картинка и используются ли при этом все возможности текущего поколения видео карт.
"Апрельский тезис" Гиф ролик моей ТехноДемки
(На самом деле довольно примитивно но ведь как смотрится ! (Особенно если учесть что основной смысл этой ТехноДемки в реальной поддержке OpenVR )

Кстати есть идея сделать полностью "софтверный рендер" но с поддержкой CUDA и OpenCL ( чисто для теста и сравнения с "обычными" АПИ )
"Не много оффтопа.."
Если это "выстрелит", то ИМХО это будет реально универсальная альтернатива с хорошим заделом на перспективу! Ведь все "супер эффекты"(причем даже те что не поддерживаются ни в одном АПИ ) давно математически описаны и общедоступны + их можно легко и свободно "выдумывать из головы", а все что нужно для их CUDA-реализации это качественно выполненная "распаралельность" задач на псевдо ядрах GPU. (Можешь сказать что CUDA и OpenCL слабо отличаются от "шейдерных расширений", но ИМХО это не так, математика доступная в шейдерах сильно указана а CUDA и OpenCP напротив стремятся к универсальности)
К тому-же CUDA-вычисление заметно проще организовать в "облачной-форме" как они заметно меньше зависят от видео подсистемы.


flint2 писал(а):
Стоит попробовать сделать пару - тройку разноплановых сцен с анимированными лесами, десятками триггеров и сотней персонажей со своими задачами и ИИ, динамическим освещением, а не со "статическими картинками https://disk.yandex.ru/d/Uo2eJ7LGscp8hA ", имеется в виду бестолковая анимация и циклы, то сразу станет ясно, что тысячей кубиков в схеме не обойтись.

1 Демка впечатляет (Хотя на вид это уровень Третьего Квака ).
2 По поводу "разноплановых сцен" то ИМХО самый красивый вариант создания "тестовых прогонов" это генерация псевдо случайных ландшафтов по минимальным описаниям (В духе " Ночь,Луна, Замок( на холме, высокий, не большой,стиль:Абстракция),Озеро,Луг,Лес ,Туман,Горы(на горизонте), Дуб(Большой,на Лугу) ").

flint2 писал(а):
Что касается Дум 4, то я предлагаю движок покруче - попробуй!


Упс... Это интересно! Гляну.

flint2 писал(а):
Давай не будем рассматривать графику, с ней всё предельно просто, давай оценивать всё остальное - "суставы", A*, ИИ, 3D математика, тела (физика там только одна из частей), шарниры, лучи...


Не совсем понял..
Если в привязке к текущему состоянию ХайАсм-а, то (ИМХО) для получения максимальной пользы от его "схемотехники" нужны четко структурированные пакеты с крупноблочными "макро-элементами" с минимумом "низкоуровневых функций" . (А от будет как с разделом OpenGL - он "вроде есть, а вроде его и нет".(то есть проще сделать IC чем юзать вроде бы неплохой по возможностям "набор кубиков") )

flint2 писал(а):
VR и шлемы субстанция тёмная и хорошо будет, что на 10 000 хоть одному человеку будет интересно. Но и на всякий случай есть в движке такой API.

1 О "субстанции VR ": "Темная" она очень ненадолго, ВиАр-мейнстрим уже в этом десятилетии НЕИЗБЕЖЕН.
2 "Но и на всякий случай есть в движке такой API" это замечательно.
flint2 писал(а):
Ну опять-жо, это графика.


VR это вот точно не графика... Почему ? А потому что "с точки зрения графики" в VR ничего особо не меняется (Стерео картинка может рендерится и на монитор и даже контроллеры приницпе можно использовать не надевая шлем или несмотря в его окуляры ). Но есть принципиально разница в построении взаимодействия с пользователем. В хорошем ВиАр приложении разрабы обязаны учитывать, то что ты находится ВНУТРИ сцены. Что заставляет переосмыслять даже такие вроде бы незаметные вещи, как менюшки, тулбары состояния и главное саму "механику мира". ( Если ты не сидишь перед монитором с клавиатурой, мышкой и джойстиком или даже "не машешь руками в окно" как в Kinect-интерфейсе то это качественно другая ситуация,даже не так уж сильно важно с помощью чего ты реально управляешь в "режиме погружения" важно что ты находишься ТАМ (в пространстве сцены) а не тут перед монитором... ...и
"Там вам не тут!" )
"Там вам не тут!"



Хотя иногда можно перепутать...


Редактировалось 16 раз(а), последний 2021-06-09 19:47:39
карма: 1

0
Ответов: 1778
Рейтинг: 121
#12: 2021-06-10 08:35:00 ЛС | профиль | цитата
AlexKir
(На самом деле довольно примитивно но ведь как смотрится ! (Особенно если учесть что основной смысл этой ТехноДемки в реальной поддержке OpenVR )

Да!
Отвечу потом. Только приехал из далёка ))
карма: 5

0
Ответов: 1778
Рейтинг: 121
#13: 2021-06-11 16:11:11 ЛС | профиль | цитата
AlexKir
https://disk.yandex.ru/d/hpHMLsmW3gjpKw

В хорошем ВиАр приложении разрабы обязаны учитывать, то что ты находится ВНУТРИ сцены. Что заставляет переосмыслять даже такие вроде бы незаметные вещи, как менюшки, тулбары состояния и главное саму "механику мира".
Да, соглашусь! Но это справедливо и без ВиАр.
Но честно говоря я от этого отошёл и от программирования тоже.
Меня сейчас больше занимает процедурная генерация сценариев в рамках которых "строится рассказ" с диалогами. Для каждой сцены генерируется игровая сцена и поведение персонажей.
То есть, при старте программы каждый раз синтезируется и проигрывается новая история, или продолжается начатая с записи.
Но вопросов много...
Сначала рассказы не получались - решил.
Потом как эти рассказы представить в виде игры, или интерактивной литературы?
Практически ни один жанр не подходит. Если посмотреть, то не в одной игре нет глубокого сюжета.
Подключился Yuriy0 и DEN 3D на том сайте, начали пробовать формы представления.
Визуальные новеллы это совсем не то, хотя там может быть много текста.
Пробовали от первого и третьего лица в 3D и 2D, шутеры, квесты и РПГ - всё упирается в контент и полноценное раскрытие сюжета!
Вроде нащупали, как генерить контент из составляющих. Пришли к симбиозу 3D-2D, но это не 2.5D! Полностью отказались от текста кроме диалогов и заданий. Но во главе угла всё равно стоит сюжет, а не стрелялка! Перестрелка, или квест являются маленькими эпизодами, которых и вовсе может и не быть.
Строятся не описание и фабула, а генерируются нужные параметры для построения сцен.
Вроде рождается новый жанр, а не симбиоз нескольких.
Вопросов ещё много, но это мне интересно.
Вот и понадобился свой движок, а не UE и еже с ними. По большому счёту, все они Гамемекеры, где шаг в сторону от шаблона - расстрел!
Сам движок не цель, а инструмент.
Конечно, по мере сил, буду прилаживать его к HiAsm - но тоже задача ещё та.
карма: 5

0
Ответов: 1778
Рейтинг: 121
#14: 2021-06-11 20:07:02 ЛС | профиль | цитата
AlexKir
Если в привязке к текущему состоянию ХайАсм-а, то (ИМХО) для получения максимальной пользы от его "схемотехники" нужны четко структурированные пакеты с крупноблочными "макро-элементами" с минимумом "низкоуровневых функций" .

Да, это понятно.
Вот сейчас и чешу репу, где эта золотая середина. Особенно не нравятся циклы в исполнении ХайАсм-а.
Склоняюсь к введению скриптов(язык скриптов - по барабану)с возможностью вызова не только API движка, но и методов кубиков(своих) не через точки, а из скрипта. Вот это уже будет на что-то похоже, но не факт.
В общем, пока пробую...

Редактировалось 1 раз(а), последний 2021-06-11 20:09:02
карма: 5

0
14
Сообщение
...
Прикрепленные файлы
(файлы не залиты)