поидее можно наверно сделать свой новый мини язык, посмотреть там, но так как это уже совсем другой может быть не интересно. как с С++ такое добавлять в существующий бекенд я не знаю
походу надо писать правильно, переносная байт код машина поидее проще, но тогда там надо думать как защищать
понял вас ну если вы сделаете 2 света с тригерным(я подправил думал не интересно), смотрите, получается вы хотите светить почти как в реале или у вас задумка с тёмнотой? может можно как-то обыграть как в первых версиях вова, тут главное не реалистичное сходство же, или вы хотите гиперреализм? там в зданиях ао может будет нужен кстати вот тут помогут запекания наверно, но с 3д я не вкурсе, я представил как в 2д из пляжа светлой теплой гаммы, перешли в теплое здание с деревянными стенами и теплым светом
я всегда себе представлял, что надо просто придать тон локации и перенести его в здание, ну да могут быть факелы там
тоесть подмешивать частички получается в свет это нагрузно вроде, хотя если рисовать частички на слоях обьектов вроде получаеся, ну да тогда надо смотреть
ну вот как раз смотрелось бы наверно прикольно, блочить на этапе компиляции через какой-то стек, код, но тут проблема генерировать тесты, там целые теории есть тут я пока не силен, но глянул по диагонали ваш проект, наверно его надо классифицировать, в макросы или в такие команды, которыми можно будет сконструировать код, тогда получается, вы конструируете плагин, и под эти части надо сообразить как математически или еще как дополнить доказательства валидности, тогда с вм, и таким плагином можно теоретически будет ограничить человеческий фактор, тоесть гоняем вроде С++, просто на етапе сборки надо доказать валидность типо помимо компилятора, ну я так представлял если представлять безопасность, понятно, что возможно это не лучшее решение, и возможно оно частично есть в ллвм, просто там такая ситуация, что есть конструкции, которые надо походу действительно через стек прогонять проверкой, но возможно это не совсем то крутое решение
есть Люа, есть Лисп, есть Java - подходы, вот я посмотрел мне понравилось стек машина
есть функция или плагин - в 1 файле, и в другом тесты, предлагаю создать стековый VM с Интерпретатором и там создать несколько инструкций. Она принимает 2 файла в своём окружении, и прогоняет по тестам до конца тестов первый файл и выводит результаты
на верху будет что-то типо 2 строки(что-то наподобии верхнего макро ассемблера)
%плагин %тесты
%принт
%плагин2 %тесты2
%принт
а так по разному конечно можно наверно
при интерпретации выводить информацию из файла что протестировать и как, с этой возможностью тогда и записывать тест в файл
так оно в междуязыках так и будет, потомучто коллайдер в дереве для столкновений и фиксируется террейном, а стены, скорее всего они обьекты на террейне значит тоже в дереве наверно, ну грубо говоря поддерево ригид боди обьектов, просто еще бывают кривые сглаженные террейны красивые, соотв по ним можно тоже ходить, и навигацию обьектов делать по дейкстре или по А* (8 направленное с диагоналями)
у вас будет орбит камера, вид от третьего лица, от первого?
всё верно выходит, код халфы решили портировать на вр, взяли и не медля кинули его каким он есть на вр, вдруг оказалось, что там не Пентиум в кратце, пришлось брать новую середину - это SSE
нет поидее, потомучто это не решает проблему коллизии(вернее убрать самый простой способ, но бб надо просто поправить поидее), как я понял бб задел дверь и заблокировал физику
плюс там вон 32 или 64 а округления бьют по расчетам
я решил проверить на системном уровне с текстом, в X11 отрисовку, и кароче там не выйдет так красиво как с наложением Area(тоесть в окне текста перерисовывает текст только тот который пересекся или обновился, строка только та где ввод, и тд, и так с ЮИ, и по производительности вообще красиво выходит ничего не дёргается не тирит), перерисовку нельзя делать всю это дорого, надо делать только в нужном месте, надо к этому стремиться, тоесть перерисовывать только тот квадрат, который изменился в интерфейсе, тогда накладных расходов будет меньше, кстати сами разрабы вроде не предоставляют такой доступ через свои интерфейсы АПИ, а значит в рейтрейсе со своим буфером частично такое можно реализовать наверно
на гпу пока не тестил этот подход, но подход имбовый
тоесть Clear не всего интерфейса, а только указаной точке с нужной шириной и высотой в окне
да, а морровинд и даггерфол не был дичью, и тогда не было клонов ), так-то если посмотреть, пейзаж красивее моделек если прям придираться и можно докапаться даже до старфилд с багами, еще вспоминается под такие оценки, первое впечатление о серии скайрим, идеал? нет конечно криво всё так-то
но ошибка выжившего, написать игру станет проще, значит будет новое решение, значит будет расти насмотренность, значит будет расти качество, тоесть попыток станет больше, значит больше лучшего будет из этих попыток как мне кажется, раньше же надо было всё написать, как я понимаю, а щас движков много, базу движок даёт
после запуска, XEmacs, мой взгляд на Gnu Emacs изменился, сам гну емакс крутой, и я его облазел вдоль и поперёк, но в нём есть конкретные проблемы, он хочет стать проще и ближе каждому, и растворяется как инструмент из-за этого. Если бы он был так же строк как XEmacs цены бы ему не было, и кнопки и подсветка и автоподополнение, вместо этого Емакс подсовывает мне комбайн, который я должен конфигурировать.
пройдёмся по конкретным деталям, нет строгого единого интерфейса и стиля, всплывающее окно по клику(вообще пойнт клик и окошко), организация буферов(+ менеджмент в интерейсе, а не где-то там), удобный интерфейс для изменения шрифта. и с такими буферами как в XEmacs банально удобнее работать, чем на биндах что-то пытаться вспомнить
я за то что в мире текста должны быть кнопки, из подхода интуитивного десктоп подхода
я бы пошел дальше и вообще бы сделал панель фундаментал по 1 команде где есть все команды в виде кнопок с всплвающей документацией чем лазеть по текстам
вот бы сурс на ansi С, я так и не осилил двиг на С, зато на плюсах ух разгуляться можно, даже не верится, что круто так работает
по моим ощущениям ECS система спорно, но удобно, потомучто она если так реализовывается в компонентах, то удобно, лучше нодовую структуру развивать и спец обьекты на уровнях нод, проходы чище, гладче поидее проходить по рендеру - хотя и от рендер системы зависит
что-то типо доменной архитектуры было круто наверно, доменно-нодовая структура наверно
дерево рендера сцены, дерево рендера уи, дерево обьектов на сцене, дерево обьектов уи, 2 дерева по столкновениям(юи и обьекты в сцене), суть та же но деревья специальные для столкновений, работает эпически просто, 2 дерева просто всегда идут вперед, 2 заиндексированы, и 2 как хранилища
она там как не пытайся всё равно в обжекты вырождается из-за запроса, чтобы ригид на обьекте был
но ведь нельзя писать на разных стандартах или можно? щас я наверно минус получу, тогда выходит, если обновилась библиотека "OpenSSL" - язык почти похож на коробку с библиотекой "почти" мне кажется, то на новую версию можно и не переходить, обновление языка, касается и безопасности в том числе, а не просто ради удобства что-то изменилось, поведение кодогенератора может отличаться, может быть улучшена поддержка чего-то, мне кажется новый стандарт как и новая версия или некая стабилити всегда свежесть и выйгрыш, да понимаю, есть килотонны кода, но я так попытался подумать в версии как смог
Gosling-Emacs вот например уже не собрать без знаний, "потомучто произошли изменения в кодинге" уже те какие всё как мне кажется уже фатальны на этапе сборки
таки да, простые задачи решают, и играет ограничение, к С легко можно пристыковать любую задачу, начиная от реализуй буфер строки-строк, до реализуй менеджер памяти на дереве, и как бы вау да, но иногда прикольно заюзать язык "X" и там будет куча условностей и нюансов реализаций в самом языке, поэтому решает наверно, просто механизм погружения в задачу лучший с ограничениями и попытками, чем ничего не делать и думать, но так можно придти к тому, что нужен язык "другой X или X-1 или X-2"
и потом разраб такой, по каким-либо причинам забивает на язык, и возвращается в язык спустя 3 года, и такой сидит и перед ним пролетают килотонны правил, ""так это можно, это нельзя, это было в легаси, так стоп это же теперь в самом новом стандарте" )
эх интересно
поидее можно наверно сделать свой новый мини язык, посмотреть там, но так как это уже совсем другой может быть не интересно. как с С++ такое добавлять в существующий бекенд я не знаю
походу надо писать правильно, переносная байт код машина поидее проще, но тогда там надо думать как защищать
классная обложка это прям гну, цветёт и пахнет )
понял вас ну если вы сделаете 2 света с тригерным(я подправил думал не интересно), смотрите, получается вы хотите светить почти как в реале или у вас задумка с тёмнотой? может можно как-то обыграть как в первых версиях вова, тут главное не реалистичное сходство же, или вы хотите гиперреализм? там в зданиях ао может будет нужен кстати вот тут помогут запекания наверно, но с 3д я не вкурсе, я представил как в 2д из пляжа светлой теплой гаммы, перешли в теплое здание с деревянными стенами и теплым светом
я всегда себе представлял, что надо просто придать тон локации и перенести его в здание, ну да могут быть факелы там
тоесть подмешивать частички получается в свет это нагрузно вроде, хотя если рисовать частички на слоях обьектов вроде получаеся, ну да тогда надо смотреть
pythonopengl_game_engine_update_4_reflections/ вот еще что видел
в третьей серии у него четко прям видны тени
могу посоветовать, тут на хабре есть обзор Doom3 там есть некоторые концепции, которые по началу могут быть не интересными, но они очень тонкие
ну вот как раз смотрелось бы наверно прикольно, блочить на этапе компиляции через какой-то стек, код, но тут проблема генерировать тесты, там целые теории есть тут я пока не силен, но глянул по диагонали ваш проект, наверно его надо классифицировать, в макросы или в такие команды, которыми можно будет сконструировать код, тогда получается, вы конструируете плагин, и под эти части надо сообразить как математически или еще как дополнить доказательства валидности, тогда с вм, и таким плагином можно теоретически будет ограничить человеческий фактор, тоесть гоняем вроде С++, просто на етапе сборки надо доказать валидность типо помимо компилятора, ну я так представлял если представлять безопасность, понятно, что возможно это не лучшее решение, и возможно оно частично есть в ллвм, просто там такая ситуация, что есть конструкции, которые надо походу действительно через стек прогонять проверкой, но возможно это не совсем то крутое решение
есть Люа, есть Лисп, есть Java - подходы, вот я посмотрел мне понравилось стек машина
https://godbolt.org/z/jW3TTqoz1
может можно как-то форт применить
при этом мне нравится Лисп и нравится XEmacs и вот тоже диллема, что лучше
есть функция или плагин - в 1 файле, и в другом тесты,
предлагаю создать стековый VM с Интерпретатором и там создать несколько инструкций. Она принимает 2 файла в своём окружении, и прогоняет по тестам до конца тестов первый файл и выводит результаты
на верху будет что-то типо 2 строки(что-то наподобии верхнего макро ассемблера)
а так по разному конечно можно наверно
при интерпретации выводить информацию из файла что протестировать и как, с этой возможностью тогда и записывать тест в файл
так оно в междуязыках так и будет, потомучто коллайдер в дереве для столкновений и фиксируется террейном, а стены, скорее всего они обьекты на террейне значит тоже в дереве наверно, ну грубо говоря поддерево ригид боди обьектов, просто еще бывают кривые сглаженные террейны красивые, соотв по ним можно тоже ходить, и навигацию обьектов делать по дейкстре или по А* (8 направленное с диагоналями)
у вас будет орбит камера, вид от третьего лица, от первого?
да, но чтобы работал везде нужен С -ansi пайтон поидее
всё верно выходит, код халфы решили портировать на вр, взяли и не медля кинули его каким он есть на вр, вдруг оказалось, что там не Пентиум в кратце, пришлось брать новую середину - это SSE
нет поидее, потомучто это не решает проблему коллизии(вернее убрать самый простой способ, но бб надо просто поправить поидее), как я понял бб задел дверь и заблокировал физику
плюс там вон 32 или 64 а округления бьют по расчетам
я решил проверить на системном уровне с текстом, в X11 отрисовку, и кароче там не выйдет так красиво как с наложением Area(тоесть в окне текста перерисовывает текст только тот который пересекся или обновился, строка только та где ввод, и тд, и так с ЮИ, и по производительности вообще красиво выходит ничего не дёргается не тирит), перерисовку нельзя делать всю это дорого, надо делать только в нужном месте, надо к этому стремиться, тоесть перерисовывать только тот квадрат, который изменился в интерфейсе, тогда накладных расходов будет меньше, кстати сами разрабы вроде не предоставляют такой доступ через свои интерфейсы АПИ, а значит в рейтрейсе со своим буфером частично такое можно реализовать наверно
на гпу пока не тестил этот подход, но подход имбовый
тоесть Clear не всего интерфейса, а только указаной точке с нужной шириной и высотой в окне
да, а морровинд и даггерфол не был дичью, и тогда не было клонов ), так-то если посмотреть, пейзаж красивее моделек если прям придираться и можно докапаться даже до старфилд с багами, еще вспоминается под такие оценки, первое впечатление о серии скайрим, идеал? нет конечно криво всё так-то
но ошибка выжившего, написать игру станет проще, значит будет новое решение, значит будет расти насмотренность, значит будет расти качество, тоесть попыток станет больше, значит больше лучшего будет из этих попыток как мне кажется, раньше же надо было всё написать, как я понимаю, а щас движков много, базу движок даёт
хочется чего-то свежего старого типо статического анализатора )
Скрытый текст
после запуска, XEmacs, мой взгляд на Gnu Emacs изменился, сам гну емакс крутой, и я его облазел вдоль и поперёк, но в нём есть конкретные проблемы, он хочет стать проще и ближе каждому, и растворяется как инструмент из-за этого. Если бы он был так же строк как XEmacs цены бы ему не было, и кнопки и подсветка и автоподополнение, вместо этого Емакс подсовывает мне комбайн, который я должен конфигурировать.
пройдёмся по конкретным деталям, нет строгого единого интерфейса и стиля, всплывающее окно по клику(вообще пойнт клик и окошко), организация буферов(+ менеджмент в интерейсе, а не где-то там), удобный интерфейс для изменения шрифта. и с такими буферами как в XEmacs банально удобнее работать, чем на биндах что-то пытаться вспомнить
я за то что в мире текста должны быть кнопки, из подхода интуитивного десктоп подхода
я бы пошел дальше и вообще бы сделал панель фундаментал по 1 команде где есть все команды в виде кнопок с всплвающей документацией чем лазеть по текстам
вот бы сурс на ansi С, я так и не осилил двиг на С, зато на плюсах ух разгуляться можно, даже не верится, что круто так работает
по моим ощущениям ECS система спорно, но удобно, потомучто она если так реализовывается в компонентах, то удобно, лучше нодовую структуру развивать и спец обьекты на уровнях нод, проходы чище, гладче поидее проходить по рендеру - хотя и от рендер системы зависит
что-то типо доменной архитектуры было круто наверно, доменно-нодовая структура наверно
дерево рендера сцены, дерево рендера уи, дерево обьектов на сцене, дерево обьектов уи, 2 дерева по столкновениям(юи и обьекты в сцене), суть та же но деревья специальные для столкновений, работает эпически просто, 2 дерева просто всегда идут вперед, 2 заиндексированы, и 2 как хранилища
она там как не пытайся всё равно в обжекты вырождается из-за запроса, чтобы ригид на обьекте был
но ведь нельзя писать на разных стандартах или можно? щас я наверно минус получу, тогда выходит, если обновилась библиотека "OpenSSL" - язык почти похож на коробку с библиотекой "почти" мне кажется, то на новую версию можно и не переходить, обновление языка, касается и безопасности в том числе, а не просто ради удобства что-то изменилось, поведение кодогенератора может отличаться, может быть улучшена поддержка чего-то, мне кажется новый стандарт как и новая версия или некая стабилити всегда свежесть и выйгрыш, да понимаю, есть килотонны кода, но я так попытался подумать в версии как смог
Gosling-Emacs вот например уже не собрать без знаний, "потомучто произошли изменения в кодинге" уже те какие всё как мне кажется уже фатальны на этапе сборки
таки да, простые задачи решают, и играет ограничение, к С легко можно пристыковать любую задачу, начиная от реализуй буфер строки-строк, до реализуй менеджер памяти на дереве, и как бы вау да, но иногда прикольно заюзать язык "X" и там будет куча условностей и нюансов реализаций в самом языке, поэтому решает наверно, просто механизм погружения в задачу лучший с ограничениями и попытками, чем ничего не делать и думать, но так можно придти к тому, что нужен язык "другой X или X-1 или X-2"
и потом разраб такой, по каким-либо причинам забивает на язык, и возвращается в язык спустя 3 года, и такой сидит и перед ним пролетают килотонны правил, ""так это можно, это нельзя, это было в легаси, так стоп это же теперь в самом новом стандарте" )
есть еще include <print> поидее квинтессенция формат и iostream через удобный интерфейс, очень удобно получается всё спрятали