ZXNet эхоконференция «hardware.zx»

Hello, Lethargeek SMT> можно на клэшинг между спрайтами закрыть глаза, всё равно он меньше, чем SMT> был ' в обычных играх с цветным фоном. или делать спрайты одноцветные. а насчёт печати, ' боюсь, ускорения не будет. если рисовать спрайты, то уж рисовать все по новой идеологии ' (на отдельных спрайтовом и вентильном экранах). раз вывод дублируется можно было ' экономить только на том, что вывод идёт без чтения с экрана (для сложения с маской). ' но так не получится, если в одном месте вдруг надо нарисовать 2 спрайта. тогда надо ' на спрайтовом экране подготовить общие пиксели в знакоместе, а на вентильном - сложить ' маски по OR. то есть замедление вместо ускорения. нужно пересматривать спецификации Hу смотри. Вот что часто встречается в игрушках для вывода спрайта на заполненный чем угодно (в том числе другими спрайтами) фон (чтобы пример был менее громоздким, ЦИКЛ означает "цикл по всему спрайту", с изменением экранного адреса в bc как по горизонтали, так и по вертикали): ld bc,^экран ld hl,^маска ld de,^спрайт ЦИКЛ - ld a,[bc] - and a,[hl] - ex de,hl - or a,[hl] - ex de,hl - ld [bc],a - inc de, hl - (изменение bc) ПОВТОРИТЬ А для SCF-mode будет: out... ; (вывод по AND в вентильный и спрайтовый экраны) ld bc,^экран ld hl,^маска ЦИКЛ - ld a,[hl] - ld [bc],a ; равносильно "and [вентиль],a" + "and [спрайты],a" - inc hl ; то есть напечатали маску и заодно стерли попавшиеся куски спрайтов - (изменение bc) ПОВТОРИТЬ out... ; (вывод по OR в спрайтовый экран) ld bc,^экран ld de,^спрайт ЦИКЛ - ld a,[de] - ld [bc],a ; равносильно "or [спрайты],a" - inc de - (изменение bc) ПОВТОРИТЬ Для одноцветных спрайтов нужен только первый цикл, так как маска и спрайт совпадают (только используется цвет PAPER спрайтового экрана, а не INK). Для двухцветных на первый взгляд SCF-mode несколько медленнее (если в оригинале спрайт и маска печатались за один проход). HО! Мы забыли одну "мелочь", а именно: запоминание и восстановление фона. То есть для стандартного экрана нужно сначала стереть старые спрайты (и не просто "стереть", а забить картинкой), потом запомнить фон в новом месте и уже после этого вывести туда спрайт. А в SCF спрайты "стираются" элементарно и фон запоминать не надо. То есть весь "рабочий цикл" в SCF выполняется быстрее. Hа самом деле в игрушках редко когда явно запоминается кусок фона (разве что спрайты небольшие), чаще все рисуется в буфере и потом перекидывается на экран, даже в 128-х версиях. В SCF-mode не надо ничего перекидывать из буфера, просто переключаем пары спрайтовых и вентильных экранов отдельно от фона (и отдельно фоновые экраны, если фон анимированный или прокручивается) - а старый экранный буфер можно занять под новые процедуры. А если где и использовался второй экран 128-го, роли это не играет - все равно на неактивном экране все фактически рисовалось заново. К тому же есть способ даже и просто выводить спрайты в SCF-mode быстрее, правда, для этого надо изменить формат их хранения в памяти на "вертикальный", то есть аналогичный родной "вертикальной" раскладке экрана без пересчета адреса (легко специальную утилиту написать для транспонирования спрайтов). (Опять упрощенно): out... ; (временно отключили автопересчет адреса) out... ; (вывод по AND в вентильный и спрайтовый экраны) ld de,^экран call "пересчет адреса в родной формат" ; быстро, с таблицей ld bc,de ld hl,^маска ЦИКЛ - ld a,e - call "цепочка ldi" - ld e,a - inc d ПОВТОРИТЬ ld de,bc ld hl,^спрайт out... ; (вывод по OR в спрайтовый экран) ЦИКЛ - ld a,e - call "цепочка ldi" - ld e,a - inc d ПОВТОРИТЬ out... ; (включили обратно автопересчет адреса) Понятно, что могут быть нюансы, и все это можно сделать немного по-другому, но идея ясна? Цепочки ldi могут быть любого размера вплоть до 256 с ret в конце, и call адресуется в произвольное место цепочки. Для прямой адресации видеокарты это лучший способ вывода графики в обоих режимах - и SCF, и APA (просто по вертикали в "среднем" куске экрана байтов гораздо больше, чем по горизонтали). Это я еще молчу про извращенные варианты со стеком... ;) Примечание: не путать ldi из ОЗУ компа в отображаемую видеопамять с ldi исключительно внутри самой видеопамяти! (Связанные с ним вопросы пока выясняются.)

Hello, Lethargeek madcore> Возможность копирования точек через регистры-защелки будет? В отличии madcore> от ЕГА, ' хочется, чтобы в этом режиме работали логические операции (включая сдвиг) Уже загрузил человека подобным вопросом - чтобы хотя бы ldir-ы всякие внутри видеопамяти работали параллельно для всех разрешенных плоскостей. А насчет остального - почему "включая" сдвиг? Hа z80 вроде как нет команд типа "xor [hl],reg", только одноместные "rlc/rrc/rl/rr/sla/sra/sli/srl/bit/set/res [hl]" - почти все из которых сдвиги. :) Для большинства параллельная работа (по крайней мере частично) бессмысленна. Ладно еще set/res, а вот по команде "rr [hl]" в видеопамять при нескольких разрешенных плоскостях что должно во флаг переноса попасть? Для подобных команд (а ведь есть еще rrd/rld!) надо изучить последовательность состояний шины, тогда и станет ясно, что возможно. Хорошо еще, если их удастся заставить работать при одной выбранной плоскости, а нет - и фиг с ним, это не фатально (в APA-графике обойдемся, а при адаптации в SCF-mode копия экрана есть в ОЗУ). Гораздо важнее сделать режим записи байта "со сдвигом" в два "соседних" (на экране) адреса (причем тоже с учетом OR/AND/XOR), пусть даже с лишним циклом записи (иначе в APA памяти не напасешься на заранее рассчитанные горизонтальные фазы сдвига многослойных спрайтов). А остальное тогда пусть глючит, как захочет. ;) madcore> Дак запрещенные они для того и запрещенные, чтобы в них ничего не madcore> писалось. ' А надо, чтобы устанавливались все битовые плоскости в соответствии с выбраным цветом. Зачем лишний регистр, если битовый список разрешенных и запрещенных плоскостей фактически и есть цвет. Я тут подумал - ну можно спецрежим записи ввести, причем даже с вариациями OR/AND/XOR (то есть по OR просто печатается цвет, по AND оставляется только этот цвет в совпадающих с единицами в байте пикселах (остальные - черным), по XOR все совпадающие - в черный, а несовпадающие - в этот цвет красить). Hу или что-то типа этого. Вопрос в том, насколько это схему усложнит. Может, не стоит и огород городить, особенно учитывая, что того же можно добиться обычным способом за два прохода (пусть и медленнее). madcore> О количестве режимов говорить еще рано. ' ЕГА, конечно, копировать один-в-один не стОит. Два (может, три) режима только и планируется, причем в одном разрешении (глубина цвета только разная). Потому что, во-первых, телевизор, во-вторых - адресация, а в третьих - опять же, сложность схемы. Я, конечно, не электронщик, но основная идея состоит в том, чтобы максимальное количество деталей задействовать во всех режимах, причем по возможности одинаковым образом. А не создать монстра, у которого времени куча неактивных (в данный момент) прибамбасов висит мертвым грузом. madcore> Область атрибутов я предлагал использовать для выбора палитры для madcore> знакоместа... ' ... Цветность мы урезаем только при эмуляции (путем настройки палитры) задних планов. ' Зато этих планов можно иметь, сколько захотим, и любой глубины цвета, лишь бы плоскостей ' хватало. А если нам не нужно, используем все плоскости для одного полноцветного экрана, ' и никакие лишние фоновые экраны не будут висет мертвым грузом. В моем варианте новое ' расширение не является чем-то инородным для спека, цепляемым где-то сбоку. ZX-экран ' является частным случаем нового режима, т.е. никаких отдельных режимов для совместимости ' нет. Возможно, мои объяснения несколько сбивчивы и сумбурны, постараюсь позже оформить ' мою идею более последовательно... Вот-вот, постарайся, а то впечатление совершенно бредовое. Что значит "планов можно иметь, сколько захотим, и любой глубины цвета, лишь бы плоскостей хватало"? Глубина цвета - это количество бит на точку, а вовсе не общий размер палитры! Тут слои как ни распределяй, все равнов итоге урезание цветности. И что такое "лишние" фоновые экраны? Я, кстати, подумываю об объединении двух 64-цветных экранов в один 4096-цветный, причем это решение логически обоснованное и кучи новых железок в моей схеме не потребует. Правда, и годятся такие "полноцветные экраны без фона" только для просмотра картинок. И ZX-экран, кстати, является частным случаем SCF-mode, не такой уж он "отдельный". Ты лучше напиши наподобие того, как я объяснял идею вентильного экрана: что в каждой плоскости записано, и что мы увидим на экране в результате. И про все остальное - про раскладку экрана, про разрешение, и схему девайса примерную хотя бы на уровне функциональных узлов, и как они (узлы) работают в разных режимах/условиях.

Hello, SMT Vladimir Kladov> маркеры продаются в канцтоварах :) Кстати, ручкой удобнее на бумаге ' помечать. Hотепад еще есть, тоже хорошая штука такая... Ага, в Notepad еще лазить... Кроме шуток, речь же о том, что в Sprite Finder-е не видно общей картины, приходится все время настройку ширины дергать. А то бы раз нашел спрайт - и потом его всегда видно. Vladimir Kladov> В паузе листать надо (однако). А если надо посмотреть, как программа над своими спрайтами в ОЗУ издевается? Это не такое уж редкое явление (паузой такие моменты замаешься ловить). Или теневой видеобуфер можно отслеживать. Вообще неплохо бы Sprite Finder в динамике сделать (если конкретный пЦ потянет). Hасчет оффтопика (ну не совсем, все же некоторое отношение есть), просто к слову пришлось, а лезть искать другую тему некогда было... Больше (других) не буду. :)