AWESOME
AMAZZZING
IMPOSSIBLE!!!111
WONDERFUL
IMPRESSIVE!!!!!
HOWWW??????
....
Лимиты на строку можно фликерить, как то делалось на донди неоднократно. Или в контре хард корпс у босса huge robot руки мерцали. Фаерболлы и прочие эффекты стробоскопом по глазам моргать в подобного рода файтингах не зазорно.

На NES мерцание не на железном уровне проходкой по спрайтам? На SMD же по умолчанию просто не показывается спрайт, который создан позже. Ты предлагаешь пересоздавать или менять местами в цикл, чтобы менялся приоритет?

Нет, на нес мерцает именно программно (в системной памяти выделяется таблица в 256 байт, через которую происходит обновление). Без этого преславутого программного мерцания добрая доля противников попросту бы не отображалась на экране. Уж лучше ориентироваться по мерцающим спрайтам, чем играть в слепую (в какой-то части диззи нет мерцания, и там если до кучки вывалишь предметы, особенно рядом с NPC, то часть спрайтов пропадёт из виду).
На смд аналогично можно делать, использовать один и тот же спрайт каждый чётный и нечётный кадр.
Допустим, слева и справа два файерболла летят одновременно, так на чётном кадре выставляем одну позицию спрайта. На нечётном - вторую, и зеркалим/меняем кадр анимации. Зачем пересоздавать? Фреймы желательно кэшировать в VRAM, ну а если места нет, то тут только по DMA, с потоковой анимацией в SGDK последних версий всё ок.
Ну а чтоб приоритет не перекрывался персонажами, достаточно нужный индекс установить, делов-то.

Ну насчёт использования одних и тех же спрайтов, наверное, лишнее... Тем более их 80 шт. Файерболы у разных персонажей разные по параметрам: габариты, палитры, скорость, анимация. Придётся много чего менять в момент. А перемещение больших спрайтов на SMD - чуть ли не самый нагружающий процесс. Уж лучше как на NES тогда делать. А если ещё HUD спрайтам сделан...
Лично я люблю создать все спрайты в начале загрузки и хранить их за пределами видимой области экрана, в нужный момент их перемещая туда и обратно. При процессах создания, уничтожения спрайтов часто можно ошибиться, и будет возникать ошибка лимита спрайтов. Поэтому предпочитаю один раз создать и работать с ними. Особенно, если движок игры с произвольными выходами из цикла, где сложно отследить уже уничтожен спрайт или нет (например выстрелил, пуля летит, ты переходишь в меню, из меню возвращаешься выше или ниже кода создания пули, она создаются снова, а затем ждёт всего одна процедура уничтожения спрайта, и один спрайт уже накапливается), а все разом уничтожать и пересоздавать геморно. Но это вопрос опрятности кодинга.
С индексами тоже не всё так просто... Не знаю как в SGDK, но через ASM это далеко не один параметр. Лично я до сих пор не разобрался как оно работает - меняешь спрайты между собой LinkSprite, и все равно то работает, то нет. Это так, лично я не особо разбираюсь в программировании и платформе... Некогда вычислять адреса, как оно хранится. Возможно, ты где-то доку встречал, где все адреса данных спрайта выписаны и как менять? Поэтому до сих пор не делал проекты с изометрией и видом сверху - на BEX, которым пользуюсь, это не реализовано, а через ASM-вставки не получается реализовать приоритет по Y спрайта, чтобы спрайты персонажей перекрывали друг друга от того, кто за кем стоит.

В случае SGDK ковырять асм не приходится. Все низкоуровневые функции прописаны и сотни раз оптимизированы уже на асме умными людьми, лучше них я точно не сделаю, поэтому не суюсь в асм (это на спектруме до сих пор не сделали такой полноценной СДК, так что там без асма далеко не уедешь, а на сеге SGDK просто песня, почти как SDL или SFML на десктопах). Так что параметры там передаются налегке, и с изометрией всё просто (передаёшь индекс в виде Y позиции делённый на коэффициент), и с крупными анимашками, как с кэшем, так и с DMA переброской всё чётко (смотри прилагающийся в комплекте бенчмарк Donut и с персонажами из Final Fight). Не понимаю, чем тебя так зацепил Bex, в котором и синтаксис допотопный, и поддержки нет никакой, стоковые функции по оптимизации конечно уг на фоне СГДК.