Для игры, использующей спрайты, подобная низкоуровневая компоновка была проблемой. Попробуйте представить себе задачу по использованию маски/записи с разрешением в один бит, когда разрешение шины составляет один байт (8 бит). Теперь представьте, как спрайт пересекает границу байтов, и задача превращается в кошмар[15]. Нагрузка на CPU была такой большой, что игры не использовали маску/запись и вместо этого предпочитали использовать предварительно повёрнутые спрайты (один набор для каждого выравнивания битов), что, к чести Atari ST, не было слишком большой проблемой, учитывая щедрое количество оперативной памяти на борту.
Отличная статья, спасиб
На первый взгляд выглядит нормально, но если почитать внимательнее, то очевидно, что аффтар перевода нихуя не понимает, что переводит:
Здесь нет хитрого трюка, но неплоская компоновка фреймбуфера позволяет 68000 «путешествовать». С кадровым буфером на 32 КБ операции move.l длиной 8000 (32 бита) выполняют работу в обоих случаях. Та же идея для FILL, за исключением того, что вместо операнда «Address register indirect with post-incrementing» первый операнд команды move.l представляет собой «Data direct», который занимает «только» 12 циклов. Это даёт в общей сложности 12 мс для FILL.
Полная ахинея.
В то время как Amiga допускает 12 бит на цвет, AtariST может дать только 9.
Не на цвет, а на пиксель, недопереводчик. 12 бит на цвет даже современные мониторы не дают. Даже ниже у тебя про это написано:
преобразовании из 12-битного в 9-битный с простым 1-битным сдвигом (LRS) для каждого канала во время загрузки
Не на цвет, а на пиксель
На цвет каждого пикселя, 3 на каждый канал.
недопереводчикЧто ж.
Нифую не понятно, но очень интересно(звиняйте, забыл взять мем)