Hacker VBI, тут вообще-то тема про Метеор. Или пиши как программировать для Метеора, или делай свой топик.
Я заинтересовался программированием для Метеора. Был бы хоть эмулятор с поддержкой одного слоя.
Вид для печати
Hacker VBI, тут вообще-то тема про Метеор. Или пиши как программировать для Метеора, или делай свой топик.
Я заинтересовался программированием для Метеора. Был бы хоть эмулятор с поддержкой одного слоя.
Smalovsky, этой теме 3 года.
и никаких сдвигов кроме флейма годами.
писать не о чём :v2_dizzy_facepalm:
Hacker VBI, надо было активничать, что бы были сдвиги, а не флеймить.
Когда программная модель выбрана, то дело пойдёт быстрее.
Вообще, на нулевом слое стандартный экран. Для него тоже ведь надо свою палитру предусмотреть, иначе стандартные цвета будут диссонировать с более богатыми оттенками цветов слоёв.
Smalovsky, активничай
Тут в управляющих регистрах надо предусмотреть возможность зеркального вывода по горизонтали и вертикали.
Допустим, надо отзеркалить по горизонтали, тогда запись данных в видеокарту надо вести не от левой границы спрайта к правой, а с правой к левой. Если зеркалить по вертикали, то запись во внутреннюю память надо организовать не от верхней границы спрайта к нижней, а от нижней к верхней.
Есть недостатки формата спрайтов - слишком много данных в памяти займут ненужные байты прозрачных пустот в спрайте.
Неплохо бы написать уже примерный список управляющих регистров без привязки к адресам.
битпланы... спрайты... тайлы... я как в далекое прошлое попал
кто-нибудь пробовал для разнообразия посмотреть эволюцию развития 2Д-шных видеочипов игровых систем ? ;)
от тайловых карт и задников, тем более битплановых, во всех их проявлениях начали отказываться еще в ранних 90х, оставили только спрайты, дохрена спрайтов. всем(?) известный Neo-Geo например так сделан.
позже пришли к выводу что и аппаратные спрайты ерунда и нафиг не нужны. потому 2Д-игровые аппараты 2й половины 90х были уже часто с блиттерами.
то есть всё что умеет видеочип - отображать фреймбуфер и копировать куски памяти туда-сюда, с масочкой, и опциональным альфа-блендингом.
такими и было большинство из немногих поздних 2Д-шных игровых систем начала 2000х, например как Cave CV-1000 известная буллетхеллами типа DoDonPachi или DeathSmiles, в которых всё видео состоит лишь из Альтеры-блиттера и пары чипов видеопамяти, относительно шустрых и больших.
а вы тут про какие-то битпланы...
MetalliC, спектрум тебе не денди. Для спектрума уже сформировалась целая культура программирования графики. Спектрумисты хотят доступ к каждому пикселю - для разных меню, редакторов, трёхмерной графики, а этого приставочная графика не может им дать. Приставочная графика - примитив для бегалок-прыгалок.
Ещё есть вопрос стилистики - графика для спектрума должна быть узнаваема. Если на экране будут изображены высокополигональные и многоцветные модели, то это уже не спектрум.
В принципе, можно идти и по пути приставок, как это сделал тслабс, но это игнорирование целой культуры программирования графики спектрума. Да и если посмотреть кто в окружении тслабса, то можно увидеть много людей, которым нравятся приставки. Поэтому спектрумисты так охотно не идут к тслабсу. Настоящие программисты для спектрума уже значительно ушли со спекки на писи, остались только ностальгирующие - застрявшие во времни приставок люди, которые думают что видеоигры - самое полезное применение ЭВМ.
Я вот помню, как в где-то в 93-97 годах, когда появились денди, спектрумисты, которые увлекались программированием даже не воспринимали приставки всерьёз. Основная проблема для них было - спектрум или писи.
"Да и если посмотреть кто в окружении тслабса, то можно увидеть много людей, которым нравятся приставки."
Smalovsky, настолько безбожно врёт, что прямо смешно :)
а покажи свои работы, "настоящий спектрумист"?
Hacker VBI, я обязан что-то показывать? Лучше на хайпе в поиске по тегам набери nes.)) Плюс много интересующихся тайлоспрайтовым двигом - это тоже, считай, приставочники.
-
Я вот подумал, выводить спрайты мы можем на экран, а вот как потом их стирать? Неохото для стирания использовать служебные цвета для вывода, может, предусмотреть какой-то механизм для стирания, например, выделить специальный регистры, в которых будет храниться цвет "ластика" для каждого слоя и управляющий регистр вывод/стирание? Тогда в режиме ластика любая запись в регистр данных приведёт к затиранию данных в установленной области вывода.
Smalovsky, согласен.
тяжело показать свой труд, которого не существует.
а я человека по трудам оцениваю.
Как результат, твоё мнение - это мнение человека, который "во всём разбирается, всё знает", но при этом это "всё" - очень поверхностно.
Smalovsky, вы меня или не поняли, или прочитали предыдущий пост по-диагонали ;)
имхо, TS-conf со своими картами тайлов и спрайтами, типа как в консолях середины-конца 80х, является таким же анахронизмом как и описываемое в этом топике.
в более позднием игровом железе от этого всего отказались в пользу быстрых блиттеров (тут их вроде DMA называют), в виду большей гибкости, простоты, удобства и дешевизны.
Да не надо такой огромной палитры, для 4/8 бит на цвет палитры достаточно 15 битной, а для 5/5/5 вообще палитра не нужна, яркость каждого цвета уже описана, тем более что точнее будет 1/5/5/5, если старший бит 0 то 5/5/5 это яркости RGB, а если старший бит 1 то первые 15 бит это уже палитра, если все 16 бит единицы то это прозрачный.
По сути и палитра то не нужна, 5/5/5 этого более чем достаточно, по 32 яркости на цвет.
- - - Добавлено - - -
Это делается примитивно и просто, в плис забивается регистровый счётчик с вычитанием/сложением.
MetalliC, отчасти с тобой согласен. разница в том, что TS-conf работает всего то с 2012го года.
и есть отличные результаты:
http://analysis.4sceners.de/assets/a...f/image005.jpg
Best Oldschool Demo:
01. Synchronization / Consciousness (ZX Spectrum enhanced)
"Some may speak of a sham, others simply do not care and enjoy a thoroughly great demo. "Synchronization" splits minds, because this wonderful show runs only on a modified Speccy. That's nothing we care about, because effects, graphics and design can only be described as spectacular. Also the magic delivered through effects is accompanied by incredibly good music which rushes your soul from one high point to the next. "
и я - один из двух кодеров этой демы.
А вот метеор - обсуждается до сих пор.
зы: да, блиттером в конфе DMA служит, есть режимы для этого
кому достаточно. а кому нет.Цитата:
Да не надо такой огромной палитры, для 4/8 бит на цвет палитры достаточно 15 битной
палитра при работе с графикой 4/8 бит на точку как раз нужна. т.е. выборка 64 или 256 цветов из какой-то палитры в столько-то цветов (столько-то бит). да и что такое 32 яркости против 256...рваные края на картинке, больше дизиренга, жутко лесенкообразный градиент. ну уж нафиг...Цитата:
По сути и палитра то не нужна, 5/5/5 этого более чем достаточно, по 32 яркости на цвет.
демка, конечно, интересная. но она всё-таки в основном "спрайтовая". пестрят спрайты, тайлы, заливка градиентом и манипуляция с результатом. хотелось бы увидеть что-то аля рефреш. догма и тому подобные демы, без тайлоспрайтов. тунельчики. ротозумы, блобсы всякие, 3д обжекты и тому подобное.Цитата:
01. Synchronization / Consciousness (ZX Spectrum enhanced)
Стирается также - спрайтом.
Принцип построения экрана, для примера возмём Exolon:
1) Выводим или спрайт размером 256x192 с черным цветом (хранить его не надо) или заполняем экран спрайтами 8x8, 16x16 самого заднего фона (как к примеру в Contra с dendy), ну или вообще bmp вывести
2) Выводим корабли
3) Накидываем звёздочки
4) Выводим врагов которые двигаются ЗА стенками И выстрелы
5) Выводим спрайты полов и стенок
6) Выводим врагов которые двигаются ПЕРЕД стенками И выстрелы
7) Выводим спрайты лифтов
8) Выводим космонавта
9) Выводим пушки
10) Выводим статистику
11) Выводим стрелку мыши (если надо)
12) Вычисляем новые координаты всего и вся
13) Начинаем заново.
Всё, никаких планов и прочей дребедени.
Здесь даже стирать ничего не надо, всё само на 1 пункте подготовиться.
Достаточно всего одного универсального VideoDMA и парочку Plot.
Объём видеопамяти при этом ничем не ограничен, в памяти процессора ей вообще отображаться не надо, загрузил спрайты с диска, распаковал, кинул в видеопамять.
CPU это ЦЕНТРАЛЬНЫЙ процессор, с каких пор в задачи процессора стала входит переброска блоков информации? на кой хер это ему нужно? его дело подготовить координаты и загрузить счётчики, дальше ему должно быть насрать как оно там будет перебрасываться, хоть боком хоть с прискоком.
Зачем вообще делать компьютер в котором CPU занимается попиксельным копированием информации с одного места в другое? ЗАЧЕМ????? делать CPU в котором тысячи регистров и программно делать копирование? ЭТО БРЕД!
Это тоже самое что директор завода будет на проходной полы подметать, НАХЕРА? что бы перекинуть спрайты из памяти на экран достаточно с десяток регистров и за 1 такт процессора кусок спрайта уже успеет отобразиться, зачем на CPU писать программу которая вычисляет по таблицам адреса (экономия скорости бугага) переключает банки памяти, считывает байты, записывает байты, корректирует байты, НАААААХРЕЕЕЕНААААА ? Пока CPU с умным видом отобразит ОДИН спрайт, сранная рассыпуха логики уже ДВУХСОТЫЙ спрайт дорисовывать будет.
- - - Добавлено - - -
Тогда проще прикрутить GeForce 210.
1 кадр в сутки z80 успеет вычислить.
не понял, 1 кадр чего? что-то в рефреше под пятногон не надо было никаких "Riva TnT", а для ТС вдруг гфорс потребовался))) смешно)))Цитата:
1 кадр в сутки z80 успеет вычислить.
под бейзконфу, кстати, были демки со всякими 3д (хоть и немного).
Sayman, есть и такое
"пестрят спрайты, тайлы, заливка градиентом и манипуляция с результатом. "- это так кажется.
естественно что юзается всё что только возможно, но дема чисто кодерская.
есть там части и с псевдо-3д
http://bbb.retroscene.org/screens/16...shot000013.png
http://bbb.retroscene.org/screens/16...shot000031.png
Да нормальное демо, и без всяких 16 миллионов нормально смотрится.
- - - Добавлено - - -
Однако есть несколько но, не по этой деме а вообще, при написании кода работы с экраном разрешение вкладывать не фиксированное а плавающее, изначально взятое из видеокарты, естественно видеокарта должна это уметь :)
Тогда если включить разрешение 640x480 например, то это же дема должна отображаться на крайних 256x192 нормально, вот тогда цель будет достигнута.
Nesser, ты хоть знаком с перечисленными мной демками?
ознакомься: рефреш, напалм и т.д. а вот демка с 3д под бейзконфу: the board, the link и т.д.
это тут вообще причём? я где то говорил про FullHD для спектурма? если речь про 24 бита палитру, так это палитра. на экране один фиг только 256 цветов. ты что-то путаешь.Цитата:
дай ссылочку на видео 16 миллионов на точку 1920x1080
да, тут уже поинтереснее, но потом дема сползла к псевдоплазме, которую можно получить манипуляциями с палитрой (хотя исходники вроде пролетали, надо бы глянуть, может там более иначе, чем мне кажется)...Цитата:
есть и такое
Если делать в железе, для какого компьютера подойдет видеокарта Meteor ?
На ZX-Evo не пойдет. Там некоторые сигналы отсутствуют. Нужно также подавать INT с видеокарты.
Для модульного компьютера лучше шина ZST-BUS. Не надо на каждой плате ставить согласующие буферы с Z80. Поэтому плата меньше и разъем надежнее.
Для ZXM-Phoenix и Scorpion можно через тройник-преобразователь.
Много желающих переделывать старые игры для устранения клешинга и писать новые без 3D и аппаратных спрайтов ?
16 бит на цвет так как все слои хранятся по 16 бит на точку без палитр.
Смотрел я демки.
Это ТЫ сказал что ступеньки градаций и всё такое :)
- - - Добавлено - - -
Я бы может и переделал несколько старых, но только с 8/16 бит на точку, аппаратной переброской и желательно бы с плавающим разрешением.
Если движок налажен программно+аппаратно то наваять игру заново не так уж и сложно, неужели сложно R-Type заново сделать? только с установкой и прокачкой модулей космолёта :D
Там кода на 1-2 кБ, а остальное звуки, музыка и графа.
Да кстати - звуки и музыка..................................
А их по сути до сих пор и нету.
TSFM весчь классная, но на самом zx музу то и не сделать :)
----------------
Вопрос музакерам - реально ли генераторами сделать нормальный игровой звук или всё же надо что-то wav`образное ?
Метеор буду делать для Феникса с шиной ZX-BUS. Добавлю развертку Pentagon-128.
Оцени ещё раз все за и против, жалко потраченного времени.
Делать НАДО, но корректируй сразу с учётом пожеланий.
Я всё таки за гибкое изменение параметров а не жёстко зафиксированных схемотехнично.
- - - Добавлено - - -
Аааа кстати, а если игры переделывать то кто рисовать будет? я не художник и не музыкант :D
Видеокарта это классно, но рисовать то кто будет ?
Nesser, Captain Drexx
http://www.youtube.com/watch?v=LnQb8wICMac
длина кодового блока - 10271 байт
это без буферов и уровней, без музык, график и прочей херни
но, естественно, с dup-ами, текстами и переменными :)
- - - Добавлено - - -
zst, ходят слухи что в фениксе ZX-BUSа нету :)
прикольна. игрулина аля товер дефенс. для zx совсем редкость (или уже нет?). а исходнички есть? это же под обычный 128й да?Цитата:
Captain Drexx
хаха))
всё есть :) я писал :)
первый и единственный товер дефенс на спектруме.
и да, 128 онли.
продавался не кронософте в формате кассеты, продано около 20 штук ;)
http://www.youtube.com/watch?v=L_1Ex4bL7yo
Ого, дефендер, не видел если честно :)
Нууу с видеокартой то DUPы не нужны :) даже если кодовый блок+текст+переменные и будет на 16 кБ этого точно хватит, тем более в прямом доступе то 48 кБ :)
Я уж и не знаю что можно запихать в 48 кБ если графика, звуки и музыка находятся в теневых страницах :)
запихнуть можно много чего. например, если игрулина аля Вольф (например, как версия для АТМы), то только для каждого масштаба (64 масштаба) своя отдельная процедура (т.е. 64 процедуры в случае с версией для АТМ которые занимают 14801 байт). ну и остальной код тоже там довольно не малый. И если карта сама не умеет в масштабы, то и 48кб может быть очень и очень впритирочку...Цитата:
уж и не знаю что можно запихать в 48 кБ если графика, звуки и музыка находятся в теневых страницах
Зачем такой шнягой CPU напрягать, да ещё и кучу видов одного и того же спрайта хранить ? :)
Масштабирование это проблема видеокарты, всё равно уже стоит ПЛИС, для справки скажу что все видеокарты изначально разрабатываются на ПЛИС и когда уже всё обкатано тогда уже переводят на штамповку.
Если начали делать так делать надо уже нормально.
Изначально нужна КОНЦЕПЦИЯ, то есть для чего вообще делать то видеокарту, не надо гнаться за суперпупер цветами и разрешениями, надо простое и уникальное решение для СЛАБОГО процессора, без всяких SDK, RISC и прочей дребедени.
Все эти масштабирования примитивно решаются в логике, крутить углы по сути тоже фигня, и портянку с текстурой можно вывести X1,Y1,X2,Y2, не сложно же реализуется.
И да, не вижу ничего зазорного если Z80 сделать на плис в виде 40 ногой панельки, поменять можно в любом zx-spectrum, одно время даже некоторые заводы (на заказ) шлёпали кристаллы плис в любой корпус, так же пихали и в 40 DIP, сейчас не знаю, наверное не выгодно.
Разве это плохо если LDIR будет не 21 такт а 1-2 такта? а в дополнение к ADD и SUB будет MUL и DIV ?
Я не работал с ПЛИС :) но на рассыпухе могу собрать что угодно, надеюсь скоро окончу текущие "проекты" с PICами (надо для заработка) и сяду ПЛИСины курить, не думаю что там всё сложно.
Но здесь же есть уже готовые спецы по ПЛИСинами, скажите, разве нельзя наваять всё это и что бы программно это обслуживалось как можно проще?
тс-конф перехватывает команды CPU, отлично, это правильное направление, в плис напихали и видео и ВСЁ ОСТАЛЬНОЕ.....это НЕПРАВИЛЬНО, видео должно быть ПОЛНОЦЕННЫМ, если надо 24 ноги для цап значит должно быть 24 ноги а не 6.
ВСЁ ОСТАЛЬНОЕ должно быть в ДРУГОЙ плис.
Нууу и так далее, вся система должна быть собрана в одну КУЧУ, а сейчас это кубик рубик который априори в правильное положение НЕ СОБИРАЕТСЯ.
Одной только видеокартой ничего не исправить.
Нужна концепция и пробы пробы пробы.
Nesser, с-конф НЕ перехватывает команды CPU.
в тс-конф - отдельные порты на всё необходимое.
Nesser, вDAC решает заложенную в архитектуре проблему вывода цвета, не более.
Nesser, ты не понял. 64 масштаба не спрайтов, это 64 процедуры. 1 процедура выдаёт тебе 1 масштаб для текстуры/спрайта. нет потребности хранить 64 копии в разных масштабах на 1 текстуру. чтобы честно видяхой это делать, она должна уметь делать сама масштабирование. для спринтера есть конфа с аппаратным масштабированием (хз как её подключать, не разобрался).
команды умеет перехватывать Спринтер, а не ТС. именно так и работает аксель.Цитата:
тс-конф перехватывает команды CPU
ld h,h - это "удвоение байта" (должно было быть, может и есть, не проверял)Цитата:
LD H,H LD L,L
ld l,l - копирование...
-----------------------------
Ээээээээ погодите ка, по поводу метеора.
А как вы собрались буфер вывода делать? Типа сканер выводит изображение на экран и я в это же время там всё перерисовываю и двигаю? а как же временный буфер на 1 кадр?
- - - Добавлено - - -
-----
Ааа теперь понятно, это у меня всё в голове намешалось :) видимо потому что нет нормально оформленной документации и на то и на то.
Да если такой мешок логики уже поставили на плату то естественно все масштабирования должна делать эта логика, иначе какой смысл ставить тысячи микросхем логики в 1 корпусе и продолжать всё делать программно, зачем :)
У нас процессор CISC, значит и всё что навешиваем должно быть сделано по такому же принципу, пусть не быстро но уверенно.
Описание концепции, характеристик, переменных видеокарты собрал в 1 пост.
Мои соображения насчёт новых регистров и блиттера. Ошибки в тексте есть)).
Предлагаю следующие регистры:
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.
- - - Добавлено - - -
Если блиттеру дать команду скопировать область размером 224*256*2=114688 байт - экран в непосредственном режиме данных, то сколько времени будет происходить копирование?