я конкретно прицепился к «требованиям software» (когда там скорей hardware+firmware+management) и «замечательной работе инженеров» (что читается как безусловное одобрение, а на самом деле вопросы есть)

Если делать с ловушкой, можно выкинуть dec c: ret z (на коротких линиях это довольно плохая идея)

и так можно, для хвоста отдельный лучше кусок (а на вертикали и не был нужен)

Если делать DDA вместо Брезенхэма, можно выкинуть одну из sub d / add e, но придётся делить в преамбуле.

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

Дело в том, в реальной жизни никогда нет 16К на процедуру рисования линии. И даже 8К обычно тоже нет на самом деле. А на масштабе 3-5К примерно одно и то же и выходит.

ничего не понял, почему нет, почему одно и то же, в каких масштабах…

Сидят те, кто не может сделать лучше, или не хочет. А кто смог — не делятся исходниками))

Каких нафиг 2-3 раза, даже в теории? У меня по диагонали сейчас выходит на пиксель в среднем ~37 тактов в основном цикле. Так ведь 15 тактов нужно только чтобы поставить точку, минимум 4 на ступеньку, минимум 11 проверка ступеньки без перехода. Без учёта вспомогательных операций для группы точек. А еще на запуск накладные расходы и завершение — то единственное, что еще осталось оптимизировать, чтобы на коротких снизить потери. Что еще там можно придумать? Разве что выбирать готовые фрагменты за счёт совершенно невменяемого размера. И то сомневаюсь, что заметный выигрыш может выйти.

30% на основной процедуре может дать 15-20% разницы в итоговом fps (и на практике люди замечали столько в элите). Еще может быть смысл позаниматься быстрыми короткими процедурами (те же 13k на диагональ, как в оригинале Spectrum Expert, достижимо в разы меньшим расходом памяти).

отсюда: hype.retroscene.org/blog/889.html#comment23545

Пример сотен байтов-килобайтов?

Быстрое рисование отрезка, нешто забыл? Твой же код жрёт больше трёх килобайт даже без таблиц. А уже если радикально оптимизировать под короткие отрезки, как завещал Алоний, то хорошо, если всё в страницу поместится. Вопрос знаю, как раз на днях нашлись мои старые наработки, будет время, доведу до конца:
zx-pk.ru/threads/11661-o-risovanii-pryamykh.html?p=986444&viewfull=1#post986444
Вывод спрайтов может обойтись в сотни лишних байтов вместе с обвязкой.

Объясни, о чем ты, в чем ошибочность, итд

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

не квадратном

down_hl, как раз, занимает всего лишь 4 такта при правильной готовке. И выполняется так с вероятностью 7/8

и с высокой вероятностью занимает уже сотни байтов, если не килобайтов

Это не делает его удобнее или быстрее чем при постолбцовой раскладке

делает значительно неудобнее

но ситуация не так уж и печальна.

для 128k разве что (и то, лучше бы отдать экрану часть этой памяти)

Скажем так, для столь мелкого экрана как 6144 байта это всё же чудесное решение.

при ошибочном целеполагании

1) на z80 возня с портами неудобна, медленна и, как следствие, обычно невыгодна
2) даже если был бы небольшой выигрыш, всё равно адрес по координатам объекта (спрайта, конца отрезка) вычисляется однократно, и в % от всего объекта будет уж совсем незначительным
3) не решает основную проблему нелинейной раскладки — медленный и неудобный down_hl, который нужен многократно на весь объект
4) в оригинальной юле, насколько помню, места не осталось уже совсем; добавлять вторую = удорожать комп; а если уж удорожать, то не для такой ерунды, а чего-нибудь намного полезнее (например, автоматического пересчета удобного логического адреса произвольного окна в неудобный физический адрес экрана, не отказываясь от экономии памяти)

да и вообще нехрен спрайтики выводить продуктами такой серьёзной компании ))

ты не понял, мб и «самым приятным образом» для 6.75k, но не для любого 32x192
и software «в узком смысле» (пзу васика) порой тоже может попортить крови

вот такая вот суровая осень))

Но сама аранжировка бит, такая, а не иначе – задана требования software.

Нисагласин. Насколько помню, сделать лучшую «орионовектороподобную» раскладку с соблюдением требований page mode было реально. Но размером 8k вместо 6.75k. Однако минимизация размера видеопамяти это всё-таки не «требование software». Для эффективного software, напротив, в итоге даже вероятнее экономия — не нужны становятся таблицы и код компактнее.

Замечательная работа инженеров!

Или замечательная недоработка (инженеров, или же начальства, или всех вместе) :P

осень! осень! моар тем про нелинейную раскладку видеопамяти! 8)

у комода нету красного цвета 8)

можно сделать больше строк или атрибуты 8x4
про скроллинг лдиром лучше вообще забыть)))

Наиболее далека от истины третья версия, наиболее близка — первая. Только «дешёвый и доступный компонент» не одной видеосистемы, а всего компа целиком — дешёвая медленная память, читать которую юла успевала с минимальным торможением процессора только в спецрежиме page mode, для чего в адресах пиксельной линии и соответствующего атрибута должны были совпадать семь бит минимум (в спектруме совпадает восемь). Да еще и размер видеопамяти экономили (напомню, спектрум начался с модели 16k). Хотя в 8k вполне можно было уложить вектороподобную раскладку для page mode read (могла, правда, усложниться схема регенерации).

Повезло тебе. А я в TES сперва нарвался на Баггерфол))

отклоняешься, там на первом месте как раз bandwidth, далее — второстепенное дополнение

Всё же термин «плотность кода» относится к размеру довольно крупных осмысленных фрагментов, а не размеру опкодов отдельных команд; первое со вторым необязательно сильно связано, и необязательно однозначно положительно во всех случаях. Thumb понадобился не для уменьшения статического размера кода (для чего эффективнее программные методы), а в основном, действительно, во избежание двукратной потери скорости на 16-битной шине, весьма распространённой в нише встроек и мобилок (особенно в те года). Вот для Thumb-2 уже соображения экономии размера кэша играли роль.