Все 25 ФПС. Там гонка за лучомЦитата:
Сообщение от Smalovsky
Firefly, batman caped crusader redheat etc
Вид для печати
Все 25 ФПС. Там гонка за лучомЦитата:
Сообщение от Smalovsky
Firefly, batman caped crusader redheat etc
я как раз про бипер и геймплей.Цитата:
Сообщение от Smalovsky
Посмотрите что стало с игрой в режиме турбо на 7МГц (момент ролика 13:19).
https://www.youtube.com/watch?v=C5TAeqfl9TM
А вообще режимы турбо возможно подходят лишь для игр, где динамика построена на прерываниях. В остальных только портят играбельность. В каком то обзоре слышал, что всего несколько игр выигрывают при включении режима турбо.
Забавно, что когда авторы создавали игры, им был нужен максимально быстрый код. Я сейчас подумываю об аппаратно реализованном контролируемом торможении исполнения кода, чтобы не ломать авторский геймплей (у меня АК ускоряет исполнение).
Я немного пошпионил и узнал методы удаления клешинга от двух людей. Ещё есть два антиклешера. У них слабоватые технологии, но моя тоже не на высоте.
Эх еще же немного и победа братцы. Я прям чувствую как клешинг начинает уходить. C 20.07.2016 клешинг уменьшился уже на 11 процентов, сегодня 1798-ой день борьбы с этой напастью. Клэшинг сам себя не уменьшит XD
coffee, описание принципа не хочешь сделать открытым? Я ,например, делаю описание своего принципа, но ещё не доделал его полностью. Собираюсь потом полное описание сделать открытым.
обязательно. Но через 5 лет (по традиции :) )Цитата:
Сообщение от Smalovsky
А вообще как это еще можно сделать меня не волнует - несколько вариантов я сам вижу. Важно другое - научится быстро обрабатывать/изучать игры на предмет адаптации под АК и раскраски (без нее эффект недостаточно красивый).
сиджей и аналогичный сеймур используют; диззи новые - новые два 128k экрана; диззи старые - вроде все рисуют сразу в экран (но мб и без буфера заморочки - во втором емнип сохранение разницы с подспрайтовым фоном и восстановление ксоркой)Цитата:
Сообщение от Smalovsky
- - - Добавлено - - -
да, и даже еще раньше и ниже (причём почему-то без ног))Цитата:
Сообщение от coffee
Привет всем. Дополнил описание параграфом про аппаратное ускорение для игр использующих теневой буфер. Также в описании рекомендовал использовать турборежим.
Отправил описание Ynicky. Интересно, что он напишет в ответ.
- - - Добавлено - - -
coffee, могу выслать тебе незаконченное описание моего видеорежима для просмотра и совета. Но правило такое - не выкладывать описание в интернет, и писать о видеорежиме на форуме не расскрывая деталей .
с точки зрения дремучего технологические навороты есть магия. если человек не знает про хэндс-фри то идущий рядом человек глядящий в никуда и разговаривающий - чекнутый. а накрутив себя до посинения в части дремучести - он ваще маг и говорит с духами.Цитата:
Сообщение от Smalovsky
то что для постороннего ахалай-махалай для Акопяна просто "ловкость рук и никакого мошенничества". скажу по секрету - разпиленные девушки - на самом деле их в ящике две. только тсс, магию изпортишь.
Честно говоря меня мой метод вполне устраивает, он хотя и очень гемморойный в плане исполнения (долго мучался над реализацией), но зато берет мало ресурсов, как по LE, так и по памяти. Сравните с "железом" для ULAX. Кстати я прикинул, что вполне могу делать АК по всем персонажам, а не только по главному герою. Но подумалось не даст это ничего особо зрелищного, а попотеть придется немало. А так контраст обесклешенного ГГ и остальных персонажей с клешом придает некий шарм. На контрасте лучше виден эффект.Цитата:
Сообщение от Smalovsky
Так что интереса к твоему алгоритму нет, но если тебе хочется знать мое мнение на тему "взлетит или нет" твой движок, то высылай, публиковать, распространять не буду, использовать тоже :) . А что сам то не сделал за 5 лет? Как говорят "железячники": "главное не то что в принципе, а то что в кожухе"(С)
честно говоря, от меня ускользает смысл экономии сегодня внутренностей плиса и памятиЦитата:
Сообщение от coffee
экономить нужно время спектрумистов, а не железки, лишь бы по карману было желающим
в дефиците нынче могут быть только ноги плисины разве что
ты ж не знаешь, сколько точно жрал тест юлакса только по антиклэшингуЦитата:
Сообщение от coffee
выбор плиса больше на перспективу, а мегабайты памяти - еще и ради удобства
можно меньше, но зачем заставлять корячиться программиста из-за мелкой экономии на железе
это мы уже проходили, не надо больше
Железка! Железку хочу! Де моя железка?! Стримить с железки! Железка!Цитата:
Сообщение от Lethargeek
Железка! Железку хочу! Де моя железка?! Шобы кот с железки стримил! Железка!Цитата:
Сообщение от Black Cat / Era CG
Скрытый текст
ну ты в курсе, что сие уже зависит не от меня :([свернуть]
Моя железка совсем не заточена под АК, это просто неплохой (как я думаю) клон спектрума, а АК - всего лишь дополнительная фишка/демонстрашка и вряд ли я буду обрабатывать кучи игр под АК. Просто проверил свои навыки - выйдет или нет. Оказалось можно сделать движок который позволяет на скромных ресурсах показывать нормальный результат. Там просто другой подход чем у вас. Даже сейчас я могу посадить всех персонажей на АК. А если чип будет всего раза в полтора мощнее (или если выкинуть PCG или текстовый оверлей на том же чипе), то вообще там пойдет АК для любой игры.Цитата:
Сообщение от Lethargeek
Вы в какую CPLD можете затолкать АК (если выкинуть лишнее, включая тесты), по минимуму? Небось только в корпуса BGA, значит дорогие платы и монтаж? Кстати у вас вроде на CPLD главный герой получался лишь двухцветным, так? Многоцветным он был только на эмулях и FPGA? А на "живом" Z80 есть версия? А вообще своя железка (не покупная девборда) есть? У меня есть, даже в корпусе (небольшой, 80х50мм). Правда дырки осталось отфрезировать под разъемы:
Вложение 75786
На самом деле, работа, сделанная вами просто огромная, я снимаю шляпу. Не только сама реализация АК в принципе, но самое главное: столько игр, надо перепахать код, вытащить нужные данные, раскрасить спрайты, сделать индивид.конфиги для загрузки. Это очень круто!
Но по железу расклад другой. Сделать как у вас (накидав кучу слоев в большой памяти, да еще на жирных чипах) я могу. А вы можете сделать как у меня, на оригинальном Z80 и на EPM1270? :v2_dizzy_roll:
в общем-то, это и в юлаксе не главное, сейчас просто отработано лучше прочегоЦитата:
Сообщение от coffee
не ко мне вопрос, и не было никакой цплд, тестили на борде, оказавшейся под рукой, притом неудобной для нас из-за динамической памятиЦитата:
Сообщение от coffee
надо переспрашивать Ynicky, сколько в ней заняло (но там кроме антиклэша был и z80, и даже файлы вкрячены в прошивку, трудно сказать)
тестов было несколько же, Wally и в оригинале двухцветным был, но спрайты Chuckie Egg уже разноцветныеЦитата:
Сообщение от coffee
а вообще вопрос довольно бессмысленный, потому что схема не работает на уровне целых спрайтов
да и не во всех игрушках спрайты бывают, точки-линии-текстуры тоже надо уметь
после пары дюжин стало рутиной, изредка только код запутанный попадаетсяЦитата:
Сообщение от coffee
раскрутить код получается быстрей намного, чем спрайты красить
потому предпочитаю игры с цветными атрибутными спрайтами
чтоб автоматически красились, как выбрал автор оригинала
*устало* столько раз уже говорено было здесь, что нету никаких там слоёв, и в документации всё расписано, и вот опять :v2_dizzy_facepalm:Цитата:
Сообщение от coffee
лично мне такой цели даже ставить не хочется, без софта железячные изыски неинтересныЦитата:
Сообщение от coffee
насколько я помню, ваша команда начала проект довольно давно. У меня работе над сабжем еще года нет, но я укоряю себя за долгострой. А вы еще тестите на девбордах, что "под рукой"...Цитата:
Сообщение от Lethargeek
В оригинале художники Микрогена нарисовали Wally 4-(или даже 5)-цветным (см. постеры и амстрадовскую версию). Под спектрум они плача, урезали до 2х цветов. У вас самих видео на эмулях имели несколько цветов, а более поздние версии под CPLD - всего 2. В этом же треде мне давали ссылки на видео прошлой осенью.Цитата:
Сообщение от Lethargeek
виноват. Чукча не читатель. Я начал читать этот тред с начала, где писали про слои, но потом устал (очень много страниц), а как вы сделали потом на самом деле - не знаю. Честно говоря времени на тред потратил больше чем на реализацию первой версию АК.Цитата:
Сообщение от Lethargeek
я понял теперь что ты по спектруму работал, по играм, а есть кто железом занимался. Был не в курсе, сорри. Просто я обращался к тебе как к команде проекта. Но вопрос на самом деле простой: у вас (у команды) на выходе своя железка есть? Или все на девбордах играетесь?Цитата:
Сообщение от Lethargeek
а ты попробуй поработать в такой команде, когда все по разным городам, лично не знакомы до этого, и у всех свои проблемы и бытовухаЦитата:
Сообщение от coffee
всё куда сложнее и медленнее, чем делать одному (когда всё, что нужно, знаешь и умеешь, естественно)
да я там говорил про оригинал своей раскраски, конечно жеЦитата:
Сообщение от coffee
почему-то нет там видео chuckie egg, у меня где-то в закромах валялось скачанноеЦитата:
Сообщение от coffee
да ты, похоже, там на первой же странице уже устал))) потому что про слои было чётко сказано уже в шестом сообщенииЦитата:
Сообщение от coffee
и с девбордами давно уже не играемся, тотем вроде что-то там паяет, но очень изредкаЦитата:
Сообщение от coffee
я чужих проблем решить не могу, хорошо хоть со своими успеваю своё пилить
да не, я про этот тред имел в виду. А ваш Ulax (более поздний) я вообще не читал, говорю же чукча -писатель :)Цитата:
Сообщение от Lethargeek
coffee, выслал описание. Поделись впечатлениями.
Увидишь, что мой видеорежим очень простой для восприятия, но для разработки игр требует высокий порог вхождения.
- - - Добавлено - - -
Lethargeek, не знаешь какие популярные процедуры применяются для печати спрайта по маске в играх с высоким фпс? Может, ссылки знаешь,где посмотреть?
Да, я получил. Посмотрю, отпишусь.Цитата:
Сообщение от Smalovsky
- - - Добавлено - - -
я не профи в этом деле, но вот такое попадалось на глаза:Цитата:
Сообщение от Smalovsky
http://www.nedopc.org/forum/viewtopic.php?f=35&t=5268
предпоследний пост. Минус - надо хранить 8 фаз движения.
я не знаю, какие процедуры и у кого считаются "популярными"Цитата:
Сообщение от Smalovsky
методы оптимизации скорости от размера спрайтов зависят сильно
смотреть стоит в сторону современных наших игр динамических
Lethargeek, мне нужны типовые процедуры, часто встречаемые в играх.
Глянь, это похоже на них?
https://abzac.retropc.ru/content?id=145
https://abzac.retropc.ru/content?id=146
https://abzac.retropc.ru/content?id=147
Smalovsky, не похоже, явная оптимизация по размеру, а не по скорости, таблицы не применяются, даже циклы не развёрнутые
Возник такой вопрос - а использование троичной адресации как на ЭВМ Сетунь решило бы вопрос клешинга более простым путем ?
Нравятся мне этот тред. Что только нового не узнаешь. Не пойму правда как троичная ферритодиодная ячейка поможет "непобедимой" проблеме клешинга?Цитата:
Сообщение от ^m00h^
Может ещё квантовый компьютер на это подписать :) ?
логики, а не "адресации"Цитата:
Сообщение от ^m00h^
запросто, вот смотри, на спеке пиксельная логика двоичная - инк либо паперЦитата:
Сообщение от coffee
чтобы не было клэшинга, нужна как минимум троичная - инк, папер, другой цвет
на двоичной имитировать неудобно
:v2_dizzy_botan:
"маловато будет! (С) . У меня на знакоместо 5 байт. Давайте 5-битную логику :)Цитата:
Сообщение от Lethargeek
P.S. через неделю и несколько часов будет довольно круглый юбилей темы - 5 лет. Предлагаю ТС, команде ULAX, Raydac и всем желающим изложить свои мысли по антиклешингу (под звон бокалов). Любые мысли (не обязательно исходники своих творений :)). Мне недавно ТС выслал для рецензии свою концепцию (чей юбилей мы и будем праздновать). Я ее в основном сформулировал(рецензию), подготовлю и выложу глубокой ночью ровно 20.07.2021 02:52 мск (5 лет спустя от начала треда), а заодно и свое видение реализации сабжа на эмулях и FPGA. Чтобы была интрига, пост выложу на 1 минуту, а потом "отредактирую", сведу самое интересное в нем до нуля, т.е. сотру (надеюсь это не нарушает правила форума?). Это шутка (а может и нет :v2_dizzy_roll:)
2 TC: разумеется я сдержу слово, никаких конкретных деталей там не будет, просто мое скромное мнение о сабже.
P.P.S. по моему тема очень интересная (я имею в виду антиклешинг и улучшение ZX игр). Определенная таинственная аура треда (чем славен уже 5 лет наш ТС) пожалуй даже полезна. Нарисовать в VHDL очередной клон ZX сейчас может и студент для курсовой. А вот подумать как победить АК в классических старых играх - это хорошая разминка для ума. Не надо бросать это дело.
если честно, интригу уже перетянули и не удивлюсь если у большинства, как и у меня, появилась уверенность что за ней пустота, так что всё надо вовремя делатьЦитата:
Сообщение от coffee
это пока неизвестность. А вдруг там прорыв? :v2_dizzy_indy:Цитата:
Сообщение от Raydac
Но твоя то работа точно хороша и реальна. Почему бы и не высказать свои мысли по теме к юбилею?
если бы был прорыв то уже было бы про это рассказано и показано, но судя по текстам и поиску инфы по процедурам выводящим спрайты, прорыва не видно, решение у этой задачи постоянно упирается в одно и тоже - где брать вычислительную мощность чтобы сохранить соотношение производительности системы к увеличившемуся размеру видеопамяти и тут или решение а-ля Spec256 и ZX-Poly или навороченный интеллектуальный девайс который за счет камня мощностью в сотню спектрумов будет на лету что то делать и подменять или требовать чтобы "немного подкорректировали код", но корректировать код никто имхо не будетЦитата:
Сообщение от coffee
p.s.
у ZX-Poly юбилей будет в конце апреля-начале мая 2024го получается, 30 лет
It's coming soon!
Доброй ночи, друзья. Теме 5 лет, может подведем какие-то промежуточные итоги и пойдем дальше? Почему ночью и зачем этот антураж? ТС заразил тягой к тайнам, "последуем за белым кроликом"? :)
Часть 1.
Итак, как обещал попытаюсь написать по возможности объективную рецензию на многолетний труд нашего ТС. Приготовьтесь, букв будет много. Сразу оговорюсь что я получил от него не весь материал, а только один раздел и то не полный (как написал мне ТС). Остальное попытаюсь домыслить. Моя задача осложняется тем что я связан обещанием хранить в секрете подробности его концепции, хотя честно говоря (спойлер!) я там никаких интересных подробностей не нашел. На всякий придется умолчать почти обо всем, а вам просто доверится моему мнению (имея в виду что другие разрабы, кто так же ознакомлен с данным трудом не дадут мне соврать).
- 1. Начну с того чего нет в материале. Там нет вообще ничего о "железе" видеоконтроллера. Как говорят, от слова совсем. На мой вопрос автор ответил, что это в другом, еще не написанном разделе. Но то что я собрал по отрывочным сведениям, не внушает особой надежды что у самого автора есть какое то готовое решение. Судите сами...
На первой же странице этого треда мы читаем:
Цитата:
Особенности
Цитата:
- Может использоваться в модели 48k(*);
А в преамбуле присланной мне работы говорится оЦитата:
2.4 Простейший вариант Swap можно использовать в клонах. В фирменных машинах, думаю, тоже можно использовать. Вопрос в том, что в фирменнлй машине нельзя будет использовать палитру.
Т.е. автор дает понять, что он собирается использовать свой новый видеорежим на стандартном ZX-Spectrum и его клонах (возможно после какой-то доработки?). Кроме того, в работе есть момент с упоминанием Ulaplus:Цитата:
возможности расширения графических характеристик бытового компьютера ZX-Spectrum
Таким образом я делаю вывод, что автор считает, что видеорежим может быть реализован на системах, построенных на базе Ulaplus. Мое мнение - это фантастика. Все очевидно, незачем объяснять почему, просто цитирую что пишут сами создатели ULAPlus:Цитата:
Совместная работа с Ulaplus ещё больше расширяет возможности видеорежима... на экране могут присутствовать одновременно 64 цвета из палитры в 256 цветов
"- Does it remove attribute clash?
- No."
Для реализации антиклешинга на стандартном ZX-Spectrum и его клонах придется заменить практически все, даже память динамическая не подойдет, надо менять на статику.
Не хочу обижать, но автор явно не силен в разработке "железа" (читая тред это ясно), а оно для решения задач антиклешинга требуется серьезное, намного сложнее самого спектрума. Отсюда мой вывод по первой части: аппаратная компонента проекта скорее всего на нуле и без сторонней помощи вряд ли когда будет реализована. Но может он все соберет на эмуляторе? Продолжим...
- 2. Программная часть. Первая мысль, когда прочитал о принципе формирования изображения, посмотрел картинки: вроде неплохо, но что-то все слишком просто и дополнительной памяти мало требуется, что-то не так. Но отвлекшись на мелочи - автор очень подробно и внешне убедительно пишет про выбор цвета для фона, спрайта, все эти операции And, Or, Xor и честно сказать я не сразу понял главное - метод ТС "не взлетит" совсем. Здесь полная катастрофа... Он работает только когда спрайт находится в границах знакомест 8х8 как по горизонтали, так и по вертикали. Любое смещение на 1-7 пикселей в любом направлении вызовет цветовые артефакты, т.е. часть объекта будет окрашена цветами фона и наоборот часть фона - цветами объекта. Визуально тот же клешинг, но в виде окантовки объекта будет на экране. Если бы автор потрудился разобрать листинг отрисовки спрайтов хоть в одной игре, то ему давно бы стало ясно, что не работает его метода. Но он явно не вникал в подобные мелочи, просто нарисовал свои красивые картинки и убедил себя, что все ОК.
Я могу еще много писать, что совсем не проработана версия с теневым экраном (потребуется 2 комплекта буферов), что для многих игр переписать код отрисовки спрайта будет очень затруднительно в виду того что все регистры и стек участвуют в работе и делать что-то дополнительно на слое маске и слое цветов.атрибутов просто не на чем - ресурсы проца заняты. Про то что просядет производительность автор сам понял. Про то что придется переписать не одну процедуру отрисовки спрайта, а все последующие процедуры, затрагивающие картинку в экране или в теневом буфере - будет для него сюрприз. Много что еще можно написать, но зачем добивать и так неживой проект?
Но если вы меня спросите - есть ли хоть что-то полезное/верное в подходе автора к проблеме? Ответ - да. Он додумался (как в прочем и другие до и после него) до слоя маски. Без нее антиклешинг не пойдет. Но от верной мысли в правильном направлении до конечной реализации в железе или в эмуляторе - дистанция огромного размера. Там как говорится дьявол в деталях...Я первую версию антиклешинга (где Валли "парил" над игрой) сделал всего за неделю, над второй бился наверно пару месяцев (правда попутно решая и др.задачи). А у автора ведь по сути нет ничего, кроме идеи слоя маски и ложной идеи атрибутов цвета спрайта. Он за 5 лет прошел всего один шаг. Raydac на самом деле прав:
Может еще через 5-10 лет…Цитата:
Сообщение от Raydac
- 3. хоть у нас и не чемпионат мира по фигурному катанию, но рискну поставить ТС оценку за артистизм: 6.0.
Почему? Треду 5 лет, он в топе с 850+ т. просмотров. Какой интерес и популярность! В какой-то степени он способствовал запуску успешного проекта ULAX (ребята в этом же треде начали раскручиваться). Ну и что, что он сам не имел в запасе ничего стоящего? Сколько людей заинтересовал интересной идеей. Да, автор не силен ни в проектировании железа, ни в программировании как на Z80 так видимо и на PC (иначе почему бы протестировать идею на эмуляторах?). Но интерес к теме он угадал и умело развил его. Надеюсь и дальше тред не затухнет. Есть над чем работать.
Часть 2 (с проектом ТС никак не связанная, это видение АК, основанное на моем скромном опыте).
Возможно я многих расстроил в связи с фиаско проекта ТС, они может ждали, когда он выйдет в паблик. А вдруг старый спектрум заиграет по-новому? Не судьба. В качестве некоторой компенсации "помогу" интересующимся и обрисую возможный алгоритм реализации антиклешинга на FPGA/эмуляторе на примере игры Three Weeks In Paradise. Сразу оговорюсь что сам я сделал не так, ибо мне надо было уместиться в намного более скромных ресурсах: оригинальный Z80 и CPLD (на порядок слабее чем FPGA, к тому же без встроенной памяти). Но тем не менее алгоритм вполне рабочий. Но само собой потребует серьезной работы для реализации. Итак, поехали… Упомянутая игра использует теневой однобитовый буфер на 4kB, содержащий 2/3 экрана – (панель инструментов не копируется), находящийся прямо за атрибутами по адресу 0x5B00, см. картинку в аттаче. По ходу игры, подпрограммы визуализации персонажей и объектов отрабатывают одна за другой, создавая нужную картинку в этом буфере. К слову сказать, он линейный и при копировании в основной экран спектрума выполняется перестановка строк. Как я уже сказал, буфер однобитовый и на нем отрисован задний фон и по очереди накладываются объекты. За цвет отвечает стандартная зона атрибутов. Отсюда собственно весь клешинг и проистекает. Мы хотим, чтобы Валли был красивым, многоцветным или хотя бы желто/черным, но не смешивался с фоном, но цвета задает слой атрибутов и Валли делается "хамелеоном" или "маляром". В качестве решения можно добавить однобитовый слой маски, на котором фиксируется персонаж - его абрис и слой/слои цвета персонажа (минимум один для желто/черного Валли, несколько для многоцвета). Допустим мы позволяем игре визуализировать все объекты как раньше, но дополнительно размещаем Валли на слое маски и на специальных цветовых слое/слоях. Как это сделать пока умолчим. Что делает теперь видеоконтроллер при сканировании? Во-первых, на каждом знакоместе он как всегда считывает байт пикселей и байт атрибутов. Во-вторых, дополнительно считывает байт маски. Допустим наличие фрагмента тела Валли в знакоместе представлено в виде 1, а его отсутствие 0. Тогда при нулях, мы ничего больше не считываем, а отображаем только пикселы и атрибуты как в обычном режиме спектрума. Но при наличии хотя бы одной 1 в байте маски, мы считываем дополнительно байты с цветовых слоев Валли. Логику коммутации и сборки выходного потока на ЦАП я описывать не буду, она очевидна для тех кто делал свой клон и вообще для специалистов. Таким образом на одно знакоместо мы имеем до 4 (или больше, если спрайт многоцветный) байт на считывание, плюс надо конечно обслуживать процессор (у меня он в приоритете ибо даже на 14 МГц должен работать с 0 W.S.). Таким образом стандартная динамическая память не успеет обслужить запросы. В случае с дабл-сканом (VGA, HDMI) темп выдачи данных еще в 2 раза быстрее (14 вместо 7 МГц). Короче желательна статическая память с циклом не хуже 70нс. Но если у вас экранная память сидит внутри FPGA, то вы вообще в шоколаде, там и скорость хороша, и разрядность любая, да и вообще все можно разделить на разные блоки и работать параллельно. Да, кстати этих экранов нужно пару комплектов - пока заполняется данными один, на отображение работает второй. Переключение производится в момент копирования теневого экрана в нормальный.
С видеоконтроллером вроде разобрались. Теперь перейдем к заполнению слоев нужными данными. Это довольно сложный и трудоемкий процесс, который можно осуществлять разными способами. Начиная с чисто софтовых (силами Z80), до продвинутых, с аппаратной поддержкой, когда аппаратные и/или программные ресурсы FPGA сами запускают дополнительные операции с памятью, внося куда надо нужные данные. Не буду расжевывать смысл этого, кто готов к подобному, тот сам догадается. А что нужно вносить, рассмотрим на примере слоя маски. Процедура отрисовки Валли (адреса 0xE269-0xE34D - листинг дизасма можно вытащить из SNA-файла игры) на первом этапе работает с фоном и маской. Три байта маски загружаются в регистры Z80 и циклически сдвигаются на 0-7 бита (сдвиг задается младшими 3 битами X-координаты, что по адресу 0xF6B4). В итоге они занимают уже 4 байта. В оригинальной процедуре они делают побайтовую операцию AND с фоном (фон предварительно сохраняется для последующего восстановления). Вот перед этим моментом надо успеть сохранить сдвинутую маску в нашем слое маски. Чем хороши эмулятор и FPGA со встроенным "Z80" - так это тем, что все регистры доступны и срисовать их куда надо много легче чем из живого Z80, можно сделать даже не ломая оригинальную процедуру. Далее процедура отрисовки спрайта аналогичным образом загружает и сдвигает пиксели спрайта. Здесь дело попроще, можно просто перенастроить вывод с теневого экрана на свой. Если у вас Валли многоцветный, то работки будет побольше. Надо иметь в виду, что блок спрайтов с Валли (начинается на 0xE71C и далее 18 картинок/фаз движения по 192 байта каждая, 24х32 пикселя, формат: сначала 3 байта маски, потом 3байта пикселей) подвергается операции зеркалирования (процедура по адресу 0xE0FE), когда Валли меняет направление движения. Если Валли у вас монохромный, то вам это безразлично - игра сама зеркалит маски и пиксели всех спрайтов. Но если Валли у вас мноцветный, то опять придется подумать, как все это реализовать.
Но это еще не конец. Надо перебрать все процедуры после отрисовки Валли до момента копирования теневого экрана в основной. И отследить кто может "испортить" нашего Валли. А это всякие столбы, трава по пояс, которые ближе к нам и должны перекрывать Валли. Т.е. мы должны отслеживать их отрисовку и в случае совпадения положения экране - корректировать слой маски - обнулять байты в этом месте. Тогда видеоконтроллер покажет в этом месте фон, где действительно нарисованы трава или столб. Эти объекты хороши тем что они расположены строго по знакоместам и можно не заморачиваясь просто обнулять целый байт маски. Но еще есть мелкие предметы (всякие котелки, тапки и проч.), которые отрисовываются как спрайты со своей маской, а они любой формы и к примеру в дырочку под ручкой котелка должен просвечивать Валли. А это значит нужна более сложная операция при отрисовке: сначала считываем данные слоя маски, потом обнуляем те биты что закрываются котелком (перемножаем маски) и пишем байт назад в слой маски.
Звучит это все громоздко и сложно для неподготовленного человека, но общем довольно стандартно. Ребята из ULAX даже поставили обесклешку на поток. Думаю, что у них реализация отличается от вышеприведенной (да и у меня она отличается).
P.S. Наверняка некоторые напишут, ну и что нового ты тут написал, все это известно, смотри тот тред или этот. Отвечу в шутку: я кроме данного треда (да и то не полностью) ничего не читал (иногда читать выходит дольше чем сделать самому). А всерьез: мой метод работает, а ваш? Знаю, что работает ULAX и ZX-Poly. Остальным критикам предложу сначала сделать самим и показать, как работает.
P.P.S. Стирать в сообщении ничего не буду. Ничего секретного я не написал, но если это кому-то поможет войти в тему, то задача будет выполнена.
Да уж, теме пять лет, а результата ноль. Изложу свое видение ситуации, у меня оно слегка иное.
Сперва конкретный ответ: на исходном Спектруме никогда не будет антиклешинга, это заложено аппаратно. Чтобы его убрать, нужен паяльник (изменения схемы).
Неа. Есть варианты даже со слабой динамикой типа РУ5-РУ7, самый очевидный - нарастить битность. То бишь память идет бутербродом, как делали в наших клонах 128-го,Цитата:
Сообщение от coffee
только читается (видеоданные) одновременно, а не попеременно. Два байта - уже хорошо, если очень извратиться, можно хоть четыре слоя поставить.
Только практического смысла в этом мало, проще реально использовать статику с хорошим быстродействием. Там времянки до 20нс и ниже есть. Либо "бутер" из двух статик.
Таким макаром можно до 16млн цветов дойти, только смысл от них на нашем слабом Z80...
Насколько понял, предлагался кастрированный вариант антиклешинга. То есть он как бы остается, просто впечатывается спрайт по маске.Цитата:
Сообщение от coffee
Соответственно, убирается клешинг на стыке спрайта и фона, но не на самом фоне/спрайте. Вариант, но лишь половинчатый.
Насчет реализации маски можно поступить куда проще, но я свое время, размышляя над улучшением графики Спектрума, хотел сделать иначе.
Тут пущусь в легкий флуд, но для понимания нюансов идеи необходимо описать мой вариант графического режима.
В изначальном варианте я подумывал сделать двухрядное чтение видеопамяти, что уже дает разом 2 байта на такт.
Попутно принимаем турбо-режим как стандарт для расширенной графики, причем разогнаны и проц, и память. Это уже вчетверо больший объем чтения, чем сейчас.
Стандартный Спектрум читает видео через такт, байт данных + байт атрибутов. На восемь точек получается 2 байта, или 2 бита на один пиксель.
Подходим к самому важному: можно отойти, наконец, от схемы "пиксели отдельно, атрибуты отдельно" и кодировать каждый пиксель своим набором бит.
Соответственно, стандартный комп может выдавать до 4х цветов на пиксель с минимальными переделками схемы, но цвета будут жестко заданы, это стандартные RGB+черный.
Именно такой видеорежим реализован, например, в БК-0010. Там же не просто от балды решили сделать только 4 цвета, да еще синий+зеленый+красный.
Все исходило из возможностей железа, тех самых двух бит на пиксель (развертка БК в целом совпадает со Спектрумовской, частоты чтения видеопамяти те же).
Если же мы наращиваем битность (2 ряда микрух) - уже имеем 4 бита на пиксел, 16 цветов. Турбо-вариант памяти - 8 бит, 256 цветов. Каждый пиксел 256 цветов, Карл.
Однако тут возникает другая проблема. Путем несложной математики получаем размер экрана 256х192=48 килобайт на экран (при 256/пиксел) либо 24 к (16/пиксел).
Для немощного Z80 это слишком накладно, извращения со страницами памяти тут помогут лишь частично. В БК ровно та же проблема: экран размером 32 килобайта,
потому что там разрешение 256х256 при 4х цветах на точку. Для слабых процов и, что тоже важно, 16-битной шины адреса это приговор.
Да, можно разбить даже экран в 48 кило по страницам. Выходит вполне удобно, по 16 кило, или треть экрана в страницу. Но усложняется работа с графикой на стыке третей.
Впрочем, для несложных графических построений такое решение бы вполне устроило. Для выплюнуть картинку и любоваться ею - вообще отличный вариант.
Теперь вернемся к маскам. Если кодировать каждый пиксел своим цветом, резко вырастет потребление памяти как экраном, так и спрайтами, в разы вырастет.
Но речь сейчас именно о реализации маски и, по возможности, быстрой реализации. Ну, быстрого вывода с маской. Тут можно сделать довольно просто.
Под маску выделяется отдельный цвет из возможного набора (16/256 в нашем случае, да хоть 16 млн, не суть важно). То есть, теряя один цвет, мы получаем маску.
Как это реализовать железно? Довольно просто, применяя логику XOR. Даже на рассыпухе получится не очень громоздко, буквально три-четыре корпуса.
При таком способе не нужно отдельно хранить маску, она уже содержится в спрайте, как некий аналог альфа-канала в текстурах "нормальных" компьютеров.
Главное же преимущество такого подхода - процедуре вывода не нужно париться с маской. Она просто кидает данные, а железо отсекает их по маске.
То есть мы просто выводим спрайт, как массив данных, путем пересылки. Байты маски игнорируются и не записываются в память.
Но все это лишь вольные хотелки на заданную тему. Реализовывать их некому. Даже если сделать рабочий экземпляр "чисто для себя", дальше эмуляторов он не пойдет.
А эмуляторы, извините за сравнение, это как резиновая женщина. Когда хочешь, сколько хочешь и что хочешь, но с живой так не получится.
Поэтому ответ на главный вопрос дан совершенно правильно:
Цитата:
Сообщение от coffee
у ZX-Poly со Spec256 разница всеж, у последнего идет обычная программа и в параллель 8 виртуальных процессоров на каждом шаге выполняют программу со своей памятью и версией проги и выводится именно их результат компонуясь в индекс 256цветной палитры, но после шага все они синхронизируются по процу который выполняет обычный неизмененный SNA файл, при таком можно безболезненно даже залезть и покрасить исполняемый код, но на реале работать не будет никогда, а у ZX-Poly 4 проца не связанных между собой и там надо быть сильно аккуратнее в раскраске,но из всех раскрасок у единственного вроде как есть в довесок к раскраске режим без раскраски но позволяющий просто изменением фонта сделать 512 на 384 в утилитахЦитата:
Сообщение от weiv
https://raw.githubusercontent.com/ra...word_mode5.gif
на исходном Спектруме никогда не будет дисковода, это заложено аппаратно. Чтобы его убрать, нужен паяльник (изменения схемы)Цитата:
Сообщение от reddie
хотя, погодите-ка...
https://www.jungsi.de/blog/wp-conten.../Beta-Disk.jpg
;)
Если это был намек на то, что новые режимы могут быть присобачены через ZX_Bus - почему бы и нет.
Но родным Спектрумовским железом это уже не будет. Давайте сразу тогда GTX 1060 присобачим. Ненуачо.
Beta Disk шел отдельно, в наших клонах он врос в плату. Возможно, это минус и привязка к TR-DOS. Но назад пути уже нет.
Если через ZX_Bus такое и будет, то видеовыход будет именно с нее, потому как в видеоконтроллер через это расширение ну никак не влезть. А коли так, то туда можно и RPI всондалить, с HDMI выходом, и OpenGL графикой (аля универсальный VDAC3). Клешинг останется на старом видеоконтроллере.
так и бетадиск не "родное", раз не от СинклераЦитата:
Сообщение от reddie
- - - Добавлено - - -
как и кемпстон, который тоже у многих "врос"
Началось... OpenGL, HDMI, прочие навороты. Напоминает идеи, витавшие тут на форуме, реализации каких-то доработок (уже не помню, о чем шла речь) на внешнем контроллере STM32 или типа того. Вам самим-то не смешно? Лепить устройство для компа с процессором в десятки-сотни слабее этого устройства. Давайте тогда сразу перейдем на Ардуино и ассемблер его процессора, в чем проблемы-то? Я скажу, в чем. Мы закостенелые ретрограды, не желающие учиться новому. Мы лучше посидим, покодим под Z80, а недостающие фичи, так и быть, реализуем более мощным железом. Вот только смысл такого подхода? Древний проц, являющийся самым слабым местом, будет тянуть всю систему на дно.
В моем видении, все дополнительные фичи могут считаться родными, если реализованы на элементной базе соответствующей эпохи. Применительно к Спектруму - никаких FPGA и STM, только православная рассыпуха, только хардкор. А то получаются у нас присобаченные через задницу контроллеры HDD, СF, МР3-плееры и все остальное. Вот только Z80 им уже не нужен, он остался как шильдик, что это типа Спектрум, а не что-то более крутое.
один будет, а несколько не будутЦитата:
Сообщение от reddie