![](https://webcf.waybackmachine.org/web/20210927122452im_/https://habrastorage.org/getpro/habr/upload_files/877/a0f/c9c/877a0fc9c92663d8cd2acc965493dacc.jpg)
Здравствуйте, дорогие друзья. Продолжаю Вас знакомить на Хабре с новостями проекта Haiku.
Типизированный язык программирования
Здравствуйте, дорогие друзья. Продолжаю Вас знакомить на Хабре с новостями проекта Haiku.
изменение цвета у спрайтов, позволяет получить нам новый спрайт, а благодаря аппаратному ускорению, прозрачность создается гораздо быстрее чем в первом SDL
приступим к коду:
Иногда нам нужно отрисовывать только часть текстуры, или иметь несколько изображений. В большинстве случаев подгружать одну картинку со множеством спрайтов экономически целесообразнее, чем подгружать множество изображений.
Дисклеймер: почему собрался это делать - потому что нет нигде нормального обучения, для С\С++, поэтому все бросают это дело, так как невозможно разобраться, просто ужас.
В предыдущей статье я описал простой путь создания генераторов на корутинах С++. На мой взгляд генераторы неплохо демонстрируют работу с такими объектами как coroutine_handle и promise_type. На этот раз речь пойдет об awaitable объектах — еще одной неотъемлемой части поддержки корутин в С++. А рассматривать мы их будем на примере реализации каналов, аналогичных каналам в GoLang. Как С++ разработчик, я не в восторге от многих решений принятых в GoLang, но в их каналы влюбился с первого взгляда. Итак, приступим!
Пару лет назад в статическом анализаторе кода PVS-Studio появился ряд диагностических правил для проверки соответствия текста программ стандарту MISRA C и MISRA C++. Увидев интерес и собрав feedback, команда разработчиков стала дальше развивать анализатор в этом направлении. В статье будет рассказано про стандарт MISRA C/C++, отчёт MISRA Compliance, про то, что мы уже успели сделать и что собираемся достичь до конца года.
Добрый день, жители Хабра. Данный пост будет посвящен программированию на C++, и использованию constexpr объектов с целью повышения уровня удобства и одновременно оптимизации кода с точки зрения размера и производительности.
В процессе работы над одним из проектов, задумался: "нельзя ли сделать удобный доступ к GPIO портам на STM32, и при этом сделать его оптимальным по размеру кода и производительности". Что я хотел получить...
Этот текст предназначен для тех, кто только осваивает программирование. Я читаю лекции по C++ на первом курсе местного университета, и в качестве практикума предлагаю запрограммировать любую игру (не выношу проектов типа "софт бронирования книг в местной библиотеке"). Соответственно, чтобы помочь начинающим, я сделал некоторое количество заготовок, с которых можно стартовать свой проект. Например, заготовку олдскульного 3д шутера в 486 строк C++ я уже описывал, а вот тут можно посмотреть, что из неё сделали первокурсники.
В этот раз всё будет ещё проще, я хочу сделать заготовку под простейший платформер, вот так выглядит результат:
На данный момент проект содержит менее трёхсот строчек цпп:
ssloy@khronos:~/sdl2-demo/src$ cat *.cpp *.h | wc -l
296
Мой опыт показывает, что просто выложить код заготовки недостаточно. Нужно детально описать, как именно я пришёл к такому коду, ведь самый главный навык программиста — это суметь разбить сложную задачу на некоторое количество более простых подзадач, каждая из которых решается легко.
Итак, поехали!
Недавно я решил написать свою собственную реализацию длинной арифметики для C++. Делал просто для себя, ибо эта тема мне кажется довольно интересной. Поставил перед собой следующие задачи:
Я уже пару лет как развлекаюсь написанием различных программ на C++ с использованием корутин. Но до сего момента это были асинхронные приложения. Я активно использовал co_await, но ни разу еще мне не понадобился co_yield. И вот, после трех дней вынужденного ничегонеделанья в больнице, я решил этот пробел восполнить и попробовать написать собственный генератор. А заодно и получше разобраться с promise_type и coroutine_handle
Привет, Хабр!
Наверняка в фильмах или сериалах, а может быть даже на собственном опыте, вы сталкивались с игровыми автоматами. Мы тоже, и однажды у нас появилась идея создать современную версию игры, похожую на всеми любимую космическую аркаду Blasteroids. А чтобы вдвойне воплотить наш замысел в жизнь, мы сделали два режима управления игрой, один из которых — с помощью Ардуино, играющего роль маленького переносного геймпада, а другой — с помощью клавиатуры.
Я сейчас изучаю продвинутые структуры данных и в один прекрасный вечер я решил собирать алгоритмы и структуры данных к себе на гитхаб (и до сих пор это делаю). Захотел я сделать так, чтобы сделать всё шаблонным, если что-то мне резко понадобится, то я смог за считанные секунды добавить себе шаблонный класс структуры данных или шаблонную функцию алгоритма и использовать. Звучит замечательно, особенно на контесты с codeforces.
Я столкнулся с проблемами и решил здесь поделиться опытом с тем, кто также, как и я, мало знаком с пром. прогой и до этого в основном увлекался олимпиадным программированием.
На сегодняшний день существует много способов организовать обмен данными между Desktop-приложением и устройствами на микроконтроллерах: Wi-Fi, Bluetooth, RF, USB, преобразователи интерфейсов и т.д.
В большинстве из вышеперечисленных вариантов реализован пакетный обмен данными между хостом и устройством. Передаваемые данными с гарантией целостности и доставки будут переданы от передатчика к приемнику.
В случае использования интерфейсов RS-232, RS-485, RS-422 или чистого UART организация пакетного обмена данными ложится на программиста.
В данной статье я хотел бы рассказать о своей реализации обмена данными между устройствами.
Решил портировать одну старую давно забытую игрушку с DOS на современную платформу. Эта игра, в своё время, привлекала ураганным геймплеем, неплохой разрушаемостью, возможностью включить всё оружие одновременно и устроить настоящий бедлам. В 2021 году играть в такое всё ещё интересно, но делать это в родном разрешении 640х480, как-то не очень. Поэтому решил портировать игру и накатить хай-рез патч. Получилось!
В наше время никого не удивишь, когда программа, написанная на скриптовом языке, вызывает нативный код, например, когда необходима максимальная производительность, обращение к каким-то внешним библиотекам или специфические системные вызовы. Точно так же, никого не удивишь, когда в программу на компилируемом языке встраивают интепретатор скриптового языка, например, для расширения функционала или возможности автоматизации действий пользователя. Но сегодня речь пойдет не о том, сегодня все будет немного более упорото.
Мы занимались разработкой... скажем так, системы отображения интерактивного контента для рынка одной азиатской страны. Пользователь имел "умное устройство", например, ТВ-приставку или смарт-телевизор, а "интерактивный контент" представлял собой по сути дела html/js/css-приложение, которое прилетало на устройство с трансляции или из интернета и отображалось в прозрачном окне поверх видео. В качестве веб-движка использовался модифицированный Blink из гугловского Chrome.
И вот, в один прекрасный день после какого-то из обновлений, один наш партнер (читай "поставщик контента") обратился к нам с проблемой: что-то не работает.