⚡️Разработчики двоичной системы счисления опровегли слухи о добавления цифры "2"
Пока что конкурирующими являются троичные, восьмиричные, десятеричные и шестнадцатеричные системы счисления
Пока что конкурирующими являются троичные, восьмиричные, десятеричные и шестнадцатеричные системы счисления
💔2❤1💯1
Advanced AVR Templates
Кароче, джентльмены
В перерывах между завариванием чая и компиляции исходников Unreal Engine решил выпустить свой джентельменский набор с шаблонами под всякие железяки для AVR (дисплеи, коммуникация, пины и тд.)
Получилось очень эффективно и оптимизированно - именно тут я раскрыл C++17 (за что его очень люблю <3)
Кароче гляните этот шедевр сами:
https://github.com/RootTool0/Advanced-AVR-Templates
(а еще... там есть кнопочка со звездой.... я конечно не на что не намекаю... но вы поняли)
Кароче, джентльмены
В перерывах между завариванием чая и компиляции исходников Unreal Engine решил выпустить свой джентельменский набор с шаблонами под всякие железяки для AVR (дисплеи, коммуникация, пины и тд.)
Получилось очень эффективно и оптимизированно - именно тут я раскрыл C++17 (за что его очень люблю <3)
Кароче гляните этот шедевр сами:
https://github.com/RootTool0/Advanced-AVR-Templates
(а еще... там есть кнопочка со звездой.... я конечно не на что не намекаю... но вы поняли)
❤2💯1
Portal Solver Editor SDK
Пока в школе абсолютно нечем заняться, решил поразмышлять над дизайном и устройством SDK для Portal: Solver
скажу сразу: эти мысли - лишь простое обсуждение, как пальцем в небо
Чтобы в будущем у нас не было путаницы с SDK для редактора и SDK для игры (а.к.а. моддинг) разделим их так: Portal Solver SDK и Portal Solver Editor SDK
Сегодня обсудим Portal Solver Editor SDK
На эту идею меня очень сильно подтолкнул/вдохновил ролик "This Turns Drawings into Portal 2 Puzzles..." с канала PortalRunner (тык)
Если вкратце - паренек, с помощью Python + OpenCV + Portal 2, написал небольшую программку, которая анализирует нарисованную на бумаге 2D-карту и строит ее в Портале. Все было бы хорошо, да только .bsp формат карт в Портале оказался таким технически тяжелым для кодо-генерации, что финальный результат... Вышел сомнительным. Ничего против не скажу, идея правда амбициозная, но старый-добрый Портал вставил палки в колеса...
И я подумал: А ведь действительно, программирование это не только "Hello, World!" в консоли... Вспомните Minecraft? Garry's Mod? Roblox? Везде, где разработчики давали программный доступ к "кишкам" игры/движку (тот самый SDK) - люди творили просто безумные вещи!
И, конечно, сложив А + Б = Это вдохновило меня на идею разработки SDK для редактора в Portal: Solver
(p.s. я никогда ранее не разрабатывал SDK xD)
Пока в школе абсолютно нечем заняться, решил поразмышлять над дизайном и устройством SDK для Portal: Solver
скажу сразу: эти мысли - лишь простое обсуждение, как пальцем в небо
Чтобы в будущем у нас не было путаницы с SDK для редактора и SDK для игры (а.к.а. моддинг) разделим их так: Portal Solver SDK и Portal Solver Editor SDK
Сегодня обсудим Portal Solver Editor SDK
На эту идею меня очень сильно подтолкнул/вдохновил ролик "This Turns Drawings into Portal 2 Puzzles..." с канала PortalRunner (тык)
Если вкратце - паренек, с помощью Python + OpenCV + Portal 2, написал небольшую программку, которая анализирует нарисованную на бумаге 2D-карту и строит ее в Портале. Все было бы хорошо, да только .bsp формат карт в Портале оказался таким технически тяжелым для кодо-генерации, что финальный результат... Вышел сомнительным. Ничего против не скажу, идея правда амбициозная, но старый-добрый Портал вставил палки в колеса...
И я подумал: А ведь действительно, программирование это не только "Hello, World!" в консоли... Вспомните Minecraft? Garry's Mod? Roblox? Везде, где разработчики давали программный доступ к "кишкам" игры/движку (тот самый SDK) - люди творили просто безумные вещи!
И, конечно, сложив А + Б = Это вдохновило меня на идею разработки SDK для редактора в Portal: Solver
(p.s. я никогда ранее не разрабатывал SDK xD)
YouTube
This Turns Drawings into Portal 2 Puzzles…
Yep, this thing can turn a drawing on paper into a Portal 2 test chamber.
Thanks to dustyhobo for the amazing music, and thank you for watching.
Streamed live on https://twitch.tv/portalrunner
Join our Discord server! https://p2r3.com/discord
Become a channel…
Thanks to dustyhobo for the amazing music, and thank you for watching.
Streamed live on https://twitch.tv/portalrunner
Join our Discord server! https://p2r3.com/discord
Become a channel…
❤1💯1
"UBlueprintFunctionLibrary - это максимально «легкий» класс. Обычный UObject может тащить за собой ненужный функционал"
Также UBlueprintFunctionLibrary который буквально унаследован от UObject и тащит за ним все: 🗿
Также UBlueprintFunctionLibrary который буквально унаследован от UObject и тащит за ним все: 🗿
😎3🔥1
Емать конечно переводчики ломаются на простой живой японской азбуке Хирагана
なつだね！- "Вот и лето, да?", "Лето началось, не так ли?"
Простейшая японская фраза, читается как:
"Natsu Da Ne !"
- Natsu (なつ) - Лето. Обычное японское слово. Оно еще как-то иероглифами записывается, но я не знаю их :(
(шучу, погуглил: 夏)
- Da (だ) - Более неформально-разговорный аналог глагола Desu (です), который можно перевести как "есть" или "быть". Те, кто в инглише, сразу увидят схожесть с "am", "is" или "are" - та же песня (но без родов, лиц и множества, прям красота)
- Ne (ね) - Частица согласия, добавляя в конце хвостик "да?", "правда?", "не так ли?"
И да, не удивляйтесь что глагол в конце - порядок слов у них специфический. В то время как у нас, у европейцев и у американцев, принята схема S-V-O - Субьект-Действие-Обьект, например: Я (субъект) читаю (действие) книгу (объект)
В Японском языке это S-O-V, и глагол всегда стоит в конце, завершая предложение. Например "читаю книгу" - hon o yomu (ほんをよむ): hon (книга, ほん ) o (частица, を) yomu (читаю, よむ)
なつだね！- "Вот и лето, да?", "Лето началось, не так ли?"
Простейшая японская фраза, читается как:
"Natsu Da Ne !"
- Natsu (なつ) - Лето. Обычное японское слово. Оно еще как-то иероглифами записывается, но я не знаю их :(
(шучу, погуглил: 夏)
- Da (だ) - Более неформально-разговорный аналог глагола Desu (です), который можно перевести как "есть" или "быть". Те, кто в инглише, сразу увидят схожесть с "am", "is" или "are" - та же песня (но без родов, лиц и множества, прям красота)
- Ne (ね) - Частица согласия, добавляя в конце хвостик "да?", "правда?", "не так ли?"
И да, не удивляйтесь что глагол в конце - порядок слов у них специфический. В то время как у нас, у европейцев и у американцев, принята схема S-V-O - Субьект-Действие-Обьект, например: Я (субъект) читаю (действие) книгу (объект)
В Японском языке это S-O-V, и глагол всегда стоит в конце, завершая предложение. Например "читаю книгу" - hon o yomu (ほんをよむ): hon (книга, ほん ) o (частица, を) yomu (читаю, よむ)
❤1🤯1
Сегодня, пока сидел на физике (ОГЭ) и ждал лабораторку, пришла интересная мысль:
Есть же в компиляторостроении такая штука как AST - Абстрактно Синтаксическое Дерево. Которая интерпретирует ваш сложный код в простые для компьютера узлы
И я подумал - а сколько этих узлов бывает?
Для лучшего контраста представим что узел - это маленькая, сантиметровая, монетка. Соберем эти монеты вдоль, друг за другом, и что мы получим (цифры подбирал примерные):
- Linux - 1.25 млрд узлов, 12.5 тысячи километров. Практически как расстояние от Москвы до Владивостока, или, высота где заканчивается атмосфера и начинаются орбиты многих искусственных спутников
- Qt6 - 2 млрд узлов, 20 тысяч километров. Почти что длина экватора Земли (40.075 км)
- LLVM/Clang - 2.7 млрд узлов, 27 тысяч километров. Сложите 2 наши Земли вместе - и расстояние между крайними точками (двум диаметрам) будет ~25.5 тысяч километров
- UE5 - 8 млрд узлов... 80 тысяч километров... Четверть расстояния до Луны...
И это все помещается в наш 64-битный компьютер, вот думайте....
P.S. Я взял в расчет ВСЮ кодовую базу проектов, что естественно неверно. Ведь компилятор строит дерево для каждого .cpp файла (единицы трансляции), создает промежуточный файл, и затем удаляет дерево из оперативки. Так-то в одном .cpp файле может быть от силы 100 тысяч узлов, и учитывая размер узла +-64 байта, это дает нам +-6 МБ. Не так уж и много
Есть же в компиляторостроении такая штука как AST - Абстрактно Синтаксическое Дерево. Которая интерпретирует ваш сложный код в простые для компьютера узлы
И я подумал - а сколько этих узлов бывает?
Для лучшего контраста представим что узел - это маленькая, сантиметровая, монетка. Соберем эти монеты вдоль, друг за другом, и что мы получим (цифры подбирал примерные):
- Linux - 1.25 млрд узлов, 12.5 тысячи километров. Практически как расстояние от Москвы до Владивостока, или, высота где заканчивается атмосфера и начинаются орбиты многих искусственных спутников
- Qt6 - 2 млрд узлов, 20 тысяч километров. Почти что длина экватора Земли (40.075 км)
- LLVM/Clang - 2.7 млрд узлов, 27 тысяч километров. Сложите 2 наши Земли вместе - и расстояние между крайними точками (двум диаметрам) будет ~25.5 тысяч километров
- UE5 - 8 млрд узлов... 80 тысяч километров... Четверть расстояния до Луны...
И это все помещается в наш 64-битный компьютер, вот думайте....
P.S. Я взял в расчет ВСЮ кодовую базу проектов, что естественно неверно. Ведь компилятор строит дерево для каждого .cpp файла (единицы трансляции), создает промежуточный файл, и затем удаляет дерево из оперативки. Так-то в одном .cpp файле может быть от силы 100 тысяч узлов, и учитывая размер узла +-64 байта, это дает нам +-6 МБ. Не так уж и много
❤1🔥1
Ничего не обычного, просто 19 способ инициализировать переменную в C++
it's simple
UPD: Кому интересно почитать: тык
it's simple
UPD: Кому интересно почитать: тык
😎1
Примеры работы с PSE SDK
Завершая и замораживая Portal Solver Editor SDK, не могу не поделиться первыми примерами работы с ним
Объясню кратко каждый шаг:
1) Создаем команду на создание элемента, и выбираем ему класс "дверь"
2) Каждый элемент имеет по 8 32-битных регистров для данных. Их спецификация расписана в PSE > Concept > Elements. В данном случае в регистре "1" находится цвет двери при активации. Туда мы записываем красный цвет
3) И затем отправляем команду чтобы установиться State = 1. Что такое State? Главная нить судьбы, связующая между элементами. Например я нажал на кнопку -> кнопка сгенерировала событие с State = 1 -> Дверь приняла этот State и открылась. Все просто. И хоть State является 8 битным числом, большинство элементов интерпретируют свою активацию при State не равном нулю, то есть, та же условная дверь откроется при State != 0
В посте также прикреплю вырезки из спецификации SDK (в которой большинство вещей уже прописаны мною)
На этом все я думаю? Не знаю, держите v flower на удачу
Завершая и замораживая Portal Solver Editor SDK, не могу не поделиться первыми примерами работы с ним
Объясню кратко каждый шаг:
1) Создаем команду на создание элемента, и выбираем ему класс "дверь"
2) Каждый элемент имеет по 8 32-битных регистров для данных. Их спецификация расписана в PSE > Concept > Elements. В данном случае в регистре "1" находится цвет двери при активации. Туда мы записываем красный цвет
3) И затем отправляем команду чтобы установиться State = 1. Что такое State? Главная нить судьбы, связующая между элементами. Например я нажал на кнопку -> кнопка сгенерировала событие с State = 1 -> Дверь приняла этот State и открылась. Все просто. И хоть State является 8 битным числом, большинство элементов интерпретируют свою активацию при State не равном нулю, то есть, та же условная дверь откроется при State != 0
В посте также прикреплю вырезки из спецификации SDK (в которой большинство вещей уже прописаны мною)
На этом все я думаю? Не знаю, держите v flower на удачу
💘4