• avatar sq
  • 2
Уже хочешь скрасть под конфу? Я тобi насквозь бачу!
  • avatar VBI
  • 1
оу, спойлеры!
  • avatar oisee
  • 3
Не, это сюжет игры.
я наврал, BIFROST*2 ENGINE выводит 20 знакомест! вива гасман
  • avatar VBI
  • 1
Спасибо!
Залил исходники Old Tower Скачать тут
Чуть подчистил исходники Глуфа, если кому интересно то скачать тут
Код переменного качества от среднего до ужасного, но от этого более понятый новичкам :)
  • avatar sq
  • 4
А потом создатели будут ныть, что их игру скрали и зарелизили без их ведома, не заплатили, шарик не дали, никакого праздника. И удалят все посты и аккаунты, хлопнув дверью и умываясь слезами.
  • avatar oisee
  • 1
Нужно срочно выпустить игру «Dizzy in Dramakingdom»! =)
Это очень плохая ссылка, написанная человеком, который видимо не вполне разбирается в теме. И фикс им предложенный реально грязный, что собственно видно даже по его экспериментам с играми.

Оригинальная модель 48К на то и оригинальная, что никуда не опаздывает. У неё действительно прерывание происходит за 64 строки по 224 такта до начала отрисовки экрана. Можно сказать, что верхний бордер у 48К спектрума содержит 64 строки (64*224=14336 машинных тактов). На самом экране строк 192, а на нижнем бордере их ещё 56. Итого 64+192+56 = 312 строк, 312*224=69888 тактов.

128К модели воспроизвели этот расклад только приблизительно, т.к. у них другое число тактов в строке. У серого +2 например на верхнем бордере 63 строки по 228 тактов, а внизу — опять 56, т.е. всего 311 строк, 311*228=70908 тактов на кадр. В итоге верхний бордер почти такой же как на 48К (63*228=14364 тактов, на 28 тактов больше).

А вот на отечественных клонах этот промежуток времени от прерывания до начала отрисовки экрана не выдерживался даже приблизительно. Самый вопиющий пример — Ленинград, у которого кадровое прерывание приходило сразу после отрисовки самой нижней строки экрана, т.е. на Ленинграде нижнего бордера по сути не было вообще, только верхний. На Пентагоне на верхнем бордере фактически 80 строк по 224 такта, т.е. 80*224=17920 тактов, зато на нижнем бордере строк всего 48. В итоге нетривиально рассчитанные эффекты, типа мультиколорного скролла описанного выше Денисом, приходится по сути рассчитывать индивидуально для каждого из клонов.
  • avatar aa-dav
  • 0
И еще — по ссылке выше про «получил такую картинку» на том форуме возникла неопределенность в следующем вопросе — когда ULA генерирует прерывание, то в одних документациях по ZX Spectrum 48 мы видим, что оно генерируется ровно за 64 «виртуальных» строки (каждая — 224 T-state-а) до первой строки изображения с адреса 16384.
Но судя по другим источникам так делают множественные клоны спектрума, а оригинальная модель 48k запаздывала с наступлением прерывания на 16 строк. И даже поэтому в клоны специально апгрейды встраивают в виде схемы задержки наступления прерывания, например тут: zxpress.ru/article.php?id=11847
Странная ситуация когда в разных местах написано разное — а так как multycolor при таких несоответствиях будет просто неправильно работать, то, думаю, не ошибусь если попрошу навести ясность в этой теме.
  • avatar aa-dav
  • 1
"… можно наверное наворотить вообще огого"
Дошло, что я это говорю человеку, который как раз воротит «огого!» и не раз и не два и с такими изощрениями, что «огогого!». :D Что-то как то совсем за всеми этими восторгами от техник забыл выразить своё почтение!
  • avatar Shiru
  • 2
Написание фреймовых скроллеров было типичной забавой во времена популярности электронной прессы на ZX — каждый старался сделать фреймовую читалку. См., например, BornDead, где к последним номерам появилась плавная попиксельная цветная листалка на весь экран (на Pentagon). Правда, в подобных листалках часто хитрили, не выводя пустые строки пикселей между строками текста.
  • avatar aa-dav
  • 1
Воспользовался советами и получил такую картинку.
В принципе весьма прикольно, регулируя область можно выходить и на плавные скроллеры с 50fps. А если рисовать в бэк-буфер и выводить его каждый второй кадр, то в стабильных 25fps можно наверное наворотить вообще огого.
  • avatar aa-dav
  • 0
P.S.
Да, наверное просто включен турбо-режим скорпиона, а где он включен даже и не пойму.
  • avatar aa-dav
  • 1
ну эмуляторы которые хотят тот же мультиколор правильно отобразить таки должны крайне скурпулёзно высчитывать тайминги, поэтому я им весьма доверяю в этом вопросе. в Spectaculator Old Tower точно работает правильно, поэтому ему верю. а вот почему UnrealSpeccy показал в два раза больше для меня неожиданность — подозреваю, что у меня просто выбрана какая то разогнанная модель, но т.к. в нём настройки все и хоткеи более чем неинтуитивны, то даже не могу понять из конфига что именно там выбрано. судя по менюшкам — скорпион какой то, но не очень понятно.
чисто исторически мы меряем всё фреймами, успевает в один фрейм (в среднем 70000тактов) = 50фпс, в два 50/2 и.т.д что там эмуляторы показывают одному автору эмулятора известно.

время выполнения обычно меряется бордюрчиком


;ждём начала кадра
halt
;синий бордюрчик
ld a,1 : out (254),a
;что надо померять
call megaDraw
;белый бордюрчик
ld a,7 : out (254),a


и получаем синенькую полосочку чтобы визуально оценить скока процедура жрёт от всего кадра :)
  • avatar aa-dav
  • 1
P.S.
Перепроверил на Spectaculator — тот показал в два раза примерно меньший фпс. Хм, видимо эмулятор Unreal у меня где то в настройках разогнан, так что всё скромнее на самом деле.
  • avatar aa-dav
  • 1
секундомером просто замерил сколько раз зацикленный в двух третях экрана паттерн делает полный проворот за 10 секунд — получилось 10 раз.
Как ты фпс считал? :) он не может быть быстрее чем период обновления экрана в два раза, т.к. даже чистая пара ldpush тратит 10.5 тактов на байт, значит 4096байт*10.5 = 43008 а это уже больше чем полфрейма, а это без учёта медленной памяти и вспомогательных вычислений