Подарю ноутбук 386SX

На блошином рынке на окраине Алматы я за 8 тысяч тенге (1500 рублей) купил 4 ретро ноутбука, сегодня расскажу об одном из них - NB 5620 от TOPPCs а в конце статьи о том как забрать его себе.
ATARI XL/XE, ретро-ноутбуки

На блошином рынке на окраине Алматы я за 8 тысяч тенге (1500 рублей) купил 4 ретро ноутбука, сегодня расскажу об одном из них - NB 5620 от TOPPCs а в конце статьи о том как забрать его себе.


В играх часто используется паттерн упаковки булевых значений в биты. Это удобно для оптимизации памяти и ускорения выполнения массовых проверок. Например, такие проверки могут включать нахождение игрока в тайле, определение доступности клеток на четырех- или шестигранной сетке, или другие пространственные проверки, которые необходимо выполнять быстро. Это не ракетостроение, но когда профайлер показал одну из таких функций в числе горячих, мне стало интересно, как именно она работает и можно ли её оптимизировать. Структура данных bitset — это способ эффективно представлять множество целых индексов, которое к тому же поддерживает различные операции над ним, например объединение, разность, пересечение.
Итак - каждый юнит может занимать один или несколько тайлов, особенно если это большой юнит, вроде колесницы или требюшета и мы хотим создать производную карту, которая хранит другие признаки, например: есть ли в тайле юнит, или фильтр по здоровью юнитов. Такие карты используются для разных быстрых проверок, вроде такой: можно ли переместиться в точку, или каких юнитов имеет смысл атаковать.
Для представления данных мы можем использовать индекс юнита в тайле. В качестве типовой задачи проверять будем только юнитов, у которых здоровье превышает определённое значение. Это условие не взято с потолка. Например, некоторые юниты используют стратегии вроде "убей слабейшего" или "нападай стаей". Для таких стратегий поюнитный обход всех юнитов вокруг (особенно если это выполняют все юниты в группе) может стать крайне затратной по времени операцией.
Название статьи получилось как-то само собой: недалеко от моего дома есть хорошее кафе Chief&Bites, достаточно популярное у местных жителей, но пирожные там начинают делать после заказа, такой вот формат анти-кафе. Сами понимаете, прождать пока сделают свежайшее пирожное полчаса, а то и час - легко, там даже на чеке пишут время, когда начали делать именно твое пирожное. Заранее извиняюсь за возможные "велосипеды" в коде, но, возможно, эта тема покажется кому-то полезной.

Всем привет! Подтолкнуло написать меня эту статью мой непосредственный интерес к алгоритмам и решению задач на leetcode, каждый раз, используя стандартную сортировку из STL std::sort, я знал, что ее сложность O(n*log(n)), но как она реализована внутри не доходили руки разобраться, в добавок мне стало интересно, какие есть другие виды сортировок, кроме самых простых, с которыми каждый знакомится в начале своего пути.
Я решил это исправить! И описать все виды сортировок, с которыми мне так или иначе приходилось встречать во время выполнения своих тасков или решению задач на leet.
Начнем с того, что разберемся, какие виды сортировок вообще есть и разобьем их на условные простые/продвинутые/для специальных случаев, а также разберемся, что использует std::sort у себя под капотом.

Страх сопровождает человечество на протяжении всей его истории. Отсутствие знаний порождало боязнь простейших природных явлений, таких как гром или молния, солнечное затмение или гало. Пытаясь объяснить различные процессы в меру своих представлений об устройстве мира, люди придумывали чудовищные легенды о различных мифических существах.
Постепенно человечество нашло объяснения большинству происходящих событий. Уменьшило ли это наши страхи? Отнюдь, ведь вместе с развитием науки и технологий развивался и трансформировался страх. Пугали друг друга страшилками у костра первобытные люди, рассказывал про мстительного призрака Плутарх в своей «Жизни благородных греков и римлян», описывали невероятных чудовищ средневековые авторы в красочных манускриптах...
bool prime(long long n){
for(long long i=2;i<=sqrt(n);i++)
if(n%i==0)
return false;
return true;
}



Во времена, когда .NET был закрытой технологией только для Windows, за ним и языком C# закрепилась репутация платформы, которая отлично подходит для решения бизнес-задач, но непригодна для соревновательного программирования и написания высокопроизводительного кода.
Часто приходится слышать, что "шарпы медленные", особенно в контексте алгоритмических задач, например с timus.online и codeforces.com. И, увы, не только слышать, но и сталкиваться с реальными проблемами, связанными с особенностями платформы, получая Wrong Answer, Runtime Error, Memory Limit, Time Limit при корректном алгоритме.
Большинство этих проблем кроется в особенностях консольного ввода и вывода. Да и часто куда проще написать cin >> nили sc.nextInt(), чем int.Parse(Console.ReadLine()) или Console.ReadLine().Split().Select(int.Parse).ToArray(), из-за чего выбор падает на другой язык.
Далее я расскажу о распространённых проблемах с консольным вводом-выводом в .NET, и о том, как сделать ввод быстрым и удобным.
Вашему вниманию предлагается небольшой обзор возможностей векторизации алгоритмов в .NET Framework и .NETCORE. Цель статьи познакомить с этими приёмами тех, кто их вообще не знал и показать, что .NET не сильно отстаёт от "настоящих, компилируемых" языков для нативной
разработки.

Всем привет. В этом материале я расскажу как создавал беспслатный сервис оптимизации изображений FlashImg.ru



Консоль Dendy в первую очередь ассоциируется с относительно простыми играми (Super Mario Bros, Duck Hunt, Battle City и т. д.), которые обычно не требуют сложных расчётов и обходятся целочисленной математикой. Но как только нужно сделать трёхмерную графику или сложную физику, сразу появляется потребность в точных вычислениях и дробных числах.
Самым простым и быстрым способом программного представления дробей являются числа с фиксированной запятой (Fixed‑point числа). О реализации такой арифметики для NES/Dendy мы и поговорим.

Начать хотелось бы с предыстории и задачи, которую я решаю на работе. Есть сайт, фотографии на котором при публикации должны подходить под определенное соотношение сторон (3х2). При этом в работе часто возникают определенные трудности. Например, что делать, если автор сделал скрин-шот, который не соответствует этому соотношению?
Здесь помочь может дизайнер, который вставит изображение на подходящий фон, или просто при загрузке выбирать, какую часть изображения придется отрезать. Оба варианта по своим причинам неудобны. Первый — из-за времени, второй — из-за потери содержания. Отсюда и родилась задача написать сервис, который автоматически будет выполнять работу дизайнера: возьмет изображение и поместит его в рамки с необходимым соотношением сторон. Получится примерно следующее:

Привет, любители старого «железа». Это Антон Комаров, и сегодня мы изучим ИТ-артефакт, одно из имен которого — Breadbox Ensemble. Это графическая оболочка для MS-DOS, которая значительно опередила свое время. К примеру, концепция меню «Пуск» в ней появилась на 2,5 года раньше, чем в Windows 95. Компанию-разработчика, Berkeley Softworks, пытались купить Microsoft, Apple Notebooks и Sun Microsystems. Но руководство не согласилось, решив продолжить самостоятельное «плавание». И оно было довольно успешным: последняя версия оболочки вышла аж в 2009 году.
Так что заваривайте себе чайку, доставайте печеньки и давайте посмотрим, ради чего в начале 90-х шла нешуточная борьба между крупнейшими софтверными корпорациями. И как Breadbox Ensemble повлияла на внешний облик операционных систем того времени. Приятного чтения.

Мой первый успех в литературе случился в 17 лет. Тогда я стал призёром олимпиады по русскому языку среди абитуриентов в вузы с сочинением: “Почему еврей Розенталь устанавливает правила русского языка”.
Пару статей назад я уже рассматривала один из алгоритмов Бойера-Мура, с помощью которого можно было найти подстроку в строке.
Сегодня хочу поболтать об алгоритме большинства голосов, который позволяется найти преобладающий элемент последовательности.
Предлагаю сразу использовать его на примере задачи «Majority Element» с leetcode.
Условие здесь: https://leetcode.com/problems/most-frequent-even-element/description/
Кстати, у меня есть телеграм-канал, где пишу подходы к решениям всяких задачек с LeetCode, там больше разборов конкретных задач, чем здесь, потому что не всегда нужна статья. В общем, если интересно - жду здесь - t.me/crushiteasy :)
Возвращаемся к Муру!
Кратко: на вход мы получаем массив, состоящий из чисел. Нужно найти число, которое встречается наибольшее количество раз.
Не супер очевидно, но это число занимает больше половины элементов массива, т.е.

В прошлой статье мы забыли упомянуть FOV (Field of view). По сути это угол обзора, в котором все лучи лежат равномерно с разницей, допустим, в ~1⁰.
К текущей статье мы успели заменить мелкую ячейку памяти настроек cell1, на банк настроек памяти bank12, bank2, bank1 (в зависимости от процессора).
Также мы решили убрать редактор карты, ведь он только запутывал людей, хотевших пользоваться нашим псевдо-3D движком, и теперь она создается автоматически.
Ещё изменился внешний вид нашего псевдо-3D движка, теперь он более аккуратный...