Зачем?Цитата:
Сообщение от Lethargeek
Вид для печати
Зачем?Цитата:
Сообщение от Lethargeek
:v2_dizzy_facepalm:Цитата:
Сообщение от Manwe
- - - Добавлено - - -
реальным пользователям не пофиг на качество (в том числе и скорость, и размеры) программЦитата:
Сообщение от Manwe
в современных проц не на 8 бит, аппаратные деления/умножения и дрова для вычислений на гпуЦитата:
Сообщение от Manwe
не особо выше чем с маскированием, больше позволяет сэкономить память на маскеЦитата:
Сообщение от Manwe
- - - Добавлено - - -
и падажжи, ты опять собрался пиксели-байты складывать словами, не заботясь о переносе?
Почему гоблины такие тормозные?Цитата:
Сообщение от Manwe
3 гоблина, зайчик,рог. Чего оно так тормозит?
Погодите, у Z80 нет что ли табличной адресации? Чем вас так испугала таблица адресов строк, что вы готовы вместо обращения к таблице по индексу умножать на 256 и складывать с умножением на 64?
таблица в любом случае лишнее обращение к памяти
чем меньше обращений к памяти
тем быстрей код работает
- - - Добавлено - - -
как бы это элементарная операция для z80 :)Цитата:
Сообщение от Manwe
- - - Добавлено - - -
не то чтобы испугалаЦитата:
Сообщение от Manwe
просто результат виден... :v2_dizzy_facepalm:
Все правильно. Я посмотрел Loom я посмотрел обезяний остров.Цитата:
Сообщение от zx_
Разговор шел что кто-то делает Loom. И показали Остров Обезьян на БК.
Мда. Жаль.
Так это результат применения совершенно других методов.Цитата:
Сообщение от NEO SPECTRUMAN
Я говорю вот про какой метод: допустим в R1 у тебя координата X, в R2 координата Y (всегда умноженная на 2). Чтобы получить адрес точки по координатам X,Y ты делаешь
Всё, теперь в R0 у тебя адрес точки. Хочешь - стирай её CLRB (R0). Хочешь, записывай число (например, данные из спрайта) MOVB (R3)+,(R0)+Код:MOV ScreenLines(R2),R0
ADD R1,R0
А теперь сравним с умножением на 320 (Y не умножен на 2):
Здесь мы делаем смелое предположение, что бит C заранее сброшен и координата Y настолько мала, что при умножении на 320 не получится переполнения. Если же учесть ещё и это, добавится ещё пара команд как минимум.Код:SWAB R2
MOV R2,R0
ROR R0
ASR R0
ADD R2,R0
ADD R1,R0
SWAB R2
Теперь посчитаем такты на БК 4 МГц.
Да-да, конечно :)Цитата:
Сообщение от NEO SPECTRUMAN
В медленной памяти:
первая процедура 56 тактов
вторая процедура 112 тактов
В быстрой памяти:
первая процедура 37.33 такта
вторая процедура 58 тактов
Внезапно 7 команд во второй программе - это 7 обращений к памяти. В то время как первая программа обращается к памяти 4 раза, причём первые два из них происходят за один цикл обработки и попадают в одно окно доступа к памяти.
Ну ладно, а что же с умножением на 256?
48 в медленной памяти,Код:MOV R2,R0
SWAB R0
ADD R1,R0
25 в быстрой.
В медленной памяти умножение на 256 получилось не сильно быстрей, чем по таблице (48 vs 56 ~ 17%). Любое отклонение от значения 256, будь оно хоть трижды "красивое" с точки зрения двоичной системы, с треском проигрывает табличному умножению. Любимая спектрумовская высота экрана 192 тоже проиграет.
1) две команды swab - лишние, пользуйся 16-битностью, пусть всегда будет Y*256Цитата:
Сообщение от Manwe
2) прибавляют обычно сразу к адресу, а не переводят каждый раз из координат
- - - Добавлено - - -
или *64 если ADD быстрее ROR/ASRЦитата:
Сообщение от Lethargeek
Убрал два SWAB, получилось 80 тактов. Всё равно больше чем 56.Цитата:
Сообщение от Lethargeek
Это принципиально не изменит результатов теста.Цитата:
2) прибавляют обычно сразу к адресу, а не переводят каждый раз из координат
Тоже сильно не повлияет.Цитата:
Сообщение от Lethargeek
зато +440 байт, которые могут пригодиться в других табличных расчётахЦитата:
Сообщение от Manwe
на машине, где всего-то 15.5 кб свободно
а что в быстрой, кстати?
- - - Добавлено - - -
+ с 320 меньше мучиться с масштабированием/обрезкой при любимом занятии быкашников - конвертации :pЦитата:
Сообщение от Lethargeek
- - - Добавлено - - -
притом табличка для странных разрешений необходима даже в случаях, когда не нужна рекордная скорость, или тормозить будет всё