Скрестить ZX и ПЦ
Обращаюсь к вам как опытный скрещиватель ZX и ПЦ с многолетним стажем. ;-) ZX-асм, ПЦ-асм - это всё очень мило. Даже соглашусь, что это бриллиант. Но этого недостаточно. Любому бриллианту приличествует изящная оправа. И вы согласитесь, что способ упаковать эффективные кодовые процедуры в структурно-модульную (или ООП) оправу - это хорошее дело, главное чтобы эффективность была на высоте.
Преимуществ у привнесения структурного уровеня (а ведь он всё равно будет, хотя бы даже записанный в тетрадке), наглядно показывающего алгоритм, - более чем достаточно. Особенно хорошо если это будет синтаксически проверяемый и компилируемый код, а не записки на манжетах. Т.е. грубая схема:
Третья строка - это наш выход на современные реалии бытия. Тут была масса претензий к качеству кода, выдаваемому SDCC. Но, господа, SDCC вовсе не отбирает у вас хлеб лоулевел кодера. Он только подставляет плечо. А кодировать вручную вы можете и в ZXDev. Та даже код на ЯВУ даёт очень много лазеек для его ручной оптимизации. Помните REPEAT UNTIL? Это всего лишь соптимизированный FOR. До оптимизации этот код занимал у меня 560 байт. После оптимизации - 500 (львиная доля из них - быстрая процедура рисования окружности), и это не предел. Я уверен, что если вывести переменную radius из процедуры на уровень модуля, она перестанет быть локальной, и код уже будет другой, и пооптимальнее. Да, наглядности это коду не добавит, но для оптимизации такое сделать можно. Можно скрестить все эти PAPER, INK, BRIGHT и FLASH в одну процедуру COLOR. И так далее.Код:если асм_zx, то ld a,b
если асм_pc, то mov al,bl
если яву, то a := b
Структурно-модульный уровень - логика кода на ЯВУ + библиотеки на асме (или на ЯВУ - там, где это уместно). Я скажу очень важную вещь, сосредоточьтесь. Как, по-вашему, что нужно сделать чтобы этот код заработал на другой платформе?
Всё просто. Есть два способа. Первый: переписать код под API (программные интерфейсы) другой платформы (а обычно - и на другой язык). Второй: эмулировать операторы ZX-Basic и Laser Basic на этой платформе, со структурой экрана и памяти (чтобы POKE работал). Какой способ вам нравится больше? Мне - ни один из них в чистом виде. Нет. Здесь нужна декомпозиция. Нужно проделать очень серьёзную работу по пересмотру абстракций, положенных в основу алгоритмов. Чем заменить PAPER и INK? Завести коды цветов как у экрана Спектрума или как-то иначе сделать? Это трудная работа, но если выйти на новый уровень абстракций, спроектировать новый интерфейс логики работы с экраном, клавиатурой, звуком, то мы получим уже нечто третье, а не два вышеперечисленных способа в чистом виде. Попробуем усложнить задачу ещё круче. Пусть выработанные нами интерфейсы будут реализованы в едином стиле для разных платформ, для начала пускай хотя бы для двух. Чувствуете какая здесь кроется мощь?
Ещё язык программирования. Неплохо конечно использовать привычный язык, но он вряд ли будет одинаково хорош для Android и для ZX. Проект XDev ставит перед собой ещё более серьёзную задачу: пусть у нас будет средство, позволяющее развернуть нашу игру и на ZX - она будет выглядеть поскромнее; и на Android - хотя бы и управление отличается, сенсор вместо клавы с джойстиком. Но логика работы над вашим проектом остаётся, открытая, доступная для дальнейшей модификации. С долей презрения к не появившимся ещё гаджетам и платформам. ;-)
Вы видели декомпилированный Exolon? Его нужно переписать в этом же духе, иначе через несколько лет у кого-то снова может появиться очень интересная головоломка "узнать как это устроено?". Я не хочу ломать кайф кому-то, но сколько же можно топтаться на одном месте. Видите как резво сменяются парки платформ? Или вы глубоко в эмуле ZX/любимой IDE C# и вам на всё пофиг? ;) Но мне-то нет. И моим единомышленникам.
Проблемы "скрещивания" кроются в том, что не всегда правильно расставляются акценты при разработке. Берутся не всегда адекватные абстракции. Игнорируется модульность. Вот, например, я бы поставил высокий удельный вес понятию спрайт (картинка на экране), при этом цветность, выравнивание по сеточке из атрибутов - уже понятия меньшего удельного веса. Язык - ещё меньше веса. Платформа - ещё меньше веса. Тогда получится программа, выводящая спрайт. А во что она превратится после нажатия на Compile - это уже второстепенно. У нас же сейчас всё иначе. Главные скрипки и трубы - платформы, процессоры и языки. А наши скромные приложения - они имеют насколько ничтожный вес, что быстро устаревают и становятся никому не нужными. У нас всё с ног на голову. Вместо того чтобы всем миром прийти к единой нотации - каждый городит свой идеальный язык. Вместо стандартизации единого апи (пусть даже этот апи будет разной мощности; и как матрёшка, совместимый сверху-вниз - для разворачивания на платформах разной мощности) - опять чёртова куча платформ, и не видно этому конца-краю. Кто-то с этим мирится и делает ZXTune для десятка платформ. Ну что ж, очень круто, молодец. А что остальным делать? ;-) У кого барьеры овладения технологий. Кто, начав с ZX-Basic, пошёл по пути QuickBasic, потом PureBasic, потом VisualBasic, потом BlitzBasic/Monkey-X. И невдомёк ему, что его мучают демоны названия языка. Это не бейсик, это много бейсиков. ;-) А В XDev язык построен по принципу матрёшек апи, как я сказал выше, чтобы разворачивать его на платформах различной мощности. Но это единый язык или в лучшем случае очень близкие диалекты, но не целый парк языков, похожих друг на друга разве что общим названем. Об этом можно долго говорить.
Примерами кода подкреплю позже, если не возражаете.