а как любые переменные пихают куда-нибудь, между процедурами, например?
кстати, там рабочую инфу по спрайтам можно хранить — снаружи цикла половина адреса уже в d
Тут я, кстати, всё ещё не догоняю, как ты насчитал +7 байт? Я ещё раз посчитал, никак у меня 7 не выходит: ld a,h: add 7: ld h,a: jr…
Про таблицу дошло. Но твой код, где ты будешь пихать байты между байтами своей таблицы я даже представлять себе не хочу. Я бы заплатил и 200 тактов, только чтобы никогда у себя такого не видеть. Но как решение, вообше, ок, почему нет, действительно может пригодиться когда всё будет совсем плохо.
потому что 7*inc+add лучше, чем 8*inc+add хоть в развёрнутом, хоть в неразвёрнутом варианте
но если ты к $47XX прибавишь $F820, то получишь $3FZZ/$40ZZ, а не $40ZZ/$48ZZ
у тебя не +6, а +7 без обрезки; у меня 26 с обрезкой, 17 без обрезки
но из них нужны реально лишь 8/5, а промежутки можно использовать
то есть у тебя реально больше места даже без обрезки уйдёт
проиграть и в скорости, и в размере, лишь бы не планировать таблицу, really?
это даже без учёта, что вероятность перехода сегмента может сильно изменяться от геймдизайна
например, сайдскроллер на 2/3 экрана, где в основном движуха по центральной оси
Хорошо. Допустим, связи нет. У тебя цикл, делающий inc h внутри (см. последние 2 примера кода в заметке). Почему мой выбор константы в de неправильный?
какой смысл в оптимизации вообще, если не упарываться всерьёз? 8)
расстояние в таблице (для всего экрана) от первого нужного байта до последнего 16 байт
с заворачиванием или обрезкой по низу — еще плюс один байт, с обрезкой по верху — еще плюс 8
в твоём случае +7 байт на обработку перехода с обратным jr и больше без него (дубль хвоста)
еще больше с проверкой обрезки, еще больше с заворачиванием
Во-первых, мы пока ещё цикл не разворачивали.
Во-вторых, у меня некоторое недоумение. Уточни пожалуйста, сколько точно байт понадобится для таблицы во втором из твоих вариантов кода.
«Чуть помедленнее» — это jr + ld a,h: add 7: ld h,a + jr = 5+15+12 = 32 такта на каждой трети. 3*32т=96т. Ты сейчас всерьёз упарываешься из-за меньше чем 100 тактов?
а как любые переменные пихают куда-нибудь, между процедурами, например?
кстати, там рабочую инфу по спрайтам можно хранить — снаружи цикла половина адреса уже в d
Про таблицу дошло. Но твой код, где ты будешь пихать байты между байтами своей таблицы я даже представлять себе не хочу. Я бы заплатил и 200 тактов, только чтобы никогда у себя такого не видеть. Но как решение, вообше, ок, почему нет, действительно может пригодиться когда всё будет совсем плохо.
но если ты к $47XX прибавишь $F820, то получишь $3FZZ/$40ZZ, а не $40ZZ/$48ZZ
но из них нужны реально лишь 8/5, а промежутки можно использовать
то есть у тебя реально больше места даже без обрезки уйдёт
проиграть и в скорости, и в размере, лишь бы не планировать таблицу, really?
это даже без учёта, что вероятность перехода сегмента может сильно изменяться от геймдизайна
например, сайдскроллер на 2/3 экрана, где в основном движуха по центральной оси
расстояние в таблице (для всего экрана) от первого нужного байта до последнего 16 байт
с заворачиванием или обрезкой по низу — еще плюс один байт, с обрезкой по верху — еще плюс 8
в твоём случае +7 байт на обработку перехода с обратным jr и больше без него (дубль хвоста)
еще больше с проверкой обрезки, еще больше с заворачиванием
Во-вторых, у меня некоторое недоумение. Уточни пожалуйста, сколько точно байт понадобится для таблицы во втором из твоих вариантов кода.
И что означает «не факт ещё, что в сумме короче»?
и да, чтоб не нужно было выполнять лишний inc, прибавлять следует 32-7*256