А как у вас ЭМВ превратился в ГВ? Для ГВ наскольько мне известно нужна масса, которая бы оказывала рябь пространства. Но в безмассовой системе откуда взяться ГВ?
Как говорил выше - подготовка единого рендерпаса получается дешевле по ресурсам и универсальнее в плане поддержки, чем рисование на нативных контролах. Ну и разработка изначально была не на Windows и не под Windows. Держать по разрабу на платформу ко всему получается довольно затратным мероприятием - все же люди хотят, чтобы редактор вел себя хорошо, а для того чтобы сделать платформеннозависимое хорошо нужно где-то иметь соответствующего разраба, который шарит за нюансы платформы - дорого и медленно.
Альтернатива номер раз - написать абстрактный слой который объединит несколько платформ потеряв где-нибудь в фичах - это путь gtk/qt. Биндинги на раст к ним имеются, но чуваки старались не иметь подобных жирных зависимостей да и писать под qt/gtk сомнительное удовольствие с учётом модели заимствований - тоже получается медленно, дорого и больно.
Вариант третий - сделать свою отрисовку и библиотеку компонентов и страдать только от радиуса собственных рук. Этим путём и пошли. Благо весь низкий уровень уже изобрели.
Компонента не работает, пока не обновится, остальное продолжает работать. Работать можно, но какой-то функционал отваливается. У меня дебаггер так отвалился, по ссылке в issue с отвалом LSP там видимо что-то ещё отваливалось, но тут сильно зависит от возможностей LSP сервера языка - вероятнее всего какая-нибудь продвинутая навигация по коду и рефакторинг ломаются.
GPU-рисование внедряют по одной причине - чтобы этот же код можно было использовать на всяких Линуксах и Маках
Совершенно точно не по одной причине и точно эта не является главной. Zed изначально появлялся на Mac OS и уже позднее его слегка допилили, чтобы завелось на Linux и с большей болью - чтобы завести на Windows. Кроссплатформенный универсальный рендеринг под все графические API решили относительно недавно с появлением WGPU. До этого практически единственным кто использовал GPU рендеринг для текста был alacritty со своим собственным бэкендом. Так что "кроссплатформенность" очень слабый аргумент в пользу рисования именно на GPU - вы видимо не пробовали делать игры под все платформы.
Electron же стал развитием идеи node js о единой кодовой базе на JS для фронта и для бэка. Только к списку добавился ещё и "нативные" приложения. Бенефиты понятны - браузеры уже перенесены на все платаформы и JS достаточно агностик для написания последних. GPU рисование тут совершенно не причём.
Работает, но у них там какая-то система обновления компонентов чрезжопная в итоге периодически когда компонент получает релиз, то zed пытается его скачать со странички релизов на github. Оно вроде даже скачивает, но что-то дальше шло не так и обновленный компонент не накатывался. С чем конкретно это связано я не понял, но как-то связанно с доступностью github. Может хэши сверять пытались и по таймауту отвал случался или что-то ещё, но это требовало нормального соединения с gh. Из подверженных компонентов были собственно наборы LSP и lldb дебаггер. Пока компонент не обновлён - установленная версия компонента не используется и не работает, то бишь нет нормального фолбэка к старой версии. Про что собственно вышеуказанная issue.
Таким образом выйду на свой первый рабочий день и увижу C++03, C++Builder
Это довольно сказочный кейс - устроиться на работу так и не узнав про рабочий стек. Не представляю как так можно устроиться на работу и узнать о том что у них C++ Builder в первый рабочий день, а не на техническом собеседовании. Особенно после рассказа о том как используют новые стандарты. Я бы вообще советовал бежать от такой кампании, если такое действительно случилось.
Увижу что все пользуются своей имплементацией std::string, std::unique_ptr
Для этого существует такое явление как онбординг. Никто в здравом уме не кидает новых сотрудников в кодовую базу без документации или временного ментора по проекту, которому можно было бы задать вопросов.
бенчмарк между подходом с ranged/views и самым обычным проходом
ну если вы джуном пойдёте, то наверное за бенчмарки вам расскажут. Если вы побородатее, то кажется написать простейший бенчмарк через дельту std::chrono::now() не сложно. Ну или хотя бы на том же godbolt подсмотреть, как они их гоняют, а то и прямо с него примеров показать. Не очень понятно что вы хотели этим сказать.
разобраться хотя бы что такое bss
а как информация о бинарных секциях поможет человеку с разработкой? туда же вопрос про переизобертение какого-нибудь visitor / flyweight / fabric / etc из книжки про паттерны без использования концептов/шаблонов.
А может ли быть такое что std::unordered_map сделана через одно место и будет куча коллизий с пустого места? А какие контейнеры сделаны дедами в pbds?
это вообще странный йвопрос - как можно изучать язык и не изучать стандартную библиотеку? понятно, что нюансов там найдётся немало, но тут сильно зависит от уровня программиста. Странно было бы выкатывать зелёному разрабу претензию про то что он чего-то не знает/не учёл. Ну и в условный HFT с таким уровнем знаний нюансов всё равно не взяли бы, так что о чём бугурт?
Не очень понятно почему они решили бампануть 1.0 когда у них так и не завёлся оффлайн режим нормально. Буквально вчера столкнулся с этой проблемой из-за того что github чихал из-за очередного вайбкоженного бага.
Маркет экстеншенов маленький.
пока не очень понятно, а что вообще нужно кроме того что уже зашито в редактор из коробки? Языковые фичи для большинства языков уже поддержаны благодаря tree-sitter. Не сталкивался с какими-либо проблемами из-за отсутвия чего-либо. В моём окружении - Rust, C, C++, CMake, Docker. Все фичи целиком и полностью поддерживаются на уровне LSP, так что проблемы Java скорее всего в малом количестве контрибутеров в их lsp. Хотя конечно intellij умеют шороху навести в их специальные редакторы.
Часть сценариев remote-разработки пока проигрывает удобству VS Code Remote.
Учитывая, что оный так и не научился работать на BSD системах не могу сказать, что он в принципе интересный эталон в данном контексе. Коллаборации и прочие фичи zed аккаунтов не пробовал, так что сравнить пока не могу.
В остальном - vim mode в редакторе несколько странно работает и пока вроде не позволяет полноценно жить без мыши. А так уже больше полугода и работается с ним на порядок приятнее чем с vscode/codium. Даже встреченные баги чинятся достаточно оперативно. Ну и совместимость json с vs code довольно большая, так что с большой вероятностью .vscode можно просто залинковать на .zed и получить похожее окружение как и в vscode.
Потому что большинству редакторов не под силу отрисовать какие-нибудь диграфы стрелочек или эмоджики из векторного шрифта и не скушать много много процессорного времени. Особенно на Windows. Простенький оптимизированный рендерпасс в этом плане не страдает от подобных проблем и даже какая-нибудь прокрутка текста не заставляет окно редактора заикаться, даже если рендеринг всё равно улетает на процессор. Можно найти старое видео от Кейси Муратори, где он там на коленке собирает простейший терминал который нормально работает с произвольным utf, цветами и эффектами (волна, мигать. переливаться и пр) и выводит гигабайт текста на экран за пару секунд, в то время как вывод того же текста в дефолтном cmd улетает за несколько минут. И это БЕЗ каких-либо эффектов. А казалось бы куда уж проще - сиди рисуй текст.
Как-то так GPU рендеринг экономит и время и ресурсы и ещё и бонусов сверху накидывает.
Похоже на то как работают query из Bevy. Но в таком виде это использовать нереально - в репозитории дикий бардак.
Папка сборки должна быть в игноре и никакие артефакты не нужно класть в неё. Разве что в релизы отправлять.
если вы хотели сделать библиотеку, то надо было разделить публичные хэдеры, которые соскладировать в общую папку include и приватную имплементацию распихать по cpp файлам.
папку с исходниками обычно называют source или src, но никак не engine. В итоге структура должна выглядеть как-то так
есть некоторый inl файл с кучкой шаблонов на который никто не ссылается. по крайней мере никто из текстовых файлов
вы хотите это сделать библиотекой или просто показываете? если библиотека, то нужно какую-нибудь лицензию указать. Что-нибудь из пермиссивных желательно - apache 2.0, mit, zlib, bsd 3 clause, например. Ну или GPL если хочется чтобы все пользователи вашей библиотеки шарили код своих игр.
Отдельно предложил бы написать cmake файл и генерировать проект для VS на его основе - заодно и кроссплатформенность появится и можно будет выпилить из репозитория все эти vcxproject и sln в корне. Можно посмотреть как оформлятют библиотеки например в beman project
Ну кстати там довольно интересные правила от федеральных регулторов по поводу лётных зон. После пары прецедентов там ещё и определения воздушного пространства частной собственности появилось.
Про criterion я знаю, но он добавит свою "обвязку", просто хотелось оставить "минимальный" ассемблер.
На производительность влияет не только эффективность ассемблера, но и "фазы луны" - температура процессора, прогрев кэшей, работа соседних процессов и т.п. В этом плане criterion позволяет все это дело митигировать и собирать чуть более честную статистику. Ну и если делать именно бенчмарки для запуска cargo bench, а не самому крафтить всю эту инфраструктуру, то код для расчёта не будет мешать коду бенчмарков. То бишь ассемблер будет чище.
Это флаг компилятора. Обычно либо скармливается с флагом -C в rustc либо указывается в toml в качестве дополнительных флагов либо через RUSTFLAGS как в комментарии в закрепе. По сути это избавляет вас от ручного выбора нужного процессора и его фич при оптимизации. Так что если без старых флагов, но с target=native получились примерно те же цифры, то поздравляю - флаг заработал как надо.
А для бенчмарков у Rust есть довольно приятный набор инструментов. Хоть бы тот же criterion попользовали, а то всё ручками да ручками, ещё и статистика небось неравномерная получается.
Ещё б в эмуляторе как в PICO-8 сделали бы загрузку произвольного картриджа. Ну и/или режим редактора хотя бы, чтобы примеры можно было запускать не отходя от браузера.
В ролике про деформации (самая первая ссылка на вквидео) на открытой модели для сборки там отдельным пунктом это зачем-то выделили. Понятно, что для подтверждения трансформаций нужно жать кнопку сохранения на действии. Но в чем соль ещё и файл ручками пересохранять после этого я тогда так и не понял.
Про это не знали, учтём...
если поправить ссылки с vk.com на vkvideo.ru то клипы становятся доступны для просмотра без регистрации. Правда не уверен что это ровно те же клипы. Хотя что там можно рассмотреть в таком формате, когда пол экрана закрывает текстом...
А как у вас ЭМВ превратился в ГВ? Для ГВ наскольько мне известно нужна масса, которая бы оказывала рябь пространства. Но в безмассовой системе откуда взяться ГВ?
то есть инфоцыгане для маркетологов. кто бы мог подумать
Как говорил выше - подготовка единого рендерпаса получается дешевле по ресурсам и универсальнее в плане поддержки, чем рисование на нативных контролах. Ну и разработка изначально была не на Windows и не под Windows. Держать по разрабу на платформу ко всему получается довольно затратным мероприятием - все же люди хотят, чтобы редактор вел себя хорошо, а для того чтобы сделать платформеннозависимое хорошо нужно где-то иметь соответствующего разраба, который шарит за нюансы платформы - дорого и медленно.
Альтернатива номер раз - написать абстрактный слой который объединит несколько платформ потеряв где-нибудь в фичах - это путь gtk/qt. Биндинги на раст к ним имеются, но чуваки старались не иметь подобных жирных зависимостей да и писать под qt/gtk сомнительное удовольствие с учётом модели заимствований - тоже получается медленно, дорого и больно.
Вариант третий - сделать свою отрисовку и библиотеку компонентов и страдать только от радиуса собственных рук. Этим путём и пошли. Благо весь низкий уровень уже изобрели.
Компонента не работает, пока не обновится, остальное продолжает работать. Работать можно, но какой-то функционал отваливается. У меня дебаггер так отвалился, по ссылке в issue с отвалом LSP там видимо что-то ещё отваливалось, но тут сильно зависит от возможностей LSP сервера языка - вероятнее всего какая-нибудь продвинутая навигация по коду и рефакторинг ломаются.
Совершенно точно не по одной причине и точно эта не является главной. Zed изначально появлялся на Mac OS и уже позднее его слегка допилили, чтобы завелось на Linux и с большей болью - чтобы завести на Windows. Кроссплатформенный универсальный рендеринг под все графические API решили относительно недавно с появлением WGPU. До этого практически единственным кто использовал GPU рендеринг для текста был alacritty со своим собственным бэкендом. Так что "кроссплатформенность" очень слабый аргумент в пользу рисования именно на GPU - вы видимо не пробовали делать игры под все платформы.
Electron же стал развитием идеи node js о единой кодовой базе на JS для фронта и для бэка. Только к списку добавился ещё и "нативные" приложения. Бенефиты понятны - браузеры уже перенесены на все платаформы и JS достаточно агностик для написания последних. GPU рисование тут совершенно не причём.
Работает, но у них там какая-то система обновления компонентов чрезжопная в итоге периодически когда компонент получает релиз, то zed пытается его скачать со странички релизов на github. Оно вроде даже скачивает, но что-то дальше шло не так и обновленный компонент не накатывался. С чем конкретно это связано я не понял, но как-то связанно с доступностью github. Может хэши сверять пытались и по таймауту отвал случался или что-то ещё, но это требовало нормального соединения с gh. Из подверженных компонентов были собственно наборы LSP и lldb дебаггер. Пока компонент не обновлён - установленная версия компонента не используется и не работает, то бишь нет нормального фолбэка к старой версии. Про что собственно вышеуказанная issue.
@antoshkkaа не подкините годной литературы людям, которые хотят писать нормальный современный код?
Это довольно сказочный кейс - устроиться на работу так и не узнав про рабочий стек. Не представляю как так можно устроиться на работу и узнать о том что у них C++ Builder в первый рабочий день, а не на техническом собеседовании. Особенно после рассказа о том как используют новые стандарты. Я бы вообще советовал бежать от такой кампании, если такое действительно случилось.
Для этого существует такое явление как онбординг. Никто в здравом уме не кидает новых сотрудников в кодовую базу без документации или временного ментора по проекту, которому можно было бы задать вопросов.
ну если вы джуном пойдёте, то наверное за бенчмарки вам расскажут. Если вы побородатее, то кажется написать простейший бенчмарк через дельту std::chrono::now() не сложно. Ну или хотя бы на том же godbolt подсмотреть, как они их гоняют, а то и прямо с него примеров показать. Не очень понятно что вы хотели этим сказать.
а как информация о бинарных секциях поможет человеку с разработкой? туда же вопрос про переизобертение какого-нибудь visitor / flyweight / fabric / etc из книжки про паттерны без использования концептов/шаблонов.
это вообще странный йвопрос - как можно изучать язык и не изучать стандартную библиотеку? понятно, что нюансов там найдётся немало, но тут сильно зависит от уровня программиста. Странно было бы выкатывать зелёному разрабу претензию про то что он чего-то не знает/не учёл. Ну и в условный HFT с таким уровнем знаний нюансов всё равно не взяли бы, так что о чём бугурт?
Не очень понятно почему они решили бампануть 1.0 когда у них так и не завёлся оффлайн режим нормально. Буквально вчера столкнулся с этой проблемой из-за того что github чихал из-за очередного вайбкоженного бага.
пока не очень понятно, а что вообще нужно кроме того что уже зашито в редактор из коробки? Языковые фичи для большинства языков уже поддержаны благодаря tree-sitter. Не сталкивался с какими-либо проблемами из-за отсутвия чего-либо. В моём окружении - Rust, C, C++, CMake, Docker. Все фичи целиком и полностью поддерживаются на уровне LSP, так что проблемы Java скорее всего в малом количестве контрибутеров в их lsp. Хотя конечно intellij умеют шороху навести в их специальные редакторы.
Учитывая, что оный так и не научился работать на BSD системах не могу сказать, что он в принципе интересный эталон в данном контексе. Коллаборации и прочие фичи zed аккаунтов не пробовал, так что сравнить пока не могу.
В остальном - vim mode в редакторе несколько странно работает и пока вроде не позволяет полноценно жить без мыши. А так уже больше полугода и работается с ним на порядок приятнее чем с vscode/codium. Даже встреченные баги чинятся достаточно оперативно. Ну и совместимость json с vs code довольно большая, так что с большой вероятностью .vscode можно просто залинковать на .zed и получить похожее окружение как и в vscode.
Потому что большинству редакторов не под силу отрисовать какие-нибудь диграфы стрелочек или эмоджики из векторного шрифта и не скушать много много процессорного времени. Особенно на Windows. Простенький оптимизированный рендерпасс в этом плане не страдает от подобных проблем и даже какая-нибудь прокрутка текста не заставляет окно редактора заикаться, даже если рендеринг всё равно улетает на процессор. Можно найти старое видео от Кейси Муратори, где он там на коленке собирает простейший терминал который нормально работает с произвольным utf, цветами и эффектами (волна, мигать. переливаться и пр) и выводит гигабайт текста на экран за пару секунд, в то время как вывод того же текста в дефолтном cmd улетает за несколько минут. И это БЕЗ каких-либо эффектов. А казалось бы куда уж проще - сиди рисуй текст.
Как-то так GPU рендеринг экономит и время и ресурсы и ещё и бонусов сверху накидывает.
Похоже на то как работают query из Bevy. Но в таком виде это использовать нереально - в репозитории дикий бардак.
Папка сборки должна быть в игноре и никакие артефакты не нужно класть в неё. Разве что в релизы отправлять.
если вы хотели сделать библиотеку, то надо было разделить публичные хэдеры, которые соскладировать в общую папку include и приватную имплементацию распихать по cpp файлам.
папку с исходниками обычно называют source или src, но никак не engine. В итоге структура должна выглядеть как-то так
есть некоторый inl файл с кучкой шаблонов на который никто не ссылается. по крайней мере никто из текстовых файлов
вы хотите это сделать библиотекой или просто показываете? если библиотека, то нужно какую-нибудь лицензию указать. Что-нибудь из пермиссивных желательно - apache 2.0, mit, zlib, bsd 3 clause, например. Ну или GPL если хочется чтобы все пользователи вашей библиотеки шарили код своих игр.
Отдельно предложил бы написать cmake файл и генерировать проект для VS на его основе - заодно и кроссплатформенность появится и можно будет выпилить из репозитория все эти vcxproject и sln в корне. Можно посмотреть как оформлятют библиотеки например в beman project
лет через 10
То есть размеры города в размер европейской части вас устраивают?
Ну кстати там довольно интересные правила от федеральных регулторов по поводу лётных зон. После пары прецедентов там ещё и определения воздушного пространства частной собственности появилось.
На производительность влияет не только эффективность ассемблера, но и "фазы луны" - температура процессора, прогрев кэшей, работа соседних процессов и т.п. В этом плане criterion позволяет все это дело митигировать и собирать чуть более честную статистику. Ну и если делать именно бенчмарки для запуска cargo bench, а не самому крафтить всю эту инфраструктуру, то код для расчёта не будет мешать коду бенчмарков. То бишь ассемблер будет чище.
Это флаг компилятора. Обычно либо скармливается с флагом -C в rustc либо указывается в toml в качестве дополнительных флагов либо через RUSTFLAGS как в комментарии в закрепе. По сути это избавляет вас от ручного выбора нужного процессора и его фич при оптимизации. Так что если без старых флагов, но с target=native получились примерно те же цифры, то поздравляю - флаг заработал как надо.
А для бенчмарков у Rust есть довольно приятный набор инструментов. Хоть бы тот же criterion попользовали, а то всё ручками да ручками, ещё и статистика небось неравномерная получается.
Ещё б в эмуляторе как в PICO-8 сделали бы загрузку произвольного картриджа. Ну и/или режим редактора хотя бы, чтобы примеры можно было запускать не отходя от браузера.
вроде завелось
Раз уж вы стали разбирать нативные оптимизации под конкретный процессоh, то почему бы не прокинуть заодно
target-cpu=native, чтоб llvm сам всё сделалВ ролике про деформации (самая первая ссылка на вквидео) на открытой модели для сборки там отдельным пунктом это зачем-то выделили. Понятно, что для подтверждения трансформаций нужно жать кнопку сохранения на действии. Но в чем соль ещё и файл ручками пересохранять после этого я тогда так и не понял.
если поправить ссылки с vk.com на vkvideo.ru то клипы становятся доступны для просмотра без регистрации. Правда не уверен что это ровно те же клипы. Хотя что там можно рассмотреть в таком формате, когда пол экрана закрывает текстом...
https://vk.com/clip-29994774_456252849 -> https://vkvideo.ru/clip-29994774_456252849