По-моему, это всё стереотипы. Какая тебе разница – 320 точек в ширину или 296?Сообщение от Lethargeek
16 бит. Речь же про процессоры 1801ВМ.смотря для каких (явно не восьмибитных)
С чего бы это? MOV (R1)+,(R2)+ для обычной памяти, MOVS (R1)+,(R2)+ для экранной (Screen) памяти. Просто дополнительный 17-ый бит в адресе устанавливается.это медленно и неудобно как раз
Для спрайтовой тоже, если нужно с точностью до пикселя двигать изображение.разве что для векторной графики
Последний раз редактировалось Manwe; 18.02.2020 в 14:52.
manwe.pdp-11.ru
адресная арифметика упрощается
для 16 тоже разница будет, если переход на несколько строк, сдвиги и сложения против умножений
кем, где и как?
у тебя в регистре ДВА пикселя, и кроме "двигать" в кадре могут быть другие операции с графикой
быстро вывести по сетке, быстро очистить - в общем, комплексно оценивать скорость нужно
Прихожу без разрешения, сею смерть и разрушение...
Например? Для 320 точек в ширину.
Есть таблица адресов строк. Ничего сдвигать не надо, а тем более умножать.если переход на несколько строк, сдвиги и сложения против умножений
Возможны варианты. В идеале – на уровне процессора. Костыльный вариант – на уровне контроллера дисплея.кем, где и как?
В тех же «Гоблинах» палитра 16 цветов. А всего их 256. Делаешь 16-цветные спрайты, но с нумерацией цветов в старших 4-х битах, а потом складываешь с фоном. Никаких масок не нужно. Просто правильно построенная палитра. А для переднего плана (дерево) в фоновой картинке установлены, помимо цвета, все старшие 4 бита в 1. Тогда при сложении со спрайтом гоблина гарантированно произойдёт переполнение, и по биту C определяешь, что эту точку рисовать не нужно (возвращаешь как было). Вариантов много, в общем.у тебя в регистре ДВА пикселя, и кроме "двигать" в кадре могут быть другие операции с графикой
быстро вывести по сетке, быстро очистить - в общем, комплексно оценивать скорость нужно
Быстро очистить – согласен. 32 килобайта очистить быстрей, чем 64. Компьютеру с 256 цветами нужен процессор помощней, чем ВМ1. И память побыстрей.
Последний раз редактировалось Manwe; 18.02.2020 в 16:22.
manwe.pdp-11.ru
причем тут пользователи и квардратные пиксели ?
я к тому что в БК уже есть стандартный видеорежим 512х256 и 256х256 придумывать новое, которое в принципе не совместимо со старыми стандартами плохая идея изначально
откуда эта идея про оптимальность ?Оптимальный видеорежим для ретро-компьютеров – 292x219 по 1 байту на пиксель. Это 63948 байт. Плюс 768 байт на описание палитры. Плюс 820 байт остаётся (в эту область можно вывести регистры горизонтального и вертикального рулонного сдвига, массив адресов строк и что-нибудь ещё).
если уж вспоминать байтовые видеорежимы то тогда 320х200, но как я уже сказал, это слишком много
поверьте, будет очень медленноАдресовать 64 килобайта экранной памяти было бы удобно специальными инструкциями процессора.
По скорости работы 1 байт на точку быстрей чем 1 или 2 или 3-4 бита на точку.
если говорить о спрайтах, то просто надо идти дальше, а именно использовать два слоя
первый слой - фон из двух планов по 16КБ
второй слой - спрайты и все что движется - тоже два плана по 16КБ
наложение идет по правилу - второй слой перекрывает первый в случае если цвет во втором слое !=0
дешево, просто и что важно - быстро
адресация страниц по 16КБ - те как уже сделано в БК11М
- - - Добавлено - - -
зачем делать палитры вообще ?
я уже писал что технологичнее и удобнее так:
собственно 16 пар регистров в которых 32х битный RGB цвет и все проблемы
те каждый из 16 цветов программируется отдельно
Все о БК ДВК УКНЦ VAX Alpha
Архив ПО для ретрокомпьютеров
предоставляю бесплатный хостинг на PDP-11.RU для проектов о ретрокомпьютерах
320 = (256 + 64)
зачем таблица, когда можно без таблицы? (в идеале - и без сдвигов, только сложения)
просто 16-цветный экран, который весит как 256-цветный
Прихожу без разрешения, сею смерть и разрушение...
на секунду вернусь
БКшечникам еще нужно доказывать что 256\512 лучше чем 320
нет если экран будет столбцами как в специалисте\орионе\векторе
то в ширину можно сколько хочешь
хоть 964
но в высоту только святые 256
- - - Добавлено - - -
маразм
оптимальный у специалиста ориона вектора
если 256с
то оптимальный будет 256 пикселей в ширину и сколько угодно в высоту
если заполнение столбцами то 256 пикселей в высоту и сколько угодно в ширину
но не какие не 292 и не 219
от куда ты их вообще отколупал?
от восьмеричных цифр голова перегрелась?
- - - Добавлено - - -
в идеале это inc dec
и никаких сложений
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Manwe,
final.zip
здесь самый последний вариант в .pdn
там рог сделан отдельным слоем, так что можно собрать варианты с рогом и без
если хочешь еще и зайца, то как то его придется поменять в ресурсах игры.
Ну и сюда как слой добавить.
С уважением,
Jerri / Red Triangle.
это на одну строку, а я про несколько
- - - Добавлено - - -
кстати, как это будет сочетаться с "установкой 17-го бита", которая тогда нужна будет и для источника - но вторым источником нужен адрес спрайта в обычной памяти
- - - Добавлено - - -
о, еще один адепт слоёв, для которых БЫСТРО должен управляться видеоконтроллер с видеопамятью
Прихожу без разрешения, сею смерть и разрушение...
в экране специалиста ориона вектора
переход вверх\вниз\вправо\влево
при помощи dec l inc l dec h inc h
256х192 256с
448х256 256с
будет вести себя также
конечно в условиях ихнего "превосходящего" 16 бит процессора
возможно это не будет так же быстро как на 8 битном...
.
Прихожу без разрешения, сею смерть и разрушение...
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответ