Мне кажется, что думать в терминах конкретных инструкций бесперспективно. Потому что как выглядят большинство хотелок в обсуждениях этого типа? «Я тут пишу код и мне хотелось бы для этого иметь EX HL,HL', было бы удобнее, быстрее и компактнее». Это подразумевает, что мы берём быстрые циклы для Z80 и ищем как их ускорить. Но качественные реформы, вроде расширенного блока регистров предложенного выше, на самом деле радикально меняют весь подход к оптимизации кода. Например, мы привыкли что самая быстрая заливка на Z80 — серия команд PUSH. А на Sharp LR35902 команда PUSH занимает уже не 11, а 16 тактов, и это при том что добавлена новая 8-тактовая команда LD (HL+),A, которая по сути может залить байтами с той же скоростью что и PUSH.
То есть я о чём. Просто набор команд недостаточен, чтобы сказать, это хорошо и плохо. Нужно знать растактовки команд и смотреть как будут выглядеть решения стандартных задач. И только там станет понятно, где у нас улучшено, а где просто изменено.
И сразу вопрос — «с занесением в стек информации для очистки в следующем фрейме» — что именно тут подразумевается? Т.е. вопрос вот в чём, что лежит под спрайтом вроде легче выяснить при выводе статических объектов. Но у тебя это разнесено. Т.е. ты либо должен восстанавливать, что у тебя под спрайтом ещё раз, либо сохранять экранные данные, либо?
Подавляющее большинство игрушек не умеют делать vsync. Подавляющее большинство игрушек обновляют экран раз в 3 фрейма или даже медленнее (offscreen buffer — одна из важных причин этого). Подавляющее большинство игрушек shipped с артефактами изображения. Мне продолжать?
Это очень хороший анекдот. Непонимание раскладки ULA — натурально, бич начинающих кодеров. Она действительно не всегда удобна, но думаю многие со мной согласятся, что с опытом приходит понимание, что она намного эффективнее линейной раскладки.
Илья, я вот думал, как написать на Хайпе про короновирус так, чтобы не было ощущения, что ничего не происходит, но и ещё чтобы не было ощущения, что мы о чём-то другом на самом деле. Очень точное у тебя попадание в правильную тему, спасибо.
Макс, прошу не воспринимать в штыки, но я реально не понимаю зачем это всё? Зачем треки называть музыкальными альбомами? Зачем посредственные демы класть с подробным видео, так что дистрибутив занимает больше места, чем топ-10 Pouet за все времена?
И проговариваю, потому что без проговаривания всё время начинается фигня. Я не хочу чтобы ты делал то, что я хочу. Делай что хочешь, это твоё право, разумеется. Но пожалуйста, объясни пожалуйста, зачем это и кому это нужно. Потому что сейчас я вижу безумие, а метода не вижу. И подозреваю что я такой не один.
Андрей, ну в общем конечно понятно, что Денис тебя провоцирует, и что сознательное смешивание маринования с внеконкурсом — как бы аргумент дохлый. Но, тем не менее, ответ немного странный. Поясни пожалуйста, из каких примерно соображений внеконкурсная работа может попасть в Tiny MP3? Потому что у меня в голове не укладывается. ОК, кто-то может захотеть хакнуть правила и заслать вне конкурса нечто неудобоваримое, что не вписывается в демокомпо? Но почему тогда не бороться с этом преселектом? Совсем чётко: какой вообще может быть резон держать внеконкурсные работы вот прямо настолько второсортными?
Ты не думал о рисовании 2х точек за каждый тест? Линию Ву обычно рисуют от центральной точки и сразу в 2х направлениях. Как думаешь, можно с двумя наборами регистров сделать это эффективно?
DDP даст -4 такта на точку, примерно как твой старый трюк, но без удвоения памяти.
Но чтобы это было выгодно на линиях хотя бы средней длины, нужно уложить вычисление коэффициента DDP в <100 тактов.
По сути, ты ускорил не длинную линию а короткую. У меня короткая линия до 30 пикселов обгоняет линию эксперта, а с этим трюком можно наверное и до 35-40 дотянуть.
Эх, это не та табличка! :) Я не потерял надежды сделать таблицу для DDP по данным dx и dy.
Ну т.е. конечно в компактном случае повеселее, и сама возможность гнать сразу две точки…
Ммм..., это конечно далеко от того, где я думал, но тоже довольно сексуально выглядит.
Извини, пропустил вопрос. На твой вопрос нет простого ответа. pt3 разрабатывался чтобы быть достаточно компактным сам по себе, но вряд ли кто-то специально думал о том, как он будет компрессироваться. С другой стороны, я не знаю других форматов с эквивалентными возможностями, чтобы можно бы было хотя бы сконвертировать пачку файлов в конкурирующий формат и посмотреть, будет ли он лучше жаться.
Ограничения на размер файлов есть почти у всех спектрумовских пакеров. Как ты собираешься распаковывать файлы больше 64К на машине с адресным пространством в 64К и реально доступной памятью в 48К?
То есть я о чём. Просто набор команд недостаточен, чтобы сказать, это хорошо и плохо. Нужно знать растактовки команд и смотреть как будут выглядеть решения стандартных задач. И только там станет понятно, где у нас улучшено, а где просто изменено.
И проговариваю, потому что без проговаривания всё время начинается фигня. Я не хочу чтобы ты делал то, что я хочу. Делай что хочешь, это твоё право, разумеется. Но пожалуйста, объясни пожалуйста, зачем это и кому это нужно. Потому что сейчас я вижу безумие, а метода не вижу. И подозреваю что я такой не один.
Но чтобы это было выгодно на линиях хотя бы средней длины, нужно уложить вычисление коэффициента DDP в <100 тактов.
Ну т.е. конечно в компактном случае повеселее, и сама возможность гнать сразу две точки…
Ммм..., это конечно далеко от того, где я думал, но тоже довольно сексуально выглядит.
Ограничения на размер файлов есть почти у всех спектрумовских пакеров. Как ты собираешься распаковывать файлы больше 64К на машине с адресным пространством в 64К и реально доступной памятью в 48К?