P.S.
И, кстати, по своим ощущениям — когда действительно этот мой библиотечный по духу код несколько вырос и я оценил просто как он при этом набухает байтами, то мне самому показалось, что без умения выкидывать неиспользованные функции, как полагается в ЯВУ, оно больше потом будет обременять в реальных вещах, чем помогать. Для асма вроде такая оптимизация не проходит, т.к. понятие функции слишком аморфно ведь.
Вот блин, из-за того, что по дефолту стояло отображение только «интересных» топиков в настройках сайта я несколько дней не замечал что тут вообще какое то обсуждение идёт. Только вот заметил, обстоятельно прочитаю и наверное еще откомментирую завтра.
По поводу моего кода — он по сути является работой над застрявшими с детства комплексами, когда смотря на, кажется, Super Code хотел повторить тот же put_pixel, но тогда навыков асма решительно не хватало. И тут просто открыл для себя с полгода назад исходники Mighty Final Fight с полным тулчейном и решил просто глазком хотя бы глянуть как кодят по современному на спектруме, а в итоге по сути глубоко в код вдаваться не стал, но реализовал то, что не давало покоя когда то. И собственно на сейчас интерес свой к практике на спектруме я утолил, так что с одной стороны на меня тратить время смысла не имеет в плане обучения меня чему то.
Но, имхо, тут есть огромный потенциал для статьи, причём можно прямо мне и адресовать и показывать на примерах сравнивая с тем моим кодом или чем то похожим — я сам с удовольствием прочитаю.
Так ответ на вопрос то не технику какую то эффективную даёт, а просто даёт ответ почему так перемешаны биты.
Это не даёт «эффективных техник», это просто ответ почему так.
И даже непрограммист на загрузке видеозаставки очередной игры видел эту нелинейность и потому конечно тоже без всякого совершенно ассемблера понимает о чём речь. И это реально оказался вопрос очень интересный людям. Более интересный, чем видеоначинка денди в которую все в детстве играли и так далее.
На самом деле и то и другое — как и мне многим было и интересно да что же за фигня то такая и этим вопросом мучались, так и «ломали голову» как с этим работать в асме. Еще одним косвенным показателем является то, что моя статья про это на другом ресурсе о котором говорил поставила рекорд по лайкам. А это и всё те же мои статьи и здесь — и про денди, и про спектрум и про всякие микропроцессоры. И вот. Абсолютный рекордсмен среди всего этого — статья про то почему у спектрума нелинейная видеопамять. Такие дела…
Ой вот не надо, эту статью я опубликовал не только тут и три разных человека как минимум мне написали, что всю жизнь тоже «мучались», «ломали голову» почему так и что им «удалось при жизни узнать эту тайну». Число незнающих и строящих гипотезы на самом деле зашкаливает.
Вот блин, далеко не я один это всё искал и не находил ГОДАМИ. Непонятно даже почему. Даже на английском языке.
И главное что версий было много и все годами спорили какая верная. Но ни одна верной не оказалась!
И когда уже всё знаешь — легко находятся объяснения на английском, по ключевым словам, но это когда уже знаешь что искать.
Странная фигня, ведь ВЕСЬ МИР СТРАДАЛ от этой раскладки и (имхо) её структура должна была бы быть в букварях объяснена. :D
Но по факту я вижу что её не знают люди самолично собирающие клоны спектрума.
ааааа, ненавижу gamedev.ru в плане поиска — просто редиректит на гугл с site:gamedev.ru и нихрена толком не ищет.
я там просто выкладывал свои сравнения для разных вариантов put_pixel и мне тогда показалось, что табличный метод не имеет решающего преимущества перед сдвигами и масками. и табличный метод именно так и реализовывался — перед таблицами внедрялась директива ассемблера выравнивания на 256 байт.
а, ладно, последние эксперименты с этим можно посмотреть тут: yadi.sk/d/XJzNIt4g3YcMsP но тут уже нет табличного метода.
P.P.S.
Ну да, вспомнил, в первую очередь не нравилось как раз то, что надо потратить почти две страницы памяти и плюс еще возня с тремя битами пикселя в полоске существует. И когда я переделал на сдвиги, то время на эффект «снежка» заметно не изменилось. Хм. Ладно, вопрос видимо не такой простой.
Аааа, не туда смотрел. Странно, у меня табличная выборка была в разы более громоздкая. Надо вспомнить точно что там было, но точно помню что мне очень не понравилось…
Эммм, но что это? У меня процедура locate_pixel в разы много более громоздкая была даже с табличным основанием.
Что такое htable и почему он рассеян по всем страницам памяти?
«Иными словами, вычислять экранный адрес по двум координатам?»
Не только экранный адрес, но и адрес цвета. Там же просто перемешать биты определенным образом и готово и то и другое за нулевое машинное время — ни складывать ни вычитать не надо. Но есть возня с портами дольше даже, чем перемешивание бит, то… вот как раз и хотелось спросить про это.
А по мне так статьи даже дополняют друг друга — моя для тех кто вообще не знает что такое RAS/CAS, а ваша более технически полная. Так что ресурс выиграет от обеих.
Ну, дело тут не в том, что я шустрый, а в том, что вопрос меня реально интересовал и я веду колонку «блеск и нищета 8-битных компьютеров и консолей» на форуме gamedev.ru, откуда сюда многое и принёс тоже. Поэтому я не мог не написать эту статью как только получил ответ на вопрос. :) Вам следовало бы там сразу дать понять, что вы сами занялись целой статьёй — тогда я бы свою и не писал бы. Объяснение действительно более полное, так что держите плюс.
В качестве бонуса:
Глянул документацию по SjASMPlus — и интуиция не подвела. Там есть для этих оптимизационных целей ключевое слово IFUSED. Прикольно, прикольно…
И, кстати, по своим ощущениям — когда действительно этот мой библиотечный по духу код несколько вырос и я оценил просто как он при этом набухает байтами, то мне самому показалось, что без умения выкидывать неиспользованные функции, как полагается в ЯВУ, оно больше потом будет обременять в реальных вещах, чем помогать. Для асма вроде такая оптимизация не проходит, т.к. понятие функции слишком аморфно ведь.
Вот блин, из-за того, что по дефолту стояло отображение только «интересных» топиков в настройках сайта я несколько дней не замечал что тут вообще какое то обсуждение идёт. Только вот заметил, обстоятельно прочитаю и наверное еще откомментирую завтра.
По поводу моего кода — он по сути является работой над застрявшими с детства комплексами, когда смотря на, кажется, Super Code хотел повторить тот же put_pixel, но тогда навыков асма решительно не хватало. И тут просто открыл для себя с полгода назад исходники Mighty Final Fight с полным тулчейном и решил просто глазком хотя бы глянуть как кодят по современному на спектруме, а в итоге по сути глубоко в код вдаваться не стал, но реализовал то, что не давало покоя когда то. И собственно на сейчас интерес свой к практике на спектруме я утолил, так что с одной стороны на меня тратить время смысла не имеет в плане обучения меня чему то.
Но, имхо, тут есть огромный потенциал для статьи, причём можно прямо мне и адресовать и показывать на примерах сравнивая с тем моим кодом или чем то похожим — я сам с удовольствием прочитаю.
Это не даёт «эффективных техник», это просто ответ почему так.
И даже непрограммист на загрузке видеозаставки очередной игры видел эту нелинейность и потому конечно тоже без всякого совершенно ассемблера понимает о чём речь. И это реально оказался вопрос очень интересный людям. Более интересный, чем видеоначинка денди в которую все в детстве играли и так далее.
Ну а число людей с которыми я эту тему обсуждал и ранее гораздо больше. При этом не знали люди даже тут.
Ой вот не надо, эту статью я опубликовал не только тут и три разных человека как минимум мне написали, что всю жизнь тоже «мучались», «ломали голову» почему так и что им «удалось при жизни узнать эту тайну». Число незнающих и строящих гипотезы на самом деле зашкаливает.
И главное что версий было много и все годами спорили какая верная. Но ни одна верной не оказалась!
И когда уже всё знаешь — легко находятся объяснения на английском, по ключевым словам, но это когда уже знаешь что искать.
Странная фигня, ведь ВЕСЬ МИР СТРАДАЛ от этой раскладки и (имхо) её структура должна была бы быть в букварях объяснена. :D
Но по факту я вижу что её не знают люди самолично собирающие клоны спектрума.
я там просто выкладывал свои сравнения для разных вариантов put_pixel и мне тогда показалось, что табличный метод не имеет решающего преимущества перед сдвигами и масками. и табличный метод именно так и реализовывался — перед таблицами внедрялась директива ассемблера выравнивания на 256 байт.
а, ладно, последние эксперименты с этим можно посмотреть тут: yadi.sk/d/XJzNIt4g3YcMsP но тут уже нет табличного метода.
Ну да, вспомнил, в первую очередь не нравилось как раз то, что надо потратить почти две страницы памяти и плюс еще возня с тремя битами пикселя в полоске существует. И когда я переделал на сдвиги, то время на эффект «снежка» заметно не изменилось. Хм. Ладно, вопрос видимо не такой простой.
Аааа, не туда смотрел. Странно, у меня табличная выборка была в разы более громоздкая. Надо вспомнить точно что там было, но точно помню что мне очень не понравилось…
ld l, y; 4
ld a, (hl); 7
…
Эммм, но что это? У меня процедура locate_pixel в разы много более громоздкая была даже с табличным основанием.
Что такое htable и почему он рассеян по всем страницам памяти?
Не только экранный адрес, но и адрес цвета. Там же просто перемешать биты определенным образом и готово и то и другое за нулевое машинное время — ни складывать ни вычитать не надо. Но есть возня с портами дольше даже, чем перемешивание бит, то… вот как раз и хотелось спросить про это.