На самом деле и то и другое — как и мне многим было и интересно да что же за фигня то такая и этим вопросом мучались, так и «ломали голову» как с этим работать в асме. Еще одним косвенным показателем является то, что моя статья про это на другом ресурсе о котором говорил поставила рекорд по лайкам. А это и всё те же мои статьи и здесь — и про денди, и про спектрум и про всякие микропроцессоры. И вот. Абсолютный рекордсмен среди всего этого — статья про то почему у спектрума нелинейная видеопамять. Такие дела…

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

Так. Разговор имеет тенденцию уходит в недосказанное, в непонятно что. А причиной тому то ни я до конца не высказываю мысли, ни ты. Ты там у себя в мыслях, насколько я понял имеешь в виду конкретную вот эту мысль, про расход памяти и минимальный размер экрана. Это да, всё верно. Сама мысль верна.

Мы, может, не поняли друг друга? Что именно названо «страданием»? Страдание при реализации или страдание от незнания окончательной правды? Похоже что в моем случае первое, а в твоем случае последнее, хотя дела обстоят, конечно, не столь трагично. Люди просто не знали этого 100% точно и всё.

P.S.
Ну а число людей с которыми я эту тему обсуждал и ранее гораздо больше. При этом не знали люди даже тут.

«Мир не страдал.»

Ой вот не надо, эту статью я опубликовал не только тут и три разных человека как минимум мне написали, что всю жизнь тоже «мучались», «ломали голову» почему так и что им «удалось при жизни узнать эту тайну». Число незнающих и строящих гипотезы на самом деле зашкаливает.

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

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

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

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

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

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

Господи, сколько понтов. Было бы ещё чем делиться.

	set 7,(hl) : dec c : ret z
	sub d : jp nc,HD_L0P6
	add e : inc h

Если делать с ловушкой, можно выкинуть 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, достижимо в разы меньшим расходом памяти).

У меня есть линия с похожими характеристиками, так что думаю я понимаю как ты её сделал. Но мне кажется, что это всё же охота на блох, в том смысле, что по-настоящему интересно будет только в том случае, если ускорить линию в 2-3 раза. С моей точки зрения ускорение на 20-30% на практике никто не заметит.

Отблагодарил человека!
Исходники бы глянуть :)

Всё так, всё так.
Список https://en.wikipedia.org/wiki/List_of_Super_NES_enhancement_chips

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

Тогда объясняй.

Надо было сразу спрашивать у знающих людей. :) Спрашивать надо конечно же у разрабов железа, а не у программистов. Все свои непонятки я развеял сразу же, когда увидел книжку Chris Smith. Хотя раньше и так было понятно что биты контролера перепутаны не из-за софтварной блажи. Ранее я считал что тому виной:

1. Требования legacy (это тоже так, просто это не упомянул.)
2. Недостаток логических элементов ULA или какой-то еще необходимости связанной с дизайном ULA

Мир не страдал. Мне такие адреса весьма по кайфу очень даже. Для программистов структура переставленных битов «объяснена» много-много-много лет назад и много где. Собственно, см. ZX Spectrum ROM 2AA: THE 'PIXEL ADDRESS' SUBROUTINE — там же есть получение адреса атрибутов из экранного, или публикации аж в ZX Review года так 90го. Ну и zxpress.ru рулит, там должно быть обязательно.
Кстати что твоя, что в ROM могут быть написаны более быстро, я имею в виду даже без таблиц.

Вот блин, далеко не я один это всё искал и не находил ГОДАМИ. Непонятно даже почему. Даже на английском языке.
И главное что версий было много и все годами спорили какая верная. Но ни одна верной не оказалась!
И когда уже всё знаешь — легко находятся объяснения на английском, по ключевым словам, но это когда уже знаешь что искать.
Странная фигня, ведь ВЕСЬ МИР СТРАДАЛ от этой раскладки и (имхо) её структура должна была бы быть в букварях объяснена. :D
Но по факту я вижу что её не знают люди самолично собирающие клоны спектрума.

Как принято выражаться, (c) «Я просто оставлю это здесь»
Lord Vader Металлолом — о строении экрана 6912 с аппаратной точки зрения.
Так что в нынешнее время нужно тщательнее искать, тщательнее!
Всё уже сделано до нас.

На NES всё же сопроцессоров не было, а работа с дополнительным железом через память на NES/SNES просто потому что на семействе 6502 нет портов в принципе. Аппаратные непрограммируемые вычислялки, типа описанной в топике, на приставках и комьпютерах встречались крайне редко, навскидку вспоминается только аппаратный MUL/DIV на SNES, и до какой-то степени DSPx (программируемый, но программу нельзя менять). Более универсальные сопроцессоры делали заметно чаще, и на ZX, можно сказать, тоже был — GS/NeoGS.

ааааа, ненавижу gamedev.ru в плане поиска — просто редиректит на гугл с site:gamedev.ru и нихрена толком не ищет.
я там просто выкладывал свои сравнения для разных вариантов put_pixel и мне тогда показалось, что табличный метод не имеет решающего преимущества перед сдвигами и масками. и табличный метод именно так и реализовывался — перед таблицами внедрялась директива ассемблера выравнивания на 256 байт.
а, ладно, последние эксперименты с этим можно посмотреть тут: yadi.sk/d/XJzNIt4g3YcMsP но тут уже нет табличного метода.