80 символов в строке и режим 512 точек вообще

[ivagor]

Моск приблизился к точке кипения, стала проскакивать тупая копипаста, но почти букву еще выгрыз

[Advertiser]

[svofski]

ivagor, спасибо! у меня тоже моск выкипел честно говоря. При беглом просмотре вижу, что у тебя примерно что и у меня в последних изменениях -- ты сделал вторую половинку в обратную сторону (чтобы делать dcr на второй странице) и креативное используешь bc в некоторых сдвигах. Попробую разобраться когда немножко остужу моск.

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

А bc/de/hl ты переставил чтобы pchl использовать?

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

А, вижу, ты битмапы развернул хитро.

[svofski]

ivagor, взял твою версию, пожульничал с ней -- 128 символов, четыре развертки, плюс убрал вычисление терминальной строки на каждый символ. Получилось 53 символа, почти 54 без самой тютельки. В первом сообщении обновил ссылку.

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

Получается в шрифте РДС на один символ 2560 / 256 = 10 байт, вполне нормально, даже с запасом на надстрочные и подстрочные "закорючки"... Надо посмотреть исходники РДС, как там символы кодируются.

Это да.. в смысле, что хранить так нормально, но для быстрого рисования это компромисс.

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

Upd: выстрадал тютельку, полных 54.

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

А если столбцами? Там можно кое-что выгадать, я думаю.

Особенно если рисовать, как делает Manwe, побитовыми столбцами.

Что такое побитовые столбцы? Тут в принципе и так столбцами, но не обязательно организованными наилучшим образом. Одна из проблем в том, что ширина текстовых колонок, если их 80 конечно, не кратна байтам.

[Sandro]

Что такое побитовые столбцы? Тут в принципе и так столбцами, но не обязательно организованными наилучшим образом. Одна из проблем в том, что ширина текстовых колонок, если их 80 конечно, не кратна байтам.

Побитовые столбцы и есть побитовые столбцы.
Так именно проблема некратности байтам и решается. Символ выводится однобитовыми столбцами. То есть, маска бита на весь столбец фиксирована, м идём сверху вниз, сдвигая изображение стобца и по переносу определяя, закрашивать писель или нет. Т.е. символ хранится не горизонтально, а вертикально нарезанный. Выходит унифицированный код вместо зоопарка со сдвигом на 0/2/4/6 пикселя.

[KTSerg]

Побитовые столбцы и есть побитовые столбцы.
Так именно проблема некратности байтам и решается. Символ выводится однобитовыми столбцами. ...

Получится значительно больше операций с памятью, а они медленные.
Или при горизонтальном выводе тоже каждый пиксель отдельно на экран выводится?
Подозреваю, что байт читается, дополняется текущей маской и сохраняется в экран. При высоте символа 8 пикселей, выходит в лучшем случае 16 чтений, 16 записей, в худшем 32/32. Если каждый пиксель выводить отдельно, то всегда 48 чтений, 48 записей.

[Sandro]

Получится значительно больше операций с памятью, а они медленные.

А сдвиги -- они быстрые? Ведь при горизонтальном выводе пиксели надо ещё и сдвигать. 16-разрядным сдвигом, поскольку они могут заехать в соседний байт. В худшем случае -- сдвигать на 4 бита. 32 16-разрядных сдвига. А так всего 48, по разу на пиксель, чтобы достать очередной бит.

Хотя, разумеется, можно завести таблицу на 512 байт и вращать через неё.

[svofski]

Побитовые столбцы и есть побитовые столбцы.
Так именно проблема некратности байтам и решается. Символ выводится однобитовыми столбцами. То есть, маска бита на весь столбец фиксирована, м идём сверху вниз, сдвигая изображение стобца и по переносу определяя, закрашивать писель или нет. Т.е. символ хранится не горизонтально, а вертикально нарезанный. Выходит унифицированный код вместо зоопарка со сдвигом на 0/2/4/6 пикселя.

Получается, что по одному пикселю за шаг мы закрашиваем? Это может быть удобно/интересно для компактного хранения, но точно не для быстрого рисования. Как упражнение можно будет попробовать, даром что фонт в моем примере изначально как раз лежит на боку.

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

Немного капитанства. В рамках выбранного подхода осталось разве что добавить оставшиеся промежуточные предсдвиги (увеличить память под предсдвинутый фонт вдвое). Дальше уже только за счет стека. Там полный предсвдиг, а для x_6 и x_7 даже по 2 байта на строку, чтобы убрать "лишние" логические операции. Если не запрещать прерывания, то придется добавить по 2 байта между символами. Вычисление адреса буквы опять замедлится, рисование ускорится. "Нет худа без добра, сказала лиса, зато ты сможешь разместить предсдвинутые фонты в квазе". Смысл стековый вариант имеет, если выводить символы группами, один раз сохраняем sp, выводим группу (без вызовов процедур, только переходы), восстанавливаем sp.

Предсдвиги здорово помогли для тех случаев, где было четыре и три сдвига. В текущем варианте третий предсдвиг дал очень мало. Для спорта тут все способы хороши, но для практики я думаю достаточно двух.

Со стеком я не очень понимаю как тут выгадаешь. Потому что ldax inr ldax inr -- это 32 такта, а pop mov mov -- это 28, 4*16 = 64 такта. Ухуху. Но на подготовку и восстановление затраты отнимут 60 тактов (если память не изменяет, может быть и хуже). 4 такта в лучшем случае, проще выпилить xchg там, где он остался от лени. Выгоду можно получить только если вынести подготовку-восстановление за скобку на все рисование строки, но тогда это совсем жесть и даже бенчмарк непонятно как тогда делать.