Портирование Autodesk Animator Pro для кроссплатформенности

предыдущий соответствующий вопрос от меня здесь Обратное проектирование старых программ рисования

Я настроил свою базу операций здесь: http://animatorpro.org вики скоро появится.

Итак, теперь у меня есть унаследованная кодовая база MSDOS на 300 000 строк. Это своего рода ситуация «будь осторожен со своими желаниями». Я не опытный программист на С. Я тоже не совсем неопытен, но во всех смыслах и целях я новичок в языке и, в частности, в тонкостях его библиотек. Я особенно не осведомлен о капризах различий между программами на C, написанными специально для MSDOS, и программами, которые являются кросс-платформенными. Однако я изучаю эту кодовую базу уже более года, и вот что я знаю об Animator Pro:

Используемые компиляторы и инструменты:

  • Компилятор Watcom C
  • tcmake (сделать программу из Turbo C)
  • 386asm, специализированный ассемблер для расширителя доса Phar Lap
  • и, конечно же, сам расширитель дозатора Phar Lap.
  • подборка малоизвестных dos утилит

Кажется, что большая часть компиляции управляется пакетными файлами. Хотя я получил копии всех этих инструментов, мне еще не удалось их скомпилировать. (хотя я скомпилировал его старшего брата, оригинал Autodesk Animator.

У него есть система плагинов, которая реплицирует DLL до того, как DLL стали доступны, на основе REX. Система плагинов обрабатывает:

  • Видеодрайверы (с множеством включенных драйверов VESA)
  • Драйверы ввода (включая планшеты wacom и клавиатуры)
  • Инструменты рисования
  • Чернила (например, фильтры фотошопа или режимы наложения)
  • Scripting Addons (по сути, скомпилированные скрипты)
  • Форматы файлов

У него есть собственный интерпретатор сценариев под названием POCO, основанный на языке C. Язык сценариев обладает достаточной мощностью, чтобы делать практически все, что может делать система плагинов. Только медленнее.

Учитывая эту информацию, это мой план развития. Пожалуйста, раскритикуйте это. Исходный код доступен по ссылке выше, так что вы можете легко, если хотите, самостоятельно оценить ситуацию.

  1. Скомпилируйте его оригинальными инструментами.
  2. Переключитесь на использование DJGPP и внесите необходимые изменения, чтобы он скомпилировался с ним, а также с исходным ассемблером.
  3. Включите библиотеку Allegro.cc «Game» и переключите как можно больше функций на эту библиотеку — возможно, просто написав новые драйверы видео и ввода, которые используют Allegro API. Я думаю об аллегро, а не о SDL, потому что: существует версия Allegro для DOS, и, что удивительно, одна из ее основных функций — возможность воспроизводить родной формат Animator Pro FLIC.
  4. Надеюсь, после 3 я устраню большую часть или весь ассемблер в проекте. Я говорю «надеюсь», потому что это малоизвестный диалект, который не ассемблируется ни в одном современном бесплатном ассемблере без существенной модификации. Я пробовал их все. Все, что осталось, преобразуется в ассемблер в NASM или в код C, если я могу определить реальную функцию ассемблера.
  5. Переключите расширитель DOS с Phar Lap на HX Dos http://www.japheth.de/HX.html, что обещает воспроизвести как можно больше API WIN32. Затем внесите все необходимые изменения в код, чтобы это заработало.
  6. Переключитесь на версию Allegro.cc для win32, предполагая, что версия для win32 может работать поверх HXDos. Внесите необходимые изменения
  7. Измените систему плагинов, чтобы использовать какую-то стандартную кросс-платформенную библиотеку плагинов. Что это будет, я понятия не имею. Может быть, вы можете предложить какие-то предложения? Я разговаривал с разработчиком, который изначально написал систему плагинов, и он сказал, что некоторые вещи, которые она делает, невозможны в современных ОС из-за ограничений сегментации. Я не уверен, что это значит, но я предполагаю, что это означает, что все плагины нужно будет переписать практически с нуля.
  8. Волшебным образом я сделал все вышеперечисленное, и мы можем попробовать запустить его в Windows, OSX и Linux, одновременно занимаясь другими кросс-платформенными мелочами, такими как длинные имена файлов и вещи, о которых я не думал.

У кого-нибудь есть проблемы с этим? Аллегро - хороший выбор? если нет, то почему? что бы вы сделали с этой системой плагинов? Что бы вы сделали иначе? Глупо ли все это, и я должен просто переписать его с нуля, взяв за основу оригинал? (очевидно, первоначальному разработчику потребовалось бы «около месяца», чтобы сделать это)

Одна вещь, которую я не рассмотрел выше, — это система текста/шрифта. Не знаю, что с этим делать, но Animator Pro имеет свой собственный формат шрифта, но также может использовать шрифты Postscript Type 1 и некоторые другие форматы.


c paint dos allegro
person Breton    schedule 06.02.2011    source источник

Ответы (3)


arrow_upward
7
arrow_downward

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

Если бы я занимался переносом, мой подход состоял бы в том, чтобы отключить как можно больше кода, чтобы ЧТО-ТО работало в современной среде, и возвращать части обратно в онлайн, по одной части за раз. Напишите простую тестовую программу, которая загружает драйвер дисплея и рисует некоторые элементы, и скомпилируйте ее для DOS, чтобы убедиться, что вы понимаете интерфейс. Затем напишите код на C, который реализует тот же интерфейс, но с помощью Allegro (или SDL, или SFML), и заставьте эту программу работать под Windows или Linux. Когда вывод отличается, у вас есть простой тестовый пример для работы.

Вся ваша работа с этим портом заключается в замене реализаций различных интерфейсов и функций совершенно новыми. С этой задачей лучше всего справляется модульное тестирование. Не пишите новый код без какого-либо теста, который выполняется на старом коде под DOS! Сделайте свои потенциальные проблемы настолько маленькими и простыми, насколько это возможно. Переносите ассемблерный код вместо того, чтобы переписывать его, только если вы достаточно уверены, что это действительно облегчит вашу работу (например, алгоритмический материал, который прекрасно компилируется с небольшими изменениями в NASM). Не откусывайте кусок больше, чем вы можете сразу уместить в своем мозгу.

Я, например, с нетерпением жду вашего прогресса! Я думаю, то, что вы пытаетесь сделать, прекрасно. Спасибо за это.

person Jeremy Penner    schedule 07.02.2011
comment
Хороший совет. Я тоже думал о таком подходе. Есть некоторое преимущество в том, что процесс сборки фактически создает 3 программы: сама основная чудовищная программа рисования, которая ничего не делает, кроме как читает список FLIC и воспроизводит их последовательно (с некоторыми другими трюками, чтобы сделать ее полезной для Power Point). type tasks), (плеер), который, вероятно, является самым простым и не делает ничего, кроме загрузки изображений в различных форматах и ​​сохранения в различных других форматах. (Обрезать). Моя мысль заключалась в том, чтобы выполнить описанную выше последовательность, но сначала с Player, который познакомит меня с кодовой базой... - person Breton; 08.02.2011
comment
достаточно, чтобы знать, что я могу вырезать и все еще иметь работу. - person Breton; 08.02.2011
comment
Что касается тестов. Недостаточно знаком с C или DOS, чтобы знать, как лучше всего настроить тестовую обвязку. На данный момент я просто пытаюсь заставить его компилироваться вообще, так как одного лишь прохождения времени было достаточно, чтобы изменить компилятор Watcom C настолько, что этот исходный код не компилируется без достаточное количество модификаций. (Огромная часть функций даже не имеет прототипов! Я получаю тонны предупреждений только об этом) ... Но есть некоторые странные тесты, встроенные в различные части кода, которые пытаются инициализировать структуру массивом символов. , количество участников определяется... - person Breton; 08.02.2011
comment
с помощью реляционного выражения... например, {char x0[sizeof(Fli_head) == 128];} ... Если размер Fli_head не равен 128, то он пытается инициализировать массив символов с 0 элементами, что выдает загадочная ошибка компилятора, привлекшая мое внимание к этому фрагменту кода. Здесь нарушается предположение о размере типов int, используемых в формате файла и во множестве других мест. Я пока не придумал, как решить эту проблему. - person Breton; 08.02.2011
comment
Похоже, первоначальный разработчик был достаточно дальновидным, чтобы вы могли настроить определения типов в INC\STDTYPES.H, чтобы решить эту конкретную проблему, слава богу. В коде предполагается, что SHORT — это 16-разрядное целое число, а LONG — 32-разрядное целое число. К счастью для вас, похоже, что эта кодовая база предназначалась для некоторой переносимости, что имеет смысл, учитывая, что она зародилась на Atari ST. - person Jeremy Penner; 08.02.2011
comment
@ Джереми Пеннер, я так и думал, поэтому я изменил определения типов на некоторые вещи из stdint.h, и это, похоже, только еще больше запутало, отчасти из-за непоследовательного использования типов из STDTYPES.H. За последние пару дней внезапно вмешалась куча других вещей, поэтому у меня не было возможности внимательно посмотреть, что там происходит. - person Breton; 10.02.2011
comment
Если ваш компилятор C имеет stdint.h, то, возможно, стоит импортировать его, а затем четко указать разрядность - используйте int32 вместо LONG и int16 вместо SHORT. - person Stuart Axon; 17.02.2014

arrow_upward
6
arrow_downward

Хммм - я мог бы подойти к этому, написав для него видео-драйвер OpenGL. и сегодняшние машины достаточно быстры с тоннами оперативной памяти, чтобы вы могли выполнять все алгоритмы, специфичные для пикселей, на основном процессоре в заднем буфере, и это сработало. Поскольку «общий» драйвер VGA просто сопоставил видеобуфер с указателем, с этого можно было бы начать. В пользовательском интерфейсе был режим масштабирования, чтобы вы могли смотреть на пиксели на дисплее с высоким разрешением.

person peterk    schedule 06.06.2011

arrow_upward
0
arrow_downward

Часто очень сложно взять существующую нетривиальную кодовую базу, которая не была написана с учетом переносимости (вы упоминаете несколько), а затем попытаться сделать ее переносимой. В пути будет много проблем. Вероятно, лучше начать с нуля и переписать код, используя существующий код только в качестве справки. Если вы начинаете с нуля, вы можете использовать существующее портативное решение пользовательского интерфейса в своем новом проекте, таком как Qt.

person AndersK    schedule 06.02.2011
comment
Я полагаю, что при таком подходе я боюсь потерять первоначальный характер программы. - person Breton; 06.02.2011
comment
@Бретон. Грубо говоря, любой инструмент, который был разработан для работы с низким разрешением и ограниченными цветами, потеряет свой характер после переноса на современные настройки. удивительное разрешение 640 x 480 выглядит очень маленьким на любом современном HD-экране. - person Ben; 06.02.2011
comment
@ Бен, я понимаю, что вы имеете в виду. Однако в этом конкретном случае исходная программа на самом деле полностью способна работать с полным разрешением на современной установке, если вы можете написать для нее видеодрайвер. На мой взгляд, это похоже на то, как если бы вам действительно нравился Эпизод IV «Звездных войн» и вы хотели бы избежать создания Эпизода 1. Или, скажем, взять оригинальный Super Mario Bros и переделать его с использованием 3D-моделей и дрянной озвучки. - person Breton; 06.02.2011
comment
оглядываясь назад, мой последний комментарий здесь действительно не имел смысла. Игнорировать. :D - person Breton; 08.02.2011
comment
честно говоря, я все еще думаю, что в вашей ситуации вам лучше начать с нуля. портирование приложения, которое для этого не предназначено, часто похоже на попытку протолкнуть квадрат через круглое отверстие. очень расстраивает. - person AndersK; 08.02.2011