Такое ощущение, что тут речь не про спрайты как они преимущественно понимаются — массив имеющих независимые координаты объектов на экране где мы выбираем какие тайлы в спрайтах отображаются, но их количество как правило не покрывает все пиксели экрана и главное что они все могут быть выведены хоть в одну координату оставив остальной экран пустой. Тут же больше похоже что речь про тайловые фоны — квадратно-гнездовые сетки из тайлов иногда аппаратно скроллируемые, но как одно целое. Они по определению всегда покрывают весь экран и образуют квадратно-гнездовую сетку. В последнем случае становится понятно почему нужно попиксельно возится со скроллингом «спрайтов» в памяти спрайтов. Но даже если и так, то всё-равно не очень понятно что тут 8-битные процессоры не вывозили — если выводом такой графики заведует отдельная микросхема то они хотя бы небольшое количество тайлов и не вижу куда бы тут танчики не влезли — подвижных там не очень много… Не кажется чем то сверхъестественным.
т.е. стандартно мы бы накладывали поверх спрайт скажем с травой, спрайт с дорогой, поверх которой накладывался бы «танчик». Т.е. все три спрайта находятся в своих пространствах по одной координате X,Y. Но маскируются друг другом с приоритетом по каналу. Канал 1 перекрывает канал 2, канал 2 перекрывает канал 3, пиксель с цветом «прозрачный» может вылезти на канал 1 из любого канала. Наверное я все еще сильней запутал, но смысл очень простой. Есть три экрана спрайтов заданных байтом 32х24 знакоместа. Это три независимых плана, которые контроллер объединяет в один видимый на экране монитора. Спрайты находятся в своих областях ОЗУ как объекты 32х32х256. Прозрачный цвет не маскируется (допустим 0x00) и через него мы можем увидеть любой пиксель спрайта нижнего плана (2,3).
Спасибо за статейку! Читать такие вещи очень интересно, на хабре читал про 6809 с огромным интересом и продолжение про apple вполне себе дополняет. Особенно интересно было узнать что у 65С816 есть такие инструкции и DP.
Как то с другом мы обсуждали возможности в разрезе Clear reander engine vs Sprite/Tile Engine. Ну и закусились на тему, а что было бы если бы у бабушки были бы… если бы было три спрайтовых плана с приоритетом отрисовки (подобие Z-буфера). Было бы мол тогда интересней программить в ЯВУ те же танчики? Ну сказано сделано, примерно недели две возни с верилогом и готовый адаптер для отрисовки такой графики появился. Повозится конечно пришлось, что бы выйти на времянки 1024х768 (ЕМНИП). 12 стадий в конвейере устройства, причем регистры на стадии в ФУ конвейера, вовсе нет — простенькие мультиплексоры даже пришлось огораживать. Какое то время мне казалось что я не вывожу на этой ПЛИС задачу и как бы вообще на голую шину не пришлось ставить регистры в отрезки между ФУ. Но нет обошлось 12 стадиями. Жуткое чудо юдо.
Да, но это я к тому что вот это вот убер устройство хотели повесить на корку 6502, ну и оно не потянуло. Потом я рассматривал 6809 и тоже нет, не потянуло :) Потому что, если бы только проблемы отрисовки спрайтов поверх других спрайтов с аппаратным перекрытием, а ведь еще и скроллинг этих спрайтов попиксельно в памяти самих спрайтов. После этого как то утвердился в мысли о том что такого рода аппаратура мало что даст для программера, нужен именно прокаченный процессор и желательно такой который может за такт не одну инструкцию, и при это еще бы и асинхронно.
По ссылке там есть еще вторая часть статьи где описывается трюк с туманом. Я глубоко не вчитывался, так поверхностно текст просканировал глазами и похоже что какие то трюки с лукап-таблицами и вроде тоже непростые.
Ссылку на пост на Хабре мне прислали товарищи, и хотя читать её было весело, по сути ничего нового для квалифицированного Z80 кодера там не сообщалось. А вот этот трюк со вторым планом я пока нигде не встречал, спасибо за пересказ. Нужно будет прочесть первоисточник целиком, похоже что там у ребят всё очень благополучно с креативным мышлением.
Последний билд у меня тоже вылетает, но то что я выложил работает.
Можно еще вот что попробовать — уже после запуска подпапка CPSSoftware содержит ini-файлы создаваемые в момент запуска. В моей сборке там есть пути из моего компьютера. Удалить всю папку и попробовать снова.
хоть из-за неё и страдает быстродействие, но действительно достаточно элегантно и просто можно расширять схему
Имхо они просто попали в «ловушку легаси».
Первые калькуляторы на арифметике +-*/ делались чисто под эти операции — BCD-логика разряд за разрядом — дешевая память в виде shift registers просто просилась в такие алгоритмы. А дальше уже остановится не могли усложняя раз за разом на базе предыдущего опыта.
Спасибо за статью, и особенно за ссылку в комменте на статью Фролова на хабре!
У меня в детстве был МК-61, и я даже неплохо по нему упарывался, но честно говоря никода даже не задумывался как он реализован внутри.
Думал, что в микрухах просто обычные элементы зашиты. А оказалось, что всё по серьёзному и современному — микрокод и всё такое.
Так же интересная архитектура с этим кольцевым буффером, хоть из-за неё и страдает быстродействие, но действительно достаточно элегантно и просто можно расширять схему.
В SNES и N64 местные чипы региональной защиты тоже сделаны на микроконтроллере Sharp SM-5. Также он использовался во множестве LCD-игр не от Nintendo (Tiger, Konami).
Поход на 6502 уже выразился тут в моих статья про программирование на NES/Famicom/Денди: hype.retroscene.org/blog/967.html :)
Кстати на nesdev.com вчера (с этой же статьи по сути) мне рассказали, что похожий чип Sharp SM-59x трудился в NES в чипе региональной защиты CIC в американских картриджах. Т.е. Nintendo с Sharp так сказать совсем даже не прекратила отношения по этой линии тогда. :)
Вот так сукины дети прикрутили CRC вместо счетчика. Так то оно конечно и быстрей и меньше ресурсов сдвигать и хорить. Ай да сукины дети! Примерно такая же идея мне пришла по поводу расчета CRC ключевых слов Форта или Бейсика, для того что бы не проводить поиск по токену, а иметь всегда уникальное смещение в результате расчета по токену из строки полинома CRC-16, да можно даже CRC-8 :)
P.S. Спасибо за статью! Порадовали. Где то в комментах проскакивало, что Вы собираетесь пойти крестовым походом на 6502, буду рад почитать.
Ладно, если честно я пока понял только то, что чтобы понять надо приложить намного, прям намного больше сил чем я изначально наивно рассчитывал. У меня честно столько на этот проект нету — нет из детства стимулирующего ностальгического элемента. :)
Как то с другом мы обсуждали возможности в разрезе Clear reander engine vs Sprite/Tile Engine. Ну и закусились на тему, а что было бы
если бы у бабушки были бы… если бы было три спрайтовых плана с приоритетом отрисовки (подобие Z-буфера). Было бы мол тогда интересней программить в ЯВУ те же танчики? Ну сказано сделано, примерно недели две возни с верилогом и готовый адаптер для отрисовки такой графики появился. Повозится конечно пришлось, что бы выйти на времянки 1024х768 (ЕМНИП). 12 стадий в конвейере устройства, причем регистры на стадии в ФУ конвейера, вовсе нет — простенькие мультиплексоры даже пришлось огораживать. Какое то время мне казалось что я не вывожу на этой ПЛИС задачу и как бы вообще на голую шину не пришлось ставить регистры в отрезки между ФУ. Но нет обошлось 12 стадиями. Жуткое чудо юдо.Да, но это я к тому что вот это вот убер устройство хотели повесить на корку 6502, ну и оно не потянуло. Потом я рассматривал 6809 и тоже нет, не потянуло :) Потому что, если бы только проблемы отрисовки спрайтов поверх других спрайтов с аппаратным перекрытием, а ведь еще и скроллинг этих спрайтов попиксельно в памяти самих спрайтов. После этого как то утвердился в мысли о том что такого рода аппаратура мало что даст для программера, нужен именно прокаченный процессор и желательно такой который может за такт не одну инструкцию, и при это еще бы и асинхронно.
Можно еще вот что попробовать — уже после запуска подпапка CPSSoftware содержит ini-файлы создаваемые в момент запуска. В моей сборке там есть пути из моего компьютера. Удалить всю папку и попробовать снова.
Первые калькуляторы на арифметике +-*/ делались чисто под эти операции — BCD-логика разряд за разрядом — дешевая память в виде shift registers просто просилась в такие алгоритмы. А дальше уже остановится не могли усложняя раз за разом на базе предыдущего опыта.
У меня в детстве был МК-61, и я даже неплохо по нему упарывался, но честно говоря никода даже не задумывался как он реализован внутри.
Думал, что в микрухах просто обычные элементы зашиты. А оказалось, что всё по серьёзному и современному — микрокод и всё такое.
Так же интересная архитектура с этим кольцевым буффером, хоть из-за неё и страдает быстродействие, но действительно достаточно элегантно и просто можно расширять схему.
Кстати на nesdev.com вчера (с этой же статьи по сути) мне рассказали, что похожий чип Sharp SM-59x трудился в NES в чипе региональной защиты CIC в американских картриджах. Т.е. Nintendo с Sharp так сказать совсем даже не прекратила отношения по этой линии тогда. :)
P.S. Спасибо за статью! Порадовали. Где то в комментах проскакивало, что Вы собираетесь пойти крестовым походом на 6502, буду рад почитать.