Быстрая видеокарта "METEOR-2013"

[Reobne]

я к примеру не хочу лопатить nether earth (самая распространённая русифицированная версия была мной переведена ) только ради того что бы убрать клешинг на жёлто-черном экране, мне его проще сделать заново если будет нормальная аппаратная организация спрайтов 8 бит на точку.

Так ведь были разные TS-Config-и. Они чем не устраивали, чтобы переделать под них nether earth?

[Lethargeek]

Не надо так реагировать на слово Денди или приставка. Клешинга там нет.

Много чего нет. Например, нормального контроля каждого пикселя. И даже тайлов не хватает на весь экран.

Что полезного в графике Денди

Ага, полезного в восемьдесят лохматом году, когда память была очень недешёвой и очень медленной.
Что в ней СЕЙЧАС полезного по сравнению с нормальным блиттером в хайколоре?

Метеор: 2 бита на цвет точки. Атрибут на область 8х1 точек, рабочие 4 цвета из 32768, любой из четырех можно указать как прозрачный. Атрибут не хранится в памяти, а перекрашивает точки в 4 цвета при рисовании тайла или спрайта.

то, что ты описал для метеора - не атрибут и не совместимо с процедурами в играх спектрума

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

Нахрена СЕЙЧАС аппаратный скроллинг? Нам что, не хватает скорости памяти, чтобы "двигать" через произвольное обновление?

Метеор: для рисования спрайта указываются координаты спрайта, размеры, 4 цвета, затем копируются данные спрайта командой LDIR. Возможно несколько вариантов копирования, например, данные можно писать по одному адресу. Можно без изменений использовать спрайты с маской при доработке старых (уже написанных) игр. Спрайты можно накладывать, цвет спрайта можно менять в процессе рисоания. В слое возможно до 32768 цветов. 2 экрана в каждом слое. Чтобы не было мерцаний один экран отображается, а на другой в это время рисуются новые спрайты.

Зачем так? В старых играх с наскока неприменимо (там не координаты, там адреса в оригинальной раскладке).
А если уж код и переделывать настолько, то ради полноцветного блитинга, а не ради жалкого двухбитного цвета.
Заодно и костыли типа аппаратного скроллинга можно выкинуть.

[zx-kit]

Ага, полезного в восемьдесят лохматом году, когда память была очень недешёвой и очень медленной.
Что в ней СЕЙЧАС полезного по сравнению с нормальным блиттером в хайколоре?
Нахрена СЕЙЧАС аппаратный скроллинг? Нам что, не хватает скорости памяти, чтобы "двигать" через произвольное обновление?

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

Зачем так? В старых играх с наскока неприменимо (там не координаты, там адреса в оригинальной раскладке).
А если уж код и переделывать настолько, то ради полноцветного блитинга, а не ради жалкого двухбитного цвета.
Заодно и костыли типа аппаратного скроллинга можно выкинуть.

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

Я предлагаю упростить расчеты и рисование спрайта. Мы будем использовать координаты. Вместо вычислений с маской мы просто будем записывать маску и байт спрайта в видеокарту. Поэтому новая процедура рисования спрайта будет короче и выполняться быстрее. То есть, скорость работы игры не уменьшится.

Давай пока блиттер отложим на следующий этап. На первом этапе устраним клешинг программным способом с элементами ускорения, описанным выше. Но это все программная реализация. Нам сейчас надо доделать аппаратные задачи и спроектировать плату. Желательно предусмотреть заранее аппаратные требования для типовых игр уровня Денди и PC времен MSDOS 6.22. Дальше предлагаю не усложнять требования.

Сейчас для 8 слоев предусмотрена быстрая 10 ns память SRAM объемом 2M. Предлагаю подумать о выборе:
1. Для блиттера увеличить в два раза скорость операций чтения и записи из/в SRAM за счет удвоения ширины шины данных с 16 до 32. Для этого добавить еще SRAM 2M. Читаться и писаться будет по две точки вместо одной.
2. Добавить SDRAM 32M для памяти тайлов/спрайтов и буфера VGA. Читаться и писаться будет по одной точке.

[Lethargeek]

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

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

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

Я предлагаю упростить расчеты и рисование спрайта. Мы будем использовать координаты. Вместо вычислений с маской мы просто будем записывать маску и байт спрайта в видеокарту. Поэтому новая процедура рисования спрайта будет короче и выполняться быстрее. То есть, скорость работы игры не уменьшится.

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

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

Ну, отложи пока. Но только не тащи подпорки и костыли при этом на его место.

Желательно предусмотреть заранее аппаратные требования для типовых игр уровня Денди и PC времен MSDOS 6.22. Дальше предлагаю не усложнять требования.

Желательно начинать с уяснения потенциала современного железа, а не с "неусложнения" наугад до уровня пародии на приставки или старые песюки.

Сейчас для 8 слоев предусмотрена быстрая 10 ns память SRAM объемом 2M. Предлагаю подумать о выборе

Предлагаю выкинуть бесполезные слои на мороз.

1. Для блиттера увеличить в два раза скорость операций чтения и записи из/в SRAM за счет удвоения ширины шины данных с 16 до 32.

у тебя же ног у плис не хватало)))

Читаться и писаться будет по две точки вместо одной.

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

2. Добавить SDRAM 32M для памяти тайлов/спрайтов и буфера VGA. Читаться и писаться будет по одной точке.

что еще за тайлоспрайты опять полезли?

[s_kosorev]

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

rle очень просто делается

[Sayman]

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

Читаться и писаться будет по две точки вместо одной.

это тоже очередной костыль. ТСлаб тоже сделал подобный баян в своём конфиге, только в дма, который умеет только по 2 байта (кратность 2 байта). если надо кратно 1 байту, то ловим пачку багов. нет уж, сами с этим играйтесь...

[Advertiser]

[Hacker VBI]

Sayman, баян баяном, но проц при пересылке остаётся свободным.
а что за пачка багов, расскажи?

мне для расширения кругозора интересно.

[Sayman]

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

[Hacker VBI]

Sayman, ты бред несёшь.

Эффект я видел. Дма там юзается только для обновления фона. Вот обсуждение этого эффекта
Слова джерри: "ДМА да использую чтобы восстановить фон. но восстанавливаю с запасом ибо лень считать было"

Читай за DMA, а не придумывай и выдавай выдумки за правду.

[Sayman]

Hacker VBI, я сижу в отладчике и вижу как оно работает.
если ты считаешь. что я гоню отсебятину, обрати внимание на мануалы и факи от тслаба:

Q: Почему в регистрах младших битов адресов не используется 0-й бит?
А: Для получения наибольшего быстродействия и минимальных затрат логики ДМА работает с 16-битными данными, следовательно адреса четные.
Записывая в младший байт регистра адреса число, младший бит НЕОБХОДИМО занулять.