Спрошу здесь, чтобы не плодить темы...
Есть такая программа Best View(er) Ивана Рощина. У меня версия 2.8 от 1999 года, также он выпустил 2.9 чуть позже. Но в 2004г. выпущена версия 2.19. И какая получается более новее, что-то нить событий теряется?
И, ещё, вопрос. Как при компиляции в SJAsm за место Stealth Boot по умолчанию, при создании .trd, прикрутить этот BV? Из него можно файлы code запускать, по другому пока что не додумался как это делать.
unreal
компиль сразу в sna (при условии что ничего не подгружается в игре)Сообщение от Biland
и не морочь голову
а потом когда закончишь уже приделаешь нормальный загрузчик
Ну, вроде бы, разобрался. Спасибо.
Но буду рад, если кто ответит про версии Best View и как его прикрутить, на будущее.
unreal
пересохрани образ диска с БВ в трд любым эмузвином
и добавь в батник который собирает сорец
копирование этого трд в новый файл (возможно удаление предыдущего)
потом компилирование самого сорца (в котором сохранение в этот новый файл)
так при каждом запуске
у тебя старый файл с добавленным .c будет удалятся
а на место него, перед компиляцией, будет подсовываться новый без него
- - - Добавлено - - -
батник
сорецКод:copy BV.TRD GAME.TRD sjasmplus.exe game.asm
проверилКод:device zxspectrum128 ;итд SAVETRD "GAME.TRD","game001.c",$C000,$4000
6-ти game001 на диске не образовалось
- - - Добавлено - - -
вот те еще подсветка синтаксиса z80 для notepad++
Вложение 69045
мож пригодится
позавчера надыбал ее дето тут на форуме
но там было абсолютно все ужас как вырвиглазно
а я оно перекрасил по образу и подобию emuzwin
и стало чуть лучшо
+в оригинале аффтар не знал\забыл что в lua тоже есть коменты
Последний раз редактировалось NEO SPECTRUMAN; 19.05.2019 в 13:41.
2.19 последняя и самая новая версия Best View. После версии 2.9, были версии 2.10, 2.11 и т.д...
Увидев сообщение, сразу понял, что 2.9 - это 2.09, далее 2.10, 2.11. Не мог от мышления заточенного под корректную "сортировку" переключиться.
И как я понял, здесь принято "кибибайт" "килобайтом" называть. Хотя я их тоже часто путаю...
unreal
В рамках спектрума о кибибитной ереси лучше забыть ))) тем более что этот плод продажной любви законодателей мер и весов к недобросовестным производителям родился намного позже устоявшихся спековских канонов, да и в обиходе по большому счету нифига не прижился, как называли кило/мега/гигабайтами (килограмами, метрами, гектарами) оба варианта, так и называют )))
Разбираюсь с экраном, много чего почерпнул. Но остались общие вопросы, для полной картины.
1. Как я понимаю некоторые игры используют буфер экрана, это где собирается экран, а потом перекидывается в область отображения.
Несмотря на специфический экран ZX, работа с ним с помощью процедур удобна по своей сути. Но возникает вопрос про буфер.
Вот найденный пример, который рисует шириной один байт вниз (28т на два вертикальных байта), в стандартный ZX экран
Если буфер экрана (или его части), хранить последовательно, то работа с ним упирается в код,Код:pop bc ;10 ld (hl),c ;7 inc h ;4 ld (hl),b ;7
примерно, такой (шириной для двух знакомест)
Что явно увеличивает число тактов (41т на два горизонтальных байта), но позволяет заполнять экран без перерасчёта знакоместа. Сложно сейчас вычислить, что на дистанции быстрее, т.к. первый вариант готовит заранее HL (стек спрайта) под прерывание (что съедает немного тактов). Но,второй вариант явно долгий более 8.000т на всю вертикальную полосу шириной в два байта, плюс подготовка.Код:ld de,31 ;новая строка pop bc ;данные спрайта ld (hl),c ;первый байт inc hl ;в буфере вправо на байт ld (hl),b ;второй байт add hl,de ;переход на следующую строку 31+1 --------- pop bc ;10 ld (hl),c ;7 inc hl ;6 ld (hl),b ;7 add hl,de ;11
Отсюда вопрос, т.к. оптимизировать второй вариант, вряд ли получится (если можно, то подскажите как). Можно ли сделать так буфер, чтобы с ним легко было работать без перерасчёта знакоместа и убрав команду ADD, например, сгруппировав его как-то своеобразно, нелинейно? Даже можно с шагом значения через два байта графики, через два байта команд, "вписавшись" в вывод
Были ли такие темы и рассуждения?Код:D SP,экран LD HL,NN ;два байта графики, здесь будет подставляться спрайт PUSH HL LD HL,NN PUSH HL
2. Для расчёта стандартного экрана координат используется небольшая процедура, которая вычисляет
адрес, также есть быстрая процедура смещения вниз на строку.
Вопрос, если использовать таблиц адресов первой колонки, чтобы быстро находить адрес строки, не будет ли быстрее? Конкретных примеров не нашёл (только в комплексе, где осилить сейчас весь код не полчуится), а свой метод перехода, отрабатывает долго. Есть ли по этому поводу комментарии?
3. Ну и третий, вопрос, про буфер. Его используют, если много страниц со спрайтами и два видео экрана. Предполагаю, но это не точно, что в ЧВ сделано так, хотя не факт.
Получается, что в продвинутых ZX, в cpu0 можно устанавливать не только 0 страницу (это тоже редкость), а любую. Значит от буфера можно отказаться, генерировать в экран cpu3 (страницы 5 и 7), подхватывая спрайты из cpu0. Тем самым экономя время на переброску буфера на экран. Это верно? За исключением того, что это могут только новые ZX.
unreal
Не бывает структуры буфера, оптимизации его и т.д. без изначально поставленной задачи.
Под каждый тип графического движка оптимален тот или иной вывод на экран.
Сперва надо определиться с задачей, потом уже придумывать, как ее реализовывать.
Что же касается 'продвинутых ZX', то их не бывает.
Есть классика - 48, 128 (буржуйские) и Пентагон-128 (наш).
А есть новодел типа Пентевы, Next'а и т.д.
Если писать под новодел, то о страничках заморачиваться не надо, надо сразу писать под новые графические режимы, битпланы, спрайты и что там еще у новодела есть.
Но аудитория у новодела пока что значительно меньше, чем у классики.
Я, например, вообще не запускаю софт под новодел, хотя эмулятор под рукой, т.к. для меня это уже не Спектрум, не ностальгия, и зачем он тогда нужен вообще)
Можно, в него будет легко выводить спрайты, но бросать такой буфер в экранную область будет неудобно.
Мои сиюминутные фантазии на эту тему.
Как я понимаю, ты хочешь сделать на полный экран, 50фпс, как можно больше спрайтов, в основном не пересекающихся на чёрном фоне и без маски. Уровень без скролла, много статичных тайлов, которые и перерисовать не нужно, следовательно бросаемый двойной буфер смысла нет использовать.
Можно попробовать переключаемый двойной буфер(седьмую страницу). Помнить какие знакоместа были со спрайтами подвижных объектов(СПО) два кадра назад, нарисовать новые СПО, запоминая в новой карте знакомест, и забывая знакоместа в старой карте. Потом пробежаться по старой карте знакомест, и затереть недотёртые. Потом переключить экраны. Вычислить продвижения объектов и всё по новой.
Чтобы не использовать седьмую страницу, нужно всё успевать перерисовать в нужном месте в нужное время. Кадровая развёртка у нас бежит сверху вниз. Вот нужно успеть "между струйками".Чтобы не сортировать СПО по координате Y, можно сделать так: Экран на спектруме как-бы состоит из трёх третей: верхней, средней и нижней. Вот, значит, пишем процедуру, которая обновляет содержимое одной трети. То есть перерисовывает все СПО и прочую индикацию в выбранной трети экрана. А в главном игровом цикле, начинаем вызывать её по порядку для верхней трети, средней, и нижней. Потом синхронизируемся с прерыванием 50гц, двигаем координаты обьектов. И по новой. А для режима пентагона, предусмотреть другой главный игровой цикл: синхронизация, перед обновлением нижней трети. Или средней трети. И ли перед перерасчётом. Всего четыре варианта, можно, думаю, подобрать, для каждого клона методом тыка.
Чтобы не подчищать лохмоты за СПО, зная их динамику, можно нарисовать их таким образом, чтобы они сами себя подчищали. Например танчик, который всегда за кадр может ехать на 1 пиксель вперёд максимум, может сам себя подчищать, имея за кормой один рядок пустых пикселей. В два раза более быстрый танк, должен иметь два рядка пустых пикселей, соответственно. При взрыве танка, последний спрайт анимации взрыва должен затереть всё. И так далее с летящими снарядами и прочим.
А что же делать, если изредка(например, каждый шестнадцатый) кадр будет такой сложный, что чуть-чуть не успеет перерисоваться за 1/50 секунды. Зато соседние кадры с гораздо большим запасиком времени успевают. Так что-же у нас будет дёрганье? Можно ведь это избежать. Но, конечно, синхронизация по HALT, мы отставим, а сделаем цикл ожидания, когда нам IM2_процедура добавит потребность в новом кадре.При старте игры или снятии с паузы (NeedFrame) надо обнулить.Код:LD HL,NeedFrame INC (HL)
Начать цикл ожидания надо с того, что один кадр отрисован, и мы его отнимаем.
А потом ждём, когда-же NeedFrame станет неотрицательной.Код:LD HL,NeedFrame DEC (HL)
Если случайно один сложный кадрик нас(то есть наш Z80) притормозит, то просто INC (HL) выполнится чуть раньше DEC (HL). Ну и ничего страшного, результат-то тот же. JP не сделает переход ни разу, то есть мы сразу выйдем из цикла ожидания и кинемся догонять время. Вместо тупого аппаратного HALT, который нас-бы(ну мы, щас за Z80 думаем), заставил бы стоять до скончания кадра, почти целый кадр.Код:PHALT: BIT 7,(HL) JP NZ,PHALT
Всё пишу из головы, код не отлажен, не пытайтесь бездумно копипастить и компилировать.
[свернуть]
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием