Просмотр полной версии : ROBOTZ! Releases
Здесь будут выкладываться свежие версии роботов.
59584
ROBOTZ! alpha 0.66, "автомаГическая" 01.08.2023
Игра без графики?
Это ещё не игра. Но это уже engine
Поэтому нет скриншотов?
А что, запустить и поглядеть самому сил нет? Запустить - не программать :v2_wink2:
Сделаю Вам скриншот, так и быть
Сделаю Вам скриншот, так и быть
Так и быть посмотрю.
---------- Post added at 20:40 ---------- Previous post was at 20:39 ----------
А что, запустить и поглядеть самому сил нет?
Windows7 знать не знает что такое .fdd
Я как бы тоже.
Вот пожалуйста, парочка скриншотов
Windows7 знать не знает что такое .fdd
Я как бы тоже.
Ну закачайте какой-нибудь Векторовский эмуль, скажем VV так как у него интерфейс попроще, и будет Вам счастье. Скачать можно, скажем, отсюда (раздел Эмуляторы слева на страничке кликаните)
http://www.vector06c.narod.ru/
Вот пожалуйста, парочка скриншотов
Прикольно. Ждём игру под Вектор на Chaos Constructions 2013!
Прикольно. Ждём игру под Вектор на Chaos Constructions 2013!
Пасиб, но скорее - к 14му. Тут работы ещё докучи, а времени свободного, к сожалению - нет.
А кстати, Петя Соболев с вами ещё? Привет ему передавайте если что. Просто вспомнилось, как 25 где-то лет назад он мечтал об организации этих компо-демо, забегая к нам в лабу между и после лекций. Удалось. :)
Новый год на носу, и я решил сделать всем небольшой подарок, релизнув вторую альфу.
Визуально уровни пока всё ещё не набиты спрайтами, хоть они у меня и есть, и можно подумать что изменений немного. На самом деле - их тьма. Появился collision detection, перелопачен рендерер, сделана поддержка всех возможных Векторовских процессоров до частоты 12МГц. Выше тоже будет работать, но возможны глюки со звуком.
Появились зачатки Multi-Functional Display (MFD) и отдельный рендерер MFD.
Вся графика, игры - open architecture, ничего не сжато, поэтому, можно, например заскинить собственный MFD и игра его загрузит. Появилось игровое меню, работающее меню опций, переключаемый звук и ещё много вещей о которых я уже и не упомню, но которые добавляют новые тысячи строк в сырцы.
Теперь - по интерфейсу.
Во время проигрывания мелодии перед выходом в главное меню:
<Ctrl> - пропустить музыку
<Shift> - начать играть сначала
В главном меню
<enter> - выбор опции
при запуске новой игры нажатием <ctrl> вместе с <enter> выводится отладочная диагностика загрузки уровня
<AP2> / <esc> - возврат в загруженный уровень
В меню опций
<Tab> и <Shift> + <Tab> - перемещение по опциям меню
Стрелки курсора / пробел - изменение опций
<AP2> / <esc> - возврат в Главное меню с сохранением опций.
Опция Sound Pitch при установке нулевого значения выключает звук в игре, оставляя в меню
В игре
<AP2> / <esc> - выход в главное меню
<TAB> - меняет цветовые палитры из 4х возможных, загруженных из файла уровня
<ПС> и <enter> переключают игру из оконного в полноэкрвнный режим и обратно
<Shift> - управляет движением робота назад в зависимости от опции Auto Heading в меню опций.
стрелки - движение робота. Гравитации в этом билде нет. Дверей и подъёмников в уровне - тоже. Над сим я буду очень скоро работать потому как engine уже в прошлом релизе поддерживал триггеры, events и sprite changing sequences. Просто руки до всего не доходят сразу.
Буду рад вашим комментам/соображениям/пожеланиям.
Mad Killer/PG
09.12.2012, 16:41
Круто, нaдо довeти до умa тaкую крaсотeнь!
Круто, нaдо довeти до умa тaкую крaсотeнь!
Спасибо, буду стараться довести по мере скромных сил и возможностей.
Класно! особенно понравился процес загрузки и менюхи, показалось как буд-то квэйк 1-й загружается :)
Класно! особенно понравился процес загрузки и менюхи, показалось как буд-то квэйк 1-й загружается :)
Спасибо, Ramiros. И отдельное спасибо за замечательный эмулятор, без него написание и отладка того что уже сделано была бы вряд-ли возможна. :v2_thumb: Как раз новая версия вышла, пойду закачивать.
Кстати, ROBOTZ! кроме попытки создать Quake - ощущение во время загрузки, использует ещё кое-что из другой очень известной игры Кармака. В частности, эффект мерцания фонтов отблесками красного в момент бутлода - одна из таких вещей. Другая - main menu layout также намеренно повторяет layout из этой супер популярной в 90х игры. ;)
Не рекомендуется использовать градации красного в главном меню. С этим цветом надо быть поаккуратнее. Уж слишком он по глазам бьет, вплоть до ощущения песка в глазах. Хотя смотрится довольно стильно.
Не рекомендуется использовать градации красного в главном меню. С этим цветом надо быть поаккуратнее. Уж слишком он по глазам бьет, вплоть до ощущения песка в глазах. Хотя смотрится довольно стильно.
"Не рекомендуется" звучит как ссылка на некий нормативный документ.
Возможно, такое main menu и не пройдёт охрану труда, или MS Health CUI, но до красного были последовательно рассмотрены серебристые и голубые тона. Оба варианта были категорично отвергнуты моими потомками с предложением рассмотреть красную палитру, коя была восторженно принята подрастающим поколением.
ЗЫ. Так как игра построена на концепции open architecture, палитры находятся в заголовке файлов .IMG (7 палитр) и могут быть проправлены. Можно также заменить любую картинку на свою.
Конвертер картинок авторства PPC - внутрь не смотрел, могу только предположить, что он написан на C.
ivagor, вы абсолютно правы, на С для компилятора SuperSoft. Правда, не написан а налабан за две недельки без всяких мыслей об оптимизации. Цели написать оптимизированный код не стояло, мне нужно было быстро слепить toolkit для конвертации и двигаться дальше, что конечно сказалось на быстродействии.
Выложу-ка я все сырцы, мне не жалко, а кто-нибудь, если захочет, сможет пооптимизировать.
В сущности, всё, что надо оптимизнуть - это тело функции
BPP4Cvt(fdOut,fdIn,_offset,w,h,_rle,_verbose)
FD *fdOut;
FD *fdIn;
unsigned _offset; /* file offset to pixel data */
unsigned w; /* should be less than 0x101 */
unsigned h; /* should be less than 0x101 */
unsigned _rle; /* RLE (for future extension */
, находяшееся в файле bmpcvt.c. Эта функция перетолмачивает BMP в 32KiB Векторовской видеопамяти.
Это - основной байтоповорачиватель и битозадвигатель и основной bottleneck при конверсии. Кстати, на 50МГц, по крайней мере у меня, он уже достаточно проворен.
С для компилятора SuperSoft
Пробовали C vinxru?
Пробовали C vinxru?
Нет, к сожалению не пробовал. Одно время я с большим интересом следил за тем, как vinxru писал свой С компилятор. Интересно будет попытаться перекомпилить им этот код. Правда, для этого наверное придется как минимум сделать порт стандартной библиотеки для его компилятора потому что Supersoft генерит код с Pascal calling convention и линковать выход с их стандартной библиотекой без перекомпиляции не выйдет.
Это в том случае, если vinxru ещё не прикрутил какой- нибудь stdlib для CP/M к своему компилятору. Интересный проект, но не возьмусь.
Очень сильно погряз в своем. Сейчас с переменным успехом борюсь с дизайном модели повреждений. Если получится, будет стибово, а если не получится, то буду упрощать. В данный момент моделирую изменения температуры электролита в батареях робота от силы тока в моторах ;-). Музон и звуковые эффекты заброшены, хотя мне до боли необходимо переделать хотя-бы STM tracker для проигрывания музыки с квазидиска. Тоже самое предстоит сделать и с движком для звуковых эффектов. Каким он будет, этот движок я ещё даже не решил, но облизываюсь на идеи Сергея Новикова, или попытку их дальнейшего развития.
В данный момент моделирую изменения температуры электролита в батареях робота от силы тока в моторах ;-)
Подготовка к 1 апреля уже началась :) ? Сегодня что-то и на другом форуме тоже пару забавных текстов сгенерировали, наверно уже пора.
Звуковые эффекты через таймер IMHO будет непросто, если по прерываниям, а не проигрывать сэмплы.
Подготовка к 1 апреля уже началась :) ?
Я серьёзно. Просто хочется сделать занятную damage model, а не простой декремент счетчика жизни. Получится или нет- другой вопрос, но к 1му апрелю всё станет ясно :-)
Звуковые эффекты через таймер IMHO будет непросто, если по прерываниям, а не проигрывать сэмплы.
Проигрывать сэмплы, к сожалению, не подходит. Только по прерываниям, причём иногда без оных, по вызову.
Проигрыватель должен переставить стек, переключить банк, достать следующую музыкальную "команду" из памяти квазидиска, поинтерпретировать её и сыграть.
Если заинтересовало, отпишусь в личку потом. Сейчас надо убегать.
Только по прерываниям, причём иногда без оных, по вызову.
Может тогда наоборот? В смысле эффекты через AY, а простенькую музычку (например через проигрыватель Новикова) через таймер.
Если заинтересовало, отпишусь в личку потом.
Спасибо за доверие, но личку я в текущей реинкарнации отключил. Да и пока не могу предложить ничего конструктивного по данному вопросу. Пробовал выдавить из ВИ53 некое подобие звуковых эффектов по прерываниям - вышло довольно по-детски. Хотя то, что у меня пока не получилось ничего стоящего, не значит, что это невозможно.
А вот если понадобится распаковщик, то в этом направлении есть отдельные успехи. В воскресенье пару часов или даже больше думал над дальнейшей оптимизацией распаковщика MegaLZ b2m. Удалось сбросить больше десятка байт и скорость чуть увеличилась. Для ВМ85 и ВМ1 получается еще лучше.
---------- Post added at 10:23 ---------- Previous post was at 10:20 ----------
Обращение к модераторам - последние сообщения, наверно стоит перенести в тему ROBOTZ.
Очень топорно переделал проигрыватель STM на чтение с квазидиска. Этот вариант можно (и нужно) оптимизировать, но надеюсь, что он будет полезен.
Очень топорно переделал проигрыватель STM на чтение с квазидиска. Этот вариант можно (и нужно) оптимизировать, но надеюсь, что он будет полезен.
Здорово!
Спасибо, ivagor, вечером погляжу. Я не отвечал не потому, что такой невежливый, а ожидал, что модераторы откликнутся на ваш призыв, и перенесут наше обсуждение из 6128 сюда.
Отвечу на ваш вопрос в той ветке. Всё-таки отчего-то не хочется задействовать AY под звуковые эффекты. Это - несмотря на то, что у меня имеются тулзы под Винду для создания звуковых эффектов для АY на Спектруме.
По поводу музыки: уровень вообше рендерится с запрещёнными прерываниями, вызывая процедуру проигрывания после выполнения определённого количества команд. Так оказалось плавнее с точки зрения рендеринга, и быстрее с точки зрения звука. Иначе рендерер будет вынужден постоянно разрешать и запрещать прерывания при копировании спрайтов стеком в видеобуфер. Как показала практика (критерий истины), при этом возможны потери до 7 процентов быстродействия.
Все спрайты, не только уровень но и оверлеи, и NPC и главный герой сидят в банках квазидиска.
Что можно получить от таймера? Как вы уже сказали - несколько детское звучание. Бипер, к сожалению использовать в помощь в качестве генератора шума видимо не получится, всё очень зажато с точки зрения быстродействия.
Надо-бы экспериментировать с движком С. Новикова на предмет попытки создания им спецэффектов в игре. Сомнения только по поводу, насколько это всё замедлит.
Сейчас в роботах движок звуковых эффектов от ППЦлиба, который я написал триста лет тому назад. Его можно конечно начать оптимизировать, но это не то. Оно играет из основной памяти, без девиаций частоты и вторичных гармоник.
Еще такой (очень специфический) вариант возможен - музыка через Sound Tracker (разъем ВУ), звук через R-Sound 2 (разъем ПУ) или наоборот. В EMU RSound поддерживается и "подключен" в конфиге 6128. По аналогии можно "подключить" и в любом другом конфиге. Можно ли в текущей версии EMU заставить их работать одновременно - не знаю, но отладить можно и по отдельности. Кстати, в stmviewer вывод запараллелен на Sound Tracker и R-Sound.
Забыл написать, что измененные мною места я пометил тремя восклицательными знаками (!!!). При использовании проигрывателя не в stmviwere стоит добавить в начало MusicInit (например после di)
push h
lxi h,FirstTime
shld SetJmp+1
pop h
Кстати, в stmviewer вывод запараллелен на Sound Tracker и R-Sound.
То-то я вчера пытался вкурить, а зачем она настраивает управляющее слово ПУ (D27 8255) засылая туда 88h.
Забыл написать, что измененные мною места я пометил тремя восклицательными знаками (!!!).
Это я сообразил ;-). Спасибо.
Небольшой ответ послал почтой. Раньше субботы серьёзно засесть, к сожалению, не смогу.
Примерно неделя-две до альфы
Выкладываю третью альфу.
Всё управление осталось таким-же как в предыдущей версии. По окончании игры, <AР2>/<ESC> возвращает в главное меню.
Введен расчёт рассчёт реакций опор с учётом гравитации в месте нахождения робота в реальном времени. В принципе, возможно иметь уровень с гравитационными градиентами, но в деме такого нету.
Появилась модель повреждений, обсчитываемая также по всем осям в реальном времени и выводимая на Instant Status панель. Выводится 20 параметров одновременно (cool).
Ведётся учёт разряда батарей, силы тока в обмотках, повреждения от ударов и от перегрева обмоток двигателей, вплоть до сгорания последних при длительной нагрузке.
Ходьба/прыжки также нагревают двигатели, так что останавливайтесь, давая движкам охладиться когда значение повреждений, тока в обмотке или температуры начнёт мерцать и робот окрасится багрянцем. Режим перегрева обмоток / превышения допустимой температуры и порога повреждения можно отключить, выставив опцию Instant Damage Rating в 0. Если установить Instant Damage Rating в 1, то проверяться будет только превышение силы тока в обмотках. Если Instant Damage Rating = 2, то проверяются все возможные повреждения: от ударов, роста температуры, максимально допустимой силы тока. Осторожнее с прыжками в районе торчащих из потолка балок, можно разбить роботу голову о косяк.
Появилась поддержка подъёмников, можно ездить по этажам, встав на платформу. Внимание с подъёмниками есть баг: при выходе в главное меню и возврате обратно, робот может свалиться с платформы. Я об этом в курсе (связано с алгоритмом обсчёта сил и реакций опор). Фикса этого явления пока не будет. Также пока не обсчитываются удары дверями / подъёмником по голове роботу. Ну ещё при падении с разных высот, повреждения пока одинаковы.
Появились события. На них в основном повешены 24 одновременно крутящихся вентиляторов, ну и одну дверку сделал для примера. В уровне сейчас 26 событий, управляющих движением двери, вентиляторов и сменой тайлов в "кирпиче" рядом с дверью. Изменяется 102 тайла, причём движок легко тянет изменения в районе 250-400 тайлов, практичечки без просаживания FPS. Количество событий пришлось ограничить не из-за быстродействия, а из-за плавности музыки. Опция "Events Per Frame" управляет количеством событий за кадр. Из-за музыки, поставлена в 0x10 (16 событий за кадр), поэтому вентиляторы крутятся с половинной скоростью. Events Per Frame равное 0 устанавливает обсчет всех принятых событий за один кадр. Визуально это отразится на скорости вентиляторов и дверей, но музыка будет choppy. Впрочем, можете попробовать поиграться с этой опцией. Вентиляторы несколько криволопастные. Я в курсе, и буду это лечить по мере сил.
Опция Complex Thermal Model добавляет дополнительный рост температуры под нагрузкой.
В меню опций появилась бегущая строка-подсказка. Текст выводится из файла options.txt. Размер текста ограничен 2K.
Планы для следующих пары версий:
- Полная переработка воспроизведения музыки (загружаемые драйверы)
- Телепортеры
- Power-Ups (сейчас игра кончается при разряде батарей)
- Триггеры (кнопки, блоки, рычаги)
- Inventory (антиграв и jet pack обещаю точно)
Оружия и врагов в 2х следующих версиях не будет - без них проблем хватает.
- Убиение дверями. Возможно - предметы, которые можно двигать, но пока не обещаю.
А в общем, всё опять удалось удержать в тех же FPS, при этом производя немеряно обсчётов и выводя всё это барахло на экран.
Как всегда, буду рад вашим комментам / предложениям / критике и вааабче :-)
Enjoy!
а сожно это выложить в виде ютубовского ролика? интересно же
Я, к сожалению, на ютубе не зареген, и не до конца представляю пост-процессинг в mp4, или что там ей нужно. Могу попробовать, конечно, если кто-нибудь пояснит мне, что и как нужно сделать с видео чтобы выкладывалось. Я уже в следующей версии, с проправленными, насколько это удалось, вентиляторами. Наверное, стоит выложить её видео, чтобы не так пугало кривыми лопастями.
PPC, я могу выложить — расшарь мне запись на DropBox-е, или чем-нибудь подобном, я залью.
svofski, а каким кодеком лучше писать из VV эмулятора? Я у себя вижу MS RLE, CinePak, MS Video1, Intel IYUV и Uncompressed. На компе седьмая Вынь 64 битная.
Видимо, надо Uncompressed чтобы во что угодно жать можно было, но меня размер пугает.
Или может лучше какой-нибудь хитрый кодек сразу поставить?
Думаю, многим будет интересно узнать как правильно оцифровать видео с эмуля, поэтому не в личку.
Есть неплохой кодек со сжатием без потерь HuffyYUV. Насколько я помню, идет в комплекте полной версии K-Lite Codec Pack (только при установке codec pack нужно убедиться, что он выбран в настройках)
Удобен тем, что потом можно легко сделать "нарезку" в чем-то типа VirtualDub и в нем уже перекодировать финальный результат в mp4
Xvid самое оптимальное, можно установить отдельно.
VV делает видео файл без звука, звук будет в отдельном файле Wav. Если нужно видео со звуком, то надо склеить в VirtualDub-е.
Спасибо всем. Попробую поцифровать на этой недельке. Скорее всего-ближе к выходным. Сейчас роботы безбожно разобраны по винтикам: освобождаю основную память, запихивая всё что можно и нельзя в банки квазидиска. Как только добью, оцифрую видео, сведу дубом в mp4 и дам знать svofski, ну или сам попробую в ютубу залить.
Для ютубов лучше сразу H.264:
http://support.google.com/youtube/bin/answer.py?hl=en&answer=1722171
Можно еще CorePNG -- он делает сжатие без потерь, так что я смогу поиграться с параметрами для ютубы локально.
Для ютубов лучше сразу H.264
Можно еще CorePNG
svofski, отлично - буду пробовать эти кодеки.
Можно еще CorePNG -- он делает сжатие без потерь, так что я смогу поиграться с параметрами для ютубы локально.
Привет,
Оцифровал кодеком CorePNG v.082 и расшарил для тебя видео и аудио в дропбоксе. Надеюсь, получилось ничего и для ютубы сойдёт на первое время.
Вижу, посмотрю как только появится минутка.
Только сразу предупреждаю, что я далеко не Феллини. Получился какой-то отладочный run. По-моему, очень затянуто, много мельтешений и повторения. Сейчас, наверное, уже бы сделал по-другому, давая время послушать музыку в менюхах и не прыгая между ними как тушкан. В общем-то можно и переделать, если ещё не смонтировано, но это затянет всё ещё на несколько дней.
PPC, давай бету видео в массы!
потом будешь лоск наводить
PPC, давай бету видео в массы!
потом будешь лоск наводить
jerri, Ok, пойдём с этой фильмой. Вот svofski смонтирует, будем посмотреть.
Фильма:
http://www.youtube.com/watch?v=v8Q2DY7P2Ww
Персональное спасибо svofski!
Симпатично
можно предложение по дизайну?
Текст в меню, опции и бегущие строки должны быть выделены цветом ярче фона. в идеале белым. Иначе видно плохо
Спасибо.
К сожалению, видео вышло достаточно смазанным, даже цвета стали грязноватее. Причём проблема не в исходном видео, и даже не в mp4. Если смотреть mp4 локально, всё заметно резче. Это ютуба похоже какой-то фильтр типа бикубик ресамплера делает, и всё выглядит жуть каким размытым. Мы как раз со svofski обсуждаем, что можно сделать чтобы победить ютубу. Возможно, пережать в 1080 progressive поможет.
Текст в опциях и бегущей строке на самом деле полупрозрачный. Через него видно задний план, но, к сожалению, из видео это не совсем ясно. Сейчас текст выводится яркостью на бит выше. Попробую поднять на 2 бита чтобы оттенить сильнее.
Игрулей занимаюсь на выходных, когда время есть. Там ещё работать и работать до победы. Но зато уже доказано, что на Векторе можно сделать игру с двойной буферизацией в 4х цветах и с горизонтальным скролом.
Симпатично
можно предложение по дизайну?
Текст в меню, опции и бегущие строки должны быть выделены цветом ярче фона. в идеале белым. Иначе видно плохо
Ну как для Вектора конечно наверное круто, но по дизайну да, предложения конечно к месту были бы.
К сожалению, видео вышло достаточно смазанным, даже цвета стали грязноватее. Причём проблема не в исходном видео, и даже не в mp4. Если смотреть mp4 локально, всё заметно резче. Это ютуба похоже какой-то фильтр типа бикубик ресамплера делает, и всё выглядит жуть каким размытым.
По поводу видео можно почитать тут -> http://support.google.com/youtube/bin/answer.py?hl=ru&answer=1722171&rd=1
Я вообще подготавливал для загрузки в Camtasia Studio, там есть сразу опция подготовить видео для YouTube.
Ну как для Вектора конечно наверное круто, но по дизайну да, предложения конечно к месту были бы.
Конечно / наверное / совсем не круто / полный отстой / автора на выселки - это вы уж определяйтесь сами.
А насчёт предложений, и не только по дизайну - я завсегда приветствую, и в каждом релизе об этом прошу.
Так давайте, предлагайте, а то "были бы" к месту. Тем более, что это даже не ранняя бета, а где-то середина альфа-цикла. Не обещаю, что будет всё именно так как именно вы предлагаете, но обещаю что учту.
Там, кстати, не только с графикой, но и со звуком ещё конь не везде валялся. Например, звук неприятно обрывает при переходах с меню на меню. Думаете, я не в курсе? Тулкита, кстати, тоже особо нет, его походу писать приходится.
Повторю только, что видео это (мягко говоря) не совсем отражает как оно выглядит на реале, эмм... эмуле.
Я предвидел эти проблемы с ютубой, поэтому и не стал сам оцифровывать, а попросил "помощи клуба".
По поводу видео можно почитать тут -> http://support.google.com/youtube/bin/answer.py?hl=ru&answer=1722171&rd=1
Я вообще подготавливал для загрузки в Camtasia Studio, там есть сразу опция подготовить видео для YouTube.
Спасибо, этот линк есть в 37м посту ветки, и о нём были все в курсе, только это как-то не очень это помогло похоже. Насчёт конкретных прог - их море, но имхо ютубе должно хватить простого дуба или какой-нибудь DV Studio.
Спасибо.
К сожалению, видео вышло достаточно смазанным, даже цвета стали грязноватее. Причём проблема не в исходном видео, и даже не в mp4. Если смотреть mp4 локально, всё заметно резче. Это ютуба похоже какой-то фильтр типа бикубик ресамплера делает, и всё выглядит жуть каким размытым. Мы как раз со svofski обсуждаем, что можно сделать чтобы победить ютубу. Возможно, пережать в 1080 progressive поможет.
Текст в опциях и бегущей строке на самом деле полупрозрачный. Через него видно задний план, но, к сожалению, из видео это не совсем ясно. Сейчас текст выводится яркостью на бит выше. Попробую поднять на 2 бита чтобы оттенить сильнее.
Игрулей занимаюсь на выходных, когда время есть. Там ещё работать и работать до победы. Но зато уже доказано, что на Векторе можно сделать игру с двойной буферизацией в 4х цветах и с горизонтальным скролом.
На мой взгляд это имитация ТВ :)
Будет ли в игре более навороченная анимация? я просто не знаю сколько памяти у Вектора
Спич вначале - лишний :)
На мой взгляд это имитация ТВ :)
Вы разгадали мой маленький секрет (с) "Донна Роза".
Это как-бы взгляд из нашей реальности в мир роботов.
Правда, пока там простые рамки, до всего руки не доходят просто, а проект достаточно большой. А с палитрой я там попробую поиграюсь, наверное ещё на 1 бит по яркости можно будет развести.
Будет ли в игре более навороченная анимация? я просто не знаю сколько памяти у Вектора.
Надеюсь. Если не упарюсь это всё рисовать, конвертить и т.п.
У Вектора вот такой расклад:
64К основной памяти, из них
32К видео ОЗУ, сформированное из четырёх 8K видео плоскостей подобно EGA (max. 16 цветов) Игра использует 2 видеобуфера по 16К каждый. Отсюда и 4 цвета вылезают (по 2 плоскости на буфер)
Остаётся 32К под основной код. Там только код, которого сейчас где-то 17К.
256К виртуальный диск, разбитый по 4 64К страницы с доступом стеком, или по 4 16К окна в каждом банке с доступом командами обращения к памяти, или комбинированно 16К окно и 64К стеком.
В 4М банке сидит операционка. Там-же я сохраняю CP/M BIOS в промежутках между файловыми операциями. Во время файловых операций, CP/M BIOS сидит в последних 8К видеопамяти, что уменьшает её с 32х до 24К (3 плоскости), и, соответственно, уменьшает количество цветов с 16 до 8 во время файловых операций.
В 16К окнах банков по адресам A000-DFFF можно исполнять код, но одно уже занято ДОСом. В остальных будут всякие музыкальные драйвера и ещё кое-что.
Сейчас есть:
1. Совсем задний план (обрамление, multi-functional display и т.п.)
2. задний план, в котором будут всякие движущиеся тайлы, ну типа вентиляторов, дверей и т.п.
3. средний план, в котором сидит робот, и будут сидеть другие "герои". Под них выделено 16К на главного героя и 24 на "врагов". В среднем плане все спрайты - с альфа каналом.
4. Если позволит быстродействие, будет ещё один план - передний overlay (как-бы ещё одна карта уровня). Всякие там колонны, стеклянные штуковины полупрозрачные и т.п. Тут тоже все спрайты с альфой. Под них выделено 32К в 4м банке, потому что именно столько надо под альфа-спрайты для 256 тайлов. Эта байда как раз занимает начало 4го банка. Как раз сейчас отлаживаю рендеринг этого слоя. Двигающихся предметов в нём не планирую, ну по крайней мере пока.
Так что графики планируется вагоны. Офигею рисовавши альфа маски :)
Чтобы было попонятнее где чего сейчас лежит - вот текущая карта памяти из файла config.inc
;================================================= =================
; MEMORY LAYOUT, top to bottom
; 4 64Kib-memory banks of 5 are allocated for the game:
;================================================= =================
; - Bank 0 ---- main and video memory -----------------------------
;================================================= =================
; 0000-0100 ISR vectors, CPM area and hooks, etc.
; 0100-HEAP CODE, DATA and STACK segments
; HEAP-7FFF HEAP: MFD.lvl, .stm, sprite and font *headers*
; 8000-FFFF 32K Video RAM (2 frame-buffered 16K banks)
;================================================= =================
; - Bank 1 ---- Options and Sound Engine
;================================================= =================
; 0000-5FFF Options menu image (24K) OPTIONS.IMG
; 6000-9FFF MFD and background sprites (16K) MFD.SPT
; A000-DFFF 16K Sound engine + current sound data / FntPat
; E000-F7FF Options menu music (6K) OPTIONS.SND
; F800-FFFF Options ticker text (2K) OPTIONS.TXT
;================================================= =================
; - Bank 2 ---- Game Menu, Terminus Sprites, Sound Engine and Data
;================================================= =================
; 0000-5FFF Menu image (24K) MENU.IMG
; 6000-9FFF 64 Terminus sprites (16K), 256K each
; A000-DFFF 16K SFX Engine + LEVELXX.SFX
; E000-FFFF Menu music (8K) MENU.STM
;================================================= =================
; - Bank 3 -- at boot loads PCM sound, then used for level data ---
;================================================= =================
; 0000-3FFF 16K 256 level tiles (2x2x16 = 64 bytes each)
; 4000-9FFF NPC sprites (24K)
; A000-DFFF 16K Level map - up to 256x64 tiles
; E000-FFFF level music (8K) LEVELXX.STM
;================================================= =================
; - Bank 4 --- System Bank: MicroDOS / GML ------------------------
;================================================= =================
; 0000-7FFF 32K LEVEL.IMG, then 256 overlay tiles (4x2x16 = 128b)
; 8000-87FF system.fnt
; 8800-9FFF compo.fnt
; A000-DFFF *** BDOS MicroDOS (16K) ***
; E000-FFFF Relocated MicroDOS BIOS (8K)
;------------------------------------------------------------------
Новая попытка победить ютубную мясорубку:
http://www.youtube.com/watch?v=9AIxD-EJmEM
(На всякий случай, если это не происходит само собой, надо нажимать на шестеренку и выбирать там 480p)
Стало лучше, но пока все равно еще не супер. PPC — если ты не против я предыдущее видео удалю.
Стало лучше, но пока все равно еще не супер. PPC — если ты не против я предыдущее видео удалю.
svofski, я не против, как раз за удаление предыдущей версии так как в этой стало гораздо лучше хотя-бы с точки зрения чёткости. Правда, местами теперь стало choppy. Я сначала подумал что это из-за скорости пересылки, но места те-же самые и явно видно, что они коррелируют со scene transitions. В начале фильмы, в главном меню, каким-то образом подсвечивается лишь половина букв. Но по-любому это огромный прогресс в сравнении с предыдущей версией с точки зрения резкости картинки.
Ок, стер старое. Про чоппинесс -- не знаю, я не ощущаю. Тебе, как автору творения, конечно, виднее. На будущее -- кодек FFV1. Лучше обходиться без CorePNG, он какой-то древний и плохо поддерживаемый. FFV1 более-менее стандартный, беспотерьный, неплохо обращается со скринкастами и, главное, ютуба его понимает.
У меня явные чопы при просмотре. Но, возможно, это декодер дуреет на транзишенах.
Да, похоже с PNG вышла промашка, но так заказывали :)
В след. раз попробую прямо MPEG кодеком. У меня ещё мать десктоповая кукукнулась уже с месяц, а то я бы наверное и пережать отважился сам. Под ютубу никогда конечно не делал, но домашнее видео когда-то цифровал пентабайтами, и подобного типа траблы ловил.
Не не, лучше FFV1. Он специально скринкастный.
Ок, спасибо! Почитал сейчас про FFV1. В след. раз пойду с ним.
Лан понятно :) чо по игре то?
может ее и на спек портировать? :)
Не очень понял. В смысле, портировать альфу?
Или, когда в бета-стадию перейдёт. И на какой спек? 128 или сразу на эву?
PPC, нет не альфу :) альфа не играбельна
полностью когда напишешь
спек 128
а эва не спек.
jerri, ну это когда ещё будет. К тому времени ты подпись 3 раза сменишь.
Я подумывал про порт на MSX2. А вообще, было-б что портировать, а куда-найдём :-)
Здесь есть кто живой? Если да, то прогревайте компы и муляторы.
Четвёртая альфа была в тубе и не будет выложена.
Зарелиживаю пятую альфу роботов. Это-первая альфа в которую можно поиграть. Коротко о том, что появилось:
- Двери на замках
- Ключи к дверям (анимированы, с альфой)
- Телепортер (анимирован, пока без альфы и использует те-же спрайты, что и подъёмник)
- Ключ к лифту (анимирован, с альфой)
- Триггер включения телепортера (анимирован, с альфой)
- Дополнительный layer с альфа-каналом и анимированной графикой
- Power-Ups: (анимированы, с альфой) батарейки восстанавливают энергию (пока-по всем осям и полностью), болты восстанавливают повреждения робота
- Яркость текста в меню опций увеличена на 1 бит
- Пофикшено падение с подъёмников после смены палитры или выхода в главное меню и возврата в игру.
Скорость осталась практически как в 3ей альфе (это при том, что выводится ещё один слой с альфа-каналом).
- Убраны следующие отладочные режимы:
Events Per Frame control (чтобы не читить, замедляя события)
Level Overlay On/Off (оверлей выводится всегда)
Pixel Shader control
-Убран полноэкранный режим
Для оценки прилагаемого уровня, привожу данные по событиям, триггерам и последовательностям отрисовки из заголовка файла уровня:
_LH_TRG: DW 37 ; number of trigger tables of SIZ_TRG
_LH_MVT: DW 4 ; number of movement tables of SIZ_MVT
_LH_EVT: DW 50 ; number of event tables of SIZ_EVT
_LH_SEQ: DW 790 ; number of sequence tables of SIZ_SEQ
То-бишь, в уровне 37 триггеров и 50 событий.
Как играть. Задача-найти 4 ключа и добраться до выключателя, который закончит игру. Придётся прыгать, телепортироваться, оценивать перегрев и повреждения робота. Иногда надо будет поторопиться, иногда - чуть покумекать, что делать дальше. Уровень абсолютно проходим, безвыходных ловушек нет. Только-что прошёл его сам с удовольствием.
К сожалению, inventoty MFD ещё не сделан, поэтому предметы придётся запоминать. Instant Status MFD работает пока как обычно, в текстовом режиме. В бете, конечно, все MFD будут в графике.
Из известных багов наиболее гаденький - срыв мелодии в меню опций. Остальное вроде пофиксил более-менее, но мог что-то просмотреть, особенно касательно вывода состояния повреждений и заряда батарей. В общем, кто-что найдёт - буду только рад. Весь баглист не привожу.
Что планируется дальше?
- Inventory MFD
- Антиграв/Jet Pack
- Общая оптимизация движка (ну это идёт постоянно)
- Возможно - лазанье по лестницам
- Возможно - морф робота и доп. функции (по типу метроида)
- Разные уровни гравитации
- Загружаемые параметры повреждения / заряда батарей (это-обязательно)
- Возможно - звуковые эффекты, но скорее это будет в 7й альфе.
В общем, заценяйте на здоровье, и как всегда буду рад вашим комментам, предложениям, пожеланиям, впечатлениям.
Обнаружился очень мерзкий баг с загаживанием нижнего этажа тайлом от одной из дверей. Как я и предполагал, причина - в функции отрисовки разряда батарей и повреждений. Вроде всё поправил. Заодно добавил пару-тройку несущественных оптимизаций на предмет скорости. Стало плавнее, но музон хромает. Однозначно придётся когда-нибудь ставить его на таймер чтобы исправить хромоту.
Так как серьёзных изменений нет, версия будет 0.51a. Как говорит svofski, "У нас теперь Новый Год чаще".
PS. Перевыкладываю версию со слегка более стабильным звуком.
Кто-нибудь уже уровень прошёл? Пожалуйста, впечатления в студию, а то без фидбэка не понять, на что обращать внимание. Также прошу ваши идеи по поводу того, чего бы хотелось видеть в игре. Для народа ведь пишется. У меня, конечно, есть кое-какие соображения по поводу концепт-дизайна на будущее (вплоть до анимации персонажа), но намеренно не хочу оглашать весь список. Хотелось-бы услышать Ваши соображения.
Покамест ускорил движок ещё почти на кадр в секунду woo-hoo!
Вот сделаем нормальные спрайты для телепортера, и наверное правда можно видео прохождения уровня на ютубу будет выложить. А пока, пожалуйста, ваши соображения на предмет, о чём мечталось-бы.
Под что это написано?) может у меня и есть такой девайс)
Под что это написано?) может у меня и есть такой девайс)
Под любой из клонов Вектор-06ц (не Криста и не Вектор-Старт) с квазидиском на 256К по Кишинёвской схеме и, по-крайней мере, одним FDD и операционкой МикроДОС.
Вот список эмуляторов на которых я пока смог проверить гаму:
emu от b2m
Virtual Vector от Ramiros
Vector-06cc на Altera DE-1 от svofski.
Процы: 8080,8085, КР-580ВМ1, z80. Tактовые частоты проца: от 3х до 18MГц.
Доп оборудование: рекомендуется AY8910/12, поддерживается Омский RTC на MC146818.
Было-бы замечательно, если бы кто-нибудь попробовал запустить гаму на реале.
PPC, Обязательно поиграю и напишу свои пожелания, только в конце августа или даже в сентябре, сейчас я в разъездах :) но спасибо за старания!
Чуток поиграл, пока только взял ключ и болт, как открывать двери непонял.
Сразу замечание - лифт желательно останавливать ненадолго в крайних точках.
Чуток поиграл, пока только взял ключ и болт, как открывать двери непонял.
Сразу замечание - лифт желательно останавливать ненадолго в крайних точках.
Для каждого ключа есть соответствующий замок. Обычно, он рядом с дверью, но не обязательно (hint). Для открывания двери закрытой на замок, необходимо найти ключ, а потом найти замок и встать так чтобы замок был за роботом. Есть двери без замков, они обычно открываются сами, когда робот напротив двери. У каждой двери своя задержка в состоянии "открыто". Первая дверь, которую можно открыть - достаточно hardcore, но пройти можно. Я уже так наловчился, что прохожу с первого-второго раза, а поначалу только убивал робота, даже болт не помогал. Правда у меня версия несколько пошустрее, и на ней играть полегче. Я её скоро выложу, там изменений совсем немного. Трудный месяц, много работы.
Про лифт подумаю, спасибо. Наверное сделаю задержку. Пока, чтобы приноровиться, можно научиться "выпрыгивать" с лифта на ходу. Это легче, чем выходить, но при прыжке будут небольшие повреждения, да и разряд батарей выше.
Выкладываю более быструю версию, о которой писал выше.
Кроме оптимизации по скорости, добавлены
'щит управления телепортером'
'силовое поле' взведённого телепортера.
ключ включения телепортера.
В принципе прохождение этой версии уже имхо можно показывать в ютубе.
Страшный хардкор. В первую дверь смог пройти всего два раза за достаточно большое количество попыток.
Страшный хардкор. В первую дверь смог пройти всего два раза за достаточно большое количество попыток.
Я даже первую дверь непрошел :) нелюблю трудные игры
нелюблю трудные игры
Честно говоря - я тоже, но тут просто из принципа решил хотя бы в дверь войти (на уровень меня уже не хватило), все же других игрушек на вектор сейчас не делают.
PPC, Сделай обязательно выбор уровня сложности, чтоб можно было нетолько хардкор, но и просто прогулка по уровню.
PPC, Сделай обязательно выбор уровня сложности, чтоб можно было нетолько хардкор, но и просто прогулка по уровню.
Принял к сведению. На самом деле, с первой дверью весь хардкор только в том, что времени не хватает, если рано впрыгнуть на подъёмник. Это связано с продолжительностью нахождения двери в положении "открыто". Почти 100% алгоритм открывания двери №1 с первого раза:
1. Спуститься на подъёмнике вниз на 1й этаж и взять ключ справа в углу.
2. Подняться на 2й этаж и встать на 1 тайл справа от замка.
3. Дождаться, когда подъёмник покажется снизу и будет примерно на тайл / "пол тайла" ниже уровня этажа
4. Нажать стрелку влево и удерживая её стрелку вверх в момент, когда робот минует тайл с замком чтобы впрыгнуть на движущийся вверх подъемник. Надо оказался на левой стороне движущейся вверх платформы.
5. За 1 тайл до 3го этажа нажать стрелку влево и удерживать, пока робот не пройдёт в дверь
Я умудряюсь сейчас пройти ещё 3 тайла и взять батарейку за дверью до момента, когда дверь №1 начнёт закрываться, так что не такой и хардкор, всё дело-в точной координации.
Задержка для каждой двери-это свой параметр, который хранится в карте уровня в соответствующих последовательностях отрисовки спрайтов двери.
Есть 2 варианта как я могу сделать разные уровни сложности:
1. Сделать тот-же самый уровень отдельным файлом, но с другими задержками. Достоинство в том, что можно точно подобрать тайминги под каждую последовательность событий и иметь сколько угодно версий уровня. Недостаток - место в каталоге файлов CP/M и расход дискового пространства.
2. Сделать так, чтобы игровой движок понимал скажем несколько настроек сложности, как в Думе по типу
I am too young to die
Rookie
Hardcore (kill em all)
Мне 2й вариант нравится больше, но это-дополнительный кодинг. Ваше мнение, какой вариант делать?
К сожалению, в связи с персональными траблами весь сентябрь проект был заброшен.
В ноябре сделал inventory MFD, пофиксил несколько мерзейших багов, которых вы с ivagor не увидели потому, что уровень не стали проходить. В частности, получение повреждений при движении на 2м подъёмнике.
Могу на днях выложить промежуточную версию с пофикшенной дверью (дам ещё секунду на положение открыто для двери №1), пофикшенными подъёмниками, музыкой в меню без сбоя, inventory MFD и загружаемыми параметрами повреждений главного героя.
Ещё там наконец-то стали появляться зачатки графики уровня (не весь фон заполнен 4мя тайлами поэтажно).
Из обещанного для следующей версии там нет только антиграва/jet pack.
Выкладывать?
Сейчас вот прямо пишу загружаемые музыкальные драйвера чтобы можно было по желанию переключать весь движок с stm на, скажем, pt3.
Необходимо будет сделать редактор уровней. Наваляю для PC на WTL-e как-нибудь, иначе уже очень тяжело руками уровень творить. Так-что будут задержки. Наверное, стоит выложить промежуточный апдейт.
ИМХО по поводу составляющих сложности.
1) Время нахождения дверей в открытом состоянии. Наверно проще с уменьшением сложности умножать на константу время задержки. Или более общий вариант (как 1.) с индивидуальной (ручной) подстройкой задержки для каждой двери.
2) "Хрупкость" робота. Вплоть до введения чита с неуязвимостью.
3) На низком (низких) уровнях сложности можно показывать индикатор фазы открытия двери при активации ключа.
4) Наличие/отсутствие подсказок и их подробность. Мне вот сначала пришлось выяснить, к какой двери подходит ключ. Потом после долгих попыток пришел к тому, что надо стоять за замком и проходить мимо него при появлении подъемника и как оказалось, это "официально одобренный вариант" :). Тут как-бы мини головоломка+ловкость. Головоломка - это ладно, а вот ловкость в сочетании со значительной "вязкостью" управления - уже не здорово. А еще ведь и робот хрупкий. Например я после первого вхождения в дверь имел глупость зайти назад и помереть, не посмотрев левую часть уровня, пришлось второй раз напрягаться.
Забыл - еще можно разное число лечилок (вплоть до полного отсутствия) на уровне размещать. Может еще что упустил.
Наверно проще с уменьшением сложности умножать на константу время задержки.
Этот вариант мне нравится больше. Но не всё так просто, как кажется. В последовательностях задержек не определено, какая из них соответствует состоянию "открыто". Представляется, что нужна будет ещё одна структура данных по типу "где-что патчить".
2) "Хрупкость" робота. Вплоть до введения чита с неуязвимостью.
Это сделанно намеренно. В версии, которая у меня есть сейчас, параметры "хрупкости" и ещё кое-какие вещи касательно описания робота сведены в отдельный файл и являются загружаемыми. В пределе моя цель - иметь несколько профилей по уровню сложности и даже несколько типов роботов. Чита с неуязвимостью не будет точно. Но, возможно, будет power-up, дающий временную неуязвимость. Это всё планировалось ещё в районе 3й альфы, но конечная имплементация будет в бетах где-то.
В любом случае, планируются как power-ups, дающие временный boost, так и постепенный upgrade робота между уровнями.
В версии, с которой ты игрался можно выставить в меню Damage Model в 0. Тогда рост температуры при движении не будет наносить повреждений и разряд батарей будет ниже.
3) На низком (низких) уровнях сложности можно показывать индикатор фазы открытия двери при активации ключа.
Подумаю. Возможно - в отдельном MFD, касающимся "состояния" уровня. Но-нескоро
4) Наличие/отсутствие подсказок и их подробность.
Это всё запланировано
Мне вот сначала пришлось выяснить, к какой двери подходит ключ.
А это-уже сделано. В новом билде есть inventory MFD. Все ключи-чуть разные. Но намеренно сделаны похожими (как раз для тренировки памяти, если без подсказок играть).
Тут как-бы мини головоломка+ловкость.
Да, это была одна из задач, которую я ставил при дизайне игры: связать аркаду с мини-головоломками хотя-бы по типу Rotors или Pairs, а в дальнейшем и куда более сложными, по типу The Incredible Machine. Но все задумки не хочу раскрывать. Если уже видно, в каком направлении будет развиваться игровой жанр, то я более чем доволен :-)
Головоломка - это ладно, а вот ловкость в сочетании со значительной "вязкостью" управления - уже не здорово.
Всё безусловно относительно, но никакой "значительной" вязкости управления там нет. Там есть инерция движения, поэтому чуть непривычно по сравнению с другими движками.
Рекомендую попробовать уже озвученные Rotors и Pairs. Или даже Putup или Rise Out. Будете удивлены, насколько Robotz проворнее. При этом, Robotz ещё и уровень скроллит. Менять жанр в сторону только статичных головоломок по типу сокобанов я не буду.
Всё безусловно относительно, но никакой "значительной" вязкости управления там нет. Там есть инерция движения, поэтому чуть непривычно по сравнению с другими движками.
Рекомендую попробовать уже озвученные Rotors и Pairs. Или даже Putup или Rise Out. Будете удивлены, насколько Robotz проворнее. При этом, Robotz ещё и уровень скроллит. Менять жанр в сторону только статичных головоломок по типу сокобанов я не буду.
В детстве putup прошел несколько раз (уж не знаю, как это меня характеризует), в rise out много играл, не помню только, прошел ли последний уровень. К rotors и pairs тоже относился положительно, но потратил на них меньше времени. Управление во всех упомянутых игрушках не казалось мне инерционным, может просто был молодым.
Управление во всех упомянутых игрушках не казалось мне инерционным, может просто был молодым.
Мне тоже так казалось, пока недавно не запустил под эмулем pairs и putup, и не поразился задержкам после нажатия на клавиатуру. Возможно, это-проблемы эмулей, не знаю.
Безусловно, Robotz не в состоянии зарендерить 20 кадров в секунду, но не всё настолько плохо ИМХО чтобы говорить о чрезвычайной вязкости. Опиши пожалуйста, в чём эта "вязкость" выражается по твоему мнению? Если в том, что робот иногда делает дополнительный шаг при нажатии на клавиатуру, то это-намеренно. То-же самое и с прыжком. На уровне даже есть место, где необходимо использовать "короткий" прыжок вверх (чтобы взять ключ для активизации подъёмника номер 2 после телепортации), иначе робот разбивает голову о потолок.
Возсожно, я намного дольше играл, но у меня проблем с какими-то лагами нет. Робот делает то, что я хочу вплоть до перепрыгивания через power-ups без их взятия (батарейка и болт на 2м этаже слева от телепортера).
Опиши пожалуйста, в чём эта "вязкость" выражается по твоему мнению? Если в том, что робот иногда делает дополнительный шаг при нажатии на клавиатуру, то это-намеренно.
Пожалуй именно в этом.
Все же ИМХО для игрушек такого типа желательно иметь FPS>=25 (еще бы и с субтайловой точностью перемещения ГГ), но понятно, что (на векторе) тогда придется жертвовать чем-то другим.
Все же ИМХО для игрушек такого типа желательно иметь FPS>=25 (еще бы и с субтайловой точностью перемещения ГГ), но понятно, что (на векторе) тогда придется жертвовать чем-то другим.
Да, 25 кадров было-бы замечательно, согласен. И, скажем, 4х - пиксельная точность ;-).
Но тогда можно забыть о многоплановых уровнях, движущихся оверлеях с альфа каналом, модели повреждения более сложной, чем декремент жизни и каких-то многофункциональных экранах. На Векторе с его вэйт стэйтами, 3МГц и 32К видеопамяти ИМХО вряд-ли удастся удержаться со всем этим даже в районе 20fps, хотя кто знает.
Когда ещё давно я стал задумываться о внутреннем дизайне игры, то отбросил субтайловые операции в первую очередь. Затем ушло разрешение тайлов на байт и было принято, что оптимальным размером тайла и шага движка должен стать квадрат 16×16 пикселов в четырех цветах с двойной буферизацией чтобы исключить мырганье. Всё это, безусловно, компромиссы, куда-ж без них.
Выкладываю промежуточный maintenance release v.0.53a.
Добавлено:
1. Переключение многофункциональных дисплеев клавишей <Tab>
2. Статус MFD повешен на <F1>
3. Многофункциональный дисплей с инвентарём. <F2>
4. Смена палитр повешена на клавишу <C>
5. Графика для телепортера
6. Зачатки графики для уровня (2й этаж)
7. Загружаемый профиль повреждений робота
8. Загружаемый музыкальный драйвер (не отлажен, и не используется)
9. Подправлен бегущий текст в меню опций
10. Подсветка выбранной опции в главном меню
Пофикшено:
1. Глюки с музыкой в меню опций
2. Повреждения при движении на подъёмниках вниз при активизации более одного подъёмника
3. Мелкие баги, касающиеся учёта повреждений робота
4. Разная скорость воспроизведения музыки на процессорах i8085 и z80
5. Задержка 1й двери в состоянии "открыто" увеличена в 2 раза
Enjoy!
5. Задержка 1й двери в состоянии "открыто" увеличена в 2 раза
Теперь в первую дверь можно зайти без мучений, приятно.
Теперь в первую дверь можно зайти без мучений, приятно.
Классно. Ну а весь уровень пройден? Там ещё пара заморочек-головоломок с открытием дверей и прохождением в них. Везде, где ожидается небольшая головоломка, я повесил анимированные экраны. Если внимательно смотреть на анимацию, можно с 1го раза догадаться, что надо делать чтобы пройти.
Про прыжок для того чтобы забрать ключ для подъёмника №2 я уже рассказал, впрочем там теперь дорожный знак height clearance висит, как-бы предупреждая о том, что высота этажа ниже.
Удобно-ли использовать <TAB> для переключения между дисплеями? Полезен-ли inventory display?
Анимация телепортера и телепортации мне до сих пор не нравится. Возможно, полупрозрачные кольца силового поля надо сделать пожирнее и погнать их быстрее снизу вверх, а перед самой телепортацией, возможно надо вспышку делать. Я даже подумывал всю палитру выбелять на момент телепортации, но пока решил этого не делать.
В общем, даже без врагов, объём доводок предстоит колоссальный. Будут ещё и горизонтальные платформы, надеюсь, и выдвигающиеся мостики и "провалы". Игрушка разрастается и с этим растут аппетиты и по возможностям движка и по графике. А графика сделана пока "начерно", и, потом, я совсем не художник ("он рисует как умеет" и "я так вижу" - это ко мне :v2_dizzy_facepalm:)
В общем, буду рад услышать любые предложения, критику и ваапче. Даже если не всё сразу приму, это даёт пищу для размышлений "куда и чего".
Ну а весь уровень пройден?
Нет, не прошел, а то бы похвастался :) Но пока и не пробовал, просто немного походил.
По графике вроде я уже высказывал крамольную мысль - а может все же конверснуть откуда-нибудь хотя бы часть (главный герой, вентиляторы, м.б. ключи)? Для конструктивности надо бы еще назвать откуда, но тут я затрудняюсь. Особый вопрос к анимации ГГ, но опять же, тут крупный шаг перемещения, даже не представляю, откуда можно украсть нечто подходящее.
Из текущей игровой графики мне понравилась батарейка :) , а из имеющихся палитр - почему-то оттенки серого.
Важно то, что сам я рисовать совсем не умею, через эту призму и надо воспринимать мои мысли про графику.
По графике вроде я уже высказывал крамольную мысль - а может все же конверснуть откуда-нибудь хотя бы часть (главный герой, вентиляторы, м.б. ключи)?
В принципе, возможно. Но, я думаю, что пока рано чуть. Не все power-ups сделаны из задуманных. Я думаю, будет намного проще, когда процентов на 90 возможности движка будут готовы. Это-к бете где-то.
Особый вопрос к анимации ГГ, но опять же, тут крупный шаг перемещения, даже не представляю, откуда можно украсть нечто подходящее.
В болдере вроде такой-же. Странно, но меня куда больше раздражают временные всплески нагрузки на CPU, чем анимация ходьбы главного героя.
Из текущей игровой графики мне понравилась батарейка :)
А мне почему-то нравится прорисовка дверей и устройства их поднимания. Люблю всё ажурное. Такое на спекки не сделать с его "атрибутикой". А батарейку-как раз можно. Видимо, "сила привычки" - великая сила, типа ожидаем от графики, чтобы было "как у них". На самом деле, хочется чего-то ажурного, где подчёркивалось бы, что Вектор может цвет на пиксел, хоть цветов и с гулькин нос, но не монохром уже :-). В общем надоть думать о "стилевом решении". Чем раньше, тем лучше, хоть и "торопиться не надо, надо хорошо вылечить" (с) Кавказкая пленница.
PS. Думаю, что основная проблема, что рисовать "в едином ключе" пока не получается. Надеюсь, что со временем всё это придёт к какому-то единству. Натырить графики, конечно можно, но хочется чего-то своего. Пилите Шура, она золотая :-).
В болдере вроде такой-же.
Там (речь ведь про версию Лебедева?), насколько помню, фаз анимации ГГ больше, хотя перемещение тоже на большой тайл. Если ГГ болдера "ходит на месте" вправо или влево то вообще хорошо. Но там ГГ как раз сдернутый, может и не дословно (попиксельно), но явно повторен прототип.
Странно, но меня куда больше раздражают временные всплески нагрузки на CPU, чем анимация ходьбы главного героя.
Это да, неприятно.
Там (речь ведь про версию Лебедева?), насколько помню, фаз анимации ГГ больше, хотя перемещение тоже на большой тайл.
Да, про неё. В принципе, я тоже могу увеличить число фаз анимации. Под это и память выделена уже. Вроде, как до 20 фаз на ГГ ЕМНИП.
Насчёт нагрузки на проц-тоже не безысходная ситуация. Главное, что я точно знаю все причины по которым всплески происходят. Конечно, рендеринг заднего плана и оверлеев с альфой уже почти на пределе в смысле оптимизаций по скорости, но вот анимации и особенно обработка триггеров может быть ещё улучшена ИМХО. На уровне, на самом деле, видимо-невидимо объектов и событий происходит. Я иногда вообще сам удивляюсь, как такое ООП на асме работает, и не рушит ничего :v2_dizzy_roll:
Уф, прошёл вроде - Game Over в конце не красиво, можно было бы хотя б Congratulations написать! Хардкор конечно знатный, особенно с первой дверью, нельзя так в самом начале напрягать имхо, лучше сперва головоловку какую-нибудь придумать.
На мой взгляд музыку было бы неплохо поменять - ту что в игре, на ту что в Options. В Options из-за картинки ничего разобрать нельзя: ни на реале, ни на эмуле. В скролле получше видно из-за того что фон более светлый, но всё равно не айс, может всю информацию по кнопкам в ReadMe и без всяких скроллов?
Заставка перед уровнем с подмаргиванием палитрой порадовала! В игре конечно графика бедновата - не работ, а скелет какой-то. Для фазы прыжка ГГ хотелось бы ещё видеть графику.
Не понял зачем столько детальной инфы по параметрам да ещё по всем 4 направлениям - не стыковкой же Шаттла управляем. Или это отладочная информация? Достаточно мне кажется одного суммарного по всем направления и не в HEX-форме, а в виде растущего ползунка-уровня, а ещё лучше на звуковые эффекты повесить.
Может пожертвовать всей этой точнейшей физикой в угоду аркадности и геймплею?
Уф, прошёл вроде - Game Over в конце не красиво, можно было бы хотя б Congratulations написать!
На 4м этаже за дверью при использовании взятого ключа зажглось? Тогда-да, поздравляю!
Game Over в конце-это временная затычка. Там вообще-то переход на следующий уровень будет с возможностью апгрейда робота между уровнями. Он поэтому и скелет такой-только "с завода", недоделанный и без рук. В чём был, в том и убежал :-)
Пока GameOver во всех случаях зажигается, и при убийстве робота тоже.
Хардкор конечно знатный, особенно с первой дверью, нельзя так в самом начале напрягать имхо, лучше сперва головоловку какую-нибудь придумать.
Уровень-тестовый вообще-то :-)
Это-единственный уровень, который у меня есть, на нём и отлаживаюсь.
Там сразу на юзера вываливает всеми возможностями движка. Для настоящих уровней нужен редактор. Его нет пока, поэтому сложность не по нарастающей, и предметы кое-как почти разбросаны.
В Options из-за картинки ничего разобрать нельзя: ни на реале, ни на эмуле.
Бида. Придётся, наверное другую картинку ставить. Уже жаловались. Уж больно мне эта нравится, но больше разность яркостей не выкрутить. Странно, что у меня всё на разных мониках разборчиво и читаемо.
Порадовало, что на реале идёт. Это-первое известие о работе на реале. Здорово! Реал с полным фаршем, квазидиск+дисководы? Сразу вопрос:загрузка уровня с дисковода долго по времени получается, или терпимо?
В скролле получше видно из-за того что фон более светлый, но всё равно н может всю информацию по кнопкам в ReadMe и без всяких скроллов?
Оно и будет в ридми. В скролле будет всякая шняга типа бестов и регардов.
Просто в ридми будет ещё одно меню, о чём читать.
Для фазы прыжка ГГ хотелось бы ещё видеть графику.
Будет. И не только для прыжка. Даже для стояния на месте. Только всё это время занимает.
Не понял зачем столько детальной инфы по параметрам да ещё по всем 4 направлениям Или это отладочная информация? Достаточно мне кажется одного суммарного по всем направления и не в HEX-форме, а в виде растущего ползунка-уровня, а ещё лучше на звуковые эффекты повесить.
Для отладки. Я уже выше об этом писал. Естественно, будут либо ползунки, либо вообще "краснеющий" по частям робот.
Может пожертвовать всей этой точнейшей физикой в угоду аркадности и геймплею?
Много скорости это само по себе не добавит. Макс-четверть кадра в секунду, я проверял уже. Но при этом уйдёт туча планируемых идей, по типу апгрейда робота по частям.
Кстати, звук можно самому поменять. Просто .stm файлы должны иметь имена menu.stm, options.stm и level001.stm. Подойдут любые с размером до 7К. Главное, чтобы в них длина была правильно прописана.
Пасиб за комменты, всё учту по мере сил.
Бида. Придётся, наверное другую картинку ставить. Уже жаловались. Уж больно мне эта нравится, но больше разность яркостей не выкрутить. Странно, что у меня всё на разных мониках разборчиво и читаемо.
Картинка хорошая - её можно при загрузке второго уровня показать, а в Options может её сделать тупо с чёрным полем под надписи, а текст самым ярким цветом?
Порадовало, что на реале идёт. Это-первое известие о работе на реале. Здорово! Реал с полным фаршем, квазидиск+дисководы? Сразу вопрос:загрузка уровня с дисковода долго по времени получается, или терпимо?
+AY ещё + винт, винт поддержать нет желания? ВИ1 только нет. Загрузка из меню до старта уровня по секундомеру 25 секунд, с эмулем разницы не ощутил, значит, не принципиальна.
А что за клякса ездит по диагонали рабочего экрана - поначалу бесила очень? Нереализованная фича?
Пасиб за комменты, всё учту по мере сил.
Вам огромное спасибо за труд, пожелаю творческих узбеков, запала и времени свободного побольше!
в Options может её сделать тупо с чёрным полем под надписи, а текст самым ярким цветом?
Хочется всё-ж оставить эффект полупрозрачности текста. Ради него всё и затевалось. Просто нужны более контрастные цвета и не такие плавные градации как на этой картинке.
+AY ещё + винт, винт поддержать нет желания?
Классный наборчик, тру Вектор со всем фаршем! А насчёт винта, возможно к этому и придём, когда дискеты не хватит.
А что за клякса ездит по диагонали рабочего экрана - поначалу бесила очень? Нереализованная фича?
Это-будущий вражина :) - чтоб оценивать, сколько отнимает пересчёт координат и вывод с точностью до пиксела. Просто вместо картинки там альфа-спрайт со всеми возможными вариантами полупрозрачности.
------------------
v. 0.54a March 31 2014
------------------
Добавлено:
1. Загружаемые драйвера для музыки и звуковых эффектов
(как следствие-возможность поддержки любых звуковых форматов)
2. Поддержка звуковых карт R Sound-2 и Sound Tracker (сменой драйвера)
3. Загружаемые библиотеки звуковых эффектов (SFX файлы)
4. Маппинг уникальных звуковых эффектов для каждого события в игре
(не все события размаплены в данной версии)
5. Отключаемые moving sequences (выключение подъемников)
6. Активизировано меню ReadMe (просмотр файла readme.txt)
7. Написан FAQ для пользователей
8. История изменений в версиях собрана в changelog (этот документ)
Пофикшено:
1. Уменьшены всплески нагрузки на процессор при обработке триггеров
2. Шрифты при смене видео режима конвертируются в банке квазидиска без malloc
3. Пофикшено отключение звука в меню нулевым значением опции Sound Tempo
4. Перерисованы изображения ключей телепортера и выхода с уровня
5. Изменена и перелинкована (на 1K меньше) утилита ShFNT.com
6. Пофикшен код воспроизведения звуковых эффектов
7. Исходный мультифункциональный дисплей заменён на "инвентарь"
Выложена новая альфа v.0.55
Robotz! Changelog
------------------
v. 0.55a 14.04.2014
------------------
Добавлено:
1. Парсер гипертекста с поддержкой тэга \цвет, где цвет= hex символ от 0 дo F.
2. Цветовые тэги в содержимое файла readme.txt (подложка/шрифт, 2 бита на цвет)
3. Простенький побайтный RLE-компрессор/декомпрессор текстовых файлов
4. Цветной текст в меню README (сжат, декомпресся на лету)
5. Дополнительный системный шрифт digitalA.fnt (увеличен до предела размер символов)
Пофикшено:
1. Ускорен вывод мультитекстурных шрифтов в режиме низкого разрешения
2. Немного подправлены системные шрифты
Попробовал увидеть детект R-Sounda - не нашел. Плохо искал, или он будет в следующих версиях?
Попробовал увидеть детект R-Sounda - не нашел. Плохо искал, или он будет в следующих версиях?
ivagor, вообще-то FAQ никто никогда не читает, но всё-таки рекомендую.
;)
Всё, что надо сделать - это заменить драйвер c классом Sound Renderer cледующим образом:
1. Запускаем роботов и смотрим в бутлоде, какой из файлов драйверов говорит что у него класс "Sound Renderer". В версии 0.55 это файл SOUND002.DRV
2. Выходим из роботов в МикроДОС и переименовываем файл rs2stm.drv соответственно (в SOUND002.DRV)
Лучше переименовывать следующим образом:
cp rs2stm.drv sound002.drv
При неправильном переименовании бутлодер сообщит, что 2 драйвера либо пытаются повеситься на одно-и-тоже устройство, или имеют один и тот-же class и не забутит игрушку, выйдя в МикроДОС
Утилита cp.com на образе диска с последней версией. Я вообще-то думал сделать 2 submit файла для простоты запуска, но не стал. Сделал только sysfnt.sub для смены системных шрифтов. На всякий случай, напишу как им пользоваться. Например, чтобы сменить системный шрифт на digital8.fnt, в командной строке МикроДОС надо набрать
sub sysfnt digital8
Игра с этого момента будет использовать digital8.fnt в качестве системного шрифта (sub файл больше запускать не надо).
Я потом когда-нибудь возможно сделаю это либо конфиг-файлом, либо-ключами. А пока-так.
PS. Да, насчёт детекта: запусти конфигурацию игры с rs2stm.drv под Sound Tracker или с отключённым R-Sound под любым из эмулей и бутлодер, загрузив драйвер, должен сказать, что device not found и поехать грузиться дальше. Но звука в игре не будет, только SFX.
PPS. Зачем всё так "сложно" сделано? Чтобы можно было иметь RS2PT2.DRV, RS2PT3.DRV и так далее.... ;)
FAQ я читал, но поверхностно. В частности пункт
Q. Does this game support R-Sound 2 sound board?
A. Yes
дальше не читал
После cp rs2stm.drv sound002.drv заиграло.
После cp rs2stm.drv sound002.drv заиграло.
Во. А теперь - "отключи" в эмуле карточку, скажем в VV в меню Sound AY/YM Sound Card, выставив Card Type в "None" или в "Sound Tracker".
Ясно, что оно играть не будет, но игрушка загрузится, а бутлодер скажет что Sound Renderer device status: not found.
Эх, хочется уже сразу иметь драйверы для проигрывания RMP,PT2 и PT3.
В игрушке всё для этого готово - она абсолютно "не в курсе", "как оно играет": драйвер не только обрабатывает всё проигрывание, но и задаёт расширение файлов и определяет их размер. Скажем, для PT3 все файлы трэков, которые сейчас .STM будут .PT3.
Жаль, что нет эмуля с поддержкой обоих карточек одновременно: можно таким-же макаром и звуковые эффекты через разное оборудование играть. Сейчас SFX идёт через PIT i8253.
У тебя DE1 есть? Можно туда прикрутить 2 карточки одновременно, но если прикручивать буду я, то чтение из R-Sound пока под вопросом.
У тебя DE1 есть? Можно туда прикрутить 2 карточки одновременно, но если прикручивать буду я, то чтение из R-Sound пока под вопросом.
Да, у меня есть DE1 (cтарого пошива, с медленной памятью)
Помнится, я даже ковырял FDD код (6502, кажется - там компилятор и линкер поменялся, и мне было не пересобрать).
А может ты попробуешь звуковые драйвера подописывать? Скажем, PT3? Я сырки тебе пришлю и driver model растолкую, хотя там всё проще репы. Просто у меня руки не доходят. Да, у S.E.S в демке Polet4k оченно няшный STM проигрыватель. Я его как-то выковырял идой, а потом-потерял весь откомментированный и отдизассембленный код :v2_dizzy_facepalm:
Желательно уточнить - у тебя работает ревизия 403 (SDRAM 60 MHz - при переносе на DE1-SoC словил сюрпризы) или 400 (SDRAM 24 MHz - обязана работать на любой плате)? Может лучше в почту, чтобы здесь меньше оффтопить.
Желательно уточнить - у тебя работает ревизия 403 (SDRAM 60 MHz - при переносе на DE1-SoC словил сюрпризы) или 400 (SDRAM 24 MHz - обязана работать на любой плате)? Может лучше в почту, чтобы здесь меньше оффтопить.
Я коммитил в сандбокс svofski когда там номера ревизий были 39x чего-то там. С тех пор твои новые не пробовал, но могу. Да, наверное надо почтой. А то мы сейчас тут начнём обсуждать и наваляем Вектор с гигабайтной виртуальной памятью ;-)
Насчет звуковых драйверов - на данный момент не готов, сильно снизилась мотивация писать что-либо для ВМ80.
Насчет звуковых драйверов - на данный момент не готов, сильно снизилась мотивация писать что-либо для ВМ80.
Это так verilog и кактус на тебя повлияли. Жаль что так, но надеюсь-что это временно.
Проект был заморожен по причине отпуска в Питер.
Вернулся и выкладываю новую альфу.
Robotz! Changelog
------------------
v. 0.56a 01.06.2014
------------------
Добавлено:
1. Звуковые эффекты и визуальные эффекты полупрозрачности в меню опций
2. Дополнительные звуковые эффекты на события в игре
3. 2-bit 9kHz звуковой DAC драйвер для воспроизведения вокала на i8253
4. 2-bit 9kHz звуковой DAC драйвер для воспроизведения вокала на Сovox
5. Инсталляционный скрипт
Изменено:
1. Изображение заднего плана в меню опций на "The Guardian" by Nikolai Nazarov
2. Цвета палитры в главном меню на оттенки серого
3. Цвета в меню "Read This"
Теперь в игре есть инсталляционный скрипт install.sub, который запускается автоматически при первой загрузке с диска и устанавливает драйвера, настраивает меню опций и кое-что ещё. При успешной инсталляции скрипт запустит игру и всё должно работать. По умолчанию ставятся следующие драйвера:
1. Sound Effects - через i8253
2. Vocal Sound в заставке 2-bit 9kHz DAC driver для i8253.
возможные альтернативы:
1-bit 7kHz DAC sound driver через бипер
2-bit 9kHz DAC driver для Covox (наилучшее звучание, хотя i8253 я довёл по качеству почти до ковокса)
В эмуле VV с эмуляцией таймера похоже глюк: при перепрограммировании режимов с WORD count на LSB звук становится глухим. Разницу слышно если запустить Роботов, выйти в ОС а потом запустить 2й раз.
3. Background Sound - STM через плату Sound Tracker
возможные альтернативы:
Background Sound - STM через плату R-Sound 2
Для того чтобы поменять драйвера на альтернативные, нужно отредактировать инсталляционный файл install.sub, раскомментарив соответствующие строчки, сохранить файл и запустить его из командной строки MicroDOS следующим образом:
a:<install.sub
Положил на диск редактор wm.com чтобы прямо в ОС редактировать.
Удачи с инсталляцией. Новая альфа как всегда в 1м посте.
2-bit 9kHz звуковой DAC драйвер для воспроизведения вокала на i8253
Немного занудства. Если считать для групп по 8 отсчетов, то получается стабильно 9202,45 Гц. А внутри группы по моим подсчетам частота немного плавает.
В принципе, возможно подобрать константы под ровно 9kHz,но не данной имплементацией-она не только для 3MHz CPU clk, а на диапазон от 2 до 20MHz. Там для частот до 12MHz примерное табличко, на слух,а выше-линейная интерполяция некоей замысловатой функцией. Кроме того, для z80 и 8085-своя отдельная таблица и функция.
Частота между отсчётами может едва-едва плавает из-за моей ленивости -не стал точно nop-ами добивать места где нет обработки склейки байтов. Кроме того, там вывод бордюра и опрос клавиатуры впихнут между байтами. Вообще, драйвер читает стеком по 2 байта, что даёт 8 отсчётов, а обработка их значений развёрнута по 12 "функциям" с абсолютно одинаковым количеством тактов. Стеком-от того, что драйвер, естественно, читает данные из банка квазидиска: все вызовы "фунций" используют pchl.
Если это принципиально, могу попробовать написать более православно. Но имхо, на 3МГц звучит не сильно хуже 2-х битного ковокса.
PS. Посмотрел на сырец, и могу подтвердить, что между отсчётами действительно есть плавание. В принципе, его легко можно прибить nop-ами до 48 тактов, даже момент с выводом бордюра.
Для любознательных:
PLBYTE MACRO _reg,_lbl1,_lbl2,_brdrw
mov a,_reg
rlc
rlc
ani 1100b
DB (ori)
_lbl1: DB 0 ; 11B
PL_VOL CPUWte ; 32 cycles
mov a,_reg
rlc
rlc
ani 11B
sta _lbl2
mov a,_reg
PL_VOL CPUWte ; 48 cycles
mov a,_reg
rrc
rrc
mov _reg,a
IFNB <_brdrw>
out D30PB
EndIF
PL_VOL CPUWte ; 24/36 cycles
IFNB <_brdrw>
mov a,_reg
ani 1
out D30PB
EndIF
mov a,_reg
rrc
rrc
mov _reg,a
PL_VOL CPUWts ; 24 cycles
EndM
Прикинул: PL_VOL занимает 192 + (32 * CPUWte) тактов. Для 3MHz CPUWte=3, что для наихудшего из случаев 24 vs 48 cycles даёт 12% качание (6% девиации) несущей. Наверное, стоит всё-таки пробить NOP-ами в следующей версии дров.
Shadow Maker
03.07.2014, 23:37
Мож кто ютуб-видео запилит? А то я в векторе ни бум бум, а посмотреть что такое эти ваши роботы - было бы неплохо.
Из меня киномеханик-не сильно хороший. Ну только если какая добрая душа найдётся.
Во вложении-православный :v2_finge: драйвер для воспроизведения 2-х битного 9кГц вокала на DAC из 3х каналов i8253 PIT.
Диапазон рабочих частот CPU для работы драйвера: 3-47.9MHz
Разрешение драйвера: 100kHz шаг CPU clock.
Поддерживаемые CPU: i8080/85,z80,KP580BM1
Относительные погрешности вводимых задержек (для разных частот CPU):
Для i8080 и KP580BM1 = 1.0(3)%
Для z80 и i8085 = 2.9%
Девиация несущей частоты:
Для i8080 и KP580BM1 = 0% (если нигде не накосячил)
Для z80 и i8085 девиация будет присутствовать, но посчитать сейчас уже нет сил, голова пухнет от подсчёта тактов.
Ошибку отклонения несущей от 9kHz не считал, но для z80 и i8085 она будет выше. Есть некоторые сомнения, что мог накосячить с подсчётом тактов для z80/8085.
Очень интересно, что покажет спектральный анализ уважаемого ivagor-а.
Для установки драйвера на диск с роботами:
1. Заменить драйвер в user 3 диска на драйвер из вложения
2. Запустить из user 0
a:<install.sub
3. Для эмулятора Virtual Vector перезапустить комп по окончании инсталляции. Для emu - не требуется.
4. При запуске роботов убедится, что бутлодер показывает версию vocal renderer драйвера как 2.0
При работе на частоте меньше 3MГц драйвер не станет проигрывать звук и бутлодер просто выйдет в главное меню игры.
Спектральный анализ я не применял :)
В emu ставил бряки и смотрел сколько натикает, так точнее.
Для установки драйвера на диск с роботами:
Гуманнее все же готовые образы выкладывать (хотя бы временно на файлообменник), к хардкору сейчас мало кто готов (я, например, не готов).
Тогда это получился синтетический тестинг ;-)
Одно файло скопировать плагином для FARa в образ-не хардкор.
PPC, я могу для ROBOTZ завести BTSync-овый фолдер на манер как мы сделали Ramiros-у для VV. Выглядит это как то, что ты кидаешь у себя файл в специальный каталог, а у меня на распе это через пару минут появляется с автоматически обновленным html-ем и проч. Ы?
PPC, я могу для ROBOTZ завести BTSync-овый фолдер на манер как мы сделали Ramiros-у для VV.
svofski, спасибо, я не против выкладывать обновления туда. Всё равно остаются 2 возможных опции в каком формате доставлять промежуточный между версиями контент:
1. Каждый раз при изменением любого файла драйвера/обоев/музыкального трека делать нумерованный релиз,бамп-ап версии и выкладывать всё это в виде готового образа .fdd, за что ратует ivagor.
2. Если изменения не затрагивают .com файл, выкладывать только эти изменения отдельными промежуточными апдейтами с описанием и инструкцией по интеграции. Хранить их до выхода следующей версии, а потом-интегрировать в образ с новой версией, если это только не какая-то альтернативная вещь типа обоев/трека.
По многим более, чем одной причине, я-за вариант номер 2. Это приемлемо?
Лично для меня вариант ivagor-а более приемлем и понятен, я тоже за него ратую =)
Если бы еще были какие-то коммандлайновые (то есть пакетные) тулы для работы с образами .fdd, тогда бы можно было б часть всего этого автоматизировать. А с этими фаровыми плагинами, я не знаю.. Кстати, надо бы выпотрошить их в коммандлайновые утилиты.
Скорее он кажется на первый взгляд удобным для поставил-запустил-посмотрел.
Но для этого как раз релизы и выходят. А между версиями могут появляться-исчезать драйвера, меняться обои и т.п. Роботы-модульные вплоть до мульти-функциональных дисплеев. Всё это грузится с диска и "возможны варианты". Когда-нибудь весь контент всяко на дискету не полезет (у меня-уже давно так :-) ). Можно, конечно, будет перейти на hdd потом, но мне просто нереально будет отслеживать версии, разница между которыми в том, что, скажем, добавилен драйвер для проигрывания .pt3 треков или изменены профайлы какого-либо из ГГ.
Но раз такое единение, то настаивать не буду.
Насчёт утилит командной строки для работы с образами-отличная идея.
Понадобятся кау минимум ключи для
create image
write file
read file
delete file
change file attributes - если хотим уважить r/o и system атрибуты
Всё это-с учётом user area
Возможно, придётся wildcards поддерживать для пакетной обработки, как иначе "стереть всё"
Вообще, директория CP/M простая так что можно и из фары не выдирать, а забацать с нуля.
Плагин к фару по-моему неплохо написан и все это в нем уже есть. Надо только отпилить собственно плагинную часть.
А почему, например, не держать сорцы на гитхабе, а на сайте выкладывать только собственно уже релизы-демки на .fdd ? Тогда все эти проблемы сами собой решаются, сорцы можно чекинить хоть после изменения каждого символа и это никого не будет напрягать, будет история и в то же время будет презентабельный способ смотреть на "релизы".
есть мой xkorvet http://zx-pk.ru/showpost.php?p=716631&postcount=24
он для корветовских KDI дисков
я его с фаром и использовал как внешний архивер ;)
и из комманд лайна.
он не привязан к формату (у корвета параметры диска читаются из 0го сектора)
если он есть в Векторовских образах - вообще просто, если нет можно заколотить его
просто орионвские диски - это потомки корветовских, там есть эта область.
xkorvet конечно далёк от идеала, но за точку отсчёта взять можно.
в ближайшее время буду его допиливать немного, (перезел под линух, надо там править, хотя фильтр для чтения под MC уже набросал)
---------- Post added at 14:01 ---------- Previous post was at 13:59 ----------
похоже тоже наследник ;)
esl@esl-hp:~/Dropbox/Emulator/Other/Vector/Games/robotz$ xkorvet l Robotz56.fdd
xKorvet Version 1.3, copyright 2002-3 by Sergey Erokhin
argv[0]=xkorvet
argv[1]=l
argv[2]=Robotz56.fdd
CMD: l
FileName: Robotz56.fdd
FileMask: *.*
KDI: Robotz56.fdd
Begin:
CP.COM 9088
DIR.COM 2048
LABEL.COM 768
TYPE.COM 768
WM.COM 9728
WM.HLP 11136
ROBOTZ.COM 18816
COMPO.FNT 6272
LEVEL001.LOL 22656
LEVEL001.LVL 13056
MFD.LVL 384
ELECTRIC.SD1 46464
ELECTRIC.SD2 62848
SFX000.SFX 6656
LEVEL001.SPT 15488
MFD.SPT 8832
RECCEBOT.SPT 1664
TERMINUS.SPT 2176
LEVEL001.STM 2304
MENU.STM 6144
OPTIONS.TXT 1536
README.TXT 2688
01\PITSFX.DRV 384
02\RS2STM.DRV 1408
02\STSTM.DRV 1280
03\BDAC1VOX.DRV 384
03\CDAC2VOX.DRV 512
03\PDAC2VOX.DRV 1024
04\DIGITAL8.FNT 2176
04\DIGITAL9.FNT 2176
04\DIGITALA.FNT 2176
05\MENU001.IMG 24704
05\MENU002.IMG 24704
05\MENU.SUB 128
06\OPTIONS0.IMG 24704
06\OPTIONS1.IMG 24704
06\OPTIONS0.STM 6144
06\OPTIONS1.STM 6144
06\OPTIONS.SUB 128
07\LEVEL001.IMG 24704
07\LEVEL002.IMG 24704
07\LEVEL.SUB 128
SUB.COM 6400
INITIAL.SUB 128
TERMINUS.BOT 384
E5\INSTALL.BAK 3328
INSTALL.SUB 3328
E5\SYSGEN.COM 2048
ROBOTZ..56 0
E5\SPRITE.INC 11776
E5\INSTALL.BAK 3328
ROBOTZ.SUB 384
E5\INSTALL.BAK 3328
E5\W.W 256
E5\INSTALL.BAK 3328
End.
---------- Post added at 14:05 ---------- Previous post was at 14:01 ----------
а вот бинарник под винду (еще тех времён)
и там внутри как его к фару подключить
https://dl.dropboxusercontent.com/u/490774/xkorvet.zip
Плагин к фару по-моему неплохо написан
Он не все файлы видит на образе.Глубже я не копал.Но в принципе, конечно подойдёт.
А почему, например, не держать сорцы на гитхабе, а на сайте выкладывать только собственно уже релизы-демки на .fdd ?
Какая-то очень древняя версия даже где-то лежит. Просто её обновить надо. Я прекратил апдейты туда по причине яростной раскройки сырков в какой-то момент.
Возможно, это самый наилучший вариант, и всякие одиночные файлы стоит держать между билдами в сорс контроле. Думаю, так и поступим.
---------- Post added at 08:09 ---------- Previous post was at 08:00 ----------
есть мой xkorvet
...похоже тоже наследник ;)
Адназначна! И бут сектор с инфой о конфигурации дискеты у нас тоже есть. Я даже когда-то очень давно писал для Вектора сюсьинфу и читал все эти 5 дюймов, двойная плотность MFM 40/80 1/2 и прочее и прочее :-)
Адназначна! И бут сектор с инфой о конфигурации дискеты у нас тоже есть. Я даже когда-то очень давно писал для Вектора сюсьинфу и читал все эти 5 дюймов, двойная плотность MFM 40/80 1/2 и прочее и прочее :-)
а они (биосы) это используют ?
а то в Корвете и ром это использует (настраивает параметры)
и биосы cp/m честно читают и настраивают контроллер.
микродосы как раз не все.
а они (биосы) это используют ?
а то в Корвете и ром это использует (настраивает параметры)
и биосы cp/m честно читают и настраивают контроллер.
микродосы как раз не все.
В биосах, которые шли с МикроДОС 3.1 было ЕМНИП жёстко прошито 80 дорог 5 секторов 2 стороны.
Но я знаю один биос, который и читает и настраивает. Патамучта кгхм... писал его я и ISA :-)
Биос сохранился, а вот сырки-нет. Это год 92-93й где-то был.
Вдогонку: биос называется Bold BIOS 3.что-то. В роботах на .fdd тоже Bold BIOS, но не тот, а ver.2.0, потому что 3.x мы не довели, но как раз с ВГ93 вроде всё доделали.
Внесу свою лепту в начавшийся оффтоп.
Давно интересовал вопрос - почему плагин для фара (автор FANSoft) видит все файлы на образах, а плагин для WC/TC (автор Error404) иногда не видит файлы в юзерах кроме 0го. Да, плагин Errora для ориона, не для вектора, но в чем разница?
Плагин для фары тоже не всегда видит все файлы, даже в нулевом юзвере.
Интересно, что и в самом МикроДОСе 3 известные мне варианта утилиты dir бывает пропускают файлы, причём разные. С dir можно погрешить на find first/next хоть для каких-то имплементаций, но похоже, это-только следствие. Хоть бери и пиши собственный dir с чтением области директории. Удивительно, но встроенная команда "D", похоже всегда видит все файлы как и power. Проблема с юзерами кроме нулевого, возможно того-же рода, что бага в CP/M, перекочевавшая и в МикроДОС, когда файл больше экстента не в нулевом юзвере при чтении сообщается в FCB как занимающий один экстент.
У роботов теперь есть svn репозиторий:
http://robotz.googlecode.com/svn/
Кому интересны сырки (их есть), забирайте в удовольствие:
svn checkout http://robotz.googlecode.com/svn/ robotz-read-only
Wiki страничек пока нету, это следующий этап. Вкратце для тех, кому интересно покопаться в сырках:
Весь код намеренно в досовской кодировке. В /tools/cross/win32/codepage лежит всё необходимое для поддержки кодировки и перекодирования в Векторовский КОИ-8 и обратно.
В /tools/cross/win32/CEdit/ лежат файлы для поддержки syntax hiliting для ассемблера i8080 в редакторе Crimson Editor.
В /bin лежат скрученные 7-zipom CP/M тулы для компиляции из DOSbox через CPM->DOS утилиту 22nice. На 32-битных процах 22nice можно пускать без ДОС бокса, прямо с командной строки.
NB!
1. Роботам нужна библиотека GML. Построенный объектный файл лежит в /Robotz/GML.REL, исходники и include файлы - в каталоге /GML.
Для компиляции роботов каталог /GML должен быть размечен (в DOSBox) как диск A. Проще всего это сделать, запустив файл setenv.bat из каталога /Robotz сразу после запуска ДОС бокса.
2. Сама библиотека GML из под 22nice построится с ошибками. Её можно строить только под МикроДОС или CP/M в эмуле или на реале.
Мини-апргейд для версии 0.56
http://robotz.googlecode.com/svn/trunk/updates/
Ради интереса, попробовал реализовать идею SES: полуэкранный 8-цветный дабл-буфферинг, озвученную ivagor-ом в этом посте (http://zx-pk.ru/showpost.php?p=537790&postcount=72).
Подкрячил сегодня рендерер. Да, получилось 8 цветов без мырганья, но стало заметно медленней. Настолько, что медлительность скролла начинает серьёзно добивать. Если убрать полупрозрачные оверлеи поверх тайлмапа, то терпимо, но с ними уйдёт туча эффектов (субтайловые спрайты, стёкла, передний план).
Всё-таки для динамических игр со скроллом на Векторе такой подход вряд-ли годится, а вот для стратегий - возможно применим.
Мне кажется, что нечто эксолоноподобное в таком режиме вполне реализуемо
Ради интереса, попробовал реализовать идею SES: полуэкранный 8-цветный дабл-буфферинг, озвученную ivagor-ом в этом посте (http://zx-pk.ru/showpost.php?p=537790&postcount=72).
а можно подробностей немного про этот режим, а то не понятно вне контекста вектор ...
а можно подробностей немного про этот режим, а то не понятно вне контекста вектор ...
Попробую. Правда, я не лучший объяснятель, но всё-же. Если что, спрашивайте, да и ivagor тут рядом.
Дальше - не реклама ;)
Видеоадаптер Вектора-06ц/06ц-02 (существенные для эффекта вещи):
- 256-цветная палитра из 332 цветового пространства
- аппаратный вертикальный скроллинг на произвольное количество строк
- 4 видеоплоскости по 8К каждая
- 2 видеорежима, высокого и низкого разрешения.
В режиме низкого разрешения, цвет пиксела на экране формируется как значения битов в плоскостях с координатами пиксела. Единичные биты в соответствующих плоскостях дают весовые коэффициенты 8,4,2,1, что приводит к 16 возможным комбинациям. Очень похоже на EGA.
При использовании всех 4х плоскостей это позволяет выводить до 2^4 = 16 из 256 различных цветов одновременно, простым программированием палитры (2х-байтовый регистр-секвенсор: номер цвета, значение и так 16 раз).
Количество цветов на экране можно уменьшать тем-же программированием палитры. Скажем, если в палитру запихнуть следующие 16 цветов, то получится 8-цветный режим:
100 101 102 103 104 105 106 107 100 100 100 100 100 100 100 100
При этом видео плоскость с весовым коэффициентом 8 может быть использована как обычный RAM (маскирование цветом).
Идея состоит в следующем: 3 плоскости отводятся под изображение.
Экран делится пополам по горизонтали. Изображение будет в пол-экрана высотой и на всю ширину.
Одна плоскость отводится под "полумаску": в ней рисуется прямоугольник на всю ширину и половину высоты экрана.
Палитра перепрограммируется каждый кадр таким образом, чтобы получилось 8 цветов, но половина экрана (верх или низ) всегда была замаскирована цветом. Скажем, если под маску выбрана плоскость с цветовым весом 8, то вторая палитра к 3-х цветному примеру выше, будет выглядеть как
100 100 100 100 100 100 100 100 100 101 102 103 104 105 106 107
Отрисовка всегда идёт в замаскированную цветом половину экрана. В это время на экране "размаскированное" изображение. По окончанию отрисовки кадра, выполняется перепрограммирование палитры и аппаратный скроллинг экрана на пол высоты. Profit. Полуэкранный 8-цветный double video frame buffer.
Уфф :). Надеюсь, не затуманил ещё больше.
В принципе, код я не потёр ещё, и могу завести в репозитории branch и кинуть туда для изучения, если хотите. Все основные изменения - в файле SLR.mac (SLR - это Sprite Level Renderer, a не Single Lens Reflex ;) ). Простое сравнение в каком-нить WinMerge всё покажет лучше 1000 слов. Заливать?
---------- Post added at 20:20 ---------- Previous post was at 20:12 ----------
Мне кажется, что нечто эксолоноподобное в таком режиме вполне реализуемо
ivagor, да, согласен, но там ведь нет скроллинга, как такового. Только чтобы спрайты не мерцали, наверное.
Но всё-таки стратегия будет сиять в этом режиме. Там скорость скроллинга не так важна, как отсутствие мерцания. Самое то вроде.
Ну будет fps в районе 6-8, ведь не смертельно. Зато - субтайловые оверлеи на все 8 цветов и абсолютно без мырганья... эх, красота ведь!
Похоже под стратегиями ты в первую очередь имеешь ввиду rts, но, например, для civilization можно обойтись и без буферизации и использовать все 16 цветов. Если не считать отсутствия программистов есть еще небольшое техническое препятствие - отсутствие нормального стандартного способа подключения мышки. Хотя, конечно, можно и без мышки
Не обязательно real time, хотя в первую очередь их. Бывают и "пошаговые" стратегии со скроллом, им тоже совсем ведь не помешает отсутствие мырганья. Мышь, мне кажется, куда меньшая проблема чем, "отсутствие программистов". В конце концов, она решаемая. Либо отдельной платой, либо 8259 на какой нибудь из IRL. Ну а программисты-это да. Вряд-ли кто-то будет сейчас учить всю Векторовскую тряхомудию. Мне просто нравится Вектор. Он няшный в смысле программания, да и от работы отдыхаешь после чудовищных микроконтроллеров. Поэтому и балуюсь. Когда время свободное есть. А его мало, увы.
Хотя, конечно, было бы приятно, если бы появлялись новоделы. Железо и муляторы-это замечательно, но без софта-увы.
Для цивы вполне подошел бы незамысловатый скролл по типу болдера. В идеальном мире лучше с буферизацией, но для многих применений (если без промежуточного стирания или восстановления фона, например под спрайтами) сойдет и простая перерисовка отличающихся тайлов. Кстати, я не интересовался, сколько занимают тайлы цивы, может в 16 цветном варианте они и не влезут (наряду с картой и всем остальным) в стандартный квазидиск, хотя тут может помочь и простейшее кеширование. Ну и немного провокативности - двумерные движки это хорошо, но трехмерные круче (хотя и не всегда) :)
---------- Post added at 09:11 ---------- Previous post was at 09:03 ----------
И еще у меня что-то типа дежа вю, вроде мы уже это обсуждали :)
Цива, сим сити, Europe in Flames (она вообще пошаговая и гексагонная), Дюна, Warcraft... жанр разработан, было-б только желание да время.
Да, уже обсуждали и мышей и rts и программистов :)
Но раз Гондурас так беспокоит, это означает, что он вызревает ;)
Кстати, кроме мышей и программистов, с Вектором есть ещё одна проблема: как показывает мой скромный опыт, она куда серьёзнее, чем мне представлялось поначалу. Очень скуден выбор средств разработки и обработки. Изображений, музыки, спец-эффектов. В какой-то малой мере, я, возможно, улучшил ситуацию. Но, как показала практика, на разработку средств разработки зачастую уходила половина времени разработки. Каламбур в стиле поручика Ржевского :)
Проблема в том, что Вектор очень "специфичен". Огромная видеопамять по меркам 8-битной машинки, обилие периферии и чертовски медленный процессор. Как у Киплинга-черепаха Неспешная :).
Поэтому битмапы надо "готовить", за звук бороться и т.д. и т.п. А на всё это нужен тулкит. Стандартным фотожопом и вав-редактором дело не заканчивается.
Плюс, даже библиотек нормальных не было. Вот поэтому, в том числе, я и отделил половину роботов в отдельную библиотечку.
Насчёт размеров. Да влезет, я думаю. В роботах вон картинки по 24К без сжатия хранятся в дополнение к текстурам тайлов, оверлейных альфа-текстур и спрайтов. Да ещё 2 фонта, один из которых-по 2 битмапа на букву. Влезет, ну и подкачку с диска замутить дело теперь нехитрое.
Насчёт 3х мерных, а точнее-псевдо 3х мерных движков.... ты как в воду глядишь :)
Третий день читаю про raycasting. Встречно-провокативное: у нас есть оптимизированный тобой амбал 3д, но ему, мне кажется, пошло бы к лицу текстурирование, bumpmapping и фильтры для освещения. Как ambient, так и texture-shaded. Только вот удастся ли со всем этим взлететь на 3х мегагерцах? А так-да, трёхмерные безусловно круче.
Амбал3D это вдохновляющий пример, но ошибка со щелями в стенах портит впечатление. Судя по еще одному примеру (только со спектрума) - wolf3d 48 - текстурированный рейкастинг на векторе вполне возможен (в эмуляторе спектрума Фролова работает, на 580ВМ80 будет медленнее, но думаю не хуже чем в 1,5 раза, если постараться). Насчет дальнейших наворотов - разве что для маленьких картинок и на скорости в 1-2 fps. Но интересно было бы взглянуть
Еще и векторное 3d было бы неплохо, тем более линии можно сделать разноцветные. Только программирование для 580ВМ80 меня сейчас не соблазняет
Да, там жёлтым бъёт при определённых углах как серпом. Я прочёл и перевариваю уже 3ю статью про raycasting. В какой-то было и про арктангенс и про ошибки со щелями из-за устранения анизотропии косинусом.
Векторное 3d будет чудовищно медленным при более-менее сносном количестве вертексов. На Векторе есть starwars, но там очень примитивные wireframes. Я тут на днях игрался со скоростной линией по Брезенхейму на одну плоскость. Выложено в GML/graph/LinBPP.mac Уверен, что её можно ускорить. Если заинтриговало, погляди.
Да, ты вроде с головой ушёл в digital design. Это само по себе тоже неплохо, но позволю процитировать: "программистов нет", а новые, думаю вряд ли появятся. Я просто констатирую. ;)
Желтым заметнее, но там в зависимости от места и синее просвечивает и красное
По поводу честного 3d. Star wars я как раз вспомнил и отсутствующую на векторе элиту. На текстурированные треугольники вряд ли хватит скорости (хотя в какой-нибудь демке интересно было бы посмотреть), а на вектора бы скорости хватило
Насчет "ушел с головой" в околоплисовость - тут совпало, что и мне интересно и для работы полезно. А наработки для ВМ80, к сожалению, проблематично использовать на работе
И насчет программистов - все же нельзя полностью исключить, что кто-то (еще кроме тебя :) ) из активно программивших для вектора в конце 80х - 90х захочет тряхнуть стариной
Я прикидывал насчёт векторной графики. В среднем по больнице, быстрый вывод произвольной линией в пол длины экрана по Брезенхейму даёт около 200 линий в секунду. Собственно, там в файле LinBPP.mac есть растактовка, и из неё получается, что уже один порядок с физическим пределом-просто записью в видеопамять. Возможно, вывод можно ещё ускорить сменив алгоритм. Скажем, в 2 раза (я бы поглядел за счёт чего, но допустим). Итого при 20fps получится 20 линий на кадр, если ничего больше не делать. IMHO для полноценного игрового 3д такого недостаточно. Дему можно замутить с предварительно обсчитанными координатами. Повторять элиту, когда есть уже starwars с похожим количеством полигонов смысла мне кажется не очень много.
Ну а насчёт кого-то из 80х-90х, было бы здорово, конечно. Те, с кем я встречался, были в восторге от того, что есть эмули и всё такое, но потом честно признавались: "ничего не помню" :).
Посему, мне кажется, что если тебе реально "хотелось бы посмотреть", то просто надо сесть и сделать. Как там у svofski ... "больше игр нет". Только теперь это можно сказать и про программеров :)
По элите количественных оценок сам я не делал, но рассуждаю так - спектрум несколько быстрее вектора, но по словам Кладова, в спековской элите многое оптимизируемо. Правда он использовал выигрыш для нововведений, а можно просто ускорить. Star wars хорошо, что есть на векторе, но с элитой не сравнить
Сесть и сделать - все зависит от текущего соотношения между ленью и желанием что-то посмотреть (сделать). Локальные нарушения равновесия в пользу сделать вполне возможны
https://www.youtube.com/watch?v=5AH-YOqgOyM
;)
Перед тем, как приступить к тотальной перекройке рендерера на субтайловый режим, профиксил за выходные всё, что не нравилось, и выкладнываю новую версию 0.58. Floppy disk image и список внесёных изменений в 1м сообщении этой ветки.
Для тракинга истории changelog 2х предыдущих версий перемещён сюда.
------------------
v. 0.56a 01.07.2014
------------------
Добавлено:
1. Звуковые эффекты и визуальные эффекты полупрозрачности в меню опций
2. Дополнительные звуковые эффекты на события в игре
3. 2-bit 9kHz звуковой DAC драйвер для воспроизведения вокала на i8253
4. 2-bit 9kHz звуковой DAC драйвер для воспроизведения вокала на Сovox
5. Инсталляционный скрипт
Изменено:
1. Изображение заднего плана в меню опций на "The Guardian" by Nikolai Nazarov
2. Цвета палитры в главном меню на оттенки серого
3. Цвета в меню "Read This"
Теперь в игре есть инсталляционный скрипт install.sub, который запускается автоматически при первой загрузке с диска и устанавливает драйвера, настраивает меню опций и кое-что ещё. При успешной инсталляции скрипт запустит игру и всё должно работать. По умолчанию ставятся следующие драйвера:
1. Sound Effects - через i8253
2. Vocal Sound в заставке 2-bit 9kHz DAC driver для i8253.
возможные альтернативы:
1-bit 7kHz DAC sound driver через бипер
2-bit 9kHz DAC driver для Covox
3. Background Sound - STM через плату Sound Tracker
возможные альтернативы:
Background Sound - STM через плату R-Sound 2
Для того чтобы поменять драйвера на альтернативные, нужно отредактировать инсталляционный файл install.sub, раскомментарив соответствующие строчки, сохранить файл и запустить его из командной строки MicroDOS следующим образом:
a:<install.sub
------------------
v. 0.57a 02.17.2015
------------------
Изменено:
1. Звуковые драйверы загружаются многоцветным шрифтом, ядро игры - нормальным
2. Файлы с вокалом переименованы в boot.sd1 и boot.sd2
Добавлено:
1. Драйвер многоцветного шрифта
2. Для вокальных драйверов, полосы на бордюре промодулированы дополнительным набором полос поверх с разной шириной и цветом в зависимости от громкости звуковой дорожки.
Мелкая имха по поводу темпов музыки - самые быстрые как-то уж очень-очень быстры
Мелкая имха по поводу темпов музыки - самые быстрые как-то уж очень-очень быстры
На самом деле, опции, управляющей темпом там быть вообще не должно. Это опция-временный костыль, за который мне в общем-то стыдно, о чём я недвусмысленно написал в комментах к этому куску ;) кода.
В зависимости от сложности уровня, (геометрия, количество обрабатываемых событий, etc.), время на рендеринг картинки уходит разное. На самом деле, разные фреймы также занимают не одинаковое время: в каких-то фреймах обрабатываются включившиеся по триггерам события, или просто есть вывод тайлов переднего плана с альфа каналом (дорогое удовольствие). Кроме этого, нужно ещё учитывать тип процессора и тактовую частоту. Всё бежит неуклюже с запрещёнными прерываниями.
Я делал вариант, который бежит, в основном, с разрешёнными прерываниями, но управление их разрешением и запрещением отнимает драгоценные такты. Ясно, что когда идёт вывод тайла стеком из банка, прерывания нужно запретить, потом - снова разрешить так как к этому времени, вполне может натикать interrupt request. Потом-снова запретить для следующего тайла, и так - до бесконечности. В общем, кадр в секунду на этом теряется так как мест, где это надо делать за фрейм набегает много :). В принципе, я оставил возможность к такому варианту вернуться: в коде библиотеки GML есть такой conditional O_DION, и надо просто поглядеть, где он используется для разрешения прерываний.
Канал таймера, как в порте Exolon, мне терять было жаль: звуковые эффекты на таймере и так бедноваты, а с двумя каналами, будет ещё хуже.
Видится вот такой более-менее сносный вариант: при старте уровня, проверить, используется ли таймер каким-нибудь из драйверов (сейчас это SFX драйвер), и временно, этот драйвер вырубить на некоторое количество фреймов, чтобы дать возможность рендереру пробежать с разными кадрами. За время пробега, измерить, сколько "абстрактных тайлов" укладывается в прерывание с учётом обработки событий, триггеров и отрисовки оверлеев/спрайтов. Это среднее использовать как счётчик тайлов при выводе. Ясно, что это-средняя температура по больнице (какой-нибудь спрайт с NPC, или большой оверлей внесёт тормоза), но пока лучшей идеи у меня нет.
Заниматься этим всем мне не очень хотелось, поэтому просто вставил примитивный костыль с задержками (которые ешё и криво работают при смене CPU или тактовой частоты). Пока могу ввести понятие нижней границы в опцию меню с диапазоном, хотя, особо не очень хочется вот именно этим заниматься сейчас.
PPC, а если использовать метод Медноногова в работе с прерываниями?
PPC, а если использовать метод Медноногова в работе с прерываниями?
Можно чуть раскрыть, в чём суть метода?
Можно чуть раскрыть, в чём суть метода?
при выводе спрайтов через стек пара ВС
через которую рисуем должна всегда соответствовать содержимому стека
единственное я смутно представляю работу прерываний на Векторе.
и текст дам в z80 кодировке
итак работа со спрайтами
грубо говоря берем простейший вывод спрайта
через стек
;hl адрес спрайта
;de координата
ld (ret_sp0),sp
ld sp,hl
ex de,hl
pop de
ld (hl),e
inc h
ld (hl),d
...
pop de
ld (hl),e
inc h
ld (hl),d
ld sp,$
retsp equ $-2
ret
если внезапно придет прерывание то спрайт будет испорчен
;вот это вешаем на прерывание
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
;теперь немного меняем процедуру рисования спрайта
;hl адрес спрайта
;de координата
ld (ret_sp0),sp
ld c,(hl)
inc hl
ld b,(hl)
inc hl
ld sp,hl
ex de,hl
ld (hl),c
inc h
ld (hl),b
...
pop bc
ld (hl),c
inc h
ld (hl),b
ld sp,$
retsp equ $-2
ret
теперь даже в случае прихода прерывания искажений спрайта уже не будет
при выводе спрайтов через стек пара ВС
через которую рисуем должна всегда соответствовать содержимому стека
единственное я смутно представляю работу прерываний на Векторе.
Там обычное кадровое прерывание. Приходит 50 раз в секунду, если прерывания разрешены.
Спасибо за пример. Подход понятен, но вот так в лоб он на Векторе (в роботах) работать не будет, и свалится вот из-за этого кода:
ld c,(hl)
inc hl
ld b,(hl)
Дело в том, что спрайт (тайл) не лежит в основном ОЗУ Вектора. Он - в одном из 64К банков квазидиска. Доступ туда довольно хитрый: стековые команды типа push, pop, ex (sp),hl работают с памятью квазидиска, в то время как ld reg,(hl) будет работать с основным ОЗУ. Поэтому в <BC> будет значение из ОЗУ, а не из банка памяти.
Кроме того, прерывание (в общем случае) выполняется с отключёнными банками, в то время как выход из него должен вернуть назад режим адресации соответствующего банка, из которого читается спрайт. Увы, регистра статуса включённого банка в Векторе нет. Есть только регистр управления включения доступа к банку, и чтение из него запрещено. Криволапо в общем. Хотя это всё решаемо.
В принципе - спасибки, подход навеял на некоторые размышления. Просто вот так, в лоб не выйдет :).
Очевидное (тупое) решение - запретить прерывания на время задания стека на исходник спрайта (в КД), т.е. EI будет перед первым POP читающим данные спрайта. Наверно можно как-то изящнее
---------- Post added at 17:36 ---------- Previous post was at 17:20 ----------
Кстати, с адаптером z80 Фролова спековский вариант можно использовать практически дословно, т.к. он может читать из КД через ld r,(hl)
---------- Post added at 17:55 ---------- Previous post was at 17:36 ----------
Или так: при старте уровня "закешировать" в основном озу по 2 первых байта из всех актуальных для уровня спрайтов
Очевидное (тупое) решение - запретить прерывания на время задания стека на исходник спрайта (в КД), т.е. EI будет перед первым POP читающим данные спрайта. Наверно можно как-то изящнее
ну есть шанс потерять прерывание...
а так да
di
ld sp,hl
pop bc
ei
Кстати, с адаптером z80 Фролова спековский вариант можно использовать практически дословно, т.к. он может читать из КД через ld r,(hl)
а что за квази диск из которого такие трудности?
di ld sp,hl pop bc ei
ei можно поставить перед pop bc, ухода на обработчик прерывания после ei не будет. Но вариант с "кешированием" еще лучше (если хватит места в основном озу).
Квазидиск (или электронный диск, как его в основном называли авторы) - дополнительное озу на 256 Кб, из которых часть доступна обычным образом, а полностью - через стековые операции.
Очевидное (тупое) решение - запретить прерывания на время задания стека на исходник спрайта (в КД), т.е. EI будет перед первым POP читающим данные спрайта. Наверно можно как-то изящнее[COLOR="Silver"]
Тогда приходим к тому, с чем боремся - по паре di/ei на вывод тайла :)
На самом деле, я сейчас поглядел на код, и вижу, что при запрещённых прерываниях, можно выкинуть переключения квазидиска туда-сюда на выводе каждого тайла. Там вся бодяга из-за каких-то 2х пар push/pop во внешнем цикле вывода во вьюпорт. На стеке хранится начало тайлмапа и координата тайла в видео ОЗУ. Само переключение - это 40 тактов, плюс push/pop дважды - ещё 48 (на Векторе). Итого 88. Можно в 68 всё уложить, если использовать ячейки памяти. Это 20 тактов экономии на тайл. Но всяко с запрещёнными прерываниями.
Кстати, с адаптером z80 Фролова спековский вариант можно использовать практически дословно, т.к. он может читать из КД через ld r,(hl)
Тогда надо иметь 2 рендерера и определять, какой адаптер квазидиска установлен. Совместимость со "стандартным" Кишинёвским адаптером я терять не хочу. В общем-то, такое обдумывалось.
Или так: при старте уровня "закешировать" в основном озу по 2 первых байта из всех актуальных для уровня спрайтов
Кстати не такая уж и плохая идея на самом деле. Изящно. Может получиться. Правда, "актуальных для уровня спрайтов" там 512 только для тайлов (задний и передний планы уровня) плюс спрайты. Легко пара килобайт выходит.
Тогда приходим к тому, с чем боремся - по паре di/ei на вывод тайла
Да, но длительность нахождения в режиме с запретом прерываний при таком подходе все же значительно меньше, соответственно намного меньше и вероятность пропуска прерывания
В глобальной картине "мира" роботов, применительно к выплёвыванию во вьюпорт и неравномерностью саунд трека, это будут копейки по сравнению с тем, как сейчас :)
В общем, пищи для размышлений достаточно. Если кто-то хочет поучаствовать, глядеть надоть на процедуру с меткой Render: в прикреплённом файле (кодировка 866, ДОС-овская).
тогда да
вот такой вариант
;hl адрес спрайта+2
;bc первая пара спрайтов (а что делать если урезание будет)
ld (ret_sp0),sp
ld sp,hl
ex de,hl
ld (hl),c
inc h
ld (hl),b
...
pop bc
ld (hl),c
inc h
ld (hl),b
ld sp,$
retsp equ $-2
ret
Если в основной памяти нет места под "кеш" начала спрайтов/тайлов, то можно так: "кеш" (в данном случае скорее резерв) хранить в КД, при выводе спрайта/тайла прерывание не запрещать, а в обработчике прерывания проверять sp. Если sp "неудачный", то восстановить начало спрайта из резерва. Очевидный недостаток - обработчик прерывания немного распухнет и замедлится.
UPD: Непринципиальная поправка - в данном случае восстанавливать из резерва придется не начало текущего спрайта, а конец предыдущего.
Если в основной памяти нет места под "кеш" начала спрайтов/тайлов, то можно так: "кеш" (в данном случае скорее резерв) хранить в КД, при выводе спрайта/тайла прерывание не запрещать, а в обработчике прерывания проверять sp. Если sp "неудачный", то восстановить начало спрайта из резерва. Очевидный недостаток - обработчик прерывания немного распухнет и замедлится.
не....
концепт неверный
со спрайтами работаем по методе Медноногова
но после каждого спрайта держим 2 байта пустых.
чтобы при установке при приходе прерывания в этом месте
ld sp,hl
pop bc
чтобы испорченная пара байтов не принадлежала спрайту
после каждого спрайта держим 2 байта пустых.
так вобще хорошо! Незначительное увеличение сложности расчета адреса спрайта, зато обработчик прерывания можно упростить
В общем, мне кажется, что проще всего на момент вывода во вьюпорт подменять ISR на специальный вариант, использующий память вместо стека для сохранения вообще всех регистров, затем - выключить квазидиск, переключиться на свой локальный стек. А по концу ISR просто восстанавливать все регистры и режим КД и делать jmp, как выше.
По окончании вывода во вьюпорт - вернуть на вектор ISR7 нормальную ISR.
Тогда не надо делать промежутки между спрайтами.
Как-то так:
di
shld TheHL
lda IsLastWord
jnz skipRestore
pop h
push b
SkipRestore:lxi h,0
dad sp
shld TheSP
lxi h,0
dad d
...
DB (lxi)
TheHL: DW 0
...
Можно вместо IsLastWord использовать факт, что тайлы выводятся на совершенно определённые адреса видеопамяти, и анализировать регистр <L>
PPC, мне кажется ты вчера помнил, а сейчас как-то забыл (работа наверно влияет) про запись в стек текущего адреса при начале обработки прерывания.
PPC, мне кажется ты вчера помнил, а сейчас как-то забыл (работа наверно влияет) про запись в стек текущего адреса при начале обработки прерывания.
Так я вроде запорченный спрайт восстанавливаю. Просто если SP уже переключен, то этого делать не надо. А в качестве индикатора, надо ли восстанавливать стек, можно использовать в ISR, скажем, значение старшего байта <SP>. Или что-то не так?
PPC, наверно я что-то недопонял в твоем предложении. Как ты предлагаешь восстанавливать спрайт, если он был запорчен адресом возврата после задания sp на спрайт, но до pop?
PPC, наверно я что-то недопонял в твоем предложении. Как ты предлагаешь восстанавливать спрайт, если он был запорчен адресом возврата после задания sp на спрайт, но до pop?
Всё также, как в оригинале от jerry: запретить прерывания, поставить стек, считать <BC>, разрешить прерывания, побежать.
Если без запрета прерываний, то да, нужны промежутки между спрайтами, но это как-то некузяво выглядит имхо, хоть и должно быть быстрее (сразу потеря 8 тактов на спрайт).
PS. В качестве уточнения: 2х-байтные промежутки ДО спрайта, не "после".
запретить прерывания, поставить стек, считать <BC>, разрешить прерывания, побежать.
т.е. фактически
запретить прерывания на время задания стека на исходник спрайта (в КД), т.е. EI будет перед первым POP читающим данные спрайта
В оригинале jerri все же было не так
В оригинале jerri все же было не так
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 ----------
Если это push - ничего не делаем, если не push - заменяем адрес возврата на вершине стека на содержимое регистровой пары (скорее всего bc) в которую был lxi.
Момент, касающийся вывода первых 2х байтов, про который забыл написать. Там м.б. что-то типа такого: lxi b,d16; sphl; push b; lxi b, d16; push b и т.д.
Еще одна вещь - в обработчике нужно проверять, куда сейчас указывает sp. Если в экран - действуем, как написано выше.
Ну и, конечно, можно просто использовать таймер, если не жалко одного канала.
---------- Post added at 14:48 ---------- Previous post was at 14:42 ----------
lxi b,d16; sphl; push b;
Еще вариант - вместо sphl здесь может быть shld, меняющий адрес обработчика прерывания. Тогда в обработчике можно не проверять, куда указывает sp.
---------- Post added at 16:03 ---------- Previous post was at 14:48 ----------
вместо sphl здесь может быть shld, меняющий адрес обработчика прерывания. Тогда в обработчике можно не проверять, куда указывает sp
Проще не трогать в указанном фрагменте 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 определить). Добавляем в специальный список координаты на тайл ниже. После отработки основного цикла вывода тайлов дополнительно обновляем тайлы из списка. Перед началом нового цикла вывода тайлов очищаем тот список.
Проще не трогать в указанном фрагменте sphl и менять обработчик один раз - перед выводом тайлов (не каждого отдельного). И пока выводим тайлы sp всегда "в экране".
Применительно к роботам - именно так, и никак иначе. При любом раскладе, нужна custom ISR. Вообще, обработчик нужен только для "равномерного" воспроизведения музыки/спецэффектов, и ни для чего больше. Увы, и музыка, и спец-эффекты, и соответствующие драйверы для них лежат в других страницах и банках квазидиска. Под страницами я имею в виду доступ к квазидиску "как к ОЗУ", под банком - как стек.
Поэтому, "переключение контекста" внутри ISR неизбежно. На самом деле, таких переключений - 3 штуки: 2 выполняются кодом входа в музыкальный драйвер из контекста ISR. Драйвер бежит в соответствующей странице, которые разные для SFX и саунд трека.
После выполнения драйвером "рендеринга" музыки, он возвращает назад режим квазидиска, в котором бежала ISR, и выходит по ret. Это надо учитывать.
Зато я вот сейчас сделал версию, которая не переключает квазидиск назад-вперёд при выводе тайлов в ОЗУ (бежит в режиме доступа стеком к тайлам всё время заполнения вьюпорта из тайлмапа). Только такая простая фишка, сразу дала выигрыш в целых 3 тайла на рендеринг экрана. Офигительно ощутимо даже визуально.
Увы, я не могу пока сделать тоже самое для тайлов переднего плана с альфа каналом. Они большие (24К вроде), и лежат не в том банке, где тайлмап. Эхх. Можно (нужно), конечно, скопировать тайлмап туда, где тайлы, но тогда придётся куда-то двинуть фонты :). Это всё не даст такой-же выигрыш, как с тайлами заднего плана, потому, что передний план не заливает весь экран (только всякие батарейки и "экраны"). Буду думать.
Версию "по Медногоногову" планирую попробовать на этих выходных. На работе не просто завал, а аврал. Не до роботов, сам как робот, по программе дом-хайвэй-работа-хайвэй-дом. :)
Стало фастер - вери хорошо! Наверняка при уменьшении шага перемещения (если созреешь на это дело) резервы скорости понадобятся.
Насчет моих хитромудрых измышлений в предварительном посте (http://zx-pk.ru/showpost.php?p=837830&postcount=167) - без большей части того, что там написано можно обойтись (http://zx-pk.ru/showpost.php?p=837867&postcount=169).
Да, стало фастер :). Попробую скрестить это с Медногоговым, поглядеть, насколько просадит фпс, и главное - насколько неровно будет играть.
Да, шаг перемещения, думаю, будем уменьшать. Но до этого - возможно выложу эту более быструю версию. Только вот погляжу, как оно будет с Медноноговым, или без.
Development update:
Сделал вариант по Медноногову и с моими ускорениями: тайлмап читается режимом квазидиска "как ОЗУ", тайлы - режимом "как стек" одновременно, что позволяет не переключать режим на каждый тайл, и даёт прибавку к скорости в 3 тайла на вьюпорт. Вывод музыки хромает как секс со старой бабушкой, глотая прерывания в многочисленных местах, где происходят переключения банков и переустановки стеков (прерывания там запрещены). Правда, весь передний план пока тоже выводится при запрещённых прерываниях, так что ближайшая задача - напустить Медноногова и на этот код. Поглядим, что можно выжать из этого. Если будет хотя бы сносно, выложу оба варианта на обозрение публики. Два варианта развития кода мне не потянуть, будем голосовать, или что-то в этом роде.
Зато эха снова оживает, и это приятно. ivagor проводит чудовищные эксперименты с ШИМом, которые можно производить "только при разрешении соответствующих органов" (с) Булгаков. Прикольно, если ему удастся запулить "Электричество" с лучшим качеством, и меньшим размером :). Сейчас - 30 секунд саундтрека в 60 с хвостиком килобайт на частоте дискретизации 9КHz двухбитовой DAC.
PPC, а ты не думал о переносе задач, требующих запрета прерываний, в обработчик?
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убтайловым рендерером (разрешение в пол тайла) использующая алгоритм УШИ (http://zx-pk.ru/threads/9569-programmnyj-vertikalnyj-skroll.html?p=832045&viewfull=1#post832045).
Клавиша <Shift> в игре - режим бега.
Код рендерера теперь выглядит как хорошая китайская головоломка.
Всех с Наступающим Новым Годом! :v2_dizzy_christmas2::v2_dizzy_christmas:
В первом посте выложена версия 0.63a
Robotz! Changelog
------------------
v. 0.63a 01.16.2017
------------------
Изменено:
1. Изменён формат хранения тайлов заднего плана в файле level001.spt (добавлены 2-х байтовые межтайловые промежутки по идее (http://zx-pk.ru/threads/19922-robotz!-releases.html?p=836375&viewfull=1#post836375) 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> на входе - индекс тайла):
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
Со сдвигами у меня не получалось быстрее 80 векторовских тактов на выборку.
Использовать <BC> или <HL> нельзя: регистр <BC> на входе кажет в предыдущий битмап (не всегда в его конец), в <HL> - координаты тайла в тайлмапе. Подумалось сейчас, что в общем-то <BC> можно использовать, если его после рендеринга тайла всегда выставлять на промежуток между битмапами, и использовать его как новую базу при вычислениях (от самого <BC> толку почти нет: 80е процы не ортогональны).
Посчитал статистику.
Для вывода выровненного на тайлы заднего плана, новый подход даёт 2097 тайлов в секунду (2-х битовый тайл 16x16), что для вьюпорта 13x10 тайлов занимает 186800 тактов (со всеми циклами, переключениями банков и т.д) и рендерит 16 FPS.
Для вывода субтайлового кадра получил 2054 тайла в секунду, 15.8 FPS. Но пришлось слегка замедлить, чтобы бежать с разрешёнными прерываниями когда нужно читать из середины битмапа. Вопрос, который jerri задал сам себе:
(а что делать если урезание будет) (http://zx-pk.ru/threads/19922-robotz!-releases.html?p=836061&viewfull=1#post836061).
Всё-же не хотелось запрещать прерывания нигде, и пришлось двигаться по битмапу ползком, т.е. стеком до нужного места.
Это сказалось: 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-е. Как обычно технически очень круто, но не очень понятно, что нужно делать. Я бы наверное оценил версию, где можно просто повтыкать в экран, ничего не нажимая.
В любом случае я очень рад обновлениям, спасибо! С наступающим!
PPC, любопытно. Под моим эмулятором дело встает на первом вызове cp.com. Подозреваю, что дело в каких-то тонкостях эмуляции вг93. Заметил, что это вообще не самый обычный МикроДОС. Он есть отдельно от ROBOTZ!ов ?
svofski, МикроДОС там самый обычный. BIOS там Bold 2.x, я не помню чтобы я ВГ93 код в нём менял хоть чуточку
В картотеке это файл MDBOLD21 вот тута: http://sensi.org/scalar/ware/835/
У тебя есть диски с Bold 3.0, вот там - да, мы много попахали ВГ-шкой чтобы поддерживать разные форматы. А тут всё должно быть нормально.
cp.com скомпилена BDS C компилером. Надоть смотреть как там read() и write() проимплементированы.
(Meanwhile, я где-то в хвосте очереди задач интересуюсь перспективами доработок МикроДОС-а. А если вдруг есть что-то в исходниках и можно не изобретать велосипед, было б проще).
Увы, сырки Bold BIOS похоже безвозвратно утеряны. Это были такие длинные .asm файлы с загадочными комментариями. Просто BIOS ессно начинался с дизассемблирования stock МикроДОСа каким-то интерактивным CP/M дизассемблером. Все дискеты побились, увы - 25 лет всё-ж прошло. Я был бы счастлив тебе всё это отдать, там c ВГ, и не только с ней немало уже было сделано.
Сам ROBOTZ! заценил в b2m-е. Как обычно технически очень круто, но не очень понятно, что нужно делать. Я бы наверное оценил версию, где можно просто повтыкать в экран, ничего не нажимая.
В любом случае я очень рад обновлениям, спасибо! С наступающим!
Спасибо!
Там всё как обычно: ходить-бродить, открывать двери, собирать power-ups, искать выход, допускать минимум повреждений и экономить электроэнергию :)
Ну и на этом уровне всё довольно головоломно. Необходимо терпение и чуть наблюдательности чтобы собрать все ключи и найти как выйти: хоть всяких подсказок там и дофига, но я их чуть спрятал за общим тайловым кошмаром.
Приятно, что понравилось. Там графики одной под 100К на уровень. А какой там рендерер под этим, мама не горюй - субтайловый 6-битовый с 3-х битовым альфа каналом . Мне (точнее Вектору) нужна DMA и SMP :)
C Новым Годом!
Видимо это просто утилита хитрая. Запись я в своих эмуляторах вообще практически не проверял, а вот и появился хороший повод.
Уже проинсталлированный ROBOTZ! советую заценить именно в vector06sdl, потому что звук в нем звучит.
А какой там рендерер под этим, мама не горюй - субтайловый 6-битовый с 3-х битовым альфа каналом . Мне (точнее Вектору) нужна DMA и SMP
Я бегло просмотрел changelog. Но даже мне не совсем очевидно, что многие из слов в нем значат. Было бы интересно послушать семинар, или просто ютубу с рассказом о том, как page flipping заменяется на scroll masking и про развитие метода Медноногова ;)
Второй этаж, справа от лифта. Рекомендую :) Туда достаточно просто добраться: идти по 1му этажу вправо, найти лифтовый контрольный модуль и вставть его слева от шахты, затем идти дальше вправо до момента, когда остановится двигатель, снять с него жёлтое колесо, установить колесо в лифтовую шахту, вернуться к контрольному модулю починенного лифта и ждать, когда он придёт по вызову.
Ха, вместо семинара можно отмотать этот тред вот на это судьбоносное сообщение от jerri:
https://zx-pk.ru/threads/19922-robotz!-releases.html?p=836375&viewfull=1#post836375
С него всё и началось :)
Плюсую восьмицвет. Можно ли ускорить старт/загрузку?
Да. Попробуй удерживать клавишу <УС> в смысле <CTRL> при старте игры (это упоминается в FAQ). Вокала вообще не будет, и печать побежит быстрее. До кнопки <S> в игре уже добрался?
Как тебе обновлённое меню Options (цвет номер 20)?
Да. Попробуй удерживать клавишу <УС> в смысле <CTRL> при старте игры (это упоминается в FAQ).
Эх, даже в игрушке нужно читать readme.
Кнопку S нажал - вижу что убирает/показывает панель.
Как тебе обновлённок меню Options (цвет номер 20)?
Цветомузыка, прикольно.
Присоединяюсь к svofski по поводу желательности демо-режима. Или ютубы с игровым процессом.
ivagor, это всё ещё сырая альфа, и робот там полупрозрачный, и NPC ещё нет пока. Планов громадьё, но сейчас я really хочу чуть-чуть отдохнуть :) Чуть офигевший от перетолмачивания графики. Сборка, которая пошла в 0.65a была собрана буквально сегодня. Буду несказанно рад, если походишь, побродишь, меня самого там несколько моментов достаёт: в частности - очень много труб на которые надо запрыгивать IMHO. В общем, игровой процесс там всё ещё далеко несбалансирован, потому, что весь мой пар пошёл на антураж и скорость рендеринга. Рано наверное запулять в ютубу. Но когда-то мы доберёмся до заветной версии 1.0b
С Наступающим тебя! :)
PS. Демо-режим сделаю :)
С Наступающим тебя!
Спасибо, тебя тоже с наступающим!
Насчет походить у меня туго, я слишком казуален для роботов. Syntal смог пройти старую версию, может и к этой примерится.
Syntal смог пройти старую версию, может и к этой примерится.
Я был молод и горяч, прошу меня понять. Всех вектористов с НГ!!!
https://pp.userapi.com/c628623/v628623736/212ef/ViJ6cUVLIcs.jpg
Ждем авторского демо-режима.
PPC, а ты коллизии спрайтов с тайлами и с другими спрайтами по координатам определяешь?
ivagor, а там пока только координаты ГГ проверяются, а что? На самом деле, алгоритм (но не имплементация!!!) примерно такой (по памяти): берётся текущая ширина ГГ в тайлах (движок считает эту величину переменной), и определяется координата центра спрайта в пикселах. Может попасть либо на границу тайлов из которых сделан спрайт, либо - на центр тайла (когда количество тайлов в спрайте - нечётное). К вычисленному в "экранных" координатах центру, прибавляются "физические" толщины ГГ в пикселах от центра, заданные в специальном файле-описателе параметров ГГ, и полученные величины превращаются в координаты в тайлах с округлением в большую сторону. Затем на тайловой карте производится проверка на попадания "граничных" тайлов ГГ на свободное (тайлы с величинами 0-0x7F) или занятое (0x80-0xFF) место. На самом деле, всё ешё сложнее, потому, что многие вещи не вычисляются каждый раз, а предкомпилированы, и код гонится по заранее известным веткам в зависимости от нажатых клавиш. Но на самом деле, всё ещё сложнее, потому, что во время прыжка или бега, алгоритм задаёт не единичные входы, и обсчёт движения за одно обновления экрана может включать несколько итераций. Как-то так. Если у тебя остался сырок, то вся эта байда происходит в файле vp.mac. Единственно, о чём надо помнить, что кроме соударений с препятствиями, на ГГ могут действовать и другие силы и они тоже обсчитываются там-же. Так сделана гравитация и также сделан эффект движения на платформе лифта.
;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
Подскажите, здесь приведён пример с прерыванием и выводом графики. Вроде бы разобрался, даже будет работать, если в этот момент не спрайты рисуются. Но возникает вопрос. Если стек SP был на одном адресе, то при переходе на прерывание он уменьшается. Здесь где выделено, он уже уменьшенный и imm_sp он присваивается, уменьшенный, а не каким он был изначально. Ведь выход не RET, а JP. Значит он не увеличится сам. Как это понять? Не должен ли быть он между PUSH и POP?
И ещё,
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 ;заменяем испорченное слово спрайта
push bc ;на текущее слово находящееся в BC
ld (imm_sp),sp
ld sp,ISR_sp
;здесь идет обработка прерывания
; ...
;----------------------------------
ld sp,$
imm_sp equ $-2
ei
jp $
imm_jp equ $-2
Подскажите, здесь приведён пример с прерыванием и выводом графики. Вроде бы разобрался, даже будет работать, если в этот момент не спрайты рисуются. Но возникает вопрос. Если стек SP был на одном адресе, то при переходе на прерывание он уменьшается. Здесь где выделено, он уже уменьшенный и imm_sp он присваивается, уменьшенный, а не каким он был изначально. Ведь выход не RET, а JP. Значит он не увеличится сам. Как это понять? Не должен ли быть он между PUSH и POP?
И ещё,
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
если внезапно придет прерывание то спрайт будет испорчен
ld (imm_jp),hl
pop hl ;заменяем испорченное слово спрайта
push bc ;на текущее слово находящееся в BC
ld (imm_sp),sp
ld sp,ISR_sp
Правильно будет может так?
ld (imm_jp),hl
pop hl ;заменяем испорченное слово спрайта
ld (imm_sp),sp
push bc ;на текущее слово находящееся в BC
ld sp,ISR_sp
Ведь заходим в прерывание по CALL, а выходим по JP. Значит SP при выходе из прерывания будет SP = SP - 2.
Код из Robotz 0.65a
Пояснения:
Assembler: Microsoft M80
ISR прерывает выполнение в multi bank mode: спрайты с 2-х байтными gaps в отдельном 64К банке с доступом стековыми операциями, операции память-память происходят в основной RAM
PGE_OFF - макро, выключающее банкинг и включающее 64K main RAM в адресное пространство 8080 на Векторе
XTB_SP - стек для ISR в основной памяти (предустановлен при настройке рендерера спрайтов)
XTB_RDM - слово-состояние порта 10h (банк со спрайтами, куда нужно переключиться по выходу из ISR, также предустановлено заранее)
RamDrv EQU 10h
PGE_SET Macro
out RamDrv
EndM
PGE_OFF Macro
xra a
PGE_SET
EndM
;===========================================
; Tile Renderer Interrupt Service Routine
;-------------------------------------------
;INPUT: <BC> stack top restore value
;OUTPUT: none
;===========================================
IsrXTB: shld XTB_HL
pop h
shld XTB_RET
push PSW
lxi h,0
dad SP ; <CY> is FUBARed
shld XTB_ESP
PGE_OFF ; assumption is that XTB_SP is in main RAM bank
DB (lxi SP)
XTB_SP: DW 0
push d
push b
call SndCBH ; call sound/SFX callback hook with assumption
;PGE_OFF ; that SndCBH will set STACK access to main RAM
pop b ; bank 0 on return (PgeRDM set satisfies this)
pop d
DB (mvi a)
XTB_RDM:DB 0
PGE_SET
DB (lxi sp)
XTB_ESP:DW 0 ; entry stack
pop PSW
push b ; restore stack, corrupted by XTB_RET
pop b ; using <BC>
DB (lxi h)
XTB_HL: DW 0
ei
DB (jmp)
XTB_RET:DW 0
В первом посте выложена новая альфа версии 0.66a
Было время слегка пошаманить на праздниках. Список изменений, как обычно, в файле changelog.txt каталога Readme.
Прошу любить и жаловать. Благодарю заранее за ваши критические комментарии и замечания.
Плюсую добавочные фазы анимации ГГ. Ну и просачивание демоэффектов в игры тоже хорошо.
Плюсую добавочные фазы анимации ГГ. Ну и просачивание демоэффектов в игры тоже хорошо.
Спасибо. Надо будет ещё фазы для разных режимов типа ходьба/бег/лазанье сделать. Пока не стал потому как анимация черновая.
Ещё из занятного в этой версии - это всплывающие подсказки-тултипы, зависимость повреждений от высоты падения, отображение их степени и предметов инвентаря в MFD. Много всяких мелких незаметных плюшек типа цветного текста в основном меню и прочее и прочее. Думаю, настала пора добавлять супостатов-неписей. Так, глядишь лет через N допилим. Эх, ещё бы времени свободного было побольше!
parallelno
11.01.2023, 10:05
PPC, почемуто не запускается на vv, emu80 и v06c эмуляторах. не пойму что я делаю не так.
0.66 пробовал в Emu, предыдущие и в других эмуляторах, проблем не было.
У меня запустился в emu80 просто так, просто открыл fdd и нажал F12. В v06x почему-то говорит BDOS error on A:SYSTEM.FNT DISK ERROR. Наверное в v06x не понял, что тут диск чуть больше обычного, или что-нибудь такое.
Попробовал 0.66 в emu, emu80, vv, v06x-godot - везде работает.
PPC, почемуто не запускается на vv, emu80 и v06c эмуляторах. не пойму что я делаю не так.
Странно. Закачал с сайта, распаковал, смонтировал FDD как диск A в VV a в emu прописал к нему путь в конфиге.
Всё запустилось. Думаю, просто не запускаете инсталляцию. Надо реально запускать МикроДОС с системных дорожек этого диска и дать batch файлам проинсталлировать драйверы и шрифты. Роботов batch файлы сами по концу инсталляции запустят.
svofski, может в VV привод стоит в R/O? Там есть чекбокс в меню.
Если да, то попробуй убрать этот checkbox и перезапустить с командной строки МикроДОСа
<install.sub
А после запуска роботов выйти из них по нормальному через QUIT GAME в МикроДОС и потом закрыть эмулятор
parallelno
12.01.2023, 08:52
PPC, спасибо, попробую.
Попробовал 0.66 в emu, emu80, vv, v06x-godot - везде работает.
Уточнение - процитированное утверждение справедливо при использовании образа дискеты с инсталлированной игрой. Если взять исходный образ из архива, то v06x-godot споткнулся при инсталляции, остальные нормально.
parallelno
12.01.2023, 20:30
PPC, Получилось запустить в VV. Раньше не работало из-за того что в эмуляторе был отключен auto run.
Графоний в игре стал еще краше, всякие лаппочки моргают, класс! Сначала увидел анимированный айтем, прикольно! А вот робота почти не было видно. После того как умер, не нашел по какой клавише вернутся в меню.
PPC, Получилось запустить в VV. Раньше не работало из-за того что в эмуляторе был отключен auto run.
Графоний в игре стал еще краше, всякие лаппочки моргают, класс! Сначала увидел анимированный айтем, прикольно! А вот робота почти не было видно. После того как умер, не нашел по какой клавише вернутся в меню.
Спасибо за коммент, Auto-run против batch файлов... ;)
Рад, что вышло запустить. Робота не видно потому как пока его графика черновая, об этом я честно пишу в прилагаемом changelog.txt (в каталоге Readme в архиве).
Выйти из игры в основное меню и вернуться назад (если робот не помер) можно в любой момент по клавише <АР2>, aka <ESC>. Выход из всех меню по этой клавише. Об этом подробно написано в подменю "READ THIS" основного меню. Там прописаны почти все клавиши управления для всех меню и режимов игры. Но никто не читает, хоть и написано, что надо...pilot error :)
Похоже, проблемы остались только у svofski c BDOS ERROR на системный фонт. svofski, я дико извиняюсь, в спешке решил что проблемы с VV, а они с V06x. C VV и emu у тебя, похоже, всё в порядке. Если это критично и повторяемо, я погляжу как время будет.
PS. В основное меню можно также вернуться отовсюду через <БЛК>+<CБР>. Но это, конечно не стандартный путь.
Старые версии не пробовал, а в VV 7.04 0.66 инсталлируется и играет и с включенным Auto Run и с выключенным.
Мне кажется, где-то раньше в этой ветке пролетало сообщение от svofski о том, что он наблюдал в V06x какие-то проблемы с утилитой cp.com.
Она используется инсталляционным скриптом для копирования драйверов по-умолчанию из разных user areas дистры. Возможно, это какие-то проблемы с имплементацией файловых операций у эмуля V06x .
Мне кажется, где-то раньше в этой ветке пролетало сообщение от svofski о том, что он наблюдал в V06x какие-то проблемы с утилитой cp.com.
Она используется инсталляционным скриптом для копирования драйверов по-умолчанию из разных user areas дистры. Возможно, это какие-то проблемы с имплементацией файловых операций у эмуля V06x .
Файловые операции мой эмулятор не эмулирует, только дисковые. Будет время, посмотрю -- хорошо, что есть известный пример для воспроизведения баги.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot