я в спринтрах не разбираюсь, но сюда по нагугленному, что то дофига занимает ресурсов для описного функционала, очень дофига, это раз
во2. в 1728 LE, ничего толкового не всунуть
Вид для печати
На мой взгляд число битов 15 на цвет точки оптимальное по объему данных, скорости и качеству изображения. 15 битов влезет в одно слово памяти, а шестнадцатый бит можно использовать как признак прозрачности. Отбросив три младших бита из 8, почти ничего не потеряем в качестве изображения. 32 оттенка серого или другого основного цвета + их комбинации вполне приемлемо для игр ZX Spectrum-a.
по твоему там мало функционала? я же говорю - в плисине комп зашит. там сидит и обработка клавы и мыши, там же АУ, там же работа с графикой, линейный акселератор, гшина иса8 и чёрт знает что ещё. К примеру, в zx-evo стоит альтера на 2880 лог.элементов, там тоже целый комп. Но всё это занимает в 2 с лихой раза меньше, чем начинка для (всего-лишь) видеокарточки. В конфиге ТС тоже есть всякие 15бит палитры, и спрайтотайло двиг и занимает это всё тоже меньше места, чем сабж. Ты не находишь это странным?Цитата:
я в спринтрах не разбираюсь, но сюда по нагугленному, что то дофига занимает ресурсов для описного функционала, очень дофига
что такое 32 оттенка и что такое 256 оттенков. Разница существенна, даже на замыленный глаз.Цитата:
32 оттенка серого
Для игр ZX-Spectrum`а есть его родная графика с его родными 16ю цветами. Если речь заводим про расширение его графических возможностей, то и расширять нужно по нормальному, а не очередной кастыль кастылить...Цитата:
их комбинации вполне приемлемо для игр ZX Spectrum-a
И кстати да, 15бит уже есть в ТС конфиге. Зачем повторять чужие ошибки-то?
Прикольна. А что тогда baseconf для эвы? тоже там 500-600 LE? хотя там АУ нет в плисине, однако сожрата почти вся плисина, а начинка стоковой конфы там слабее, чем у спринтера.Цитата:
ну AY просмотрел, походу он и съел весь чип, остальное ну 200-500 LE
Если настолько сильный ahdl/vhdl кодер, может быть сможешь конфу спринтера подправить и оптимизировать?
пипл, а может с другой стороны подойти к проблеме? начните писать диззи-подобный движок и в процессе придет понимание как, а главное зачем всё это нужно :)
Изменения в проекте:
Восемь битов на каждый сигнал 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
Давайте обсудим такой интерфейс с видеокартой:
Упростить систему команд Метеора до двух адресов. По одному адресу записывается номер регистра внутри видеокарты. По другому адресу записываются данные в этот регистр. Такой способ управления позволит вынести Метеор в отдельный корпус и подключать к разным компьютерам и микроконтроллерам, как LCD индикатор 2х16 строк. Или добавить эти функции в видеоадаптер VGA SPUTNIK.
А основной экран брать в аналоговом виде с платы компьютера.
Точная частота кадров не очень важна. На мониторе кадры будут идти немного ускоренно через 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
Номер слоя
Маска включенных слоев
Запись данных должна увеличивать номер регистра, если был не регистр данных. Это позволит выбрать номер одного регистра, а затем загружать данные в несколько регистров подряд. Также можно загружать данные в память с автоматическим вычислением следующего адреса в памяти.
zst, вы эту http://zx-pk.ru/threads/21462-bystra...ot/page32.html тему уже забросили? Написал там пост с идеями относительно видеокарты.
На текущий момент концепция видеокарты «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 точек в текущий слой, перекрашивая точки в текущие цвета.
мрак и ужос... zst, я начинаю подозревать, что ты так просто тролишь своеобразно :D
Для устранения клешинга атрибутов достаточно двух цветов + прозрачный. А если будет 3 цвета + прозрачный можно сделать хорошие спрайты:
http://s020.radikal.ru/i708/1608/40/80dd364094c1.gif
Обычно достаточно использоваться черный + белый + один из цветов:
http://i042.radikal.ru/1608/54/79b5bce2baact.jpg
Если трех цветов не хватает можно поверх нарисовать детали другими тремя цветами:
http://s019.radikal.ru/i644/1608/9b/54123e4ad79c.png
Подробнее про это тут.
http://s017.radikal.ru/i437/1608/f2/4e440daf7782.png
Это напоминает технологию иноземцева, только у него каждый дополнительный цвет свой слой.Цитата:
Если трех цветов не хватает можно поверх нарисовать детали другими тремя цветами:
Да, старые игры можно относительно легко доработать только до 2+. А для новых можно сразу в 3+ делать. Согласись, что это будет недостижимый для старой графики Спектрума эффект ! Хотя он появился в 1983 году. А лучше в играх и не надо.
Количество цветов на экране и в спрайтах нужно в разумных пределах ограничивать. Игры - это ведь не фотографии, тут все условно. Да и рисовать трехцветные изображения проще. И занимают они минимальный объем памяти. Графика не должна отвлекать от сюжета и самой игры. Главное, чтобы не было грубых дефектов в виде клешинга, мерцаний спрайтов и тормозов. Над чем я и работаю, разарабатывая видеокарту Метеор.
в новых сразу можно (и нужно!) применять блиттер и все цвета, которые поддерживает железо
это будет жалкая пародия на консоли старой спектрумовской эпохи :v2_sick:
не надо говорить за всех, что им надо
ты хочешь ограничивать в неразумных
может, лучше чтобы каждый сам себе условия мог задать?
проще не страдать от искусственных религиозных ограничений и не мучиться с "единственно кошерным" числом цветов
тебе памяти в 2016 не хватает? лучше на слои бездарно потратить? :v2_dizzy_facepalm:
графика не должна портить впечатление от сюжета и самой игры
ты работаешь над стрельбой из пушки по воробьям
Текущие переменные для управления видеокартой «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 — рисовать с учетом коэффициента прозрачности
zst,
mirrorh -зеркалить по горизонтали
mirrorv - зеркалить по вертикали
alpha - рисовть с учетом коэффициента прозрачности
Предлагаю следующие регистры:
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.