ну почему же глупо? просто ассиметричный кластерЦитата:
Сообщение от AlexCrush
Вид для печати
ну почему же глупо? просто ассиметричный кластерЦитата:
Сообщение от AlexCrush
Всё это в разы удобнее и привычнее делать через память, а не через порты. Очень здорово будет через порты заливать 30-байтную процедуру в память по адресу #7FF0. А во временной смене адресного пространства ничего страшного нет.Цитата:
Сообщение от Raydac
Почему Вы боитесь признать что фишка с подменой портов в имеющемся виде бесполезна? Давайте её выкинем! Зачем усложнять железо ненужными вещами? Вот когда будет применение этой вещи + когда идея будет доведена до ума...
"Контроллер SD/MMC само по себе простейшее устройство, вот кто программно поддержит это на спеке?"
Сейчас я делаю поддержку сом через вход-выход
магнитофона (пока только 38400 и ТАР-файлы)
Затем - 1 меговый+ диск, после карты ...
А "ZX-Poly" помрет не родившись ...
Що? Вы, господа, когда тут перестанете генеталиями мерятся?Цитата:
Сообщение от andrews
Цитата:
Сообщение от icebear
+1 :v2_clapp:
до чегож народ у нас любит офтопить.....
(icebear это не про тебя.... :v2_wink2: )
Хм. Предложение унификации атрибутов выходит за рамки простоты?Цитата:
Сообщение от Raydac
Кстати о простоте (и гибкости) - так называемые "видеорежимы 0-3" вообще не нужны в явном виде, они прекрасно получаются настройкой режимов 256x192x4 и 512x384x1, нужно (в дополнение к регистрам палитры) всего два байта-описателя пиксельных и атрибутных блоков 2x2 (то есть с какой плоскости брать соотв-й пиксел/атрибут в каждой четверке пикселов/атрибутов). При этом сразу появляются "режимы" 512x192 и 256x384 с прямоугольными точками (не считая остальных извращенных частных случаев), можно моргалки быстрые делать... В режиме 256x192x4 "лишние" цвета убиваются просто настройкой палитры.
Когда кто-то реально докажет и покажет :)Цитата:
Сообщение от icebear
..своё железо в действии, разумееца...
Самое страшное - это не видеть, "куда там доводить еще". Иметь четыре одинаковых псевдостандартных режима - это типа не страшно, а ведь там требуются те же переключатели. Описанные дополнительные настройки - ерунда по сравнению палитрой, тем более вроде как решено для логики юзать ПЛИС, какие проблемы-то? В случае трудностей спецы здесь всегда помогут.Цитата:
Сообщение от Raydac
Видать, реализовать более эффективную (а главное - полезную) архитектуру "инженерное мышление" не позволяет? Почему из разряда "невозможно" надо обязательно переводить в разряд "сложно", а не в разряд "просто, удобно и эффективно"?
нет, не правильно, такое обсуждение полезно даже в случае "извращений ради извращений". Метод, при котором рассматриваются даже бредовые идеи используется в ТРИЗ и называется "мозговым штурмом". Это очень полезный метод :), т.к. он позволяет в дальнейшем рассмотрении оперировать на всём поле возможных вариантов, а не зацикливаться на одном направлении, хоть возможно и перспективном с первого взгляда.Цитата:
Сообщение от Lethargeek
ну это в обычных переделываемых игрушках врядли есть, а если есть, то помена не частая (т.е. не несколько раз на строку или на кадр).Цитата:
Сообщение от Lethargeek
Я ж не спорю что вариант прожорливый, но тут уже можно подумать об аппаратных возможностях нивелирующих фазовое рассогласование обсчёта и отображения, что-то типа отделения памяти видеопроцессора от общей памяти и синхронизация содержимого во время обратного хода луча.Цитата:
Сообщение от Lethargeek
Ладно, спасибо за участие в обсуждении и подведём итог:
1) Вариант атрибут на столбец 1х8 с построчным переписыванием атрибутов наезжающих друг на друга спрайтов в принципе может решить поставленную задачу в самом общем случае, хотя и ценой значительных затрат ресурсов процессоров, поэтому применение такому методу может быть демонстрационное.
2) Можно достичь решения задачи более простыми средствами, но ограничиваясь при этом меньшим количеством цветов на пиксель, чего при определённых условиях может быть достаточно. Для этого достаточно отдать один из битов цвета (например бит плоскости I) в качестве определителя палитры (сигнальный цвет как предлагал Lethargeek). При таком раскладе получаем 8 цветов на пиксель из 4х (16ти) пар 4х битных палитр адресуемых значением атрибута для данной группы пикселов и выбираемых в паре с помощью сигнального бита I на группу из 4х (8ми) пикселов (при этом ЦАП можно попробовать заменить тремя пятиразрядными R-2R матрицами). При этом группы из 4х и 8ми пикселей могут быть сконфигурированы как 1х4, 2х2, 4х1 и соответственно 1х8, 2х4, 4х2, 8х1.
Вопрос: есть ли какие соображения по обоснованию конфигурированию групп пикселей?
Мозговой штурм производится в соответствующих разделах. А здесь похоже уже все ясно: автор - гений, проект - совершенство, и что-то предлагать/критиковать не только бесполезно, но и кощунственно. Аллилуйя и вечная слава "инженерному мышлению". :v2_biggr:Цитата:
Сообщение от Black_Cat
В любых несколько спрайтов запросто могут сойтись на одном небольшом участке - например вражины толпой накинулись на героя.Цитата:
Сообщение от Black_Cat
Ну что за фигня опять, я ж русским языком написал: 16 цветов так и остается, 16! Из них два зависят от (четвертушки) атрибута. Палитра - общая, глубина цвета в ней зависит только от разрядности ЦАП. В том числе и "цвета" в соотв-х атрибутах - это тоже номера регистров палитры, а не цвета напрямую.Цитата:
Сообщение от Black_Cat
Маскировать отдельные плоскости и сокращать количество цветов действительно полезно (тогда при соответствующей настройке палитры получаем полный аналог "стандартных режимов 0-3", или например два 4-цветных режима), нужен только байт безразличия плоскостей для определения атрибутнозависимых цветов, тогда и получится что-то похожее на твое описание. "Группы пикселей" - только 2x2 в режиме высокого разрешения - опять-таки только для "отключения" плоскостей.
А, бесполезно тут разоряться... :v2_sleep: