компилятор собрать можно кланг например нет?, вообще я щас дич наверно напишу, но можно наружу вытащить семантику согласованную, а поддержку языка компилировать, получается ставим компилятор(компилируем), и компилируемся(или настраиваемся на ллвм-ке к своей семантике) к своему компилятору(или к своей семантике ). Ну да звучит фантастично, зато единый язык
я просто насмотрелся пример Калейдоскоп, вот мечтаю спрятать С++ в такой компилятор или транслятор не знаю, а в семантике оставить то что я хочу
скриптовый язык в С++ типо не знаю - наверно, тоесть пользователь пишет программу, и она по настроенным канонам внутри создаёт С++ код, так можно и стандарты настраивать и прочее, ну получается масло маслянное, но вроде прикольно
Суть ответа почему так, тоесть "почему" надо или придётся понимать рекурсию таится в мотивации, если мы пишем примеры, по подобию как на бумаге, то это одно, раздел изучили? изучили. Но сами мотивации не в примерах на бумаге, а на боевом примере. И тогда надо будет после некоторых вводных, мотивируясь большой целью, понять почему там очередь с приоритетом. И точно так же с деревьями. Наивно же думать, что пример, который останется на бумаге, будет иметь полную имплементацию, тоесть придётся определиться. Какие структуры, или как удобно(как хотелось бы решить и так далее), какая мотивация решения задачки, будут ли нпцшки ходить и прочее, и там уже мотивация, чтобы не лагало хотябы это...
можно добавить нескучное сжатие из будущего jpeg-xl, или завелосипедить на С ТГА -труколор сжатие чередующихся длин серий ) ух, первый просто фантастика, второй без магии на выходе, но если велосипедить, то мозг поломает нормально ), что интересно на С в строках второй алгоритм наитривиальнейший - просто можно недели ловить эти пиксели )
зная что поиск пикселей не поможет от примера со строками )
по-сути да вдохнуть можно, например если реализовывать буфер на jpeg-xl если сравнить его с png, я сегодня тестил свежую версию, то там разница размера колоссальна, да конечно, можно рисовать в терминал аски, но терминал, всё чаще для набросков, понятно, что символы которые в терминале будут чаще как пиксели, и тут либо tga и энтузиазм к своему сжатию или как раз такие форматы как jpeg-xl поидее, и как раз это приближает к реализациям всё ближе, ведь в терминале действительно набросок всё чаще фановый, сам то буфер будет или лучевой или растеризированный поидее
Это вы еще не затронули нюанс, кто и как просчитывает эту деревню. Ведь в фрустуме игрока не вся деревня, а дай бог 1 нпс, если игрок зашел в безлюдный дом... Надо как-то оптимизированно, пока склоняюсь к мнению, не рисовать - это минимум, то что не видно, но вот как обноовлять.
Конечно, может можно фрустум как матрицу накинуть на игрока, и при рендере знать "что внутри бокса -фрустума", но не знаю, пока звучит не чётко для меня.
спасибо, интересно, тема графов интересная, наблюдать как это работает интересно ), хотя вроде и нет в этом ничего такого, нпц в 3д ходють прям как в скайриме ), автопуть вот это вот всё это тоже графы поидее, одного графа с рандомным броском поиска в ограниченном пространстве достаточно, чтобы нпц зажили прям - это удивительно
да я уверен нет там никакой магии, как бы проще сказать походу нового мы ничего не увидем всё теже указатели, как я понял, но я могу ошибаться вижу птр - думаю что указатель
вся магия на сколько я понял, это перестать писать на реактиве, он разгрузит что-то там, юзать структуры ну и указатели, а тот язык от указателей не защитит всё равно
и как бы получается стиль на паттерне flyObject is trivialData, поидее llvm хорошо справляется с таким кодом ) и либо на С либо на грани С++ они одинаковы будут, можно даже без vtable поидее, но будет геморно
тоесть свои структуры так можно написать ) если нужен максимальный прирост просто можно переписать всё в таком стиле и сравнить )
классно было бы если бы чисто математически появился язык на базе Ocaml, который чисто математически исходя из входных данных просчитывал бы всю безопасность(adaptive-kernel,balance-kernel)
тоесть прога компилируемая, но с помощью ML(Multi-Language) слоёв он строил бы уникальную стратегию безопасности накладывая слой на программу и входные данные и имел бы адаптивные возможности к атакам, тоесть их с платформы и прочее брал бы, а код прогера между этим слоем типо
поидее на ML(Multi-Language) можно съэмулировать С наверно вот интересно кстати
вообще имея такие возможности странно, что Linux Foundation не стал это исследовать - это как минимум интересно, и поидее это не просто Раст в виде бороу чекера
это и не сеЛинукс наверно и не Раст, как я себе представляю, а некий язык с языками для политик безопасности тут и как раз тпм наверно можно было бы прикрутить
и вызывали бы С через этот слой с семантикой С, да и кстати по скрипту как я понимаю в ML можно семантику поменять поидее - + к поддержке поидее, но фантастика конечно
bool cmp11(const std::string_view& s1, const std::string_view& s2) {
return s1 == s2;
}
int main() {
std::string s1("hello");//явное владение
std::string s2("world");//явное владение
s1.clear();s2.clear();
std::cout<<cmp11(s1,s2)<<std::endl;
//отправка указателей на владельцев поидее
return 0;
}
точно так же и с выводом можно сделать поидее, явно аллоцировать владение строки(но не стараться хранить сразу стринг_вью там даже если покажется, что работает в кадрах будет видно, что где-то будет мусор), чтобы оно жило в своём кадре и отправлять только интерфейс на строку, но при условии, что владение существует
а как же Юникод, это же std::u32string и хэш uint32_t в char* с размером глифа, который отразится в аабб, разве это зоопарк или мы обсуждаем только ASCII? в аски просто стринг, или char строка и инт - кодпойнт, с аабб, по обратной связи вы возможно спросите как управлять такой строкой и текстом.
так ответ и кроется в реализации, если мы рисуем строки и они не изменны никогда, это заведомо текстура, если рисуем текстовый редактор, то пользователь манипулирует строкой через механизм 2д как бы мы этого не хотели, границы окна, границы текстБокса, границы глифа, так это еще учитывая то что у вас никогда не будет строки прямой, там будет сущность буффера даже в С++, изза того, что проще писать хэш во время открытия файла, соотв если это не текстовый редактор, надо реализовать механизм ввода символов через Юникод же, а это текстуры глифов с позициями, и там еще будут нюансы с линейностью, тоесть всё таки это через вектор да, ну тоесть vector-string-size? нет конечно, мы получаем метаданные глифа до отрисовки, в нужной локали, и реализовываем буффер вывода строки
если это 8битные вещи, там уже есть преднастроенные глифы, битмапы же тоже
странно тут как не крути буффер - его реализация будет одна, и она не будет string напрямую, это будут кусочки памяти char* от кодпойнта же
std::u32string. в С uint32_t и char* symbol, хранить строку можно в rope буфере - дереве, потомучто помимо пространства строки есть еще пространство 2д, строка в 2д будет ограничена краями, и задана размером глифа помимо наполнения самого квадрата глифом, а это значит если сцена реализована через дерево, строки, которые находятся в текстБоксе лучше хранить в дереве тоже
а если это текстура(неизменяемый текст), то это не строка а текстура предпосчитанная из строки движком текста
почему так, потомучто рекурсивный обход дерева при рендере частично выраждается в корутину с нюансами, тоесть рендерим квадратики
template<typename T>
void renderTreePASSUI(const SceneUINode<T>* root, Shader *shader,float dt,glm::mat4 &projection)
{
if (root == nullptr)
return;
// Обработка левого поддерева
renderTreePASSUI(root->left, shader,dt,projection);
// Рендер текущего объекта
const T& obj = root->object;
if (obj.VAO && *obj.VAO)
glBindVertexArray(*obj.VAO);
else{
outputError("Error on RENDER!");
return;
}
if (obj.textureID && *obj.textureID)
glBindTexture(GL_TEXTURE_2D, *obj.textureID);
glm::mat4 model = glm::mat4(1.f);
if (obj.type == OBJUITYPES::STATICUI && obj.pos) {
model = glm::translate(glm::mat4(1.f), *obj.pos);
model = glm::scale(model, obj.ptr->size); // размер 100x100 пикселей
model = glm::mat4(1.0f) * model;
shader->setMat4("uModel", model);
shader->setVec4("color", obj.ptr->color);
glDrawElements(GL_TRIANGLE_STRIP, 6, GL_UNSIGNED_INT, 0);
glBindVertexArray(0);
}
// Обработка правого поддерева
renderTreePASSUI(root->right, shader,dt,projection);
}
Скрытый текст
квадратики включая указатель в центре, потомучто это уже система УИ
рендер квадратиков, как видим векторов тут нету, вектор просто хранит обьекты, лично я считаю это нюансы нелинейного обхода данных, даже при условии что рендерится от начала до конца
тоесть по моему мнению в высоконагруженных приложениях нельзя просто так взять и
а теперь представье, что есть не только Виндовс, но и другие ОС, и там есть всякие флаги, банально какая-то ОС сама собирает компилятор GCC, теперь представьте, что вроде безопасность и прочее, но тут нам говорят, нет чувак юзай Generic или я падаю(хотя Генерик вроде по дефолту, но может есть тут тоже нюансы какие-то, 1 из нюансов, что если настройка екслюзивная компилятора/ров придётся насколько я знаю пересобирать софт, чтобы использовались эти настройки ) ), а там нам показали, например, что либу переписали на скорость и она тянет за собой компилятор, или наоборот, тянем растап, а там узнаёца, что компилятор на локалке не подходит, одинаковый код на опр сборке компиляторов по разному вроде работает, эта ситуация со всей базой внутри как раз и хочет это обходить, вы представляете какой рантайм там
попробуйте блендер собрать сегодня 4.4.0 там тоже есть пайтон, представляете если еще она кланг запросит, гцц, и пайтон, и в конце как финишная сборки раст еще соберёт, это ради того, чтобы заюзать решение блендер ну и допустим решили его скомпилять, как вам конечный дизайн? )
можно конечно пойти по простому пути, не настраивать ничего и пользоваться бинарником
просто раст как замена на бинарнике окей, как только реч идёт о настройках или зависимостях и не дай бог компиляции, собираться с растом на сколько я понимаю будет всё ) может я ошибаюсь конечно )
та же ситуация и с явой, и она поставляется бинарником, мы же не собираем все зависимости или собираем?)
тоесть может оказаться так, что производительность не первична ради поддержки на ОС или оборудовании, а это значит если нету бинарника с нужными настройками, придётся что-то делать если это не учтено, этим и красив С поидее
view = camera.getViewMatrix();
asp = (float)win.width / win.height;
projection = glm::perspective(glm::radians(45.0f), asp, 0.1f, 2000.f);
Oproj = glm::ortho(0.0f, float(win.width), 0.0f, float(win.height), -1.f, 1.f);
есть такой момент, и надо чтобы бл УИ например ниже красивое решение
pickObject(xpos, ypos, objectsUI, view, Oproj, &camera, &win, &picker);
...
glm::vec3 worldCoords{mouseX,mouseY,1.0f};
glm::vec3 worldCoordsZ{mouseX,mouseY,-1.0f};
// outputInfo(std::to_string(mouseX)," ",std::to_string(mouseY));
Ray ray = CreateRay(worldCoords, worldCoordsZ);//2D
я уи повесил на дерево тоже, и там были баги
(баг провявлялся следующим образом.
кнопка 1 но гденибудь скраю при тесте коллизии
ААББ дублируется).
с таким проходом сверху слева 0 0,
и по ААББ кнопки не повторяются -
выбранные елементы для коллизии не дублируются при
тесте пересечения, красивое решение
тоесть в теории можно избежать вообще обратных матриц
соотв можно настроить, там еще при загрузке фрибсд можно посмотреть переменные и примерить размеры консольки
но сама проблема глубже с фреймбуферами, чтобы понять проблему глубже надо задаться вопросом, как рисовать квадратик в окне из пикселей, без драйвера, который в SDL например, в софтверном!(там где нет шейдеров, потомучто Xorg медленный на сколько я знаю) варианте, и более менее пазл встанет на свои места
тоесть надо получить доступ к текущей конфигурации оборудования на уровне ускорения напрямую в граффическую карту, через SHM возможно, другой способ писать свой драйвер KMS, раньше это был DOS int13h наверно
фрагментация даже в расте произойдёт ) самое интересное, нету магии к сожалению, просто раст предлагает аля готовое решение на этапе компиляции ), далее же это для того чтобы положиться на Раст, на его механизм и тут будут теже проблемы как и всегда, перезапись/пересоздание и прочее, что иногда и не только на С/С++ приводит к фрагментации ), тоесть создать убирание утечек, надо было еще оптимизиатор по работе с памятью сделать и выводить на этапе компиляции вы неправильно работаете с памятью тут и тут, надо вот так, почитать можно тут, а так получается проект не собирается потомучто, там посчитались ссылки..., что-то проанализировалось, как бы собираешь, а логические ошибки не аналазируются полностью, и в итоге фрагментация может произойти всё равно, а если оно так, то синтаксис надо стандартизировать, чтобы читать и исправлять было удобно
компилятор собрать можно кланг например нет?, вообще я щас дич наверно напишу, но можно наружу вытащить семантику согласованную, а поддержку языка компилировать, получается ставим компилятор(компилируем), и компилируемся(или настраиваемся на ллвм-ке к своей семантике) к своему компилятору(или к своей семантике ). Ну да звучит фантастично, зато единый язык
я просто насмотрелся пример Калейдоскоп, вот мечтаю спрятать С++ в такой компилятор или транслятор не знаю, а в семантике оставить то что я хочу
скриптовый язык в С++ типо не знаю - наверно, тоесть пользователь пишет программу, и она по настроенным канонам внутри создаёт С++ код, так можно и стандарты настраивать и прочее, ну получается масло маслянное, но вроде прикольно
Суть ответа почему так, тоесть "почему" надо или придётся понимать рекурсию таится в мотивации, если мы пишем примеры, по подобию как на бумаге, то это одно, раздел изучили? изучили. Но сами мотивации не в примерах на бумаге, а на боевом примере. И тогда надо будет после некоторых вводных, мотивируясь большой целью, понять почему там очередь с приоритетом. И точно так же с деревьями. Наивно же думать, что пример, который останется на бумаге, будет иметь полную имплементацию, тоесть придётся определиться. Какие структуры, или как удобно(как хотелось бы решить и так далее), какая мотивация решения задачки, будут ли нпцшки ходить и прочее, и там уже мотивация, чтобы не лагало хотябы это...
можно добавить нескучное сжатие из будущего jpeg-xl, или завелосипедить на С ТГА -труколор сжатие чередующихся длин серий ) ух, первый просто фантастика, второй без магии на выходе, но если велосипедить, то мозг поломает нормально ), что интересно на С в строках второй алгоритм наитривиальнейший - просто можно недели ловить эти пиксели )
зная что поиск пикселей не поможет от примера со строками )
Скрытый текст
по-сути да вдохнуть можно, например если реализовывать буфер на jpeg-xl если сравнить его с png, я сегодня тестил свежую версию, то там разница размера колоссальна, да конечно, можно рисовать в терминал аски, но терминал, всё чаще для набросков, понятно, что символы которые в терминале будут чаще как пиксели, и тут либо tga и энтузиазм к своему сжатию или как раз такие форматы как jpeg-xl поидее, и как раз это приближает к реализациям всё ближе, ведь в терминале действительно набросок всё чаще фановый, сам то буфер будет или лучевой или растеризированный поидее
а там разве всегда будет ровно то нужное соотношение, вода испаряется, батарейка от солнца, ветряк от ветра
Это вы еще не затронули нюанс, кто и как просчитывает эту деревню. Ведь в фрустуме игрока не вся деревня, а дай бог 1 нпс, если игрок зашел в безлюдный дом... Надо как-то оптимизированно, пока склоняюсь к мнению, не рисовать - это минимум, то что не видно, но вот как обноовлять.
Конечно, может можно фрустум как матрицу накинуть на игрока, и при рендере знать "что внутри бокса -фрустума", но не знаю, пока звучит не чётко для меня.
спасибо, интересно, тема графов интересная, наблюдать как это работает интересно ), хотя вроде и нет в этом ничего такого, нпц в 3д ходють прям как в скайриме ), автопуть вот это вот всё это тоже графы поидее, одного графа с рандомным броском поиска в ограниченном пространстве достаточно, чтобы нпц зажили прям - это удивительно
99012
improved_string_formatting_in_rust
да я уверен нет там никакой магии, как бы проще сказать походу нового мы ничего не увидем всё теже указатели, как я понял, но я могу ошибаться вижу птр - думаю что указатель
вся магия на сколько я понял, это перестать писать на реактиве, он разгрузит что-то там, юзать структуры ну и указатели, а тот язык от указателей не защитит всё равно
и как бы получается стиль на паттерне flyObject is trivialData, поидее llvm хорошо справляется с таким кодом ) и либо на С либо на грани С++ они одинаковы будут, можно даже без vtable поидее, но будет геморно
тоесть свои структуры так можно написать ) если нужен максимальный прирост просто можно переписать всё в таком стиле и сравнить )
всё тривиал и темплейты )
классно было бы если бы чисто математически появился язык на базе Ocaml, который чисто математически исходя из входных данных просчитывал бы всю безопасность(adaptive-kernel,balance-kernel)
тоесть прога компилируемая, но с помощью ML(Multi-Language) слоёв он строил бы уникальную стратегию безопасности накладывая слой на программу и входные данные и имел бы адаптивные возможности к атакам, тоесть их с платформы и прочее брал бы, а код прогера между этим слоем типо
поидее на ML(Multi-Language) можно съэмулировать С наверно вот интересно кстати
вообще имея такие возможности странно, что Linux Foundation не стал это исследовать - это как минимум интересно, и поидее это не просто Раст в виде бороу чекера
это и не сеЛинукс наверно и не Раст, как я себе представляю, а некий язык с языками для политик безопасности тут и как раз тпм наверно можно было бы прикрутить
и вызывали бы С через этот слой с семантикой С, да и кстати по скрипту как я понимаю в ML можно семантику поменять поидее - + к поддержке поидее, но фантастика конечно
вот на всякий случай демка, визуальная, тоже от 3 лица. dealers-dungeon.com/demo/ она указана в гитхабе сокол АПИ (это большой набор апи - уже почти стек) github.com/floooh/sokol.git
прикольно, успехов вам. А как ходить по террейну и местности вы определились? у художников есть правило идти от общего к частному на всякий случай )
поидее тогда если так то
точно так же и с выводом можно сделать поидее, явно аллоцировать владение строки(но не стараться хранить сразу стринг_вью там даже если покажется, что работает в кадрах будет видно, что где-то будет мусор), чтобы оно жило в своём кадре и отправлять только интерфейс на строку, но при условии, что владение существует
а как же Юникод, это же std::u32string и хэш uint32_t в char* с размером глифа, который отразится в аабб, разве это зоопарк или мы обсуждаем только ASCII? в аски просто стринг, или char строка и инт - кодпойнт, с аабб, по обратной связи вы возможно спросите как управлять такой строкой и текстом.
так ответ и кроется в реализации, если мы рисуем строки и они не изменны никогда, это заведомо текстура, если рисуем текстовый редактор, то пользователь манипулирует строкой через механизм 2д как бы мы этого не хотели, границы окна, границы текстБокса, границы глифа, так это еще учитывая то что у вас никогда не будет строки прямой, там будет сущность буффера даже в С++, изза того, что проще писать хэш во время открытия файла, соотв если это не текстовый редактор, надо реализовать механизм ввода символов через Юникод же, а это текстуры глифов с позициями, и там еще будут нюансы с линейностью, тоесть всё таки это через вектор да, ну тоесть vector-string-size? нет конечно, мы получаем метаданные глифа до отрисовки, в нужной локали, и реализовываем буффер вывода строки
если это 8битные вещи, там уже есть преднастроенные глифы, битмапы же тоже
странно тут как не крути буффер - его реализация будет одна, и она не будет string напрямую, это будут кусочки памяти char* от кодпойнта же
std::u32string. в С uint32_t и char* symbol, хранить строку можно в rope буфере - дереве, потомучто помимо пространства строки есть еще пространство 2д, строка в 2д будет ограничена краями, и задана размером глифа помимо наполнения самого квадрата глифом, а это значит если сцена реализована через дерево, строки, которые находятся в текстБоксе лучше хранить в дереве тоже
а если это текстура(неизменяемый текст), то это не строка а текстура предпосчитанная из строки движком текста
почему так, потомучто рекурсивный обход дерева при рендере частично выраждается в корутину с нюансами, тоесть рендерим квадратики
Скрытый текст
рендер квадратиков, как видим векторов тут нету, вектор просто хранит обьекты, лично я считаю это нюансы нелинейного обхода данных, даже при условии что рендерится от начала до конца
тоесть по моему мнению в высоконагруженных приложениях нельзя просто так взять и
это будет грузить почему-то мне кажется
the_hidden_cost_of_software_libraries_c_vs_rust тут еще есть что-то интересное со сравнениями
а теперь представье, что есть не только Виндовс, но и другие ОС, и там есть всякие флаги, банально какая-то ОС сама собирает компилятор GCC, теперь представьте, что вроде безопасность и прочее, но тут нам говорят, нет чувак юзай Generic или я падаю(хотя Генерик вроде по дефолту, но может есть тут тоже нюансы какие-то, 1 из нюансов, что если настройка екслюзивная компилятора/ров придётся насколько я знаю пересобирать софт, чтобы использовались эти настройки ) ), а там нам показали, например, что либу переписали на скорость и она тянет за собой компилятор, или наоборот, тянем растап, а там узнаёца, что компилятор на локалке не подходит, одинаковый код на опр сборке компиляторов по разному вроде работает, эта ситуация со всей базой внутри как раз и хочет это обходить, вы представляете какой рантайм там
попробуйте блендер собрать сегодня 4.4.0 там тоже есть пайтон, представляете если еще она кланг запросит, гцц, и пайтон, и в конце как финишная сборки раст еще соберёт, это ради того, чтобы заюзать решение блендер ну и допустим решили его скомпилять, как вам конечный дизайн? )
можно конечно пойти по простому пути, не настраивать ничего и пользоваться бинарником
просто раст как замена на бинарнике окей, как только реч идёт о настройках или зависимостях и не дай бог компиляции, собираться с растом на сколько я понимаю будет всё ) может я ошибаюсь конечно )
та же ситуация и с явой, и она поставляется бинарником, мы же не собираем все зависимости или собираем?)
тоесть может оказаться так, что производительность не первична ради поддержки на ОС или оборудовании, а это значит если нету бинарника с нужными настройками, придётся что-то делать если это не учтено, этим и красив С поидее
если до сих пор интересно, в 2д Ortho
тоесть в теории можно избежать вообще обратных матриц
там в лоадере можно пошуршать
соотв можно настроить, там еще при загрузке фрибсд можно посмотреть переменные и примерить размеры консольки
но сама проблема глубже с фреймбуферами, чтобы понять проблему глубже надо задаться вопросом, как рисовать квадратик в окне из пикселей, без драйвера, который в SDL например, в софтверном!(там где нет шейдеров, потомучто Xorg медленный на сколько я знаю) варианте, и более менее пазл встанет на свои места
тоесть надо получить доступ к текущей конфигурации оборудования на уровне ускорения напрямую в граффическую карту, через SHM возможно, другой способ писать свой драйвер KMS, раньше это был DOS int13h наверно
прошу прощения, а если переписать этот механизм на Раст, поидее будет безопаснее отлаживать по step_into наверно
фрагментация даже в расте произойдёт ) самое интересное, нету магии к сожалению, просто раст предлагает аля готовое решение на этапе компиляции ), далее же это для того чтобы положиться на Раст, на его механизм и тут будут теже проблемы как и всегда, перезапись/пересоздание и прочее, что иногда и не только на С/С++ приводит к фрагментации ), тоесть создать убирание утечек, надо было еще оптимизиатор по работе с памятью сделать и выводить на этапе компиляции вы неправильно работаете с памятью тут и тут, надо вот так, почитать можно тут, а так получается проект не собирается потомучто, там посчитались ссылки..., что-то проанализировалось, как бы собираешь, а логические ошибки не аналазируются полностью, и в итоге фрагментация может произойти всё равно, а если оно так, то синтаксис надо стандартизировать, чтобы читать и исправлять было удобно