Реальная скорость работы УКНЦ

[vladtru]

Продолжение ))

Вот вам и медленная «плановая» видеопамять. Конечно, у «последовательного» кодирования цвета (БК, CGA, Amstrad CPC, BBC Micro и т.д.) есть и некоторые достоинства – например, у БК при побайтовом горизонтальном сдвиге шаг сдвига меньше, чем у ПК с плоскостной организацией (4 точки вместо 8, а у Amstrad CPC в 16-цветном режиме - вообще 2 точки), т.е. в большем числе случаев можно задействовать не медленный побитовый сдвиг, а быстрый побайтовый (с другой стороны, у ПК с битовыми планами скорость побитного сдвига сравнима со скоростью побайтного сдвига у ПК с «последовательным» цветокодированием , да и горизонтальное разрешение у "последовательных" ПК часто меньше (особенно в случае БК и УКНЦ), что позволяет с примерно тем же успехом использовать побайтный сдвиг и на ПК с "параллельной" видеопамятью вроде УКНЦ).

К тому же, поскольку скорость отображения цветных картинок у ПК с организацией экрана наподобие БК практически не отличается от скорости отображения монохромных картинок и занимаемый в памяти объем тоже (что само по себе – большой недостаток; даже звучит всё это странно – ведь логика подсказывает, что монохромные картинки должны быть меньше по объему и поэтому вроде должны отображаться быстрее ; тем не менее, объем монохромных картинок у таких ПК также очень неестественным образом обычно равен объему цветных, при условии что требуется их быстрый вывод на экран; а если «сжать» монохромные картинки до уровня 1 бит на точку (как и положено для них), то скорость их отображения на экране упадёт в разы) у программистов нет соблазна уменьшить многоцветность изображения (а проявления такого соблазна мы очень хорошо видим на УКНЦ!) для увеличения скорости отображения графики или уменьшения занимаемого объема (а в УКНЦ - ещё и для упрощения жизни программиста, чтобы не пришлось задействовать ПП или одновременно ЦП и ПП). Поэтому на многих таких ПК графика очень цветастая и красивая (яркий пример – Amstrad CPC), можно сказать, как ни странно, вынужденно цветастая . Впрочем, это вовсе не значит, что ПК с битовыми планами (а это УКНЦ, Корвет, Вектор-06Ц, Орион-128 (в 4-цветном режиме), IBM PC c EGA – ПК с подобной видеопамятью, кстати, не так уж и много) в этом отношении чем-то хуже – на них можно сделать абсолютно такую же многоцветную графику, причём выводимую намного быстрее, просто у программиста было поле для манёвра – и во многих случаях это, к сожалению, приводило к сильному упрощению графики как бы в угоду скорости игры и простоте программирования (вот и на УКНЦ полно монохромных или почти монохромных игр, есть они и на Векторе, и на Орионе…).

У «плановой» организации видеопамяти есть и ещё одно интересное свойство (особенно в сочетании с программируемой палитрой) – очень легко реализовать точное наложение спрайтов на сложный фон. Если на БК, Спектруме, Амстраде, ИБМ с ЦГА и других ПК без поддержки аппаратных спрайтов наложение спрайтов на фон – это целая проблема (нужно хранить в памяти кроме спрайта ещё теневую маску такого же объема, в общем случае перед наложением спрайта надо скопировать фон в буфер (а в следующем цикле наложения спрайтов сначала восстановить фон из буфера), потом накладывать маску логическими операциями (очищать фон под спрайтом), накладывать сам спрайт логическими операциями и т.д. – это ж с ума сойти можно!), то на ПК с «плоскостями» да ещё и программируемой палитрой можно, немного пожертвовав опять же многоцветностью картинки, накладывать спрайты самым примитивным образом – простым копированием их в видеопамять, без всяких теневых масок и извращений с буферами и логическими операциями (т.е. не только в разы быстрее, но и в разы менее затратно по памяти!).

Например, на «Векторе» (а я уж, простите, лучше разбираюсь в нём, чем в УКНЦ) очень часто использовался режим, когда два битовых плана отводились для фона (4 цвета) и два плана – для спрайтов (ещё три цвета – четвертый прозрачный), что позволяло отображать очень даже приятную 7-цветную картинку (Амбал, Гротоход, Step&Jump и др. игры) с прекрасными, очень быстрыми спрайтами без всяких чёрных или цветных квадратиков по краям спрайтов. Аналогично использовался режим 1 цвет спрайтов на 8-цветном фоне (например, в «Полёте», а можно было и наоборот – 7-цветные спрайты на одноцветном фоне). В общем, у программиста на «Векторе» почти не было проблем с выводом спрайтов на сложном фоне (впрочем, большинство программистов-любителей всё равно предпочитали использовать привычный одноцветный чёрный фон . На «Корвете» с этим было похуже – трёх плоскостей уже не очень-то хватало для относительно многоцветных игр (можно было применять режимы «1-цветные спрайты на 4-цветном фоне» или «3-цветные спрайты на 2-цветном фоне»), зато у «Корвета» была своя фишка – аппаратное ускорение (цветовой режим), позволявшее очень быстро и точно отображать одноцветные объекты любым из 8 цветов. А вот на УКНЦ я не знаю, использовалось ли какое-то аппаратное наложение спрайтов на фон с помощью плоскостей и палитры или другим способом (у него вроде тоже есть «цветовой режим» для быстрого наложения цветных объектов на сложный фон).

Кстати, если уж пошла речь об аппаратном наложении – у таких ПК обычно есть также возможность использования и других «хитростей»: имитации нескольких кадровых буферов (например, по одному монохромному буферу на одну плоскость экрана), аппаратного наложения нескольких планов (аналогично наложению спрайтов на фон – объекты на «ближних» планах могут перекрывать более «дальние» в том числе с «полупрозрачностью»), аппаратное маскирование части экрана (например, на половине выводится изображение, а вторая половина используется для хранения программ или данных) и просто управление объемом видеопамяти (часть плоскостей видеопамяти можно не использовать для вывода на экран, а хранить там данные).

И ещё замечание насчет возможности снижения вертикального разрешения – это не так уж бессмысленно, особенно если не хватает скорости или чего-то ещё. По крайней мере, у 8-битных Атари такой приём использовался часто (в некоторых играх было разрешение, по-моему, порядка 96 линий!, а уж 128 линий – это у них запросто, причем и горизонтальное разрешение было соответствующее – тоже от 128 точек). Не могу сказать, что такое низкое разрешение мне нравится (выглядит, по большому счёту, оно ужасно), но игры-то делали и продавали, и вообще в 80-х компьютеры Атари считались у нас очень крутыми игровыми ПК. У Атари, кстати, проблема в том, что при всей продвинутости их видеосистемы (всё таки специальный «видеопроцессор» с довольно гибкими настройками) многоцветное изображение можно было получить только при весьма низком разрешении, вот и делали такие «пикселизованные» игры. А в принципе возможность дублирования строк (и не только подряд, но и в разных частях экрана, и неоднократно) в сочетании с возможностью выбора горизонтального разрешения для каждой строки и аппаратными скроллингами, конечно, даёт потрясающие возможности для всяких видеоэффектов типа повтора групп строк на экране (например, аппаратного заполнения экрана какой-то повторяющейся «полосой», причём сдвинутой в разных фазах), мгновенного масштабирования, воспроизведения одной и той же картинки одновременно в разном масштабе и т.д. А еще можно же задействовать и цветовые эффекты с палитрами.

Прошу прощения за такую длинную «лекцию», но ваше замечание об отставании скорости графики на УКНЦ от БК из-за наличия в УКНЦ трёхплановой структуры видеопамяти меня, конечно, задело.

Спасибо за ссылку на статью о школьной информатике – конечно, я уже давно с ней знаком, но статья, безусловно, чрезвычайно интересная. Жаль только, что никаких цен там нет – а было бы интересно узнать цены не только на УКНЦ, но и, например, на «Корвет» (о его стоимости у меня вообще нет никакой информации – если сравнивать по числу микросхем, он вполне мог стоить и порядка 1000 рублей, как ПК8002 или наши ИБМ-совместимые, но в статье написано, что в 1987 году стоимость Корвета была в 2,6 раза больше УКНЦ – это что же, получается 1600х2,6=4160 рублей??? Как-то очень странно, если, конечно, речь идёт о «голом» Корвете – без дисководов и монитора).