Коллеги, чего то меня переклинело...
Ситуация такая:
Вопрос такой:
Будет такой файл https://disk.yandex.ru/d/g1yFuLwyXJe7ZA - совсем не маленький будет (для нового пакета FPC тоже) и он будет юзаться в каждом компоненте движка.
Не будет ли увеличиваться объём кода из-за этого, или лучше разбить по компонентам?
Дело в том, что я хочу подключить скриптовый язык для удобства, а регистрировать все функции в нём удобней из одного такого файла, нежели из множества маленьких.

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

flint2, думаю что не нужно разбивать по компонентам. Насколько разбираюсь разбиванием на компоненты, выигрыш в размере будет не существенный, а то и полностью отсутствовать. А вот проблем при разработке, доработке и т.п. будет в разы больше. Так что прописать:

Дело такое, чтоб тему поддержать, а то всё заглохло...
Давно пользуюсь таким 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

sla8a, спасибо за отклик!
Вчера был в слишком приподнятом состоянии, лоханулся не поблагодарив.

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

flint2, держи планку выше

https://youtu.be/oYxIGQRIR7Q

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

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

Black Shark Graphics Engine
(Полностью на паскале и вполне живой и развивается )
https://bshark.org/
Для текущей версии хайсма видимо придется сделать "DLL-обёртку" но не думаю, что это будет слишком уж сложно.

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

flash1103
Привет!
Требуется настроение, чтобы всё красиво было.
Полуфабрикат не хочется выкладывать.
..., так королеву.
AlexKir
Ты не сердись, но такого https://bshark.org/ уже не носят.
По ходу дела, это обёртка над GL и движком назвать нельзя.
Движок - далеко не физика, шейдеры, частицы и графика...

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

Ну ИМХО прелесть этого проекта в том что в первых он довольно новый( те же шейдеры поддерживает),а во вторых сравнительно и компактный и простой.Физика есть отдельно например тут 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 герц) более чем нормально ! )

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

AlexKir

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

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

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

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

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

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

Кстати есть идея сделать полностью "софтверный рендер" но с поддержкой CUDA и OpenCL ( чисто для теста и сравнения с "обычными" АПИ )



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



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



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


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


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

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

AlexKir

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

AlexKir
https://disk.yandex.ru/d/hpHMLsmW3gjpKw

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

Редактировалось 10 раз(а), последний 2021-06-11 18:16:28

AlexKir

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

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

Я тут на выходных пытался преодолеть "застой в отдельно взятом проекте" путем "героического превозмогания" ... Вообщем как там? "Мы многого достигли... Но давайте пожелаем друг другу больше такого и такими образом не достигать!"

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


Эх когда же я доберусь до просмотра настоящей схемы хайасма? Но вроде теперь проект уверенно приближается к "уровню три" и что-бы "закрыть уровень два" нужно сделать хоть какой-то "показ готовой схемы" а для этого я как раз планирую сделать реальный SHA-парсер.

--- Добавлено в 2021-06-14 21:10:40

Кстати возможно вместо движка в хайасме можно использовать технологии Web-VR ?

https://roskelld.github.io/Wolf3DVR/
https://my.matterport.com/show/?m=Vz8kCqGRjQA
https://www.babylonjs.com/demos/hillvalleyvr/
По сути все что нужно это расширить стандартный пакет Wеb!
Зы
Про "заброшенное программирование" это зря ! "Соскочить с бронепоезда" просто, а вот потом догнать довольно трудно.
(Имею печальный опыт который реально ДРОГО (причем в потерянных годах жизни ) мне обошелся! )

Редактировалось 3 раз(а), последний 2021-06-14 21:16:02