Программист
Всем привет, сегодня я расскажу про верстку в SwiftUI с помощью AlignmentGuide.
AlignmentGuide позволяет сделать специальное выравнивание внутри View. А точнее сказать, инструмент позволяет строить направляющие для выравнивания в контейнерных типах View (HStack, VStack, ZStack) между родителем и его потомками.
В этой статье будут встречаться термины, которые я намеренно не перевожу из-за того, что перевод либо звучит ужасно, либо не отражает сути термина.
В быстро развивающемся мире и генеративных моделей появляются всё новые и новые модальности. После текста, изображений, звуков и музыки, настала очередь 3D моделей. Представьте себе систему, способную за считанные секунды создавать огромные, тщательно детализированные 3D-миры, будь то целые города или микроскопические структуры. Проблема в том, что существующие модели часто не справляются с задачей обеспечения баланса между разрешением, эффективностью и масштабируемостью, особенно в крупномасштабных решениях.
Сегодня я хочу рассказать вам про XCube - новый подход от Nvidia к генеративному 3D, в котором для преодоления этих ограничений используются подход Sparse Voxel Hierarchies. В отличие от традиционных моделей, XCube легко масштабируется от отдельных объектов до обширных открытых сцен, достигая уровня детализации с разрешением до 
вокселей - и при этом сохраняя эффективность вычислений. Этот метод не только повышает геометрическую сложность создаваемых моделей, но и поддерживает редактирование пользователем и универсальную генерацию атрибутов.
В 2019 году я ступил на путь разработки электроники. Моим первым устройством является Орнамент-8. Не судите строго.
- Орнамент-8 это устройство, способное реализовывать сложные конечные автоматы.
- Переход конечного автомата из одного состояния в другое определяется патчем, соединением входов и выходов ячеек Орнамента.
- Каждая из 8 ячеек Орнамента представляет собой моновибратор.
- Если моновибратор запустить, он будет удерживать высокое состояние в течение периода времени, задаваемого потенциометром TIME.
- В момент перехода моновибратора (далее ячейка) из высокого состояния в низкое происходит генерация триггера.
- Этот триггер способен запустить любую другую ячейку Орнамента, кроме самой себя. Для этого необходимо соединить тригерный выход с тригерным входом.
- Если триггер приходит на вход уже активной ячейки, он не поглощается, а поступает на тригерный выход PASS>. Этот выход реализует логику: если ячейка активна -> пусть триггер активирует другие ячейки.
- Помимо тригерных входов и выходов каждая ячейка имеет аналоговый выход, сигнал на котором пропорционален времени активации ячейки от 0 до 1 в зависимости от параметра TIME. Если моновибратор сравнить с наполняющимся сосудом, то аналоговый выход (CV>) показывает уровень жидкости в этом сосуде.
- Каждая ячейка имеет вход для управляющего напряжения (>CV). Приложенное к этому входу напряжение управляет коэффициентом, увеличивающим значение параметра TIME установленного потенциоментром. Приложение управляющего напряжения к >CV можно представить как растяжение времени в системе координат ячейки.
Кажется, что Орнамент-8 это какой-то странный артефакт, упавший из космоса. Зачем он нужен? Что с ним делать? Кто и почему придумал такую странную систему правил?
В этой статье я хочу показать, как цепочка маленьких и оправданных дизайн-решений может привести к созданию устройства, которое открыло совершенно новую парадигму для создания секвенций.
Привет, Хабр! Меня зовут Николай, я разработчик С++ в SimbirSoft. В предыдущей статье мы с вами рассмотрели применение стандартных алгоритмов в повседневном коде и их преимущества над обычными циклами. В продолжение этой темы мне хотелось бы рассказать о недостатках стандартных алгоритмов и способах их решения с помощью библиотеки Ranges. Практические примеры я разбил на три части: в первой показаны обычные циклы, во второй — вариант написания с помощью алгоритмов (но не всегда можно это сделать), в третьей – с использованием Ranges. Этот материал будет полезен тем разработчикам, которые хотят применять новые стандарты и подходы у себя на проектах.
Так прошло три дня. В комнате темно и холодно, но мониторы слепят. Ты дезориентирован настолько, как будто тебя кидает из одного диссоциативного эпизода в другой. Тебя то и дело пробивает нервный смех, хотя смеяться нечему. Как я здесь оказался? В чём моя вина?
Главная ошибка была в том, что ты в это вообще ввязался — в этом никаких сомнений.
Ещё когда я впервые взялся проходить курс по C++ несколько лет назад, меня учили, что, если я не предоставлю собственного конструктора, то компилятор сам подберёт ему замену — своего рода конструкторы, действующие по умолчанию. Я решил подробнее в этом разобраться, особенно меня волновали случаи, которые выглядят примерно так:
Материал подготовлен на основе выступления с CppCon 2015 "Greg Law: Give me 15 minutes & I'll change your view of GDB" (доступно по ссылке ). Многие моменты я изменял и корректировал, поэтому учтите, что перевод достаточно вольный.
И да, вынесем за скобки вопрос о том, насколько GDB в целом удобная или неудобная программа, и что в принципе лучше использовать для дебаггинга: в данной статье будет рассматриваться именно работа с GDB.
В статье будет рассматриваться отладка кода на C в ОС Linux.
«Твой двадцатый день рождения
отмечал я в Картахене;
двадцать душ зажёг как свечи
доброй порцией картечи!»
Андрей Корф, «Порт-Ройял».
Наткнулся недавно на книгу "1100 words you Need to Know" by Murray Bromberg and Melvin Gordon" (для уровня C1-C2). Она легко гуглится в Яндексе.
Данную книгу упоминали уже здесь, на Хабре, как хороший способ изучения новых слов. Я напишу еще немного.
В августе этого года, после полутора лет напряженной работы, наконец-то вышла наша третья книга (про первую и вторую уже были посты на Хабре) ориентированная на разработку игр: 3D Graphics Rendering Cookbook: A comprehensive guide to exploring rendering algorithms in modern OpenGL and Vulkan.
Прим. переводчика: в данной статье обсуждается общий подход к выбору вопросов для собеседований на позицию программиста компьютерной графики на примерах конкретных вопросов.
Недавно я видел в твиттере довольно много дискуссий о хороших и плохих вопросах на интервью. Некоторые из этих вопросов выглядят полезными.
В основном, наиболее интересные из них выглядят открытыми. Они могут привести к весьма большим и разветвленным обсуждениям или даже не имеют «верного» ответа. В конце концов, вам, скорее, нужно не узнать ответ (он всё равно будет 42), а увидеть процесс решения проблемы и/или оценить общие знания и понять собеседуемого.
Ниже я приведу примеры, которые я использовал несколько раз, и они ориентированы на программистов графики с некоторым количеством опыта.
Так, я наиграл в Fire Emblem: Three Houses уже порядка 160 часов в течение последней пары недель, думаю пришло время вновь побыть интернет-экспертом.
Тема, по которой я планировал сделать пост еще очень давно, это синхронизация в Vulkan'е. У многих, изучающих этот API, этот топик вызывает наибольшие трудности, и в этой статье я хотел бы сформировать у читателя ментальную модель, а не просто пересказать техническую спецификацию. Не смотря на кажущуюся неимоверную сложность, синхронизация в Vulkan' е вполне понятна и логична, если преодолеть начальные трудности.
С момента релиза War Robots прошло уже более 7 лет. В 2014 году мобильный игровой рынок был гораздо скромнее, чем сейчас, а девайсов, которые могли без проблем тянуть трехмерную игровую графику, — и того меньше. Несмотря на то, что уже случилась шейдерная «революция», и на замену графического конвейера с фиксированным функционалом (fixed-function pipeline) пришли вершинные и фрагментные шейдеры, возможностей для создания качественной картинки уровня настольного компьютера было явно недостаточно.
На старте разработки оригинальной игры фактически единственным среди графических API на мобильных платформах (Android, iOS) был OpenGL ES 2.0. Результат его эволюционного развития, OpenGL ES 3.0, был только-только утвержден, и на рынке даже не было устройств, которые бы его поддерживали. Таким образом, графика в Walking War Robots была основана на технологиях и возможностях, предоставляемых именно OpenGL ES 2.0.
У War Robots тех времен был вполне себе типичный графический стек, поддерживающий один направленный источник света и способный рассчитать от него затенение с учетом весьма простой системы материалов. Со временем графика в игре улучшалась и совершенствовалась, но довольно быстро ее развитие стало упираться ограничения OpenGL ES 2.0. Наступил момент, когда потенциал эволюционного развития был достигнут, и без комплексного революционного подхода рывок в графике уже не представлялся возможным. В тот момент мы и приняли решение, что игре нужен ремастер.
Всем привет. Меня зовут Ширшов Владимир и я техлид проекта King's Bounty 2. Игра разрабатывается на движке Unreal Engine 4.
King's Bounty 2 - это игра с открытым миром, в котором есть города, поселения, наполненные персонажами, интерактивными объектами и зонами сражений. Персонаж может перемещаться по миру как пешком, так и верхом. Все элементы открытого мира должны помещаться в память, удовлетворять требованиям по производительности и успевать загружаться на всех целевых платформах (PlayStation 4, XBox One, Nintendo Switch), чтобы вокруг игрока всегда были персонажи и детализированные объекты.
Я хочу поделиться опытом использования системы стриминга уровней в Unreal Engine 4 World Composition для создания открытого мира и рассказать об ее плюсах и минусах. Также расскажу о тех изменениях, которые нам потребовалось внести в нее для того, чтобы игра помещалось в память целевых платформ, и уровни успевали загружаться при перемещении игрока по локации.
Одна из самых простых и базовых концепций в программировании игр — это идея игрового цикла. При запуске вашего проекта происходит его инициализация, после чего игровой цикл действует до тех пор, пока игрок хочет продолжать игру: каждый кадр вы обрабатываете ввод, обновляете состояние игрового мира и выводите результат на экран. Когда игрок закрывает игру, происходит очистка данных, и на этом все заканчивается.
Но когда вы пишете игровой код на Unreal Engine, вы не имеете дело с игровым циклом напрямую. Вы не начинаете работать сразу с основной функцией — сначала вы определяете подкласс GameMode и переопределяете функцию под названием InitGame. Или пишете одноразовые классы Actor и Component и переопределяете их функции BeginPlay или Tick для добавления собственной логики. Это самый минимум того, что вам нужно сделать: обо всем остальном движок позаботится за вас.
Unreal Engine также предлагает вам как программисту мощный и гибкий инструментарий: конечно, он имеет открытый исходный код, но также возможно и расширение несколькими другими способами. Даже если вы только начинаете работать с этим движком, было бы не лишним получить представление о его GameFramework: о таких классах, как GameMode, GameState, PlayerController, Pawn и PlayerState.
И один из лучших способов ближе познакомиться с движком — это заглянуть в его исходный код и посмотреть на то, как он загружает вашу игру.
Только самый-самый ленивый человек не написал о том, как искать работу на удаленке. Большинство советов про то, как откликнуться, пройти собеседование и так далее. Меня интересует другое — где вообще удобно искать вакансии. Составил свой рейтинг, протестировав 10 самых известных агрегаторов.
