Новый графический режим для игр [Архив] - Страница 3 - Speccy

Nesser

06.09.2015, 20:21

Единственное верное решение это делать точку кратной байту.
Точнее иметь экран и место для хранения спрайтов кратному байту, а некая программная процедура уже принимать спрайт в любом формате (хоть ч/б) и сделать из него 1 байт на точку, то есть показал где у тебя в памяти находится спрайт и в каком он формате а процедура его декодирует и помещает с память спрайтов 1 байт на пиксель.
Это даёт огромное преимущество в скорости работы подобного устройства, видео память имеет организацию 256 байт по X (младший регистр 16 битного регистра) и 192 байта по Y (старший регистр), то есть в регистре HL в L находится горизонталь а в H вертикаль, при H=0 и L=255 (HL=255) точка будет в верхнем правом углу (или нижнем :) ) то после команды INC HL получится H=1, L=0 (HL=256) точка получится слева вверху на 1 пиксель ниже, то есть автоматически произойдёт и сброс X и увеличение Y, это оооооочень удобно для работы с растровой графикой и для аппаратного драйвера переброски спрайтов это так же очень удобно, 8 битные счётчики в помощь.
Так же этот 1 байт можно сделать не RGB а какой нибудь GB-Y как на PC, преимущество в том что можно впихнуть к примеру цвета с номерами 192-255 будут не цвета а ВЗЯТЫЙ цвет из палитры в 64 регистра, то есть можно выводить один и тот же спрайт, но с прожилками другого цвета, к примеру War Craft с домиками разных цветов для разных игроков, а при числе 255 тупо не производить перезапись пикселя, то есть прозрачный цвет, то что уже есть на экране не будет затёрто. Хотя можно сделать и переключаемый режим - с регистрами или тупо 2-2-2-2 (8 бит) по 4 яркости на каждый цвет и 4 яркости общих.

zx-kit

06.09.2015, 20:28

Наш любимый велосипед вышел на трек и вполне успешно наматывает круги.
Мы два месяца это обсуждали, а тут за 5 минут весь трек. Сейчас новые идеи пойдут. Да нормально все. Тема очень большая - ее прочитать за 5 минут нереально. Когда поймет, до какой степени мы упростили первоначальные замыслы - пойдут полезные идеи.

Nesser

06.09.2015, 20:29

Nesser, К тебе большая просьба: перечитай, пожалуйста, весь тред. В третий разу же говорим о том, что аппаратные спрайты, шейдеры, блиттеры, HD-видео, 48-килобитный экран - это не про эту разработку. Проникнись, пожалуйста, предлагаемой архитектурой и задавай вопросы в ее ключе. Этак карта делается во-первых для простой и последовательной адаптации существующих игр, во-вторых, для разработки игр в ключе Спектрума, а не Денди/Амиги/РС.

Меня хватило только на десяток страниц :)
Дык 48-килобАйтный экран
Подожди, но ты уже увеличил объём спрайтов в 2 раза+куча палитр, да и экран уже стал как минимум в 2 раза больше и экрана надо всё равно 2, иначе будет видно отрисовку, то есть 6144*2*2=24576 и плюс в 2-5 раз увеличенные в 2 раза спрайты и приклеенные к ним палитры которые по размерам больше чем сам спрайт, встаёт проблема запихивания этого всего в 2-3 страницы по 16к, то есть старую игру надо не просто переделать а тупо написать ЗАНОВО, по иным принципам и с помощью новых процедур, да ещё и гемор с кучей палитр всего по 3 регистра каждая :)

zx-kit

06.09.2015, 20:30

Меня хватило только на десяток страниц :)
Дык 48-килобАйтный экран
Подожди, но ты уже увеличил объём спрайтов в 2 раза+куча палитр, да и экран уже стал как минимум в 2 раза больше и экрана надо всё равно 2, иначе будет видно отрисовку, то есть 6144*2*2=24576 и плюс в 2-5 раз увеличенные в 2 раза спрайты и приклеенные к ним палитры которые по размерам больше чем сам спрайт, встаёт проблема запихивания этого всего в 2-3 страницы по 16к, то есть старую игру надо не просто переделать а тупо написать ЗАНОВО, по иным принципам и с помощью новых процедур, да ещё и гемор с кучей палитр всего по 3 регистра каждая :)
На первой старинице есть ссылки на текущую конфигурацию режимов и что планируется реализовать в железе.

Alex Rider

06.09.2015, 20:37

Надо разработать команды загрузки палитр.
Предлагаю сделать палитру в 512 байт (коли 16 бит на цвет). Загружать по ldir в некую область ПЗУ, во время записи карта будет вычитвать палитру (желательно менять палитры динамически, чтобы можно было иметь разные палитры в разных локациях; желательно иметь возможность менять любой цвет в палитре, можно будет делать fade-in-эффекты).
Как адресовать палитры:
1 цвет - атрибут слоя задает номер цвета в палитре (0-255), номер палиты слоя не используется.
2 цвета - номер палитры слоя (старшие 4 бита) задают одну из 16 палитр, из которой выбираются цвета INK и PAPER (0-7), включенный бит BRIGHT означает, что к номеру цвета INK добавляется 8. После сброса номер палитры для такого режима - 0, а сама палитра инициализируется стандартными цветами Спектрума (16 одинаковых 16-цветных палитр). Кстати, бит Flash будет поддерживаться?
2 цвета + прозрачный - то же, что и 2 цвета, но цвет №0 - прозрачный (так же и для 3, 7 и 15 цветов).
3,4 цвета - каждая пара бит кодирует один из четырех цветов одной из 64 палитр, номер (смещение 1-го цвета) которой задают 6 старших бит номера палитры слоя.
7, 8 цветов - каждая тройка бит растра задает один из 8 цветов в одной из 32 8-цветных палитр, смещение первого цвета которой задают 5 старших бит номера палитры слоя.
15, 16 цветов - каждая четверка бит растра задает один из 16 цветов в одной из 16 16-цветных палитр, смещение первого цвета которой задают 4 старших бита номера палитры слоя.

---------- Post added at 20:37 ---------- Previous post was at 20:31 ----------

Возможно лучше это оставить на 2 ступень расширения графики.
Очень хочется вот этот функционал сразу. Объясню почему: избавление игр от клешинга не дает такой wow-эффект, как появление коричневенького, оранжевенького или сиреневенького хотя бы на статичной рамке экрана в игре :)

Nesser

06.09.2015, 20:38

Предлагаю сделать палитру в 512 байт (коли 16 бит на цвет). Загружать по ldir в некую область ПЗУ, во время записи карта будет вычитвать палитру (желательно менять палитры динамически, чтобы можно было иметь разные палитры в разных локациях; желательно иметь возможность менять любой цвет в палитре, можно будет делать fade-in-эффекты).

Да нет смысла настолько усложнять такое устройство, или зажали 48 кБ из 8 МБ для нормального байтового экрана? :)

Все эти процедуры можно произвести программно перед закидыванием спрайтов в память устройства, и там они уже будут храниться в нормальном для устройства виде 1 байт на точку, что проще перекинуть - тупо 1 байт с места на место ИЛИ взять 1 байт произвести с ним кучу манипуляций по вырезанию нескольких пикселей и микшированием их с палитрами и т.д. ?

Nesser

06.09.2015, 20:51

Я уже даже придумал как с растрами работать :)

К примеру нужно сделать
PLOT 128,88,116 - То есть по центру экрана вывести точку с цветом 116

LD A,116
LD L,128
LD H,88
-----------
LD (200),HL
LD (202),A
-----------
устройство принимает при записи в пзу по адресу 200 и 201 соответственно Y и X и защелкивает их в регистр
а по адресу 202 получает цвет и сразу же записывает его на экран

---------- Post added at 21:51 ---------- Previous post was at 21:48 ----------

прямая линия по центру экрана с цветом 19

LD A,19
LD L,0
LD H,88

L1 LD BC,255
LD (200),HL
LD (202),A
INC L
DJNZ L1

:)

Alex Rider

06.09.2015, 21:09

так не бывает, рисовать можно на экране 4 способами
1. Процессором хоста
2. Спрайтовый движок
3. Блиттер
4. Процессор в видеокарте (шейдер)
А давай придумаем 5-й способ = 1 + 4? Процессор рисует графику вместе с железом видеокарты? Ведь без разницы же как видеокарта помогает рисовать быстрее - прошивкой ПЛИС или прошивкой процессора?

Теперь, речь идет о ускорении, при этом последние 3 варианта исключаются, каким образом достигается ускорение?
Ахтунг! Читаем примеры кода, которые я приводил для вывода спрайтов, считаем такты, думаем. Для тех, кому лень:
1. Мы перестаем запоминать фон и восстанавливать его. upd: и передний статический слой тоже
2. Мы начинаем выводить знакоместо без маски через dup 8: ldi: edup, знакоместо с маской и 4-хцветное знакоместо - через dup 8: ldi: dec e: ldi: edup (а с новой адресацией мы можем так вывести целый столбец спрайта).
3. Для монохромных спрайтов мы перестаем выводить атрибуты.
4. С новой адресацией экрана забываем страшный код перехода к новой строке/трети.

---------- Post added at 20:59 ---------- Previous post was at 20:58 ----------

Объем данных увеличивается и при этом процессор хоста одновременно быстрее рисует? ну так не бывает.
Перестаем размышлять в рамках известных архитектур, и все начинает получаться!

---------- Post added at 21:01 ---------- Previous post was at 20:59 ----------

Подожди, но ты уже увеличил объём спрайтов в 2 раза+куча палитр, да и экран уже стал как минимум в 2 раза больше и экрана надо всё равно 2, иначе будет видно отрисовку, то есть 6144*2*2=24576 и плюс в 2-5 раз увеличенные в 2 раза спрайты и приклеенные к ним палитры которые по размерам больше чем сам спрайт, встаёт проблема запихивания этого всего в 2-3 страницы по 16к, то есть старую игру надо не просто переделать а тупо написать ЗАНОВО, по иным принципам и с помощью новых процедур, да ещё и гемор с кучей палитр всего по 3 регистра каждая
Вот ровно поэтому и надо перечитать тему :) Я вот утверждаю, что при отказе от старых режимов под экран нужно на 768 байт памяти меньше. А ты мне говоришь, что вот обязательно нужно распихивать что-то по страницам. Это я брежу, или ты чего-то не знаешь об архитектуре разработки?

---------- Post added at 21:05 ---------- Previous post was at 21:01 ----------

Все эти процедуры можно произвести программно перед закидыванием спрайтов в память устройства
Это, если и будет, то не сразу. Да и не надо особо. А что, если игра модифицирует спрайты во время работы? А, если в рендеренге спрайтов живет логика игры? Как ты столкновение аппаратных спрайтов определять будешь, например? Это я все пока про переделку игр большей частью говорю.

---------- Post added at 21:08 ---------- Previous post was at 21:05 ----------

К примеру нужно сделать
PLOT 128,88,116 - То есть по центру экрана вывести точку с цветом 116
Векторная графика - это тоже на будущее. Сейчас приновом формате экрана для того, чтобы сделать твой PLOT, придется пока покрутить биты и поделить x на 8, остальное все почти так же. А при поддержке растровой графики прямые линии рисовать в цикле CPU - это фи. Надо уж сразу делать аппаратные векторные примитивы, ибо в той же Elite движок более половины времени рендерит картинку на экран.

---------- Post added at 21:09 ---------- Previous post was at 21:08 ----------

Для начала, хоть кто-то сделал стандартный спектрумовский видео режим 256х192 с бордюром? О чем здесь можно ещё говорить, когда нет даже базового режима?
А, тем более, нет эмулятора. Без него совсем тяжко будет, отвыкли мы все уже от Alasm'ов на реале.

Nesser

06.09.2015, 21:16

По спрайтам точно так же.
К примеру есть память 1 МБ, то есть 20 бит адреса и 49 кБ экрана (два) то есть 16 бит адреса, к примеру включаем режим спрайтов 8*8 (16*16), то есть 64 байта, то бишь 6 бит адреса, остаётся 20-6=14 бит адреса на номер спрайта то есть 16384 спрайтов, можно и меньше памяти (или больше).

Задача вывести спрайт под номером 217 в координаты 200, 140

LD L,200
LD H,140
LD DE,217
-----------------
LD (204),HL
LD (206),DE
-----------------

Или к примеру нужна летающая табличка для демки (или большой монстр в R-TYPE) шириной 64 пикселя (8 спрайтов) и высотой 24 пикселя (3 спрайта), в ширину раскладываем табличку на 8 спрайтов с номерами 100-107, следующий ряд 108-115, следующий 116-123, то есть тупо картинку раскладываем подряд в спрайты, кидаем координаты и после каждого спрайта увеличиваем координаты на 8, в итоге получим боольшую шнягу на экране не сильно усложняя устройство, на такие манипуляции cpu точно хватит, пока он выполняет свои команды устройство выкидывает предыдущий спрайт на экран..

---------- Post added at 22:16 ---------- Previous post was at 22:14 ----------

нууу если вдруг не успеет то в момент записи в 206 адрес можно тормознуть камень по вайту :)

Alex Rider

06.09.2015, 21:18

По спрайтам точно так же.
Ты читаешь вообще что тут пишут? Или ты решил в этой теме придумать свою видеокарту? На данный момент никаких аппаратных точек и спрайтов не будет! Можно завести еще один тред и рассказывать там всем какая карта понравилась бы лично тебе.

Nesser

06.09.2015, 21:26

Это, если и будет, то не сразу. Да и не надо особо. А что, если игра модифицирует спрайты во время работы? А, если в рендеренге спрайтов живет ллгика игры? Как ты столкновение аппаратных спрайтов определять будешь, например? Это я все пока про переделку игр большей частью говорю.

Нууу столкновение исторически вычисляется двумя способами

тупо последовательным перебором координат спрайтов в поисках наложений (программно или аппаратно)

или

ведением теневого экрана в котором после вывода спрайта на основной экран делается такое же (или параллельно) в теневом экране (записывается только номер спрайта предварительно считывая байт (два) который там уже есть (или 0 если там ещё нет спрайтов)) и если на месте записи нового спрайта уже есть номер другого то регистрируется коллизия (номер спрайта на который была попытка наложиться уже есть) которая программно допроверяется что с этим делать...

---------- Post added at 22:26 ---------- Previous post was at 22:24 ----------

Ты читаешь вообще что тут пишут? Или ты решил в этой теме придумать свою видеокарту? На данный момент никаких аппаратных точек и спрайтов не будет! Можно завести еще один тред и рассказывать там всем какая карта понравилась бы лично тебе.

Так новый графический режим это и есть устройство под названием видеокарта, или можно будет пару ножек перерезать и кусочками мгтф сделать? :)

Alex Rider

06.09.2015, 21:31

Нууу столкновение исторически вычисляется двумя способами
А еще при рендеренге на экран определяется :) И такое есть в существующих играх.
Так новый графический режим это и есть устройство под названием видеокарта
Да, только zst уже придумал архитектуру, которую он хочет сделать на первом этапе. И там нет аппаратных точек и спрайтов. И не будет до тех пор, пока не появится первая работоспособная версия. Идей-то много, реализаторов и поддержаторов не хватает.

s_kosorev

06.09.2015, 21:31

А давай придумаем 5-й способ = 1 + 4? Процессор рисует графику вместе с железом видеокарты? Ведь без разницы же как видеокарта помогает рисовать быстрее - прошивкой ПЛИС или прошивкой процессора?
да блин, кто же запрещает и как правило это само собой разумеющееся
Мы перестаем запоминать фон и восстанавливать его. upd: и передний статический слой тоже
какой профит в играх где фрейм заново рисуется каждый кадр? тот же R-Type
Мы начинаем выводить знакоместо без маски через dup 8: ldi: edup, знакоместо с маской и 4-хцветное знакоместо - через dup 8: ldi: dec e: ldi: edup (а с новой адресацией мы можем так вывести целый столбец спрайта).
маска это для спрайтов, обычно малая часть экрана, для фонов сцен толку 0
Для монохромных спрайтов мы перестаем выводить атрибуты.
Вот где экономия! ну сколько тех атрибутов на спрайт? тоже мизер
С новой адресацией экрана забываем страшный код перехода к новой строке/трети.
Какое планируемое ускорение в 2-3 раза? или хотя бы 2-3%
Перестаем размышлять в рамках известных архитектур, и все начинает получаться!
Да не вижу я архитектуры, кроме списка портов, которые не о чем собсно не говорят, и перечень поротов больше похож на api графической библиотеки, чем интерфейс к железке, регистры, мультикплексоры, декодеры в плис скушают прилично ресурсов, я уже вижу примерно на половину корки AVR занятых ресурсов, причем с сомнительным выхлопом

Nesser

06.09.2015, 21:36

Я в описании ничего не нашёл о том как аппаратно это устройство выглядит, линейная адресация побитовых пикселей может только создать тормоза, так как для перехода на следующую линию придётся делать ADD X,128, то есть обычным inc уже не обойдётся...

---------- Post added at 22:34 ---------- Previous post was at 22:32 ----------

А еще при рендеренге на экран определяется :) И такое есть в существующих играх.

Так это и есть второй способ который я указал :)

---------- Post added at 22:36 ---------- Previous post was at 22:34 ----------

Да не вижу я архитектуры, кроме списка портов, которые не о чем собсно не говорят, и перечень поротов больше похож на api графической библиотеки, чем интерфейс к железке, регистры, мультикплексоры, декодеры в плис скушают прилично ресурсов, я уже вижу примерно на половину корки AVR занятых ресурсов, причем с сомнительным выхлопом

Вот и я говорю что это уже видеокарта а не графический режим :)

zx_

06.09.2015, 21:40

zx-kit

06.09.2015, 21:46

так не бывает, рисовать можно на экране 4 способами
1. Процессором хоста
2. Спрайтовый движок
3. Блиттер
4. Процессор в видеокарте (шейдер)

Теперь, речь идет о ускорении, при этом последние 3 варианта исключаются, каким образом достигается ускорение? Объем данных увеличивается и при этом процессор хоста одновременно быстрее рисует? ну так не бывает.

Ускорение при переделке старых игр достигается за счет таких улучшений:

Аппаратное наложение маски при рисовании спрайта.
Рисование тайлов и спрайтов в разных слоях без перерисовки фона.
Линейная адресация с адреса 0000 без деления экрана на секторы. А это ускорение вычисления адреса и возможность рисования спрайта более быстро другими командами.
Один байт атрибутов вместо 768, что экономит время на вычислении адреса атрибута.
Возможность освободить старую экранную область для оптимизации других задач.

Объем данных не увеличивается. В большинстве игр на каждый байт пикселей итак есть байт маски.

Пример копирования спрайта с маской для стандартного режима (40*8=320 такта):

; hl - адрес спрайта с маской
; de - адрес в области пикселей экрана
dup 8

ld a,(de)
and (hl)
inc l
or (hl)
inc l
ld (de),a
inc d

edupПример копирования спрайта с маской для нового режима с линейной адресацией с адреса 0000 (36*8=288 тактов):

; hl - адрес спрайта с маской
; de - адрес в области пикселей экрана
dup 8

ldi
dec e
ldi

edup
Пример копирования спрайта с маской для стандартного режима с использованием стека (36*8=288)

; стек - адрес спрайта с маской
; hl - адрес в области пикселей экрана
dup 8

pop de
ld a,(hl)
and e
or d
ld (hl),a
inc h

edup

Пример копирования спрайта с маской для нового режима с линейной адресацией с адреса 0000 с использованием стека (28*8=224 тактов):

; стек - адрес спрайта с маской
; hl - адрес в области пикселей экрана
dup 8

pop de
ld (hl), e
ld (hl), d
inc l

edup

Мне кажется Alex_Rider не понимает принципа действия карты, который как мне кажется еще и zst не понимаетВам виднее...

Nesser

06.09.2015, 21:48

ицых с гвоздями!
вот у компьютера Специалист восемь цветов на точку не тормозили совсем процессор
и раскрашивать легко
и всего штук пять дип и немного озу
и схему цветности к чему угодно подключить, порт только выбрать
а в ВГА преобразовать уже совсем другая и решенная задачка

от нищеты люди гораздо лучше придумывали (с)

У него 384*256 ЧЕРНО-БЕЛЫЕ
А цвета только в текстовом режиме
И где ты нам нём 5 DIP увидел?
http://www.old-games.ru/wiki/%D0%A1%D0%BF%D0%B5%D1%86%D0%B8%D0%B0%D0%BB%D0%B8%D 1%81%D1%82_%28%D0%BA%D0%BE%D0%BC%D0%BF%D1%8C%D1%8E %D1%82%D0%B5%D1%80%29

Alex Rider

06.09.2015, 21:50

какой профит в играх где фрейм заново рисуется каждый кадр? тот же R-Type
В таких играх, да никакого профита.

маска это для спрайтов, обычно малая часть экрана, для фонов сцен толку 0
Только вывод спрайтов с маской - довольно жрущая операция (для одного знакоместа):

dup 8
ld a,(de)
and (hl)
inc hl
or (hl)
inc hl
ld (de),a
inc d
edup

Вот где экономия! ну сколько тех атрибутов на спрайт? тоже мизер
Атрибутов на спрайт - мизер, но пересчет координат в адрес атрибута для каждого знакоместа - тоже не мгновенная операция.

Какое планируемое ускорение в 2-3 раза? или хотя бы 2-3%
В среднем по больнице не знаю. Для Саботера могу оценить ускорение процентов в 30 от текущей реализации и процентов 200 от оригинальной (если уж полностью переписывать рендерер)

Да не вижу я архитектуры, кроме списка портов, которые не о чем собсно не говорят

Я в описании ничего не нашёл о том как аппаратно это устройство выглядит
zst, можешь-таки собрать в первом посту не ссылки на топики, а попытаться создать нормальную спецификацию. Ну вот правда не найдешь в этой теме про новую адресацию ничего...
Nesser, планируется сдедать так: если нам нужен байт по координатам x, y (x в знакоместах, y в пикселах), то его адрес - y + x * 256, то есть, в старшем байте пары будет x (0..31), в младшей - y (0..191), соответственно inc/dec - переход к соседним координатам по x и y.

Nesser

06.09.2015, 22:04

А какое устройство будет производить определение коллизии спрайтов? И где будут храниться данные о том какой спрайт сейчас затирается?

---------- Post added at 22:54 ---------- Previous post was at 22:52 ----------

Только вывод спрайтов с маской - довольно жрущая операция (для одного знакоместа):

dup 8
ld a,(de)
and (hl)
inc hl
or (hl)
inc hl
ld (de),a
inc d
edup

А у меня спрайт с маской быстрее выводиться :)

Задача вывести спрайт под номером 217 в координаты 200, 140

LD L,200
LD H,140
LD DE,217
-----------------
LD (204),HL
LD (206),DE

---------- Post added at 23:01 ---------- Previous post was at 22:54 ----------

планируется сдедать так: если нам нужен байт по координатам x, y (x в знакоместах, y в пикселах), то его адрес - y + x * 256, то есть, в старшем байте пары будет x (0..31), в младшей - y (0..191), соответственно inc/dec - переход к соседним координатам по x и y.

То есть по иксу я могу двигать спрайты только с кратность 8 точек? Это чё за прикол такой.

Нуууу ты немного недоучёл...

LD L,191 (Y=0-191)
LD H,10 (X=0-31)

После INC HL будет странная ситуация, X не изменит своего положения а Y уйдёт за пределы экрана, то есть надо ещё и детектировать переход за 191 ???

---------- Post added at 23:04 ---------- Previous post was at 23:01 ----------

В старом экране хотя бы по русски слева-направо и сверху вниз :)
А тут вообще получается сверху-вниз с детекцией выхода и слева-направо с кратностью 8.

Что то тут не так Оо

Alex Rider

06.09.2015, 22:05

А какое устройство будет производить определение коллизии спрайтов? И где будут храниться данные о том какой спрайт сейчас затирается?
Кстати, да, zst, интересный вопрос... А что будет читаться из видеопамяти для при включенной отрисовке слоя? Стандартный экран? Хотелось бы байт, с включенными битами там, где непрозрачно.

А у меня спрайт с маской быстрее выводиться
Неправда твоя. У тебя нет такой видеокарты, в которой так можно сделать. А, если продолжать говорить о том, какая эта карта плохая и никому не нужная, то и ни у кого никогда ее не будет, будут лишь 100500 идей о том, как ее сделать. У zst стальные нервы, надо сказать. Я бы уже на середине темы сказал послал бы всех и, либо забил бы совсем, либо сделал бы как хочется мне. Давай договоримся, что, идеи о том, как сделать другую видеокарту в этой теме будут считаться офтопом и наказываться соответствующе, ok? Никто не запрещает тебе завести рядом тему о том, какая карта на самом деле нужна, глядишь, сообща придумается концепт и найдется тот, кто сделает.

Nesser

06.09.2015, 22:09

С слоями я вообще не догнал, 8 слоёв это аппаратные или программные?
Карта в реальном времени выкидывает поочередно 8 слоёв на экран 50 раз в секунду ?

---------- Post added at 23:09 ---------- Previous post was at 23:08 ----------

Неправда твоя. У тебя нет такой видеокарты, в которой так можно сделать. А, если продолжать говорить о том, какая эта карта плохая и никому не нужная, то и ни у кого никогда ее не будет, будут лишь 100500 идей о том, как ее сделать. У zst стальные нервы, надо сказать. Я бы уже на середине темы сказал послал бы всех и, либо забил бы совсем, либо сделал бы как хочется мне. Давай договоримся, что, идеи о том, как сделать другую видеокарту в этой теме будут считаться офтопом и наказываться соответствующе, ok? Никто не запрещает тебе завести рядом тему о том, какая карта на самом деле нужна, глядишь, сообща придумается концепт и найдется тот, кто сделает.

Я не говорю что это плохая карта :)
Я пытаюсь понять как она работает с точки зрения программиста :v2_dizzy_priest:

zx-kit

06.09.2015, 22:10

Кстати, да, zst, интересный вопрос... А что будет читаться из видеопамяти для при включенной отрисовке слоя? Стандартный экран? Хотелось бы байт, с включенными битами там, где непрозрачно.
Пока чтение для новых режимов не предусмострено, FLASH тоже. Читаться будет стандартный экран или ПЗУ при линейной адресации.

Nesser

06.09.2015, 22:10

Надо же мне понять какой редактор для этого писать :)

Alex Rider

06.09.2015, 22:18

То есть по иксу я могу двигать спрайты только с кратность 8 точек? Это чё за прикол такой.
Это как на Спектруме принято. Скроллировать битыки в байте для попиксельного сроллинга тебе никто не запрещает. Спрайтовы движок будет позже (если автора тут не замучают совсем критикой).
После INC HL будет странная ситуация, X не изменит своего положения а Y уйдёт за пределы экрана, то есть надо ещё и детектировать переход за 191 ???
Ну как бы границу экранной области надо детектить всегда и везде :) inc hl делать в этом режиме совсем не надо, операция бессмысленная и жрет 2 лишних такта.

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

Nesser

06.09.2015, 22:21

Я одного не могу понять, если пытаться вкорячить это в старые игры переделывая им только часть вывода на экран то что измениться? мне лично эти наползания цвета никогда не мешали :)
Кроме того почти во всех играх спрайты ЧЁРНО-БЕЛЫЕ, а атрибуты выставляются принудиловкой после вывода спрайтов, то есть самих цветов то и нет, если накладывать сверху цветовую маску в 2 бита так это увеличение объёма спрайта на 2 раза, был 1 бит ч/б стал 1 бит ч/б+2 бита цвета, то есть надо раздвигать код и скорее всего всё это не влезет в память и придётся делать драйвер страниц. Да и получается что надо делать редактор спрайтов, выковыривать старые и дорабатывать их из 1 бита в 1+2 бита, то есть по сути заново сделать саму игру.
Или я что то не так понял? :)

п.с. не судите строго, я только ЗА :D

Alex Rider

06.09.2015, 22:22

Пока чтение для новых режимов не предусмострено, FLASH тоже.
Ну чтение, хрен с ним, нужно только для определения столкновений во время отрисовки, не велика поетря с учетом того, что такой способ не дает ответа на вопрос "с чем столкнулись". А что будет делать бит FLASH в 2-цветном режиме? Поднимать яркость PAPER'а? Кстати, в стандартном режиме (с выключенной фкнуциональностью совсем и в слое стандартного экрана) FLASH надо сделать обязательно, ибо придется что-то мудрить в играх, где FLASH используется. Не хотелось бы его делать программно.

Nesser

06.09.2015, 22:27

В старом режиме (с кратностью 8) надо еще и переход через трети детектить на кажом сдвиге на одно знакоместо вниз, а по пиксельным строкам вообще только на 7 ниже можно опуститься без фокусов :)

У меня всегда была таблица адресов по Y - 384 байта, никогда с этим не заморачивался :)

---------- Post added at 23:27 ---------- Previous post was at 23:23 ----------

Вот посмотри
http://zxaaa.untergrund.net/view_demo.php?id=4898
Я делал хер знает когда, только не ржите, графику не я рисовал :)
С адресацией Y никогда проблем не было :D

Alex Rider

06.09.2015, 22:33

Я одного не могу понять, если пытаться вкорячить это в старые игры переделывая им только часть вывода на экран то что измениться?
Вырастет скорость отрисовки. Исчезнет клешинг. Это уже немало.
Кроме того почти во всех играх спрайты ЧЁРНО-БЕЛЫЕ, а атрибуты выставляются принудиловкой после вывода спрайтов, то есть самих цветов то и нет, если накладывать сверху цветовую маску в 2 бита так это увеличение объёма спрайта на 2 раза, был 1 бит ч/б стал 1 бит ч/б+2 бита цвета, то есть надо раздвигать код и скорее всего всё это не влезет в память и придётся делать драйвер страниц.
Возможно. Не обязательно переделывать все спрайты, возможно, пепекраска лишь некоторых спрайтов (особенно, статичных) сделает игру намного красивше. Если будут реализованы палитры, можно будет еще больше разнообразить игры в плане цветов (как в ULA+, например). Собственно, карта позволяет переделывать игру постепенно: сначала убрали клешинг и разогнали, потом переделали графику обрамления экрана, потом раскрасили ГГ... Частые релизы с небольшими изменениями подпитывают интерес к переделке и позволяют собрать больше мнений сообщества. Можно действительно допеределываться до того, что старого кода и не останется совсем :) Лишь бы людям было интересно.

Да и получается что надо делать редактор спрайтов, выковыривать старые и дорабатывать их из 1 бита в 1+2 бита, то есть по сути заново сделать саму игру.
Ну, переделка спрайтов и создание игры с нуля - это совсем разные вещи. Не уверен, что нужно будет делать редактор, но какие-то перекодировачные тулы писать придется, да. Собсна, как и при любой переделке графики с изменением глубины цвета.

---------- Post added at 22:33 ---------- Previous post was at 22:30 ----------

Вот посмотри
Неплохо :)
У меня всегда была таблица адресов по Y - 384 байта, никогда с этим не заморачивался
Выход за пределы этой таблицы же тоже надо контроллировать, правильно? И inc hl на 31-м столбце тоже. Так что у zst как минимум не хуже, только таблица не нужна от слова "совсем"

zx-kit

06.09.2015, 22:39

О линейной адресации байтов на экране

Для новых режимов графики в дополнительных слоях 1-8 адресация байтов на экране линейная, экран располагается с адреса 0000 и занимает 8 KB.
Если в hl записан адрес байта, то для перехода к байту справа надо выполнить команду inc h, для перехода к байту снизу - inc l.

Преимущество линейной адресации:
Проще и быстрее вычислять адрес байта на экране.
Нет деления экрана на трети/секторы.
Для копирования/стирания тайлов/спрайтов можно использовать более эффективные комбинации команд Z80.
Можно выводить тайлы/спрайты/буквы с точностью до пиксела по-вертикали.
В дальнейшем можно будет увеличить разрешение экрана до 320х240 точек.

При линейной адресации экрана с адреса 0000:
Первый столбик байтов имеет адреса 0000, 0001, ... 00BF.
Второй столбик - 0100, 0101, ... 01BF.
Последний столбик - 1F00, 1F01, ... 1FBF.

Nesser

06.09.2015, 23:00

Так это уже не линейная адресация а НЕлинейная :)
Линейная это когда номер пикселя совпадает с адресом, а тут получается 192*32 ?
А 320*240 это 240*40 ?
Я так и не понял а как вычислять смещение пикселя в байте? программно?

---------- Post added at 23:57 ---------- Previous post was at 23:55 ----------

Эээээ а как считывать байт? считается пзу ?

---------- Post added 07.09.2015 at 00:00 ---------- Previous post was 06.09.2015 at 23:57 ----------

И я не понял как это переделывать игру постепенно ? :)
Она или переделывается сразу и полностью или делается заново с модульным строением для добавления новых функций "видеорежима".

Alex Rider

06.09.2015, 23:47

Так это уже не линейная адресация а НЕлинейная
Никто и не спорит

Я так и не понял а как вычислять смещение пикселя в байте? программно?
Да

Эээээ а как считывать байт? считается пзу ?
Пока да. Надеюсь, потом уговорю zst читать что-то вразумительное из текущего слоя.

И я не понял как это переделывать игру постепенно ?
Она или переделывается сразу и полностью или делается заново с модульным строением для добавления новых функций "видеорежима".
Откуда инфа?
В чем я вижу плюс "Метеора" - в том, что игру можно переделывать именно постепенно. Потому что непеределанный код работает так же, как и раньше - пишет в стандартный слой, соответствющий видеорежиму Спектрума. Захотели отрисовать что-то по-другому, переделали кусочек, наслаждаемся результатом. Потренировались на статике, переделали передний слой, потом ГГ, потом врагов, в общем, как хочешь. Остальные реализованные видеорежимы требуют переделки всей отрисовки сразу. Ну, может быть, в TS-Conf из-за строчных прерываний можно оставить, к примеру, какую-то часть экрана срандартной и переделать, скажем, какую-нить приборную панель внизу.

Nesser

07.09.2015, 00:13

А чё экран боком? :)

Nesser

07.09.2015, 08:37

Для такой простой графики не много ли 2 проца по 4 МГц ? :)

zx-kit

07.09.2015, 16:25

Так это реально работающий проект на z80, а то что здесь намечтали уже работает?

А игры там можно модернизировать/писать ? Или это совсем со Спектрумом не связано ?

zst, у тебя на Specy2010 заработала тестовая конфигурация?
Я пока железом и кодированием не занимался. Только синхроимпульсы VGA на VERILOGе. Твои проекты слишком сложные и не подходят мне. Надо будет все видеорежимы писать с нуля. Сейчас я пока мечтаю, проектирую режимы, а кодированием займусь потом.

---------- Post added at 18:25 ---------- Previous post was at 18:10 ----------

Предлагаю сделать палитру в 512 байт (коли 16 бит на цвет). Загружать по ldir в некую область ПЗУ, во время записи карта будет вычитвать палитру (желательно менять палитры динамически, чтобы можно было иметь разные палитры в разных локациях; желательно иметь возможность менять любой цвет в палитре, можно будет делать fade-in-эффекты).
Как адресовать палитры:
1 цвет - атрибут слоя задает номер цвета в палитре (0-255), номер палиты слоя не используется.
2 цвета - номер палитры слоя (старшие 4 бита) задают одну из 16 палитр, из которой выбираются цвета INK и PAPER (0-7), включенный бит BRIGHT означает, что к номеру цвета INK добавляется 8. После сброса номер палитры для такого режима - 0, а сама палитра инициализируется стандартными цветами Спектрума (16 одинаковых 16-цветных палитр). Кстати, бит Flash будет поддерживаться?
2 цвета + прозрачный - то же, что и 2 цвета, но цвет №0 - прозрачный (так же и для 3, 7 и 15 цветов).
3,4 цвета - каждая пара бит кодирует один из четырех цветов одной из 64 палитр, номер (смещение 1-го цвета) которой задают 6 старших бит номера палитры слоя.

Очень хочется вот этот функционал сразу. Объясню почему: избавление игр от клешинга не дает такой wow-эффект, как появление коричневенького, оранжевенького или сиреневенького хотя бы на статичной рамке экрана в игре :)
512 байтов - это наверно для палитры VGA, для остальных на 2-4 бита по 256 отдельных палитр, расположить во внутреннем ОЗУ SDRAM.

На первом этапе в слоях будут использоваться номера цветов от 0 до 15, соответствующие стандартным цветам. Только вместо темного черного с номером 0 будет писаться в слой яркий черный с номером 8. Зачем нам два черных ? А номер 0 - будет для прозрачного цвета.

Как говорили в этой теме MVV и другие - надо сначала сделать что-то простое. Сразу то все не получится. Вот к этим номерам для каждого слоя потом можно добавить старшие 4 бита номера палитры для слоя. Тогда номера цветов при выводе в буфер экрана будут от 0 до 255.

Сменой номера палитры слоя и 15 цветов в этой палитре можно делать затемнение или использовать для этого палитру VGA.

А палитра VGA 255 -> 32768 будет общая для точек из буфера экрана. С другой стороны, 255 цветов на экране может не хватить в будущем. И надо об этом подумать сейчас. Может важнее затемнений возможность рисовать в каждом слое со своей палитрой 255 -> 32768.

Переменная attribute не очень подходит для разных режимов цвета. Наверно надо сделать несколько переменных для разных режимов:
1 цвет - color - номер цвета 0-15 (в дальнейшем до 255)
2 цвета - attr - атрибут как в стандартном режиме, только FLASH не используется
3-4 цвета - pl2bit - номер двухбитной палитры
7-8 цветов - pl3bit - номер трехбитной палитры
15-16 цветов - pl4bit - номер четырехбитной палитры

Надо подумать как сделать так, чтобы после сброса все палитры показывали стандартные цвета. Наверно палитры с номером 0 делать аппаратные со станlартными цветами, а палитры 1-255 уже в ОЗУ.

Окно размером 256 или 512 байтов во области ПЗУ можно выделить для загрузки палитр. Теперь надо выбрать, как указывать, какую палитру мы загружаем для каждого режима.

Nesser

08.09.2015, 08:04

А палитра VGA 255 -> 32768 будет общая для точек из буфера экрана. С другой стороны, 255 цветов на экране может не хватить в будущем. И надо об этом подумать сейчас. Может важнее затемнений возможность рисовать в каждом слое со своей палитрой 255 -> 32768.

Дык не проще сделать тупо по 16 бит на точку, а все перепаковки предварительно сделать программно?
Я боюсь всех этих палитр, смахивает на сжатый bmp, только тут его походу придётся пережимать в реальном времени на каждый пиксель :)

Reobne

08.09.2015, 12:45

Я думаю не надо ничего боятся. Система "Метеор График" взлетит, если найдутся благожелательные люди, которые будут хорошо понимать её, хорошо разбираться в чужом коде. Светлые хакеры-адаптатеры. Создатель игры делает версию для 128К, выражает желание получить версию под метеор. Возможно даёт расширенные ресурсы, более многозветную графику и спрайты, может и звук. И через какоето время оценивает результат.

А если ещё какие-нибудь среды разработки игр (чурера, AGD) смогут компилировать игру, которая при запуске детектит "Метеор" и патчует игру для его использования. Это-же вообще бум будет! :)

А палитры - хорошее дешёвое средство, для некоторых игровых и демонстрационных применений. Как сделать мигающие точки врагов на карте? Либо ты перерисовываешь пиксели, либо рисуешь их мигающим цветом. Как легко сделать, чтобы одни и те же униты красного игрока имели на спрайтах красные флаги, а синего игрока - синие флаги. Нарисовать бегущую каёмочку. Бегущий ручеёк.
Больше возможностей и только один недостаток - надо уметь этим пользоваться, и не ленится делать инструменты для конвертации. :)

---------- Post added at 16:28 ---------- Previous post was at 15:47 ----------

Может даже ещё упростить проект. Смотрите:
16 бит на пиксель.
8 палитр 256 цветов (по 24 бита 8r8g8b или 15 бит 5r5g5b или 16 бит 8wite4[-r]4[-b] неважно)
4 настройки режима отображения на выбор. В настройке режима просто номера пикселей, для формирования байта цвета. 4 Варианта 8-ми четырёхбитных значений. 4*8*4=128 бит=16 байт

Настроил их, и переключай в игровом процессе.
допустим, режим 0 видим фон (биты 12,13,14,15) и спрайты первого экрана (0,1,2,3). 8 бит идут адресом в палитру. Цвет получаем и пиксель готов. То что бит 12 означает будет ли фон перед спрайтом или за ним заложено при формировании палитры.

Выбираем 2 палитры (одну из восьми) палитру для рисования и палитру для отображения.
Про палитру отображения уже понятно.

Инструмент. При записи в ПЗУ, карта помня адрес прошлой записи в ПЗУ если ячейка та-же, то циклически пишет принятый байт в 8-ми байтовый буфер кисти. Если адрес другой, то скидывает буфер в нужные пиксели, согласно палитре инструмента (для каждого пикселя 8 бит из каждого соответствующего бита байта буфера кисти :) ) Логика работы инструмента прописана при программировании кода, заполняющего палитру. На выходе из палитры 16 бит маски - какие пиксели менять и 16 бит значений. (возможны варианты)

Допустим 8 инструментов прописали при инициализации игры, и переключаем их в зависимости от того, рисуем ли мы спрайт на первый слой, на второй слой, рисуем ли мы фон, рамку, задаём ли уровень фона (перед спрайтами или за).

На первых порах даже такая минимальная конфигурация позволит переделать много игр, устранить клешинг, немного добавит эффектов и новых цветов. И вроде не очень сложно для понимания, вот я одним залпом придумал и написал. В моей голове вроде пока всё сходится, конечно будут нюансы, но ворожу что решаемы. :)

Имея такую простую карту, уже можно отработать схемы: выход VGA, перехват факта записи из Z80 в ПЗУ. Убедиться что эти части работают. Посмотреть скольких людей мы заинтересуем, которые изучат возможности и сделают переделки игр, или новые. То есть откусим хороший кусок от конечного продукта.

Кусать надо так, чтобы можно было прожевать. :)

---------- Post added at 16:45 ---------- Previous post was at 16:28 ----------

Допустим у нас магазин трусов, и приходят клиенты, жалующиеся, что нет карманов, коротко, ткань тонкая нет петелек для ремня и ширинка не на молнии. Ребята, вам в магазин брюк. :)

Nesser

08.09.2015, 14:17

А палитры - хорошее дешёвое средство, для некоторых игровых и демонстрационных применений. Как сделать мигающие точки врагов на карте? Либо ты перерисовываешь пиксели, либо рисуешь их мигающим цветом.

Для этого достаточно регистров, необязательно делать палитру :)

- Я чего то не догоняю, так это видеорежим или средство хранения номеров спрайтов?

- 8 планов это же увеличение памяти в 9 раз?

- Чтобы устройство наложило план на план оно должно посмотреть есть ли в пикселе прозрачность и в случае если она есть то считать пиксель с предыдущего плана, посмотреть его номер после чего обратиться в палитру что бы узнать по этому номеру цвет и внести на экран это пиксель а если и в предыдущем плане стояла прозрачность то надо будет сделать это 7 раз для всех планов? и так 2 457 600 раз в секунду, то есть должно производится не менее 40 миллионов циклов в секунду? и это без учёта сканера экрана, регенерации памяти и сторонних операций с памятью?

Reobne

08.09.2015, 15:28

MVV,
Я уже часть задумок реализовал на U16, и могу сказать, что всё что здесь навыдумывали практически не заработает )
Круто. :)
Если не заработает, то: "Я-же говорил!"
Если заработает, то : "Во как я вас отмотивировал, через спортивную злость! Вы даже невозможное сделали! А без меня-бы всё протухло!" :)

---------- Post added at 18:43 ---------- Previous post was at 18:28 ----------

zst, Как вообще планы? Какие-то этапы на какие-то сроки намечены?

---------- Post added at 19:28 ---------- Previous post was at 18:43 ----------

Nesser, Что-то тоже не догоняю, если вопросы ко мне, то к какой части моего сообщения? Я вроде не писал про номера спрайтов, об этом zаботится Z80, согласно задумке zst.
Я не писал про 8 планов. 256x192 16 бит на пиксель и всё. Один широкий слой, а не 8. Нужные для режима 8 бит берутся согласно установкам режима отображения, проходят через активную смеситель-палитру (одну из восьми в памяти палитр , выбранную для текущего кадра). Палитр в памяти, да восемь. 256 по 32бита каждая. (всего 8 килобайт) Все 32 бита используются для палитры инструмента (16 бит маска и 16 бит значения, для изменения пикселя), Для отображения можно меньше. Возможны варианты. Если по 16 бит (5 красных, 6 зелёных,5 синих), то, можно в два раза больше палитр отображения. Какие банки памяти палитр как использовать решает хакер-адаптант, согласно задаче.
Прозрачности и прочие эффекты закладываются в логике палитры отображения. Карта об этом вообще не думает.

zx-kit

08.09.2015, 17:01

Я думаю не надо ничего боятся. Система "Метеор График" взлетит, если найдутся благожелательные люди, которые будут хорошо понимать её, хорошо разбираться в чужом коде. Светлые хакеры-адаптатеры. Создатель игры делает версию для 128К, выражает желание получить версию под метеор. Возможно даёт расширенные ресурсы, более многозветную графику и спрайты, может и звук. И через какоето время оценивает результат.

А если ещё какие-нибудь среды разработки игр (чурера, AGD) смогут компилировать игру, которая при запуске детектит "Метеор" и патчует игру для его использования. Это-же вообще бум будет! :)

А палитры - хорошее дешёвое средство, для некоторых игровых и демонстрационных применений. Как сделать мигающие точки врагов на карте? Либо ты перерисовываешь пиксели, либо рисуешь их мигающим цветом. Как легко сделать, чтобы одни и те же униты красного игрока имели на спрайтах красные флаги, а синего игрока - синие флаги. Нарисовать бегущую каёмочку. Бегущий ручеёк.
Больше возможностей и только один недостаток - надо уметь этим пользоваться, и не ленится делать инструменты для конвертации.

http://s019.radikal.ru/i639/1506/36/f2bf9b657467t.jpg (http://s019.radikal.ru/i639/1506/36/f2bf9b657467.png)
Палитра как у MSX2+ 32K цветов при 15-битном RGB 5+5+5

Хорошие идеи. Еще предлагали делать затенение/затуманивание слоя фона, а спрайт героя при этом чтобы оставался без изменений. Также писали про переливающееся защитное поле. Надо составить список всех возможных применений. Это может пригодиться для написания демы.

Давайте начнем проектирование второй ступени расширения видеорежимов. Предлагаю добавить палитры и скроллинг фона. Это поможет заложить возможность расширения при реализации 1 ступени. Там кое-что уже прояснилось с реализацией, а некоторые вещи еще непонятно, как сделать в FPGA. Сроки выхода видеокарты прогнозировать сложно - разработка новых режимов не простая штука.

Выбираем 2 палитры (одну из восьми) палитру для рисования и палитру для отображения.
Мне понравилось деление палитр на два типа. Одна палитра нужна для преобразования цветов нарисованного слоя - это палитра для отображения. На каждый слой нужна своя палитра, одна для фона, другая для ГГ и т.п. Значит надо 8 палитр для отображения на VGA. Кроме этого при переходе с одного уровня на другой цвета местности могут меняться, например зеленая трава, лес, вода меняется на лед, камни и т.п. То есть палитру будем иногда перезагружать.

При рисовании в режиме с двумя битами на точку нужна палитра для рисования. Она будет преобразовывать 2 бита в номер цвета из 8 битов. Палитра для рисования может быть одна. Но лучше один раз настроить несколько палитр, а потом только выбирать нужную по номеру палитры pl2bit.

Reobne

08.09.2015, 17:11

Сроки выхода видеокарты прогнозировать сложно
Это я спросил в свете "Ничего не будет" от MVV. Если не определить срок, после которого он смог-бы сказать: "Ага! Не получилось! :)", то ему останется только ждать признания автора себя побеждённым, и периодически напоминать, что он с жаждой этого ждёт. :)

zx-kit

08.09.2015, 17:13

Это я спросил в свете "Ничего не будет" от MVV. Если не определить срок, после которого он смог-бы сказать: "Ага! Не получилось! :)", то ему останется только ждать признания автора себя побеждённым, и периодически напоминать, что он с жаждой этого ждёт. :)
Мы не на соревнованиях. Пусть разрабатывает свою видеокарту. Напишет, что хочет сделать. Кому это может понадобиться. Посмотрим, как он будет укладываться в сроки. Как его будут поддерживать или критиковать.

Reobne

08.09.2015, 17:15

На каждый слой нужна своя палитра
Или я непонятно говорю, что имею ввиду 16 бит на пиксель всего. А слои - не слои это уже закладывает хакер-адаптактер, в логике заполнения палитры отображения. Хоть 2 слоя по 8 бит, хоть 16 слоёв по 1 бит. В любых сочетаниях.
Либо ты имеешь ввиду уже полный режим "Метеор графикс", а не предложенный мной "первый укус", "Метеор графикс--"

zx-kit

08.09.2015, 17:19

Или я непонятно говорю, что имею ввиду 16 бит на пиксель всего. А слои - не слои это уже закладывает хакер-адаптактер, в логике заполнения палитры отображения. Хоть 2 слоя по 8 бит, хоть 16 слоёв по 1 бит. В любых сочетаниях.
Либо ты имеешь ввиду уже полный режим "Метеор графикс", а не предложенный мной "первый укус", "Метеор графикс--"
Я там ничего не понял. У нас в каждом слое точка кодируется одним байтом. Это дает возможность использовать на слое до 255 цветов. При рисовании на каждые 8 точек Z80 записывает данные байтами . Обычно по 2 бита на точку. При этом использует палитры для рисования, где выбирает, какими тремя цветами идет рисование.

Reobne

08.09.2015, 17:35

zx-kit

08.09.2015, 19:04

zst, Ещё разок, конкретнее, поясню. Я предложил совсем простой режим. Я всё его описание легко держу в голове. Если плохо-непонятно выражаю, извиняете, может в диалоге уточню. Этот "Метеор графикс--" Для отработки системы перехвата записи в область ПЗУ. Для отработки системы генерации VGA. Пробные демочки можно сделать. Отработать с реальным кодом на Z80. Попробовать обесклешить игру, если получится. Чисто для тестов, пробный зонд, спутник пик-пик, а там видно будет. Может и это не осилим, и ракета упрётся в "небесную твердь". :) (Думаю навряд ли)
Были такие скоростные теплоходы "Метеор" и "Ракета". Предлагаю твою видеокарту назвать "Ракета".

http://i004.radikal.ru/1509/4f/134540f792eat.jpg (http://i004.radikal.ru/1509/4f/134540f792ea.png) http://s020.radikal.ru/i710/1509/19/93c05a0b4373t.jpg (http://s020.radikal.ru/i710/1509/19/93c05a0b4373.jpg) http://s014.radikal.ru/i327/1509/12/267ac446e547t.jpg (http://s014.radikal.ru/i327/1509/12/267ac446e547.jpg) http://s003.radikal.ru/i202/1509/c7/f5b690663cdat.jpg (http://s003.radikal.ru/i202/1509/c7/f5b690663cda.jpg)

Reobne

08.09.2015, 19:16

zst, Эх, я уже завёл тему (http://zx-pk.ru/showthread.php?p=826905#post826905), пока там ничего ценного, немного по бла-блакал. Но вдруг чего получится. Буду скидывать свои фантазии туда, и там отвечать на вопросы, чтобы тут меньше путаться и мешаться. :)

---------- Post added at 23:16 ---------- Previous post was at 23:14 ----------

Если "Метор Графикс" твоя торговая марка, то переименую, по первому сигналу. :)

zx-kit

09.09.2015, 18:18

Если "Метор Графикс" твоя торговая марка, то переименую, по первому сигналу. :)
Запланирована такая видеокарта и про ее разработку уже две темы - в Software и Hardware. Чтобы не было путаницы лучше вам другое название придумать.

Режимы графики оптимизированы с учетом прозрачного цвета:

COLOR3C и COLOR4 объединяются в COLOR4P.
COLOR7C и COLOR8 объединяются в COLOR8P.
COLOR15C и COLOR16 объединяются в COLOR16P.

2 бита на цвет точки:

COLOR4P - 4 цвета на 8 точек
По соответствующему адресу в области пикселей нужно записать подряд 2 байта данных. На каждую из восьми точек приходится по 2 бита из разных байтов.
В палитре рисования 4 цвета от 1 до 255 и 0 прозрачный. Номер палитры в переменной pl4.

3 бита на цвет точки:

COLOR8P - 8 цветов на 8 точек
По соответствующему адресу в области пикселей нужно записать подряд 3 байта данных. На каждую из восьми точек приходится по 3 бита из разных байтов.
В палитре рисования 8 цветов от 1 до 255 и 0 прозрачный. Номер палитры в переменной pl8.

4 бита на цвет точки:

COLOR16P - 16 цветов на 8 точек
По соответствующему адресу в области пикселей нужно записать подряд 4 байта данных. На каждую из восьми точек приходится по 4 бита из разных байтов.
В палитре рисования 16 цветов от 1 до 255 и 0 прозрачный. Номер палитры в переменной pl16.

Nesser

10.09.2015, 00:25

Я может слишком груб, но разве VGA не прошёл этот путь с палитрами в течении 20 лет? :)
В итоге осталось только прямое управление от пикселя к цап )

---------- Post added at 01:25 ---------- Previous post was at 01:24 ----------

И где хранить палитры по 8кБ ? :)
Планировалось же уменьшение размеров а тут сама палитра больше экрана :)

zx-kit

10.09.2015, 05:20

Я может слишком груб, но разве VGA не прошёл этот путь с палитрами в течении 20 лет? :)
В итоге осталось только прямое управление от пикселя к цап)

Вы не учитываете, что с 1982 года скорость Z80 осталась без изменений 3.5 MHz. А палитра дает ускорение, перекрашивая 1 или несколько бит в нужный цвет. Для прямого указания цвета потребовалось бы писать 15 бит, что увеличило бы объем спрайтов в 15 раз и уменьшило бы скорость вывода почти во столько же раз.

И где хранить палитры по 8кБ ? :)
Планировалось же уменьшение размеров а тут сама палитра больше экрана :)Палитры и слои находятся в памяти видеокарты. Они не занимают основную память 48КB-128КB-1MB компьютера. Запись в слои происходит через адреса стандартного экрана 4000 или линейного экрана с адреса 0000. Запись в палитры через область графических переменных по адресам ПЗУ.

Добавлены новые режимы для 1 бита на цвет точки COLOR2P и COLOR2MP. Отличаются от COLOR2 и COLOR2M тем, что цвет точки определяется не аппаратными стандартными цветами по переменной attr, а берутся из двухцветной палитры. Номер палитры в переменной pl2. То есть в палитре с номером pl2 находятся 2 байта. Один задает цвет бита 0, другой - цвет бита 1. Цвета могут быть от 0 до 255.

---------- Post added at 07:20 ---------- Previous post was at 05:42 ----------

Палитры отображения.

Палитра отображения преобразовывает логический цвет из 8 битов с номером 1-255 слоя в физический цвет, задаваемый 15 битами. Для каждого из слоев можно установить свою палитру отображения. После сброса для каждого слоя задана палитра с номером 0. Это аппаратная палитра, которая отображает цвета 1-15 в стандартные цвета Спектрума на экране монитора.

Reobne

10.09.2015, 05:33

Чтобы не было путаницы лучше вам другое название придумать.
Я-то имел ввиду, что --, как-бы декремент. По аналогии С++, где ++ это инкремент. Ну ладно.
Подумал. Мне лично нравится ZXПирит, по английски ZXPyrite. Нормально будет? Две буквы ZX никто не считает своей торговой маркой? Пирита ещё не было? :)

Погуглил, вроде ерунда какая-то ищется.

Alex Rider

10.09.2015, 07:34

После сброса для каждого слоя задана палитра с номером 0. Это аппаратная палитра, которая отображает цвета 1-15 в стандартные цвета Спектрума на экране монитора.
Все-таки, цвета 0-15. Причем, без серого. Чтобы игры не колбасило когда такую палитру включаешь для слоя без переделки графики.

Мне лично нравится ZXПирит
Пирит - серный колчедан (FeS). Конечно, на нерусском оно звучит как-то по огненному, но ты и правда хочешь, чтобы за картой закрепилось прозвище "колчедан"?

Reobne

10.09.2015, 07:47

Пирит - серный колчедан
Колчедан. Нормально. Пойдёт. Мне сам кристалл нравится. Вселенская красота, логика и упорядоченность. У меня парочка есть. Любуюсь.

zx-kit

10.09.2015, 19:05

Все-таки, цвета 0-15. Причем, без серого. Чтобы игры не колбасило когда такую палитру включаешь для слоя без переделки графики.

Я предлагаю такую аппаратную палитру отображения для стандартных цветов с учетом прозрачного:

http://s017.radikal.ru/i402/1509/57/a646a97c2938t.jpg (http://s017.radikal.ru/i402/1509/57/a646a97c2938.png) http://s013.radikal.ru/i322/1509/82/c1fbefa8c3c4t.jpg (http://s013.radikal.ru/i322/1509/82/c1fbefa8c3c4.png)

zx_

10.09.2015, 22:13

мысли о колчедане
прост и быстр и. красив!
использовать кеш 16 кб статики для памяти кода цвета
вот, по такому принципу
http://www.spetsialist-mx.ru/index23.html

или есть две экранных области в 128
еще две экранных области по принципу профпзу
в статическом рам
и вывод на экран
не только в глубину, но еще и в ширину и высоту , разное разрешение

не хочу 256 кб видеорам и цплд!
)
вечерний приход, типа эврики

Nesser

10.09.2015, 22:34

Палитры и слои находятся в памяти видеокарты. Они не занимают основную память 48КB-128КB-1MB компьютера. Запись в слои происходит через адреса стандартного экрана 4000 или линейного экрана с адреса 0000. Запись в палитры через область графических переменных по адресам ПЗУ.

Так и где всё таки хранить палитры? На диске? И подгружать их с диска в видеокарту использую cpu ? А как тогда переделывать старые игры? :) 7 кБ игра и 24 кБ палитры? :)
Не слишком ли навороченная карта для вывода 2-х цветного спрайта ? :)

Alex Rider

11.09.2015, 02:56

Я предлагаю такую аппаратную палитру отображения для стандартных цветов с учетом прозрачного:
Да черт его знает как правильнее... Надо подумать. Основной как бы посыл - при переключении в такой режим не должно быть необходимости сразу перепахивать всю графику.

zx-kit

11.09.2015, 05:17

использовать кеш 16 кб статики для памяти кода цвета вот, по такому принципу http://www.spetsialist-mx.ru/index23.html

В Метеоре применяется почти такой же способ формирования цвета, как в контроллере цвета Специалиста, только разрешение экрана остается 256х192 для совместимости со старыми играми:

КОНТРОЛЛЕР ЦВЕТА ДЛЯ ПК "СПЕЦИАЛИСТ_МХ" В состав компьютера был введён контроллер цвета, допускающий 16 цветов на точку при разрешении 384 х 256 точек и имеющий своё собственное ОЗУ. Появилась возможность создавать "цветные" программы.
Основным отличием данной версии от предыдущих является наличие собственного порта цвета, реализованного на регистрах D1, D2. Это существенно облегчило программную поддержку контроллера цвета. Код цвета записанный в контроллер постоянно хранится в нём. При записи информации в экранную область памяти, код цвета из регистров порта параллельно записываются в ОЗУ цвета на элементах D3...D10. При отображении информации на экране монитора, одновременно с извлечением из видео ОЗУ байта посылки (8 горизонтальных точек), из ОЗУ цвета извлекается код цвета и фиксируется в регистре D12. Далее, при выводе битов полок видеоизображения на экран, код цвета записывается в регистры D13, D14.Отдельное ОЗУ в видеокарте Метеор. В режиме COLOR2 в качестве порта цвета используется переменная attr. Режим экрана с линейной адресацией также похож на адресацию Специалиста. При увеличении младшего адреса с 0 до 191 экран заполняется вертикальными столбиками из горизонтальных байтов. Для перехода к следующему столбику надо увеличить адрес старшего байта.

Если бы Синклер не добавил в атрибут бит FLASH, то у нас тоже было бы по 16 цветов для PAPER и INK, как в Специалисте. Но видимо, не подумали об этом тогда. А сейчас уже ничего не изменить - игры написаны под стандартный байт атрибута. Но в Метеоре мы можем использовать режим COLOR2P, где PAPER и INK круче, чем в Специалисте, по 8 бит на цвет !

---------- Post added at 06:20 ---------- Previous post was at 06:00 ----------

Так и где всё таки хранить палитры? На диске? И подгружать их с диска в видеокарту использую cpu ? А как тогда переделывать старые игры? :) 7 кБ игра и 24 кБ палитры? :)
Не слишком ли навороченная карта для вывода 2-х цветного спрайта ? :)
После RESETа все цвета стандартные, используются аппаратные палитры для совместимости. Для устранения клешинга атрибутов палитры загружать не надо. Если в игре нужно использовать свою палитру - ее можно загрузить в загрузчике. Естественно все данные игры лежат на диске и их в начале игры загружают в ОЗУ, только палитры в ОЗУ видеокарты. Палитра не занимает ОЗУ компьютера - она в ОЗУ видеокарты Метеор.

---------- Post added at 06:25 ---------- Previous post was at 06:20 ----------

Да черт его знает как правильнее... Надо подумать. Основной как бы посыл - при переключении в такой режим не должно быть необходимости сразу перепахивать всю графику.
В Спектуме 15 цветов из 16 возможных. Два одинаковых цвета 0 и 8. Видеокарта при записи в память слоя цвет 0 преобразовывает в 8. То есть получаются цвета 1-15. На мониторе при этом все цвета останутся стандартными.

---------- Post added at 06:40 ---------- Previous post was at 06:25 ----------

В режиме COLOR2P видеокарта Метеор получает байт, который Z80 записывает в область пикселов экрана. Если бит 0, то в ОЗУ видекарты записывается байт цвета для 0 бита, если 1 - записывется байт цвета для 1 бита. Цвета берутся из палитры для рисования с номером в переменной pl2. Один байт для цвета бита 0, другой для цвета бита 1. Это позволит перекрашивать игры в момент рисования на экран в требуемые цвета. Можно использовать одну палитру, постоянно меняя два байта для выбора цвета или в загрузчике игры загрузить несколько палитр, а в игре выбирать номер соответствующей палитры.[COLOR="Silver"]

zx_

11.09.2015, 21:58

у Вектора еще была (есть) быстрая графика
http://emu80.org/dev/dev_v.html

в копилку идей, тс
схемотехнику при медленном проце

zx-kit

12.09.2015, 07:08

у Вектора еще была (есть) быстрая графика
http://emu80.org/dev/dev_v.html

в копилку идей, тс
схемотехнику при медленном проце
Спасибо, но в Векторе режимы не имеют особых преимуществ перед режимами Метеора:

В БПЭВМ "Вектор-06Ц" используется общая оперативная память для микропроцессора и контроллера графического дисплея объемом 64Кбайта. Объем экранного ОЗУ, при числе адресуемых точек изображения 256х256 и 16-и цветах, равен 32Кбайт.

Метеор не занимает основную память.

Для удобства описания экрана он делится на 4-е плоскости.
Таблица плоскостей экранного ОЗУ :
¦ Адресное ¦ Номер ¦
¦ пространство ¦ плоскости ¦
¦ E000-FFFF ¦ 0 ¦
¦ C000-DFFF ¦ 1 ¦
¦ A000-BFFF ¦ 2 ¦
¦ 8000-9FFF ¦ 3 ¦

В Метеоре 8 дополнительных слоев и у всех одинаковые адреса пикселей c 0000 или 4000.

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

В Метеоре также.

Вся плоскость графического экрана состоит из 8-и точечных черточек. Самому младшему адресу "черточки" соответствует левая нижняя черточка. Следующая черточка расположена над ней и т.д. до самого верха (8000H-80FFH). Черточка с адресом 8100Н геометрически расположена правее черточки с адресом 8000Н. Адрес самой верхней правой черточки в этой плоскости - 9FFFH.

В Вектрое байты идут снизу-вверх. В Метеоре в линейном режиме L=0 - это верхний байт в столбике, L=191 - это нижний байт. Также как в Специалисте.

каждой геометрической точке экрана соответствует по одному биту в каждой из 4-х плоскостей. Эти четыре бита и определяют номер цвета 0-15
В Метеоре также - от 1 до 4 битов на точку.

аппаратная поддержка вертикального сдвига отображаемой информации

А вот над этим надо подумать. Как в Метеор на второй ступени расширения графических возможностей добавить аппаратный скроллинг.

zx-kit

12.09.2015, 09:28

256 точек по-горизонтали это 32 столбика байтов с номерами 0-31 в старшем байте. Чтобы создать иллюзию сдвига экрана надо задавать смещение от 0 до 7. При 0 - смещения нет.

Скроллинг влево.
При смещении 1 бит D7 в левом байте не виден, зато появляется бит D7 в байте из столбика 32. Перед сдвигом фона влево надо заполнить дополнительный столбец 32 тайлами фона.

Скроллинг вправо.
Также предварительно заполняем тайлами 32 дополнительный столбец экрана.

Давайте, думать как сдвигать и заполнять экран, если смещение больше 7.

Alex Rider

12.09.2015, 09:48

zx-kit

12.09.2015, 10:07

Да и не надо двигать больше, чем на 8 пикселей за раз. Другое дело, что в расширенной адресации для дополнительного столбца место есть, а вот в стандартном режиме дополнительный столбец надо класть в атрибуты, пострадает графика стандартного слоя. Олсо сдвиги вверх и вниз тоже нужны. Предлагается двигать слои отдельно (например, завести байтовую переменную, включенные биты которой говорят какие слои сдвинутся следующей командой. Еще хочется циклический сдвиг - это позволит выделить слой под спрайт, вывести его один раз и двигать по экрану аппаратным скроллингом.
По-вертикали понятно тоже надо, там тоже есть запас 16 точек (при линейной адресации с адреса 0). Стандартный экран сдвигаться не будет. Если надо сдвиг подпрограмму рисования фона надо будет преобразовать в режим цвета COLOR2 и линейную адресацию.

Видеокарта будет сдвигать текущий слой. Надо графические переменные типа направление сдвига слоя shift_direct (LEFT, RIGHT, UP, DOWN), величину сдвига shift_value (1-8). Про циклический сдвиг не понятно. Может достаточно за 1 кадр сдвигать на 1-8 точек ?

Nesser

12.09.2015, 11:30

Я как представлю каким образом придётся переделывать к примеру Soldier of Fortune то что то аж голова болеть начинает.
Весь блок отображения надо менять ПОЛНОСТЬЮ, он однозначно будет увеличен в размере, как минимум раза в 2-3, время выполнения соответствующее. Ко всем спрайтам придётся дорисовывать цветовую маску которая в 2-3 раза больше самого спрайта, принцип хранения спрайтов естественно надо будет менять, размер будет увеличен как минимум в 3 раза. Безостановочный рекодинг цветов из байтового представления в битовое убьёт процессор на первой же трети экрана.
Не совсем понятен в какой части карты здесь идёт разгрузка процессора? :)

---------- Post added at 11:53 ---------- Previous post was at 11:50 ----------

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

---------- Post added at 12:30 ---------- Previous post was at 11:53 ----------

Эммм, а если вдруг потом загорится увеличить возможное разрешение, то я что то не понимаю как это предусмотреть программно без переделки части отображения, формат хранения пикселей очень неудачен для разрешения больше 256, это моё мнение, не берите в голову :)

zx-kit

12.09.2015, 12:24

Я как представлю каким образом придётся переделывать к примеру Soldier of Fortune то что то аж голова болеть начинает.
Весь блок отображения надо менять ПОЛНОСТЬЮ, он однозначно будет увеличен в размере, как минимум раза в 2-3, время выполнения соответствующее. Ко всем спрайтам придётся дорисовывать цветовую маску которая в 2-3 раза больше самого спрайта, принцип хранения спрайтов естественно надо будет менять, размер будет увеличен как минимум в 3 раза.
Если в игре нет масок у спрайтов - значит в ней нет и клешинга.

Безостановочный рекодинг цветов из байтового представления в битовое убьёт процессор на первой же трети экрана.
Не совсем понятен в какой части карты здесь идёт разгрузка процессора? :)

Нет никагого преобразования байтов в биты. Этим занимается карта. Процессор пишет байтами. Про причины ускорения и разгрузки процессора есть ссылка в 1 посту.

Кстати, мне уже кажется что сам программный код управляющий этой карточкой будет на несколько килобайт, может как нибудь подменяющееся пзу с программным кодом? а то пихать в каждую игру драйвер как то не айс
Пзу убрать нельзя - оно нужно для старых игр. Да и что туда писать - какие драйвера ?

---------- Post added at 12:30 ---------- Previous post was at 11:53 ----------

Эммм, а если вдруг потом загорится увеличить возможное разрешение, то я что то не понимаю как это предусмотреть программно без переделки части отображения, формат хранения пикселей очень неудачен для разрешения больше 256, это моё мнение, не берите в голову :)
Про линейную адресацию экрана есть ссылка в 1 посту.

Nesser

12.09.2015, 13:03

Непонятные для меня моменты:

Если карта успевает отображать только 5 слоёв с прозрачностью, то какой смысл в 8 слоях?
Что подразумевается под прозрачностью, просто отсутствие пикселя на данном плане и оставленный пиксель с предыдущего плана или же настоящая прозрачность - цвет пикселя на данном плане интерполированный с цветами пикселей предыдущих планов

при переделке игре надо оставлять стандартный вывод в 16384 и добавлять вывод цветов в пзу или полностью делать заново и всё выводить в пзу? если по 1 варианту так это явное увеличение выполнения, а если по 2-му то какой тогда смысл оставлять такую "неудобную" работу с пикселями если всё равно придётся всё перелопачивать
скроллинг экрана надо будет делать по принципу 15 летней давности аля денди? мож у кого посвежей идея есть? :)

---------- Post added at 14:03 ---------- Previous post was at 13:59 ----------

; hl - адрес символа
ld de, x * 256 + y * 8
dup 8
ldi
dec e
ldi
edup

я не понимаю как мне вывести спрайт в координаты x=243, y=179

zx-kit

12.09.2015, 13:31

Непонятные для меня моменты:

Если карта успевает отображать только 5 слоёв с прозрачностью, то какой смысл в 8 слоях?

На отключенных слоях, например, можно рисовать следующий кадр, а потом по INT их включить, а слои с предыдущим изображением выключить.

Что подразумевается под прозрачностью, просто отсутствие пикселя на данном плане и оставленный пиксель с предыдущего плана или же настоящая прозрачность - цвет пикселя на данном плане интерполированный с цветами пикселей предыдущих планов

Пиксель не может отсутствовать на слое - он или прозрачный и через него будет видно изображение с нижних слоев при выводе на монитор или он цветной.

при переделке игре надо оставлять стандартный вывод в 16384 и добавлять вывод цветов в пзу или полностью делать заново и всё выводить в пзу? если по 1 варианту так это явное увеличение выполнения, а если по 2-му то какой тогда смысл оставлять такую "неудобную" работу с пикселями если всё равно придётся всё перелопачивать

Сначала все выводится стандартно с адреса 16384 в слое 0. Потом, для устранения клешинга главного героя (ГГ), подпрограмму его вывода можно изменить для вывода в режиме COLOR2M в слой 1. Цвета спрайта в переменной attr те же, что были раньше.

скроллинг экрана надо будет делать по принципу 15 летней давности аля денди? мож у кого посвежей идея есть? :)

Денди сделали в 1983 году, на год позже ZX Spectruma, то есть 32 года назад. Однако кое-что оттуда можно применить. У Спектрума нет аппаратного скроллинга. Почему бы не добавить ? Только у нас сдвиг будет задаваться на 1-8 точек. Это свежая идея ?

я не понимаю как мне вывести спрайт в координаты x=243, y=179
Пример копирования спрайта с маской для стандартного режима (40*8=320 такта):

; hl - адрес спрайта с маской
; de - адрес в области пикселей экрана
dup 8

ld a,(de)
and (hl)
inc l
or (hl)
inc l
ld (de),a
inc d

edup
Пример копирования спрайта с маской для нового режима с линейной адресацией с адреса 0000 (36*8=288 тактов):

; hl - адрес спрайта с маской
; de - адрес в области пикселей экрана
dup 8

ldi
dec e
ldi

edup
Пример копирования спрайта с маской для стандартного режима с использованием стека (36*8=288)

; стек - адрес спрайта с маской
; hl - адрес в области пикселей экрана
dup 8

pop de
ld a,(hl)
and e
or d
ld (hl),a
inc h

edup
Пример копирования спрайта с маской для нового режима с линейной адресацией с адреса 0000 с использованием стека (28*8=224 такта):

; стек - адрес спрайта с маской
; hl - адрес в области пикселей экрана
dup 8

pop de
ld (hl), e
ld (hl), d
inc l

edup

zx-kit

12.09.2015, 16:58

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

А можно выводить без буфера сразу на экран.

экономия в 4 такта без стека (вот не надо принудительно тормозить вывод) и 8 со стеком не столь существенна.

Исправил на более быстрый вариант для стандартного режима. Экономия 4 такта при рисовании каждых 8 точек. Не много, но все равно это быстрее, чем в стандартном режиме. Даже если бы и медленнее было бы - устраняется клешинг атрибутов, а это - резкое улучшение качества графики. Кроме этого, с такой же скоростью рисует и режим "4 цвета на точку". Это позволит немного разукрасить старые игры, а в новых рисовать тайлы и спрайты более объемными или разноцветными.

все игры с xor идут мгновенно лесом (казалось бы причем тут dizzy), ну или требуют также серьезной переделки

xor то был не от хорошей жизни. можно ничего и не менять - тогда все останется по-старому. А можно поменять и получится лучшая графика.

попиксельные выводилки немного посложнее

В линейном режиме линии точками рисовать проще и быстрее

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

Nesser

12.09.2015, 20:41

Бог с ним, с задним планом, в обычном режиме он заодно и экран стирает, так а как мне вывести того же самого колобка который двигается с точностью 1 пиксель во все стороны? делать 2 буфера (пиксельный и масочный) на 8 пикселей больше по X и в нём уже сдвигать всё это по пикселям в зависимости от того куда мне надо сдвинуть? а если у меня 64 одинаково выглядящих объекта на экране которые динамично двигаются по экрану с точностью 1 пиксель? делать 64 буфера и в них двигать? или делать по 8 вариантов самого спрайта вместе с цветовой маской?

как бы всё таки проц не помер на первой же трети экрана

---------- Post added at 21:41 ---------- Previous post was at 21:39 ----------

И кстати, видео DMA в состоянии всего из 1 обычного экрана сделать хоть 16 планов, причём с наложением, стоит ли овчинка выделки?

zx-kit

13.09.2015, 08:13

Неспособность Z80 нарисовать колобка и необходимость для этого блиттера сильно преувеличена. До этого спрайты в играх рисовали без блиттера. Шарики есть во многих играх.

Реализация 1 этапа расширения графики в эмуляторе и видеокарте "Meteor Graphics" позволит устранить клешинг и ускорить построение изображений в играх следующих типов:

Цветные ходилки типа "Three Weeks in Paradise"

http://www.youtube.com

Ходилки с несколькими планами фона типа "SABOTEUR 2"

http://www.youtube.com

Игры с проволочной графикой типа "ELITE"

http://www.youtube.com

Реализация 2 этапа расширения графики в эмуляторе и видеокарте "Meteor Graphics" позволит ускорить построение изображений в играх со скроллингом фона:

"R-TYPE"

http://www.youtube.com

"SILKWORM"

http://www.youtube.com

"SABOTAGE"

http://www.youtube.com

"Flying Shark"

http://www.youtube.com

Посмотрите на игры для Денди. Не так уж много там спрайтов. Неужели Z80 не успеет их нарисовать ?

"Darkwing Duck Черный Плащ"

http://www.youtube.com

"Jackal"

http://www.youtube.com

Конечно можно пытаться вывести огромное количество спрайтов на экран и перегрузить процессор. Но можно ведь выбрать разумное их количество !

Nesser

13.09.2015, 11:57

А на сколько процентов работа уже выполнена в железе?
И на каком чипе будет?

Nesser

13.09.2015, 21:53

А кто программно ваять будет? :)

---------- Post added at 22:53 ---------- Previous post was at 22:17 ----------

Как подключаться будет, мгтф или разъём чей нибудь?

Eagle

13.09.2015, 21:56

Как подключаться будет, мгтф или разъём чей нибудь?
Надеемся на ZX-BUS/NEMO-BUS, иначе в топку.

zx-kit

14.09.2015, 22:38

А кто программно ваять будет?

Прошивку для FPGA буду сам разрабатывать и кодировать. И форум поможет.

Как подключаться будет, мгтф или разъём чей нибудь?
Видеокарта "Meteor Graphics" будет разрабатываться в виде контроллера для шины ZX-BUS.

Скроллинг по-горизонтали.
Экран шириной 256 точек - это 32 столбика байтов с номерами от 0 до 31. Чтобы сдвинуть экран влево надо заполнить тайлами еще один столбик с номером 32. А чтобы через 8 сдвигов на 1 точку продолжилось изображение надо за это время заполнить тайлами еще и столбик с номером 33. Как прошел сдвиг, кратный байту номера, номера и адреса столбиков соответственно меняются. То есть номера столбиков у нас опять будут 0-31, но экран сдвинулся на 1 байт влево.

Для сдвига экрана влево надо предварительно заполнять тайлами столбики с номерами 40 и 41.

Lethargeek

15.09.2015, 01:26

Мда, взялся было прочитать всё, что накопилось за время моего отсутствия в теме, дошёл до замены блиттера слоями... и бросил нафиг :v2_dizzy_facepalm:

Smalovsky

15.09.2015, 02:24

Мда, взялся было прочитать всё, что накопилось за время моего отсутствия в теме, дошёл до замены блиттера слоями... и бросил нафиг
Это на какой странице было?

Reobne

15.09.2015, 02:53

Планируемый срок реализации 1 ступени расширения графики - до Нового Года !
Если так быстро, то и ZXПирит окажется ненужной! :)
Я планирую её старт не раньше апреля 2016, а скорее всего позже.
Но я всё равно буду её вести. Пусть будет космонавтом-дублёром, так и не взлетевшим.

---------- Post added at 06:53 ---------- Previous post was at 06:51 ----------

а скорее всего позже.
И возможно намного позже. Из-за эффекта непредвиденного.

zx-kit

15.09.2015, 05:33

Мда, взялся было прочитать всё, что накопилось за время моего отсутствия в теме, дошёл до замены блиттера слоями... и бросил нафиг :v2_dizzy_facepalm:
В 1 посте есть ссылки по теме на основные страницы.

Запланировано для 2 этапа расширения графики на эмуляторе и в видеокарте "Meteor Graphics":

Палитры для рисования и отображения
Режимы с 2 - 4 битами на цвет точки
Аппаратный скроллинг экрана

s_kosorev

15.09.2015, 14:04

Палитры для рисования и отображения
Режимы с 2 - 4 битами на цвет точки
Аппаратный скроллинг экрана
есть идея ребрендинга, идеальное название Лифт-2013, так как этот девайс позволяет чуть быстрее передвигаться и при желании его можно догнать.

---------- Post added at 14:04 ---------- Previous post was at 13:33 ----------

И еще, с выбором чипа, EP2C5
Есть уверенность что все влезет в этот чип?
Насколько я помню, вместо EP2C5 уже не поставить EP2C8 и выше, там есть небольшие расхождения пинах

Nesser

15.09.2015, 17:49

А какой лучше чип использовать что бы на будущее? :)

zx-kit

21.09.2015, 19:26

Новые режимы в дополнительных слоях 1-8 нужно делать сразу для линейной адресации экрана с адреса 0000.

zx-kit

22.09.2015, 04:33

Для упрощения прошивки FPGA и ускорения работы в схему видеокарты "Meteor Graphics" добавлен 1 MB статики. Теперь ее надо распределить.

50 раз в секунду стандартный экран и дополнительные слои с расширенной графикой накладываются с учетом прозрачного цвета и палитр. Результирующее изображение записывается в буфер экрана в формате 2 байта на точку. Для буфера экрана нужна память размером 256*256*2=128KB.

Первый этап расширения графики.
Разрешение экрана 256*192 точки.
Один слой будет занимать 256*256=64KB.
128KB: буфер экрана + стандартный экран 6912
7*128KB: 14 слоев по 64KB без аппаратного скроллинга

Второй этап расширения графики
Разрешение экрана 256*192 точки + аппаратный скроллинг.
Один слой будет занимать 512*256=128KB.
128KB: буфер экрана + стандартный экран 6912
7*128KB: 7 слоев по 128KB с аппаратным скроллингом

Третий этап расширения графики
Можно будет подумать о разрешении экрана 320*240 точек и блиттере.
Один слой будет занимать 512*256=128KB. Тайлы и спрайты разместить в SDRAM.
2*128KB: буфер экрана + стандартный экран 6912
6*128KB: 6 слоев по 128KB с аппаратным скроллингом

Первоначально планировалось сделать 8 дополнительных слоев. Предыдущие расчеты показывают, что для разрешения 256*192 с возможностью аппаратного скроллинга - памяти хватает на 7 слоев, а для разрешения 320*240 - на 6 слоев.
Применение статической памяти позволит отображать сразу 7 слоев одновременно. Также статика упрощает реализацию аппаратного скроллинга и блиттера с точностью до точки.

zx-kit

22.09.2015, 20:50

Таблица размещения в статической памяти размером 1 MB буфера экрана, двух стандартных экранов 6912 (для 128K) и 7 слоев для расширенной графики

http://s016.radikal.ru/i334/1509/94/8675e8d9ee7dt.jpg (http://s016.radikal.ru/i334/1509/94/8675e8d9ee7d.png)

Эта информация нужна для проектирования прошивки FGPA. В таблице показано расположение памяти со стороны FPGA. Вся память делится на 8 страниц по 128 KB с номерами от 0 до 7. Номер слоя 1-7 соответствует номеру страницы. Z80 к этим областям доступа не имеет. Байты, которые он записывает в дополнительные слои, преобразовываются в цвета 8 точек и FPGA записывает эти 8 байтов в нужную область SRAM.

Картинку надо будет немного подкорректировать:
Так как в режиме 128K у нас 2 экрана, то второй экран надо разместить снизу в 7 странице.
Для разрешения 256*192 весь буфер экрана уместится в 0 странице. В 7 странице можно разместить 7 слой.

jerri

23.09.2015, 16:11

а 4 бита на точку хватит?
а сколько цветов будет?

zx-kit

23.09.2015, 16:55

а 4 бита на точку хватит?
а сколько цветов будет?
Видеокарта сможет показывать 32768 цветов - 32 оттенка серого:

http://s003.radikal.ru/i202/1509/e0/bc17139cece0t.jpg (http://s003.radikal.ru/i202/1509/e0/bc17139cece0.jpg)

На первом этапе будет устранен клешинг атрибутов. Цвета останутся стандартными.
На втором этапе добавится палитра в каждом слое и аппаратный скроллинг.
На третьем добавится блиттер с 8 битами на точку.

Программно больше 4 битов на точку наверно не имеет смысла гонять.

Распределение статической памяти внутри видеокарты "Meteor Graphics".

http://i003.radikal.ru/1509/d6/3d3c9fe33294t.jpg (http://i003.radikal.ru/1509/d6/3d3c9fe33294.png)

s_kosorev

23.09.2015, 20:48

Байты, которые он записывает в стандартный экран и дополнительные слои, преобразовываются в цвета 8 точек и FPGA записывает эти 8 байтов в нужную область SRAM.
а если атрибут меняется или мерцание флеша? Это уже 64 байта, что бы успеть, без останова процессора, SRAM должна работать на 3,5/3*64 = 74мгц + если читать хотя бы с частотой 7мгц 6 слоев это еще 42МГц, итого нужна SRAM как минимум 9нс а это SSRAM с очень высокой стоимостью

---------- Post added at 20:48 ---------- Previous post was at 20:48 ----------

Или я что то не понял по нагрузке на шину?

zx-kit

23.09.2015, 21:00

а если атрибут меняется или мерцание флеша? Это уже 64 байта, что бы успеть, без останова процессора, SRAM должна работать на 3,5/3*64 = 74мгц + если читать хотя бы с частотой 7мгц 6 слоев это еще 42МГц, итого нужна SRAM как минимум 9нс а это SSRAM с очень высокой стоимостью. Или я что то не понял по нагрузке на шину?
Исправил. В стандартном режиме (в слое 0) все хранится по-старому. Отдельно байт пикселов и байт атрибутов.
В дополнительных слоях нет атрибутов и флеша. Там только 8 байтов на 8 точек.

а 4 бита на точку хватит?

Должно хватить. 4 бита на точку - это 16 цветов на спрайт из 256 цветов в слое из 32768 цветов !
В большинстве случаев хватит и 2 бита на точку - это 4 цвета на спрайт из 256 цветов в слое из 32768 цветов.
При рисовании используется палитра для рисования. А в каждом слое палитра отображения.

http://s019.radikal.ru/i639/1506/36/f2bf9b657467t.jpg (http://s019.radikal.ru/i639/1506/36/f2bf9b657467.png)
Палитра как у MSX2+ 32K цветов при 15-битном RGB 5+5+5

jerri

24.09.2015, 15:13

да да вот я и хотел уточнить сколько бит на цвета закладываешь
15 бит... наверное нормально.

zx-kit

24.09.2015, 20:33

все игры с xor идут мгновенно лесом (казалось бы причем тут dizzy), ну или требуют также серьезной переделки

Давайте уточним полярность байтов и масок.
Маска содержит 0 - там, где цвета спрайта и 1 - там, где прозрачный цвет ?
При использовании XOR спрайт не содержит маски. 1 - там, где цвет спрайта и 0 - там, где прозрачный ?
Можем мы вывести спрайт без маски в режиме COLOR1C ?

COLOR1C - 1 цвет на 8 точек + прозрачный
По соответствующему адресу в области пикселей нужно записать байт данных. На каждую из восьми точек приходится по 1 биту: 0 - прозрачный, 1 - цветной. Номер цвета предварительно записывается в переменную color. 0 - прозрачный, 1-255 выбранный цвет. Данный режим предназначен для наложения одноцветного изображения поверх существующего. Например, для вывода текста, рисования линии по точкам, а также для стирания тайла/спрайта с текущего слоя, если color = 0.

Alex Rider

24.09.2015, 21:46

Маска содержит 0 - там, где цвета спрайта и 1 - там, где прозрачный цвет ?
Да

При использовании XOR спрайт не содержит маски. 1 - там, где цвет спрайта и 0 - там, где прозрачный ?
Да

Можем мы вывести спрайт без маски в режиме COLOR1C ?
Не вижу причин, почему нельзя.

Nesser

25.09.2015, 00:02

Зачем в цветах на каждую точку использовать XOR ?
Мне уже страшно становиться какого размера будет драйвер управления.

zx-kit

25.09.2015, 05:10

Пример подпрограммы рисования спрайта с маской в режиме COLOR2M размером 24х24 точки по координатам, заданным в знакоместах. Спрайт в памяти хранится так: байт маски 1 линии в столбике, байт данных 1 линии в столбике, байт маски 2 линии в столбике, байт данных 2 линии в столбике, ... байт маски 24 линии в столбике, байт данных 24 линии в столбике. Затем аналогично записан второй и третий столбики спрайта.

; перед выводом спрайтов устанавливаетя режим цвета color_mode = COLOR2M
; и выбирается номер слоя current_layer для рисования
;
; hl - адрес спрайта
; d - координата x в знакоместах
; e - координата y в знакоместах
; a - цвет спрайта, соответствует стандартному атрибуту Спектрума

ld (attr), a ; устанавливаем цвет спрайта

sla e ; вычисляем адрес младшего байта e в области пикселов
sla e ; старший байт d соответствует координете x
sla e

push de ; сохраняем координаты начала столбика

dup 24 ; рисуем 1 столбик спрайта высотой 24 байта
ldi
dec e
ldi
edup

pop de ; восстанавливаем координаты начала столбика
inc d ; переходим к столбику справа
push de ; сохраняем координаты начала столбика

dup 24 ; рисуем 2 столбик спрайта высотой 24 байта
ldi
dec e
ldi
edup

pop de ; восстанавливаем координаты начала столбика
inc d ; переходим к столбику справа

dup 24 ; рисуем 3 столбик спрайта высотой 24 байта
ldi
dec e
ldi
edup

ret

Пример подпрограммы рисования спрайта без маски в режиме COLOR1C размером 24х24 точки по координатам, заданным в знакоместах. Спрайт в памяти хранится так: байт данных 1 линии в столбике, байт данных 2 линии в столбике, ... байт данных 24 линии в столбике. Затем аналогично записан второй и третий столбики спрайта.

; перед выводом спрайтов устанавливаетя режим цвета color_mode = COLOR1C
; и выбирается номер слоя current_layer для рисования
;
; hl - адрес спрайта
; d - координата x в знакоместах
; e - координата y в знакоместах
; a - цвет спрайта от 1 до 15

ld (color), a ; устанавливаем цвет спрайта

sla e ; вычисляем адрес младшего байта e в области пикселов
sla e ; старший байт d соответствует координете x
sla e

push de ; сохраняем координаты начала столбика

dup 24 ; рисуем 1 столбик спрайта высотой 24 байта
ldi
edup

pop de ; восстанавливаем координаты начала столбика
inc d ; переходим к столбику справа
push de ; сохраняем координаты начала столбика

dup 24 ; рисуем 2 столбик спрайта высотой 24 байта
ldi
edup

pop de ; восстанавливаем координаты начала столбика
inc d ; переходим к столбику справа

dup 24 ; рисуем 3 столбик спрайта высотой 24 байта
ldi
edup

ret

Пример подпрограммы стирания спрайта размером 24х24 точки по координатам, заданным в знакоместах.

; перед стиранием спрайтов устанавливаетя режим цвета color_mode = COLOR1C,
; цвет для стирания color = 0 и выбирается номер слоя current_layer для стирания
;
; d - координата x в знакоместах
; e - координата y в знакоместах

sla e ; вычисляем адрес младшего байта e в области пикселов
sla e ; старший байт d соответствует координете x
sla e

ld a, #FF; байт для стирания - стираем все 8 точек в байте

dup 24 ; стираем 1 столбик спрайта высотой 24 байта сверху-вниз
ld (de),a
inc e
edup

inc d ; переходим к столбику справа

dup 24 ; стираем 2 столбик спрайта высотой 24 байта снизу-вверх
dec e
ld (de),a
edup

inc d ; переходим к столбику справа

dup 24 ; стираем 3 столбик спрайта высотой 24 байта сверху-вниз
ld (de),a
inc e
edup

ret

zx-kit

25.09.2015, 20:20

Надо бы к моменту изготовления видеокарты или доработки эмулятора сделать демы для некоторых режимов. Есть у кого идеи?
Я прикинул, что в режиме COLOR2 можно делать программный скроллинг экрана в цвете для окна 160х160 точек. Еще бы в верхнем слое добавить самолет или вертолет, летящий вверх типа FLAYING SHARK.

Или Ded Moroz Demo. Идет объект в режиме ZX COLOR в виде контура. Потом переходит в зону СOLOR1C. Тут он уже однотонный, но сквозь глаза виден фон. Потом в зоне COLOR2M глаза уже нормальные - черные. В зоне COLOR4 шуба уже красная. лицо желтое, а елка зеленая.

Вообще, раз демонстрируем возможности видеокарты надо делать дему с визуальными эффектами.

Nesser

27.09.2015, 09:55

Сколько тактов получилось на спрайт 24х24 ?
И по мне так это всё таки странное решение выводить по знакоместам

---------- Post added at 10:28 ---------- Previous post was at 10:22 ----------

Я прикинул, что в режиме COLOR2 можно делать программный скроллинг экрана в цвете для окна 160х160 точек. Еще бы в верхнем слое добавить самолет или вертолет, летящий вверх типа FLAYING SHARK.

Так будет ускорение вывода или уменьшение выводимой информации?

Или Ded Moroz Demo. Идет объект в режиме ZX COLOR в виде контура. Потом переходит в зону СOLOR1C. Тут он уже однотонный, но сквозь глаза виден фон.

Эти случаи двойного наложения настолько редкие (очень редкие) что делать из-за этого аппаратные слои нет никакого смысла, у меня создаются стойкие ощущения что для всего этого потребуется процессор > 30 МГц

---------- Post added at 10:46 ---------- Previous post was at 10:28 ----------

Кстати скроллинг экрана не всегда бывает кратный 1-му пикселю, он может быть и 2 и 3 и 9 и 27, что делать в таком случае? полностью перерисовывать фон?

---------- Post added at 10:55 ---------- Previous post was at 10:46 ----------

http://www.gamedev.ru/code/articles/?id=4208

Sameone

27.09.2015, 15:31

Не надо столько режимов.
Режим 1 – цвет 1 байт на 8х1 пикселей;
Режим 2 – цвет 2 байт на 8х1 пикселей;
Режим 3 – цвет 3 байт на 8х1 пикселей;
Режим 4 – цвет 4 байт на 8х1 пикселей.
Во всех режимах доступна палитра 16/256. Всего 16 палитр, по умолчанию палитра 0. По умолчанию представляет стандартные цвета. Любой цвет любой палитры может быть объявлен прозрачным. Смена палитры, переопределение цвета в палитре и объявление цвета прозрачным производятся через вызов соответствующих функций. С одинаковыми номерами во всех трёх режимах.
Программы, которые не знают об этих функциях и не знают их номеров, всё равно не смогут их вызвать. А конструкция «видеочипа» будет проще. Номера режимов прямо указывают на количество битов на пиксель (байтов на тайл 8х1).
Во всех режимах по умолчанию атрибут на знакоместо. Но можно установить флаг атрибут на строку знакоместа. Атрибут из расчёта байт на битплан слоя, хранит номера цветов 16-цветной палитры. В качестве атрибута всего знакоместа используется атрибут его 0 строки. Дополнительный параметр устанавливает возможность использовать бит 7 битплана 0 как бит мерцания, в этом случае для фона битплана 0 доступны только цвета 0-7 текущей палитры. По умолчанию (после сброса) параметр установлен.
Во всех режимах возможна установка разрешения 256х192 или 320х200. Разрешение 320х240 (QVGA) не нужно, оно использовалось только на мобилках и карманных медиалеерах с середины «нулевых», но под него не было каких-то эксклюзивных удачных игр, портировать с него нечего. А в 320х200 много старых игр (на PC, например). Зато, возможно, стоит рассмотреть вариант 320х180 – он будет без чёрных полосок подгоняться под современные мониторы 16:9. По умолчанию (после сброса) разрешение 256х192.
По умолчанию во всех режимах экран располагается с адреса 8000h, при необходимости адрес может быть переключён на 0000h.
Такая архитектура в силу своей ортогональности максимально упрощает разработку и отладку видеокарты, а также интуитивно понятна программисту.
Расход памяти в байтах на каждый слой: 2 х номер_режима х разрешение_режима. Округлённо: 64 КБ на экран 320х200 в режиме 4. На 8 слоёв необходимо 512 КБ памяти.
Рендеринг изображения производится в буфер (ramdac), всего есть 2 буфера, которые переключаются по кругу (двойная буферизация). Переключение буферов производится специальным вызовом вручную. При 8 слоях в режиме 4 у нас будет максимум 128 цветов на точку, округляем до байта и получаем 128 кб двухпортовую память (два буфера 320х200х256). При переключении буфера текущая палитра дублируется в теневую копию, которая затем используется при выдаче содержимого буфера на экран. Т. е. на экране отображается одна 256-цветная палитра, а мы работаем в видеопамяти с другой.
P.S. Номер режима 0 может быть использован (зарезервирован) для текстового режима видеокарты (пригодится для системных и офисных программ).
P.S.2. Не понимаю какая разница с какого адреса у нас видеопамять: с 0000 или 8000, всё равно банками щёлкать. Хотя как бы процессору и незачем лезть непосредственно в память спрайтовой видеокарты (а Метеор хоть и несколько оригинальная, но таки спрайтовая видеокарта). А вот источником головной боли для программиста/хакера-адаптатора отображение видеопамяти поверх системного ПЗУ вполне может стать. Ведь игра вполне может вызывать отдельные функции оттуда. Или использовать системный шрифт.

Alex Rider

27.09.2015, 18:00

Не надо столько режимов.
Sameone, а ты прочитал всю тему прежде, чем вносить предложения? Перечитай, пожалуйста, и ответь сам себе на вопрос о нужности в этой теме идей о том, как сделать принципиально другую видеокарту. Надоело по 10-му разу это объяснять очередному прочитавшему первый и десяток последних постов.

а Метеор хоть и несколько оригинальная, но таки спрайтовая видеокарта
Олсо ты даже не понял что за идея тут предлагается.

Sameone

28.09.2015, 12:59

ты прочитал всю тему
Представь, да, всю прочитал.

принципиально другую видеокарту
Не вижу принципиальных отличий. В обоих случаях слои, внутри которых битовые плоскости с атрибутами 8х1 или 8х8.
Некоторые отличия есть. Я предлагаю уменьшить количество названий режимов и заменить буквенно-цифровые абривеатуры их названий на номера, прямо указывающие на глубину цвета в этих режимах.
Предлагаю сделать все слои равноправными, это упростит видеокарту и при этом несколько расширит её возможности. Для совместимости инициализировать все слои в стандартном для Спектрума виде.
Предлагаю поддержать разрешение 320х200, которое есть на ряде спектрум-сомвестимых машин, что, ИМХО, вполне вписывается в идеологию "упрощения адаптации старых игр". А вот разрешение 320х240 да, считаю ненужным. Не было его на Спеке никогда, нечего адаптировать.
Я даже на адресацию с 0000 не покушаюсь. хотя и опасаюсь что в некоторых случаях она может стать источником проблем.

С чего ты взял что я предлагаю забить на Метеор и сделать принципиально другую карту? Увидел многа бакаф? Так более-менее полное описание я привёл потому, что хотел избежать нескольких страниц вопросов вроде "а эта пимпочка по умолчанию включена или выключена"?

ты даже не понял что за идея тут предлагается
Идея Метеора в "ленивой" переделке старых игр (устранение клешинга, увеличение количества цветов). Разве нет?

P.S. А как ты называешь прямоугольные графические объекты с атрибутами? Я спрайтами.

zx-kit

28.09.2015, 18:17

P.S. Номер режима 0 может быть использован (зарезервирован) для текстового режима видеокарты (пригодится для системных и офисных программ).
P.S.2. Не понимаю какая разница с какого адреса у нас видеопамять: с 0000 или 8000, всё равно банками щёлкать. Хотя как бы процессору и незачем лезть непосредственно в память спрайтовой видеокарты (а Метеор хоть и несколько оригинальная, но таки спрайтовая видеокарта). А вот источником головной боли для программиста/хакера-адаптатора отображение видеопамяти поверх системного ПЗУ вполне может стать. Ведь игра вполне может вызывать отдельные функции оттуда. Или использовать системный шрифт.
320х240 кратен режиму монитора 640х480. Каждая точка увеличена в два раза по-вертикали и по-горизонтали. В режиме 256х192 лишние точки используются для бордера. Под номером 0 стандартный экран. Адрес 0000 - для упрощения вычислений адреса байта на экране. Z80 не имеет доступа к памяти видеокарты. Банками переключать не надо. Адреса у всех байтов, из которых получаются 8 точек одинаковые. Байты записываются по-очереди в один адрес. Но в слоях 8 точек в любом дополнительном режиме представлены 8 байтами. Количество битов на точку в режимах с палитрой - это количество цветов на спрайт. Это может быть один байт или несколько. Без разницы. Под атрибуты память не тратится. Закрашивание точек происходит после записи последнего байта из 1-4 для разных режимов. Из ПЗУ читается как-обычно. И подпрограммы в нем тоже могут выполняться. В видеокарту происходит только запись. Но можно эту запись временно отключать на время работы некорректных подпрограмм в ПЗУ, которые пишут в адрес ПЗУ.

zx-kit

28.09.2015, 18:32

Режимы слишком специфичные, я бы для начала исходя из их характеристик просто подумал как в 3-4 играх, с разным методом вывода, переделать по Вашу концепцию. Сразу будет видно сколько работы надо проделать, увидите недостатки.
Посмотрел код THREE WEEKS IN PARADISE. Там рисование идет в буфер размером в 2 сегмента. Потом с помощью LDIR буфер копируется на экран. Маска сдвигается сразу для четырех байтов. Потом накладывается на буфер. Перед этим содержимое буфера сохраняется. Видимо для восстановления фона. Потом сдвигается 4 байта спрайта и накладываются в буфер. Пока не придумал как модернизировать этот код. Надо еще найти подпрограмму, которая восстанавливает фон. Подпрограмму оригинала с комментариями выкладываю. Надо подумать коллективно. Еща какие игры с клешиногом будем смотреть ?

Nesser

28.09.2015, 21:44

мне кажется что идея заранее провальная, не в том смысле что это не надо делать а в том смысле что это какая то странная технология вывода, иметь на борту столько памяти и делать какую то раскоряку :)

---------- Post added at 22:44 ---------- Previous post was at 22:38 ----------

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

Nesser

29.09.2015, 08:19

Дык никто не говорит что *****, старые игры переделать и я мож помогу :)
Просто я до сих пор не пойму зачем столько сложностей для программиста если в железяке стоит довольно мощная плис и аж 1-8 метров видеопамяти, и при этом до сих пор непонятно как же выводить с точностью до пикселя, я не хочу крутить по битам спрайт диззи в буфере, я хочу тупо вывести его на экран, и пусть это будет даже 1 байт на пиксель, всё равно всё храниться в видеопамяти, я в самом начале игры возьму чёрно-белый спрайт, 1 байт на 8 пикселей, наложу на него цвет, и закину в видеопамять уже в виде 1 байт на пиксель, а в нужный момент просто дам команду для переброски из адреса спрайта в адрес на экране с учетом размеров спрайта, а если мне захочется сделать новую игру или графический редактор то я сразу буду хранить это в 1 байт на точку.

п.с. Ничего личного, это моё виденье ситуации :)

Alex Rider

29.09.2015, 12:30

Смена палитры, переопределение цвета в палитре и объявление цвета прозрачным производятся через вызов соответствующих функций.
Что такое выхов функций в предлагаемой архитектуре? Запись нажных байтов в регистры карты, замаппированные в ПЗУ?

Во всех режимах возможна установка разрешения 256х192 или 320х200.
Все расширенные режимы оставлены "на потом".

По умолчанию во всех режимах экран располагается с адреса 8000h,
что делает невозможной адаптацию игр без их полного переписывания.

а Метеор хоть и несколько оригинальная, но таки спрайтовая видеокарта
Метеор - растровая видеокарта. Про понятие "спрайт" он не знает совсем.

Для совместимости инициализировать все слои в стандартном для Спектрума виде.
Этого сразу не прозвучало, сложилось впечатление, что стандартный режим поддерживать и не предлагается.
Кроме того, я нигде не нашел упоминание про один из самых важных придуманных режимов - монохромный с маской.

Sameone

29.09.2015, 17:53

zx-kit

29.09.2015, 19:43

zst,
320х240 планируется из-за того, что это четвертушка от 640х480, верно? А 320х200 это четвертушка от 640х400, которое есть разрешение текстового режима VGA, мне по крайней мере ещё не попадался VGA-монитор, который бы не понимал развёртку textmode. Впрочем, 320х200 тоже стандартный режим VGA. Но если 320х240 нужен, пусть будет. Тогда сэкономить на видеопамяти неудастся.
А как насчёт 320х200? Его ведь тоже можно вписать в 320х240?

За основу взята развертка 640х480@60Hz, так как это индустриальный стандарт и поддерживается большинством мониторов и телевизоров с VGA входом. 640х400@70Hz может не на всех заработать. Текстовой режим пока не планировался.

Новый вариант адресации через hl, который планируется в Метеор, очень хорош. Я только высказал опасения, что включение видеопамяти вместо ПЗУ потенциально может вызвать проблемы в некоторых программах. А можно слелать так, чтобы по желанию программиста карточка смещала новую адресацию на 4000? Как раз для "некорректных программ, которые пишут в ПЗУ" (я так понимаю, это СР/М и всё что под неё)? Видеокарта ведь для любого спектрум-совместимого компа? Кстати, когда я говорил про видеопамять с 8000 я ошибся. С 4000, я имел ввиду стандартное начало видеопамяти в спектруме, почему меня переклинило не знаю.
Да, а читать из видеокарты точно никогда-никогда не потребуется, даже в будущем?

Видеокарта для игр. Начало экрана с 0000 упрощает адресацию. Сначала новые режимы предполагались и 4000 или 0000. С адреса 4000 новые видеорежимы будут затирать часть игры, так как новый экран занимает 8KB адресов. Чтение из видеокарты может пригодиться. Возможно лучше выделить часть памяти с адресами 2000-3FFF в качестве дополнительного ОЗУ для доработки игр. В нее можно было бы загружать новые подпрограммы. При этом чтение из ПЗУ конечно придется отключить. На некоторых комьпютерах, где можно включить ОЗУ вместо ПЗУ могут быть конфликты. Надо это обдумать.

Битпланы в Метеоре всё-таки есть, просто их не нужно переключать ручками. Я ж вроде и не предлагал?
Чего плохого в том, чтобы все слои по желанию программиста могли быть более чем двухцветными, тем более слой 0 - я так понимаю, он самый дальний? Видеокарта инициализируется в режим слой=0, разрешение=256х192, начало видеопамяти=4000, глубина цвета=1 бит/пиксель, атрибут=1 байт на знакоместо, бит 7=флэш, палитра=спектрум_стандарт, никаких траблов. При необходимости можно эти параметры менять, если программа знает и умеет это. Это не сужает, а расширяет возможности карты.

В слоях физически каждая точка может иметь 255 разных цветов. Вначале будет стандартных 15. Стандартный режим расширять не планируется - он остается без изменений в 0 слое. Его можно будет отключить. Вместо стандартного лучше все рисовать в режиме COLOR2 - проще и быстрее.

Атрибуты при глубине цвета более 1 бит/пиксель я предлагаю. Потому как в том же Денди, например, атрибуты на спрайт 8х8, а в самом спрайте указывается который из 4 цветов использовать. Если будут атрибуты на знакоместо в режиме 2, это упростит перенос игр как с Денди, так и с денди-конфы. Это плохо? Возможность в режимах 1 и 2 задать атрибуты для блока 8х1 пикселей --- это для адаптации картинок в мультиколоре, чтобы не подменять атрибуты на каждой строке каждый кадр. В режимах 3 и 4 и правда можно обойтись без атрибутов, напрямую указывать цвет из палитры слоя.

У Денди тайлы и спрайты имеют 3 цвета на тайл/спрайт + прозрачный. В Метеоре этому режиму соответствует режим COLOR4C. В палитре можно выбрать 4 цвета, среди которых может быть и прозрачный. Только вместо атрибутов перед рисованием выбирается палитра из четырех цветов. Можно менять номер палитры для каждого байта или для каждых 8 байтов или для каждого большого спрайта.

А разве не планируется тулза для перекодировки спрайт+маска в 4-цветный спрайт (один цвет прозрачный)? Или скормить ей все спрайты игры это очень долго? Если она будет -- зачем поддерживать маску?

Маска нужна для постепенного перехода от старой графики к новой без изменения спрайтов. Конечно в режиме COLOR4C цветов больше. Как писал Lethargik, нужны такие режимы, чтобы можно было выбирать степень переработки игры. Для новых игр режим с маской особо и не нужен.

P.S. Можно попросить документ про Парадиз выложить в rtf? Я бы хотел глянуть, но у меня MS Word.
Выложу в разделе игр (http://zx-pk.ru/showthread.php?t=25643).

Nesser

30.09.2015, 13:41

Старую игру всё равно придётся полностью делать ЗАНОВО!
Иначе какой тогда смысл вообще начинать?
Экономия 5-10% мощности CPU не есть гуд, переделывать даже 1 старую игру это ппц какой гемор, а если это делать только из-за того что бы убрать на паре спрайтов наползание цвета то не вижу в этом смысла. Почему нельзя сделать тупо видео DMA ?
А если я захочу сделать игру и в 256x192 и в 640x480 ? Всё? :) Тупик?
А ведь с видео дма это решается примитивно и просто, AMIGA тому подтверждение.

Nesser

01.10.2015, 09:22

А можно нагрузить плис выводом анимационного заднего фона? :)

zx-kit

01.10.2015, 16:28

Старую игру всё равно придётся полностью делать ЗАНОВО!
Иначе какой тогда смысл вообще начинать?

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

Экономия 5-10% мощности CPU не есть гуд, переделывать даже 1 старую игру это ппц какой гемор, а если это делать только из-за того что бы убрать на паре спрайтов наползание цвета то не вижу в этом смысла.

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

Почему нельзя сделать тупо видео DMA ?
А если я захочу сделать игру и в 256x192 и в 640x480 ? Всё? :) Тупик?
А ведь с видео дма это решается примитивно и просто, AMIGA тому подтверждение.
Надо все делать поэтапно. Нет пределу совершенства. Сначала отладим программое рисование спрайтов без клешинга. Потом продолжим разработку блиттера. DMA наверно не понадобится.

---------- Post added at 18:28 ---------- Previous post was at 18:26 ----------

А можно нагрузить плис выводом анимационного заднего фона? :)
А зачем и как это будет выглядеть ?

Nesser

01.10.2015, 20:06

Сейчас мне скажут что создавай свою ветку и там пиши про свою новую видеокарту :)

Нууу значит как бы я хотел видеть это устройство с точки зрения программиста.

Raydac

01.10.2015, 20:12

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

Nesser

01.10.2015, 20:25

Reobne

02.10.2015, 05:17

возьмет
Оно должно давать. Давать наслаждение работой своего мозга, разбираясь в интересном старом загадочном коде. Получая наглядный результат.
Не интересно - просто брось это. И никаких проблем. :)

zx-kit

02.10.2015, 05:58

Берём хотя бы диззи, к примеру в лесу стоит факел, нужно сделать отрисовку всего экрана с учётом света от факела, при чём с минимальной нагрузкой, единственный вариант это наложить слой с радиальной яркостью которая изменит яркость предыдущего слоя, то есть чисто маска есть/нет здесь не прокатит. Так же интересно выглядело солнце вверху от которого идёт яркостная засветка фона.
Ну это в принципе мелочи.

Ландшафтный фон - загружаем в память видеокарты файл карты и спрайты к ней. Допустим карта 512 на 256 двухбайтовых слов в которых содержится номер спрайта ну и к примеру разброс анимации по номеру спрайта, к примеру спрайты 16 на 16, карта получается 8192 на 4096 пикселей, то есть 32 на 21 экран, че то я переусердствовал :) ну да бог с ним, так вот, подаю я к примеру координаты 2785, 476 и карточка будет отображать слой с ландшафтом по этим координатам, то есть CPU вообще не имеет гемора с отображением карты, а если видеокарте сказать что разрешение было изменено с 256x192 на 640x480 то она просто изменит поправочный делитель в блоке вывода и на экране прекрасно будет выводиться другое разрешение, можно даже завести туда все стандартные, скажем так на будущее :) чем мощнее потом ставить плисину тем большее разрешение она будет успевать перелопачивать, одна и та же игра будет заведомо работать на б`О`льших разрешениях.
Может вообще сделать её командно-управляемую? как встроенный калькулятор BASICа у которого свой язык, подаешь карте адрес и она начинает выполнять программу в своей памяти, запихать в плисину небольшой специализированный cpu с небольшим набором команд я думаю не сложно :)

нуу пока что так :D
Видеокарта не расчитывается на математические расчеты для вычисления яркости, тени, 3D и т.п. наворотов. Это уже давно изобретено в лучшем виде на PC. Меня интересует ретро-графика, а не 3D.
Блиттер пока не добавляем. На рисование карты программными тайлами не так уж много времени надо. А если на втором этапе добавим аппаратный скроллинг фона, то надо будет заполнить фон один раз на весь экран (тут время не очень критично), а потом дорисовывать только столбик или строку (а на это времени хватит и программным способом). Потом может это все ускорит блиттер. Но не первом этапе. Потом продолжим разработку и команд и дисплей-листов. Этим мы уже занимались и в этой теме и в железе были наброски команд - перечитайте, что мы там уже напридумывали.

Сейчас удалось спроектировать такие режимы, которые могут совместить на экране и стандартную графику и рисование программно и рисование блиттером. Дополнительные слои подходят и для программного и аппаратного копирования и сдвига экрана. Но сначала надо реализовать простое. Обсуждать команды конечно можно заранее, но с учетом, что реализовываться они будут позже, на третьем этапе.

s_kosorev

02.10.2015, 09:47

Берём хотя бы диззи, к примеру в лесу стоит факел, нужно сделать отрисовку всего экрана с учётом света от факела, при чём с минимальной нагрузкой
так наоборот надо делать, понижать яркость не освещенных участков, причем не ниже порога общего освещения, так что тут не совсем маска, нужно слой с освещением рассчитывать, потом на сцену накладывать, в общем математика с насыщением нужна, несложная, для FGPA вообще не вопрос, но тем не менее

Nesser

02.10.2015, 11:09

Так я и говорю что это не проблема, тем более там больше 100 МГц плисина :)

Raydac

02.10.2015, 11:51

а как планируется быть с кейсом когда в игре есть dashboard и все взаимодействие с юзером и индикация осуществляется через изменение цветов атрибутов на dashboard, целиком переписывается данные код?

Nesser

02.10.2015, 15:05

Я так понимаю что через изменения цвета в палитре

zx-kit

02.10.2015, 18:20

Координаты спрайта

В некоторых старых играх спрайты выводятся не вертикальными столбиками из байтов, а горизонтальными линиями из байтов. При этом, для экономии места, спрайты иногда перед выводом сдвигают программно на нужное количество битов. Чтобы облегчить доработку таких игр добавляются следующие переменные, где 0-7 = номер байта в линии спрайта, A-D (или E-H) = байты 1-4 для соответствующего режима цвета:

A0, A1, A2, A3, A4, A5, A6, A7,
B0, B1, B2, B3, B4, B5, B6, B7,
C0, C1, C2, C3, C4, C5, C6, C7,
D0, D1, D2, D3, D4, D5, D6, D7,

или

E0, F0, G0, H0,
E1, F1, G1, H1,
E2, F2, G2, H2,
E3, F3, G3, H3,
E4, F4, G4, H4,
E5, F5, G5, H5,
E6, F6, G6, H6,
E7, F7, G7, H7,

Например, для вывода с маской в байты A0-A7 (или E0-E7) записываются 1-8 байтов маски, а в байты B0-B7 (или F0-F7)— соответствующее количество байтов спрайта.

Координаты на экране левого байта линии спрайта предварительно задаются следующими переменными:

x — мл. байт координаты X в пикселах
xh — cт. байт координаты X в пикселах
или
xc — координата X в знакоместах
xs — смещение по-горизонтали в знакоместе

y — мл. байт координаты Y в пикселах
yh — cт. байт координаты Y в пикселах
или
yc — координата Y в знакоместах
ys — смещение по-вертикали в знакоместе

Это позволяет рисовать спрайты на экране с расположением с точностью до пиксела.

Nesser

02.10.2015, 22:48

А как быть если в это байте уже стоят две точки с соседнего спрайта, то есть я должен сделать буфер спрайта, сдвинуть его столько раз сколько надо для смещения 1-7, потом считать 2 байта из экрана куда нужно выводить, очистить биты куда буду выводить, наложить туда байт из буфера, и положить всё это обратно на экран, то же самое сделать для соседнего байта. Тек что ли? :)

zx-kit

03.10.2015, 05:40

Да какие уж там проценты - одного человека достаточно, например вот человек спрашивает как побыстрее линию нарисовать - http://zx-pk.ru/showpost.php?p=811234&postcount=43 - ему если дать аппаратную точку или линию, он глядишь и DOOM соберёт ))

Теперь появляется возможность рисовать точками в нужном цвете, если задавать в соответствующих переменных координаты точки и рисовать в режиме COLOR1C.

А как быть если в это байте уже стоят две точки с соседнего спрайта, то есть я должен сделать буфер спрайта, сдвинуть его столько раз сколько надо для смещения 1-7, потом считать 2 байта из экрана куда нужно выводить, очистить биты куда буду выводить, наложить туда байт из буфера, и положить всё это обратно на экран, то же самое сделать для соседнего байта. Тек что ли? :)
Надо рисовать в дополнительном слое и использовать маску для задания прозрачного цвета на краях спрайта.

---------- Post added at 07:40 ---------- Previous post was at 07:30 ----------

а как мне вывести того же самого колобка который двигается с точностью 1 пиксель во все стороны?
Теперь способ найден.

drbars

03.10.2015, 09:23

zst, ты думал про то, что в большей части игр сам спрайт взаимодействует с содержимым экрана? (например игры серии Dizzy). Как думаешь этот момент проработать?

---------- Post added at 12:23 ---------- Previous post was at 12:16 ----------

Ещё мне не очень понятны как отслеживать пересечения спрайтов.

zx-kit

03.10.2015, 09:27

zst, ты думал про то, что в большей части игр сам спрайт взаимодействует с содержимым экрана? (например игры серии Dizzy). Как думаешь этот момент проработать?

Как именно взаимодействует? Мне надо посмотреть примеры кода. Особо интересует для игры Dizzy XII: Underground (http://www.worldofspectrum.org/infoseekid.cgi?id=0015212) Если имеется ввиду наложение по маске и клешинг атрибутов, то тут вопрос уже решен. Рисовать не в промежуточный буфер, а прямо на экран в дополнительный слой №1.

Ещё мне не очень понятны как отслеживать пересечения спрайтов.
Это отслеживать как обычно по аркадным атрибутам. Если имеется ввиду наложение изображений двух спрайтов - то просто рисовать в дополнительном слое с учетом маски. Они наложатся без клешинга. У каждого спрайта может быть свой цвет.

Reobne

03.10.2015, 09:31

drbars, Прям на пиксельном уровне? Таких игр, думаю, не большинство.
Леменги, может древние лабиринты - бродилки на чистом фоне.
А на атрибутном уровне... ну, просто оставить этот атрибутный уровень да и всё. :)

drbars

03.10.2015, 10:16

Как именно взаимодействует?
Занули в анреале область с #4000 до #57FF и получишь эффект.

Мне надо посмотреть примеры кода. Особо интересует для игры Dizzy XII: Underground (http://www.worldofspectrum.org/infoseekid.cgi?id=0015212) Если имеется ввиду наложение по маске и клешинг атрибутов, то тут вопрос уже решен. Рисовать не в промежуточный буфер, а прямо на экран в дополнительный слой №1.
Изучай http://opensourcezx.untergrund.net/a_games-dizzy_xxi_src.html

Это отслеживать как обычно по аркадным атрибутам. Если имеется ввиду наложение изображений двух спрайтов - то просто рисовать в дополнительном слое с учетом маски. Они наложатся без клешинга. У каждого спрайта может быть свой цвет.
Имеется в виду не наложение, флаг пересечения спрайтов с пиксельной точностью. Для определения коллизий.

zx-kit

03.10.2015, 10:26

Занули в анреале область с #4000 до #57FF и получишь эффект.

Как это сделать ?

Изучай http://opensourcezx.untergrund.net/a_games-dizzy_xxi_src.html

Там исходники в XAS на диске TRD без комментариев. Чем отличается от дизассемблера UNREALе ? Ведь ты знаешь где эти места в коде ?

Имеется в виду не наложение, флаг пересечения спрайтов с пиксельной точностью. Для определения коллизий.
Такое наверно не используется. В Денди например как делают ? Там нет пикселов.

---------- Post added at 12:26 ---------- Previous post was at 12:22 ----------

Кстати как в UNREALE вставить кусок дизассемблированного текста в файл ?

goodboy

03.10.2015, 10:36

Кстати как в UNREALE вставить кусок дизассемблированного текста в файл ?
если сразу в программу то в мониторе alt+r (load data to memory from binary file)

drbars

03.10.2015, 10:44

zst, идея карты такова чтобы избавиться от клешинга: значит тебе просто напросто нужно сделать такую железку, чтобы было несколько битпланов стандартного 6912 экрана. Причем чтобы записывать ты мог в любой из этих битпланов, а читать уже только сложенные битпланы со стандартного адреса.
Как маскировать спрайт на битплане, чтобы сложение было без клешинга на экране можно придумать... Может автомаска? Запись в нужный битплан включать командой OUT.

zx-kit

03.10.2015, 13:54

если сразу в программу то в мониторе alt+r (load data to memory from binary file)
Мне надо было наоборот для комментирования текст в файл. Нашел рядом - alt+w.

---------- Post added at 13:31 ---------- Previous post was at 13:29 ----------

Занули в анреале область с #4000 до #57FF и получишь эффект.

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

---------- Post added at 13:32 ---------- Previous post was at 13:31 ----------

zst, идея карты такова чтобы избавиться от клешинга: значит тебе просто напросто нужно сделать такую железку, чтобы было несколько битпланов стандартного 6912 экрана. Причем чтобы записывать ты мог в любой из этих битпланов, а читать уже только сложенные битпланы со стандартного адреса.
Как маскировать спрайт на битплане, чтобы сложение было без клешинга на экране можно придумать... Может автомаска? Запись в нужный битплан включать командой OUT.
Стандартного 6912 экрана достаточно одного. А в других слоях уже использовать прозрачный цвет. Режим COLOR2M (http://zx-pk.ru/showpost.php?p=823101&postcount=385) можно назвать автомаской ? А нужный для записи слой выбирать записью в переменную current_layer.

---------- Post added at 14:46 ---------- Previous post was at 13:32 ----------

Добавил в первый пост документацию по видеокарте в формате PDF.

---------- Post added at 15:54 ---------- Previous post was at 14:46 ----------

drbars, давай твою новую игру Dizzy7 сделаем for Meteor only ?

drbars

03.10.2015, 15:04

drbars, давай твою новую игру Dizzy7 сделаем for Meteor only ?
Я пока даже от TSconf отказался. Будет стандартное 128К издание, возможно материальное даже :)
Карту к фирменной машине не прицепить, это минус... надо делать имхо на западную аудиторию. С большой программной поддержкой.

Smalovsky

03.10.2015, 15:19

drbars, делай для спектрумовского экрана, но для себя примечай, как что из графики можно будет адаптировать для метеора.

ZX_NOVOSIB

03.10.2015, 16:04

Я пока даже от TSconf отказался. Будет стандартное 128К издание, возможно материальное даже :) Материальное? Ого. Пожалуй встану в очередь ) Чур мне с афтографом ;)

Карту к фирменной машине не прицепить, это минус... надо делать имхо на западную аудиторию. С большой программной поддержкой.
Делать всё надо с оглядкой на западную аудиторию. Всё должно быть универсальным и работать как на наших клонах, так и фирменных спектрумах. Не, какую-нибудь мелочь, можно делать как угодно, но что-то серьезное, сложное, надо делать универсальным по любому.

zx-kit

04.10.2015, 07:03

Делать всё надо с оглядкой на западную аудиторию. Всё должно быть универсальным и работать как на наших клонах, так и фирменных спектрумах. Не, какую-нибудь мелочь, можно делать как угодно, но что-то серьезное, сложное, надо делать универсальным по любому.
Надо подумать, может подключать видеокарту "Meteor Graphics" через кросс-плату HEPTAGON (http://zx-pk.ru/showpost.php?p=832228&postcount=432) или укороченную версию TRITON, которые можно будет подключить к компьютерам типа Ленинград или оригнальному ZX-SPECTRUM.

Titus

04.10.2015, 10:13

drbars, давай твою новую игру Dizzy7 сделаем for Meteor only ?

Не смей такое даже предлагать, ибо линчуют на месте)

Nesser

04.10.2015, 15:53

Надо рисовать в дополнительном слое и использовать маску для задания прозрачного цвета на краях спрайта.

Не совсем понятно, то есть если в 1 байт попали части разных спрайтов то их надо рисовать на разных слоях?

Такое наверно не используется. В Денди например как делают ? Там нет пикселов.

У денди в видеопроцессоре стоит сканер спрайтов, в момент обратного хода луча он поочередно проверяет координаты спрайтов и в случае коллизии выставляет флаг коллизии с номером спрайта, это АППАРАТНОЕ устройство, там или 32 или 64 спрайта проверяется, точно уже не помню.

А разве программно проверить 10-15 координат на сравнение так сложно?

zx-kit

04.10.2015, 16:13

Не смей такое даже предлагать, ибо линчуют на месте)
А если бы предложили только под ATM или TS-Conf ?

---------- Post added at 18:13 ---------- Previous post was at 18:10 ----------

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

Nesser

04.10.2015, 19:42

zx-kit

04.10.2015, 20:54

Так я говорю не про слои а про несколько попавших спрайтов в 1 байт, то есть к примеру 1 пиксель (2 бита) это конец одного спрайта и 3 пикселя (6 бит) другого спрайта, то есть когда нужно поместить 3 пиксели то к этому времени в этот байт экрана уже поместили точку другого спрайта, то есть нужно провести считывание-обрезание-наложение-запись, программно это пирдец как долго

8 точек в слое - это физически не 1 байт, а 8 байтов внутри видеокарты. Каждый можно перекрасить в свой цвет. Допустим до этого все 8 точек были синего цвета. Потом левую точку закрасили красным цветом из одного спрайта. В памяти видеокарты будет один байт с номером красного цвета и 7 байтов с номером синего цвета. Потом сверху нарисовали еще один спрайт желтого цвета - 3 правые точки. В памяти видеокарты будет один байт с номером красного цвета, 4 байта с номером синего цвета и 3 байта с номером желтого цвета. И так можно рисовать поверх спрайт за спрайтом. Видеокарта не производит считывание и наложение битов. Она записывает новые цвета в те байты, на которые показывает маска с помощью нулевых битов. Если в байте маски бит равен 1 - соответствующий байт внутри видеокарты не меняется. Если бит равен 0 - туда записывается новый номер цвета. Номер цвета видеокарта опрделяет на основе информации из байта спрайта и байта атрибута в переменной attr.

Nesser

04.10.2015, 21:49

Nesser

05.10.2015, 08:52

Посмотри игры RimWorld и Factorio, может какие мысли дадут :)

zx-kit

06.10.2015, 06:02

А нельзя как то попроще всё это сделать?
Хочу в программах нормальные окна делать :) а это по сути обычные большие спрайты, и тут уже без дма не обойтись. Гонять по памяти придётся :) Да и шрифт выводить надо не в текстовом режиме а в графическом, а это пистец какая нагрузка.
На экране 256*192 находится 49152 пикселя, при 50 кадрах и 3,5 МГц CPU это всего лишь 1,4 такта на пиксель, то есть программно всё это делать бредовая идея, надо как можно больше задач убрать от CPU, но при этом продумать всё так что бы в последствии без ущерба можно было сделать более скоростной камень и более мощное видео...
Если надо еще проще - обращайтесь к MVV. У него крутая видеокарта uGFX с текстовым режимом.

Я текстом и блиттером пока заниматься не собираюсь. Итак много чего надо реализовать. Надо ограничивать функции видеокарты иначе в попытке сделать идеальную можно не сделать ничего.

Nesser

06.10.2015, 12:30

Я не просил текстовый режим :)
Надо текст в графическом режиме, а идеальные уже сделаны, нам надо наоборот продуманную и примитивную.

zx-kit

21.10.2015, 16:08

Поздравляю всех с этим знаменальным днем ! Сегодня к нам из прошлого прилетали на машине времени Док Браун и Марти Макфлай !

http://s019.radikal.ru/i607/1510/31/8c8d4d94155ct.jpg (http://s019.radikal.ru/i607/1510/31/8c8d4d94155c.jpg)

Цитаты из фильма "Назад в будущее":

Дороги? Там, куда мы направляемся, дороги не нужны.

Марти МакФлай: Ты что, сделал машину времени… из DeLorean?
Эмметт Браун: Если ты делаешь машину времени из автомобиля, то почему бы ей не выглядеть стильной ?

Я встал на унитаз, чтобы повесить часы, но подскользнулся и стукнулся головой о край умывальника — так мне было явлено откровение, видение, картинка в моём мозгу, видение вот этого — потокового накопителя.

- А у вас есть телевизор?
- Да, у нас их два.
- Ну вы и богачи!
- Сынок, он просто тебя дразнит. Ни у кого нет двух телевизоров.

— Ваше будущее еще не написано. И ничье. Будущее такое, каким вы его сделаете сами. Так что старайтесь!

Давайте продолжим творить будущее ! В комплекте с первыми видеокартами будет идти плата-переходник TRITON для подключения к старым компьютерам без ZX-BUS и новым компьютерам с ZX-BUS. Для них уже заказаны разъемы DIN-64.

Что-то авторы эмуляторов не хотят добавлять режим Meteor в свои эмуляторы. Наверно он очень сложный в реализации. Давайте подумаем, как можно упростить. Наверно, надо убрать ВСЕ, что не требуется для устранения клешинга атрибутов ! Тогда модель будет конечно упрощенная, зато работать в эмуляторах.

zx-kit

21.10.2015, 18:43

Чтобы рисовать спрайты ГГ без клешинга атрибутов в игре THREE WEEKS IN PARADISE надо записать в видеокарту Meteor Graphics следующие параметры:
Включение режима Метеор
Координаты X и Y по одному байту
Выбрать 1 (дополнительный), а потом вернуть в 0 (основной) слой для рисования
3 байта для маски спрайта
3 байта для данных спрайта
Режим COLOR2M для рисования спрайта с маской
Режим COLOR1C для стирания спрайта с дополнительного слоя

Этого достаточно для устранения клешинга. Его можно на большинстве девборд и в эмуляторах.
Посмотрел исходники Xpeccy - ничего не понял. Наверно я не смогу сам доработать эмулятор.
Может кто в этом лучше меня разбирается ? Я бы помог с объяснениями, что надо сделать.

Smalovsky

22.10.2015, 04:50

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

zx-kit

22.10.2015, 06:04

Так как в игре TWIP спрайт рисуется горизонтальными линиями, причем сначала 3 байта маски, а затем 3 байта спрайта можно будет использовать команды:
ld hl, адрес первого байта маски спрайта
ld de, A1 ; адрес 1 байта маски в переменных видеокарты
записать координаты X, Y верхней линии спрайта на экране

ldi ; копируем 3 байта маски
ldi
ldi

ld e, мл. байт A2 ; адрес 1 байта данных спрайта в переменных видеокарты

ldi ; копируем 3 байта маски
ldi
ldi

ld e, мл. байт A1 ; адрес 1 байта маски спрайта в переменных видеокарты
изменить координату Y
...

Raydac

22.10.2015, 09:45

Не хватает именно схем и рисунков. На словах все путано. Эмуляторщикам нужно помочь врубиться в работу видеокарты.
кстати да.. странно что с этого не начинают

zx-kit

25.10.2015, 11:06

http://s013.radikal.ru/i323/1510/fc/65ee7a4aa9c2t.jpg (http://s013.radikal.ru/i323/1510/fc/65ee7a4aa9c2.png) http://s015.radikal.ru/i332/1510/ef/6f5692c8333ft.jpg (http://s015.radikal.ru/i332/1510/ef/6f5692c8333f.png) http://s017.radikal.ru/i407/1510/0e/ebc344af015ft.jpg (http://s017.radikal.ru/i407/1510/0e/ebc344af015f.png) http://s011.radikal.ru/i318/1510/47/403b2d49cffbt.jpg (http://s011.radikal.ru/i318/1510/47/403b2d49cffb.png) http://s019.radikal.ru/i609/1510/ee/e6d63d26f552t.jpg (http://s019.radikal.ru/i609/1510/ee/e6d63d26f552.png)

Raydac

25.10.2015, 11:10

zx-kit

25.10.2015, 11:41

я правильно понял что данное решение позволяет медленно на старте загрузить спрайты в област памяти карты и потом их быстро выводить клмандой? но нельзя будет сделать полноценный скажем эффект "плазма" или текстовый редактор раскрасить который 64 символа выводит?

Нет, спрайты предварительно не загружаются в память видеокарты. Спрайты остаются в том же формате, что и в игре и остаются в том же месте. Попутно удалось перейти от 15 цветов к 255 цветов без палитры и рисовать спрайты по координатам с точностью до пиксела. Также просто реализовать режимы цвета: 3 цвета + прозрачный для спрайтов и 4 цвета для тайлов. Точки тоже просто рисовать в режиме COLOR1C, указывая координаты и выбирая цвет.

Эффект плазмы сделать нельзя, так как палитра не используется. Символы можно раскрасить, меняя перед рисованием спрайта буквы соответствующие переменные цвета. Но при 64 символах в строке ширина символа получится 4 бита, что плохо читаемо. Разрешение экрана ведь остается 256х192 пиксела.

Пока считаю указанные возможности достаточным для облегчения устранения клешинга в старых играх и увеличения цветности в новых. Также это достаточно просто реализовать в эмуляторах и компьютерах на FPGA. Было бы желание ...

zx-kit

25.10.2015, 11:52

Raydac, у тебя русскоязычного описания ZX-Poly не осталось? Есть кое-какие моменты для уточнения. Решил продолжить работу над конфигурацией.
На днях собрал Spec256 (http://www.emulatronia.com/emusdaqui/spec256/index-eng.htm), но файлы для софт эмулятора совсем не то, что нужно для аппаратного.
MVV, а режим Meteor Light по приведенному описанию можешь добавить в Speccy2010 и ReVerSE ?

Raydac

25.10.2015, 11:55

Raydac, у тебя русскоязычного описания ZX-Poly не осталось? Есть кое-какие моменты для уточнения. Решил продолжить работу над конфигурацией.
ты тогда лучше так списком спроси, а то описание косноязычное и старое, заодно и я получу фокус на непонятные моменты и опишу их более детально

Titus

25.10.2015, 13:03

Копирую сюда нашу переписку из резервного форума:

Я так понимаю, что идет преобразование 50Hz->60Hz, т.е. можно смело сказать досвидания плавному обновлению экрана.

Так его уже как бы и нет. Большинство любителей Спектрума для запуска игр используют эмуляторы с частотой экрана 60 Hz. На видеокарте можно сделать и 50 Hz, но это погоды не сделает и не все мониторы такую частоту корректно отображают. Надо подумать, как приспособиться к новой реальности. Возможно для новых игр с плавным скроллингом в эмуляторах и на LCD мониторах придется игры делать с частотой INT 60 Hz.

Вот именно, ключевое слово 'как бы' )
Настоящий спектрумист никогда не откажется от возможности насладиться плавностью one-frame демы или игры. Даже та же новая проектируемая Dizzy 7 заточена под one-frame.
А на счет частоты инта 60Hz - та это вообще фантастика, уводящая от совместимости далеко-далеко)

zx-kit

25.10.2015, 13:12

Копирую сюда нашу переписку из резервного форума:
Спасибо, понял. Добавил в первую картинку режим 50Hz/60Hz. Посоветуй, что еще доработать в режиме Meteor.

Titus

25.10.2015, 14:24

Спасибо, понял. Добавил в первую картинку режим 50Hz/60Hz. Посоветуй, что еще доработать в режиме Meteor.

Советую) Пойти по пути ZX-Poly) Только усовершенствованому)
Таким образом в играх достаточно будет лишь раскрасить графику, что в 100 раз быстрее, чем переписывать код под новую архитектуру)

Raydac

25.10.2015, 14:32

Советую) Пойти по пути ZX-Poly) Только усовершенствованому)
тогда получится ZX-Poly, а человеку хочется своего ))
у ZXPoly перед темами с "акселератором" есть один приличный минус - организация многопроцессорного взаимодействия заставляет делать весьма неслабые аппаратные и программные выкрутасы, в то время как "акселератор" как темная сторона силы - "проще, доступнее" ))

zx-kit

25.10.2015, 15:28

Raydac, а ты что посоветуешь ? Я пока делаю что-то между программым и аппаратным рисованием спрайтов. Может усовершенствую до такой степени, что для рисования спрайта нужно будет только указать координаты на экране, размеры спрайта и скопировать все командой LDIR. Но тогда игры будет писать слишком легко.

---------- Post added at 17:28 ---------- Previous post was at 17:18 ----------

Советую) Пойти по пути ZX-Poly) Только усовершенствованому)
Таким образом в играх достаточно будет лишь раскрасить графику, что в 100 раз быстрее, чем переписывать код под новую архитектуру)
Выдирать и перекрашивать графику тоже время надо. Само ничего не делается. Даже аппаратные спрайты сами не нарисуются.

Titus

25.10.2015, 15:28

тогда получится ZX-Poly, а человеку хочется своего ))
у ZXPoly перед темами с "акселератором" есть один приличный минус - организация многопроцессорного взаимодействия заставляет делать весьма неслабые аппаратные и программные выкрутасы, в то время как "акселератор" как темная сторона силы - "проще, доступнее" ))

Я сам бы сделал нечто типа ZX-Poly, только с большей глубиной цвета и множественными другими наворотами. Чтобы были слои и т.д. Тогда для любой игрушки можно будет сделать цветную графику, спрайты с маской (даже если в игре спрайты накладывались по XOR, OR или другой фигне), при этом совсем не трогая код игры. Это идеал для меня.

zx-kit

25.10.2015, 15:33

Я сам бы сделал нечто типа ZX-Poly, только с большей глубиной цвета и множественными другими наворотами. Чтобы были слои и т.д. Тогда для любой игрушки можно будет сделать цветную графику, спрайты с маской (даже если в игре спрайты накладывались по XOR, OR или другой фигне), при этом совсем не трогая код игры. Это идеал для меня.
Совсем не трогать код - это сложно. А слои, прозрачный цвет и 255 цветов из палитры ULAplus у меня есть. Плюс рисование спрайтов с точностью до точки. Для новых игр - хорошие возможности. Кто бы написал. Ведь есть же у кого-то идеи игр, которые нельзя нарисовать в цвете из-за клешинга атрибутов. Потренировались бы и отладили заодно видеорежимы. Знающие люди могли бы и эмулятор допилить до Meteor Light. Что для одного сложно - для другого просто и наоборот. Я режим придумал - давайте вместе его продвигать в массы.

Titus

25.10.2015, 16:15

Совсем не трогать код - это сложно. А слои, прозрачный цвет и 255 цветов из палитры ULAplus у меня есть.
Легко при подходе типа ZX-Poly.
Да и ULAplus палитра по нашим временам уже бедновата (если уж раскрашивать графику).

zx-kit

25.10.2015, 16:18

Легко при подходе типа ZX-Poly.
Да и ULAplus палитра по нашим временам уже бедновата (если уж раскрашивать графику).
Начал рисовать палитру. Нормальная палитра.

http://s004.radikal.ru/i205/1510/75/535509abd530t.jpg (http://s004.radikal.ru/i205/1510/75/535509abd530.png) http://s017.radikal.ru/i403/1510/a6/6257373f0f45t.jpg (http://s017.radikal.ru/i403/1510/a6/6257373f0f45.png)

Слева из описания на ULAplus. На мой взгяд - бледновато. Справа - закрашиваю посчитанными для Meteor Graphics цветами - выглядит сочно. И оттенков достаточно. Нам же не фотографии рассматривать - нам цвет для игр нужен. Тем более, для Спектрума рисунки должны закрашиваться не ровными цветами, а для красоты их надо рисовать в крапинку. Тогда все будет отлично даже если цветов всего 255 !

Raydac

25.10.2015, 17:13

а ты что посоветуешь ?
сделать черновое описание платформы, а потом обязательно сделать прогрфммный (а не аппаратный) эмуль и на нем обкатать расцвечивание какойнить игрухи, сразу удастся выяснить слабые стороны и дешево подкорректить

Я сам бы сделал нечто типа ZX-Poly, только с большей глубиной цвета и множественными другими наворотами.
потенциально по схеме ZXPoly можно сделать хоть TrueColor на спеке без задержек будет работать на Z80 )) но как то не уверен что спрос на такое будет + добавление каждого нового юнита в систему это геометрическое усложнение системы взаимодействия, ZXPoly всеж не только расцвечивать позволяет, но там процы могут друг другом рулить и можно взять скажем и сделать из одного процессорного юнита симуляцию какой то переферии, типа муз процессора

Eagle

25.10.2015, 17:24

но там процы могут друг другом рулить и можно взять скажем и сделать из одного процессорного юнита симуляцию какой то переферии, типа муз процессора
Это никто не смог сделать даже на существующем GS, а про ZX-Poly и мечтать бестолку.

zx-kit

26.10.2015, 05:51

http://s008.radikal.ru/i303/1510/5c/39fb80540582t.jpg (http://s008.radikal.ru/i303/1510/5c/39fb80540582.png)

Палитра ULAplus V.1. Менялись старшие 3 бита, младшие 5 для PC равны 0.

http://s019.radikal.ru/i632/1510/a9/08f082359e6et.jpg (http://s019.radikal.ru/i632/1510/a9/08f082359e6e.png)

Прикинул цвета по-своему. Добавил простые цвета и 16 оттенков серого.

Titus

26.10.2015, 10:38

потенциально по схеме ZXPoly можно сделать хоть TrueColor на спеке без задержек будет работать на Z80 )) но как то не уверен что спрос на такое будет + добавление каждого нового юнита в систему это геометрическое усложнение системы взаимодействия, ZXPoly всеж не только расцвечивать позволяет, но там процы могут друг другом рулить и можно взять скажем и сделать из одного процессорного юнита симуляцию какой то переферии, типа муз процессора

Не так 'в лоб' разумеется.
В моей идее там не много процессоров (каждый на свой бит), а особый процессор, у которого сразу 128-битные (или более) регистры. Кроме того, есть возможность манипуляции спрайтами, но на совместимый с игровым кодом манер. Т.е. менять в коде ВООБЩЕ НИЧЕГО не надо. Только нарисовать true-color графику, сделать маски и практически все.

Raydac

26.10.2015, 13:48

а особый процессор, у которого сразу 128-битные (или более) регистры.
ну так то понятно что можно, но это уже специальный кастомный проц, мне с zxpoly было интересно что то что потенциально можно из элементной базы 80-х собрать, пускай и шкафчик получится, интересно было могли ли тогда уже на коленке дома собрать что то по мощности как PC XT или нет

Djoni

26.10.2015, 19:02

Это никто не смог сделать даже на существующем GS, а про ZX-Poly и мечтать бестолку.

Были проекты General Sound AY Emulator v1.0 http://www.zxpress.ru/article.php?id=9503

Eagle

26.10.2015, 19:06

Были проекты General Sound AY Emulator v1.0 http://www.zxpress.ru/article.php?id=9503
А на выхлопе даже демки нет.

Nesser

22.03.2016, 23:23

Мне кажется или все завяло?

zx-kit

04.04.2016, 19:12

Наверно будет с выходом FULL HD на основе видеоадаптера VGA SPUTNIK.
Z80-MUX + VGA SPUTNIK = METEOR.

ram_scan

05.04.2016, 20:19

Ребят, а не проще на MSX-2 переползти и велисапед не изобретать ?

jerri

06.04.2016, 20:01

ram_scan, а смысл? мсх-2 совершенно другая идеология

Sayman

07.04.2016, 11:25

интересно:

Палитра - 3х6 бит (как BMP 256), размещена во внутренней памяти FPGA 256 * 18 бит.
Только у БМП 256 цветов, палитра хранится в формате 4x8 (RGBa, последний байт всегда равен 0, в заголовке под палитру 1024 байта отведено, proof (https://en.wikipedia.org/wiki/BMP_file_format#Color_table):In most cases, each entry in the color table occupies 4 bytes, in the order blue, green, red, 0x00 (see below for exceptions). This is indexed in the BITMAPINFOHEADER under the function biBitCount.). Это можно видеть при выгрузке картинки из фотошопа. Про другие редакторы и конвертилки я не знаю и на них не полагаюсь. Хотя знаю, что, например, xnView, если в картинке меньше 256 цветов, то он в заголовок кидает соответствующую палитру. т.е. если будет 128 цветов, то половина заголовка будет выкушена из файла. Возможно какие-то другие программки пихают палитру ещё как-то иначе. Кроме того, Спринтер имеет такой же формат палитры и я просто беру БМП файл, из его заголовка выгребаю как есть палитру, применяю её и далее кидаю сам битмап в экран.
И в целом не понятно, к чему ограничиваться 5+5+5 палитрой, когда можно свободно сделать 8+8+8 и ни о чём не парится?!

размещена во внутренней памяти FPGA 256 * 18 бит.
5+5+5 = 15 бит. От куда ещё 3 бита взялось и для чего? С точки зрения математики и просто удобства, проще и удобнее хранить как 24бита (8+8+8).

да и опять-таки, несколько раз предлагалось в теме - вкарячить в карту подобие шейдеров - описание того, что и как делать со спрайтами/тайлами/адерсами их хранения. Без этого получается очередной тайлоспрайтовый двиг аля ТС на котором даже ротозум полноэкранный будет тормозить...

s_kosorev

07.04.2016, 17:51

5+5+5 = 15 бит. От куда ещё 3 бита взялось и для чего?
ты странный, непонятный кусок без контекста и ссылки на оригинал процитировал, хочешь ответа, ладно бы если поиск работал, а так вообще в воздух

но можно предположить 18 бит это ширина рам блока в альтерах, то есть один М512 блок позволяет хранить 256x18 данные, удобно

Sayman

07.04.2016, 18:10

ты странный, непонятный кусок без контекста и ссылки на оригинал процитировал, хочешь ответа, ладно бы если поиск работал, а так вообще в воздух
вопрос адресован разработчику. Он в курсе от куда эта цитата. Но если так нужно и другим, то это от сюда (http://zx-pk.ru/showthread.php?t=21462&p=610738&viewfull=1#post610738).

то есть один М512 блок позволяет хранить 256x18 данные, удобно
Вопрос в том, что это удобно только одному - тот кто девайс разрабатывает, а не тем для кого он его разрабатывает. Удобнее работать с полной палитрой, а не с её огрызком. А как там в плисине это выглядит, кодеру/пользователю фиолетово!

s_kosorev

07.04.2016, 18:24

Вопрос в том, что это удобно только одному - тот кто девайс разрабатывает, а не тем для кого он его разрабатывает. Удобнее работать с полной палитрой, а не с её огрызком. А как там в плисине это выглядит, кодеру/пользователю фиолетово!
тут 2 варианта: не укладываемся в емкость чипа, все идет лесом, либо работаем с 5 бит на компоненту, что по удобности не сильно отличается от 6 бит на компоненту, а цветовое разрешение в 8 раз меньше
тем более это палитра, с ней хоть на бейсике работай

- - - Добавлено - - -

вопрос адресован разработчику.
у разработчика тоже поиск не работает, он у всех не работает

Sayman

07.04.2016, 18:42

тут 2 варианта: не укладываемся в емкость чипа
ОПА?!
в Метеоре хотят использовать FPGA EP2C5Q208. Кол-во логических ячеек - 4608.
У Спринтера используется более древняя EP1K30QC208. Кол-во логических ячеек - 1728.
А теперь вопрос - почему в плисину по объёму почти в 2 раза меньше засунули целый комп с палитрой 32 бита, а в Метеоре в жирную плисину кое как влезает 15бит? что за приколы такие?
Не жирновато потратить такую жирную плисину фиг знает на что?

zx-kit

07.04.2016, 19:46

Со временем параметры возможностей и аппаратуры меняются/уточняются. Разработка так затянулась...
Сейчас это VGA выход FULL HD 1920х1080 60Hz 15 бит. Количество цветов 32768 как в SUPER NINTENDO.
Внутри FPGA развертка с частотой 50 Hz. Масштабирование разрешения 256х192 в 4 раза по-вертикали и по-горизонтали.

s_kosorev

07.04.2016, 20:14

в Метеоре хотят использовать FPGA EP2C5Q208. Кол-во логических ячеек - 4608.
У Спринтера используется более древняя EP1K30QC208. Кол-во логических ячеек - 1728.
я в спринтрах не разбираюсь, но сюда по нагугленному, что то дофига занимает ресурсов для описного функционала, очень дофига, это раз
во2. в 1728 LE, ничего толкового не всунуть

zx-kit

07.04.2016, 20:34

На мой взгляд число битов 15 на цвет точки оптимальное по объему данных, скорости и качеству изображения. 15 битов влезет в одно слово памяти, а шестнадцатый бит можно использовать как признак прозрачности. Отбросив три младших бита из 8, почти ничего не потеряем в качестве изображения. 32 оттенка серого или другого основного цвета + их комбинации вполне приемлемо для игр ZX Spectrum-a.

Sayman

08.04.2016, 08:33

я в спринтрах не разбираюсь, но сюда по нагугленному, что то дофига занимает ресурсов для описного функционала, очень дофига
по твоему там мало функционала? я же говорю - в плисине комп зашит. там сидит и обработка клавы и мыши, там же АУ, там же работа с графикой, линейный акселератор, гшина иса8 и чёрт знает что ещё. К примеру, в zx-evo стоит альтера на 2880 лог.элементов, там тоже целый комп. Но всё это занимает в 2 с лихой раза меньше, чем начинка для (всего-лишь) видеокарточки. В конфиге ТС тоже есть всякие 15бит палитры, и спрайтотайло двиг и занимает это всё тоже меньше места, чем сабж. Ты не находишь это странным?

32 оттенка серого
что такое 32 оттенка и что такое 256 оттенков. Разница существенна, даже на замыленный глаз.

их комбинации вполне приемлемо для игр ZX Spectrum-a
Для игр ZX-Spectrum`а есть его родная графика с его родными 16ю цветами. Если речь заводим про расширение его графических возможностей, то и расширять нужно по нормальному, а не очередной кастыль кастылить...
И кстати да, 15бит уже есть в ТС конфиге. Зачем повторять чужие ошибки-то?

s_kosorev

08.04.2016, 09:47

обработка клавы и мыши, там же АУ, там же работа с графикой, линейный акселератор, гшина иса8 и чёрт знает что ещё.
ну AY просмотрел, походу он и съел весь чип, остальное ну 200-500 LE

Sayman

08.04.2016, 13:58

ну AY просмотрел, походу он и съел весь чип, остальное ну 200-500 LE
Прикольна. А что тогда baseconf для эвы? тоже там 500-600 LE? хотя там АУ нет в плисине, однако сожрата почти вся плисина, а начинка стоковой конфы там слабее, чем у спринтера.
Если настолько сильный ahdl/vhdl кодер, может быть сможешь конфу спринтера подправить и оптимизировать?

s_kosorev

08.04.2016, 15:52

Прикольна. А что тогда baseconf для эвы? тоже там 500-600 LE? хотя там АУ нет в плисине, однако сожрата почти вся плисина,
без понятия, ссылку на сырки, можно посмотреть что и где съело

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

skyther

08.04.2016, 17:35

пипл, а может с другой стороны подойти к проблеме? начните писать диззи-подобный движок и в процессе придет понимание как, а главное зачем всё это нужно :)

zx-kit

09.04.2016, 12:05

Изменения в проекте:

Восемь битов на каждый сигнал RGB.
Частота видеорежимов 50 Hz.
VGA выход FULL HD 1920х1080 60 Hz.
Повтор каждого шестого кадра для преобразования 50 Hz -> 60 Hz.
Масштабирование изображения в 4 раза (256 x 192 -> 1024 x 768 + BORDER).
Scanlines для имитации развертки древних телевизоров.

- - - Добавлено - - -
Размеры окна Спектрума на экране телевизора/монитора с разрешением FULL HD:

http://s017.radikal.ru/i431/1604/90/ba224eb331c1t.jpg (http://s017.radikal.ru/i431/1604/90/ba224eb331c1.jpg)

zx-kit

14.04.2016, 06:06

Давайте обсудим такой интерфейс с видеокартой:

Упростить систему команд Метеора до двух адресов. По одному адресу записывается номер регистра внутри видеокарты. По другому адресу записываются данные в этот регистр. Такой способ управления позволит вынести Метеор в отдельный корпус и подключать к разным компьютерам и микроконтроллерам, как LCD индикатор 2х16 строк. Или добавить эти функции в видеоадаптер VGA SPUTNIK.

А основной экран брать в аналоговом виде с платы компьютера.

s_kosorev

14.04.2016, 08:29

Повтор каждого шестого кадра для преобразования 50 Hz -> 60 Hz.
50Hz спектрум, насколько я понимаю, почти сферический, в ходу более популярный с около 48Hz или не прав?

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

zx-kit

14.04.2016, 19:48

50Hz спектрум, насколько я понимаю, почти сферический, в ходу более популярный с около 48Hz или не прав?
Точная частота кадров не очень важна. На мониторе кадры будут идти немного ускоренно через 1/60 Hz = 16,7 mS вместо 1/50 Hz = 20 mS или 1/48 Hz = 20,8 mS. В целом плавность движений остается. А один кадр будет повторяться по мере надобности. Лучшего способа преобразования не придумал.

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

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

В адресном пространстве микропроцессора нужно выбрать два адреса. Сделать схему дешифрации, чтобы при записи в эти адреса мы получили два сигнала записи. Шину данных подать на разъем через буфер, например, 555АП6. Подаем эти 10 сигналов на FPGA видеокарты через схему согласования. Запись в FPGA с шины данных по спаду сигналов записи. Это обеспечит большую скорость.

В микроконтроллере можно один порт использовать как данные, а две линии в другом порте как сигналы записи.

В видеокарте нам нужны несколько регистров для настройки режимов. Например, мы хотим изобразить спрайты или текст в режиме три цвета + прозрачный. Вот минимальный список регистров. Максимальное количество 256, хотя может не хватить объема FPGA.

Младший байт координаты X
Старший байт координаты X
Младший байт координаты Y
Старший байт координаты Y
Режим цвета - число байтов на 8 точек, наличие прозрачного цвета и т.д.
Высота спрайта
Номер палитры
Номер цвета в палитре
Масштаб по X
Масштаб по Y
Номер слоя
Маска включенных слоев

Запись данных должна увеличивать номер регистра, если был не регистр данных. Это позволит выбрать номер одного регистра, а затем загружать данные в несколько регистров подряд. Также можно загружать данные в память с автоматическим вычислением следующего адреса в памяти.

Lethargeek

14.04.2016, 20:57

ОПА?!
в Метеоре хотят использовать FPGA EP2C5Q208. Кол-во логических ячеек - 4608.
У Спринтера используется более древняя EP1K30QC208. Кол-во логических ячеек - 1728.
А теперь вопрос - почему в плисину по объёму почти в 2 раза меньше засунули целый комп с палитрой 32 бита, а в Метеоре в жирную плисину кое как влезает 15бит? что за приколы такие?
Не жирновато потратить такую жирную плисину фиг знает на что?
не "фиг знает на что", а на "полезные и нужные" "улучшения" c "упрощением" использования оных :rolleyes:
а теперь ответ - потому что бессистемное нагромождение "упрощений" многократно усложняет систему в целом

AzAtom

21.04.2016, 15:21

zst, вы эту http://zx-pk.ru/threads/21462-bystraya-videokarta-quot-meteor-2013-quot/page32.html тему уже забросили? Написал там пост с идеями относительно видеокарты.

zx-kit

20.08.2016, 19:18

На текущий момент концепция видеокарты «Meteor Graphics» такая:

Изображение на экране получается путем наложения 8 слоев. Они располагаются в статической памяти видеокарты (SRAM) общим объемом 2 MB. Неиспользуемые слои можно отключать. Каждая точка представлена 16 битами (одним словом SRAM). В слое может быть до 32768 разных цветов. Каждый слой состоит из двух блоков размером 256 х 256 точек. Слой можно использовать для фона из тайлов или изображения движущихся объектов из спрайтов. Для фона можно применить аппаратный скроллинг. А для устранения мерцания спрайтов можно рисовать их в одном блоке и отображать при этом другой блок. Для отображения нужной части слоя задается смещение по X и Y для каждого слоя. Размер активной части экрана 256 x 224 точки.

Для устранения клешинга атрибутов в старых играх и экономии памяти на графику в новых играх в тайлах и спрайтах на каждую точку приходится по 2 бита. Перед рисованием тайла или спрайта выбираются 4 текущих цвета из возможных 32768 (с кодами 0000-7FFF) и двух кодов прозрачности (8000 — не менять цвет точки в слое или 8001 — сделать точку слоя прозрачной). Текущие цвета можно менять в любой момент. Спрайты и тайлы рисуются сразу по 8 точек. Для этого в видеокарту на каждые 8 точек записывается по 2 байта. Получается по 2 бита на точку. Это дает 4 комбинации. Каждой комбинации соответствует один из четырех текущих цветов. Видеокарта записывает по 8 точек в текущий слой, перекрашивая точки в текущие цвета.

Lethargeek

21.08.2016, 00:35

мрак и ужос... zst, я начинаю подозревать, что ты так просто тролишь своеобразно :D

zx-kit

21.08.2016, 15:40

Для устранения клешинга атрибутов достаточно двух цветов + прозрачный. А если будет 3 цвета + прозрачный можно сделать хорошие спрайты:

http://s020.radikal.ru/i708/1608/40/80dd364094c1.gif (http://radikal.ru/big/bf1739d6f875450fbeabaa57a5a0aeba)

Обычно достаточно использоваться черный + белый + один из цветов:

http://i042.radikal.ru/1608/54/79b5bce2baact.jpg (http://i042.radikal.ru/1608/54/79b5bce2baac.png)

Если трех цветов не хватает можно поверх нарисовать детали другими тремя цветами:

http://s019.radikal.ru/i644/1608/9b/54123e4ad79c.png (http://radikal.ru/big/45b5273c2f0f4789ae8830e5e027ae69)

Подробнее про это тут (https://habrahabr.ru/post/229187/).

http://s017.radikal.ru/i437/1608/f2/4e440daf7782.png (http://radikal.ru/big/3010b4f444ce442181dff86785b859f3)

Smalovsky

21.08.2016, 16:58

Если трех цветов не хватает можно поверх нарисовать детали другими тремя цветами:

Это напоминает технологию иноземцева, только у него каждый дополнительный цвет свой слой.

Lethargeek

21.08.2016, 21:33

Для устранения клешинга атрибутов достаточно двух цветов + прозрачный. А если будет 3 цвета + прозрачный можно сделать хорошие спрайты:
"3 + прозрачный" не настолько лучше спектрумовских "2 + прозрачный", чтобы ради них в старых играх полностью переделывать графпроцедуры и сами спрайты
если уж возиться и переделывать, то не ради этой жалкой добавки и картинки качества тридцатилетней приставки

zx-kit

21.08.2016, 22:13

"3 + прозрачный" не настолько лучше спектрумовских "2 + прозрачный", чтобы ради них в старых играх полностью переделывать графпроцедуры и сами спрайты
если уж возиться и переделывать, то не ради этой жалкой добавки и картинки качества тридцатилетней приставки

Да, старые игры можно относительно легко доработать только до 2+. А для новых можно сразу в 3+ делать. Согласись, что это будет недостижимый для старой графики Спектрума эффект ! Хотя он появился в 1983 году. А лучше в играх и не надо.

Количество цветов на экране и в спрайтах нужно в разумных пределах ограничивать. Игры - это ведь не фотографии, тут все условно. Да и рисовать трехцветные изображения проще. И занимают они минимальный объем памяти. Графика не должна отвлекать от сюжета и самой игры. Главное, чтобы не было грубых дефектов в виде клешинга, мерцаний спрайтов и тормозов. Над чем я и работаю, разарабатывая видеокарту Метеор.

Lethargeek

22.08.2016, 00:15

Да, старые игры можно относительно легко доработать только до 2+. А для новых можно сразу в 3+ делать.
в новых сразу можно (и нужно!) применять блиттер и все цвета, которые поддерживает железо

Согласись, что это будет недостижимый для старой графики Спектрума эффект !
это будет жалкая пародия на консоли старой спектрумовской эпохи :v2_sick:

А лучше в играх и не надо.
не надо говорить за всех, что им надо

Количество цветов на экране и в спрайтах нужно в разумных пределах ограничивать.
ты хочешь ограничивать в неразумных

Игры - это ведь не фотографии, тут все условно.
может, лучше чтобы каждый сам себе условия мог задать?

Да и рисовать трехцветные изображения проще
проще не страдать от искусственных религиозных ограничений и не мучиться с "единственно кошерным" числом цветов

И занимают они минимальный объем памяти.
тебе памяти в 2016 не хватает? лучше на слои бездарно потратить? :v2_dizzy_facepalm:

Графика не должна отвлекать от сюжета и самой игры
графика не должна портить впечатление от сюжета и самой игры

Главное, чтобы не было грубых дефектов в виде клешинга, мерцаний спрайтов и тормозов. Над чем я и работаю, разарабатывая видеокарту Метеор.
ты работаешь над стрельбой из пушки по воробьям

zx-kit

23.08.2016, 20:00

Текущие переменные для управления видеокартой «Meteor»:

КООРДИНАТЫ:

xl, xh — координата X в пикселах (младший и старший байты)
yl, yh — координата Y в пикселах (младший и старший байты)

РАЗМЕРЫ ТАЙЛА ИЛИ СПРАЙТА:

dxl, dxh — ширина в пикселах (младший и старший байты)
dyl, dyh — высота в пикселах (младший и старший байты)

ЦВЕТА:

color_1_l, color_1_h — цвет 1 (младший и старший байты)
...
color_4_l, color_4_h — цвет 4 (младший и старший байты)

УПРАВЛЕНИЕ СЛОЯМИ:

layer — номер слоя, на котором рисуем (1-8)

layer_1_on — включение слоя 1 (0 = off, 1 = on)
layer_1_sxl, layer_1_sxh — смещение слоя 1 по-горизонтали (младший и старший байты)
layer_1_syl, layer_1_syh — смещение слоя 1 по-вертикали (младший и старший байты)
...
layer_8_on — включение слоя 8 (0 = off, 1 = on)
layer_8_sxl, layer_8_sxh — смещение слоя 8 по-горизонтали (младший и старший байты)
layer_8_syl, layer_8_syh — смещение слоя 8 по-вертикали (младший и старший байты)

Итого: 57 байтов

Возможно в дальнейшем:

УПРАВЛЕНИЕ ВЫВОДОМ СПРАЙТОВ:

mirror_h — зеркалить по горизонтали
mirror_v — зеркалить по вертикали
alpha — рисовать с учетом коэффициента прозрачности

Smalovsky

23.08.2016, 20:14

zst,
mirrorh -зеркалить по горизонтали
mirrorv - зеркалить по вертикали
alpha - рисовть с учетом коэффициента прозрачности

Smalovsky

25.08.2016, 23:15

Предлагаю следующие регистры:
accel_mode - выбор аппаратного ускорения: 0 - через регистр данных, 1 - БЛИТТЕР.
out_mode - режим вывода: 0 - вывод через регистр данных или блиттер, 1- режим ластика;
В режиме ластика при выводе через регистр данных запись любого значения в регистр данных приводит к к заполнению области вывода цветом очистки, при выводе блиттером область вывода заполняется цветом очистки.
out_control - регистр контроля. При выводе через блиттер, значение нулевого бита: 0 - пересылки нет( устанавливается после пересылки), запись 1 - начать пересылку; значение первого бита: 0 - данные из памяти брать последовательно, 1 - данные из памяти выравнивать в соответствии с регистрами dxl, dxh, dyl, dyh, alignment_value( этот режим работы блиттера полезен, когда нужно переслать подготовленную в памяти компьютера теневую область). При выводе через регистр данных, значение нулевого бита устанавливается и сохраняется значение 1 при последовательной записи значений в регистр данных, запись 0 приведёт к сбросу последовательного вывода и дальнейшее заполнение области вывода будет происходить сначала; значение первого бита игнорируются.
Пары регистров clear_color_1_h:clear_color_1_l .. clear_color_1_h:clear_color_1_l - двубайтное значение цвета очистки для каждого слоя с учётом значений прозрачности.
data_format - формат данных для вывода через регистр данных или блиттер:
0 - двуцветный вывод двумя первыми служебными цветами;
1 - двуцветный вывод двумя первыми служебными цветами с учётом маски;
2 - вывод служебными цветами;
3 - ВЫВОД ДВУБАЙТНЫМ ЗНАЧЕНИЕМ ЦВЕТА С УЧЁТОМ ПРОЗРАЧНОСТИ. Запись в регистр данных при таком формате последоватиельна - побойтово передаётся значение цвета.
alignment_value - значение ширины строки по которому происходит выравнивание данных блиттером при считывании данных из памяти.
bl_status - статус пересылки данных блиттером: 0 - пересылка закончена, 1 - пересылка идёт.
Пары регистров bl_addr_h:bl_addr_l - задают начало пересылаемой блиттером области данных в нутри страницы( для регистра bl_addr_h биты 7 и 6 игнорируются).
bl_num_page - номер страницы в которой начинается область данных пересылаемой блиттером.
Адрес назначения во внутренней памяти видеокарты при пересылке блиттером вычисляется автоматически исходя из значений регистров xl, xh, yl, yh. Блиттер сам выравнивае выводимые данные в области вывода и определяет количество пересылаемых байт используя значения регистров dxl, dxh, dyl, dyh. Другими словами - со стороны памяти компьютера данные можно брать с выравниванеием или последовательно, а со стороны области вывода данные выводятся с выравниванием автоматически.
Соглашение о выводе через регистр данных:
Последовательная запись значений в регистр данных приводит к последовательному заполнению области вывода, определяемую регистрами xl, xh, yl, yh, dxl, dxh, dyl, dyh. Перезапись одного из перечисленных регистров приводит к началу последовательного вывода в начало новой области вывода. Что бы сделать сброс последовательного вывода и вернутся к выводу в начало области вывода не переопределяя последнюю - необходимо ваоспользоваться регистром out_control.