Вот тут-то вы и не правы. А что, если графика типа Micronaut One? Как, по-вашему, там изображают хотя бы купол Jelly Fly?Цитата:
Сообщение от Kirill Frolov (500:812/1.507)
Вид для печати
Вот тут-то вы и не правы. А что, если графика типа Micronaut One? Как, по-вашему, там изображают хотя бы купол Jelly Fly?Цитата:
Сообщение от Kirill Frolov (500:812/1.507)
Ты еще Gyron вспомни
не надо путать заливку замкнутого контура и рисование закрашенных примитивов
а что, это табу такое - Gyron? Или всё таки игра с оригинальной и быстрой графикой.Цитата:
Сообщение от jerri
3Д весьма концептуальноеЦитата:
Сообщение от TomCaT
Извините, я пошутил неудачно. Конечно же, я знаю и видел эту игру. Мне просто показалось, что Вы считаете Gyron плохим примером. :) Больше, надеюсь, не повторится.Цитата:
Сообщение от jerri
я не собираюсь путать. Я привоже пример. Хорошая процедура заливки и в игре м/б пригодится. Пусть это хоть текстовая адвенчура - большая часть времени там как раз на заливку уходила. А ещё на дуги и окружности, но это в плохих квестах и с использованием ПЗУ (Urban Upstart)Цитата:
Сообщение от jerri
Кстати, родилась бешеная идея оптимизации процедуры заливки. Если все получится, то заливать будет не точками -- байтами, но при этом без ошибок, именно замкнутый контур. Из за неперерасчета координат и практически восьмикратного увеличения темпов должно получиться весело!
А потом надо бы ее встроить в Asterix & Obelix, а то игра красивая (хоть и простенькая сюжетно), но заливка там достает неимоверно!
Заливка нужна узором или нет?
Если первое - то сложнее. Обычно делается сначала заливка без узора, а потом по вычисленной маске заполняется узором. Тогда память будет отжираться помимо рекурсивных нужд алгоритма еще и на хранение маски.
А вообще да, байтами можно. Как раз как-то давно я делал именно алгоритм, который заливал байтами, соотв. смещение по x - это инкремент/декремент, а по y понятно, что сложнее, но не на много.
Увы, исходников не осталось, но кое-какие воспоминания есть... может попробую восстановить.
Да с узором потом уж как-то разбираться... Пока ускорить бы Solid Fill.
Я уже половину написал, все должно работать (как всегда, ДОЛЖНО, но... :). Но если исходников нет, может, есть какие идеи по оптимизации?.. Я, к сожалению, пока распланировал неплохо, даже стек -- только для сохранения ответвлений, никаких лишних операций с памятью, но -- жрет альтернативные. Случайно нет таких команд: EX DE,IX / EX DE,IY? Поиск в инете говорит, что вроде нет :( :/.
В частности, нужно быстро переходить из адреса видеобуфера на соседнюю строку вверх и вниз. Можно использовать аккумулятор и одну какую то пару, DE например. Я пока догадался только, что если неприятные переходы и преобразования адреса ждут сверху, то внизу их точно нет, и vice versa... Еще можно сделать табличку из 192 адресов левого края строк, а один 8-битный рег использовать для хранения номера строки, изменяя параллельно с адресом и рассчитывая заново после снятия адреса со стека.
__________________________________________
Еще вот похожие на рабочие варианты: так как всегда заняты A, HL для операций с очередным байтом и BC, для хранения и отсчета текущего бита, A' -- разные флаги, то IY мог бы хранить старый стек (с IY на его вершине -- используется только в начале и конце работы), а IX и DE -- два адресов соседних строк. Но уже тут проблемы с хранением маски. Так что, если нет команды обмена последних, стоит отказаться от одного адреса (он и так легко получается INC/DEC HL), введя одним флагом признак "стороны" той строки, что сейчас в DE. А еще в E хранить маску, а в D -- биты старшие 4-0, младшие 7-5 адреса соседней строки, по которым из HL также недолго (AND, OR, пара AND A, SCF, 6 сдвигов A и 3 -- другого регистра) получить адрес второй строки-соседки. Старый стек тогда в IX. Итого занято 4 пары и оба аккумулятора.
Зачем так сложно? Это же простое текстурирование, сиречь перевод координат X,Y в U,V. Т.е. заливать не волновым алгоритмом (вроде как самый распространёный?), а просто переводить координаты и читать из куска памяти с текстурой цвет точки. Проблема только в умножении.Цитата:
Сообщение от maximk
Ну, поставили мы очередную точку, а перейдя к следующей откуда известно - это незалитая точка или черная точка узора?Цитата:
Сообщение от icebear
А, понял, понял. Ну, перевод координат - задача не для z80, имхо...
Да, заливка с маской была в каком-то редакторе для спека, но я не помню в каком, я его почти не юзал. Так, просто осмотрел.