Хорошо. Допустим, связи нет. У тебя цикл, делающий inc h внутри (см. последние 2 примера кода в заметке). Почему мой выбор константы в de неправильный?
Во-первых, мы пока ещё цикл не разворачивали.
Во-вторых, у меня некоторое недоумение. Уточни пожалуйста, сколько точно байт понадобится для таблицы во втором из твоих вариантов кода.
«Чуть помедленнее» — это jr + ld a,h: add 7: ld h,a + jr = 5+15+12 = 32 такта на каждой трети. 3*32т=96т. Ты сейчас всерьёз упарываешься из-за меньше чем 100 тактов?
Ты конечно знатный извращенец. Действительно, с таблицами такого размера спрайты на полэкрана для тебя и правда фантастичны. На каждом ряде знакомест вместо 67 тактов у тебя выходит 4+11+7+7+8+10 = 47 тактов. 24*20т = 480т (на самом деле, меньше, из-за обработки хвоста). Я бы не стал так делать. Разворот DJNZ даст намного больше скорости и займёт намного меньше памяти.
Но я рад любым идеям, потому что, как ты знаешь сам, приходит день и всё это обязательно пригождается, м.б. в каком-то другом виде.
Кроме того, RST7 предложил ещё один подход к реализации DOWN_HL, разбивающий счётчик строк в спрайте на два и в итоге ускоряющий DOWN_HL ещё в 2 раза. Это решение показано в только что добавленном приложении к статье.
Не прошло и ста лет, как я обнаружил, что исходники демо выложены на GitHub: github.com/restorer/zxspectrum-lo-fi-motion-2020
Большое спасибо автору! Надеюсь это поможет другим невнимательным читателям вроде меня!
Ссылку на пост на Хабре мне прислали товарищи, и хотя читать её было весело, по сути ничего нового для квалифицированного Z80 кодера там не сообщалось. А вот этот трюк со вторым планом я пока нигде не встречал, спасибо за пересказ. Нужно будет прочесть первоисточник целиком, похоже что там у ребят всё очень благополучно с креативным мышлением.
Воруй палитры у художников на zxart.ee. Просто любой объект у них бери объёмный, ляжка там какая-нибудь, и смотри как идут от самого тёмного цвета к самому яркому цвету.
В гигаскрине цветов больше, палитры рисовать легче.
Технически, то что тебе нужно называется не палитрой, а «color ramp». Мы привыкли плюс-минус менять яркость одного и того же цвета, поэтому у нас на спектруме выходит очень мало вариантов. А художники умеют прямо в голове, по мере тего как они меняют яркость, менять ещё и hue. Если изменения hue более-менее последовательные, выходит не хуже чем если бы мы просто меняли яркость.
Подробнее, конечно, лучше художников расспрашивать.
Спасибо за подробный рассказ! Некоторые эффекты были для меня новыми (например, интерполяцию я не встречал, и про капли я не заметил что они были из целых квадратов, на глаз казалось что сделано пикселями). Ну и в целом, всегда интересно какие технические решения были приняты и почему. Мне не понравилась палитра, поэтому отдельное спасибо за честное объяснение почему именно такая :)
Всё вместе получилось, ОК, я согласен что не восторг, но сделано крепко. Мне было интересно увидеть демо в чём-то очень олдскульное, но в чём-то ещё и с элементами ньюскула (хотя, как я сейчас понял из пояснений, фикса в ней было меньше чем мне тогда показалось). Но любое успешное «надурил» — всегда в плюс авторам и в плюс демо.
Если тебе реально нужны компиляторы Си, тебе нужно развивать другие вещи. Я бы начал с команд типа ld r,(rr+n), ld r,(rr+r), push nn (единственная стоящая команда выше, мне кажется), и всяких add rr,nn. Потому что я ещё никого не видел, кто бы сказал, что Си проще компилировать в 6502, чем в Z80. Но вообще заниматься компилятором Си сложнее, чем очень много чем другим.
Я это всё понимаю. Речь о другом. Даже если вы просто возьмёте и сделаете «Z80 на стероидах», просто с кучей однотактовых команд, ничего не меняя, это уже будет подразумевать что паттерны хорошего кода поменяются. Вот там выше aa-dav пишет про неэффективность LDIR, что зачастую правда, но только если речь идёт о скорости копирования. С точки зрения компактности кода LDIR очень эффективна, а по скорости — не более чем посредственна, так что вы не найдёте, например, декомпрессора на спектруме без LDIR. Т.е. даже медленная LDIR — очень даже пригождается.
Ваш перелопаченный Z80 потребует пересмотра вообще всех таких привычных соображений, во всяком случае с точки зрения хорошо оптимизированного кода. Поэтому невозможно вообще что-либо сказать, ни про твои доработки с сегментом регистров а-ля геймбой, ни про доработки некста. Без точной информации о скорости команд, разговор получится ни о чём.
Мне кажется, что думать в терминах конкретных инструкций бесперспективно. Потому что как выглядят большинство хотелок в обсуждениях этого типа? «Я тут пишу код и мне хотелось бы для этого иметь EX HL,HL', было бы удобнее, быстрее и компактнее». Это подразумевает, что мы берём быстрые циклы для Z80 и ищем как их ускорить. Но качественные реформы, вроде расширенного блока регистров предложенного выше, на самом деле радикально меняют весь подход к оптимизации кода. Например, мы привыкли что самая быстрая заливка на Z80 — серия команд PUSH. А на Sharp LR35902 команда PUSH занимает уже не 11, а 16 тактов, и это при том что добавлена новая 8-тактовая команда LD (HL+),A, которая по сути может залить байтами с той же скоростью что и PUSH.
То есть я о чём. Просто набор команд недостаточен, чтобы сказать, это хорошо и плохо. Нужно знать растактовки команд и смотреть как будут выглядеть решения стандартных задач. И только там станет понятно, где у нас улучшено, а где просто изменено.
Во-вторых, у меня некоторое недоумение. Уточни пожалуйста, сколько точно байт понадобится для таблицы во втором из твоих вариантов кода.
И что означает «не факт ещё, что в сумме короче»?
Но я рад любым идеям, потому что, как ты знаешь сам, приходит день и всё это обязательно пригождается, м.б. в каком-то другом виде.
github.com/restorer/zxspectrum-lo-fi-motion-2020
Большое спасибо автору! Надеюсь это поможет другим невнимательным читателям вроде меня!
В гигаскрине цветов больше, палитры рисовать легче.
Технически, то что тебе нужно называется не палитрой, а «color ramp». Мы привыкли плюс-минус менять яркость одного и того же цвета, поэтому у нас на спектруме выходит очень мало вариантов. А художники умеют прямо в голове, по мере тего как они меняют яркость, менять ещё и hue. Если изменения hue более-менее последовательные, выходит не хуже чем если бы мы просто меняли яркость.
Подробнее, конечно, лучше художников расспрашивать.
Всё вместе получилось, ОК, я согласен что не восторг, но сделано крепко. Мне было интересно увидеть демо в чём-то очень олдскульное, но в чём-то ещё и с элементами ньюскула (хотя, как я сейчас понял из пояснений, фикса в ней было меньше чем мне тогда показалось). Но любое успешное «надурил» — всегда в плюс авторам и в плюс демо.
Ваш перелопаченный Z80 потребует пересмотра вообще всех таких привычных соображений, во всяком случае с точки зрения хорошо оптимизированного кода. Поэтому невозможно вообще что-либо сказать, ни про твои доработки с сегментом регистров а-ля геймбой, ни про доработки некста. Без точной информации о скорости команд, разговор получится ни о чём.
То есть я о чём. Просто набор команд недостаточен, чтобы сказать, это хорошо и плохо. Нужно знать растактовки команд и смотреть как будут выглядеть решения стандартных задач. И только там станет понятно, где у нас улучшено, а где просто изменено.