Электроника БК 0010-01 vs ZX.

[NEO SPECTRUMAN]

Это не чанки, это лоурез
Чанки текстурированные

да какая разница что это
и то что на картинке
на вид как раз мультиколорные чанки....


а на счет БКшечной демы
как бы интересно она не выглядела
от выбранной штриховки рябит в глазах

вот быстренько нарисовал
сравниваем 2 верхних варианта с нижним

[Advertiser]

[Manwe]

Мда. Не шибко шустро. Это на реальном БК? Даже в быстрой памяти.

Да, на реальной БК. А сколько там было на Спектруме? Напомни плиз.

Дело-то в чём:
У Z80 довольно простая системой команд, поэтому дешифратор инструкций несложный - насколько я понял, двухуровневый, его с очень большой натяжкой можно назвать "микрокодом".
А ВМ1 весь построен на микрокоде: у него внутри "RISC-процессор" архитектуры "Электроника НЦ", который "эмулирует" инструкции PDP-11 своими микропрограммами. За счёт этого потеря в производительности. Некто Ralph Johnson писал: "There were lots of different models of the PDP11. Most were implemented with microcode, each model had a different micro architecture, but they all implemented the same PDP-11 instruction set". Это в полной мере относится и к процессору БК 0010. Получается, существовали реализации без микрокода. В теории, они должны быть существенно быстрей. Если бы у БК был такой процессор - было бы супер круто.

Вторая вещь, тормозящая БК - контроллер ВП1-037, который постоянно обновляет динамическую память и раз в несколько тактов "замораживает" доступ к ОЗУ. Если центральному процессору в этот момент понадобилось считать из памяти инструкцию или данные, то ему приходится ждать. Было бы круто сделать в БК двухпортовую память - тогда ждать не пришлось бы и производительность взлетела ещё вдвое. Но это дороже.

- - - Добавлено - - -

сравниваем 2 верхних с нижней

Это всё можно, только уже не уместится в 512 байт.
А можешь нарисовать красивые чанки в 4x5 точек?
Сейчас у меня чанки генерятся программно по заданным вручную огибающим - можно изобразить любые градиенты, например:



Это добро занимает аж 284 байта (включая очистку экрана и прочие служебные вещи) и генерит чанков на 320 байт.

[NEO SPECTRUMAN]

А можешь нарисовать красивые чанки в 4x5 точек?

на счет красмвые не уверен

ну и чанки бывают разные
могут просто монохромные с каким то оттенком и с разным диапазоном яркости
а могут быть на 256 цветов с 3-мя\15-ю каналами яркости...

ну и х5 будут плохо стыковаться
или нужны разные наборы чанков для соседних "знокомест"

- - - Добавлено - - -

Это добро занимает аж 284 байта (включая очистку экрана и прочие служебные вещи) и генерит чанков на 320 байт

чота много

проще загрузить пожатые чанки в запакованом виде
ну и как привило соседние чанки друг от друга отличаются одним пикселем
(ну и это критично для LCD мониторов для которых чем меньше пикселей меняется тем лучше)

так что можно закодировать даже как
2...3 бита координата по х
2...3 бита координата по у
итого на описание 16...64 градаций чанкания уйдет 128...384 бита
25...48 байт
ну и 3 раза повторить для B, R и G

[Manwe]

чота много

Потому что универсальный алгоритм, который хранит отдельные огибающие для red, green, blue и позволяет таким образом генерить сколько угодно плавных переходов "цветов". Ну и не забывай, что процессор 16-битный, поэтому код занимает вдвое больше места, чем на ZX.

проще загрузить пожатые чанки в запакованом виде

В маленьких интрах я так и делаю. А в больших можно сгенерить 336 "цветов", тогда выгодней делать это кодом, чем хранить готовый результат (даже пожатый).

Так или иначе, чанки и лоу-рез мне всё равно не очень нравятся.

- - - Добавлено - - -

вот быстренько нарисовал

Получается, по 5 градаций на каждую составляющую r/g/b, итого 125 "цветов" - в принципе, неплохо. Разрешение экрана 64x64 чанка. Жаль, в пропорциях экрана БК эти чанки получаются не квадратными.

[NEO SPECTRUMAN]

в пропорциях экрана БК эти чанки получаются не квадратными.

если учитывать в эффекте пропорции чанка
та все равно каких они пропорций


ну и высота 5 не рациональна

получить белый можно небольшим количеством способов


но чтобы обеспечить стыкуемость чанков
нужно будет 100500 вариантов чанков для разных строк столбцев... (но в принципе этим можно значительно повысить количество цветов)

более рациоанальным было бы высота 3
как оно накладывается на вашу адресацию видео памяти?

для диагональных 4х3
с 3 мя вариантами чанка
можно выдать 1728 цветов
по 12 градаций на канал

конечно это не будет 512 байт интро
но кому нужно *****е кастрированное 512 байт интро
когда можно сделать просто интро

[Manwe]

у меня получается 8 заливок за секунду
сколько на реальном БК?

На реальном БК получилось 7,63 заливок в секунду. Это с медленной экранной памятью. Быстрая память даёт 11,1 заливок в секунду.
Результат сравним со Спектрумом, несмотря на заявления, что он в несклько раз быстрей.
Но я всё равно продолжаю настаивать, что такие синтетические тесты не дают объективного представления о производительности.

[Titus]

Ну и не забывай, что процессор 16-битный, поэтому код занимает вдвое больше места, чем на ZX.

Я думаю, что не вдвое, а в 1.5, или еще даже меньше.
Т.к. каждой командой можно сделать больше, чем на Z80.
Кроме того, далеко не все команды на Z80 однобайтные.
Так что думаю, что 1.5 или меньше.

[Manwe]

если учитывать в эффекте пропорции чанка

то эффект будет притормаживать.

но чтобы обеспечить стыкуемость чанков
нужно будет 100500 вариантов чанков для разных строк столбцов...

Скорее, для строк. У нас же 4 точки в ширину, 5 в высоту.

- - - Добавлено - - -

Я думаю, что не вдвое, а в 1.5, или еще даже меньше.
Т.к. каждой командой можно сделать больше, чем на Z80.
Кроме того, далеко не все команды на Z80 однобайтные.
Так что думаю, что 1.5 или меньше.

Демка "Mona Lisa" в 256 байт показала, что размер даже одинаковый.

[NEO SPECTRUMAN]

конечно
развновидностью горизонтальных полос можно и такой шеврон

но выглядит он на любителя...

- - - Добавлено - - -

то эффект будет притормаживать.

это смотря какой эффект
для некоторых это может быть совершенно прозрачно
просто разные коэфиценты для х и у
а выглядеть будет как на квадратных чанках...

- - - Добавлено - - -

Скорее, для строк. У нас же 4 точки в ширину, 5 в высоту.

дык выше привел картинку
что для одних надо в ширину
для других в высоту
а для третих и в ширину и в высоту...

- - - Добавлено - - -

Ну и варианты получения белого из RGB
для сравнения


как по мне диагональные полосы лучше всего

кстате когда можно выбрать палитру
черный фиолетовый голубой желтый
то можно использовать более прогрессивный вариант (выше яркость\детализация)

такой вариант имеет плохую цветопередачу "кодерских" цветов
и больше подходит для всяких фоток

- - - Добавлено - - -

вот слегка перекрасил твой градиент в CMY

[jerri]

На реальном БК получилось 7,63 заливок в секунду. Это с медленной экранной памятью. Быстрая память даёт 11,1 заливок в секунду.
Результат сравним со Спектрумом, несмотря на заявления, что он в несклько раз быстрей.
Но я всё равно продолжаю настаивать, что такие синтетические тесты не дают объективного представления о производительности.

Конечно не дают.
Тем более я выбрал медленный способ заполнения.
Нормальную скорость ты можешь увидеть в играх так то обычно 4-6кб мы за 2 фрейма освежаем. Это даёт где-то до 150кб перерисованного экрана в секунду.