Ну, берется голый OpenGL или DirectX, и пишется игра. То что в последнее время игры в основном на перечисленных движках пишутся - это довольно новое веяние, последних 5-10 лет, наверное. До этого писали вообще без движков, либо каждая студия писала свой движок под серию игр или даже под одну игру.

Если возник новый вопрос - задавайте, а не портите старый, который относится совершенно к другой теме.

Увы, вы почему полностью вопрос поменяли, а не удалили этот и создали новый?

@insolor - "До этого писали вообще без движков"... я бы посмотрил, насчет того, что это довольно новое веяние. Доказательство тому - то, что самим игровым движкам - уже много лет (Unity - 19 лет, UE - около 25 лет, и уже в 2004-2007 году его использовали, например, для Mass Effect). Другое дело, что "мода" на игровые движки меняется

@ШвеевАлексей У меня блокировка вопросов, пытаюсь из неё вылезти, я даже конкурс поставил, чтобы меньше таких вопросов было

@KirillLanskoy А теперь подумай, почему у тебя может быть блокировка вопросов...

@ШвеевАлексей. Я вопросы до блокировки никогда не менял

@KirillLanskoy Увы

Пожалуйста прекратите вандализировать свои вопросы.

Я ничего не могу поделать, я даже конкурс начал, что вы не откатывали к предыдущим версиям

Почему блокируются вопросы с моей учетной записи?

1 - BCD избыточен. 2 - у него нет фиксированной длины. Процессору удобно брать значение 32/64 бит в регистр, и с ним работать. 3 - процессору удобнее считать в двоичном представлении, а не в костыльно прикрученном десятичном. 4 - сверхвысокая точность без потерь при конвертации в десятичную систему действительно нужна только в очень узком круге задач - при работе с деньгами, например. В остальных случаях достаточно "неточного", зато относительно просто реализуемого в "железе" IEEE 754.

@insolor. 1. BCD избыточен - странное замечание. 2. Не очень понял, что Вы имели в виду. 3. Плавающие числа(это даже не двоичное представление, а двоичный стандартный вид числа) считает FPU, а с таким же успехом можно написать и BCDU без потерь скорости. 4. Зачем иметь неточный IEEE754, если разницы в реализации условного BCDU и FPU нет?

В последние годы внезапно оказалось, что высокая точность нигде и никому не нужна. 64-битные вещественные числа практически нигде не используются. С лихвой достаточно 32 бит. Более того, в связи с развитием нейронных сетей возникла необходимость хранить огромные объёмы данных для них. И даже 32 бит оказалось слишком дорого. Вполне хватило бы 16 бит, но совсем чуть-чуть не хватает точности. Причём и её хватило бы, если пересчитать все накопленные массивы информации нейросеток, а на это нужны годы. В итоге, сейчас используются 19-битные процессоры (это не опечатка, именно девятнадцать).

Сейчас даже есть 8 и 4-битные форматы чисел с плавающей точкой. И для огромного количества применений их точности хватает.

@AlexanderPetrov Возврат на 60 лет назад? Когда в ходу были 48-битные и 37-битные и любые компьютеры)))

@AlexanderPetrov. А если серьёзно, то минимальное это 16 бит (как раз обычно для нейронок), меньше никак не может быть

@KirillLanskoy однобитных нейронок не хотите? habr.com/ru/articles/822141

@KirillLanskoy 1. классический BCD: в одном полубайте используются значения от 0 до 9, A-F - нет. Итого из 256 возможных значений используется 100, более чем в два раза меньше. Это и есть избыточность. Использовать это для чего-то другого, чем промежуточного представления в памяти перед выводом на экран - расточительство. 2. Как в обычном десятичном формате, так и в BCD числа могут занимать разное количество байт. В бинарном формате - максимум, который укажем (32, 64 бита). Для меня все еще загадка - что за BCDU, поисковики ничего подходящего не находят.

@KirillLanskoy меньше 16-битного float вполне может быть. Главное это как-то в железе реализовать. См. en.wikipedia.org/wiki/Minifloat. Для нейронок, когда нужно хранить значения от 0.0 до 1.0, и прямо высокая точность не нужна - в самый раз.

@insolor. Я сказал "условный BCDU" по аналогии с FPU, а то всегда один из первых ответов, что BCD медленнее, так он не реализован в железе. Там не в два раза, чем больше число, тем меньше значений BCD хранит, на 64 ещё меньше чем просто в двоичном формате. Но здесь речь всего лишь про 52 бита и разница в три десятичные цифры, зато без ошибок округления, проблема A-F может реально отразиться на каких-нибудь 1024 значениях

Когда-то давным-давно вычисления с BCD были реализованы в железе. Не помогло.

@AlexanderPetrov Потому что тогда просто все условные 64 бита отдавались на BCD

@KirillLanskoy, да просто нет никакого смысла в изначально двоичный мир тянуть человекоцентричную десятичную систему. Это только усложнит железо. Если железо сложнее, то оно дороже, а тут еще оверхэд из-за неиспользуемых вариантов значений. Ошибки округления точно так же будут и в десятичной системе, просто не будет потерь точности при переводе между системами, а это можно пережить.

@insolor. Разве FPU «легкий»?

И я не понимаю, почему вопрос понижают за недостаточность описания проблемы, там вроде всё описано

@KirillLanskoy FPU - относительно простой, ваш BCDU из-за этого перетягивания десятичности в двоичный мир - сложный.

@KirillLanskoy у вас кривое оформление вопроса (в начале вопроса куча жирного текста, не относящегося к, собственно, вопросу), плюс вы с ходу обрушиваете на читателя кучу непонятных аббревиатур