Новый принцип устранения клешинга

[Reobne]

Ну зачем так сложно-то, ё-моё...

Затем, что минимизируется ПЗК (предварительно загруженная конфигурация). Нужно знать только адреса начала и конца вывода спрайта.
Но возрастает потребная вычислительная мощь карты.

- - - Добавлено - - -

Если-же расчитывать на более слабую карту. С неким навороченым, но ещё не придуманным, ПЗК 8-битных команд.
То и тут предложение blackmirror можно использовать в инструментах кроссплатформенной доработки игры. Я уже писал о мечте об инструменте, который позволит дорабатывать игру не программисту и не хакеру и даже не особо художнику, просто тыкая мышкой в экран.

[Lethargeek]

Затем, что минимизируется ПЗК (предварительно загруженная конфигурация)

вряд ли разница даже в несколько десятков байт (да и то не факт) имеет какое-то значение
а тем более - ценой потери тонкого контроля над отрисовкой на уровне пиксельных операций
важней время на работу по адаптации (и в основном оно уйдёт на трассировку и поиск кода)

Нужно знать только адреса начала и конца вывода спрайта.

вот тут неясно, что считать "началом и концом вывода"
у кода собс-но "вывода" может быть много веток, входов и выходов
если подниматься выше - дольше разбираться в коде придётся
и нагрузка на железо тоже растёт

Но возрастает потребная вычислительная мощь карты.

как минимум до уровня непрактичности (если не до невозможности вообще)
чего стоит одна только операция "сделать две копии памяти в момент начала рисования спрайта"

Если-же расчитывать на более слабую карту. С неким навороченым, но ещё не придуманным, ПЗК 8-битных команд.
То и тут предложение blackmirror можно использовать в инструментах кроссплатформенной доработки игры. Я уже писал о мечте об инструменте, который позволит дорабатывать игру не программисту и не хакеру и даже не особо художнику, просто тыкая мышкой в экран.

это как? если предварительно как раз и потребуется хакерскими способами найти "адреса начала и конца вывода"
в общем же на примере эмулей с раскрасками видно, что "нехакерская" доработка в принципе не всегда возможна
и может времени потребовать больше "хакерской"; а для начинающего хакера есть снапшоты и визуализация памяти
(вот где стоит поработать над большей наглядностью и удобством)

[Titus]

на примере эмулей с раскрасками видно, что "нехакерская" доработка в принципе не всегда возможна

Примеры, когда не возможна - в студию.

[Raydac]

То и тут предложение blackmirror можно использовать в инструментах кроссплатформенной доработки игры. Я уже писал о мечте об инструменте, который позволит дорабатывать игру не программисту и не хакеру и даже не особо художнику, просто тыкая мышкой в экран.

ну дак в zxpoly я так и раскрашивал

[blackmirror]

как минимум до уровня непрактичности (если не до невозможности вообще)
чего стоит одна только операция "сделать две копии памяти в момент начала рисования спрайта"

Не знаю на счёт мелкой логики, а для ПЛИС или программной эмуляции операция вполне реальная, чистить ведь только нужно флаги верхнего уровня, копировать небольшой блок памяти, чистить и устанавливать флаги на следующем уровне потребуется только при записи одним из процессоров. Для эмуляции на x86 очистка 256 флагов потребует всего трёх SSE-команд. При чтении нужно проверить два уровня флагов, чтобы определить можно ли брать данные из памяти клона, еще один флаг чтобы проверить не нужно ли подменить данные на 00 или FF и тремя командами cmov выбрать нужное значение. При записи проверяем флаг верхнего уровня, если не установлен, то ставим и очищаем 256 флагов нижнего уровня, потом проверяем флаг нижнего уровня, если не установлен, значит ставим и копируем ячейку в память клонов(возможно с подменой на 00 и FF), после чего спокойно записываем что собирались.

Но два клона для адаптации конечно слишком мало, если идти по пути ZX-poly, то инструмент для адаптации должен позволять сделать примерно следующее:
1) запускаем автоматическую трассировку, которая для каждой ячейки запомнит адрес команды которая её читала или записывала, после чего смотрим какие команды записывали в видеопамять.
2) смотрим код и находим начало и конец функций записывающих видеопамять, может тут придётся походить по шагам чтобы понять куда мы вернёмся и откуда оно вызывается.
3) просматриваем буфер трассировки и выясняем, какие ячейки читались командами относящимися к нашей функции, из них выкидываем все ячейки с переменными способными повлиять на выполнение функции, оставляем помеченными только массивы в которых могут быть спрайты.
4) создаём пару десятков клонов в зависимости от того, сколько требуется разрядов чтобы можно было адресовать все биты эмулируемого адресного пространства(если у нас 64К, нам достаточно 16+3 клонов, если 1Мб, значит 20+3)
5) в те биты, которые мы пометили как потенциальные спрайты, мы записываем их номера, по одному биту номера в соответствующий бит клона
6) запускаем клоны до конца функции и собираем из видеопамяти номера оказавшихся там бит, то есть ткнув в некоторую точку на экране мы можем определить откуда она здесь взялась
7) если на экран данные рисуются из какого либо буфера, значит по результатам трассировки нужно смотреть где он записывается, потом выяснять откуда, ну а дальше править биты, чтобы понять какие из них попадут на экран

В общем трассировка должна давать возможность для любой области памяти отслеживать откуда она читалась и/или записывалась, для группы или отдельных команд отслеживать откуда они читают и куда пишут. Еще нужно производить над полученными множествами логические операции, добавлять и удалять элементы, а так же создавать клоны и нумеровать биты из некоторого множества, чтобы можно было отслеживать их перемещения. В тот момент, когда мы смогли пометить все ячейки занимаемые спрайтами и пронумеровали их биты, для точки на экране можно определить откуда она взялась и перекрасить её в нужном спрайте.

[Lethargeek]

Не знаю на счёт мелкой логики, а для ПЛИС или программной эмуляции операция вполне реальная, чистить ведь только нужно флаги верхнего уровня, копировать небольшой блок памяти, чистить и устанавливать флаги на следующем уровне потребуется только при записи одним из процессоров. Для эмуляции на x86 очистка 256 флагов потребует всего трёх SSE-команд. При чтении нужно проверить два уровня флагов, чтобы определить можно ли брать данные из памяти клона, еще один флаг чтобы проверить не нужно ли подменить данные на 00 или FF и тремя командами cmov выбрать нужное значение. При записи проверяем флаг верхнего уровня, если не установлен, то ставим и очищаем 256 флагов нижнего уровня, потом проверяем флаг нижнего уровня, если не установлен, значит ставим и копируем ячейку в память клонов(возможно с подменой на 00 и FF), после чего спокойно записываем что собирались.

Второй уровень уже придётся в память писать, это 32 байта разом только для одного клона, а их ведь несколько, а потом при почти каждой записи кроме собс-но записи байта данных нужно соответственный байт флагов второго уровня прочитать-модифицировать-записать, да еще "в ускоренном режиме" (насколько ускоренном?), да еще для кучки клонов одновременно, а ведь всем им мало в плисину поместиться (кстати, сколько полных клонов z80 может влезть в недорогую сегодня?), шину-то одну на всех придётся делить. Нереально, даже эмуляция под вопросом.

И самое главное - зачем весь этот путь боли ради поиска графики в игре (да еще и с точностью до бита), когда уже после второго шага:

1) запускаем автоматическую трассировку, которая для каждой ячейки запомнит адрес команды которая её читала или записывала, после чего смотрим какие команды записывали в видеопамять.
2) смотрим код и находим начало и конец функций записывающих видеопамять, может тут придётся походить по шагам чтобы понять куда мы вернёмся и откуда оно вызывается.

...нам известны адреса отдельных команд, пишущих или читающих байты графики - "переводим" их в расширенную форму для "ПЗК" и в эмуле логируем адреса, с которыми они отработали (если графику потом раскрашивать захотим)

- - - Добавлено - - -

Примеры, когда не возможна - в студию.

Уже были - ксорки, атрибутные перекраски, set/res еще. Не, формально "доработка" возможна - в смысле просто цветов добавить, но результат выходит неполноценным.

[Titus]

Уже были - ксорки, атрибутные перекраски, set/res еще. Не, формально "доработка" возможна - в смысле просто цветов добавить, но результат выходит неполноценным.

Ну, set/res - это только векторные или точечные эффекты.

[Lethargeek]

в целом процедурная графика: генерация кустов-травы, например, или фоновой текстуры чисто из регистров; динамичные эффекты; возможно, grax

[Titus]

в целом процедурная графика: генерация кустов-травы, например, или фоновой текстуры чисто из регистров; динамичные эффекты; возможно, grax

Лучше привести примеры конкретных игр.

[blackmirror]

Lethargeek, для плис можно увеличить количество уровней, а блоки флагов во внешней памяти уменьшить хоть до байта, остальные флаги хранить в блоках памяти внутри плис, скажем на нижнем уровне 8192 блока по 8 флагов, остальное уже в плис - 512 блоков по 16 флагов, далее 32 блока по 16 флагов, а на верхнем уровне регистр в 32 бита. Доступ к памяти без клонирования будет требовать дополнительно(кроме операций внутри плис) только прочитать байт флагов, а запись с клонированием будет требовать RW для флагов и RWW или RWWW(если пишет Z80) для данных, то есть 5 или 6 операций. Цифра на первый взгляд дикая, но столько операций делает только один из клонов, остальные только две, поэтому если поделить на троих, получится в среднем около 3х операций.

Что касается количества клонов Z80 влезающих в плис, то реально требуется один полноценный клон, полноценный в том смысле, что выполняет программу параллельно с Z80, мы всегда знаем что у него в регистрах и можем создавать в нужный момент еще два клона CPU0 и CPU1 которые будут рисовать на фоне из 0 и 1 соответственно. Можно попробовать обойтись и одним клоном, который будет рисовать на инверсном фоне, и считать что к спрайту относятся совпавшие точки, но в этом случае будут сложности с определением спрайтов рисуемых в режиме XOR. Что касается того, насколько быстро должен работать клон, то это требуется только если из-за изменения фона выполнение программы пойдёт другим путём, например после сдвига перенос бита в другой регистр делается не через ADC, а через условный переход и INC, хорошо если к моменту записи на экран клоны тоже успели до этого дойти и мы знаем какие из записанных точек фон, а какие спрайт.

В реальности такой путь боли конечно не нужен, поскольку есть zx-poly и spec256, а эмуляция двух десятков клонов позволит отслеживать точки и раскрашивать для них спрайты прямо на экране. Можно даже попробовать отслеживать точки не изучая код игры:

0) запоминаем начальное состояние нашей системы
1) эмулятор выполняет программу и записывает в лог все выполненные инструкции и обращения к памяти(чтобы потом было проще, можно записывать полный адрес, с учётом всяких страниц)
2) далее начиная с начального состояния, эмулятор запускается в режиме воспроизведения лога, выполняя только операции записи в память, а когда в буфере экрана появится интересная нам картинка воспроизведение останавливаем
3) создаём 32 клона и в каждый бит записываем его номер (кроме тех областей из которых судя по логу выполнялся код) умноженный на некоторую константу, допустим на 419, чтобы нумерация поместилась в 32 бита, но не имела в памяти клонов регулярной структуры
4) в памяти сначала располагаем нулевые байты всех клонов, потом первые, вторые и так далее до конца их адресного пространства
5) запускаем воспроизведение лога, при этом для всех клонов повторяем указанные в логе команды используя SSE регистры, но для команд читающих и записывающих память используем адреса из лога
6) из флагов при воспроизведении можно эмулировать только флаг переноса, поскольку нужен для всяких ADC, а остальное слишком сложно поэтому нафиг
7) когда мы дойдём до интересной нам точки, то для каждого бита извлекаем из памяти клонов его номер умноженный на нашу магическую константу 419 и если полученное число нацело не делится, значит нельзя сказать откуда оно взялось, если число не менялось, значит в этот бит программа еще ничего не записывала, ну а если число изменилось, но делится на 419, значит мы точно знаем откуда оно здесь взялось
8) конечно, при таком упрощённом подходе, спрайт отражённый через таблицу отследить мы не сможем, но с другой стороны где-то он наверно выводился и в нормальном виде и воспроизведя лог до другой точки может получиться раскрасить и его