Недавно наши ребята из движковой команды выпустили статью о том, как мы навели, «красивостей» в нашем внутреннем движке. Речь шла о концепциях и том, что было важно для нас при улучшении визуальной составляющей. В этой статье я хочу рассказать, как все работает с технической стороны.
В этом уроке мы научимся запускать программу в несколько потоков, создавать полноценные уровни из мини изображения, так же научимся открывать несколько окон, скрывать и выводить вперед.
В прошлой статье мы начали рассказ о рецептах, посвященных переводу Qt-приложений на рельсы High DPI, то есть адаптации этих приложений к мониторам высокой четкости.
Суть в том, что в ОС Windows давно есть такие настройки, как масштабирование шрифта и изображений (масштаб экрана), которые применяются для увеличения слишком малых элементов GUI на мониторах с высокой чёткостью (High DPI). Однако не каждое приложение, написанное на Qt, способно адекватно учитывать, применять этот самый масштаб экрана. Частая ситуация – приложение хорошо выглядит на Full HD (1920x1080), но стоит поставить монитор 4K (3840x2160) и увеличить масштаб экрана, то появляются многочисленные артефакты.
В этой статье мы продолжим разбор примеров и изложение рецептов. Будем делать это для более сложных случаев, связанных с сохранением размеров между запусками приложения, а именно с сохранением тех настроек пользователя, что связаны с размерами.
Данный текст является переводом недавнего поста Бена Крейга - одного из членов комитета С++. TL;DR для нетерпеливых: Networking TS/Asio (P2444) не получает общего одобрения комитета, модель Senders/Receivers (P2300) становится основным направлением развития асинхронного программирования в С++.
Всем привет.
Возможно, вы слышали обо мне по моей работе над freestanding C++, но я также вице-председатель Library Evolution Working Group (LEWG). Хотел бы поделиться с вами результатами недавнего голосования комитета по поводу будущего асинхронного программирования в C++. Опрос касался "Senders and Receivers"/S&R (P2300) и Networking TS/Asio (P2444).
Данная статья посвящена параллелизму в C++, сопутствующим сложностям и как их можно обойти, используя библиотеку oneAPI Threading Building Blocks (oneTBB) для упрощения параллельного программирования.
В этой статье я хочу поделиться несколькими нестандартными алгоритмами для быстрого возведения числа в степень, а также продемонстрировать их реализацию и сравнить их быстродействие в C++, C# и Java.
Сравнить точность алгоритмов можно прямо сейчас на этой странице.
В конце будет краткая памятка по тому, где и когда лучше применять какой из методов. При правильном выборе можно добиться увеличения скорости вычислений в 5 раз при погрешности ~1%, а иногда и вовсе без неё.
В своих предыдущих постах я описывал задачи, которые были решены скорее в академических целях. Сегодня я хочу поделиться реальным примером, который работает в продакшене. Речь пойдет о написании сопрограмм, которые можно прервать извне. Изначально мне это понадобилось для реализации механизма deadline или timeout (кому как больше нравится). Согласитесь, довольно часто возникающая задача. На этом примере я продемонстрирую использование еще нескольких возможностей, предоставляемых С++. Речь пойдет об await_transform и конструкторе объекта promise_type.
в этом уроке научимся запускать таймер выводить на экран, считать фреймы в секунду
обнулять таймер и ускорять /замедлять FPS
Как и любой другой инструмент, POSIX-сигналы имеют свои правила, как их использовать грамотно, надежно и безопасно. Они испокон веков описаны в самом стандарте POSIX, в стандартах языков программирования, в manpages, однако и по сей день я нередко встречаю связанные с этим грубые ошибки даже в коде опытных разработчиков, что в коммерческих проектах, что в открытых. Поэтому давайте поговорим о важном еще раз.
Размер современных приложений и сложность языка C++ превышают возможности людей по всестороннему анализу текста программ на обзорах кода. Компенсационная методология – статический анализ кода.
Всем доброго времени суток! Это моя история о том, как я портировал исходный код одной фанатской Windows-игры о Марио с Visual Basic 6 на C++, и с какими трудностями я столкнулся в процессе создания порта.
Эта статья рассказывает о портировании Super Mario Bros. X, фанатской игры Эндрю Спинкса, созданную им в 2009 году, которую он затем бросил 2011 году в пользу более серьёзного и масштабного проекта в лице Terraria.
Задача коммерческих статических анализаторов выполнять более глубокий и полный анализ кода, чем компиляторы. Давайте посмотрим, что смог обнаружить PVS-Studio в исходном коде проекта LLVM 13.0.0.
Тема сетевого программирования является для разработчиков одной из важнейших в современном цифровом мире. Правда, надо признать, что большая часть сетевого программирования сосредоточена в области написания скриптов исполнения для web-серверов на языках PHP, Python и им подобных. Как следствие - по тематике взаимодействия клиент-сервер при работе с web-серверами написаны терабайты текстов в Интернете. Однако когда я решил посмотреть, что же имеется в Интернете по вопросу программирования сетевых приложений с использованием голых сокетов, то обнаружил интересную вещь: да, такие примеры конечно же есть, но подавляющее большинство написано под *nix-системы с использованием стандартных библиотек (что понятно – в области сетевого программирования Microsoft играет роль сильно отстающего и менее надежного «собрата» *nix-ов). Другими словами все эти примеры просто не будут работать под Windows. При определенных танцах с бубнами код сетевого приложения под Linux можно запустить и под Windows, однако это еще более запутает начинающего программиста, на которого и нацелены большинство статей в Интернете с примерами использования сокетов.
Ну а что же с документацией по работе с сетевыми сокетами в Windows от самой Microsoft? Парадоксальность ситуации заключается в том, что непосредственно в самой документации приведено очень беглое описание функций и их использования, а в примерах имеются ошибки и вызовы старых «запрещенных» современными компиляторами функций (к примеру, функция inet_addr() - https://docs.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-listen ) - такие функции конечно же можно вызывать, заглушив бдительность компилятора через #define-директивы, однако такой подход является полным зашкваром для любого даже начинающего программиста и категорически не рекомендуется к использованию. Более того, фрагмент кода в примере от Microsoft по ссылке выше.
Как вы думаете, многие люди используют дома холодильники и стиральные машины? Наверное практически все. А ломается эта техника? Еще как! А всегда ли ее потом чинят? Наверное кто-то чинит. А кто-то не чинит, а хочет от нее избавиться. А как проще всего избавиться? Вынести на помойку? А если вы живете на 3…5 этаже без лифта? Может быть выкинуть в окно? ;-) Нет, гораздо проще дать бесплатное объявление типа «Отдам даром старый холодильник. Морозит кое как самовынос и самовывоз». Объявление можно дать на авито или юлу. Указать свой номер телефона и всегда найдутся желающие взять технику. Что-то можно будет сдать в прием лома, что-то пустить на запчасти, а что-то может и починить, если есть навыки.
Только вот есть интересные моменты: сколько может найтись таких желающих и как быстро они найдутся?
Забегая вперед скажу: желающих может найтись много, и найдутся они очень быстро. В СПб, в среднем, холодильник в любом состоянии находит нового владельца за 1…2 минуты. Время очень короткое, неправда ли? А теперь я расскажу мою историю по порядку.
Несколько лет назад, мне по работе приходилось мотаться по городу. Причем ездил я в основном на метро и на маршрутках. Сидел и копался на сайтах объявлений в поисках чего-то интересного из компьютерных раритетов и прочих штуковин. И случайно напоролся на объявление об отдаче то ли газовой плиты, то ли еще чего-то похожего. И отдавали рядом с моим домом. Решив, разжиться на халявку этой техникой я дождался станции (чтобы не так шумно было) и позвонил, но мне ответили, что все, уже отдано. А прошло минуты 3…4. Ого-го, что-то быстро. И я стал уже целенаправленно искать подобные объявления, и да, они находились, только реально что-то взять уже не выходило. Я всегда опаздывал.
Накопилось у меня некоторое количество радиоуправляемых игрушек, из тех, которые покупать своим двум детям нельзя: один пульт управляет всем в округе, никакого разделения ни по частотам, ни по кодам. Одновременно играть не получится. У меня эти игрушки работают на частоте 27mhz, но аналогичные могут работать на частотах 35, 40, 49 mhz по тому же простейшему протоколу, о котором и пойдет речь дальше.
Моя идея заключалась в том, чтобы сделать USB девайс, на который можно передавать с компьютера коды команд, а это устройство каждую команду закодирует и выдаст в эфир RC-машинке.
В связи с техническим прогрессом рынок мониторов постоянно обновляется моделями с повышенным разрешением, плотностью пикселей и/или размером экрана. Году в 2010 стандартным монитором можно было считать экземпляр 19’’ c разрешением WXGA++ (1600*900) и фактической плотностью пикселей 97 DPI (dots per inch). Сейчас (2021 год) стандартным монитором, думаю, можно признать экземпляр 24’’ c разрешением Full HD (1920*1080) и плотностью пикселей 92 DPI. Под «стандартным» я понимаю тот монитор, который стоит на рабочем месте у большинства работающего люда: инженеры, бухгалтеры, переводчики и т.д. (при этом, конечно, «стандартность» — это субъективная и приблизительная оценка). Относительно новые и отчасти нишевые модели (для фотографов, видеографов, геймеров) имеют характеристики: 4K UHD (3840*2160) и 28’’ (157 DPI) или UWQHD (3440x1440) и 34" (109 DPI) или QHD (2560x1440) и 27" (109 DPI) или UWHD (2560x1080) и 29" (96 DPI). Таким образом, наблюдается рост в связанных группах признаков: разрешение+размер экрана, или разрешение+плотность пикселей, или даже разрешение+плотность пикселей+размер экрана. На рынке ноутбуков в плане экранов похожая ситуация – растет разрешение+плотность пикселей.
К сожалению, не всегда программное обеспечение поспевает за ростом характеристик мониторов. Нередко оно выглядит немного коряво и неухоженно, что расстраивает пользователя. Действительно, на дворе 21 век, а зачастую приходится видеть размытые шрифты, а иногда и микроскопические иконки.
Что касается высокой чёткости (большой плотности пикселей), то в ОС Windows давно есть такие настройки, как масштабирование шрифта и изображений (масштаб экрана), которые применяются для увеличения слишком малых элементов GUI на мониторах с высокой чёткостью (High DPI). Также есть поддержка в платформе Qt (с нюансами, об этом далее). Однако способно ли Ваше, конкретное ПО их адекватно учитывать, применять?
Хочу рассказать об одном интересном решении для работы с небольшими графами (несколько сотен или тысяч вершин с несколькими ребрами каждый) над которыми нужно выполнять довольно много разнообразных вычислений. Я постарался изложить материал максимально просто, чтобы было понятно даже начинающим разработчикам, и последовательно, начиная с самых первых простых решений в начале работы и дальше в строну усложнения. Тем не менее для поминания необходимо знание С++, в частности базовое понимание шаблонов и рекурсивных функций. Статья скорее про реализацию на С++, чем про графы.
