PPC, наверно я что-то недопонял в твоем предложении. Как ты предлагаешь восстанавливать спрайт, если он был запорчен адресом возврата после задания sp на спрайт, но до pop?
Вид для печати
PPC, наверно я что-то недопонял в твоем предложении. Как ты предлагаешь восстанавливать спрайт, если он был запорчен адресом возврата после задания sp на спрайт, но до pop?
Всё также, как в оригинале от jerry: запретить прерывания, поставить стек, считать <BC>, разрешить прерывания, побежать.
Если без запрета прерываний, то да, нужны промежутки между спрайтами, но это как-то некузяво выглядит имхо, хоть и должно быть быстрее (сразу потеря 8 тактов на спрайт).
PS. В качестве уточнения: 2х-байтные промежутки ДО спрайта, не "после".
ivagor, пойми, в глобальной картине всё это мало что изменит потому, что кроме спрайтов, в банках квазидиска сидит ещё туча всяких вещей типа карты триггеров, списка событий, фонтов и т.п. фигни, и ещё туча кода должна будет запрещать/разрешать прерывания. Сейчас практически весь цикл бежит с запрещёнными. Я делал версию с EI. Мало того, что прерывания терял, так она ещё примерно почти на кадр медленнее бежала.
PPC, тебе относительно роботов однозначно виднее. А лично мне это микрообсуждение было интересно нахождением удачной адаптации предложения Медноногова (про него я раньше читал в zxformate) к использованию с КД.
Мне тоже было исключительно интересно. Мало того, я думаю, что попробую все возможные озвученные варианты, чтобы понять, насколько это будет влиять на саундтрек и скорость. Просто вывод тайлов - не единственное место, где надо извращаться, если бежать совсем с разрешёнными прерываниями.
Могу сразу сказать, что вариант, когда прерывания запрещены на время вывода всего тайла, я пробовал, и он нежизнеспособен. Звучание саундтрека было гораздо хуже, чем вот сейчас, с практически запрещёнными. Вывод тайлов во вьюпорт занимает 2.82 прерывания, и они, естественно, регулярно терялись во время рендеринга. Мне интересно, какой эффект даст короткое запрещение прерываний. Боюсь, что всё равно будут частые потери так как для вьюпорта 10x13 тайлов это придётся делать 260 раз (задний план, потом - передний план). Вариант с "разреженными" тайлами и разрешёнными прерываниями - возможно, лучший кандидат, если ничего ещё не придумается, но и он добавит тактов (два сложения при нахождения адреса тайла).
Пара слов про самый быстрый вариант вывода тайлов - lxi + push. К роботам это вряд ли применимо, но как минимум в одной векторовской игре используется.
В принципе и это можно совместить с разрешенными прерываниями. В обработчике проверяем код команды, на которую будет возврат. Если это push - ничего не делаем, если не push - заменяем адрес возврата на вершине стека на содержимое регистровой пары (скорее всего bc) в которую был lxi. Небольшая проблемка есть с самыми нижними строками:
1. Если сначала рисуются верхние тайлы, потом нижние и используется двойная буферизация, то можно просто после цикла вывода тайлов "зарисовать" две строки примыкающие к нижнему ряду тайлов.
2. Чуть медленнее, но более универсально - выводить 2 нижние строки примерно так, как выводятся первые два байта в оригинале Медноногова, приведенном jerri.
Причем этот подход к совмещению с разрешенными прерываниями можно применить и к оптимизированной версии lxi+push, когда часть lxi заменяется на mvi, часть lxi/mvi/... пропускается (и т.п.). Но все же ограничение накладывается - нельзя использовать для задания графики две регистровые пары, что в некоторых случаях (регулярные паттерны размером 4x8) позволяет еще немного ускорить вывод.
Еще вариант, но менее удачный и универсальный - использовать определенное выравнивание процедур вывода и в обработчике прерывания проверять несколько младших бит адреса возврата.
---------- Post added at 14:42 ---------- Previous post was at 14:02 ----------
Момент, касающийся вывода первых 2х байтов, про который забыл написать. Там м.б. что-то типа такого: lxi b,d16; sphl; push b; lxi b, d16; push b и т.д.
Еще одна вещь - в обработчике нужно проверять, куда сейчас указывает sp. Если в экран - действуем, как написано выше.
Ну и, конечно, можно просто использовать таймер, если не жалко одного канала.
---------- Post added at 14:48 ---------- Previous post was at 14:42 ----------
Еще вариант - вместо sphl здесь может быть shld, меняющий адрес обработчика прерывания. Тогда в обработчике можно не проверять, куда указывает sp.
---------- Post added at 16:03 ---------- Previous post was at 14:48 ----------
Проще не трогать в указанном фрагменте sphl и менять обработчик один раз - перед выводом тайлов (не каждого отдельного). И пока выводим тайлы sp всегда "в экране".
Вопрос только в том, на какую глубину будет использован стек, чтобы не попортить расположенные по ходу стека другие тайлы, которые не будут выводиться в данный момент. Как минимум будет использрован адрес возврата, psw и hl (для анализа содержимого sp или его сохранения), т.е. 6 байт. Таким образом, последние 3 команды push для вывода на экран должны быть при запрещённых прерываниях.
В обработчике, активном при выводе тайлов - только на 2 байта для хранения адреса возврата. Все регистры сохраняются в памяти через shld и разнообразные обмены и пересылки.
---------- Post added at 17:43 ---------- Previous post was at 16:28 ----------
Если еще подумать, то все очень просто. Рисовать тайлы с использованием push (данные для push можно задавать любым образом - lxi, mvi, mov и т.д.) без запрета прерываний можно даже не изменяя обработчик прерываний если:
1. Использовать двойную буферизацию.
2. Рисовать тайлы сверху вниз, например построчно. Самую нижнюю строку тайлов рисуем обычными процедурами (без push).
Если высота тайла 16 точек, то глубины стека в прерывании хватит на 7 push.
Мой предварительный большой и местами неверный пост теперь можно было бы стереть, но тогда повиснет в воздухе пост b2mа, который подтолкнул меня в правильном направлении.
---------- Post added at 19:41 ---------- Previous post was at 17:43 ----------
Последний приведенный вариант уже нормальный, но при выборочном обновлении (выводим только изменившиеся тайлы) его нужно дополнить. В обработчике прерывания проверяем, выводятся ли сейчас тайлы, и если да, то какие координаты текущего (можно даже по sp определить). Добавляем в специальный список координаты на тайл ниже. После отработки основного цикла вывода тайлов дополнительно обновляем тайлы из списка. Перед началом нового цикла вывода тайлов очищаем тот список.
Применительно к роботам - именно так, и никак иначе. При любом раскладе, нужна custom ISR. Вообще, обработчик нужен только для "равномерного" воспроизведения музыки/спецэффектов, и ни для чего больше. Увы, и музыка, и спец-эффекты, и соответствующие драйверы для них лежат в других страницах и банках квазидиска. Под страницами я имею в виду доступ к квазидиску "как к ОЗУ", под банком - как стек.
Поэтому, "переключение контекста" внутри ISR неизбежно. На самом деле, таких переключений - 3 штуки: 2 выполняются кодом входа в музыкальный драйвер из контекста ISR. Драйвер бежит в соответствующей странице, которые разные для SFX и саунд трека.
После выполнения драйвером "рендеринга" музыки, он возвращает назад режим квазидиска, в котором бежала ISR, и выходит по ret. Это надо учитывать.
Зато я вот сейчас сделал версию, которая не переключает квазидиск назад-вперёд при выводе тайлов в ОЗУ (бежит в режиме доступа стеком к тайлам всё время заполнения вьюпорта из тайлмапа). Только такая простая фишка, сразу дала выигрыш в целых 3 тайла на рендеринг экрана. Офигительно ощутимо даже визуально.
Увы, я не могу пока сделать тоже самое для тайлов переднего плана с альфа каналом. Они большие (24К вроде), и лежат не в том банке, где тайлмап. Эхх. Можно (нужно), конечно, скопировать тайлмап туда, где тайлы, но тогда придётся куда-то двинуть фонты :). Это всё не даст такой-же выигрыш, как с тайлами заднего плана, потому, что передний план не заливает весь экран (только всякие батарейки и "экраны"). Буду думать.
Версию "по Медногоногову" планирую попробовать на этих выходных. На работе не просто завал, а аврал. Не до роботов, сам как робот, по программе дом-хайвэй-работа-хайвэй-дом. :)
Да, стало фастер :). Попробую скрестить это с Медногоговым, поглядеть, насколько просадит фпс, и главное - насколько неровно будет играть.
Да, шаг перемещения, думаю, будем уменьшать. Но до этого - возможно выложу эту более быструю версию. Только вот погляжу, как оно будет с Медноноговым, или без.
Development update:
Сделал вариант по Медноногову и с моими ускорениями: тайлмап читается режимом квазидиска "как ОЗУ", тайлы - режимом "как стек" одновременно, что позволяет не переключать режим на каждый тайл, и даёт прибавку к скорости в 3 тайла на вьюпорт. Вывод музыки хромает как секс со старой бабушкой, глотая прерывания в многочисленных местах, где происходят переключения банков и переустановки стеков (прерывания там запрещены). Правда, весь передний план пока тоже выводится при запрещённых прерываниях, так что ближайшая задача - напустить Медноногова и на этот код. Поглядим, что можно выжать из этого. Если будет хотя бы сносно, выложу оба варианта на обозрение публики. Два варианта развития кода мне не потянуть, будем голосовать, или что-то в этом роде.
Зато эха снова оживает, и это приятно. ivagor проводит чудовищные эксперименты с ШИМом, которые можно производить "только при разрешении соответствующих органов" (с) Булгаков. Прикольно, если ему удастся запулить "Электричество" с лучшим качеством, и меньшим размером :). Сейчас - 30 секунд саундтрека в 60 с хвостиком килобайт на частоте дискретизации 9КHz двухбитовой DAC.
PPC, а ты не думал о переносе задач, требующих запрета прерываний, в обработчик?
ivagor, думал, но это потребует солидных переделок там и сям. Сейчас пытаюсь оценить объём и количество требуемых повреждений ;).
На самом деле, мне ужасно хочется начать субтайловый (байтный) режим. Там тоже некисло надо рихтовать. Если тотальный Медноногов выльется в несколько недель работы напильником, отложу на потом. На обозрение, выложу 2 версии, по Медноногову - что смогу пока. Это всё - если за эти выходные успею с минимальными переделками.
В первый пост выложен новый альфа-релиз, версия 0.59am.
В релизе, как и обещал, две исполняемых версии кода.
Файл robotzDI.com - это фактически старый вариант программы, бегущий с запрещёнными прерываниями, но с незначительными изменениями в сторону ускорения рендеринга. Выложен для сравнения, и не используется по умолчанию.
Файл robotz.com - это практически переписанный вариант Роботов. Исполняется, в основном, с разрешёнными прерываниями по методе Медноногова (спасибо jerri за идею. Процедуру обработчика прерывания при рендеринге, предложенную в этой ветке выше, пришлось серьёзно модифицировать для учёта особенностей чисто Векторовской bank-switching архитектуры. Также пришлось поработать и над загружаемыми драйверами, обеспечив их прозрачность в смысле выбранного в данный момент режима доступа к квазидиску, контекста (вызов изнутри video-ISR или снаружи) и совместимости с версией, бегущей с разрешёнными прерываниями. Новые драйверы подойдут и к старым версиям кода, скажем, 0.58.
Задача полностью избавиться от запрещения прерываний в этой версии не ставилась так как это бы потребовало серьёзных изменений форматов данных и релокации этих данных в банках квазидиска. Прерывания запрещаются, в основном, из-за необходимости одновременного доступа к более, чем одному банку в режиме доступа как стек и как память соответственно из-за соответствующего размещения данных (тайлмапы, карты уровней, драйверы звука, звуковые дорожки и т.п.). Поэтому, будет наблюдаться некоторое "хромание" звуковой картины, но могу Вас заверить, это хромание на порядки слабее, чем пару недель назад, когда я просто влепил обработчики по Медноногову в имеющийся код бэйс. В общем-то объём оптимизаций для устранения хромоты проведён нешуточный (у кого есть IDA, может в этом легко убедиться).
Новую версию, кроме того, что она сообщает о себе как 0.59M вместо 0.59a, очень просто отличить, скажем, в эмуляторе Virtual Vector, который позволяет изменять тактовую частоту "на лету". В старой версии, при таком изменении, необходимо выйти в основное меню, и вернуться в игру для пересчёта коэффициентов задержки саунд-трека. В новой версии, изменение тактовой частоты на лету, не изменит темпа воспроизведения музыки и звуковых эффектов.
Обе версии в данном релизе бегут быстрее, чем предыдущая версия 0.58 (отчего - смотрите выше по ветке). Мне сдаётся, что версия по Медноногову бежит чуть быстрее, чем с запрещёнными прерываниями. По крайней мере, по вычислениям, она рендерит задний план на примерно 4000 тактов быстрее.
Как я и предполагал, 2 версии кода значительно различаются друг от друга, и поддерживать обе будет выше моих сил. Кого интересует, предлагаю высказывать своё мнение, какую поддерживать далее а также pros и cons с Вашей точки зрения. Своё мнение я не скажу, дабы опрос был нейтральным. Скажу только, что в версии с запрещёнными прерываниями, звуковая дорожка пока более стабильна, но эта стабильность зависит от количества спрайтов на экране. В версии по Медноногову, стабильность дорожки также пока зависит от количества спрайтов (так как доступ к ним требует переключения банков), но в теории, она более стабильна в будущем.
В общем, зацените, и высказывайте свои соображения.
Как мне показалось в версии с "разрешенными прерываниями" музыка играет в своем нормальном ритме местами "подтормаживая" и субъективно показалось что рендеринг идет немного быстрей и игра кажется как бы более живой. в версии DI музыка постоянно в каком то заторможеном состоянии (видимо из за стабильных пропусков прерывания) что придает ощущение тормознутости игры несмотря на более равномерный темп музыки. В общем я за новый вариант :) Думаю со временем его удасться еще допилить в лучшую сторону.
В общем, после некоторых очень слабых колебаний, я решил поддерживать вариант с разрешёнными прерываниями.
Пока думал над тем, как сделать bank switching без запрещения прерываний, рихтовал версию 0.59M, выложенную в первом посте. Удалось и ускорить, и снизить звуковую хромоту. Во вложении-только исполняемый файл с рихтовками. Скопируйте его прямо в .fdd образ диска версии 0.59, и всё должно работать.
Robotz! Changelog
------------------
v. 0.60a 12.09.2015
------------------
Mini-upgrade, выкладывается только исполняемый файл robotz.com для замены предыдущей версии 0.59.
Изменено:
1. Принято решение поддерживать только вариант с разрешёнными прерываниями по методе Медноногова.
2. Ускорен рендеринг заднего плана и оверлеев
3. Уменьшено время нахождения в состоянии с запрещёнными прерываниями вне ISR, вызванное переключением банков.
На самом деле, уже найден алгоритм переключения, позволяющий полностью отказаться от запрещения прерываний при переключении банков. Но пока-как есть.
Убрано:
1. Текстовый драйвер для вывода сплошного текста 8xN пикселов в низком разрешении.
Вместо него во всех случаях используется драйвер, поддерживающий наложение масок на текст
Пофикшено:
1. Баг в текстовом драйвере 8xN пикселов с поддержкой масок.
При отключении масок и запрещении видеоплоскости 0x8000-0x9FFF, cплошной текст не выводился на экран.
Месяца с 3 назад обнаружил, что версия 0.60a из предыдущего поста может и будет крашиться рано или поздно при определённых условиях. Никто и не заметил ;). Пофиксил этот крэш, но выложить руки никак не доходили.
Robotz! Changelog
------------------
v. 0.61a 03.08.2016
------------------
Mini-upgrade, выкладывается только исполняемый файл robotz.com для замены в предыдущей версии 0.60
Добавлено:
1. Счётчик кадров в панели Instant Status
Пофикшено:
1. Редкий и гадкий крэш, связанный с переключением банков квазидиска во время отрисовки оверлеев
В первом посте выложена версия 0.62a c cубтайловым рендерером (разрешение в пол тайла) использующая алгоритм УШИ.
Клавиша <Shift> в игре - режим бега.
Код рендерера теперь выглядит как хорошая китайская головоломка.
Всех с Наступающим Новым Годом! :v2_dizzy_christmas2::v2_dizzy_christmas:
В первом посте выложена версия 0.63a
Robotz! Changelog
------------------
v. 0.63a 01.16.2017
------------------
Изменено:
1. Изменён формат хранения тайлов заднего плана в файле level001.spt (добавлены 2-х байтовые межтайловые промежутки по идее Jerri)
2. Значительно улучшена равномерность воспроизведение саунд трека (убраны запрещения прерываний при чтении тайлмапа и тайлов заднего плана из банков ERAM)
3. Слегка изменёны видео-эффекты в драйвере вокала pdac2vox.drv
Пофикшено:
1. Крэш при возврате в игру из меню опций после установки заново субтайлового режима работы рендерера (опция AutoRun OFF)
Наконец-то я более-менее удовлетворён рендерингом и звучанием саунд-трека. Хотя на самом деле, и это безусловно не предел. Теперь можно оценить, насколько подтормаживает вывод саунд-трека в прерывании, установив Sound OFF в меню опций. Подтормаживает он заметно. Вывод, который напрашивается - надо пилить старинный бульбовский код STM плеера на предмет быстродействия, а может - просто переходить на PT2 или PT3, если они более оптимальны.
А в общем осталось всего-ничего: сделать чистовую графику, нормальные (не отладочные уровни), неписей с AI и оружие, и можно считать, что beta готова :D
В топе этой ветки выложена новая версия 0.64a.
------------------
v. 0.64a 01.30.2017
------------------
Изменено:
1. Отказался от умножения сдвигами при вычислении адресов битмапов. Перешёл на табличный обсчёт, пожертвовав 512 байт на BSS,
но доведя FPS субтайлового рендерера заднего плана до 16 (тайлмап и битмапы всё также - в банках).
2. Полностью устранил запрещёние прерываний при выводе субтайлов во время рендеринга заднего плана и при одновременном
переключении банков для воспроизведения SFX и саунд-трека.
Прерывания теперь запрещаются на очень короткий момент только при выводе оверлеев (тоже устранимо, но надо менять банк для тайлмапа оверлеев).
Пофикшено:
1. Race condition при выводе левой части субтайла (алгоритм в версии 0.63 рано или поздно начинал гадить в экран одним из макросов)
Добавлено:
1. Добавлено 2 новых системных шрифта опционально.
Причина - обнаружил на этих выходных race condition в одном из своих хитромудрых макросов по выводу полутайлов. Заодно пооптимизировал ей чуток ;). Всё-же, умножать на 66 сдвигами - это медленно, учитывая, что надо вычислять
64 * n + 2 * n + 2 = 2 * (32 * n + n + 1). Множить на 32 - это много-много сдвигов.
Перешёл на таблицы. Сначала был даже вариант, где SP использовался в виде РОН - хранил базовый адрес таблицы с адресами тайлов в банке, но потом и от этого отказался. Просто завёл 2 выровненных таблицы по 256 байт, получив 64 векторовских такта (с вэйтами) на загрузку (<E> на входе - индекс тайла):
Со сдвигами у меня не получалось быстрее 80 векторовских тактов на выборку.Код:xchg
mvi h,HIGH(TLE_ADR)
mov a,m
inr h
mov h,m
mov l,a
sphl ; points to 1st byte AFTER gap, so that ISR uses gap
pop b
Использовать <BC> или <HL> нельзя: регистр <BC> на входе кажет в предыдущий битмап (не всегда в его конец), в <HL> - координаты тайла в тайлмапе. Подумалось сейчас, что в общем-то <BC> можно использовать, если его после рендеринга тайла всегда выставлять на промежуток между битмапами, и использовать его как новую базу при вычислениях (от самого <BC> толку почти нет: 80е процы не ортогональны).
Посчитал статистику.
Для вывода выровненного на тайлы заднего плана, новый подход даёт 2097 тайлов в секунду (2-х битовый тайл 16x16), что для вьюпорта 13x10 тайлов занимает 186800 тактов (со всеми циклами, переключениями банков и т.д) и рендерит 16 FPS.
Для вывода субтайлового кадра получил 2054 тайла в секунду, 15.8 FPS. Но пришлось слегка замедлить, чтобы бежать с разрешёнными прерываниями когда нужно читать из середины битмапа. Вопрос, который jerri задал сам себе:
(а что делать если урезание будет).
Всё-же не хотелось запрещать прерывания нигде, и пришлось двигаться по битмапу ползком, т.е. стеком до нужного места.
Это сказалось: 2032.7 тайлов в секунду и 15.64 FPS.
Но зато весь вывод заднего плана теперь вообще происходит без запрещённых прерываний. При этом ISR ещё дополнительно переключает банки чтобы сыграть саунд-трек и/или звуковой эффект. Такая там чехарда стоит :)
Но в среднем задний план рендерится за 15.8 FPS так как субтайловые кадры чередуются с обычными при движении ГГ. По моим подсчётам, вывод таким методом c bank-switching ТОЛЬКО тайлов без подсчёта их координат, индексов, координат тайла в видео-памяти и зацикливания пока не выведен весь вьюпорт в теоретическом пределе позволяет рендерить таким алгоритмом до 18 FPS. На практике, конечно, надо двигаться и по видеопамяти вьюпорта и по тайлмапу, вычисляя тайловые индексы (2 кадра туда и уходит). Но в общем, практические 16 FPS - это совсем недурно для нашего неспешного Вектора, учитывая, что рендерер - субтайловый, и трюки со сравнением и перерисовкой только изменившихся тайлов тут не пройдут (они и так в роботах не пройдут потому, что поверх заднего плана "гадит" в видеопамять рендерер альфа-тайл - оверлеев).
Померил суммарную скорость роботов. Сейчас это что-то в районе 8.5 FPS. Силы уходят на обработку событий, отработку триггеров, модель повреждений, collision detection, проигрыватели SFX (немного) и sound track (много) в драйверах, вызываемых из ISR ну и на обновление всякой инфо-фигни на экране. Но, думаю, при наличии времени и уровне попроще, чем этот (45 триггеров, 54 события для 900 "движущихся" тайлов заднего плана плюс оверлеи), можно этот мультиплановый рендерер-ад ещё ускорить.
А пока-более-менее равномерный звук :v2_cool:.
Немного оффтоп, помню в 1992 у меня появился вектор, а в 1997 был убран в шкаф, т.к. его место занял PC, т.е. время жизни вектора было примерно 5 лет )) Этому проекту роботов тоже 5 лет уже, если бы в свое время он появился на свет, то получается так бы и не успел выйти в свет ))
Но очень хочется увидить игру в играбельном виде, чтоб заценить все фичи движка.
Ramiros, это понятно, но всё упирается в свободное время; "время жизни" платформы (если и есть такое) тут имхо ни при чём. Два крайних года я не более двух недель в сумме потратил на движок. Как оно дальше получится - никто не знает. Кармак на эту тему сказал как-то: "программа будет написана, когда она будет написана". Обещать какой-то deadline я не могу, но то что буду тратить часть свободного времени на допиливание - несомненно. Правда, уже однозначно выпадают февраль и март: похоже не будет ни дня свободно.
В общем-то, если "очень хочется", то уровни и графику для них можно и самому клепать: там открытая архитектура, всё, что касается описания уровней и профиля ГГ загружается из файловой системы. Другое дело, что пока нет NPC, оружия и ещё части power-ups, которые задумывались.
Если есть желание потренироваться, можно в личке обсудить.
В первом посте новая версия ROBOTZ! Alpha 0.65, "Новогодняя". Что успел, то в неё и вошло.
С Наступающим!
:v2_dizzy_christmas:
PPC, любопытно. Под моим эмулятором дело встает на первом вызове cp.com. Подозреваю, что дело в каких-то тонкостях эмуляции вг93. Заметил, что это вообще не самый обычный МикроДОС. Он есть отдельно от ROBOTZ!ов ?
(Meanwhile, я где-то в хвосте очереди задач интересуюсь перспективами доработок МикроДОС-а. А если вдруг есть что-то в исходниках и можно не изобретать велосипед, было б проще).
Сам ROBOTZ! заценил в b2m-е. Как обычно технически очень круто, но не очень понятно, что нужно делать. Я бы наверное оценил версию, где можно просто повтыкать в экран, ничего не нажимая.
В любом случае я очень рад обновлениям, спасибо! С наступающим!
svofski, МикроДОС там самый обычный. BIOS там Bold 2.x, я не помню чтобы я ВГ93 код в нём менял хоть чуточку
В картотеке это файл MDBOLD21 вот тута: http://sensi.org/scalar/ware/835/
У тебя есть диски с Bold 3.0, вот там - да, мы много попахали ВГ-шкой чтобы поддерживать разные форматы. А тут всё должно быть нормально.
cp.com скомпилена BDS C компилером. Надоть смотреть как там read() и write() проимплементированы.
Увы, сырки Bold BIOS похоже безвозвратно утеряны. Это были такие длинные .asm файлы с загадочными комментариями. Просто BIOS ессно начинался с дизассемблирования stock МикроДОСа каким-то интерактивным CP/M дизассемблером. Все дискеты побились, увы - 25 лет всё-ж прошло. Я был бы счастлив тебе всё это отдать, там c ВГ, и не только с ней немало уже было сделано.Цитата:
Сообщение от svofski
Спасибо!Цитата:
Сообщение от svofski
Там всё как обычно: ходить-бродить, открывать двери, собирать power-ups, искать выход, допускать минимум повреждений и экономить электроэнергию :)
Ну и на этом уровне всё довольно головоломно. Необходимо терпение и чуть наблюдательности чтобы собрать все ключи и найти как выйти: хоть всяких подсказок там и дофига, но я их чуть спрятал за общим тайловым кошмаром.
Приятно, что понравилось. Там графики одной под 100К на уровень. А какой там рендерер под этим, мама не горюй - субтайловый 6-битовый с 3-х битовым альфа каналом . Мне (точнее Вектору) нужна DMA и SMP :)
C Новым Годом!
Видимо это просто утилита хитрая. Запись я в своих эмуляторах вообще практически не проверял, а вот и появился хороший повод.
Уже проинсталлированный ROBOTZ! советую заценить именно в vector06sdl, потому что звук в нем звучит.
Я бегло просмотрел changelog. Но даже мне не совсем очевидно, что многие из слов в нем значат. Было бы интересно послушать семинар, или просто ютубу с рассказом о том, как page flipping заменяется на scroll masking и про развитие метода Медноногова ;)
Второй этаж, справа от лифта. Рекомендую :) Туда достаточно просто добраться: идти по 1му этажу вправо, найти лифтовый контрольный модуль и вставть его слева от шахты, затем идти дальше вправо до момента, когда остановится двигатель, снять с него жёлтое колесо, установить колесо в лифтовую шахту, вернуться к контрольному модулю починенного лифта и ждать, когда он придёт по вызову.
Ха, вместо семинара можно отмотать этот тред вот на это судьбоносное сообщение от jerri:
https://zx-pk.ru/threads/19922-robot...l=1#post836375
С него всё и началось :)
Плюсую восьмицвет. Можно ли ускорить старт/загрузку?
Да. Попробуй удерживать клавишу <УС> в смысле <CTRL> при старте игры (это упоминается в FAQ). Вокала вообще не будет, и печать побежит быстрее. До кнопки <S> в игре уже добрался?
Как тебе обновлённое меню Options (цвет номер 20)?
ivagor, это всё ещё сырая альфа, и робот там полупрозрачный, и NPC ещё нет пока. Планов громадьё, но сейчас я really хочу чуть-чуть отдохнуть :) Чуть офигевший от перетолмачивания графики. Сборка, которая пошла в 0.65a была собрана буквально сегодня. Буду несказанно рад, если походишь, побродишь, меня самого там несколько моментов достаёт: в частности - очень много труб на которые надо запрыгивать IMHO. В общем, игровой процесс там всё ещё далеко несбалансирован, потому, что весь мой пар пошёл на антураж и скорость рендеринга. Рано наверное запулять в ютубу. Но когда-то мы доберёмся до заветной версии 1.0b
С Наступающим тебя! :)
PS. Демо-режим сделаю :)
Я был молод и горяч, прошу меня понять. Всех вектористов с НГ!!!
https://pp.userapi.com/c628623/v6286...iJ6cUVLIcs.jpg
Ждем авторского демо-режима.
PPC, а ты коллизии спрайтов с тайлами и с другими спрайтами по координатам определяешь?
ivagor, а там пока только координаты ГГ проверяются, а что? На самом деле, алгоритм (но не имплементация!!!) примерно такой (по памяти): берётся текущая ширина ГГ в тайлах (движок считает эту величину переменной), и определяется координата центра спрайта в пикселах. Может попасть либо на границу тайлов из которых сделан спрайт, либо - на центр тайла (когда количество тайлов в спрайте - нечётное). К вычисленному в "экранных" координатах центру, прибавляются "физические" толщины ГГ в пикселах от центра, заданные в специальном файле-описателе параметров ГГ, и полученные величины превращаются в координаты в тайлах с округлением в большую сторону. Затем на тайловой карте производится проверка на попадания "граничных" тайлов ГГ на свободное (тайлы с величинами 0-0x7F) или занятое (0x80-0xFF) место. На самом деле, всё ешё сложнее, потому, что многие вещи не вычисляются каждый раз, а предкомпилированы, и код гонится по заранее известным веткам в зависимости от нажатых клавиш. Но на самом деле, всё ещё сложнее, потому, что во время прыжка или бега, алгоритм задаёт не единичные входы, и обсчёт движения за одно обновления экрана может включать несколько итераций. Как-то так. Если у тебя остался сырок, то вся эта байда происходит в файле vp.mac. Единственно, о чём надо помнить, что кроме соударений с препятствиями, на ГГ могут действовать и другие силы и они тоже обсчитываются там-же. Так сделана гравитация и также сделан эффект движения на платформе лифта.
Подскажите, здесь приведён пример с прерыванием и выводом графики. Вроде бы разобрался, даже будет работать, если в этот момент не спрайты рисуются. Но возникает вопрос. Если стек SP был на одном адресе, то при переходе на прерывание он уменьшается. Здесь где выделено, он уже уменьшенный и imm_sp он присваивается, уменьшенный, а не каким он был изначально. Ведь выход не RET, а JP. Значит он не увеличится сам. Как это понять? Не должен ли быть он между PUSH и POP?Код:;hl адрес спрайта
Код:
;вот это вешаем на прерывание
ISR_sub
di
ex (sp),hl ;обмениваем вершину стека и содержимое HL
ld (imm_jp),hl
pop hl ;заменяем испорченное слово спрайта
push bc ;на текущее слово находящееся в BC
ld (imm_sp),sp
ld sp,ISR_sp
;здесь идет обработка прерывания
; ...
;----------------------------------
ld sp,$
imm_sp equ $-2
ei
jp $
imm_jp equ $-2
И ещё,
это то же, что иКод:ld (imm_jp),hl
jp $
imm_jp equ $-2
?Код:ld (imm_jp+1),hl
imm_jp jp $
здесь похоже на ошибку.
оно должно выглядеть так
Код:;hl адрес спрайта
Код:
;вот это вешаем на прерывание
ISR_sub
di
ex (sp),hl ;обмениваем вершину стека и содержимое HL
ld (imm_jp),hl
pop hl
ld (imm_sp),sp
;заменяем испорченное слово спрайта
push bc ;на текущее слово находящееся в BC
ld sp,ISR_sp
;здесь идет обработка прерывания
; ...
;----------------------------------
ld sp,$
imm_sp equ $-2
ei
jp $
imm_jp equ $-2