Просмотр полной версии : Зачем всё делать плоским? (Опять о спрайтах)
Vladimir Kladov
22.04.2008, 20:57
Я всё-таки не пониамю (вот так пусть и остаётся - не пониамю), почему все придумывая новые концепции видеоотображения оставляют плоский экран? Ну, отбросив нехватку памяти (2 М - уже как бы и не проблема подключить), остаётся ещё ведь и скорость. Даже на турбе заполнить весь экран 16с за кадр не получается, минимум за 2.
Давайте подумаем что можно было бы всё-таки сделать, если отбросить пробему совместимости (нет такой проблемы, потому что переделывать всё равно придётся оченно глЫбоко, и это практически то же, что написать заново - тогда о чём говорить). И отбросить узость и плокость мышления.
Вот такой вариант. Читаем внимательно. Картинка состоЯИт из 2х планов - переднего и заднего. Задний - это прежний спековский экран, с его клэшингом и атрибутом на знакоместо. Только 2 маленьких усовершенствования: 1) палитра берётся из таблицы палитр, и для каждой из 192 строк может быть выбрана своя собственая таблица палитр. Флэшем можно спокойно пожертвовать, и превратить в отдельный бит "яркости" для заднего плана. 2) Всю эту картинку можно скролльнуть влево-вправо и вверх-вниз, оставив её там, где она есть, просто указав в регистре порта пиксель (не байт из 8 пикселей, а именно пиксель), с которого начинается экран. И если кто-то думКает, что это пригодится только для создания крутых эффектовОВ в дЭмах, то это - зря. Такой режим, когда каждая плоскость независимо аппаратно скроллится куда угодно, чрезвычайно интересен для гейм-мэйкинга.
А теперь самое интересное - это спрайты. Кто сказал, что они обязаны быть квадратными (или прямоугольными?). Нет, не так. КТО СКАЗАЛ, ЧТО ОНИ ОБЯЗАНЫ БЫТЬ КВАДРАТНЫМИ? Вот, так будет видно. Спрайтом у нас будет последовательность 4-битных пикселей, по 2 на байт. Формат атрибутов может быть такой же, цвет берётся из палитры по номеру, для каждого участка спрайта палитра задаётся отдельно (т.е. если в совокупности спрайт - это несколько цветных линий, то каждая линия может быть раскрашена своей палитрой, из того же общего набора палитр по 16 цветов на палитру). Спрайты размещаются в памяти где угодно. Если у нас есть круглый колобок, то мы можем поместить все его линии впритык друг к другу, и это займёт места меньше, чем квадрат (для которого ещё нужен и "прозрачный" цвет, или маска прозрачности). Задавать "видеопроцессору" что рисовать, мы будем таблицей разметки. Вид таблицы очень простой: несколько полей на каждый участок, который есть линия из нужного спрайта, плюс длина прозрачного участка, в котором спрайтов нет. Проблемы наложения спрайтов друг на друга тоже нет, т.к. в таблице разметки задаётся, сколько конкретно пикселей брать, и с какого (чётного или нечётного пикселя в байте) начинать брать. Сколько спрайтов рисовать одновремено (на экране, в строке, ...), решает программер. Ограничения физические есть, но они компенсируются и ограничены размером внутреннего буфера видеопроцессора. Рисование экрана (точнее перерисовка) сводится к построению новой таблицы разметки, что наверняка будет быстрее, чем все пиксели самому на экран перебрасывать любыми изощрёнными приёмами. Чтобы, пока строится новая таблица, можно было отображать прежнюю, да или просто быстро переключаться между уже несколькими заранее построенными - не нужно никакое ограничение на количество "экранов", то бишь этих самых таблиц разметки. Т.е. где-то надо указать, где начинается таблица, и всё переключение экранов на этом и заканчивается.
Ну, и напоследок, как вариант, формат элемента таблицы (набросок):
- 2 байта - длина в пикселях пустого пространства, то бишь заднего плана (младшие 10 бит, например) + номер палитры в таблице палитр (старшие 6 бит) для описанного далее кусочка спрайта,
- 2 байта адрес в памяти, где лежит первый пиксель очередного спрайта в памяти,
- 1 байт - длина пиксельной строки 0..63, старший бит устанавливается, если начинать отображать строку с нечётного пикселя в этом "спрайте", бит 6 - если пиксели брать в обратном порядке ("аппаратный" горизонтальный флиппинг).
Итого - 5 байт на фрагмент спрайта + пустого пространства перед ним.
Для того, чтобы спрайты можно было разместить в памяти в настоящий момент не впечатаных страницах, девайсу в отдельной четвёрке регистров можно было бы задавать свой собственый набор страниц для адресов, примерно как в самом 128 спеке сделано, но для каждой страницы 16К - отдельно. Соответственно, одновременно получаем доступ к 64К для спрайтов, одновременно присутствующих на экране - более чем предостаточно.
Ну и как? Почему нельзя было такую элементарщину реализовать ещё в 95 году? Плоское мышление и гигантизм, стремление за какой-то гипотетической совместимостью.
(Да, я понимаю, берём V9990 или сколько там девяток, сопрягаем, и всё работает, коли руки не кривы. Осталось найти достаточное количество дешёвых V9990, выполнить дешёвую плату сопряжения, и дальше пытаться что-то под неё запрограммировать. Сразу же обнаружится, что программить некому, и нечего, и это опять монстростроение (в том смысле, что девайс к спеку оказывается дороже его самого). Вообще, мне интересно, что железячный народ скажет в плане реализуемости описанного мною выше сюжета. (Ну на своём новом эмуляторе, я бы взялся его проэмулировать, жаль, паяльник мне не друг - в самом широком смысле, в том числе в плане проектирования ПЛМ :v2_blush:)
Лучше это
http://www.zx.pk.ru/showthread.php?t=1399&highlight=%F0%E0%F1%F8%E8%F0%E5%ED%E8%E5+%E2%E8%E4 %E5%EE%F0%E5%E6%E8%EC%E0&page=25
cyrax inc
22.04.2008, 23:30
как-то не проглядываются особые преимущества описанной идеи. сложности (по сравнению со спрайтовой структурой) по растасовке объектов по экрану перекладываются на плечи программиста, а насчет экономии памяти за счет битов прозрачности - тут бабушка надвое сказала: вполне реальны ситуации, когда затраты будут бОльшими.
да, для чего это "Зачем всё делать плоским?", "плоский экран"? как ни крути-верти, а оно как было плоским, так и останется, независимо от структуры. и как решается в данном случае с "кем и что программировать"?
Black_Cat
23.04.2008, 00:16
Почему нельзя было такую элементарщину реализовать ещё в 95 году?потому что под эту "элементарщину" нужен отдельный программируемый видеопроцессор (читай - либо микрокомпьютер, либо что-то а-ля v9990), а не простой конечный автомат а-ля сканер, который можно реализовать в ПЛИС или даже на логике. В случае создания этого чуда на FPGA - это будет не дешевле разработки с нуля чего-то типа v9990, а в случае эмуляции с помощью стандартного микропроцессора - это потребует высоких тактовых частот, со всеми вытекающими из этого технологическими трудностями выливающимися в дикую цену платы при мелкосерийном производстве (например четырёхслойка 140х105 мм обходится в ~100$/шт.) А в 95м это обходилось бы в десятки раз дороже, для примера можно взять Спринтер и оценить стоимость разработки конструкции на FPGA -> ~10000$, а про платы способные работать на частотах 200МГц и говорить тогда не приходилось, не говоря уже об доступности таких процессоров. Щас конечно всё дико подешевело, но тем не менее это будет не так уж и дёшево, а учитывая что это фактически будет новый компьютер, не имеющий ничего общего со Спеком, то к тому-же ещё и непонятно кому это нужно.
Вот учитывая эти соображения и приходится идти на компромис между сложностью конструкции, технологичнескими, ценовыми и маркетинговыми ограничениями. В этом плане есть достаточно сбалансированная по всем критериям конструкция Летаргика, и это предел сегодняшних возможностей растровой графики для Спектрума.
Lethargeek
23.04.2008, 15:25
если отбросить пробему совместимости (нет такой проблемы, потому что переделывать всё равно придётся оченно глЫбоко, и это практически то же, что написать заново - тогда о чём говорить). И отбросить узость и плокость мышления.
Ну и как? Почему нельзя было такую элементарщину реализовать ещё в 95 году? Плоское мышление и гигантизм, стремление за какой-то гипотетической совместимостью.
Как раз в 95 "о совместимости" походу никто не задумывался. Все ваяли "рабочие коммерческие" режимы, кое-кто дендюк спрайтовый прикручивал. И где тонны "глЫбоких переделок" под эти новации?
Такой режим, когда каждая плоскость независимо аппаратно скроллится куда угодно, чрезвычайно интересен для гейм-мэйкинга.
Узость мЫшления. Для гейм-мейкинга со времен NeoGeo "чрезвычайно интересно аппаратно скроллировать" независимые объекты, а не плоскости целиком.
КТО СКАЗАЛ, ЧТО ОНИ ОБЯЗАНЫ БЫТЬ КВАДРАТНЫМИ?
Узость мЫшления. Кто сказал, что они обязаны БЫТЬ?
(т.е. если в совокупности спрайт - это несколько цветных линий, то каждая линия может быть раскрашена своей палитрой, из того же общего набора палитр по 16 цветов на палитру).
Что с точки зрения железа (в сочетании с требованием "неквадратности") означает не "N линий одного спрайта", а "N фактически разных спрайтов". А это уже две БОЛЬШИЕ разницы.
Если у нас есть круглый колобок, то мы можем поместить все его линии впритык друг к другу, и это займёт места меньше, чем квадрат (для которого ещё нужен и "прозрачный" цвет, или маска прозрачности).
Не стоит так извращаться из-за одного только частного случая. Идеальный общий вариант - упакованная графика на входе и выходе, и узел-перепаковщик между ними (можно обойтись и попроще - упаковка хотя бы только источника), что позволит значительно разгрузить самый узкий канал - шину данных видеопамяти. Да и графики больше влезет.
Рисование экрана (точнее перерисовка) сводится к построению новой таблицы разметки, что наверняка будет быстрее, чем все пиксели самому на экран перебрасывать любыми изощрёнными приёмами.
Самому-то зачем? (Кстати зачем вообще общая память для графики и Z80?) Да и список заданий на тупое копирование объектов ничем (кроме большей простоты для програмера) от упомянутой таблицы не отличается.
и это предел сегодняшних возможностей растровой графики для Спектрума.
Ну вообще-то совсем уже не "предел", поскольку ПЛИСы все толстеют и дешевеют ;) (причем слабые модели снимаются с производства). А про идеальный двухмерный движок я выше писал. Совместимость в такую схему можно по-разному прикрутить, и цена ее поддержки ничтожная по сравнению с основным движком.
Vladimir Kladov
23.04.2008, 15:27
Под плоским я понимаю вот что. Всё изображение представляет собой неподвижную матрицу Width x Height (256х192, 384х200, ...), и заполнять его надо программно, сдвигать программно, и всё делать в одной плоскости.
Я понял, что перекладывание всех проблем с размещением спрайтов на плечи программера не приветствуется (но мне кажется, что режим 16c в этом плане вряд ли столь уж прост, тем более что и памяти при этом приходится заполнять в 4 раза больше).
Я немного ещё подумал, и мне пришло в голову, что всё можно упростить кардинально. Итак, 4 байта на описатель кусочка:
XOFF - 1 байт смещения спрайтной линии от левого края экрана (0..255);
PAL+LEN - палитра (3 бита, 0..7) + длина линии (5 бит, 0..31), LEN=0 означает "спрайта нет";
EVEN+FLIP+Addr_hi - начинать со старшего (EVEN=1) или младшего (EVEN=0) пикселя в байте спрайта по адресу Addr, FLIP=1, если пиксели отображать справа налево, Addr_hi - 6 старших бит адреса спрайта.
Addr_lo - 8 младших бит адреса спрайта.
Теперь каждой из 192 линий (из 256 пикселей) соответствует 8 таких 4-байтных описателей, т.е. 32 байта. Размещать спрайты намного проще: достаточно поместить заранее заготовленные адреса/длины/чётности (и поправить FLIP, если надо) - в нужное (по вертикали) место в одной из 8 колонок, указав правильное смещение от левого края экрана. Чем дальше (или ближе, неважно) колонка от начала описателя строки, тем более приоритетен соответствующий (один из восьми) слой, и такой спрайт перекрывает все прочие, если они пересеклись. Такая схема требует быстрого приоритетного выбора пикселя из 8 возможных, и это, наверное, её недостаток. Но, наверное, разруливается как-то. Зато у нас 8 независимых слоёв, не считая заднего плана, 16 независимвых цветов на точку, причём для каждой линии спрайта можно выбрать одну из 8 различных цветовых палитр по 16 цветов. (Кстати, палитру первого слоя, т.е. самой первой колонки можно заодно задействовать и для заднего плана, если больше негде хранить).
В итоге на экране вообще без проблем размещаются 8 спрайтов в ширину, а если какие-то могут двигаться только в одном горизонтальном слое, то нет проблем выполнить совмещение по вертикали, и суммарное число спрайтов легко увеличивается.
Мне кажется, "автомат" здесь вполне можно построить, причём не очень сложный, и для него не нужна какая-то сверх-навороченная альтера, а достаточно простой и не сверхмощной, хоть я и не специалист по фпга. Смысл всего этого такой: памяти требуется всего в 2 раза больше, чем для обычного спековского режима, скорость заполнения получается наверняка больше, чем в случае прямого рисования в экран. А качество графики - совсем другое, чем мы привыкши видеть на спектруме.
Алгоритм должен быть примерно такой (предполагаем, что проблемы считывания таблицы и самих байтов спрайтов как-то решаются, если за раз приходится считывать не более 2 байт из двух спрайтов). На строке -1 считываются данные таблицы для строки 0, на 0й - для строки 1 и т.д. Без буфера тут никак. Дальше, начиная с 0-го пикселя строки, на каждом из 256 пикселей выбирается, что будет рисоваться в качестве пикселя: пиксель первого спрайта, попадающего на этот пиксель экрана, или, если ничего нет, то очередной пиксель заднего плана. Как только найден пиксель спрайта, происходит выборка соответствующего байта (можно сэкономить на обращениях к ОЗУ, и закэшировать байт с парой пикселей, если это принципиально). По окончании каждого пикселя все ненулевые счётчики длины спрайтов во всех 8 описателях уменьшаются, чётность инвертируется, если 0->1, адрес не меняется (при FLIP=0), если 1->0, адрес продвигается вперёд. И так 256 раз.
Про адрес: он стал 14-битным, и получается, что использовать спрайты придётся только из одного непрерывного банка, что может быть не очень удобно, если они все не вмещаются в 16К. Имеет смысл всё-таки разбить адресное пространство на 2 банка по 8192 байта, и младшие адреса 0000-1FFF будут обращаться к одному банку ОЗУ, а старшие - к другому. Порт мог бы иметь вид:
aAAAbBBB, где мленькая буква соответствует биту, который управляет, в какой половине банка идут обращения, младшим или старшим 8К из 16, а большие буквы - задают номер банка ОЗУ, одного из 8.
Про спрайт: к сожалению, ширина линейки спрайта не может быть больше 31 пикселя. Но спрайты пошире легко строятся состыковкой 2х спрайтов.
Если схема слишком сложна для одновременной работы с 8 источниками, число можно сократить до 7 или 6 (хотя это плохо, конечно). Зато программировать такую спрайт-систему очень просто, а качество графики наверняка превысит ямаховское. (И если спрайтов всё-таки не хватает, то ведь и на заднем полане всё ещё можно что-нибудь подрисовать, тоже).
Добавлено через 5 минут
Я прекрасно понимаю, что это малореально было ТОГДА. Хотя бы потому, что своих игрушек в те времена у нас практически (и теоретически) не было (да и сейчас по пальцам). Демки были, а игрушек - не было. Я просто пытаюсь понять, насколько такой спрайт-режим реален СЕЙЧАС, и что конкретно для этого требуется.
Black_Cat
23.04.2008, 16:15
Я просто пытаюсь понять, насколько такой спрайт-режим реален СЕЙЧАС, и что конкретно для этого требуется.Реально это было и тогда - вопрос в деньгах..
Имхо мне видится другая постановка вопроса - делать эволюционно совместимые режимы, или совсем другие, ничего общего с оригиналом не имеющее.
В первом случае необходимо чёткое понимание идеологии заложенной в конкретную конструкцию, которую предстоит развивать. Без этого это будет не развитие, а замена одной конструкции на другую.
Во втором случае собсно нет никаких ограничителей в виде изначально заданной идеологии, и можно делать всё что вздумается изобретая новую идеологию, но это уже будет идеология другой конструкции.. т.е. - не Спектрум! А если изобретать сегодня что-то новое, то возможности тут безграничны и нет никакой необходимости ограничиваться какими-то убогими спрайтовыми движками, сейчас 2d ускорители встраиваются прямо в TFT матрицы, да и 3d реально доступны. А чтоб изваять 3d компьютер, достаточно взять серийно выпускаемую видеокарту и заставить её процессор работать в несколько нетрадиционном режиме - и практически весь компьютер готов :) .
Vladimir Kladov
23.04.2008, 19:17
По моему спектрум - это не просто жёстко зафиксированные параметры архитекутру (проц, память, страничная организация, видеоформирователь, звуковые прибамбасы), а идеология "сделай дешевле 100 баксов", чтобы просто задаваить массововстью. Мне понятно, что технически на тот момент одновременный доступ к памяти из процессора и видеосистемы представлял трудность. Но чуть позже, когда уже появился режим 16с, я так полагаю, проблема была практически разрешима. Вариант, который я описываю, мне кажется реализуем даже на рассыпухе, не говоря уже о ПЛМ (+отдельная память для буфера, например). Да хотя бы взять самую первую часть переделки: аппаратный скроллинг. Смотрите сами: гораздо быстрее удалить с экрана объекты, выполнить аппаратный сдвиг, и перерисовать объекты на новом месте (аппаратный сдвиг можно делать в любой момент между этими действиями), чем перерисовывать весь экран. И никакого клэшинга по крайней мере для заднего плана, потому что картинка сдвигается вся и сразу. Почему не реализовано? Какая такая совместимость? Чем это не спектрум, если к стоимости ничего не добавляется, кроме нескольких перепаек, или даже небольшой доп. платки? Если рассуждать так спектрум, не спектрум - то и добавление TR-DOS и мы получаем из спектрума - не спектрум. Вот с магнитофоном - это спектрум, а с диском - нет, это амстрад или текноложи рисёч, но не спектрум.
И никакого клэшинга по крайней мере для заднего плана, потому что картинка сдвигается вся и сразу. Почему не реализовано?
Что то тут не то,
если имеется ввиду сдвиг аппаратный в смысле сдиг картинки на экране, то встает вопрос с распределением памяти (нада делать что то в духе 512х256), но клэшинг останеться так как он сдигается вместе с картинкой, и если рисовать по тому же адресу то соответсвенно и местро рисования тож сдвинется
если имеется ввиду в пиксельной памяти эмулить экран спека то это во первых проблемы менять цвет атрибутов, во вторых попиксельный сдвиг будет уже гораздо чувствительней
Как раз в 95 "о совместимости" походу никто не задумывался. Все ваяли "рабочие коммерческие" режимы, кое-кто дендюк спрайтовый прикручивал. И где тонны "глЫбоких переделок" под эти новации?
По этому поводу вот какие мысли: Ну допустим возникла бы у кого-то потребность перевести тот же Flying Shark под этот NES видеоадаптер в каком-то виде пускай не 1:1 а скажем со своим редактором спрайтов и backgroud-a. Что бы он делал? А просто нашел бы где там лежит графика и где процедура обновляющая экран и рисующая на нем все спрайты после каждого INT-a, потом графику конвертнул бы в NES формат а процедуру вывода background-a и спрайтов переписал бы для NES-a. Скажем так если бы этим занялся бы гуру типа AloneCoder-a то закончил бы за день. Какие бы возникли проблемы? - никаких так как NES выводит background и спрайты из своей паралельной памяти а Speccy бы просто освободился от кучи кода (ломать не строить).
В чем же была причина поражения - я думаю в железе...
1. Тяжело скрестить 2 экрана, один в виде RGBI SYNC а другой в PAL, да еще так чтоб схема к любому спекки подошла; (Эта проблема есть и сейчас и решена она наверное НЕ БУДЕТ так как сложная и никому не интересная).
2. Возможно первая версия подключения NES-a имела ряд проблем например мало памяти и низкая скорость обмена с ZX-ом кроме того на практике это выглядело как спекки с TRDOS на макетных платах или как с ISA модемом - куча МГТФ-а.
"Коммерческие" режимы? - они свое получили: CPM, supercalc, turbo pascal... что называется по стопам robotron 1715. Игры и спрайты и сам ZX-SPECTRUM к этому всему отношения не имеет по-моему никакого.
Ну вообще-то совсем уже не "предел", поскольку ПЛИСы все толстеют и дешевеют ;) (причем слабые модели снимаются с производства). А про идеальный двухмерный движок я выше писал. Совместимость в такую схему можно по-разному прикрутить, и цена ее поддержки ничтожная по сравнению с основным движком.
А на что максимум мы можем реально рассчитывать в ближайшие 5 лет с таким подходом к разработке будущего ZX видеопроцессора? S3Trio64V+? Или V9990? А какая цена его будет $100? $150? При том что цена на готовый аппарат NES или SegaMD уже давно сравнялась и составляет менее $20. А может теперь удастся сделать аля Voodoo2 плату с видеомикшером способную смешать качественно экран спекки с готовым PAL изображением?
Vladimir Kladov
23.04.2008, 21:07
имеется ввиду сдвиг аппаратный
Я имею в виду то, что написал в самом начале. Какая разница уле (или рассыпухе или ПЛМ-ке, которая её замещает), с какого пикселя начинать отображение? Почти - ни какой. Аппаратный сдвиг - это мы как бы указываем на сколько пикселей сдвигается верхний левый угол картинки спека (вместе с тарибутами!) вправо и вниз. Отображение зацикливается, и соответственно если сдвинули картинку вправо на 1 пиксель, то последний пиксель отобразится в левом верхнему углу. По-моему, проще не бывает. Но даже это никто не пытался сделать.
Потому что перепахать дофига
Сырки анрыла открыты, почем бы туда режим не добавить? Зачем сразу железо пилить...
А на что максимум мы можем реально рассчитывать в ближайшие 5 лет с таким подходом к разработке будущего ZX видеопроцессора?
Если syd сделает speccy2008 (ценой до 100$), это и будет современный
спек, с возможностью написать на hdl, нормальный 2Д видео-процессор (в
fpga).
Black_Cat
23.04.2008, 23:06
а идеология "сделай дешевле 100 баксов", чтобы просто задаваить массововстью"Абы что, лишь-бы дешевле и забористей" - это не идеология Спектрума, эт больше смахивает на идеологию алкоголиков пьющих спиртосодержащие стеклоочистители :( К сожалению ты не аппаратчик и не понимаешь что такое красивая конструкция, но даже среди аппаратчиков, понимающих это, не многие понимают суть идеологии конкретно Спектрума, потому как чтоб её понимать, необходимо сначала взять классический 48 Спек и длительное время обдумывать как его упростить не в ущерб функциональности. И когда после мучительных поисков наконец станет ясно, что ничего из него выкинуть нельзя - наступит понимание абсолютной идеальности конструктивных решений - ВОТ ЭТО И ЕСТЬ ИДЕОЛОГИЯ АППАРАТНОГО КОНСТРУКТИВА СПЕКТРУМА, ЗАЛОЖЕННАЯ ГЕНИЕМ АЛЬТВАССЕРА!!! Все аппаратные расширения этого компьютера должны в первую очередь соответствовать этой идеологии! Но кроме идеологии аппаратного конструктива, являющегося формулой скелета конструкции, есть ещё идеология развития - роста этого скелета! Эта идеология определяет вектор направления эволюционного изменения конструкции, и определяется требованиями занимаемой устройством потребительской ниши, и глобальными тенденциями развития информационной техники. К сожалению редко какому разработчику доступна такая глубина понимания идеологии устройства, т.к. она требует широты взглядов на уровне генерального конструктора, а отнюдь не разработчика оконечного узла. Отсюда собственно и берёт начало монсторостроительство - это попытки какого-нить разработчика уровня оконечного узла (возможно вполне грамотного разработчика для своего уровня) "улучшить глобально" всю конструкцию, при этом как правило ничтоже сумняще даже не подозревает о существовании такого уровня абстракции как "идеология", не говоря уже о понимании существования таких более глубоких уровней абстракции как идеология аппаратного конструктива и идеология развития конструкции!! Вот именно этим и объясняются попытки прикрутить то Денди, то v9990, то ещё какую лабуду, объявляя это очередной панацеей и "спасением" Спектрума.. За всю историю отечественного Спектрумостроения пожалуй только один разработчик наиболее досконально и комплексно понимал как изначальную идеологию Спектрума, так и идеологию его развития, это - Nemo! Поэтому его разработки и сейчас являются образцом конструкторских решений, так-же как и разработки самого Альтвассера!
И тут Остапа понесло... :)
Lethargeek
24.04.2008, 00:42
А на что максимум мы можем реально рассчитывать в ближайшие 5 лет с таким подходом к разработке будущего ZX видеопроцессора? S3Trio64V+? Или V9990? А какая цена его будет $100? $150?
Я там про цену в ячейках, а не в баксах :)
При том что цена на готовый аппарат NES или SegaMD уже давно сравнялась и составляет менее $20.
Уровень графики SegaMD (тем более NES) и даже SNES - уже неинтересно. На современных отнюдь не самых навороченных ПЛИСах и статике сейчас лехко забабахать что-нить покруче.
А может теперь удастся сделать аля Voodoo2 плату с видеомикшером способную смешать качественно экран спекки с готовым PAL изображением?
А оно надо? В смысле - кто реально будет юзать всякие микшеры и зачем?
Я там про цену в ячейках, а не в баксах :)
я понял, я цену от себя писал в $$$ чтоб показать что реально доступно сейчас нам.
Уровень графики SegaMD (тем более NES) и даже SNES - уже неинтересно. На современных отнюдь не самых навороченных ПЛИСах и статике сейчас лехко забабахать что-нить покруче.
ну ну... и что это будет "по круче" ? Давай на чистоту с чем мы это сможем сравнить? PS1? Dream? PS2? PS3? при том что цена будет сходу как у Altera DE1.
А оно надо? В смысле - кто реально будет юзать всякие микшеры и зачем?
Если сделать хорошо то народ будет пользовать - задача только сложная, сделать "дырки" дырки в экране спекки чтоб через них видно было куски SegaMD screen.
Lethargeek
24.04.2008, 16:19
Давай на чистоту с чем мы это сможем сравнить? PS1? Dream? PS2? PS3?
Сравнивать с соньками итп просто бессмысленно - хотя бы потому что никто никогда не будет на игрушечном Спеке массово писать софт, в полной мере юзающий аналогичные возможности. Сравни хотя бы с упомянутыми мной 16-битками.
Вот например стандартное окно на SNES или Сеге 256x224, возьмем для определенности такое же (хотя щас полезней сделать например дюжину независимых аппаратных окошек любого размера). В отличие от спрайтайловых движков - простой растровый режим с глубиной цвета 16 бит на точку (вместо жалких палитровых 64 сеговских и 256 снесовских с оговорками). С внешней видеопамятью на стандартной 15ns статике можно полностью прокачать от 3-6 (в зависимости от способа компрессии графики) таких экранов за один 60Hz кадр. Реально это больше, чем 3-6 независимых плоскостей или соотв-е по площади кол-во спрайтов, поскольку неизбежно будут пустоты (и перекрытия, которые тоже можно автоматически пропускать). Выходит даже лучше NeoGeo по качеству (хотя тут уже вряд ли сильно по скорости). А еще из все того же 2D-движка в качестве почти бесплатных бонусов можно выжать всякие вкусности типа обсчета прозрачности, закраски гуро для плоских фигур, элементов mpeg итд.
Если сделать хорошо то народ будет пользовать - задача только сложная, сделать "дырки" дырки в экране спекки чтоб через них видно было куски SegaMD screen.
Это не ответ на вопрос "зачем?" :)
Вот представь, что спековская графика - это карандаш, а навороченная - фломастер. Так вот вместо того, чтобы рисовать два отдельных рисунка (один - карандашный, другой - фломастерный), а потом кромсать один из них ножницами и накладывать на другой, удобней и проще сразу рисовать и карандашом, и фломастером на одном и том же общем листе бумаги? Вот собс-но что я понимаю под "совместимостью".
Vladimir Kladov
24.04.2008, 16:41
ничего из него выкинуть нельзяда запросто: мф вообще не нужен, если нужную игруху вставлять прямо в ПЗУ, и такие ПЗУ есть, картриджи. И без звука (даже МИК) вполне можно обойтиться. Глухим, кстати, он точно не нужен.
Если улучшать, то спрайтами. Если спрайтами, то никак НЕ V9990 - в цельную фпгашку оно не поместится (я даже не буду пытаться сэмулировать эту V9990 в своём эмуле - слишком сложно, а вот то что я описал - запросто).
а вот то что я описал - запросто
Только ниодин вменемый настроко изрекошетить спектрум не решится что бы поиметь эту фичу
кстати в Турбо 2+ нечто подобное есть
да запросто: мф вообще не нужен, если нужную игруху вставлять прямо в ПЗУ, и такие ПЗУ есть, картриджи. И без звука (даже МИК) вполне можно обойтиться. Глухим, кстати, он точно не нужен.
Ну и как отрезать эти 2 бита из порта #fe? Или вместе с бордюром и клавиатурой убрать? Может тогда ULA сразу отрезать и оставить токо Z80 и ROM? К стати 32к быстрой памяти потом уже добавили так что отрезать быструю память не предлагать.
Добавлено через 30 минут
Это не ответ на вопрос "зачем?" :) ... Вот представь, что спековская графика - это карандаш, а навороченная - фломастер. Так вот вместо того, чтобы рисовать два отдельных рисунка (один - карандашный, другой - фломастерный), а потом кромсать один из них ножницами и накладывать на другой, удобней и проще сразу рисовать и карандашом, и фломастером на одном и том же общем листе бумаги? Вот собс-но что я понимаю под "совместимостью".
Зачем - чтоб рисовать не токо "карандашем"(zx) ценой в $0 ... $100 но и делать апликации "ножницами"(genlock) за $30 от "фломастерных" (segamd) рисунков за $20. Итого: все 10000 игрушек спекки можно "обклеить цветной апликацией" и заставить "звучать" по другому за прибамбас ценой в $50 при этом не выбрасывая свой родной Leningrad1 или Pentagon.
А в то что рисовать можно сразу "фломастерами" дешевле чем на Altera DE1 я не верю, к тому же агрегат этот не потерпит рядом старенького ZX-a который прийдется продать "за долги". :)
Black_Cat
24.04.2008, 21:23
мф вообще не нужен, если нужную игруху вставлять прямо в ПЗУ, и такие ПЗУ есть, картриджи. И без звука (даже МИК) вполне можно обойтиться:) эт не научный подход :) Если продолжить твою логическую цепочку - то и без Спектрума можно обойтись :)
Если улучшать, то спрайтамихозяин-барин! хотя с т.з. идеологии Спектрума то, что ты предллагаешь и бесперспективно..
Vladimir Kladov
24.04.2008, 21:54
то, что ты предллагаешь бесперспективно..А я и не спорю. И даже знаю почему. Посчитайте количество русских игрушек. Складывается впечатление, что наши спектрумисты - почти чистые потребители. Или исключительно радиолюбители. Т.е. спаять что-нить могут, а вот запрограммировать то что спаяли - лень. (Какой-то я злой сегодня. Наверное, потому что 256 режим не заводится, зараза).
Black_Cat
24.04.2008, 22:01
сты - почти чистые потребители. Или исключительно радиолюбители. Т.е. спаять что-нить могут, а вот запрограммировать то что спаяли - леньну, есть и исключения :), вон Дима Быстров :) хоть он и не железячник, но вполне удачно ковырялся, и программы писал..
Lethargeek
25.04.2008, 01:25
Зачем - чтоб рисовать не токо "карандашем"(zx) ценой в $0 ... $100 но и делать апликации "ножницами"(genlock) за $30 от "фломастерных" (segamd) рисунков за $20. Итого: все 10000 игрушек спекки можно "обклеить цветной апликацией" и заставить "звучать" по другому за прибамбас ценой в $50 при этом не выбрасывая свой родной Leningrad1 или Pentagon.
То-то все удивляются, почему у нас до сих пор вырезают гланды, но только через задний проход...
Если уж на то пошло, любители "кромсать" могут на телевизор бумажную аппликацию повесить - по совершенно смешной цене и с неограниченными (в отличие) глубиной цвета и разрешением!! :v2_laugh:
А в то что рисовать можно сразу "фломастерами" дешевле чем на Altera DE1 я не верю, к тому же агрегат этот не потерпит рядом старенького ZX-a который прийдется продать "за долги".
Дешевле - не юзать тестовые по сути своей универсальные борды для сборки готовых разработок!
Добавлено через 3 часа 7 минут
хозяин-барин! хотя с т.з. идеологии Спектрума то, что ты предллагаешь и бесперспективно..
Дело даже не в идеологии конкретно Спектрума. Аппаратные спрайты - морально устаревший паллиатив, просто некоторые не понимают, почему и зачем их были вынуждены использовать на рубеже лохматых 80-х.
Vladimir Kladov
25.04.2008, 15:36
Аппаратные спрайты - морально устаревший паллиативА аппартный 3Д-рендер - это то что надо... особенно для спектрума. А чего, правда, OpenGL на спеке, и вперёд.
Если уж на то пошло, любители "кромсать" могут на телевизор бумажную аппликацию повесить - по совершенно смешной цене и с неограниченными (в отличие) глубиной цвета и разрешением!! :v2_laugh:
А смешно то как нам всем... что аж плакать хочется. Если есть какие-то претензии по поводу что сделать нормальный genlock c програмируемым видеомикшером за $30 почти невозможно то я бы охотно поверил и проникся техническими проблемами. Ну а так я не вижу никаких аргументов почему эта идея с dendy Веремеева так и погибла на самом старте.
Дешевле - не юзать тестовые по сути своей универсальные борды для сборки готовых разработок!
Ага - расскажешь это caro который вместо того чтоб 1chip_msx покупать запустил себе его на AlteraDE1 успешно (и дешевле и прикольнее).
Аппаратные спрайты - морально устаревший паллиатив, просто некоторые не понимают, почему и зачем их были вынуждены использовать на рубеже лохматых 80-х.
Ну ну обьясни нам почему? Не потому ли что 95%(?) игрушек на спектруме состоит из background-a, спрайтов, музыки и логики? (И если для background-a, спрайтов и музыки сделать отдельные пространства памяти со своими процессорами/контроллерами то память и шина основного проца будет полностью свободна для логики).
И кроме того хотелось бы услышать почему ж спрайты устарели (что пришло им на замену)? И если они устарели то чего куча народу пишет на крутом 3D железе игры в которых 2D спрайты одни или псевдо-3D графика?
Lethargeek
25.04.2008, 16:13
А аппартный 3Д-рендер - это то что надо... особенно для спектрума.
3D-то к спрайтам которым боком? Снова - теплое с мягким?
А чего, правда, OpenGL на спеке, и вперёд.
Это уже к медведу :p
Добавлено через 4 минуты
Ну а так я не вижу никаких аргументов почему эта идея с dendy Веремеева так и погибла на самом старте.
Потому что софт писать под фактически новый комп никто не стал, а генлок сам по себе просто скучен.
Ну ну обьясни нам почему? Не потому ли что 95%(?) игрушек на спектруме состоит из background-a, спрайтов, музыки и логики? (И если для background-a, спрайтов и музыки сделать отдельные пространства памяти со своими процессорами/контроллерами то память и шина основного проца будет полностью свободна для логики).
И кроме того хотелось бы услышать почему ж спрайты устарели (что пришло им на замену)? И если они устарели то чего куча народу пишет на крутом 3D железе игры в которых 2D спрайты одни или псевдо-3D графика?
Ты однако не путай аппаратные спрайты с программными.
Ужос... как все запущено... :rolleyes:
Black_Cat
25.04.2008, 17:23
А аппартный 3Д-рендер - это то что надо... особенно для спектрума. А чего, правда, OpenGL на спеке, и вперёд.:) нет, 3d никогда не будет Спековским режимом :), да и до 2d Спектрум врядли когда дойдёт.. хотя точно сказать не берусь - глубоко в 2d не вникал.
Я понимаю огорчение от того, что твои идеи не воспринимаются "на ура", хотя не могу сказать, что здесь тоже не всё однозначно, в частности в том, что утверждает Летаргик. Летаргик утверждает глобально правильные вещи, верные в пределе. Но не вдаваясь в подробности, должен заметить, что любая система - конечна, и потому действительных решений будет не одно, как было-бы в случае сходящейся последовательности при бесконечном пределе, а некоторое множество, образующее параметрическую плоскость действительных решений. :) Если короче - скажу может быть крамольную вещь - но для Спектрума, как конечной системы может существовать некоторое отклонение развития его видеосистемы в сторону спрайтового движка, хотя такое отклонение сугубо локальное и строго ограниченное, и уж никак не тянет на запросы Владимира. Это допустимое отклонение находится приблизительно на уровне текстового режима (может чуть шире), который по сути является примитивным спрайтовым движком. Не хочу глубже развивать эту тему, потому что она далеко не однозначна и требует очень тонкого параметрического разделения того что допустимо, а что уже находится за пределами области действительных решений (хотя я в общих чертах и представляю направление в какую сторону нужно рыть чтоб определиться с таким разделением). Единственно, что могу с уверенностью сказать уже сейчас - это то, что предложенный спрайтовый движок точно не вписывается в область допустимых решений, т.к. является слишком развитым спрайтовым движком, а имеющее место допустимое небольшое отклонение может разрешать существование только самых примитивных спрайтовых движков на платформе Спектрума.
3D-то к спрайтам которым боком? Снова - теплое с мягким?
Это было сказано не серьезно в ответ на такое же издевательство с твоей стороны по поводу того что спрайты "устарели" и не имеют для спектрума никакой ценности.
Потому что софт писать под фактически новый комп никто не стал, а генлок сам по себе просто скучен.
1 момент, не "писать" а адаптировать! все те 10000 игрушек под новую графику и звук. Точно так же под TRDOS и GS вначале ничего небыло, потому что само железо было у единиц. А тут вообще у одного Веремеева был genlock в каком-то "глюканутом" виде еще у десятка было TWO MONITOR solution чисто из интереса поганять dendy игрушки без картриджа. И даже при этом есть LaserBasic адаптированный под это дело тем же Веремеевым, даже утверждалось что написать там игру типа DIZZY может школьник 4-го класса. Так что вся проблема токо в самой схеме\плате а не в идее или в не желании кого-то это покупать\пользовать.
Ты однако не путай аппаратные спрайты с программными.
Я ничего не путаю - если спрайты устарели то зачем их применять в новых играх? - Пиши все ввиде wolf3d. А если применять токо спрайты то нафиг железо воротить на 100 миллионов транзисторов которое под 3D заточенно? - Cпрайтовый движек типа v9990 вполне прокатит.
Lethargeek
25.04.2008, 19:57
Это было сказано не серьезно в ответ на такое же издевательство с твоей стороны по поводу того что спрайты "устарели" и не имеют для спектрума никакой ценности.
И не только для Спектрума, а уже вообще для чего угодно.
Насколько "серьезно" там было сказано - виднее самому В.Кладову.
И даже несерьезные мысли надо таки корректно формулировать.
1 момент, не "писать" а адаптировать! все те 10000 игрушек под новую графику и звук.
Что в случае прикрученного дендюка с прямо-таки противоположной Спеку архитектурой как раз и означает "написать заново". А тырдос и даже GS не требуют подобного объема работ для адаптации и фактически не влияют на совместимость софта со стандартным железом.
Школьникам писать Dizzy было неинтересно (и нафиг им Спек? когда были сюборы всякие), а "крютые кодеры" и так прекрасно клепали дизей на Z80. И нафига прибамбас, который либо требует значительных усилий для полного освоения и эффективного использования, либо не обеспечивает настоящего качественного скачка?
Спек как эмуль картриджа для денди - ваще смешно и к спектрумизму отношения не имеет.
Я ничего не путаю - если спрайты устарели то зачем их применять в новых играх? - Пиши все ввиде wolf3d. А если применять токо спрайты то нафиг железо воротить на 100 миллионов транзисторов которое под 3D заточенно? - Cпрайтовый движек типа v9990 вполне прокатит.
Ты путаешь ВСЕ. Повторяю для тех, кто в танке: устарели аппаратные спрайты (вместе с тайловыми задниками). А то, что "используется в новых играх" - это битмапы (в том числе заюзанные даже в упомянутом вольфе) - спрайтами и тайлами они называются условно и по привычке.
Про тридевятый лучше промолчу - любители сеги со снесом сами поймут.
Vladimir Kladov
25.04.2008, 21:46
3D-то к спрайтам которым боком? Снова - теплое с мягким?А прочитать внимательно? Сарказма не улавливается? Там квотация была, для понимания, на какую фразу я отвечаю. Спрайты, видите-ли, оказывается, тупик, и всё делать процессором - это правильно. А то, что в современных компах графикой занимается специализированный 3Д-ускоритель - тоже тупик?
однако не путай аппаратные спрайты с программными
Да какая разница человеку, смотрящему в экран, аппаратные эти спрайты или программные? А вот то, что картинка быстро двигается и при этом видно одновременно 2 миллиона цветов, вот это и есть достижение аппаратных спрайтов. И программеру лабать на спрайтах аппаратных заведомо проще: у него просто больше свободы останется на логику и математику, и не надо дрожать над каждым тактиком в кадре.
(О, щас польётся: вот потому-то Спековские программеры и круты... Знаю, знаю, особенно наши. До того крутЫ, что наших игрушек - пальцев на одной руке хватит, чтобы посчитать... только демок лабать и могут, ну такие крутые, что дальше некуда).
И программеру лабать на спрайтах аппаратных заведомо проще: у него просто больше свободы останется на логику и математику
Это достигается и без аппаратных спрайтов
Vladimir Kladov
26.04.2008, 09:23
Это достигается и без аппаратных спрайтов
С этого места, пожалуйста, подробнее. И наверное очень удобно для программинга. И памяти мало требует. И скорость офигительная, можно всё продолжать на 3.5 МГц делать. И цветов на экране - миллионы. Тогда я - пас.
Да, все перечисленное можно скорость слегка меньше но возможностей больше, достигается юзанием блитера ну мож еще и с очередью
Просто нада понимать что спрайты предоставляют тож достаточно жесткие требования к памяти, ты записал и ряд 4 спрайта с дырками в начале экрана (скажем в первых 10% экрана), а девайсу треснуть прийдется что бы их показать
К тому же возникают ограничения 4 спрайта на горизонтальную линию, и задники к примеру спрайтами не прокачаеш, нада процом рисовать, а так пнул железку пусть заполняет куски памяти (даж не обязательно прямоугольные)
Lethargeek
26.04.2008, 12:53
А прочитать внимательно? Сарказма не улавливается? Там квотация была, для понимания, на какую фразу я отвечаю.
Там был ответ на что угодно, кроме "той" фразы. :p
Спрайты, видите-ли, оказывается, тупик, и всё делать процессором - это правильно.
"А прочитать внимательно?"
Не надо выдавать собственные фантазии за мнение оппонента.
А то, что в современных компах графикой занимается специализированный 3Д-ускоритель - тоже тупик?
В очень отдаленной перспективе узкая специализация отдельных узлов - скорее всего тупик (не уверен, что доживем). А ближе к нам - кроме 3D есть вообще-то такая вещь, как 2D-ускоритель. Если кто не знает.
Да какая разница человеку, смотрящему в экран, аппаратные эти спрайты или программные?
Разница - прежде всего для кодера.
Хотя и для юзверя-геймера тоже вполне заметно. Вот например такая вещь, как антиалиасинг. Внимательно посмотрим на какую-нить 16-битную игрушку с рендеренными спрайтами, например Donkey Kong для SNES - "внутри" спрайта все красиво и гладко, а кромка-то - зубчатая! Я уж молчу про такие вещи, как плавное масштабирование и движение с шагом меньше размера пикселя.
А вот то, что картинка быстро двигается и при этом видно одновременно 2 миллиона цветов, вот это и есть достижение аппаратных спрайтов.
С определенного момента быстрее уже не надо! Надо лучше.
И как раз по "одновременным" цветам спрайтайловые движки в глубокой попе.
И программеру лабать на спрайтах аппаратных заведомо проще: у него просто больше свободы останется на логику и математику, и не надо дрожать над каждым тактиком в кадре.
Например "над тактиками не надо трястись" на SNES, где все операции с графикой должны укладываться в коротенький промежуток вертикального гашения? :rolleyes:
Vladimir Kladov
26.04.2008, 18:50
ряд 4 спрайта с дырками
8
Добавлено через 2 минуты
кроме 3D есть вообще-то такая вещь, как 2D-ускоритель
не, не знаю. На ПЦ такого нет. Ну даже допустить что есть, что в жтом спеку?
Добавлено через 5 минут
а кромка-то - зубчатаязубчатка я так полагаю следствие низкого разрешения. А на мелком экране типа телефона видно не будет. Другой вариант борьбы: альфа-канал в цвете, по краям размещать полупрозрачные пиксели.
Добавлено через 10 минут
Спрайты, видите-ли, оказывается, тупик, и всё делать процессором - это правильно.
"А прочитать внимательно?"А нечего было читать. Только и оставалось что фантазировать.
Добавлено через 20 минут
Я вообще не имею в виду адаптацию старых игр. Хотя она наверное в каких то случаях реальна Я имею в виду возможность написатния игр нового класса спектруму ранее недоступного. Например, как вы предсталяете себе игрушку Зума на Спеке? Я - никак. А вот с таким аппаратным спрайт-режимом - очень даже. Экран мелковат, но это переживаемо.
На спеке нереализуем целый класс игр, например, в которых требуется плавный скроллинг заднего поля. Например, ещё в конце 80х на КУВТ Ямаха были такие: вертолётик, который всё время в центре экрана, он только меняет направление, движется земля-море-корабли под ним. Что, есть такое на спеке?
Плавное масштабирование спрайтами такого рода достижимо. Масштабировать придётся самому, такты на это есть (с такой аппартной поддержкой времени на отображение достаточно). Можно даже 3Д-игры с проволочной графикой перевести на спрайты и раскрасить. Это уже в меру мастерства.
Но мне показалось наиболее перспективным вот что. В последующем спек, живой окажется в музее, под стеклянным колпаком. Вообще исчезнуб "живые" Z80, ВГ. Спек будет эмулироваться, либо чипом FPGA, либо на другом компьютере. В обоих случаях разработка и поддержка простого своего спрайтового аппаратного движка для впихивания его в этот же FPGA или в софтверный эмулятор намного проще, чем точное воспроизведение сложного чужого устройства, будь то V9990 или какое другое.
Lethargeek
26.04.2008, 19:18
не, не знаю. На ПЦ такого нет.
Учить матчасть!!
Ну даже допустить что есть, что в жтом спеку?
А что Спеку в спрайтах? Как вообще можно предлагать что угодно (не только спрайты), ничего другого по теме не зная?
зубчатка я так полагаю следствие низкого разрешения.
Спрайты проблему разрешения никак не решают. Совсем даже наоборот.
А на мелком экране типа телефона видно не будет.
А "что в этом Спеку"?
Другой вариант борьбы: альфа-канал в цвете, по краям размещать полупрозрачные пиксели.
А это значит: убить на то же самое изображение вдвое больше отведенного на чтение спрайтов времени только из-за альфа-канала (краями тут не обойдешься, большинство изображений - далеко не выпуклые фигуры) - то есть прощай половина спрайтов в строке! В случае 2D-ускорителя потребуется отнюдь не вдвое времени на отрисовку, а всего лишь процентов на 10-15 больше - примерно пропорционально длине границы.
P.S. Спрайты тоже "делаются процессором", если уж на то пошло. Спецпроцессором - таким же, как и 2D-ускоритель. Причем в отличие от оного - динамически, что влечет за собой известные неудобства.
У спрайтовых движков есть несколько очень существенных недостатков.
К примеру У тебя есть 8 спрайтов на линию растра (если появляется альфа то требования на порядок ужесточаются), у тебя есть ширина канала памяти скажем для вывода в начале экрана одновременно 3-5 спрайтов (8 равномерно размещеных соотвественно это уже средняя ситуация), так вот у тебя в некоторыйх участках экрана память в полном ауте и юзается на 100% в других участках простаивает к тому же имееш аппаратные ограничения на колво спрайтов
В случае двухмерного ускорителя (bitblt - билттер) у тебя есть скажем 1млн цклов памяти и ты их юзаеш как тебе нада без каких либо ограничений в рамках полосы.
И опятьже делаьт спрайтовый движок достойный вертолетиков это не прогресс а как раз 80е.
Lethargeek
26.04.2008, 22:15
На спеке нереализуем целый класс игр, например, в которых требуется плавный скроллинг заднего поля. Например, ещё в конце 80х на КУВТ Ямаха были такие: вертолётик, который всё время в центре экрана, он только меняет направление, движется земля-море-корабли под ним. Что, есть такое на спеке?
А на Ямахе было что-нить наподобие Operation Hormuz? :p
Хотя в принципе существует и позорная "спрайтовая" версия (на комоде). :D
И опятьже делаьт спрайтовый движок достойный вертолетиков это не прогресс а как раз 80е.
Угу, я-то хотел бы что-нить уровня Jets'n'Guns :D Ну хоть приблизительно ;)
Угу, я-то хотел бы что-нить уровня Jets'n'Guns Ну хоть приблизительно
Всмысле изобразить?? Вперед, особено если будет 48к касетная версия :)
Интересно там для задников HAM компресия графики оптимально будет?
Lethargeek
27.04.2008, 03:39
Всмысле изобразить?? Вперед, особено если будет 48к касетная версия
Интересно там для задников HAM компресия графики оптимально будет?
Спокуха, разрешение будед где-то вдвое меньше однако.
А задники - вычисляемые в реалтайме ;)
Грузить - по уровням. Желательно с сидюка, благо он уже есть. :p
Vladimir Kladov
27.04.2008, 10:46
не, не знаю. На ПЦ такого нет.
Учить матчасть!!На ПЦ нету. Учите сами.
Спрайты проблему разрешения никак не решают. Совсем даже наоборот.Спрайты вообще не имеют никакого отношения к разрешению, оно просто остаётся каким было. Кому не хватает разрешения, идут на другую платформу.
вдвое больше отведенного на чтение спрайтов времени только из-за альфа-канала (краями тут не обойдешься, большинство изображений - далеко не выпуклые фигуры)
Не вдвое а на трерть. Это раз. Во-вторых, альфа может быть частью самой палитры. Тогда на ноль.
большинство изображений - далеко не выпуклые фигуры
Альфа-канал решает. Используется палитра, в которой есть полностью прозрачный цвет.
8 равномерно размещеныхРазмещенных в любых местах по строке, я настаиваю на втором варианте. Это удобно для програминга. И наплевать, что нужна немножко сложненькая логика для выбора того из какого именно спрайта или фона берётся пиксель. Это прошивается один раз и зыбыли.
Operation HormuzЯ не знаю, что это, но наверняка в плане графики на Ямахе можно сделать всё что есть на спеке и еще в 10 раз больше. Хотя я видел только парочку игрушек, случайно попал в класс для продвинутых детей, туда нас наш препод пригласил зачёты ему сдавать по прогрммированию. Пока его группа детишек играла и на бэйсике кое-кто кропал, он и у нам чего-то принимал. Спек в это время у меня уже был, и я уже мог осознвть, что эта графика Спеку недоступна.
Размещенных в любых местах по строке, я настаиваю на втором варианте. Это удобно для програминга. И наплевать, что нужна немножко сложненькая логика для выбора того из какого именно спрайта или фона берётся пиксель. Это прошивается один раз и зыбыли.
Если тока прошьется...
Добавлено через 7 минут
Я кончно понимаю, но смотреть на железку со стророны эмулятора...
и кидаться общими фразами немножко там, слегка там, на самом деле Ваш вариант српайтового движка будет сложнее в реализации чем просто тупой блитер с той же функциональностью, а в итоге можно будет гораздо больше вывести графических обьектов за такт, при тех же затратах со стороны проца
Добавлено через 20 минут
И еще в ПЦ есть 2D и он доступен даже из под DOS через последние версии VESA VBE BIOS, а под конкретные видяхи через порты их юзают еще знает фик с каких времен Trident 9440 уже содержал данный блок (звался что то в духе - ускоритель Windows)
Vladimir Kladov
27.04.2008, 18:21
в ПЦ есть 2D и он доступен даже из под DOS через последние версии VESA VBE BIOS, а под конкретные видяхи через порты их юзают еще знает фик с каких времен Trident 9440 уже содержал данный блок (звался что то в духе - ускоритель Windows)При чём тут 2D? Ускорение пересылки блоков, тот же DMA, но внутри исключительно видеопамяти. Хотя называйте как хочется.
Я не очень понимаю 2 вещи. Каким образом ускорение пересылки байтов (тот же DMA или блиттер как его именуете вы) может решить 2 проблемы: построение сцены (заполнение экрана) фрагментами из разных мест памяти, и вотрая, это экономичное представление более 16 цветов на точку одновременно. Если делать 256 цветов, то ещё как-то представить можно, но это ещё в 2 раза больше памяти чем для 16цветов (который требует в 4 раза больше памяти чем стандартный, и дело ведь не в объёме, а в скорости заполнения экрана), но спрайтный режим при наличии 8 (даже) палитр даёт уже 128 разных цветов, что не на много меньше 256 (а можно подумать как сделать ещё больше), и при этом памяти (всего) для представления экрана требуется в 2 раза больше чем для стандартного режима. В 2 тоько лишь потому что прежний экран остаётся как сдвинутый по x, y фон, и ещё ровно столько же - для описателей размещения спрайтов. Что касается самих спрайтов, то они занимают почти столько же, например, сколько занимали бы гипотетически в плоском 16ц режиме (будь для этого режима хоть одна спрайтовая игрушка, что невозможно из-за тормозов).
Да, я понимаю, что если играть "по правилам" и делать устройство, которое бы соблюдало скоростные характеристики памяти, имевшие место в 1995, то ни фига не выйдет. Хотя, если обеспечить эксклюзивный доступ к нужным банкам памяти от видеоустройства, можно было бы и подумать. (На самом деле, когда мы приготовили кадр и переключили видеобанк, нам доступ к банкам, отданным видеопроцессору уже не нужен от проца, пока не пройдёт кадр и банки опять не переключатся).
Для блиттера (что за блитер, кстати, если реализован и используется широко для некоего видеорежима, то как называется это устройство, чтобы почитать), я пока не могу понять способ заполнения даже для режима 16ц. Тем более ничего не знаю о режимах 256ц. Просветите?
Lethargeek
27.04.2008, 18:56
На ПЦ нету. Учите сами.
Не стыдно раз за разом так попадать исключительно из-за собственного упрямства? :rolleyes:
Спрайты вообще не имеют никакого отношения к разрешению, оно просто остаётся каким было. Кому не хватает разрешения, идут на другую платформу.
А кому не хватает спрайтов и вертолетиков - идут туда же?
Проблема сглаживания тоже не одним увеличением разрешения решается (см. собственную цитату). Телевизор обычный - высокое там разрешение? (имею в виду не старые кинескопы, а сам сигнал) И ничего - все гладко.
Не вдвое а на трерть. Это раз. Во-вторых, альфа может быть частью самой палитры. Тогда на ноль.
Альфа-канал решает. Используется палитра, в которой есть полностью прозрачный цвет.
Налицо полное непонимание вопроса и даже базовых терминов.
Прозрачный цвет - это и есть полностью "прозрачный" цвет (transparent) (общий или вырожденный случай)
Альфа-канал - это частично прозрачный цвет (translucent) (более узкий термин)
Альфа требует на один пиксель столько же бит, сколько на одну цветокомпоненту в палитре (а не количество бит на закодированный цвет в палитровых режимах). То есть 32K цветов (hi-color) - нужно 5 бит, 256K цветов (VGA-палитра) - 6 бит, 16M цветов (true-color) - 8 бит на каждый альфа-пиксель. Это в дополнение к каждому пикселю собс-но самого спрайта.
Далее - спрайты в прямой кодировке сроду не делались (иначе любой спрайтовый движок сдохнет), обычно - 4-16-32 цвета на спрайт из палитры начиная с 4K-32K цветов. То есть в среднем надо 5 бит на пиксель спрайта и столько же - на альфа-пиксель. Итого - ВДВОЕ больше.
В особо извращенных случаях может быть еще и раздельная альфа для каждой из трех цветокомпонент (для эффектов типа цветного стекла).
Размещенных в любых местах по строке, я настаиваю на втором варианте. Это удобно для програминга. И наплевать, что нужна немножко сложненькая логика для выбора того из какого именно спрайта или фона берётся пиксель. Это прошивается один раз и зыбыли.
Спрайты должны читаться полностью и заранее - с опережением на строку, вне зависимости от перекрытия. Отсюда получаем верхнюю границу и ограничение на число спрайтов в строке. Если их даже там нет ни одного - все равно должны резервировать столько же времени.
Я не знаю, что это, но наверняка в плане графики на Ямахе можно сделать всё что есть на спеке и еще в 10 раз больше.
А вот неплохо бы посмотреть - что это (и чем отличается от упомянутой комодурской вериии). Чисто для сравнения с "вертолетиками". :) На Ямахе сделать такое (а именно перспективный скроллинг и эпизодическую псевдо-трехмерность) "на спрайтах" не выйдет, а прямой доступ к видеопамяти там ацтойный.
Спек в это время у меня уже был, и я уже мог осознвть, что эта графика Спеку недоступна.
"Недоступна" фактически только по цветности, в меньшей степени - по плавности (эти проблемы в принципе решаемы даже методами ZX-Poly а-ля EmuZwin :) и/или турбированием проца, не говоря уж о растровых ускорителях). А вот спрайтовым движкам многие вещи недоступны по качеству и динамике (либо доступны, но с большим геморроем и "потерей мощности").
Добавлено через 1 час 18 минут
Каким образом ускорение пересылки байтов (тот же DMA или блиттер как его именуете вы) может решить 2 проблемы: построение сцены (заполнение экрана) фрагментами из разных мест памяти,
Тут вообще проблемы нет.
...и вотрая, это экономичное представление более 16 цветов на точку одновременно.
Я так понял, про упаковку графики - в упор не видим?
По блиттеру - читаем доки на Амигу. Для начала. Это наверное первый - и довольно простой - вариант.
Народ а не кажется ли Вам что разговор зашел в тупик по причине того что обсуждается не конкретная реализация а так что-то несуществующее при этом расплывчатое и имеющие сходство практически со всем что вокруг можно увидеть - MSX, SNES, c64, S3-911/Trident windoze ускорители, NEOGEO, SONY PS1/2/3 ... Так или иначе никто их Вас сдесь не предложил ничего нового а только лишь описал что-то отдаленно напоминающие какую-то конкретную железяку из существующих. Дальнейшее обсуждение имеет смысл вести токо приводя какие-то куски псевдо кода (например похожего на тот же C или BASIC) чтоб описать а что собственно будет делать это предлагаемое железо иначе разговор ни о чем.
Ну и так общее замечание - прежде чем предлагать конструкцию учитывайте на какую пропускную способность памяти мы сдесь ориентируемся. На скоко я понял с самого начала железяка планируется не для "monster RDRAM 1Ghz 512bit quad pumped bus" а для того же родного Leningrad-1 с РУ5Г и все что можно достичь введением в основное адресное пространство всяких там DMA и blitter-ов уже достиг тот же VELESOFT и автор UltraDMA sound-a.
При этом спрайтовые движки древнейшая и проверенная технология которую протерли до дыр в свое время вот на этом сайте доказательства: http://www.system16.com/
Lethargeek
27.04.2008, 21:37
Ну и так общее замечание - прежде чем предлагать конструкцию учитывайте на какую пропускную способность памяти мы сдесь ориентируемся. На скоко я понял с самого начала железяка планируется не для "monster RDRAM 1Ghz 512bit quad pumped bus" а для того же родного Leningrad-1 с РУ5Г
То есть даешь резню и тупой раскаленный предмет?
К тому же все эти РУ скоро совсем вымрут как класс.
Глупо не юзать современные м/с, которые и лучше, и доступнее!!
а для того же родного Leningrad-1 с РУ5Г и все что можно достичь введением в основное адресное пространство всяких там DMA и blitter-ов уже достиг тот же VELESOFT и автор UltraDMA sound-a.
DMA - не блиттер. Ну и трогать основную память - опять же, для любителей резни и затормаживания проца.
При этом спрайтовые движки древнейшая и проверенная технология которую протерли до дыр в свое время
"Если в сыре много дыр - значит, вкусным будет сыр.
Если в нем одна дыра - значит, вкусным был вчера!!" :v2_laugh:
Добавлено через 40 минут
Даже ссылки нормальной не дал. Хотя в результате поиска по форуму выясняется, что они там даже таких слов, как "блиттер", походу не знают. Узость мышления, таксзать. :rolleyes:
Народ а не кажется ли Вам что разговор зашел в тупик по причине того что обсуждается не конкретная реализация
Да не, спорить не буду, я прекрасно понимаю что у Владимира есть своя точка зрения а переубеждать неблагодарное дело :)
Lethargeek
28.04.2008, 00:57
Да не, спорить не буду, я прекрасно понимаю что у Владимира есть своя точка зрения а переубеждать неблагодарное дело
Ну а я собс-но прежде всего пытаюсь выяснить возможные степени "узости мЫшления" :v2_devil:
Ну у каждого из подвариантов есть свои плюсы и минусы
а технологий даже в 2Д графике хватает
Vladimir Kladov
28.04.2008, 17:22
Не стыдно раз за разом так попадать исключительно из-за собственного упрямства?
Нет не стыдно. Вы можете называть блиттер 2Д-ускорителем, но в ускоритель даже 2Д обязано быть включено: а) масштабирование б) повороты в) цветоналожение. А блиттер - просто пересылка блоков прямоугольной формы. Для спрайт-движка абсолютно непригодны в случае отсутствия альфа-канала.
Телевизор обычный - высокое там разрешение?
небольшой блюринг на старых телевизорах, на новых часто отсутствует. Но даже в этом случае легко сглаживается удалением глаз от экрана на 2 метра, скакого расстояния телевизор и предназначен использоваться. Если посчитаете, то у вас как раз получится 5-10 см если смотреть с 30-50 см. Т.е. чуть больше телефона, что я и имел в виду говоря о телефонном экране ниже.
Альфа-канал - это частично
Я в курсе. Мне всё совсем подробно излагать некогда, догадывайтесь.
То есть в среднем надо 5 бит на пиксель спрайта и столько же - на альфа-пиксель.
Мне надо на диктофон надиктовать и копи-пасте? Альфа-канал - часть палитры, а не спрайта. Например, есть 16 цветов в палитре. 1 цвет делаем полностью прозрачным, ещё один - на четверть прозрачный, на 3/4 ультрамарин. Остаётся 14. Это в той строке, где нужна полная прозрачность. Для длугой строки спрайта можем использовать другую палитру. Так - понятно?
Спрайты должны читаться полностью и заранее
Какие-то пробемы? За две строки до - (1) прочитать описать, за одну строку до - (2) сформировать 256 пикселей, и пока они выводятся, делать (1) для строки i+2, и (2) для i+1 ?
А вот спрайтовым движкам многие вещи недоступны по качеству и динамике
Например? (А, догадался я: рисование каждого кадра, если он заранее заготовлен и скинут на сидюк, и гра заключается в выборе разветвления, в каком порядке смотреть ролики). Ну вообще-то я уже придумал вариант, в котором нет ограничений на размер спрайта в ширину, все 256 пикселей наши. Достаточно длину срайта хранить в самой линии спрайта в памяти, занимая на это ровно один байт.
про упаковку графики
и про рсапаковку на лету. Да, и на 3,5 МГц. Очень верится. Или это будет делать блиттер? Респект ему.
читаем доки на АмигуНе, не хочу я читать про Амигу. Это комп совсем другого класса. То, что я предлагаю, по-моему вполне вписывается в рамки современного спектрума.
на какую пропускную способность памяти мы сдесь ориентируемся. На скоко я понял с самого начала железяка планируется не для "monster RDRAM 1Ghz 512bit quad pumped bus" а для того же родного Leningrad-1 с РУ5Г
А вот РУ5 - это уже вряд ли, к сожалению. Как минимум simm, а по причине и их редкости - уже надо о dimm думать (да и они скоро станут раритетом, наверное).
они там даже таких слов, как "блиттер"
А вы уверены, что это слово должно быть известно всем, интересующимся графикой? Скажите, а как с помощью блиттера бросить на экран спрайт с неровными краями, если только этот блиттер не умеет отсекать прозрачные пиксели? Тогда это у же принципиально не блиттер и не ДМА, а тот же спрайтовый двиг, только с другого боку. И в нём есть помимо схожестей один большой отличий = недостаток: вы как ему последовательность разных пересылоки перебросок зададите? Дали команду, подождали, когда выполнит, дали другую команду? Да нафиг он такой нужен! Спрайтовый двиг хорош тем, что задали карту экрана на 1 кадр, переключились, и делаем другие важные дела. А он работает, и проц вообще не отвлекает. По-моему, кое-то просто упёрся, и готов спорить ради спора. Мнре это неинтересно. Я хотел получить обсуждение спрайтового двига и возможных технических характеристик от специалистов, а не пустой болтовни о том, почему этого делать не надо. Я просто добавлю в свой эмулятор такую поддержку спрайтового движка, якобы аппаратного, но уже без соотнесения с возможностями аппаратуры того или иного поколения. На каком-нибудь, будет реализуемо.
Тогда это у же принципиально не блиттер и не ДМА
Я понял - необходимо понимание что блитер это не dma, потому как он не с блоками памяти работает а с блоками графики, мож тогда проще будет
Может распаковывать графику находу, расчитывать альфа канал, маштабировать и т.д. то что недоступно спрайтам из за их ограниченого по времени (на строку) работы принципу.
Если syd сделает speccy2008 (ценой до 100$), это и будет современный
спек, с возможностью написать на hdl, нормальный 2Д видео-процессор (в
fpga).
Сорри но я так не думаю :( - то что делает syd это к сожалению никакой не zx-spectrum а очередной недо-AlteraDE1 board в стиле 1_сhip_msx. А не 100% спекки клон он уже сделал. Я думаю что zx-spectrum это: http://en.wikipedia.org/wiki/ZX_Spectrum А современный zx-spectrum это: http://www.zxdesign.info/wideMemContention.shtml
Добавлено через 18 минут
Может распаковывать графику находу, расчитывать альфа канал, маштабировать и т.д. то что недоступно спрайтам из за их ограниченого по времени (на строку) работы принципу.
что за чепуха? тот hardware overlay который сейчас есть в каждом современном видео чипе и есть своего рода спрайт :) и все он может включая масштабирование. Та по сути тот же blitter это глупый переброс кусков информации в видео память что есть изначально тупая операция из-за того что совсем паралельно из других банков памяти можно бросать эти пиксели прямо на выходной DAC не мешая ни СPU и сканеру показывающему background. Спрайты не требуют высокой пропускной мощи памяти и тем более не должны быть в основной памяти CPU или иметь что-то общее с палитрами background-a... В гипертфророванной реализации этой модели спрайты это всеравно что наложенные друг на друга (по сложным правилам) бесконечное количество экранов каждый со своей отдельной видеопамятью и pixel shader-ом.
hardware overlay
Это не билер это спрайт
о оверлеем ты из внеекранной памяти даже фон одинаковый тайлом не заполниш
Добавлено через 47 секунд
Даже не спрайт а отдельное "Окно" что то в духе PIP
Добавлено через 1 минуту
то что делает syd это к сожалению никакой не zx-spectrum а очередной недо-AlteraDE1 board
Ага собери себе спрайтовый движок на рассыпухе
Vladimir Kladov
28.04.2008, 18:54
необходимо понимание что блитер это не dmaГуд, я прочитал что такое блиттер на вики, достаточно? Недостатки блиттера по сравнению со спрайтами очевидны: большой объём памяти для хранения всего построенного экрана, причём нужны 2 копии этого всего дела, и ещё одна копия для заднего плана, т.к. на каждом кадре надо восстановить фон, им заново нарисовать сцену. Спрайты для блиттера нужны всё равно, вряд ли они будут компактнее, чем без него. Программирование блиттера занимает времени больше, чем построение таблицы для отображения спрайта. То, что я набросал - даёт полностью весь тот же эффект, но без этих недостатков, вполне хватит 128К и 3.5МГц. Можно даже масштабирование подрубить аппаратное, буде оченно хочется (с поворотами не уверен, но флиппинг предусмотрен изначально).
Lethargeek
28.04.2008, 19:03
Гуд, я прочитал что такое блиттер на вики, достаточно?
Судя по всему дальнейшему тексту - недостаточно. Ну на каждую фразу можно писать опровержение! :rolleyes:
Амижный блиттер - только пример, причем довольно простой. Блиттер не обязан быть именно таким.
А все перечисленные недостатки имели какое-то значение до середины 90-х.
Добавлено через 38 минут
Нет не стыдно. Вы можете называть блиттер 2Д-ускорителем, но в ускоритель даже 2Д обязано быть включено: а) масштабирование б) повороты в) цветоналожение. А блиттер - просто пересылка блоков прямоугольной формы.
:rolleyes: ...ладно, молчу, благо вопрос частично отпал
небольшой блюринг на старых телевизорах, на новых часто отсутствует. Но даже в этом случае легко сглаживается удалением глаз от экрана на 2 метра,
Я совсем другое имел в виду. Будь на телевизоре пиксели размером даже со спековский атрибут, кромки всех объектов в телепередачах все равно будут столь же "гладкими", как и их внутренность - из-за (пере)дискретизации и усреднения цветов, причем начиная еще со стадии записи изображения.
Мне надо на диктофон надиктовать и копи-пасте? Альфа-канал - часть палитры, а не спрайта. Например, есть 16 цветов в палитре. 1 цвет делаем полностью прозрачным, ещё один - на четверть прозрачный, на 3/4 ультрамарин. Остаётся 14. Это в той строке, где нужна полная прозрачность. Для длугой строки спрайта можем использовать другую палитру. Так - понятно?
Мне понятно, что в результате получится полная фигня.
Контрпример - верхняя кромка сплющенного эллипса (в одну строчку!). Вот здесь на каждый пиксель (даже строгой симметрии может не быть, так что даже не на каждый второй) должна идти своя уникальная альфа-характеристика.
В итоге один хрен - на каждую строчку спрайта грузить строчку альфа-спрайта или перегружать уникальную палитру. По циклам памяти то ж на то ж и выйдет - ВДВОЕ больше (а по качеству будет даже хуже, потому что доступные цвета еще более урезаются).
вообще-то я уже придумал вариант, в котором нет ограничений на размер спрайта в ширину, все 256 пикселей наши. Достаточно длину срайта хранить в самой линии спрайта в памяти, занимая на это ровно один байт.
Просто смешно. Прочитать два бэкграунда и 8 строк спрайтов (до 256 точек каждый) хотя бы просто в 16 цветах с "тупой" палитровой прозрачностью - за 224 такта (на 3.5 МГц, ага)? Это 1280 байт получается! :v2_laugh:
Память придется раз в 6 разгонять (как раз 15ns статика покатит) - только чтобы картинку отобразить суметь, и то Z80 встанет намертво. Забудьте про общую память и 3.5МГц. Ничего сильно круче комодури так не получится.
Я хотел получить обсуждение спрайтового двига и возможных технических характеристик...
См. чуть выше :v2_laugh:
...а не пустой болтовни о том, почему этого делать не надо.
Тогда не стоило начинать тему с провокационной пустой болтовни типа "почему оставляют все плоским" , "нет никакой проблемы совместимости", "круче спрайтов для Спека быть ничего не может", "узость и плоскость мышления" (после чего демонстрировать прямо-таки пещерные представления о принципах построения двухмерных графических движков) итд итп.
Я хотел получить обсуждение спрайтового двига и возможных технических характеристик
А не хотите попробовать, взять за основу обычный сеговский (мегадрайв) видео-процессор.
Только немного изменить (улучшить):
Спрайты сделать - 8бит на пиксель (вместо 4бит)
Разрешение сделать - 320*240 (вместо 320*224)
Палитра 4096 цветов (12бит)
Остальное реализовать по докам, на этот чип.
Сеговские игрушки все видели,
еще представить что цветов больше стало.
А не хотите попробовать, взять за основу обычный сеговский (мегадрайв) видео-процессор.
И что потом? В лучшем случае результат будет эквивалентен тридевятому (логическому продолжению всех этих TI99xx видео-процессоров) для такого сопроцессор-а потребуется отдельный СPU или микро-контроллер в результате будет еще одна недо-SegaMD на fpga и ценой в $200. Это все не считая затрат на разработку и вылавливание тысячи глюков.
Vladimir Kladov
29.04.2008, 18:28
А не хотите попробовать, взять за основу обычный сеговский (мегадрайв) видео-процессор.
Только немного изменить (улучшить):
Спрайты сделать - 8бит на пиксель (вместо 4бит)
Разрешение сделать - 320*240 (вместо 320*224)
Палитра 4096 цветов (12бит)
Остальное реализовать по докам, на этот чип.
Я хотел бы использовать стандартное разрешение 256х192, чтобы прежний спековский экран (с учётом сдвига по х,у) можно было использовать как задний план. Что касается цветов на точку, то их получается столько, сколько хочется, было бы место, где разместить достаточное число палитр. Номер палитры может быть расширен до байта, но независимо от того, лежат палитры в общей памяти, или предварительно загружаются в собственную память "процессора спрайтов", занимают они довольно прилично (например, если это RGBA8, т.е. 32 бит на цвет). Меня в чисто спрайтовом движке смущает только ограничение на число спрайтов по горизонтали. Оно можно подумать над таким вариантом, когда таблица задаёт не размещение спрайтов по строкам, а просто задаются местоположения спрайтов, дальше их размещением занимается процессор, а будет это блиттер или схема, строящая изображение на лету - уже не суть важно. Но в случае схемы слишком много одновременно спрайтов задать не получится, у схемы должно быть физическое ограничение хотя бы на количество одновременно считающих счётчиков, а ещё компараторов до кучи... В случае блиттера ограничение как бы снимается, можно построить изображение по такой таблице...
Будь на телевизоре пиксели размером даже со спековский атрибут, кромки всех объектов в телепередачах все равно будут столь же "гладкими", как и их внутренностьЭто я не понимаю. Блиттер, получается, делает гладкое изображение, а спрайтовый движок - нет? Чушь какая-то, тем более что спрайтовый движок принципиально ничем от блиттера не отличается, кроме того, что в случае блиттера изображение строится в буфере, а потом кидается на экран, а в спрайтовом режиме - изображение сразу отправляется на экран, минуя буфер.
Контрпример - верхняя кромка сплющенного эллипса (в одну строчку!). Вот здесь на каждый пиксель (даже строгой симметрии может не быть, так что даже не на каждый второй) должна идти своя уникальная альфа-характеристика.
И сколько пикселей у верхней кромки эллипса будет в разрешении 256х192? Думаю, 16 максимум. Как раз столько, чтобы можно было выделить особую палитру под верхнюю кромку. А с учётом симметрии эллипса, и до 32 дотянет. Это если действительно требуется уникальное значение на каждый пиксель (половины эллипса, вторая половина симметрична). Но это тоже не очень умно: по мне, можно использовать одинаковый "цвет" с альфой и на 2-3 подряд пикселя.
перегружать уникальную
Что имеется в виду под перегружать? Все палитры или берутся из страницы видеопамяти, или заранее загружаются в собственную видеопамять видеоустройства. Даже если их 256 штук, по 16 цветов х 4 байта.
Память придется раз в 6 разгонять (как раз 15ns статика покатит) - только чтобы картинку отобразить суметь, и то Z80 встанет намертво. Забудьте про общую память и 3.5МГц.
Я не схемотехник.
Но почему 8 строк надо читать за 224 такта? По мне так достаточно читать те "пиксели", которые в данной точке подлежат отображению. В большинстве случаев это будет 0,5 (ноль целых пять десятых) байта на точку, итого 128 байт пикселей. Плюс 32 байта на чтение описателя спрайтов, если их 8 в строке, плюс по одному байту на чтение длины спрайтной строки, для присутствующих спрайтов (т.е. от 0 до 8 байтов). Если учесть наложения полупрозрачных пикселей, то ограничив их максимум 3 слоями, получим 1,5 байта на точку. Неужели <500 байт не потянет? Что-то не верится. Я потому и говорю, что вы чего-то недопоняли: мой набросок показывает, что общие требования на физические параметры даже меньше, чем требования на режим 16с, о котором здесь все слышали.
И почему надо читать 2 бакграунда? Задний план в моём варианте - это стандартный спековский видеорежим с одновременным скроллом всех точек и атрибутов с точностью до пикселя. Итого 64 байта на строчку для него.
Я хочу реализовать настолько простую "машинку" для спрайтов, чтобы её можно было чрезвычайно легко повторить, в другом эмуляторе, или в железе, мысля под железом не конкретно то железо, которое использовалось для спектрума традиционно, но и всякие эмуляторы спектрума на фпга. Может, и появятся желающие попробовать что-нибудь запрограммировать, хотя бы сначала на эмуляторе. Но я - почти полный ноль в схемотехнике, и поэтому мне совершенно неизвестны ограничения, которые могут возникнуть при реализации совсем простого, на взгляд программера, устройства, в том же фпга. Мне очень не хочется останавливаться на 8 спрайтах в ширину, но судя по описанию v9990, там это ограничение ещё жёстче - 6 штук на строку. Я бы очень хотел вообще не ограничиваться в числе спрайтов на строку, предпочитая общее ограничение на число спрайтов или пикселей. Это даёт блиттер, но мне он кажется слишком громоздким из-за промежуточной памяти для буфера изображения. Если включать в машинку масштабирование или повороты, т.е. делать полноценный 2Д, то это уже потянет на громоздкую реализацию, а это сложности с отладкой-доводкой, и этого мне тоже не хочется. В общем, я ещё подумаю над своим видеорежимом, пока довожу чужой до ума.
Lethargeek
29.04.2008, 20:33
Это я не понимаю. Блиттер, получается, делает гладкое изображение, а спрайтовый движок - нет? Чушь какая-то, тем более что спрайтовый движок принципиально ничем от блиттера не отличается, кроме того, что в случае блиттера изображение строится в буфере, а потом кидается на экран, а в спрайтовом режиме - изображение сразу отправляется на экран, минуя буфер.
В том-то и дело, что "сразу" в данном случае означает "с жесткой привязкой по времени". Отсюда следует (см. ниже), что паковать спрайты хотя бы за счет "дырок и обрезанных границ" толку мало (разве что несколько разгрузить шину для CPU). А вот блиттер легко пропускает ненужные точки и может использовать любую схему компрессии (например нужен объект в 17 цветов - тогда самый "редкий" цвет отделяем в отдельную картинку и потом накладываем на 16-цветный объект всего несколько таких точек, без лишних затрат времени; в случае спрайтового движка нужно убить два спрайта либо портить бэкграунд). И уж конечно "потом кидать на экран" буфер не надо, просто переключаем отображаемые буфера.
А принципиальное отличие состоит в коренном ОГРАНИЧЕНИИ:
* Для спрайтовых движков - суммарное количество (включая прозрачные) обрабатываемых накладывающихся пикселей (даже не спрайтов как таковых, хотя от их кол-ва схема тоже разбухает) на каждую СТРОКУ.
* Для блиттера - суммарное количество обрабатываемых накладывающихся пикселей (легко делается без прозрачных, в зависимости от раскладки) на весь КАДР (считая бордюр и интервалы гашения!). К тому же в крайнем случае всегда можно частоту обновления игрового поля (не скорость самой игры!) понизить - мигать ничего не будет, в отличие от спрайтового движка.
И сколько пикселей у верхней кромки эллипса будет в разрешении 256х192? Думаю, 16 максимум. Как раз столько, чтобы можно было выделить особую палитру под верхнюю кромку. А с учётом симметрии эллипса, и до 32 дотянет. Это если действительно требуется уникальное значение на каждый пиксель (половины эллипса, вторая половина симметрична).
Проблемы начнутся на следующих строчках, когда помимо кромки возникает шиииироооокая и непрозрачная середина. И если на нее истрачены все цвета - хоть ты тресни, а на сглаживание кромок не остается. Нужно использовать дополнительный спрайт. На самом деле весьма вероятная ситуация для любых обычных корявых объектов, а не только для гипотетических эллипсов.
Но это тоже не очень умно: по мне, можно использовать одинаковый "цвет" с альфой и на 2-3 подряд пикселя.
Суррогат. :v2_sick:
Что имеется в виду под перегружать? Все палитры или берутся из страницы видеопамяти, или заранее загружаются в собственную видеопамять видеоустройства. Даже если их 256 штук, по 16 цветов х 4 байта.
Проблема в том, что на любую отдельную строчку спрайта в общем случае потребуется своя собственная палитра. Сколько строк - столько уникальных палитр. На ОДИН спрайт. Сколько тогда потребуется внутренней памяти для палитр? Кстати эти палитры из-за прозрачности еще на треть (а то и вдвое) разбухнут. Дык их там еще и обновлять придется при любой анимации (не путать с простым движением) спрайта! А тянуть из внешней видеопамяти - ну так и есть, фактически второй спрайт. Иначе - подбирать внутренне зависимые жесткие раскраски (если уникальных не хватит) на каждый игровой эпизод без потери качества - ну, это для отпетых мазохистов.
И почему надо читать 2 бакграунда? Задний план в моём варианте - это стандартный спековский видеорежим с одновременным скроллом всех точек и атрибутов с точностью до пикселя. Итого 64 байта на строчку для него.
Даже так освобождается только 64 байта. Итого осталось 1216.
Но почему 8 строк надо читать за 224 такта? По мне так достаточно читать те "пиксели", которые в данной точке подлежат отображению.
Ничего не выйдет. Любой спрайтовый движок ОБЯЗАН обеспечить вывод строки "в худшем случае" в жестких временнЫх рамках - иначе это не спрайтовый движок, а фуфло. Сказано - "8 спрайтов в строке" - значит, 8! Сказано "в спрайте до 256 точек" - значит, будь ВСЕГДА готов обработать ВСЕ возможные 256*8=2048 пикселей. Плюс бэкграунды.
Уфф.. я надеюсь, мне все-таки не придется объяснять - почему. :rolleyes:
Я хочу реализовать настолько простую "машинку" для спрайтов, чтобы её можно было чрезвычайно легко повторить, в другом эмуляторе, или в железе, мысля под железом не конкретно то железо, которое использовалось для спектрума традиционно, но и всякие эмуляторы спектрума на фпга.
Просто = убого.
Мне очень не хочется останавливаться на 8 спрайтах в ширину, но судя по описанию v9990, там это ограничение ещё жёстче - 6 штук на строку.
Там - 16 на строку (но всего по 16 пикселей на каждый) в 16 цветах, на весь экран 4 палитры. Конкретно спрайтовые режимы у тридевятого не фонтан. А растровые - тормозные.
Выгрызать и делать отдельно аналог одних только спрайтовых режимов особого смысла не вижу.
Это даёт блиттер, но мне он кажется слишком громоздким из-за промежуточной памяти для буфера изображения. Если включать в машинку масштабирование или повороты, т.е. делать полноценный 2Д, то это уже потянет на громоздкую реализацию,
И что "громоздкого" в буфере? Как второй экран на Спеке-128 (можно еще и не полностью все окошко впечатывать). Масштабирование - конечно с тотальным сглаживанием (и вращением) подробно считать надо (если просто с одним прозрачным цветом - ерунда). Повороты на прямой угол и отражения - даром, пару счетчиков переименовать.
Я хотел бы использовать стандартное разрешение 256х192, чтобы прежний спековский экран (с учётом сдвига по х,у) можно было использовать как задний план.
Вероятно проще сразу делать нормальный (полно-функциональный)
новый экран, чем возиться со старым.
Если напрягает ограничение на спрайты в строке, тогда блитер.
Взять тотже 320*240 * (4бит на точку) и реализовать команды блитера.
Насчет спековского экрана как задника, тут проще и быстрее будет
кодеру напрограммить хоть 2, хоть 3 "игровых плана",
используя блитер нового экрана.
Black_Cat
30.04.2008, 18:02
Вероятно проще сразу делать нормальный (полно-функциональный)
новый экран, чем возиться со старым.
дык есть уже - в РС - "нормальный полнофункциональный" и главное уже не надо возиться со старым Спеком :v2_scare:
Vladimir Kladov
30.04.2008, 22:52
шиииироооокая и непрозрачная середина. И если на нее истрачены все цвета - хоть ты тресни, а на сглаживание кромок не остается.Там кромок-то две всего. Значит, 2х цветов достаточно. Уж как-нибудь в 16 цветов в строчку вписаться вполне можно. В любом случае это больше, чем 16 цветов на экран или даже на строчку экрана. И вообще, это не имеет значения, блиттером или спрайтом. Я не хочу заморачиваться с кучей всяких вариантов сжатий, это уже усложнение неоправданное для простого устройства. 16 цветов, но из кучи палитр. Это в любом случае решит и проблему сжатия, и разнообразия. Каждый пиксель экрана раскрасить своим уникальным цветом - это уже снобизм.
принципиальное отличие состоит в коренном ОГРАНИЧЕНИИ
я знаю прекрасно об этом ограничении и оно мне изначально не нравится. Но я хочу простое (хотя бы для целей эмуляции), экономное для целей реализации в железе и чтобы красиво было и удобно программировать. Если команды блиттеру помещать в память, думаю, будет так же удобно, как и для спрайтера. Набор команд мне кажется надо ограничить самыми примитивными пересылками с флипом по горизонтали и поворотами на 90 градусов, и без всякого аппаратного масштабирования. А вот альфа пригодилась бы в палитре как раз. Те же 16 цветов на точку, из одной из до кучи палитр.
Я всё-таки хочу оставить именно спековский экран+аппаратный сколл в качестве заднего плана. Можно и не использовать, но если использовать, то это очень экономичный режим, практически 1 пиксель на точку, и при правильном использовани атрибутов вона какие красявые картинки рисует народ. Можно на крайняк из двух экранов составлять, тот же флаш+брайт. Но с общим скроллом, и тогда никакого клэша на заднем плане.
Добавлено через 4 минуты
Кстати, по поводу раскраски. Тут к празднику говорят покажут Штирлица раскрашенного... Если кому интересно глянуть, как могла бы выглядеть графика на спеке, то мне кажется самым показательным knight lore в 256 режиме. Ну очень симпатяшный. Прочие раскрашенные игрульки меня как то не особенно тронули.
я вот смотрю все предлагают разные графические режимы для спека 320x240, 640x480,... Однако на мой взгляд графический режим у спека есть, вот чего спеку не хватает, так это текстового режима :D
Серьезно, читать тексты в режиме 4x8 пиксела, не очень-то комфортно :v2_wink2:
В нормальном текстовом режиме 80x25, с цветами, аппаратным знакогенератором с возможностью загрузки своих фонтов... вот что было бы классно :v2_wink2:
Lethargeek
01.05.2008, 03:45
Там кромок-то две всего. Значит, 2х цветов достаточно.
А вот и НЕТ! В одной кромке запросто может быть более одной точки. А в корявых спрайтах может быть и более двух кромок (например сечение человечка вполоборота: рука-туловище-рука, итого 6 кромок, это значит уж минус 6 цветов из 16 как минимум, а то и 8).
В любом случае это больше, чем 16 цветов на экран или даже на строчку экрана.
Но меньше, чем 32K цветов на экран.
На Спеке вон тоже как бы "15 цветов на строчку", а на самом деле?
И вообще, это не имеет значения, блиттером или спрайтом. Я не хочу заморачиваться с кучей всяких вариантов сжатий, это уже усложнение неоправданное для простого устройства.
То есть все аргументы чисто религиозные? Судя по отсутствию любых попыток более-менее подробно оценить (я уж не говорю - подробно просчитать) потенциально возникающие проблемы - так оно и есть.
16 цветов, но из кучи палитр.
Повторяю вопрос: где/как эта "куча палитр" будет храниться и связываться со спрайтами/бэкграундами?
Это только кажется, что все просто.
Это в любом случае решит и проблему сжатия, и разнообразия.
Голословное утверждение. Схема сжатия для спрайтов как минимум не проще таковой же для блиттера, при меньших возможностях.
Каждый пиксель экрана раскрасить своим уникальным цветом - это уже снобизм.
Не снобизм, а отсутствие ненужной головной боли для программиста.
Добавлено через 11 минут
Но я хочу простое (хотя бы для целей эмуляции), экономное для целей реализации в железе и чтобы красиво было и удобно программировать.
Ну, то что описывалось до сих пор - не имеет шансов стать таковым.
Если команды блиттеру помещать в память, думаю, будет так же удобно, как и для спрайтера.
Будет удобнее. :)
Набор команд мне кажется надо ограничить самыми примитивными пересылками с флипом по горизонтали и поворотами на 90 градусов, и без всякого аппаратного масштабирования.
Хороший пример того, что не стоит спешить с программными заявлениями без предварительного обдумывания. Например примитивное масштабирование без сглаживания (а-ля Doom) делается проще простого, всего лишь разрешением дробных приращений счетчиков адреса.
А вот альфа пригодилась бы в палитре как раз. Те же 16 цветов на точку, из одной из до кучи палитр.
Палитровая альфа годится только для эффектов типа полупрозрачного дыма. Да и то - тратить на это спрайты, которых и так немного... :rolleyes:
Про "кучу палитр" уже упоминал - несерьезно.
Я всё-таки хочу оставить именно спековский экран+аппаратный сколл в качестве заднего плана. Можно и не использовать, но если использовать, то это очень экономичный режим, практически 1 пиксель на точку,
Прежде всего стОит задать себе вопрос - ЧТО собираемся экономить ("если" :) использовать)?
Неэкономично иметь кучу режимов, пригодных только для одной какой-то задачи.
Добавлено через 19 минут
я вот смотрю все предлагают разные графические режимы для спека 320x240, 640x480,... Однако на мой взгляд графический режим у спека есть, вот чего спеку не хватает, так это текстового режима
Для любителей текстового режима например существует такая скучная хрень, как GMX. :v2_sleep: Проблема надумана, поскольку легко решается в рамках любого графического движка простым удвоением разрешения по горизонтали за счет цветности (в простейшем варианте это "кулибинский" режим 512x192) - и поддержу знакогенератора городить незачем.
Vladimir Kladov
01.05.2008, 10:15
чего спеку не хватает, так это текстового режимаА вот это неправда. Если режим монохромный для Пентагона и Таймекса, 512х??? (не помню вертикаль, кажется, 200 или 240).
Добавлено через 3 минуты
А в корявых спрайтах может быть и более двух кромок (например сечение человечка вполоборота: рука-туловище-рука
Ну, не корявых. Опять же в случае блиттера, кто мешает уменьшить число дырок и увеличить число выпуклых спрайтов за счёт разбивки корявого спрайта на части (рука отдельно, туловище отдельно). А в случае спрайтера, поверьте, вы не увидите особых ступенек внутри спрайта, чего-там просвечивает, и ладно. Опять же не вижу причины, почиму нельзя использовать тот же единственный цвет на полупрозрачность на все кромки, просто заплпнировать и туловище и руку одним цветом и всех делов.
Добавлено через 11 минут
где/как эта "куча палитр"
вот это я не знаю. Мне кажется, в памяти спека - нехорошо, даже если память используется видеопроцессором, блитеер он или спрайтер, полностью независимо. Просто из экономии имеет смысл сделать отдельное хранилище, а перегружать палитры в это хранилище каким-нибудь несложным способом. (Несложным - это важно). А из всех несложных способов самым несложным кажется мне дубляж памяти спека, когда после вывода в какой-то порт всё, что пишется в память спека, попадает в тень. Раз загрузили под завязку, дальше только переключаем наборы палитр в массиве (частями, как банки памяти), и юзаем до 256 одновременно разных палитр. 256х16 = 4096 разных цветов на экране, а если делать альфа-канал и разрешить смешивать их в разных пропорциях, то легко получается ещё хN, где N зависит отдискретности альфа-канала. Максиму х256, итого 64К разных цветов. Замечу, что это не то же, что режим 64К на ПЦ с его 5+6+5 битами на RGB. При желании можно получить (легко) плавнейший градиен по нужному оттенку цвета.
Добавлено через 15 минут
спековский экран+аппаратный сколл в качестве заднего плана. Можно и не использовать, но если использовать, то это очень экономичный режим, практически 1 пиксель на точку,
Прежде всего стОит задать себе вопрос - ЧТО собираемся экономить ("если" использовать)?
Неэкономично иметь кучу режимов, пригодных только для одной какой-то задачи.Этот режим уже есть, к нему просто добавляется скролл. Экономить - память спека. Кроме того, этот режим можно использовать сам по себе, например для плавной фреймовой прокрутки текстов.
Black_Cat
01.05.2008, 10:31
512х??? (не помню вертикаль, кажется, 200 или 240).не, обычный - 192
Vladimir Kladov
01.05.2008, 10:32
примитивное масштабирование без сглаживания (а-ля Doom) делается проще простого, всего лишь разрешением дробных приращенийЯ знаю, но это в любом случае усложнение, без которого можно (скрипя сердцем) обойтись.
Добавлено через 1 минуту
512х??? (не помню вертикаль, кажется, 200 или 240).
не, обычный - 192Да, именно, я ещё помню, в Таймексе есть такая возможность, переключить режим на обычный с нужной строки экрана, и получается, например - вверху графика, внизу текст или наоборот. Даже в паре адвенчур типа хоббита использовалось.
Добавлено через 3 минуты
существует такая скучная хрень, как GMXЯ кстати когда хотел реализовать ещё в старом EmuZWin, так и не нашёл достаточной документации на эту хрень, чтобы реализовать. Может из схемы что-то можно понять, но я схемы не читаю.
Vladimir Kladov
01.05.2008, 13:19
Вот набросок с учётом возможностей блиттера по сравнению со спрайтами-на-ходу. Тоже вполне простой. Сейчас вложу пдфку.
Здесь только о слое со спрайтами, задний слой - прежний экран спектрума 256х192, со скроллами по вертикали и горизонтали.
Ах, да, про гапы-то я совсем забыл. Перезагрузил пдфку ещё раз. Теперь вроде всё.
Только пдфку я положил себе на страницу, а здесь оставлю ссылку:
http://kolmck.net/zx/Blit-sprite-processor.rar
Буду экономить место на форуме. И заодно привёл пару графических примеров порядка вывода пикселей спрайтов в двух режимах.
Black_Cat
01.05.2008, 15:23
Может из схемы что-то можно понять, но я схемы не читаю.из схемы ничего понять нельзя, а создавать его с нуля никому не надо, дык что забудь про него
Vladimir Kladov
01.05.2008, 17:06
из схемы ничего понять нельзя
Ну я так и понял, что GMX умер...
Я тут обновил pdf-ку, дописал про задний план и команды, тайл, обрезка - кажется, это тоже минимумально необходимо (даже больше чем повороты и масштабирования). Пока все празднуют, я тут обдумывал. Кажется, в таком виде я бы без проблем вставил блит-спрайт-процессор в эмулятор. Осталось только оговорить номер порта, и что как выводить в него, чтобы им управлять. Так примерно прикинул: кажись, зуму вполне реализовать можно, разрешения 512х384 вполне хватит на то, чтобы приличное число шариков нарисовать. Мне в эмулятор и повороты с масштабирование всунуть нет проблем - опен гл всё за меня сам сделает... Ладно, я подожду обсуждения и новых пинков, а пока что-нибудь другое сделаю пойду, например, управления меню клавишами сильно не хватает.
http://kolmck.net/zx/Blit-sprite-processor.rar
Lethargeek
01.05.2008, 18:32
Ну, не корявых. Опять же в случае блиттера, кто мешает уменьшить число дырок и увеличить число выпуклых спрайтов за счёт разбивки корявого спрайта на части (рука отдельно, туловище отдельно).
Большинство реальных спрайтов - таки корявые. В случае блиттера редко понадобится разбивать спрайт на части (блиттер и так способен все дырки пропускать без остановок), скорее - по цветности (если количество цветов на конкретный упакованный объект не равно степени двойки). Ну и сглаживание границы - печатаем все кромки, именно столько пикселей, сколько нужно, с точной степенью полупрозрачности, без всяких подгонок и суррогатов.
А в случае спрайтера, поверьте, вы не увидите особых ступенек внутри спрайта, чего-там просвечивает, и ладно.
Я например гоняю снесовские игрушки - и порой очень заметно и сильно раздражает, даже видеофильтры не всегда спасают.
Опять же не вижу причины, почиму нельзя использовать тот же единственный цвет на полупрозрачность на все кромки, просто заплпнировать и туловище и руку одним цветом и всех делов.
А я может не хочу что-либо "планировать одним цветом"! Хочу забыть, как страшный сон, любую подгонку по цветам. Хватит с меня спектрумовских атрибутов!
Раз загрузили под завязку, дальше только переключаем наборы палитр в массиве (частями, как банки памяти), и юзаем до 256 одновременно разных палитр. 256х16 = 4096 разных цветов на экране, а если делать альфа-канал и разрешить смешивать их в разных пропорциях, то легко получается ещё хN, где N зависит отдискретности альфа-канала. Максиму х256, итого 64К разных цветов.
Ну вот, опять необязательные извращения и головная боль! К тому ж цветов получится куда меньше, многие палитры будут вообще отличаться всего одним-двумя цветами на реальных игрушках.
Замечу, что это не то же, что режим 64К на ПЦ с его 5+6+5 битами на RGB.
Вот и плохо.
Этот режим уже есть, к нему просто добавляется скролл. Экономить - память спека. Кроме того, этот режим можно использовать сам по себе, например для плавной фреймовой прокрутки текстов.
Не проще тогда внутреннюю память спека вообще не использовать для видео? (а я так понял, там еще и спрайты хранить предлагается) Вон только что предлагалось палитры в отдельную память вынести. Че за монструкция - куча несамостоятельных друг друга тормозящих узлов!
Я знаю, но это в любом случае усложнение, без которого можно (скрипя сердцем) обойтись.
Уж лучше тогда без спрайтов обойтись. И особенно от плавного их вращения - вот уж усложнение так усложнение!
Вот набросок с учётом возможностей блиттера по сравнению со спрайтами-на-ходу. Тоже вполне простой. Сейчас вложу пдфку.
Ой, мама. И это называется "спрайтовые движки удобно программируются"?
Че обсуждать - непонятно, поскольку по времянкам расчетов нет. Вообще не вижу смысла вставлять подобное в эмулятор при живом-то 256-color (спаять который и то реальнее по-настоящему, а в эмуле - больше пользы).
Нельзя на телек вывести больше 288 строк, если оставлять совместимость со старым эраном, и в ширь для подавляющего большества более 352-356 пикселей
при пиксель клоке 7МГц
Vladimir Kladov
01.05.2008, 19:54
Хочу забыть, как страшный сон, любую подгонку по цветам. Хватит с меня спектрумовских атрибутов!И спектрума - тоже? :) Нормальные атрибуты, чего такая нелюбовь. Цветов маловато, это да. Но напрямую все цвета задавать это тоже знаете ли - слишком круто. Потому я и решил, что 16 на строку спрайта - очень даже харашо, и даже не по сравнению с тем что было, а вообще - хорошо. Никто же (в случае блиттера) не запрещает широкий многоцветный спрайт поделить на несколько вертикальных полосок. Или если цветов недостаточно по ширине, но хватает по высоте, то можно его всегда рисовать повёрнутым на 90 градусов.
Добавлено через 2 минуты
Замечу, что это не то же, что режим 64К на ПЦ с его 5+6+5 битами на RGB.
Вот и плохо.Ни фига се неплохо. Вы этот 64К включите и просто перезагрузитесь под ХП. Есле у вас видно окно приветствия, вот там во всей красе видно (верхний левый угол) как оно неплохо.
Добавлено через 5 минут
Не проще тогда внутреннюю память спека вообще не использовать для видео? (а я так понял, там еще и спрайты хранить предлагается) Вон только что предлагалось палитры в отдельную память вынести.
я же говрю - теневой дубль банков спектрума, которые сейчас не задействованы под видео, делется автоматом. Палитры в отдельную память я предполагал таким же макаром засовывать. Но там это процедура получается одноразовая, т.к. все банки в которые записаны активные палитры сразу же становятся недоступны для дубляжа, и после этого их можно переиспользовать для своей надобности, в видеопамяти они уже не изменятся.
Скажите, народ, кто в схемотехнике рубит: я гоню или это нормальный ход?
Добавлено через 7 минут
Уж лучше тогда без спрайтов обойтись. И особенно от плавного их вращения - вот уж усложнение так усложнение!
Я с самого начала говорю, что это будет усложнение. В описани выделено красным цветом, поддерживать необязательно. Делается так, что если этот режим включается, блиттер пропускает байты вращения/масштаба, и рисует 1:1. Частично может прокатить даже если игруля будет написана с расчётом на вращение/масштабирование.
Добавлено через 9 минут
это называется "спрайтовые движки удобноОчень удобно. Спрайт задаётся один раз. Таблица вывода может строиться на каждом кадре, или только модифицироваться, если число объектов не меняется, а только они двигаются. Что сложного?
Добавлено через 15 минут
Нельзя на телек вывести больше 288 строк, если оставлять совместимость со старым эраном, и в ширь для подавляющего большества более 352-356 пикселей
при пиксель клоке 7МГцРазве у видеопроцессора, прилаженного сбоку не может быть своя частота вывода? Разве у нас только телевизор (который скоро умрёт, в связи с переходом на цифру)? У меня новый телек на кухне стоит, автомобильный, уже плоский, и 640х480 видео понимает, может как моник работать.
Кроме того, есть такая штука как ресамплинг. Внутреннее изображение 512х384 ресамплится до нужного масштаба уже на этапе вывода, и все дела. Заодно и углы сгладятся.
Просто я оптимист :)
Lethargeek
02.05.2008, 03:33
Но напрямую все цвета задавать это тоже знаете ли - слишком круто. Потому я и решил, что 16 на строку спрайта - очень даже харашо, и даже не по сравнению с тем что было, а вообще - хорошо.
БЫЛО круто. Лет 15 тому назад. А сейчас это уже даже не "хорошо", а просто убого.
Никто же (в случае блиттера) не запрещает широкий многоцветный спрайт поделить на несколько вертикальных полосок. Или если цветов недостаточно по ширине, но хватает по высоте, то можно его всегда рисовать повёрнутым на 90 градусов.
Да начхать мне с блиттером на всякие "полоски", когда я могу накладывать друг на друга изображения любой формы и цветности ("палитра объекта" в этом случае - просто ключ для разворачивания упакованных цветов в hicolor).
Судя по прилагаемому пдфу - что такое блиттер, до сих пор не понятно? В первых же строках описатель спрайта почему-то называется "командой блиттера" :) Да и все остальное никакого отношения к блиттеру не имеет!
БЛИТТЕР всего лишь осуществляет условные статичекие переброски память-память с параметрами "куда, откуда, сколько, как" - к раскладке экрана и временным параметрам кадра блитер никак не привязан! СПРАЙТЕР же осуществляет динамическую переброску память-буфер (отображаемой строки) и последующий выбор из нескольких точек (или их смешивание) для отображения. Почувствуйте разницу.
Есс-но и блиттер, и спрайтер стремятся использовать для своих надобностей одни и те же циклы видеопамяти, и потому друг с другом уживаются плохо!
Ни фига се неплохо. Вы этот 64К включите и просто перезагрузитесь под ХП. Есле у вас видно окно приветствия, вот там во всей красе видно (верхний левый угол) как оно неплохо.
Меня вообще-то виндовозные глюки мало волнуют.
Прямой цвет для программирования однозначно удобнее.
я же говрю - теневой дубль банков спектрума, которые сейчас не задействованы под видео, делется автоматом. Палитры в отдельную память я предполагал таким же макаром засовывать.
И зачем это надо, еще какая-то отдельная память (к тому же большей частью простаивающая). Это как минимум лишние ноги плис, если в железе.
Очень удобно. Спрайт задаётся один раз. Таблица вывода может строиться на каждом кадре, или только модифицироваться, если число объектов не меняется, а только они двигаются. Что сложного?
Ну только если "задается один раз на весь эпизод" :)
Почему?
За время отображения текущей строки можно прочитать (чтобы подготовить для отображения следующей) только определенное количество пикселей (и еще оставить время, как минимум достаточное для доступа Z80 к старому экрану). Если спрайты переменной ширины - значит, нужно разделить это кол-во между спрайтами. Сделать это можно только одним способом - читать поочередно по одному пикселю из каждого спрайта, сколько успеем. Что не успели - обрежется. И чтобы ничего не резалось, надо обдумывать габариты всех используемых спрайтов заранее - иначе при любом движении хотя бы одного спрайта по вертикали возникает риск испортить картинку! И что теперь? Программисту вручную проверять, что ли, суммарную ширину спрайтов по всем изменившимся строкам отображения? И что собс-но делать, когда выявлено превышение лимита?
Отсюда выводы:
1) От строк различной ширины у одного спрайта толку мало. Достаточно задать ширину всего спрайта.
2) (следствие из п.1) Отступ слева не нужен - слишком маленькая экономия, да и то непонятно зачем.
3) Скорее всего ограничение "N спрайтов суммарной шириной W на одну строку" на практике будет относиться уже не к строке, а ко всему "игровому полю". Иначе бедный кодер замается на ходу считать допуски (и так уже ни о какой "простоте" речи не идет).
4) (следствие из п.3) Движок крайне неэффективен, поскольку доступные циклы видеопамяти (при довольно больших требованиях к ее скорости) большую часть кадра реально использоваться не будут - теряем в качестве непонятно ради чего.
Кроме того, спрайты не только двигаются, но и кадры анимации переключаются.
Разве у видеопроцессора, прилаженного сбоку не может быть своя частота вывода? Разве у нас только телевизор (который скоро умрёт, в связи с переходом на цифру)? У меня новый телек на кухне стоит, автомобильный, уже плоский, и 640х480 видео понимает, может как моник работать.
Чем больше разрешение (след-но пиксельклок), тем быстрее потребуется память, тем меньше времени (хуже, чем просто пропорционально увеличению площади типового объекта) на полезную работу с графикой.
Кроме того, есть такая штука как ресамплинг. Внутреннее изображение 512х384 ресамплится до нужного масштаба уже на этапе вывода, и все дела. Заодно и углы сгладятся.
А толку? "Внутреннее изображение" все равно придется читать в полном объеме! Поэтому вышеперечисленные проблемы останутся. Только лишний узел городить непонятно зачем - уж лучше просто иметь больше цветов (получаемых по желанию напрямую - а не через задницу в результате ресамплинга) на меньшем разрешении.
Просто я оптимист
А я - скептик. И потому большинство возможных проблем замечаю издалека. :p
Vladimir Kladov
02.05.2008, 08:30
Да начхать мне с блиттером на всякие "полоски"Именно с блиттером - полоски нужны. Вы вообще читали изложенное? Там - блиттер. Спрайты копируются командами во внутренний буфер видеопамяти и уже из этой видеопамяти выводятся, смешиваясь с задним планом.
Меня вообще-то виндовозные глюки мало волнуют.
Прямой цвет для программирования однозначно удобнее.
Винда тут ни при чём. 64К цветов в формате R5G6B5 для градиента - это очень мало и очень плохо.
БЛИТТЕР всего лишь осуществляет условные статичекие переброски память-память с параметрами "куда, откуда, сколько, как" - к раскладке экрана и временным параметрам кадра блитер никак не привязан! СПРАЙТЕР же осуществляет динамическую переброску память-буфер (отображаемой строки) и последующий выбор из нескольких точек (или их смешивание) для отображения. Почувствуйте разницу.Не чувствую. Переброски они и есть переброски. Они должны быть выполнены в течение кадра, последовательно, одна за другой. Если не успели, фигня получится, кадр не успел построиться. Я называю прямокгольники спрайтами, вы их не называете спрайтами, но результат-то тот же.
только если "задается один раз на весь эпизод"Спрайты задаются один раз на всю игру. В моём представленном последним варианте 256 спрайтов собираются из 4 банков спрайтов, и в любой момент можно указать в качестве любого банка любой набор спрайтов, т.е. общее их количество ограничено только фантазией автора. Если подумать, то можно сделать команду переключения банков спрайтов прямо в последовательности команд, и тогда число разных спрайтов на кадре так же легко преодолевает границу 256. (Я просто ещё не подумал).
И зачем это надо, еще какая-то отдельная памятьВы сами себе противоречите. Блиттер и строится на большом количестве отдельной памяти. Даже для того чтобы просто сохранить кадр, построенный блиттером, нужно порядка 500х300х4=600000 байт. По-моему, добавить к 600К ещё 128К для затенения всей памяти спектрума - это очень дешевое и простое решение. Блиттер весь работает в своей памяти. Когда я говорю память спектрума я подразумеваю, затенённая блиттером копия памяти спека.
От строк различной ширины у одного спрайта толку мало.Толк есть, и он не только в количестве хранимых данных, но и в количестве читаемых блиттером данных, а значит, и в скорости построения кадра. Просто удваивает количество спрайтов, которые можно за кадр блитнуть, спрайты это или части спрайтов, уже не суть.
И потому большинство возможных проблем замечаю издалека.
Не убедительно: не вижу ни одной проблемы из перечисленных. Кроме сложности самого устройства. Проэмулировать его, наверняка легче чем воплотить в железо.
Даже для того чтобы просто сохранить кадр, построенный блиттером, нужно порядка 500х300х4=600000 байт.
Допустим память 32 бита то 500*300*60 = 9000000 циклов чтений в секунду, не многовато ли только для вывода картинки?
Не проще ли 320х240х16 при 16 битной памяти 320*240*60= 4608000, меньше памяти (75килослов), меньше заполнять.
Допустим берем память 28МГцх32бита - 28000000/500*300*60=3.1 память позволяет прокачать 3.1 экрана за фрейм, 28000000(16бит)/320*240*60=6
То есть при Вашем разрешении 30% полосы памяти уходит только на вывод картики. Если брать блитер который к примеру заниается перекидыванием непожатой графики то получается что за один фрейм можно только 1 раз заполнить весть кадр графикой (то есть перекрытия при насыщеной картнике уже трудно делать)
Толк есть, и он не только в количестве хранимых данных, но и в количестве читаемых блиттером данных, а значит, и в скорости построения кадра.
А что блитеру мешает читать именно необходимый кусок? То есть есть спрайт 16х16, на экран влазит только 6х6, щитается элементарно какой кусок нада выводить.
Спрайты задаются один раз на всю игру. В моём представленном последним варианте 256 спрайтов собираются из 4 банков спрайтов, и в любой момент можно указать в качестве любого банка любой набор спрайтов, т.е. общее их количество ограничено только фантазией автора.
Чем больше спрайтов на экране тем больше процом щитать нада что бы не нарваться на превышение спрайтов на строку
Там - блиттер. Спрайты копируются командами во внутренний буфер видеопамяти и уже из этой видеопамяти выводятся, смешиваясь с задним планом.
А почему их сразу нельзя выводить на экран, делаем 2 экрана, основной и теневой, в некоторых играх можно и одним отмазаться с небольшой аппаратной поддержкой, делаем что блитер не может выводить графику ниже луча развертки, и подаем ему отрисовку сверху вниз.
Vladimir Kladov
02.05.2008, 12:49
Трудно здесь что-то конкретное цитировать, но вот что скажу (2hero). Если скорости недостаточно, никто не мешает 1. юзать прежнее разрешение 256х192, а четвёрки пикселей строк спрайтов с двойным разрешением просто усреднять в один пиксель.
2. Можно оптимизировать достаточно легко, для спрайтов однократного разрешения заполняя не четвёрки пикселей, а один пиксель, помечая его в 4-м байте флажком. (У нас в целевом экране реально нужен только R8G8B8, а четвёртый байт совершенно не используется). И тогда при чтении, если первый в четвёрке пиксель содержит такой флаг, то количество чтений уменьшается тоже (правда, уже не вчетверо, а вдвое).
Добавил: хотя нет, альфа-то нужна, но 1 битик оторвать от неё можно (младший), просто градаций уменьшится с 256 до 128. И опять же только если скорости не хватит.
на экран влазит только 6х6, щитается элементарно какой кусок нада выводить.
Странно, а где-то сказал, что все пиксели должны пересылаться? А для чего я тогда об обрезке в спецификации написал, для красного словца, что ли?
делаем что блитер не может выводить графику ниже луча развертки, и подаем ему отрисовку сверху вниз.
Вот пусть Lethargeek объяснит, мну уже понял, что блиттер - это не спрайтер. :)
Lethargeek
02.05.2008, 16:31
Именно с блиттером - полоски нужны. Вы вообще читали изложенное? Там - блиттер. Спрайты копируются командами во внутренний буфер видеопамяти и уже из этой видеопамяти выводятся, смешиваясь с задним планом.
...мну уже понял, что блиттер - это не спрайтер.
Так "уже понял" или "не понял"? Между ними разница, как в банке между "перечислением денег со счет на счет" и "получением налички со счета". :)
Винда тут ни при чём. 64К цветов в формате R5G6B5 для градиента - это очень мало и очень плохо.
Подумаешь, нельзя что ли размытый паттерн использовать (и вместо 5:6:5 уж лучше 5+:5+:5+, выглядит почти как 6:6:6)? Градиент - не такая важная проблема, чтобы ее решение порождало кучу других проблем.
А 24-битный ЦАП на выходе вместо 15/18-битного между прочим тоже не даром достается.
Не чувствую. Переброски они и есть переброски. Они должны быть выполнены в течение кадра, последовательно, одна за другой. Если не успели, фигня получится, кадр не успел построиться. Я называю прямокгольники спрайтами, вы их не называете спрайтами, но результат-то тот же.
Учим матчасть - результат не тот же. Блиттер рисует в буфер, и может пропустить кадров сколько угодно, старый-то кадр никуда не делся! А вот спрайтер действительно должен все успевать.
Спрайты задаются один раз на всю игру. В моём представленном последним варианте 256 спрайтов собираются из 4 банков спрайтов, и в любой момент можно указать в качестве любого банка любой набор спрайтов, т.е. общее их количество ограничено только фантазией автора.
Да при чем тут количество? Я про соотношение габаритов всех спрайтов, которые могут оказаться одновременно в кадре!
Вы сами себе противоречите. Блиттер и строится на большом количестве отдельной памяти.
Кто противоречит? :v2_wacko:
Не я же предлагал к отдельной внешней "памяти спрайтов и задников" ЕЩЕ какую-то отдельную "память палитр"!
Даже для того чтобы просто сохранить кадр, построенный блиттером, нужно порядка 500х300х4=600000 байт.
Вообще-то бит, а не байт. :D
Странные разрешения фтопку, а под буфер требуется не больше, чем занимает игровое поле (всякие менюшки и панели побоку). Весь кадр сохранять не нужно, просто переключаем аппаратное окошко нужного размера на другой начальный адрес видеопамяти. Например окно 256x192x16 это всего 96K. А упакованная графика, которой заполняется этот буфер, занимает в разы меньше при той же площади.
Толк есть, и он не только в количестве хранимых данных, но и в количестве читаемых блиттером данных, а значит, и в скорости построения кадра. Просто удваивает количество спрайтов, которые можно за кадр блитнуть, спрайты это или части спрайтов, уже не суть.
Во-превых, опять-таки, никаким блиттером тут и не пахнет, а во-вторых, "скорость построения кадра" у спрайтовых движков постоянна и жестко привязана к развертке! Все такты, которые не были использованы на чтение спрайта в строке - просто пропали зря!
Главная проблема спрайтового движка - низкий КПД.
Не убедительно: не вижу ни одной проблемы из перечисленных.
Потому что вместо расчетов (основанных на понимании принципов работы графдвижков) - одни благие пожелания.
Кроме сложности самого устройства. Проэмулировать его, наверняка легче чем воплотить в железо.
Кто бы сомневался. :rolleyes:
Вот только помимо очевидных "железных" проблем у кодера тоже будет забот полно.
Добавлено через 28 минут
Трудно здесь что-то конкретное цитировать, но вот что скажу (2hero). Если скорости недостаточно, никто не мешает 1. юзать прежнее разрешение 256х192, а четвёрки пикселей строк спрайтов с двойным разрешением просто усреднять в один пиксель.
Толку от этого нуль, поскольку придется читать все те же 4 пикселя!
2. Можно оптимизировать достаточно легко, для спрайтов однократного разрешения заполняя не четвёрки пикселей, а один пиксель, помечая его в 4-м байте флажком. (У нас в целевом экране реально нужен только R8G8B8, а четвёртый байт совершенно не используется). И тогда при чтении, если первый в четвёрке пиксель содержит такой флаг, то количество чтений уменьшается тоже (правда, уже не вчетверо, а вдвое).
Ну и получим вдвое меньше пикселей спрайтов на строку, то ж на то ж и выйдет. Особенно если проблему чтения задника решить тем же способом. Типо скандаблер. :D
Странно, а где-то сказал, что все пиксели должны пересылаться? А для чего я тогда об обрезке в спецификации написал, для красного словца, что ли?
В спрайтовых движках время нельзя толком экономить, его можно только тратить! Нельзя с уверенностью использовать пропущенные (из-за обрезки и гапов) циклы чтения для вывода других спрайтов, поскольку нет гарантии, что таковые циклы всегда найдутся!
Еще раз: проблему подгонки размеров спрайтов придется решать заранее для целого эпизода (эпизод - времЕнной отрезок с закрытым фиксированным набором потенциально используемых спрайтов). Потому что делать это по мере возникновения проблем - мартышкин труд. А "решать заранее" - это значит вводить искусственные ограничения изначально, и КПД движка на практике получится еще ниже.
(придется видимо пример рисовать)
Vladimir Kladov
02.05.2008, 17:25
Учим матчасть - результат не тот же. Блиттер рисует в буфер, и может пропустить кадров сколько угодно, старый-то кадр никуда не делся! А вот спрайтер действительно должен все успевать.Ага, ага, а потом твой герой заходит в комнату набитую предметами, и всё замедляется впятеро. То, что в буфер, я сразу понял, я не идиот безмозглый. Фразу "учим матчасть" следует применять по назначению. Была бы матчасть, было бы что и учить. А так её самому приходится на ходу придумывать.
64К цветов в формате R5G6B5 для градиента - это очень мало и очень плохо.
Подумаешь, нельзя что ли размытый паттерн использовать
Убожество с крапинками разного цвета? Это ещё можно стерпеть на экране 1024х768, когда размер точки 0,2 мм, но когда она 2-3 мм - извините.
при чем тут количество? Я про соотношение габаритовКоличество при том, что полноценный спрайт может составляться из многих мелких кусков (рука, нога, отдельно ладонь руки, сжатая, разжатая, в перчатке, рот улыбается, открыт, закрыт, брови туда-сюда ходят, шляпа подпрыгивает, шнурок на ботинке развязался...). Тогда 256 мелких спрайтиков на один кадр может не хватит.
Не я же предлагал к отдельной внешней "памяти спрайтов и задников" ЕЩЕ какую-то отдельную "память палитр"!
Мои пардоны, но вы пока ничего не предлагали, кроме блиттера вместо спрайтера-на-ходу, а теперь, когда я предложение оценил и принял, поносите меня по самое не могу, даже не пытаясь понять, что то, что предложено, блиттер и есть. Или мне надо начинать расписывать подробно всю схему работы, что в какой порт пишется, на какой строке луча какие байты куда считываются? Опять мои пардоны, но мне в такую подробную детализацию на этапе обсуждения соваться не интересно. Мне достаточно того, что изложено, для целей эмуляции. А там уже и посмотреть можно.
порядка 500х300х4=600000 байт.
Вообще-то бит, а не байт.Байт, однако. х4 означает 4 байта на хранение полной цветовой информации и альфы на каждый пиксель.
опять-таки, никаким блиттером тут и не пахнетХотите оскорблений? Получите. Прочитайте уже текст, он у меня на сайте выложен, ссылка была выше.
а четвёрки пикселей строк спрайтов с двойным разрешением просто усреднять в один пиксель.
Толку от этого нуль, поскольку придется читать все те же 4 пикселя!
Да, целых два байта. Это на этапе блиттинга. А на этапе развертки - один.
А упакованная графика, которой заполняется этот буфер, занимает в разы меньше при той же площади.
Я не знаю и знать не хочу, что такое упакованная графика. Количество операций для блиттера она не уменьшит, а усложнить его сможет в разы. 16 цветов на точку и баста. Дальше всё варьируется палитрами, наложением спрайтов с альфой, и этого хватит на всё.
Lethargeek
02.05.2008, 19:53
Ага, ага, а потом твой герой заходит в комнату набитую предметами, и всё замедляется впятеро.
С буфером-то я по крайней мере увижу эти предметы - в отличие от спрайтового мельтешения кучи огрызков. :p К тому же всегда можно уменьшить плавность анимации, не изменяя скорости игры. А еще необязательно обновлять ВЕСЬ буфер, можно только изменившиеся участки (сие воэможно как раз потому что цвет прямой, и не нужно в кадре динамически палитры переключать при переходе от предмета к фону или другому предмету).
Убожество с крапинками разного цвета? Это ещё можно стерпеть на экране 1024х768, когда размер точки 0,2 мм, но когда она 2-3 мм - извините.
На снесах вовсю юзали даже неразмытые градиенты на 15 бит - и ничего. Тем более почти одноцветные крапинки еще хрен заметишь, в отличие от тех же контрастных кромок типа "темное на светлом".
Количество при том, что полноценный спрайт может составляться из многих мелких кусков (рука, нога, отдельно ладонь руки, сжатая, разжатая, в перчатке, рот улыбается, открыт, закрыт, брови туда-сюда ходят, шляпа подпрыгивает, шнурок на ботинке развязался...). Тогда 256 мелких спрайтиков на один кадр может не хватит.
Вот радость-то кодеру с ними возиться! Не говоря уж о том, что куча спрайтов - это в железе куча регистров и муксов. И дело не в кусках, коренное ограничение на суммарную ширину при этом никуда не девается, а только усугубляется.
Мои пардоны, но вы пока ничего не предлагали, кроме блиттера вместо спрайтера-на-ходу, а теперь, когда я предложение оценил и принял,
Не "оценил" (потому что не понял и желания понять НЕТ, как я вижу). Следствие - "принял" неизвестно что.
А я прежде всего отвечал на провокационные заявления в начале темы.
Или мне надо начинать расписывать подробно всю схему работы, что в какой порт пишется, на какой строке луча какие байты куда считываются? Опять мои пардоны, но мне в такую подробную детализацию на этапе обсуждения соваться не интересно.
Это не детали, а предпосылки. :p
Мне достаточно того, что изложено, для целей эмуляции. А там уже и посмотреть можно.
Зачем эмулировать неудобный в использовании (про железные проблемы молчу) девайс?
Байт, однако. х4 означает 4 байта на хранение полной цветовой информации и альфы на каждый пиксель.
Вообще-то альфа в буфере нафиг не нужна (требуется временно только на этапе копирования в буфер).
А 24-битный прямой цвет нафиг не нужен исходя из характеристик доступной элементной базы. 24-битный палитровый - вообще никогда нафиг не нужен, цветов на экране слишком мало, чтобы заметить разницу с 16-битным.
поносите меня по самое не могу, даже не пытаясь понять, что то, что предложено, блиттер и есть.
Хотите оскорблений? Получите. Прочитайте уже текст, он у меня на сайте выложен, ссылка была выше.
Да оскорбляйте себя (из-за собственных упрямства и лени) сколько угодно, мне пофиг.
Текст я естественно прочитал сразу же. Выводы:
1. Блиттером там и не пахнет
2. Блиттером в тексте обозвано неизвестно что
3. Если корову обозвать лошадью - лошадью она от этого не станет
4. Учить матчасть наконец! (а конкретно что такое блиттер на самом деле)
Да, целых два байта. Это на этапе блиттинга. А на этапе развертки - один.
Этап развертки выполняется схемой (заведомо быстрее чтения из памяти) и на характеристики движка никак не влияет.
Я не знаю и знать не хочу, что такое упакованная графика. Количество операций для блиттера она не уменьшит,
Еще как уменьшит. Упаковка применяется по двум направлениям:
1) Сжатие цвета. 1-2-4-8-битные "пиксели" из пожатого объекта пересчитываются в прямой 16-битный цвет по таблице. Для "однобитных" объектов получится почти в два раза быстрее. Для "8-битных" - в полтора. Таблица - та же палитра, но (в отличие от спрайтовых палитр) одномоментно нужно лишь одну сохранять (несколько - по желанию, для удобства). Альфа-канал (когда нужен) можно пустить отдельным потоком, никак не теряя в цветности.
2) Пропуск "полностью прозрачных" точек при переброске - значит, для типового спрайта еще где-то на треть быстрее, в дополнение к п.1
Итого для переброски "среднего" 8-битного спрайта где-то в два раза.
Упаковка - вещь однократная, дальше кодер просто юзает эти объекты, как хочет.
16 цветов на точку и баста. Дальше всё варьируется палитрами, наложением спрайтов с альфой, и этого хватит на всё.
Этого хватит только на геморрой для кодера. Зачем ему необязательные заморочки, когда перспективы появиться в железе у такого мегамонстра околонулевые, а в эмуляторе уже есть режим 256c и турба?
Проблема надумана, поскольку легко решается в рамках любого графического движка простым удвоением разрешения по горизонтали за счет цветности (в простейшем варианте это "кулибинский" режим 512x192) - и поддержу знакогенератора городить незачем.
в том-то и вся суть, что не решается - проц будет сильно загружен рисуя буквы, а так, чтобы вывести символ нужно всего то записать один байт в нужную ячейку и все! остальное время проца можно тратить на чтото полезное :v2_wink2:
возможно для статичной картинки это не очевидно, но возьмем для примера текстовый редактор. Как с этим справится z80 с графическим режимом? ;)
Lethargeek
03.05.2008, 13:50
в том-то и вся суть, что не решается - проц будет сильно загружен рисуя буквы,
Одну-то строчку подрисовывать для аппаратной прокрутки?
а так, чтобы вывести символ нужно всего то записать один байт в нужную ячейку и все! остальное время проца можно тратить на чтото полезное
Что-нибудь полезное - это неограниченный шрифт вместо жалких 256 букавок.
возможно для статичной картинки это не очевидно, но возьмем для примера текстовый редактор. Как с этим справится z80 с графическим режимом?
Всяко быстрее, чем тюкающий по клавишам юзверь.
Тут фреймовость вообще не нужна.
Все вышесказанное - еще без учета аппаратного ускорения вывода. Буквы в принципе ничем от обычных блоков (или тайлов в случае спрайтайлового движка) не отличаются.
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot