C# *

Если вы недавно обновились до Unity 6 (или URP 17+) и попытались перенести свои старые пост-эффекты, то наверняка столкнулись с красной консолью и предупреждениями об устаревших методах.

Старые туториалы по созданию эффекта обводки (Outline) через ScriptableRendererFeature больше не работают "из коробки". Unity полностью изменила архитектуру рендера, внедрив Render Graph. Старый добрый метод Execute канул в Лету, а fullscreenMesh заменили на Blitter.

В этой статье мы не просто перепишем классический эффект Outline под новые реалии Unity 6. Мы решим две главные проблемы подобных шейдеров, о которых часто умалчивают в гайдах.

CoreBus — кроссплатформенный терминал для работы с COM-портами и TCP-сокетами с поддержкой протоколов Modbus TCP / RTU / ASCII и много чего еще.

Приложение развивается уже довольно давно. Но была одна фича, которой не хватало, чтобы сделать CoreBus по-настоящему универсальным терминалом. Мне об этом писали еще с первых релизов. В личных сообщениях и в комментариях к статьям. Эта идея формулировалась по-разному, но суть была одна.

И поэтому хочу представить вам новый режим - "Modbus мониторинг"!

Когда мы говорим о генерации ландшафтов в компьютерных играх или симуляторах, перед разработчиком всегда встает вопрос: хранить огромные карты высот на диске или генерировать их на лету? Хранение готовых текстур требует места, а их загрузка - времени и пропускной способности памяти. Процедурная генерация решает эту проблему, позволяя создавать уникальные, детализированные и невероятно большие миры, имея в распоряжении лишь математические формулы и несколько входных параметров он же сид.

Однако генерация сложных ландшафтов на CPU может стать узким местом, особенно когда речь идет о streaming-мирах или динамическом разрушении окружения. На помощь приходит вычислительная мощь графического процессора. Используя Compute Shaders, мы можем перенести тяжелые математические расчеты на тысячи ядер видеокарты, получая готовую карту высот или же heightmap за доли миллисекунд. В этой статье мы разберем, как устроены процедурные текстуры, почему GPU идеален для этой задачи, и напишем собственный генератор местности с эрозией на HLSL.

Дали мне недавно задачу написать тесты для одной CLI-тулзы. Это мне уже привычно и понимание, зачем тулза нужна, есть. Я только не знал, что меня ждёт в коде. Программист, писавший её, сделал гигантскую работу — претензий нет (не обижайся, пожалуйста, если читаешь это, но это стоит отдельной статьи). Там суммарно, наверно, порядка 30к строк кода написано. Нюанс в том, что, видимо, он раньше не писал на C#,

Так что тут я соберу для вас примеры, как нельзя писать и как стоит.

Привет, Хабр. Я — Андрей Макар-Уваров, Head of Frontend в Surf. Недавно решил проверить одну гипотезу: насколько далеко можно уехать на ИИ в разработке, если взять задачу, в которой ты абсолютный ноль.

Как стартовую точку выбрал микро-игру. Идея простая: рыжий кот с фонарём ходит по тёмному лабиринту, находит других животных и передаёт им свет. Например, можно оставить свет зайчику, чтобы он подсвечивал проход, или забрать его и усилить собственный фонарь. Должен был получиться небольшой атмосферный пазл про свет, тьму и управление ограниченным ресурсом. И вот что получилось.

Когда проект молодой, писать «всё в одном классе» кажется быстрее. Создать отдельный интерфейс, вынести слой — это же лишняя минута! Но эта минута потом стоит часов: код невозможно покрыть тестами, замена ORM превращается в переписывание бизнес-логики, а новый человек в команде тратит день только на то, чтобы понять, где в методе заканчивается выборка из базы и начинается бизнес-правило.

Эти антипаттерны не привязаны к языку программирования — они встречаются и в Java, и в Go, и в Python. Примеры покажу на C#/.NET, но суть та же для любого стека. Три конкретных случая из реальных проектов — и как их исправить.

Я хочу поделиться опытом создания универсального прокси-сервера на C#, который поддерживает не только HTTP/HTTPS, но и FTP-протокол с автоматической подстановкой учетных данных. Зачем это нужно? Представьте ситуацию: вам нужно работать с FTP-сервером через корпоративный прокси, но стандартные средства не поддерживают автоматическую аутентификацию. Или вы хотите иметь полный контроль над трафиком между клиентом и FTP-сервером. Мой прокси-сервер решает эти задачи.

Привет, уважаемые пользователи Хабра! Решил поделиться с вами историей своего пути в геймдев. Забегая вперед, скажу, что история еще не окончена и чем окончится никому не известно. Тем не менее, возможно она вдохновит тех, кто хочет изменить свою жизнь, но не решается это сделать, потому что считает, что в «40+ уже поздно» или опасается быть непонятым окружающими.

Это моя дебютная статья. Не ждите глубоких технических разборов или чудодейственных методик, гарантированно ведущих к успеху. Никакой преисполненности собственной крутости или токсичной позитивности — только правда. При написании статьи ни одна нейросеть «не пострадала», да бы материал максимально отражал реальный уровень моих знаний и навыков. И так, не буду затягивать вступление и перехожу непосредственно к истории...

Всем привет! Меня зовут Григорий Дядиченко, и я разрабатываю разные проекты на заказ. Сталкивались ли вы с ситуацией, когда персонаж в вашей игре начинает немного дёргаться, если поиграть достаточно долго? Или пуля иногда пролетает сквозь тонкую стену, хотя коллайдер на месте? Если да — добро пожаловать в мир проблем float precision.

Сегодня хочется поговорить о том, почему тип float — при всей его повсеместности — может создавать тонкие и неочевидные баги в играх. Разберём, как он устроен, где именно он начинает врать, и что с этим делать.

Если вам интересна эта тема — добро пожаловать под кат!

В мире высоконагруженных .NET-приложений каждая наносекунда на счету. Когда ваш код обрабатывает миллионы запросов, даже микрооптимизации могут дать ощутимый прирост производительности. Две ключевые фичи, появившиеся в .NET 8— SearchValues<T> и FrozenSet<T>/FrozenDictionary<TKey, TValue> — позволяют выжать максимум из «горячих путей» (hot paths) благодаря умной предварительной оптимизации.

Меня зовут Степан, я C# профессионал уже более 7 лет на рынке и рассказываю об этом в Telegram каналe StepOne. Иногда мне скучно на работе, потому что перекладывать JSON это слишком просто, даже если микросервисы.

Я отучился на системного программиста-компиляторщика и столкнулся с отсутствием спроса рынка на такие навыки. Но выбрал быть счастливым и написал язык программирования hydrascript, чтобы JSON гонялся даже в докере на макбуке. Решение под катом вас точно удивит!

Давно интересовал вопрос использования 16-битного АЦП STM32H7 для обработки I/Q сигналов в реальном времени.

Почти год ушел на эксперименты реализации SDR приемника на базе Tayloe mixer и MCU STM32H723ZGT6, и вот что у меня получилось: принимаемый КВ диапазон 1...30МГц, вывод обработанного аудио через внутренний 12-битный ЦАП или вывод I/Q потока на ПК через UAC1.

Всем привет! Я - новичок на Хабре, потому, набравшись смелости, хотел бы поделиться небольшим домашним проектом, над которым работаю последний год в свободное время.

Расскажу немного про Big Picture Manager и о том, как читать сырые данные с контроллера Xbox Series и какие маршруты я исследовал, чтобы в итоге записать в него данные.

Любой десктопный монолит имеет один фатальный изъян: если UI поток падает - умирает вся бизнес-логика. Я решил это применив бэкенд-подход на десктопе.

Задача была амбициозной: создать единый центр управления рабочим местом. Чтобы одной кнопкой (или по расписанию) переключать ПК и комнату между режимами “кодинг”, “игры”, “стрим”. Это значит: управлять умным домом (Home Assistant), блокировать отвлекающие процессы и сайты, запускать нужный софт, контролировать медиа (Spotify) - и всё это через плагины.

Это - четвертая и последняя (пока) статья цикла про ограничение скорости обработки запросов в ASP.NET Core. Она содержит концептуальное (т.е. раскрывающее состав и взаимодействие частей друг с другом) описание функции ограничения скорости обработки запросов в ASP.NET Core. В этой статье рассмотрено, как на базе универсального компонента ограничения скорости реализована функция ограничения скорости обработки запросов в ASP.NET Core.

Предупреждение: если вам не требуется или не интересно просто для себя (как это интересно мне) разбираться, как устроена и работает функция ограничения скорости обработки запросов в ASP.NET Core, то эта статья, скорее всего, покажется вам длинной и занудной. Потому что в ней рассказывается о весьма специфических подробностях, знание которых совершенно не требуются для того чтобы просто взять и начать использовать в своей программе функцию ограничения скорости обработки запросов ASP.NET Core. Для использования этой функции, скорее всего достаточно будет изучить примеры - или из первой статьи цикла - руководства по использованию, или вообще из документации на сайте Microsoft. В таком случае вам, наверное, читать эту статью не стоит. Но, возможно, и в этом случае вам стоит хотя бы заглянуть в приложения к ней. Там я, в качестве иллюстрации к основному материалу статьи, описал сделанные мной компоненты, позволяющие использовать функцию ограничения скорости нестандартным способом: возможно, вы найдёте применение одному из таких компонентов в своей программе. Компоненты эти оформлены в виде библиотек классов .NET, так что для их использования уже сейчас можно взять их в исходном виде и добавить в свое решение (solution). Причем, при описании каждого компонента я постарался вынести в начало их описания пример его использования - так, чтобы для использования компонента не требовалось читать остальной текст приложения, где написано как он устроен и работает.

Ну, а если вам пришлось разбираться (потому что эта функция не работает так, как вы ожидали) или, как мне, просто захотелось разобраться для себя, как работает функция ограничения скорости обработки запросов в ASP.NET Core - читайте дальше.

Это - третья статья цикла про функцию ограничения скорости обработки запросов в ASP.NET Core. Она содержит концептуальное (т.е. раскрывающее состав и взаимодействие частей функции друг с другом) описание классов универсального компонента ограничения скорости .NET. Функция ограничения скорости обработки запросов в ASP.NET Core, которая является предметом рассмотрения всего цикла, базируется именно на этом универсальном компоненте. В этой статье я собираюсь завершить описание универсального компонента ограничения в .NET: описать входящие в его состав базовые (неселективные) ограничители.

Предупреждение: если вам не требуется или не интересно просто для себя (как это интересно мне) разбираться, как устроена и работает функция ограничения скорости обработки запросов в ASP.NET Core, то эта статья, скорее всего, покажется вам длинной и занудной. Потому что в ней рассказывается о весьма специфических подробностях, знание которых совершенно не требуются для того чтобы просто взять и начать использовать в своей программе функцию ограничения скорости обработки запросов ASP.NET Core. Для использования этой функции, скорее всего достаточно будет изучить примеры - или из первой статьи цикла - руководства по использованию, или вообще из документации на сайте Microsoft. В таком случае вам, наверное, читать эту статью не стоит. Но, возможно, и в этом случае вам стоит хотя бы заглянуть в приложения к ней. Там я, в качестве иллюстрации к основному материалу статьи, описал сделанные мной компоненты, позволяющие использовать функцию ограничения скорости нестандартным способом: возможно, вы найдёте применение одному из таких компонентов в своей программе. Компоненты эти оформлены в виде библиотек классов .NET, так что для их использования уже сейчас можно взять их в исходном виде и добавить в свое решение (solution). Причем, при описании каждого компонента я постарался вынести в начало их описания пример его использования - так, чтобы для использования компонента не требовалось читать остальной текст приложения, где написано как он устроен и работает.

Ну, а если вам пришлось разбираться (потому что эта функция не работает так, как вы ожидали) или, как мне, просто захотелось разобраться для себя, как работает функция ограничения скорости обработки запросов в ASP.NET Core - читайте дальше.

Привет, Хабр!

На днях HR-отдел отклонил мое резюме на позицию джуна. Вместо фидбека я получил ответ «В нашей команде слишком много козерогов, и нашему тарологу не понравился ваш Сатурн». Сначала я хотел возмутиться, но потом подумал. Может звезды не врут? Возможно наш звездный язык программирования определяется в зависимости от расположения планет во время первого запуска IDE.

Я провел фундаментальное исследование, проанализировал натальные карты Гвидо ван Россума, Страуструпа и прочих, и составил первый в мире точный гороскоп языков программирования.

И результат меня поразил...

В этой статье мы заглянем под капот CLR (Common Language Runtime) и разберём как хранятся разные типы данных. Также поговорим о том, что такое стек и куча, и как они взаимодействуют. И в заключении рассмотрим, как происходит выделение памяти и разберем принципы работы сборщика мусора.

На рождественских каникулах я ехал на автобусах из одного штата в другой, и мне нужно было как-то убить 24 часа. Я читал об UTF-8 и узнал об этой кодировке нечто интересное: все традиционные символы ASCII сохранены в ней в их исходном однобайтовом представлении, поэтому их можно сканировать крайне быстро. Я решил поэкспериментировать с кодом, максимально быстро подсчитывающим такие символы, в результате получив готовый парсер CSV, который вполне сравним с предыдущими парсерами, а то и быстрее них.

В статье я расскажу о своём процессе работы, экспериментах и оптимизациях, которые привели меня к этому итогу.

Давайте представим, что вам нужно создать класс для хранения данных пользователя. Сколько строк кода вы напишете? Конструктор, свойства, метод ToString(), сравнение объектов... А если добавится новое поле? Придется обновлять конструктор, метод Equals, GetHashCode — утомительная работа, которая не добавляет бизнес-ценности вашему приложению.

В этой статье мы разберем, как records меняют подход к написанию кода, и почему они должны стать вашим стандартным выбором для представления данных.