Нет, это не совсем верно. Я прогнал анализ всех треков и самое большое число периодов — всего 234 ( у многих треков меньше). Поэтому вместо периода можно хранить его однобайтный номер, это сокращает каждый трек на треть. В новом формате все данные упаковались до 32кб (Exomizer).
А такой вопрос: есть ли какое-то точное описание формата в котором хранится музыка? Я понимаю, что можно прочесть плейер x86, но прочесть просто формат было бы проще. Я так понимаю что формат не должен бы был далеко уйти от примера проигрывателя на бейсике? Но хочется полной уверенности, по возможности.
Спасибо за подробный рассказ! Меня удивил этот альбом; многие из твоих биперных треков даже для спектрума звучали намного интереснее и лучше и я не мог понять, зачем тебе потребовался шаг назад (в моём понимании). Теперь я вижу, что тебя интересовала немного другая задача и немного другой фронт работ.
Сделать спектрумовский плейер для этого альбома не представляет из себя никаких сложностей. Думаешь, это могло быть кому-то интересно?
Это очень плохая ссылка, написанная человеком, который видимо не вполне разбирается в теме. И фикс им предложенный реально грязный, что собственно видно даже по его экспериментам с играми.
Оригинальная модель 48К на то и оригинальная, что никуда не опаздывает. У неё действительно прерывание происходит за 64 строки по 224 такта до начала отрисовки экрана. Можно сказать, что верхний бордер у 48К спектрума содержит 64 строки (64*224=14336 машинных тактов). На самом экране строк 192, а на нижнем бордере их ещё 56. Итого 64+192+56 = 312 строк, 312*224=69888 тактов.
128К модели воспроизвели этот расклад только приблизительно, т.к. у них другое число тактов в строке. У серого +2 например на верхнем бордере 63 строки по 228 тактов, а внизу — опять 56, т.е. всего 311 строк, 311*228=70908 тактов на кадр. В итоге верхний бордер почти такой же как на 48К (63*228=14364 тактов, на 28 тактов больше).
А вот на отечественных клонах этот промежуток времени от прерывания до начала отрисовки экрана не выдерживался даже приблизительно. Самый вопиющий пример — Ленинград, у которого кадровое прерывание приходило сразу после отрисовки самой нижней строки экрана, т.е. на Ленинграде нижнего бордера по сути не было вообще, только верхний. На Пентагоне на верхнем бордере фактически 80 строк по 224 такта, т.е. 80*224=17920 тактов, зато на нижнем бордере строк всего 48. В итоге нетривиально рассчитанные эффекты, типа мультиколорного скролла описанного выше Денисом, приходится по сути рассчитывать индивидуально для каждого из клонов.
Оптимизация не делается ради оптимизации. Да, таблица работает быстрее умножения на константу, но выполнять это умножение Денису нужно раз за фрейм (даже и раз за два фрейма, если уж совсем точно). Т.е. мы тратим лишнюю сотню тактов на фрейм, 100/70000 — это меньше 0.2% общего времени. Думаю, что у Дениса были более эффективные способы потратить 256 байт на ускорение программы.
Про мультиколор 8х1 ты немного отстал: Gasman в Ultraviolet сделал 8х1 мультиколор на 22 знакоместа шириной. Но вообще, очень здорово, что ты написал такую заметку, мало кто понимает как планируется кадр для мультиколорного рендера. А ты объяснил всё очень просто и понятно, может быть это поможет кому-то ещё сделать другие игры и демки с мультиколором, да и не только.
Я не считал свою преамбулу отдельно. Я меряю просто среднюю скорость отрисовки линий фиксированной длины. Сейчас у меня в среднем 504 такта на линию из 5 точек, 983 такта на линию из 15 точек, 1703 такта на линию из 30 точек.
Пробежался бездумно по памяти и увидел :)
Короче, интересная идея. Скорее всего я пущу её в ход. Но хочется большего. Хочется линию в 2 раза быстрее, например. Вот это будет заметно.
Кроме того, забыл написать про оптимизацию преамбулы. Да, алон прав, в большинстве случаев преамбула оптимизирована неважно. Но, если честно, сделать оптимизацию преамбулы несложно, просто уже потому, что там нечего особенно оптимизировать. Ну да, на коротких линиях это важно и коротких линий обычно большинство. Поэтому мне понятен посыл, но не очень понятно что там по этому поводу можно обсуждать — у всех кто ставит перед собой такую задачу, преамбула эффективна.
Посмотрел твой код. Да, идея развести Брезенхема в 2 независимые ветки прикольная, но непрактичная, с моей точки зрения. Жизненные реалии для меня выглядят так: если пишешь 128К демо, очень желательно иметь весь код для выкладки в экран ниже 49152 (чтобы можно было пользоваться теневым экраном). При этом, если хочется поддержать классические спектрумы, крайне нежелательно класть код ниже 32768. У тебя грубо говоря есть 16К под код; на самом деле меньше, потому что есть такие вещи как резидентное ядро, и всякие данные, и, разумеется, код для чего-то ещё кроме рисования линий. Стандартная быстрая линия, как у Рейдера, или из Эксперта, занимает около 5кб. Думаю, что за пределы 7-8 килобайт выходить нельзя, если хочется реально практичных решений.
Твоё предложение фактически удваивает размер кода за 4 такта на точку. 4 такта — это из цикла где в лучшем случае тратится 26 тактов на итерации (на самом деле, в среднем тратится больше). 4/26 — это даже не 20% выигрыша. Думаю что DDA оправдать будет проще, потому что табличное деление можно втиснуть примерно в 100-150 тактов, и это выиграет относительно стандартного подхода для (100-150)/4 ~ 25-40 точек, т.е. для достаточно длинных линий.
Конкретно в деталях, ты там явно расписал не только Брезенхема в 2 ветки, ты также расписал и что-то другое. Мне было лень разбираться в подробностях, но процедура рисования линий длиной более 16К — это просто даже уже не очень и смешно.
Elite вышла на спектруме в конце 1985 года — обзоры в журналах датированы ноябрём или декабрём. Для сравнения, обзоры на Starion вышли в мае-июне, когда спектрумовская элита хорошо ещё если уже планировалась.
Я сейчас не помню кто первым изобрёл копирование буфера в экран стеком. Но точно помню что это было раньше, что-то типа 1985 или 1986; думаю к 1989, которых не клали в экран стеком, просто уже увольняли по профнепригодности :)
@tsl, походу в этом треде жгут вообще поголовно все!
Пояснение для некодеров: DAA — это команда для коррекции нормальной арифметики в применении к числам в BCD представлении. Неважно, что это заклинание означает, но важно понимать, что это странная команда для немного странной вещи, узкоспециализированная. Всякий раз когда кодер придумывает какое-то применение для DAA вне BCD чисел, все остальные кодеры сбегаются в восхищении, чтобы выразить своё почтение и внести изобретателя на руках на Олимп.
Если ты всерьёз сейчас расскажешь, как применить DAA для ускорения вычисления адресов в экране спектрума, у тебя добавится много новых поклонников.
Но вообще чем больше ты будешь писать под меня или под кого-то ещё, тем, мне кажется, выйдет неинтереснее. Интересно как лично ты видишь программирование на спектруме. Вот Flying сел писать такую заметку и у него вышел рассказ про библиотеку менеджмента памяти. Он ведь много что накодил, а болел получается именно этим. Вот интереснее всего и выходит когда рассказывают о том, что наболевшее в каком-то смысле.
Саша, возможно ты не заметил, но там этого не написано :) Да, там поясняется формат данных под чанки под «леймов», но там и сам текст назван шит, и вообще очень много ни к чему конкретному не привязанной бравады.
Т.е. я не знаю, м.б. Exploder и очень сложный и даже неприятный человек, я же не знаю. Но на основании одного предложения в заметке примерно на пару кб текста, в основном на ассемблере, тебе не кажется, что ты немного скоропалительно приходишь к выводам?
Ну просто я вот не люблю понты впустую. Lethargeek выложил график своей новой линии. ОК, мне это интересно, я тоже иногда занимаюсь своей линией. Но график как он есть — это он выложил чисто подразниться. Я написал что думаю про его график. А он рисуется, наверное, думает, что его будут упрашивать.
Ты прав в одном, я никогда не буду работать в команде с Lethargeek. А он, наверное, примерно так же никогда не стал бы работать со мной. Потому что команда — это не просто несколько человек с интересом на похожие темы. Это ещё и… назовём это «совместимостью».
Сделать спектрумовский плейер для этого альбома не представляет из себя никаких сложностей. Думаешь, это могло быть кому-то интересно?
Оригинальная модель 48К на то и оригинальная, что никуда не опаздывает. У неё действительно прерывание происходит за 64 строки по 224 такта до начала отрисовки экрана. Можно сказать, что верхний бордер у 48К спектрума содержит 64 строки (64*224=14336 машинных тактов). На самом экране строк 192, а на нижнем бордере их ещё 56. Итого 64+192+56 = 312 строк, 312*224=69888 тактов.
128К модели воспроизвели этот расклад только приблизительно, т.к. у них другое число тактов в строке. У серого +2 например на верхнем бордере 63 строки по 228 тактов, а внизу — опять 56, т.е. всего 311 строк, 311*228=70908 тактов на кадр. В итоге верхний бордер почти такой же как на 48К (63*228=14364 тактов, на 28 тактов больше).
А вот на отечественных клонах этот промежуток времени от прерывания до начала отрисовки экрана не выдерживался даже приблизительно. Самый вопиющий пример — Ленинград, у которого кадровое прерывание приходило сразу после отрисовки самой нижней строки экрана, т.е. на Ленинграде нижнего бордера по сути не было вообще, только верхний. На Пентагоне на верхнем бордере фактически 80 строк по 224 такта, т.е. 80*224=17920 тактов, зато на нижнем бордере строк всего 48. В итоге нетривиально рассчитанные эффекты, типа мультиколорного скролла описанного выше Денисом, приходится по сути рассчитывать индивидуально для каждого из клонов.
Про мультиколор 8х1 ты немного отстал: Gasman в Ultraviolet сделал 8х1 мультиколор на 22 знакоместа шириной. Но вообще, очень здорово, что ты написал такую заметку, мало кто понимает как планируется кадр для мультиколорного рендера. А ты объяснил всё очень просто и понятно, может быть это поможет кому-то ещё сделать другие игры и демки с мультиколором, да и не только.
Короче, интересная идея. Скорее всего я пущу её в ход. Но хочется большего. Хочется линию в 2 раза быстрее, например. Вот это будет заметно.
Твоё предложение фактически удваивает размер кода за 4 такта на точку. 4 такта — это из цикла где в лучшем случае тратится 26 тактов на итерации (на самом деле, в среднем тратится больше). 4/26 — это даже не 20% выигрыша. Думаю что DDA оправдать будет проще, потому что табличное деление можно втиснуть примерно в 100-150 тактов, и это выиграет относительно стандартного подхода для (100-150)/4 ~ 25-40 точек, т.е. для достаточно длинных линий.
Конкретно в деталях, ты там явно расписал не только Брезенхема в 2 ветки, ты также расписал и что-то другое. Мне было лень разбираться в подробностях, но процедура рисования линий длиной более 16К — это просто даже уже не очень и смешно.
Вот цитата из его интервью: «This was a bit of a breakthrough at the time. The key to it was some very efficient code for copying the 4K of active screen area (256x128) during the screen refresh. I had to draw each frame in a separate block of RAM (4K) and then copy it across to the graphics area when the machine had finished drawing that part of the screen to the CRT. So I wrote a routine treated the screen memory like a stack, using every register of the CPU (including the alternates), pushing and popping 16 bytes at a time.»
Пояснение для некодеров: DAA — это команда для коррекции нормальной арифметики в применении к числам в BCD представлении. Неважно, что это заклинание означает, но важно понимать, что это странная команда для немного странной вещи, узкоспециализированная. Всякий раз когда кодер придумывает какое-то применение для DAA вне BCD чисел, все остальные кодеры сбегаются в восхищении, чтобы выразить своё почтение и внести изобретателя на руках на Олимп.
Если ты всерьёз сейчас расскажешь, как применить DAA для ускорения вычисления адресов в экране спектрума, у тебя добавится много новых поклонников.
Вот заметка Flying, которая меня в своё время удивила: zxpress.ru/article.php?id=3614
Про Robus у меня не так много очевидных ссылок; ну вот можно например глянуть прямо у нас на Хайпе: hype.retroscene.org/blog/demo/830.html
Но вообще чем больше ты будешь писать под меня или под кого-то ещё, тем, мне кажется, выйдет неинтереснее. Интересно как лично ты видишь программирование на спектруме. Вот Flying сел писать такую заметку и у него вышел рассказ про библиотеку менеджмента памяти. Он ведь много что накодил, а болел получается именно этим. Вот интереснее всего и выходит когда рассказывают о том, что наболевшее в каком-то смысле.
Т.е. я не знаю, м.б. Exploder и очень сложный и даже неприятный человек, я же не знаю. Но на основании одного предложения в заметке примерно на пару кб текста, в основном на ассемблере, тебе не кажется, что ты немного скоропалительно приходишь к выводам?
Ты прав в одном, я никогда не буду работать в команде с Lethargeek. А он, наверное, примерно так же никогда не стал бы работать со мной. Потому что команда — это не просто несколько человек с интересом на похожие темы. Это ещё и… назовём это «совместимостью».