Программирование графики MSX

[ivagor]

fMSX 6.0, которым я пользуюсь, ругнулся и отказался запускать их.

Добавил romы для fMSX (он мне никогда не нравился и тут ответил взаимностью). Вчера проверял "некратные" ромы в BlueMSX, OpenMSX, Mesei - никаких проблем. Автор fMSX довольно своеобразный человек, и это касается не только (и не столько) fMSX.

[Advertiser]

[CityAceE]

ivagor, спасибо, опробую чуть позже!

И сразу походу вопрос: а каким эмулятором предпочтительнее пользоваться? Чтобы и совместимость нормальная была и, самое главное, удобный и функциональный отладчик.

[goodboy]

удобный и функциональный отладчик

я обычно ковыряюсь в BlueMSX, хотя отладчик там не идеальный.
и когда нужно например выдрать музыку делаю в нём SaveAllRAM и переношу блок на спек

[ivagor]

В Emu очень продвинутый отладчик, по моему мнению лучше, чем в BlueMSX (многообразие условных бряков), спасибо b2mу, что добавил msx в свой эмулятор. Но все же msxы не профильные для Emu, поэтому сама эмуляция там не очень точная (скорость, цвет, охват дополнительных устройств). Мне удобнее отлаживать в Emu и потом проверять (и при необходимости доотлаживать) в BlueMSX.

[jerri]

Это к ivagor. Думаю, что он бы относительно легко с ним разделался


Как раз думаю по этому поводу. Но на графическую архитектуру MSX не очень ложится то, как написана эта игра. Слишком много всего придётся переделывать и переписывать.

Напрасно ты так.
Кирпичики тайлами , монстры спрайтами. Пусть будут чернобелыми.

[b2m]

все же msxы не профильные для Emu

Да, есть такое. Я вроде даже эмуляцию видео-чипа недоделал. Просто не нашёл программы, где бы использовалось аппаратное рисование линий, так что этой фичи нет.

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

Червь сомнений всё-же глодал, заглянул в исходники, с линией вроде всё в порядке, а вот чтение пикселя и поиск пикселя не реализован. И ещё какая-то операция с кодовым названием LMCM (Logical move VRAM to CPU).

[ivagor]

b2m поправь хотя бы палитру msx2, в синем канале у тебя 4 градации вместо 8.

[CityAceE]

Возможно кому-то пригодится аналогичная по назначению процедура

Ознакомился с твоим вариантом. Конечный результат одинаковый с моим, но у тебя всё компактнее и быстрее!

Ну, и вопросы. Куда ж без них?

1. В вариантах для двух моделей обработка ч/к картинки идентична. Но для засылки байта в MSX2 используется просто out, а в MSX1 out c последующим nop'ом. Я так понимаю, что это задержка. В Yazzie она тоже используется. У себя я все nop'ы убрал, потому что под эмуляторов всё работает и без них. Так вот вопрос, почему ты в одном варианте nop поставил, а во втором нет?

2. ld de,(-7*256)+1 - что это за ячейка? Что из неё читается и почему такая странная запись?

Кирпичики тайлами , монстры спрайтами. Пусть будут чернобелыми.

Да, это если эту игру проектировать и писать с нуля. А если брать готовые исходники и пытаться их адаптировать к существующей архитектуре, то становится понятно, что это не будет просто. К тому же, даже с кирпичами будет проблема, так как они не вписываются в блоки 8*8, а снаружи еще и обведены линией толщиной в пиксель.

[ivagor]

почему ты в одном варианте nop поставил, а во втором нет?

У видочипов msx1 и msx2 разные тайминги при доступе к VRAM.

ld de,(-7*256)+1

Это просто приращение для коррекции адреса при переходе между знакоместами.

Что касается батти выскажу субъективное мнение, что серьезные технические сложности при адаптации для msx там вряд ли возникли бы. Запас по быстродействию есть. Движущиеся спрайты, насколько помню, копируются на экран из буфера, их можно и во VRAM переслать. Ну а с неподвижными объектами типа кирпичей совсем проблем нет.

[goodboy]

во многих играх перенесённых со спека логика работы такая-же, изменён только вывод из буфера на экран.
я помнится одно интро к игре перенёс с msx на zx (версии с ним не-было) - изменил только печать из буфера.
позже эта игра `всплыла`, так вывод графики в моём варианте оказался даже быстрее.