Есть такое. Но в случае Думов таких трюков нет, табличный способ там для скорости. Синусы и прочая тригонометрия тоже была табличной.
Фиксированная псевдослучайность тут даже помогает. Демки проигрываются ровно с теми же значениями, достаточно запоминать действия игроков и начальное значение(random seed).
Но разве настолько плохая реализация PRNG вообще может пригодиться для чего-либо?
Например, в Doom 1/2 в качестве генератора случайных чисел вообще использовался массив из 256 unsigned char'ов в псевдослучайном порядке, и этого хватало.
Главное не использовать такие простые функции там, где случайность действительно важна, о чём документация везде и говорит.
В системных требованиях Mortal Kombat 1 указано, что для игры необходимо 100 ГБ свободного места на ПК. Если пользователи несколько раз столкнутся с подобными сбоями, то размер игры превысит заявленные требования в геометрической прогрессии, пишет автор IGN.
Откуда тут геометрическая прогрессия? Добавка каждый раз по гигабайту - арифметическая.
Unreal Tournament и другие игры на том же движке на современных системах лучше работают на D3D10-рендере https://kentie.net/article/d3d10drv/ , есть и другие подобные.
Для исправления цветов и тормозов ряда старых игр подходит dgVoodoo2 - эмулирует Direct3D 3-9, DirectDraw и Glide через DX11/DX12.
Есть и другие случаи, в которых ученые могут только догадываться о происхождении роли «x», например, фраза «X отмечает место».
Что тут догадываться, это не "икс", а крест(X mark). Как отметить точку на карте в стародавние времена? Поставишь просто точку - будет неясно, может это просто помарка. Жирную точку - можно не угадать и получится клякса(шариковые ручки и карандаши тогда ещё не изобрели). Самое простое обозначение - это пересечение двух отрезков, чем крест и является в данном случае.
Этот код позволяет нам написать код, который работает как для координат с плавающей запятой, так и для координат с целыми числами. Если мы захотим добавить новую реализацию Point для другого типа данных, нам просто нужно добавить новый модуль.
Возможно это в каком-то случае было бы правильно, но в приведённом примере код для f32 и i32 идентичный и выглядит просто как нарушение принципа DRY. И вообще сложно вообразить, для какого же типа distance_to будет выглядеть иначе.
У нас имеется отсортированный список, и нам нужно найти, куда можно вставить value. В C++ для этого используется std::lower_bound, возвращающая первую позицию (итератор), для которой сравнение (обычно <) возвращает false, или last, если сравнение истинно для всех элементов.
Стоит заметить, что как раз для списков(std::list) этот код работать не будет, в отличие от std::lower_bound. Требует контейнер с последовательным расположением элементов(SequenceContainer). Из стандартных типов это массивы, std::array, std::vector, std::basic_string, и std::deque.
Установка пакетов во всех менеджерах производится схожим образом. Необходимо сначала скачать пакет (.deb, .rpm ...), далее установить пакет вручную, используя команду данного дистрибутива (dpkg, rpm и т.д.). Например, для dpkg это будет dpkg –i firefox-19.0.deb, а для apt apt-get install firefox
dpkg -i firefox-19.0.deb ставит пакет из файла, apt-get install firefox из репозитория. В последнем случае не нужно скачивать файл вручную вообще - apt скачает нужные файлы из репозитория и сам же вызовет dpkg для их установки.
Так вот, этот код, использующий адресную арифметику, служил верой и правдой на x86, и даже на x86_64 и ARM. Но на Windows ARM64 упал. Заработал после замены на va_start, va_arg и т.д.
Код рассчитан на RTL-размещение элементов в стеке начиная с item с размером элементов, равным длине указателя. Надо копать документацию MSVC ABI ARM64, чтобы точно понять, что там происходит. В общем случае UB, зависимое от реализации(implementation-defined).
Например, item может передаваться в регистре, а не на стеке. Другой вариант - выравнивание переменных аргументов может не быть равным размеру указателя(что вряд ли, но в теории возможно на каких-нибудь экзотичных архитектурах).
В Win32 API часто встречаются структуры с массивом единичного размера в конце. Запись и чтение этих массивов тоже UB?
Приведённая структура это обычная структура со счётчиком и массивом из одного элемента, что вообще соответствует всем стандартам. В отличие от массива нулевого размера(в GNU C это расширение стандарта, в общем случае зависит от реализации) или неполного типа(С99).
Код, который с ней работает, может быть или не быть UB. Если правильно выделена память под количество элементов размеромsizeof(FILEGROUPDESCRIPTORW) + sizeof(FILEDESCRIPTORW)*(cItems - 1) и за границу при обращении не выходят, то на мой взгляд тут нет UB.
Есть такое. Но в случае Думов таких трюков нет, табличный способ там для скорости. Синусы и прочая тригонометрия тоже была табличной.
Фиксированная псевдослучайность тут даже помогает. Демки проигрываются ровно с теми же значениями, достаточно запоминать действия игроков и начальное значение(random seed).
Например, в Doom 1/2 в качестве генератора случайных чисел вообще использовался массив из 256 unsigned char'ов в псевдослучайном порядке, и этого хватало.
Главное не использовать такие простые функции там, где случайность действительно важна, о чём документация везде и говорит.
В игровой форме повышать навык слепой печати можно ещё в таких играх:
Epistory - Typing Chronicles
Nanotale - Typing Chronicles
The Typing of The Dead: Overkill (в России на данный момент недоступна)
Все они про стрельбу по монстрам при печати слов, в разной форме. В Epistory и The Typing of The Dead можно загружать словари из мастерской Стима.
Для начального обучения вряд ли подойдут, но для закрепления и повышения скорости печати - вполне.
https://github.com/ErrorFlynn/ytdlp-interface
Откуда тут геометрическая прогрессия? Добавка каждый раз по гигабайту - арифметическая.
Можно попробовать исправить:
https://www.pcgamingwiki.com/wiki/Toy_Story_3:_The_Video_Game#Video
https://www.pcgamingwiki.com/wiki/Worms_World_Party#Widescreen_resolution
Neverhood - может работать через ScummVM.
Unreal Tournament и другие игры на том же движке на современных системах лучше работают на D3D10-рендере https://kentie.net/article/d3d10drv/ , есть и другие подобные.
Для исправления цветов и тормозов ряда старых игр подходит dgVoodoo2 - эмулирует Direct3D 3-9, DirectDraw и Glide через DX11/DX12.
Так и в std::array итератор - тоже обёртка над сырым указателем. Они вообще между собой ничем не отличаются, даже типом:
Выведет для g++ и clang++:
Т.е. указатели на int, в данном случае.
Вопрос был в том, можно ли итераторы использовать для работы с ними, или нет, а не в том, что умеют или не умеют массивы сами по себе.
А вот и неправда:
Что тут догадываться, это не "икс", а крест(X mark). Как отметить точку на карте в стародавние времена? Поставишь просто точку - будет неясно, может это просто помарка. Жирную точку - можно не угадать и получится клякса(шариковые ручки и карандаши тогда ещё не изобрели). Самое простое обозначение - это пересечение двух отрезков, чем крест и является в данном случае.
Возможно это в каком-то случае было бы правильно, но в приведённом примере код для f32 и i32 идентичный и выглядит просто как нарушение принципа DRY. И вообще сложно вообразить, для какого же типа distance_to будет выглядеть иначе.
Стоит заметить, что как раз для списков(std::list) этот код работать не будет, в отличие от std::lower_bound. Требует контейнер с последовательным расположением элементов(SequenceContainer). Из стандартных типов это массивы, std::array, std::vector, std::basic_string, и std::deque.
dpkg -i firefox-19.0.deb
ставит пакет из файла,apt-get install firefox
из репозитория. В последнем случае не нужно скачивать файл вручную вообще - apt скачает нужные файлы из репозитория и сам же вызовет dpkg для их установки.Код рассчитан на RTL-размещение элементов в стеке начиная с item с размером элементов, равным длине указателя. Надо копать документацию MSVC ABI ARM64, чтобы точно понять, что там происходит. В общем случае UB, зависимое от реализации(implementation-defined).
Например, item может передаваться в регистре, а не на стеке. Другой вариант - выравнивание переменных аргументов может не быть равным размеру указателя(что вряд ли, но в теории возможно на каких-нибудь экзотичных архитектурах).
Приведённая структура это обычная структура со счётчиком и массивом из одного элемента, что вообще соответствует всем стандартам. В отличие от массива нулевого размера(в GNU C это расширение стандарта, в общем случае зависит от реализации) или неполного типа(С99).
Код, который с ней работает, может быть или не быть UB. Если правильно выделена память под количество элементов размером
sizeof(FILEGROUPDESCRIPTORW) + sizeof(FILEDESCRIPTORW)*(cItems - 1)
и за границу при обращении не выходят, то на мой взгляд тут нет UB.Flexible array member входит в стандарт C99. Но там не нулевого размера, а неполного типа(incomplete type), т.е. вида
int a[];
.Четырехмерное пространство вообразить довольно просто. Для этого достаточно представить четыре ортонормированных вектора. Остальное приложится. (c)
Скорее так - гравитация искривляет кратчайший путь света, а не фотоны сами по себе.
Выходит, что не деформируется. Возможно потому, что фотон это переносчик взаимодействия, а не вещество.
Аналогичный эффект проявляется в космологическом красном смещении - длина волны фотона становится короче, пока он летит в расширяющейся вселенной.
Полагаться на это не стоит:
А кстати…
Уже нашли причину проблем с картами Nvidia: https://www.nvidia.com/en-us/geforce/forums/game-ready-drivers/13/501432/nvidia-frameview-sdk-service-causing-massive-lag-a/3283721/
Решение: https://nvidia.custhelp.com/app/answers/detail/a_id/5395