Важная информация

User Tag List

Страница 1 из 9 12345 ... ПоследняяПоследняя
Показано с 1 по 10 из 85

Тема: Зачем всё делать плоским? (Опять о спрайтах)

  1. #1
    Master Аватар для Vladimir Kladov
    Регистрация
    09.02.2005
    Адрес
    Новосибирск
    Сообщений
    933
    Спасибо Благодарностей отдано 
    0
    Спасибо Благодарностей получено 
    17
    Поблагодарили
    17 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию Зачем всё делать плоским? (Опять о спрайтах)

    Я всё-таки не пониамю (вот так пусть и остаётся - не пониамю), почему все придумывая новые концепции видеоотображения оставляют плоский экран? Ну, отбросив нехватку памяти (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, выполнить дешёвую плату сопряжения, и дальше пытаться что-то под неё запрограммировать. Сразу же обнаружится, что программить некому, и нечего, и это опять монстростроение (в том смысле, что девайс к спеку оказывается дороже его самого). Вообще, мне интересно, что железячный народ скажет в плане реализуемости описанного мною выше сюжета. (Ну на своём новом эмуляторе, я бы взялся его проэмулировать, жаль, паяльник мне не друг - в самом широком смысле, в том числе в плане проектирования ПЛМ )
    Последнюю версию EmuZWin (2.7) можно получить по этой ссылке, а "официальная" страница с описанием здесь. Если что-то не пашет, берите там же версии 2.6 или старше. [B]

  2. #1
    С любовью к вам, Yandex.Direct
    Размещение рекламы на форуме способствует его дальнейшему развитию

  3. #2

  4. #3
    Member Аватар для cyrax inc
    Регистрация
    24.09.2006
    Адрес
    Саратов
    Сообщений
    99
    Спасибо Благодарностей отдано 
    0
    Спасибо Благодарностей получено 
    0
    Поблагодарили
    0 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    как-то не проглядываются особые преимущества описанной идеи. сложности (по сравнению со спрайтовой структурой) по растасовке объектов по экрану перекладываются на плечи программиста, а насчет экономии памяти за счет битов прозрачности - тут бабушка надвое сказала: вполне реальны ситуации, когда затраты будут бОльшими.
    да, для чего это "Зачем всё делать плоским?", "плоский экран"? как ни крути-верти, а оно как было плоским, так и останется, независимо от структуры. и как решается в данном случае с "кем и что программировать"?
    この悲しみは何時かきっと優しさに成る
    貴方に逢えた丘の上星が降る
    -------------------------------------------------
    Критик - человек, рассуждающий о том, как бы правильно сделал он сам... если бы умел.
    -------------------------------------------------
    Sony PS2 SCPH-70008 et Sony PS3 Eur 2.10

  5. #4
    Banned Аватар для Black_Cat
    Регистрация
    15.06.2006
    Адрес
    S.Pb
    Сообщений
    5,791
    Спасибо Благодарностей отдано 
    0
    Спасибо Благодарностей получено 
    6
    Поблагодарили
    6 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Vladimir Kladov Посмотреть сообщение
    Почему нельзя было такую элементарщину реализовать ещё в 95 году?
    потому что под эту "элементарщину" нужен отдельный программируемый видеопроцессор (читай - либо микрокомпьютер, либо что-то а-ля v9990), а не простой конечный автомат а-ля сканер, который можно реализовать в ПЛИС или даже на логике. В случае создания этого чуда на FPGA - это будет не дешевле разработки с нуля чего-то типа v9990, а в случае эмуляции с помощью стандартного микропроцессора - это потребует высоких тактовых частот, со всеми вытекающими из этого технологическими трудностями выливающимися в дикую цену платы при мелкосерийном производстве (например четырёхслойка 140х105 мм обходится в ~100$/шт.) А в 95м это обходилось бы в десятки раз дороже, для примера можно взять Спринтер и оценить стоимость разработки конструкции на FPGA -> ~10000$, а про платы способные работать на частотах 200МГц и говорить тогда не приходилось, не говоря уже об доступности таких процессоров. Щас конечно всё дико подешевело, но тем не менее это будет не так уж и дёшево, а учитывая что это фактически будет новый компьютер, не имеющий ничего общего со Спеком, то к тому-же ещё и непонятно кому это нужно.
    Вот учитывая эти соображения и приходится идти на компромис между сложностью конструкции, технологичнескими, ценовыми и маркетинговыми ограничениями. В этом плане есть достаточно сбалансированная по всем критериям конструкция Летаргика, и это предел сегодняшних возможностей растровой графики для Спектрума.

  6. #5
    Guru Аватар для Lethargeek
    Регистрация
    08.09.2005
    Адрес
    Воронеж
    Сообщений
    4,533
    Записей в дневнике
    3
    Спасибо Благодарностей отдано 
    264
    Спасибо Благодарностей получено 
    208
    Поблагодарили
    166 сообщений
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Vladimir Kladov
    если отбросить пробему совместимости (нет такой проблемы, потому что переделывать всё равно придётся оченно глЫбоко, и это практически то же, что написать заново - тогда о чём говорить). И отбросить узость и плокость мышления.
    Цитата Сообщение от Vladimir Kladov
    Ну и как? Почему нельзя было такую элементарщину реализовать ещё в 95 году? Плоское мышление и гигантизм, стремление за какой-то гипотетической совместимостью.
    Как раз в 95 "о совместимости" походу никто не задумывался. Все ваяли "рабочие коммерческие" режимы, кое-кто дендюк спрайтовый прикручивал. И где тонны "глЫбоких переделок" под эти новации?

    Цитата Сообщение от Vladimir Kladov
    Такой режим, когда каждая плоскость независимо аппаратно скроллится куда угодно, чрезвычайно интересен для гейм-мэйкинга.
    Узость мЫшления. Для гейм-мейкинга со времен NeoGeo "чрезвычайно интересно аппаратно скроллировать" независимые объекты, а не плоскости целиком.

    Цитата Сообщение от Vladimir Kladov
    КТО СКАЗАЛ, ЧТО ОНИ ОБЯЗАНЫ БЫТЬ КВАДРАТНЫМИ?
    Узость мЫшления. Кто сказал, что они обязаны БЫТЬ?

    Цитата Сообщение от Vladimir Kladov
    (т.е. если в совокупности спрайт - это несколько цветных линий, то каждая линия может быть раскрашена своей палитрой, из того же общего набора палитр по 16 цветов на палитру).
    Что с точки зрения железа (в сочетании с требованием "неквадратности") означает не "N линий одного спрайта", а "N фактически разных спрайтов". А это уже две БОЛЬШИЕ разницы.

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

    Цитата Сообщение от Vladimir Kladov
    Рисование экрана (точнее перерисовка) сводится к построению новой таблицы разметки, что наверняка будет быстрее, чем все пиксели самому на экран перебрасывать любыми изощрёнными приёмами.
    Самому-то зачем? (Кстати зачем вообще общая память для графики и Z80?) Да и список заданий на тупое копирование объектов ничем (кроме большей простоты для програмера) от упомянутой таблицы не отличается.

    Цитата Сообщение от Black_Cat
    и это предел сегодняшних возможностей растровой графики для Спектрума.
    Ну вообще-то совсем уже не "предел", поскольку ПЛИСы все толстеют и дешевеют (причем слабые модели снимаются с производства). А про идеальный двухмерный движок я выше писал. Совместимость в такую схему можно по-разному прикрутить, и цена ее поддержки ничтожная по сравнению с основным движком.
    Последний раз редактировалось Lethargeek; 23.04.2008 в 15:32.
    Прихожу без разрешения, сею смерть и разрушение...

  7. #6
    Master Аватар для Vladimir Kladov
    Регистрация
    09.02.2005
    Адрес
    Новосибирск
    Сообщений
    933
    Спасибо Благодарностей отдано 
    0
    Спасибо Благодарностей получено 
    17
    Поблагодарили
    17 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Под плоским я понимаю вот что. Всё изображение представляет собой неподвижную матрицу 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 минут
    Я прекрасно понимаю, что это малореально было ТОГДА. Хотя бы потому, что своих игрушек в те времена у нас практически (и теоретически) не было (да и сейчас по пальцам). Демки были, а игрушек - не было. Я просто пытаюсь понять, насколько такой спрайт-режим реален СЕЙЧАС, и что конкретно для этого требуется.
    Последний раз редактировалось Vladimir Kladov; 23.04.2008 в 15:32. Причина: Добавлено сообщение
    Последнюю версию EmuZWin (2.7) можно получить по этой ссылке, а "официальная" страница с описанием здесь. Если что-то не пашет, берите там же версии 2.6 или старше. [B]

  8. #7
    Banned Аватар для Black_Cat
    Регистрация
    15.06.2006
    Адрес
    S.Pb
    Сообщений
    5,791
    Спасибо Благодарностей отдано 
    0
    Спасибо Благодарностей получено 
    6
    Поблагодарили
    6 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Vladimir Kladov Посмотреть сообщение
    Я просто пытаюсь понять, насколько такой спрайт-режим реален СЕЙЧАС, и что конкретно для этого требуется.
    Реально это было и тогда - вопрос в деньгах..
    Имхо мне видится другая постановка вопроса - делать эволюционно совместимые режимы, или совсем другие, ничего общего с оригиналом не имеющее.
    В первом случае необходимо чёткое понимание идеологии заложенной в конкретную конструкцию, которую предстоит развивать. Без этого это будет не развитие, а замена одной конструкции на другую.
    Во втором случае собсно нет никаких ограничителей в виде изначально заданной идеологии, и можно делать всё что вздумается изобретая новую идеологию, но это уже будет идеология другой конструкции.. т.е. - не Спектрум! А если изобретать сегодня что-то новое, то возможности тут безграничны и нет никакой необходимости ограничиваться какими-то убогими спрайтовыми движками, сейчас 2d ускорители встраиваются прямо в TFT матрицы, да и 3d реально доступны. А чтоб изваять 3d компьютер, достаточно взять серийно выпускаемую видеокарту и заставить её процессор работать в несколько нетрадиционном режиме - и практически весь компьютер готов .

  9. #8
    Master Аватар для Vladimir Kladov
    Регистрация
    09.02.2005
    Адрес
    Новосибирск
    Сообщений
    933
    Спасибо Благодарностей отдано 
    0
    Спасибо Благодарностей получено 
    17
    Поблагодарили
    17 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    По моему спектрум - это не просто жёстко зафиксированные параметры архитекутру (проц, память, страничная организация, видеоформирователь, звуковые прибамбасы), а идеология "сделай дешевле 100 баксов", чтобы просто задаваить массововстью. Мне понятно, что технически на тот момент одновременный доступ к памяти из процессора и видеосистемы представлял трудность. Но чуть позже, когда уже появился режим 16с, я так полагаю, проблема была практически разрешима. Вариант, который я описываю, мне кажется реализуем даже на рассыпухе, не говоря уже о ПЛМ (+отдельная память для буфера, например). Да хотя бы взять самую первую часть переделки: аппаратный скроллинг. Смотрите сами: гораздо быстрее удалить с экрана объекты, выполнить аппаратный сдвиг, и перерисовать объекты на новом месте (аппаратный сдвиг можно делать в любой момент между этими действиями), чем перерисовывать весь экран. И никакого клэшинга по крайней мере для заднего плана, потому что картинка сдвигается вся и сразу. Почему не реализовано? Какая такая совместимость? Чем это не спектрум, если к стоимости ничего не добавляется, кроме нескольких перепаек, или даже небольшой доп. платки? Если рассуждать так спектрум, не спектрум - то и добавление TR-DOS и мы получаем из спектрума - не спектрум. Вот с магнитофоном - это спектрум, а с диском - нет, это амстрад или текноложи рисёч, но не спектрум.
    Последнюю версию EmuZWin (2.7) можно получить по этой ссылке, а "официальная" страница с описанием здесь. Если что-то не пашет, берите там же версии 2.6 или старше. [B]

  10. #9
    ZEK
    Гость

    По умолчанию

    Цитата Сообщение от Vladimir Kladov Посмотреть сообщение
    И никакого клэшинга по крайней мере для заднего плана, потому что картинка сдвигается вся и сразу. Почему не реализовано?
    Что то тут не то,
    если имеется ввиду сдвиг аппаратный в смысле сдиг картинки на экране, то встает вопрос с распределением памяти (нада делать что то в духе 512х256), но клэшинг останеться так как он сдигается вместе с картинкой, и если рисовать по тому же адресу то соответсвенно и местро рисования тож сдвинется

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

  11. #10
    Guru Аватар для bigral
    Регистрация
    12.07.2006
    Адрес
    г. Киев, Украина
    Сообщений
    2,147
    Спасибо Благодарностей отдано 
    25
    Спасибо Благодарностей получено 
    95
    Поблагодарили
    82 сообщений
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Lethargeek Посмотреть сообщение
    Как раз в 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 к этому всему отношения не имеет по-моему никакого.

    Цитата Сообщение от Lethargeek Посмотреть сообщение
    Ну вообще-то совсем уже не "предел", поскольку ПЛИСы все толстеют и дешевеют (причем слабые модели снимаются с производства). А про идеальный двухмерный движок я выше писал. Совместимость в такую схему можно по-разному прикрутить, и цена ее поддержки ничтожная по сравнению с основным движком.
    А на что максимум мы можем реально рассчитывать в ближайшие 5 лет с таким подходом к разработке будущего ZX видеопроцессора? S3Trio64V+? Или V9990? А какая цена его будет $100? $150? При том что цена на готовый аппарат NES или SegaMD уже давно сравнялась и составляет менее $20. А может теперь удастся сделать аля Voodoo2 плату с видеомикшером способную смешать качественно экран спекки с готовым PAL изображением?
    Последний раз редактировалось bigral; 23.04.2008 в 21:04.

Страница 1 из 9 12345 ... ПоследняяПоследняя

Информация о теме

Пользователи, просматривающие эту тему

Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)

Похожие темы

  1. [FWD] Знать, что делать, а не как делать Автор: Сергей Леонов
    от Wladimir Bulchukey (500:95/462) в разделе Зарубежные компьютеры
    Ответов: 1
    Последнее: 29.06.2006, 17:29
  2. Зачем Вам Спектрум?
    от Titus в разделе Разный софт
    Ответов: 37
    Последнее: 23.04.2006, 03:52

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •