когда это у Спектрума разрешение сделалось 256x224 как у NES? кому оно вообще нужно? для NES есть другой раздел и другие железки.
когда это у Спектрума разрешение сделалось 256x224 как у NES? кому оно вообще нужно? для NES есть другой раздел и другие железки.
Есть такая игра от Дениса Грачёва как Лирус
в общем, я её переделывал под ТС-конфигурацию.
Для фона я использовал блиттер, заполнив ним полностью весь экран графики повторяющимися графическими паттернами. При движении корабля графический слой аппаратно скроллится в нужном направлении, и достигая макс. размера паттерна - сбрасывается в 0 позицию.
Поверх него лежат тайлы карты и обьекты игры - игровое поле. Весь этот блок - с прозрачными областями, под которыми виден "нижележащий" фон с паттернами - это тайловая карта №1, которая аппаратно отображается, я лишь меняю номера тайлов в карте.
над ней, сверху, расположены служебные элементы - радар, счёт, прочее - этим занята тайловая карта №2.
Выглядит всё это так:
К чему я веду. Слои - вещь хорошая и полезная. Но это не значит что "чем больше - тем лучше".
8 штук - супер, но и на троих специализированных можно хорошо отработать.
найти саму игру можно здесь
Продолжу.
MultiDude - два слоя, оба тайловых. на одном - вся игра, на втором - вывод текста
Сaptain Drexx - два слоя. Один - тайлы игровой карты с башнями, поверх неё - спрайты крипов (врагов), взрывы.
служебная инфа - внизу экрана, в собственной служебной области.
Последний раз редактировалось Hacker VBI; 11.08.2016 в 11:17.
Hacker VBI, ты про этот Lirus на ТС-конфе говоришь?
отбой. запустил в эмуле. сильно отличается, но если честно, не понятно, ожидал увидеть супер быстрый вывод спрайтов, типа, фрейм и всё такое. Но что-то нету фреймовости...
- - - Добавлено - - -
и вапще, когда уже 3д ускорители будут на спектруме?!))))
Последний раз редактировалось Sayman; 11.08.2016 в 11:39.
Sayman, про этот
я постарался максимально сохранить существующий геймплей, и сделал обвязку под другое видео.
а то вышла бы совсем другая игра.
фрейм? всё там нормально
Hacker VBI, ну если эмуль не врёт, то я бы сказал, что игра не успевает всё нарисовать во фрейм. т.е. там ясно не 50 фпс, на глаз, я бы сказал, около 20, наверное. хотя может эмуль не корректно что-то делает.
Sayman, основной цикл игры - это 2 фрейма. отсюда и 25фпс.
на 50 играть, для данной игы - сложно.
но это не значит что 50 недостижимо
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Тс-conf идёт в правильном направлении, разрешение надо увеличивать, какие проблемы запихать в плис настройки VGA/SVGA ? Супер-пупер разрешений никто не просит, но 640x480 хотя бы, только с нормальным выводом спрайтов, спрайтовому DMA какая разница какого разрешения экран, он тупо копирует из одной области памяти в другую, только с коррекцией переход x, y.
Это же всё несложно в плис делается, да и насколько я помню слои прекрасно делаются тупо сменой очерёдности вывода спрайтов, но перед многослойным экраном имеется очевидное преимущество - многослойка обязана прочитать все уровни слоёв, то есть сделать 256x192x8=393 216 выборок для 8 слоёв, а для разрешения 640x480 нужно всего лишь 307 200 выборок, по мне так лучше 640x480 с аппаратным перебросом спрайтов чем 256x192 с 8 аппаратными слоями и программным выводом.
Редактор под TSFM даже сделать не можем, тупо текст на экран не помещается, а если я вдруг надумаю корюзлый excel слепить?
Разве такая проблема к плис подключать динамическую память? (я сам кстати с плисинами ещё не работал)
И вообще, вся эта идея как то поплыла, без обид, если и переделывать старые игры по графону, ага а музыку оставим древнюю, и музыку естесно, то надо кардинально изменить подход к лепке, городить огород поверх старой игры это мягко говоря туповато, её в итоге всё равно придётся заново делать.
Взять к примеру Exolon, там за глаза 256 цветов, но должна быть именно аппаратная поддержка.
Нууу к примеру мои мысли вслух.
Делаем редактор для спрайтов, 256/32768 цветов на пиксель, аппаратный SpriteDMA поможет самому редактору комфортно двигать редактируемый экран, сам z80 никогда в жизни с этим не справиться.
Лепим к примеру 512 спрайтов по 16x16 1 байт на цвет, код 255 - прозрачный, итого 131 кБ файл спрайтов.
Память видео 1-8 Мб, грузим файл с спрайтами в память видео.
Включаем нужное разрешение и в адресный регистр заносим с какого места в видеопамяти будет выводится на экран, а в экран по другому адресу будем кидать спрайты.
Заносим в регистры размер спрайтов 16x16, вычитающие регистры с перезагрузкой.
Заносим размер экрана в сумматор перехода по X. (коррекция разрешения, по сути хоть 256x192 хоть 1920x1080, главное что бы цап успел)
-----------------------
Заносим координаты для вывода x,y
Заносим адрес спрайта
Вывести спрайт, пока он выводится, CPU никто не держит.
Повторяем последние 3 пункта
-----------------------
При частоте выборки из памяти 100 МГц, гораздо выгоднее работать с спрайтами 32x32.
Утрированно при 3.5 МГц (а почему нельзя поставить Z84C0020 на 12-24 МГц ?) 70 тысяч тактов в фрейме, используем половину 35 тыс на 512 спрайтов 16x16x256c (их хватает и на задний фон и на 3-4 динамичных слоя), получится что есть 68 тактов на передачу данных о спрайте, аппаратную скорость копирования можно не считать, при хреновом раскладе это 2 тысячи спрайтов во фрейм, весь упор в процессор
Да и максимальный размер спрайта в таком случае получается 4096 на 4096 (при 12 битных счётчиках координат) больше нет никакого смысла делать, а меньше только 8 бит 256x256 буээээ, то есть никто не мешает мне добавить всего лишь 2 счётчика для организации плавающего количества аппаратных слоёв, включаем к примеру 2 слоя, включаем разрешение 640x480, кидаем команду копирования спрайта размером 640x480 по адресу 1 слоя, через 20 тысяч (одна треть фрейма) тактов CPU 3.5 МГц появится красочный задний фон, и там и будет висеть пока его не удалить, если его же кидать при помощи проца то на это уйдёт порядка 8 миллионов тактов, потом кидаем на второй слой иконки и windows готов.
Так же и окно ссссссс текстовым редактором например рисуется, чертишь всё в памяти а потом шлёпаешь куда надо, скорость реакции окна на мышку столько же сколько кадров стоит на вывод, так как даже открытый на полный экран всё равно успевает за фрейм выводится, и CPU при этом никаким боком не нагружается, 100-150 тактов и хай оно там себе перекидывается.
Ну это так, дурные мысли в голову лезут.
----------
Ага, и ещё дурная мысль - 0-ым слоем можно выводить текст, тупо текстовый экран, при 640x480 это 80 на 30/40/60 символов, рисуем допустим музыкальный редактор для TSFM (по сути это готовый bmp/сжатый на весь экран), а все нотки через текстовый слой, бред конечно, но у нас же плис?
Последний раз редактировалось Nesser; 12.08.2016 в 01:37.
Как отображать 8 слоёв.
Можно для каждого слоя, пусть 16 бит/пиксель, хранить альфа канал: 1 бит/пиксель = 16 бит/(16 пикселей - горизонтальный блок)
Вот эти горизонтальные блоки, кэшируемо, вычитывать из памяти для всех 8-ми слоёв.
Потом логическая функция скажет нам, какой наименьший слой непрозрачен. Для каждого пикселя читаем 16 бит цвета только этого слоя.
Итого в среднем 24 бит на пиксель.
24bpp это крута. ну давайте сразу 3д, шейдеры, "dx12"))) щутка...Сообщение от Reobne
а вот если серьёзно - уже было предложено хорошее решение - на борту видяхи сколько то мегабайт видеопамяти, как на современных. туда скинули "текстурки", скинули "шейдеры" (типа дисплей лист), а видяха по ним работает. между делом, ваши конкуренты в лице тслаба уже контроллер ft8xx прикрутили к эве (мегатупо правда). это как бы намёк что уже давно есть готовые решения в виде gpu или подобных. нужно только подобрать нужный и накидать это в виде подключаемого девайса.
Это уже проходили
Экономия мощности относительная, больше 2-3 слоёв уже нет никакого графического прироста, и в 1 слой прекрасно делается и задний фон и все спрайты, игра всё равно динамически обновляет экран.
А отдельный битовый экран и отдельно пиксельный это в старой Амиге используется, на те года это был единственный выход из положения, частоты то были 5-30 МГц, но в 2016 году копеечная память работает на частотах 100-3000 МГц и за 1 такт выдаёт сразу 64 байта данных.
Во много раз проще тупо швыряться спрайтами в экран, тем более никто не запрещает использовать логику коллизии спрайтов, задне-фоновые спрайты из низа списка тупо не появятся если выше них по списку есть более крупный спрайт на ближнем фоне, один раз делается логический автомат по такому отбору а потом в качестве апгрейда только увеличиваем частоту и размер списка переходом на более мощную плисину, хотя и сразу можно нормально сделать, многослойность давно уже делается тракторным способом на обычном однослойном экране, то ли один экран очистить то ли восемь, тем более один экран и очищать то не надо, задний фон сам всё очистит, в конце вывода остаётся только смачно кинуть 16x16 в виде стрелки мышки, на следующем фрейме задний фон всё равно всё сотрёт.
Для твоей версии требуется поочередный перебор, берём байт, каждый бит это маска соответствующего слоя, используем много много плисовой логики и смотрим при помощи параллельного однотактового сдвигателя слева направо первую 1, на выходе имеем номер слоя который самый ближний к поверхности, дальше вычисляем адрес этого слоя с учётом текущих координат, считываем пиксель, заносим его в регистр палитры, считываем цвет из памяти палитры, заносим цвет в регистр ацп, повторяем цикл.
За сколько тактов плиса сможешь сделать каждый цикл?
Нуу это всё классно....а графику то кто рисовать будет?
Значит надо дополнительно в циклы перебора ещё и вносить вычисление смещения 0-15 адреса координат x,y для смещения слоя перед отрисовкой движения, значит реальный размер экрана должен быть на 16 пикселей больше с каждой стороны, экран 256x192 в памяти должен быть как 288x208, в 8-битные регистры уже не лезет, надо 9 бит, ну да фиг с ними, и это надо для 8 слоёв, не кратная организация памяти грозит серьёзными техническими проблемами
Нууу и так далее.
п.с. это всего лишь моё неадекватное понимание
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
