Каких нафиг 2-3 раза, даже в теории? У меня по диагонали сейчас выходит на пиксель в среднем ~37 тактов в основном цикле. Так ведь 15 тактов нужно только чтобы поставить точку, минимум 4 на ступеньку, минимум 11 проверка ступеньки без перехода. Без учёта вспомогательных операций для группы точек. А еще на запуск накладные расходы и завершение — то единственное, что еще осталось оптимизировать, чтобы на коротких снизить потери. Что еще там можно придумать? Разве что выбирать готовые фрагменты за счёт совершенно невменяемого размера. И то сомневаюсь, что заметный выигрыш может выйти.
30% на основной процедуре может дать 15-20% разницы в итоговом fps (и на практике люди замечали столько в элите). Еще может быть смысл позаниматься быстрыми короткими процедурами (те же 13k на диагональ, как в оригинале Spectrum Expert, достижимо в разы меньшим расходом памяти).
У меня есть линия с похожими характеристиками, так что думаю я понимаю как ты её сделал. Но мне кажется, что это всё же охота на блох, в том смысле, что по-настоящему интересно будет только в том случае, если ускорить линию в 2-3 раза. С моей точки зрения ускорение на 20-30% на практике никто не заметит.
Надо было сразу спрашивать у знающих людей. :) Спрашивать надо конечно же у разрабов железа, а не у программистов. Все свои непонятки я развеял сразу же, когда увидел книжку Chris Smith. Хотя раньше и так было понятно что биты контролера перепутаны не из-за софтварной блажи. Ранее я считал что тому виной:
1. Требования legacy (это тоже так, просто это не упомянул.)
2. Недостаток логических элементов ULA или какой-то еще необходимости связанной с дизайном ULA
Мир не страдал. Мне такие адреса весьма по кайфу очень даже. Для программистов структура переставленных битов «объяснена» много-много-много лет назад и много где. Собственно, см. ZX Spectrum ROM 2AA: THE 'PIXEL ADDRESS' SUBROUTINE — там же есть получение адреса атрибутов из экранного, или публикации аж в ZX Review года так 90го. Ну и zxpress.ru рулит, там должно быть обязательно.
Кстати что твоя, что в ROM могут быть написаны более быстро, я имею в виду даже без таблиц.
Вот блин, далеко не я один это всё искал и не находил ГОДАМИ. Непонятно даже почему. Даже на английском языке.
И главное что версий было много и все годами спорили какая верная. Но ни одна верной не оказалась!
И когда уже всё знаешь — легко находятся объяснения на английском, по ключевым словам, но это когда уже знаешь что искать.
Странная фигня, ведь ВЕСЬ МИР СТРАДАЛ от этой раскладки и (имхо) её структура должна была бы быть в букварях объяснена. :D
Но по факту я вижу что её не знают люди самолично собирающие клоны спектрума.
На NES всё же сопроцессоров не было, а работа с дополнительным железом через память на NES/SNES просто потому что на семействе 6502 нет портов в принципе. Аппаратные непрограммируемые вычислялки, типа описанной в топике, на приставках и комьпютерах встречались крайне редко, навскидку вспоминается только аппаратный MUL/DIV на SNES, и до какой-то степени DSPx (программируемый, но программу нельзя менять). Более универсальные сопроцессоры делали заметно чаще, и на ZX, можно сказать, тоже был — GS/NeoGS.
ааааа, ненавижу gamedev.ru в плане поиска — просто редиректит на гугл с site:gamedev.ru и нихрена толком не ищет.
я там просто выкладывал свои сравнения для разных вариантов put_pixel и мне тогда показалось, что табличный метод не имеет решающего преимущества перед сдвигами и масками. и табличный метод именно так и реализовывался — перед таблицами внедрялась директива ассемблера выравнивания на 256 байт.
а, ладно, последние эксперименты с этим можно посмотреть тут: yadi.sk/d/XJzNIt4g3YcMsP но тут уже нет табличного метода.
Быстрое рисование отрезка, нешто забыл? Твой же код жрёт больше трёх килобайт даже без таблиц. А уже если радикально оптимизировать под короткие отрезки, как завещал Алоний, то хорошо, если всё в страницу поместится. Вопрос знаю, как раз на днях нашлись мои старые наработки, будет время, доведу до конца: zx-pk.ru/threads/11661-o-risovanii-pryamykh.html?p=986444&viewfull=1#post986444
Вывод спрайтов может обойтись в сотни лишних байтов вместе с обвязкой.
Объясни, о чем ты, в чем ошибочность, итд
в том, что минимальный размер экрана не означает экономного расходования памяти
Это не locate pixel, это locate byte, допустим для вывода спрайта.
Таблица экранных адресов выравнена в памяти на адрес кратный 256 байт и занимает 256+256=512 байт памяти, имея следующую организацию:
первые 256 байт — младшая часть адреса
вторые 256 байт — старшая часть адреса
Из каждых 256 байт важны только первые 192 байта, остальные заполнены нулями и организуют бонусом автоматический «клиппинг», т.к. вместо адреса экрана будет подставлен 0 и запись уйдет в ROM.
P.P.S.
Ну да, вспомнил, в первую очередь не нравилось как раз то, что надо потратить почти две страницы памяти и плюс еще возня с тремя битами пикселя в полоске существует. И когда я переделал на сдвиги, то время на эффект «снежка» заметно не изменилось. Хм. Ладно, вопрос видимо не такой простой.
Аааа, не туда смотрел. Странно, у меня табличная выборка была в разы более громоздкая. Надо вспомнить точно что там было, но точно помню что мне очень не понравилось…
Эммм, но что это? У меня процедура locate_pixel в разы много более громоздкая была даже с табличным основанием.
Что такое htable и почему он рассеян по всем страницам памяти?
30% на основной процедуре может дать 15-20% разницы в итоговом fps (и на практике люди замечали столько в элите). Еще может быть смысл позаниматься быстрыми короткими процедурами (те же 13k на диагональ, как в оригинале Spectrum Expert, достижимо в разы меньшим расходом памяти).
Исходники бы глянуть :)
Список https://en.wikipedia.org/wiki/List_of_Super_NES_enhancement_chips
1. Требования legacy (это тоже так, просто это не упомянул.)
2. Недостаток логических элементов ULA или какой-то еще необходимости связанной с дизайном ULA
Мир не страдал. Мне такие адреса весьма по кайфу очень даже. Для программистов структура переставленных битов «объяснена» много-много-много лет назад и много где. Собственно, см. ZX Spectrum ROM 2AA: THE 'PIXEL ADDRESS' SUBROUTINE — там же есть получение адреса атрибутов из экранного, или публикации аж в ZX Review года так 90го. Ну и zxpress.ru рулит, там должно быть обязательно.
Кстати что твоя, что в ROM могут быть написаны более быстро, я имею в виду даже без таблиц.
И главное что версий было много и все годами спорили какая верная. Но ни одна верной не оказалась!
И когда уже всё знаешь — легко находятся объяснения на английском, по ключевым словам, но это когда уже знаешь что искать.
Странная фигня, ведь ВЕСЬ МИР СТРАДАЛ от этой раскладки и (имхо) её структура должна была бы быть в букварях объяснена. :D
Но по факту я вижу что её не знают люди самолично собирающие клоны спектрума.
Lord Vader Металлолом — о строении экрана 6912 с аппаратной точки зрения.
Так что в нынешнее время нужно тщательнее искать, тщательнее!
Всё уже сделано до нас.
я там просто выкладывал свои сравнения для разных вариантов put_pixel и мне тогда показалось, что табличный метод не имеет решающего преимущества перед сдвигами и масками. и табличный метод именно так и реализовывался — перед таблицами внедрялась директива ассемблера выравнивания на 256 байт.
а, ладно, последние эксперименты с этим можно посмотреть тут: yadi.sk/d/XJzNIt4g3YcMsP но тут уже нет табличного метода.
zx-pk.ru/threads/11661-o-risovanii-pryamykh.html?p=986444&viewfull=1#post986444
Вывод спрайтов может обойтись в сотни лишних байтов вместе с обвязкой.
в том, что минимальный размер экрана не означает экономного расходования памяти
Таблица экранных адресов выравнена в памяти на адрес кратный 256 байт и занимает 256+256=512 байт памяти, имея следующую организацию:
первые 256 байт — младшая часть адреса
вторые 256 байт — старшая часть адреса
Из каждых 256 байт важны только первые 192 байта, остальные заполнены нулями и организуют бонусом автоматический «клиппинг», т.к. вместо адреса экрана будет подставлен 0 и запись уйдет в ROM.
Ну да, вспомнил, в первую очередь не нравилось как раз то, что надо потратить почти две страницы памяти и плюс еще возня с тремя битами пикселя в полоске существует. И когда я переделал на сдвиги, то время на эффект «снежка» заметно не изменилось. Хм. Ладно, вопрос видимо не такой простой.
Аааа, не туда смотрел. Странно, у меня табличная выборка была в разы более громоздкая. Надо вспомнить точно что там было, но точно помню что мне очень не понравилось…
ld l, y; 4
ld a, (hl); 7
…
Эммм, но что это? У меня процедура locate_pixel в разы много более громоздкая была даже с табличным основанием.
Что такое htable и почему он рассеян по всем страницам памяти?
Пчму? Пример сотен байтов-килобайтов?
> при ошибочном целеполагании
Объясни, о чем ты, в чем ошибочность, итд
делает значительно неудобнее
для 128k разве что (и то, лучше бы отдать экрану часть этой памяти)
при ошибочном целеполагании