Идея простого расширения стандартного видорежима

[SMT]

только воплощать в эмуляторе то что будет сотворено, я стану не раньше, чем появится софт, который это железо юзает и сам при том востребован

замкнутый круг? а в чём же Lethargeek будет переделывать игрушки под свой режим, как не в твоём эмуляторе?

[Vladimir Kladov]

замкнутый круг? а в чём же Lethargeek будет переделывать игрушки под свой режим, как не в твоём эмуляторе?

Вот это мне и не нравится - опять переделывать. Хочу попробовать другое в борьбе с клэшем. Не ИИ, но вроде того. А если удастся это в эмуляторе, то почему бы и не воплотить в железо. Хотя особой радости в том тоже не вижу. Для меня реальный спек - в далеком прошлом. Спектруму не нужен реал, чтобы оставаться живым.

[Spectre]

Надо лишь сделать так, чтобы тот софт, что уже есть, с МИНИМАЛЬНЫМИ изменениями (ИЛИ ВООБЩЕ БЕЗ ИЗМЕНЕНИЙ - этого не было, но об этом все подумали) шел в новом режиме и радовал глаз. Как минимум - отсутствием клэшинга.

Собственно это и есть основная идея Lethargeek'ого режима. Жаль что не все прониклись ею. Я уже отписал Lethargeek'у в письме что планирую накидать список игр которые я хотел бы видеть в переделке (например, Dizzy, Exolon, Robocop, Laser Squad, то есть классику спектрумских игр), потом изучить их процедуры вывода на экран чтобы представить какие минимально необходимые требования к новому режиму, при этом требующие минимальной переделки игр. То есть главное условие - это компромис. Варианты Sam Style и CHRV в предложенном варианте этому условию не удовлетворяют.

[Lethargeek]

SAM style> Я в своей песочнице, ты в своей.
' Ittekimasu, чуваки. Как сделаю себе девайс на скорп - вернусь (может быть).

Когда вернешься, жду подробный отчет, как ты на своем девайсе пытался спрайты гонять.
Не представишь - буду песком кидаться!

[Lethargeek]

SMT> а на чём планируешь делать? альтера, микроконтроллер, или рассыпуха? схему SAM style
' я без труда представляю в железе, а вот твой режим сделаю, не раньше, чем схема будет.
' по виртуальным (например, 256-цветным) режимам, это Кладов специалист

Это к схемотехникам вопрос (пишем письма друг другу пока что). А что, у тебя движок
настолько завязан на эмуляцию именно железа, что ему обязательно схему сигналов подавай?
Нельзя пока сделать с точностью до временных характеристик ULA эмуляцию, только текущий
пиксел стандартного режима вовремя подменять?

SMT> p.s. с вентилем понял. а зачем ему атрибут? чтобы в 8 раз быстрее заполнить переход
' на один из экранов?

Ну примерно так. Еще спрайтом мигать можно быстро. Я подумал - все равно контроллер
по два байта читает, не пропадать же второму.

[Lethargeek]

Vladimir Kladov> Вот это мне и не нравится - опять переделывать. Хочу попробовать другое
' в борьбе с клэшем. Не ИИ, но вроде того. А если удастся это в эмуляторе, то почему бы
' и не воплотить в железо.

Свои сомнения по поводу "железной" реализации я изложил ранее, и повторяться не буду.
А кое-что только сейчас на ум пришло - как, например, насчет игр с подгружаемыми уровнями?

А вообще хочу сказать большое спасибо за то, что могу в EmuZWin хотя бы оценить, как
будут примерно выглядеть адаптированные игрушки, и графику быстро найти. Кстати, как раз
по поводу Sprite Finder-a у меня есть некоторые рацпредложения:

Неплохо бы иметь возможность на любой адрес поставить маркер - ширину обнаруженного спрайта
(хватит однобайтового). И чтобы он действовал до следующего маркера. А нулевое значение
"ширины" будет означать просто отмену предыдущего маркера и использование "общей" ширины.

Также под формат спрайта можно отвести три бита маркера. Например, байты спрайта могут
храниться столбцами, или мой любимый способ - "змейкой" (то есть четные строки - справа
налево, нечетные - слева направо). И вообще "столбцовой змейкой", хотя я такого пока не
встречал. Плюс возможность переворачивать спрайт кверх ногами. А то пока, похоже, только
формат "слева-направо, сверху-вниз" поддерживается. Само собой, список маркеров должен
автосохраняться/подгружаться со снапшотом.

И чтобы память в Sprite Finder-е отображалась постранично, а то пока листаешь, страницы
могут переключаться, и видишь глюки.

[Lethargeek]

Очередной вариант (специально для ewgeny7). Старый убил.
Теперь так и буду вложением кидать - это лучше, чем простыни множить.

В следующий раз, надеюсь, добавлю рисунки.

(убил 1-11-2005)

[SMT]

а на чём планируешь делать

движок настолько завязан на эмуляцию именно железа, что ему обязательно схему сигналов подавай?

для эмулятора, понятное дело, всё равно. просто интересно, какие схемотехнические приёмы будут использованы, и во сколько килограмм выйдет этот монстр ведь для карты SAM style схема вырисовывается в уме средним спектрумистом-железячником и спаять не проблема, у 9990 CHRV, я думаю, есть схема типового включения, описанная разработчиками кристалла. а доберётся ли третья карта до стадии схемы - вопрос

зачем ему атрибут

спрайтом мигать можно быстро

хорошо, прям как на денди только для игр плохо тем, что нельзя, чтобы в атрибутном квадратике мигания были другие спрайты, (напр., в играх типа golden axe чтобы так умирали монстры на игровом поле). для SCF атрибутный клешинг с фоном ты разрулил, но между спрайтами конфликты так и остались. так что вариант CHRV качественнее (и кажется, по цене и корпусам компактнее)

[Vladimir Kladov]

Vladimir Kladov> Вот это мне и не нравится - опять переделывать. Хочу попробовать другое
' в борьбе с клэшем. Не ИИ, но вроде того. А если удастся это в эмуляторе, то почему бы
' и не воплотить в железо.

тут я сначала ничего не понял, пока не дочитал до конца. Мне кажется вопрос здесь по поводу возможности моего эмулятора - оффтопик, надо было отдельную тему или присоседиться к теме по моему эмулятору.

Свои сомнения по поводу "железной" реализации я изложил ранее, и повторяться не буду.
А кое-что только сейчас на ум пришло - как, например, насчет игр с подгружаемыми уровнями?

Здесь я опять ничего не понял - это про 256-режим, что ли? Никак почти. Делается каждый уровень отдельно, если спрайтовка разная. Я же не за то, чтобы все на 256 переводить, а то, что переводится, выглядит просто красивее. Я вообще этот режим сделал только потому, что мне понравилось как Knight Lore стал после переделки выглядеть. Правда, потом я его еще улучшил, но даже то, что было, мне нравилось.

А вообще хочу сказать большое спасибо за то, что могу в EmuZWin хотя бы оценить, как
будут примерно выглядеть адаптированные игрушки, и графику быстро найти. Кстати, как раз
по поводу Sprite Finder-a у меня есть некоторые рацпредложения:

Неплохо бы иметь возможность на любой адрес поставить маркер - ширину обнаруженного спрайта
(хватит однобайтового). И чтобы он действовал до следующего маркера.

маркеры продаются в канцтоварах Кстати, ручкой удобнее на бумаге помечать. Нотепад еще есть, тоже хорошая штука такая...

храниться столбцами, или мой любимый способ - "змейкой" (то есть четные строки - справа
налево, нечетные - слева направо). И вообще "столбцовой змейкой", хотя я такого пока не
встречал.

Думаю, что и не встретите Если встретите - обязательно напишите, в каком чуде вы такое нашли.

Плюс возможность переворачивать спрайт кверх ногами. А то пока, похоже, только
формат "слева-направо, сверху-вниз" поддерживается.

есть переворот по вертикали. Только надо включить граф редактор, там он и находится. Хотя может и в файндере есть (я не помню, давно не открывал).

И чтобы память в Sprite Finder-е отображалась постранично, а то пока листаешь, страницы
могут переключаться, и видишь глюки.

В паузе листать надо (однако).

[madcore]

Вообще печать спрайта в моем варианте выглядит так: сначала разрешаем для записи все слои и за один проход печатаем маску по AND, затем (допустим, спрайт трехцветный - красного, желтого и зеленого цвета) разрешаем только красный слой экрана, печатаем красный слой спрайта, разрешаем только зеленый слой экрана и печатаем зеленый слой спрайта и... все! Желтый цвет получился слиянием зеленого и красного - преимущество битплановых режимов
(можно раскладывать на спрайт на цветосоставляющие для любого числа слоев).

Возможность копирования точек через регистры-защелки будет? В отличии от ЕГА, хочется, чтобы в этом режиме работали логические операции(включая сдвиг)

Насчет режима записи madcore: "соответствующий регистр" - это просто тот же самый регистр разрешения записи/чтения слоев. Просто в разрешенные слои запись идет по OR, а в запрещенные - по NOT+AND.

Дак заприщенные они для того и запрещенные, чтобы в них ничего не писалось. А надо, чтобы устанавливались все битовые плоскости в соответствии с выбраным цветом.

Для чтения я уже предлагал нечто подобное (перечитай specs!). При записи такой режим даст реальный выигрыш только для одноцветных спрайтов - буквы на фоне рисунка, что ли, печатать собрался?

Еще примитивы - линии, прямоугольники, кружочки Т.е., старый код для их рисования менять не нужно будет, только устанавливать регистр цвета перед выводом.

Не лучше ли это сделать по-моему, когда в
APA-mode тоже есть "спрайты". 5 режимов записи (а не 4) - это плохо, бит повиснет Хотя я подумаю, как это сделать, чтобы во всех режимах больше пользы было.

О количестве режимов говорить еще рано. ЕГА, конечно, копировать один-в-один не стОит.

madcore> Что мешает видеокарте выводить zx-экран? Просто настроить запись/чтение на одну
' плоскость, астольные либо заполнены 0, либо палитра установлена так что их не видно.
' И почему не 5aff? ИМХО, под это дело не грех выделить и 16К - для быстрого копирования
' спрайтов. Конечно, перекроет системные переменные и бэйсик, но во время вывода спрайтов
' оно нам не надо.[/I]

Что мешает? Атрибутов нет! Либо все равно удваивать цикл чтения, либо читать их с другого слоя. И писать тогда тоже в два слоя одновременно. То есть опять просто не получится.

Область атрибутов я предлагал использовать для выбора палитры для знакоместа. Стандартный ZX-экран в этом случае просто часть нашего нового режима. Только поддержка мерцания выглядит не очень стройно, но можно продумать. Правда, для 16 цветов хранение 256 различных палитр вполне реально, а вот для 6-ти и 8-ми плоскостей уже уже неоправдано и странно... Тут можно придумать, чтобы атрибуты выступали в качестве модификаторов установленной палитры, или еще чего..

А то, что предлагает в данном случае madcore - убожество, получается, мы сознательно урезаем цветность.

Цветность мы урезаем только при эмуляции(путем настройки палитры) задних планов. Зато этих планов можно иметь сколько захотим и любой глубины цвета, лишь бы плоскостей хватало. А если нам не нужно, используем все плоскости для одного полноцветного экрына, и никакие лишние фоновые экраны не будут висет мертвым грузом.
В моем варианте новое расширение не является чем-то инородным для спека, цепляемым где-то сбоку. ZX-экран является частным случаем нового режима, т.е. никаких отдельных режимов для совместимости нет.
Возможно, мои объяснения несколько сбивчивы и сумбурны, постараюсь позже оформить мою идею более псоледовательно. На счет атриботов-палитры надо еще продумать для количества плоскостей более 4-х.