GriV, вот я тоже так считал!
А вот тут http://zxdn.narod.ru/coding/n105sprd.txt
Да и Andrew771 про такую же таблицу наверное говорит. Как это подробнее?5.По табличке (192*2=384 байт), содержащей по два байта, означа-
ющих начало каждой следующей линии. В глубоком детстве мне ка-
залось, что это очень расточительно для памяти. :/
POP DE
LD A,E
ADD A,C
LD E,A
Итого по тактам: на каждую следующую линию = 22 такта.
Последний раз редактировалось NovaStorm; 03.01.2012 в 15:40.
звучит как наезд! А вы из какой группировки? :-)Сообщение от Andrew771
Код хочу, это всё слова.
Это нечестное сравнение. Мою п/п вы вызовете в любое время и она вам пересчитает. А этот код предполагает что вы следите (заряженными данными на стеке), какая у вас текущая строчка, на шага влево, ни шага вправо. Недостатков тут хватает, кстати, и работа с прерываниями уже исключена.
Если же вы захотите стек перед рассчётом установить, то рассчёт у вас будет по времени больше занимать, чем прямой рассчёт down hl в лоб, да и сам стек ещё надо восстанавливать после использования.
Если же использовать таки ту технологию, что тут была предложена - слежением за текущей строчкой - то я предложу вариант ещё короче
условие: hl - указывает на текущую строчку/символ
pop de
add hl,de
; данные на стеке содержат разницу в адресах при переходе с указанной пиксельной линии на следующую
получилось короче на 1 такт и в байтах основного тела - 2 байта вместо 4х.
Имхо узкоприкладной способ этот. Да и разница - 21 такт вместо типичных 27 - не так уж велика, часто ли приходиться переходить с одной пиксельной полоски на другую?
В регистре DE при вызове процедуры содержать координаты точки на экране, а не адрес. Тогда всё намного проще.
1. Down HL:
INC H
LD A,H
AND 7
RET NZ
LD A,L
SUB #E0
LD L,A
SBC A,A
AND #F8
ADD A,H
LD H,A
2. Самый быстрый адрес:
POP HL
(стек конечно на табличку экранных адресов указывает)
3. Вывод спрайта:
Формируем в памяти массив вида
[вывод 1-й строчки]
[вывод 2-й строчки]
[вывод 3-й строчки]
[вывод 4-й строчки]
[вывод 5-й строчки]
[вывод 6-й строчки]
[вывод 7-й строчки]
[вывод 8-й строчки]
переход на строку ниже (к L прибавляем #20, H - восстанавливаем любым методом)
Дальше тоже-самое.
[печать следующего знакоместа, снова вывод 8 строчек]
Дальше всё так-же + переход на другой сегмент.
Обращатся с этим извратом так: Рассчитываем КУДА прыгать (с какой строки рисовать начинаем), потом рассчитываем ГДЕ заканчивать (ловушку ставим прямо в код, RET или какой другой выход, JP например).
Кидаемся в подпрогу.
Она отрисовывает и вылетает где надо.
Восстанавливаем код (который ловушками зафаршмачили).
Делаем дальнейшие дела (ну там инт ловим, или музыку-ноту брякаем в общем что там ещё...)
Быстрей по-видимому никак...
Не понял я. Ещё раз прошу, код с пояснениями можно увидеть? Если я правильно понял, то предлагается одну задачу заменить другой. Это неправильно. Стояла задача быстрого DOWN HL, табличного. Да и как можно в 384 байта уложить весь экран со всеми его замороками?
---------- Post added at 01:39 ---------- Previous post was at 01:38 ----------
ну его я и привёл, фактически. Разница там незначительна на некоторых вариантов. Хотя пруф засчитан, но это не табличное решение.
В конце RET отсуствует.
---------- Post added at 01:40 ---------- Previous post was at 01:39 ----------
Стоп. А стек как устанавливать и где? И как учитывается смещение по X в этом методе?
---------- Post added at 01:41 ---------- Previous post was at 01:40 ----------
+1. Но собственно с этим я не спорю. Но это не табличный или не совсем табличный метод. Это скорее раскрытые циклы с учётом вхождения по пиксельным линиям, пример качественного кода.
---------- Post added at 01:52 ---------- Previous post was at 01:41 ----------
Ага вот ещё как можно. Строится таблица всех переходов начиная с адреса #8000. Логика такая. Умножаем на 2 адрес, указывающий на экран. Получаем адрес #8000-#B600, в которых содержится адрес следующей ячейки.
Логика такая:
add hl,hl
ld sp,hl
pop hl
Итого 11+6+10= опять 27 тактов но железно всегда, даже если переходы через трети/знакоместа. Плюс портится стек, который где-то восстанавливать надо.
Резюмирую так же: не стоит оно того.
GriV, ограниченные штуки со стеком и таблицей, выигрывающие несколько тактов, решают в демах. там эти такты многократно потом вылазят, а прерывания в такие моменты просто не придут и стек перенастраивать только 1 раз на почти 200 линийтак что всему свое время и место. это просто говорит о том, что стандартный down hl - не всегда идеал.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
2 GriV:
Ты всё правильно понимаешь.
Либо скорость, либо плотный код.
На современном железе это всё теряет значение, но на тупорылом спеке - конечно нужно чем-то жертвовать.
Или памятью, или скоростью...
(конечно обидно! а выхода нет...)
---------- Post added at 03:24 ---------- Previous post was at 03:17 ----------
Стековая таблица тут получается для каждого столбца (32 экранных знакомест) и на всю высоту (тоже для каждого, т.е. (192х32)*2 ибо целый ворд (слово, 2 байта) на адрес)
Ну и ещё прескролловую табличку (размером в #1000) нужно где-то разместить, это и будет твой X.
---------- Post added at 03:29 ---------- Previous post was at 03:24 ----------
На спеке, в виде современного (т.е. желаемого как максимум) кодинга - только раскрытие циклов (полный отказ от них) и развёртка кода в один гигантский исполняемый дамп.
Таблицы - помогают, но это костыли.
Алонкодер в этом хорошо разбирается, но он ни с кем не делится своими знаниями.
Его можно понять.
(ну например: Ты хотел-бы объяснить муравью корпускулярно-волновую теорию? Вот так-то...)
---------- Post added at 03:40 ---------- Previous post was at 03:29 ----------
А, ну да.
Это оттого что только на процессе отладки CALL делают, а вообще эти все DOWNHL втыкают сразу в тело кода (да ещё с учётом сегмента) чтоб значит не жрало лишних тактов по 50 раз во фрейм.
---------- Post added at 03:54 ---------- Previous post was at 03:40 ----------
Вообще сказать - это позорище и ламота, этого делать никогда (на Speccy) нельзя, эти ревюшные процедуры (на которых мы росли, учились и т.д.) - страшный расход процессорного времени (ибо Z80 есть не что иное как медленный кусок кремня, жутко неоптимизированный и просто законеченная в себе вещь, как результат триумфа своего времени.)
Но вот вытащить из него максимум - это подвиг!
(ребята какие-то General Sound придумали, а получился у них паскудный звук и второй спектрум впридачу, который якобы УСТРОЙСТВО!)
Вот тот-же AloneCoder, на пару с ShiruOtaku (которого я тоже как и с Titus`ом путал что думал мол, Митника поймал) - пошли другим путём:
Ширу - написал винрарную статью (по которой я сделал-таки себе немножко doom`а,).
А АлонКодер - всех поимел, написал позорный вольф, подождал (несколько лет), а когда я решил что уже крут - макнул мордой мня в грязь выложив сорцы свои.
Я и притух...
А ведь действительно, чего я там с тангенсами бился???
Последний раз редактировалось Destr; 04.01.2012 в 04:19.
Да я спорю что ли? Просто тут люди говорят про 384 байта, я вот думаю как они туда весь экран засунули?
---------- Post added at 11:53 ---------- Previous post was at 11:29 ----------
спс :-)
Т.е. при переходе на другую координату X надо пересчитывать таблицу и адрес вхождения? Т.е. на единичной операции - непроизводительно? и 384 байта - это только для 1ной координаты X? А всего 384*32=12288 байт? Ну тогда вы далеки от оптимальности :-) И произвольная смена координаты X|Y поставит ваш алгоритм в тупик :-)
Не всегда эффективно, только на упрощаемых операциях. Не всю логику можно упростить.
За базар ответишь? :-) зря человека обижаешь, очень отзывчивый он.
ок :-)
Это ты на святое руку поднял :-) как раз ревюшние этюды это пример мегакомпактного, но эффективного кода. Быстрее только были только бешенные развёрнутые циклы типа pop push, их код сам по себе уже не подлежал оптимизации. Так что - не согласен :-)
---------- Post added at 12:05 ---------- Previous post was at 11:53 ----------
Возвращаясь в наши баранам - кто нить даст универсальный быстрый табличный код down hl? :-)
Подведу промежуточные итоги:
- Самый быстрый универсальный пока предложен мной - 27 тактов на тело + 12288 байт таблица + недостаток используется стек + не используются другие регистры
- Самый быстрый с слежением - 10 тактов на тело + 12288 байт таблица + недостаток используется стек + не используются другие регистрыКод:add hl,hl ld sp,hl pop hl
- Медленнее, но с приемлей по размерам таблицей - 21 такт на тело + всего-то 384 байт таблица + недостаток используется стек + недостаток используется DEКод:pop hl
Из табличных пока ничего другого нет.Код:pop de add hl,de
---------- Post added at 12:12 ---------- Previous post was at 12:05 ----------
Просьба больше по теме писать :-)
Andrew771, это дорого - тратить целую пару регистров на координаты при отсутствии жесткой необходимости
С уважением,
Jerri / Red Triangle.
странный какой-то код... как минимум он не реюзабельный - кто будет hl каждый раз перезагружать?
вот приводился нормальный реюзабельный код:
здесь рег.С=Х, одна табличка 384 байта, 22 такта.Код:POP DE LD A,E ADD A,C LD E,A
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
