Все это делается только для фана. Образования специального нет, погромистом нигде не работал.
Delphi Seattle. Из обвесов DDev и EurekaLogs 7.4 (кстати вот за эту я бы заплатил, оно того стоит. Может и куплю в итоге, 150$ не такие большие деньги. А вещь реально отличная).

Моего кода - 320к строк, включая PAX.

Все это бодро и весело крутится под вин, баги вылавливались годами, практически не осталось их - стало скучновато. Задумался про мультиплатформенность. Первым пойдет в ход андроид - с ним проще всего, и эмуляторов рабочих полно, и у меня несколько реальных девайсов под руками разных версий - вобщем есть где тестить. С тем же иосом куда сложнее будет.

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

Сначала я без спешки где-то год разделял тот монолит, который у меня был на ядро + надстройка. Попутно максимально отделял от основной части приложения логгер, скрипты и прочее - вобщем делал то, что по-хорошему изначально должно было быть. Попутно, начитавшись рекомендаций по переходу на малтиплаформенность от ЕМ, убирал явные косяки в коде - обращение к символу строки по индексу и прочее такое очевидное.
В это же время был переезд с PascalScript на Pax, именно из-за мультиплатформенности пакса, но этот ад достоин отдельного поста, потом распишу подробнее.
На этом этапе я еще не выносил код гуя из юнита формы в отдельный юнит, про это тоже позже.

Потом, на удивление легко и просто, через пару дней допиливания напильником скомпилировалось ядро под андроид. Пока только скомпилировал, ничего не запускал.
Споткнулся разве что об WaitForMultiple - работает только в Win, и это была большая засада.
Сделал банально:


а в CommonTimerProc (который в дочерних классах перекрывается при нужде) перебирать уже всё.



Взялся за надстройку.

Из того, что явно запомнилось по коду:
1) Как я уже писал пару недель тому в соседней теме - Не надо использовать System.ByteString. Вообще. У меня вдруг после включения этих байтстрингов в десятка полтора юнитов в одном месте вылетела ошибка что-то там, мол приложение скомпилировано с неправильной версией юнита variants, хотя я таким не баловался никогда. Гугл не помог. Отказался от System.ByteString - и все нормально стало, хотя ByteStrings были для сиэттла.
Правильный, но тяжелый путь - переводить все на юникод. Для анси использовать
//bytes := TEncoding.ANSI.GetBytes(str); и //str := TEncoding.ANSI.GetString(bytes);
Вначале кажется, что оно неприменимо везде никак, все равно мол. останется куча мест. Ан нет, в итоге перекрыл все ими. Приноровиться надо, тогда все просто оказывается :)
2) Перевод всех TList; на TList<X>; Их было очень много (только в одном юните около 30). Особенно навеселился с компараторами. Но сделал. Оно конечно можно было бы не трогать, это (пока?) лишь warnings, но когда их столько - начинает напрягать.
3) Классическое TStringList.Add('xxx',TObject(some_record)); перевел все структуры в классы, нормально.
4) от ZEROBASEDSTRINGS, настоятельно рекомендуемого ЕМ, я отказался - делать аудит ВСЕГО кода я охренею. Это добавило чуток сложностей в плане того, что надо все время держать в памяти, что в стрингхелпере оно включено, а у меня нет - но это некритично.
5) куча всяких мелочей, типа неподдерживаемого ZDecompress с указателями в параметрах (оставили только с TBytes) и прочее.

Явно что-то забыл, спрашивайте.



Про FMX позже.

P.S. У нас тут суета и паника, уже завтра-послезавтра могут всех домой отправить, так что не до интернета несколько. Зима пришла на месяц раньше ожидаемого :(

Миграция PascalScript => Pax.

PS, при всей его вылизанности - увы, не поддерживает ничего кроме Win в принципе. Пришлось переходить на Pax.
Ну и плюс Пакс поддерживает хелперы, классы в коде, overload, default param и прочее. Да и сам по себе движок очень мощный.

Вначале, прочитав что PaxProgram (компилятор в байт-код) работает намного быстрее, чем PaxInterpreter - начал заниматься им. Багов там не то, чтобы много - их там невероятное кол-во. Я вылизывал его две недели, и все равно, новые всплывали без конца и края.
Почему я сразу не стал использовать PaxInterpreter, который, собственно, и есть мультиплатформенный - вопрос без ответа.
В итоге перешел на него. Скорость поменьше, чем у PaxProgram - но мне с головой хватает. Багов, по сравнению с PaxProgram - крайне мало, и те скорее из-за невозможности протестировать автором всё. Вообще у меня сложилось ощущение, что с какого-то момента все внимание автора пакса уделялось только PaxInterpreter, а разработка PaxProgram была прекращена, а сам движок пакса развивался, фичи добавлялись - оттуда и все эти баги. Так, в комлекте идет, но работать с ним почти невозможно.
В PaxInterpreter'е тоже багов хватало, и потери от кривого перевода типов, и неправильное освобождение строк, а работа с массивами - это вообще что-то.

Потом выложу свой вариант исходников куда-то на гитхаб или еще куда. Предлагал автору, автор не захотел отвечать (хотя пару лет тому сквозь зубы пару строк выдал). Ну нет так нет.

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

Впилил в него полноценную отладку - получение и установку переменных, полей классов и структур и прочее, прочее. Где-то в соседних темах показывал скрин редактора в момент отладки.

Из поддерживаемых языков - VB работает так же хорошо, как и паскаль.
А вот JS сырой. Совсем сырой, от кривых массивов, до отсутствия подхвата-на-лету строк вида '{Count: 1, Items: [{ClilocID: x, Params: [''str1'', ''str2'']}]}'. А кому оно в таком обрезанном виде надо?



P.S. Это кстати вторая попытка впихивания пакса, удачная. Первая была года 3 тому, но неудачно. Багов было больше, знаний меньше.

wadmanVizit0r,

софт-то что делает в общих чертах?
Только для внутреннего потребления?

Скриптовый клиент для игр. Т.е. никакой графики вообще.

Vizit0rwadmanVizit0r,

софт-то что делает в общих чертах?
Только для внутреннего потребления?

Скриптовый клиент для игр. Т.е. никакой графики вообще.

Поправлю себя - графика есть. В UO-надростойке вычитываются дата-файлы игры, и в одной из вкладок рисуется простейшая 2д-карта, по ней удобно бегать и вообще понимать что и где.
Вот собственно и вся графика.

про FMX.

В Seattle его уже хоть как-то, пусть с оговорками, но можно использовать. До этого пробовал XE7 - все было уныло начиная уже со старта.

Из больших подводных камней:

1) Самый большой, встреченный мною - это TBitmap. В VCL ты спокойно задаешь pixelformat и вперед. А в FMX так нельзя. Там нельзя задать pixelformat вообще, он задается сам в зависимости от движка отрисовки. А даже если бы можно было (до XE8, насколько помню) - pf15bit там вообще нет. И вот фиг знает что мне делать, конвертировать 800 мб арта в 32б формат меня как-то не радует.
А по остальному - пикселы мапятся, и через GetScanline читаются.

Пользуясь случаем - никто не встречал на своем пути сторонних мультиплатформенных классов по работе с графикой, и чтоб бм поддерживала? гугл не признается.

2) Неплохой набор подводных камней сидит в стандартных компонентах. Например для TEdit и TComboBox нельзя сделать высоту меньше чем 32, оказывается это фича такая.
Лечение тоже в духе FMX

.
Да и шрифт в TComboBox так просто не изменишь, но это уже мелочи.
А вот то, что у TComboBox отсутствует ивент OnSelect - это уже не мелочи. Теперь приходится при операциях с ComboBox ставить OnChange в nil, потом возвращать обратно. Та же история с CheckBox, кстати.
Измененные названия проп типа Caption\Text - это ерунда. Правильно поменяли, кстати. А то эти пропы с типом "TCaption" меня всегда напрягали.

Загрузку из ресурсов я еще не успел проверить.

Нет OwnerDraw у айтемов листбокса - это сделало мне большую печаль. Вроде есть варианты, но там тоже не так все гладко. Но хотя бы направление движения есть - буду копать.

3) Попереименовывать все цвета в TColors.XXX (напр. TColors.Green) - невелика проблема.

Так сходу из общих проблем FMX ничего не вспоминается.

rgreatVizit0rПользуясь случаем - никто не встречал на своем пути сторонних мультиплатформенных классов по работе с графикой, и чтоб бм поддерживала? гугл не признается.Graphics32 не катит разве?
качну, посмотрю что там, спасибо.

FMX применительно к Андроиду.

Мне вот надо, чтоб приложение работало только в landscape режимах - обычном и перевернутом. Portait - нафиг.
И вот идешь в опции проекта, там смотришь в Application-Orientation, включаешь, выбираешь 2 нужных галки. Вроде все классно и очень просто. Вот только не работает. При повороте приложение все равно хочет повернуться в portrait и тупо крашится.
А работает как надо только при сочетании двух вещей -
1)
в .dpr проекта сразу после
Application.Initialize;
добавить
TAndroidHelper.Activity.setRequestedOrientation(TJActivityInfo.JavaClass.SCREEN_ORIENTATION_SENSOR_LANDSCAPE);
ну и
Androidapi.Helpers,
Androidapi.JNI.App,
Androidapi.JNI.GraphicsContentViewText,
в uses

2) в файле AndroidManifest.template.xml поменять android:configChanges на
android:configChanges="orientation|keyboard|keyboardHidden|screenSize" .

Второй фикс - для решения вопроса краша при повороте, первый - для использования только двух landscape режимов.


Радует, что в Сиэттле "изкаропки" нормально работают в андроиде контролы, получающие фокус, раньше в андроиде 5 вешали приложение наглухо.

Из интересных моментов - вот есть в FMX классические Open\Save dialogs. Все отлично вроде как. Вот только на андроиде никакого диалога не показывает, а сходу возвращает False. Почему было не реализовать его при наличии всех необходимых апи - то вопрос вопросов. Причем ЕМ про этот факт скромно забыло упомянуть в инфе про диалоги. Впрочем, в инете народ уже выложил несколько вариантов, потом буду смотреть, что там да как.

Вообще разработка гуя, или фикс чего-то в андроиде - это отдельная песня, причем очень грустная. Это в VCL просто - поменял, запустил, посмотрел результат, закрыл и по кругу. В Андроиде, когда компиляция + deploy + запуск приложения занимает минуты по 3 (на i7-то!) - разработка превращается в нечто невероятное.
После нескольких экспериментов оказалось, что никакого выигрыша в скорости при использовании андроид-эмуляторов нет, с реальным получается быстрее всего.

Еще вспомнилось "двойное завершение" приложения, когда при закрытии оного происходит двойной заход в деструктор главного окна. Причину я так и не понял, корни уходили в глубину явы, так что поставил простой семафор и забыл.

на текущий момент:
1) приложение запускается, все настройки подхватывается, к серверу подключается нормально, (по отзывам нескольких юзеров скорость такая же как и на компе - 1-2с на коннект. Здесь же интернет через спутник - коннект может и полминуты идти), скрипты запускаются.
2) Для полноценной работы всех дата-файлов надо впилить класс MMF для андроида - сейчас 5 юнитов из 13 фактически отрезаны.
3) разобраться с битмапами
4) опен-диалоги и прочее, это уже текучка.

Вот как-то так.

было чуть времени, заценил 2 реализации списка каталогов\файлов - одну на основании банального TDirectory.GetDirectories и TDirectory.GetFiles, вторую на основании крохотного java-класса. Вторая чуть быстрее, но чувствуется это только на реально больших списках - напр. 200 фоток через дельфийские методы получал чуть-чуть дольше, чем через ява-класс. Мне такие каталоги не нужны, а значит можно сказать что скорость одинакова.
А вот с импортом все оказалось намного сложнее. Надо прицепить .jar, в деплоймент прицепить все нужные файлы от него, правильно прописать им RemotePath. В офиц. инструкции все красиво и легко - просто импортируйте все нужные файлы в проект. всё.

Итог - использую самописный список, на основе первого варианта. К нему и фильтра дописать можно и вообще настроить как хочется.

makhaon,

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

А насчет андроидного варианта - да вобщем-то мне и FMX подходит, тем более что он не только под андроид идет. Размер они по сравнению с первыми версиями FMX уменьшили, скорость работы вобщем-то пристойная - пока что все устраивает.




Сегодня кстати выложу скриншотов, как закончу делать ownerdraw для listboxItem.

makhaonVizit0r,

:) всё так жестко было? 1.7 (транковый) точно так не делает. 40 мб - в дебаг режиме. если без - размер будет меньше.

авторПока что все устраивает

Если работает - то отлично! Показывайте, рассказывайте. LCL, к слову, тоже везде работает.

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

Через пару часов буду на работе и скину скринов.



P.S. Рисование на канвасе в FMX отличается от VCL, но ничего такого абсолютного иного. Хелп + примеры нормально помогают. Самый сложный момент оказался с цветами - там TAlphaColor используется, который есть $FF or TColor. Сразу не обратил внимания - и не мог понять, чего это ничего не рисуется. А оно просто прозрачное всё было.

kealon(Ruslan)Vizit0rСкриптовый клиент для игр. Т.е. никакой графики вообще.
А что за игра?

основная - это та, под которую упор делается, есть много народу, который приложением пользуется (и тестит, соответственно) - это Ultima Online.

Так-то переделывалось и под Perfect World, и под несколько VK игр - еще до разделения на ядро и игровую надстройку.
Уже несколько заявок есть на другие игры, но пока не до них.

Два скрина - вин и андроид.
Эти цветные полоски убивают тонну времени - я часа два потратил на то, чтобы правильно подобрать их положение. И то не до конца, но это уже мелочи. Да и цвета явно не те, что должны быть - виндовые цвета на андроиде извратились до совершенно других. Пока взял Red Blue Green, потом подберу покрасивее.

а черт, 2 скрина с нета под спойлером, и еще 1 приложился файлом - продублировался.

в FMX, в отличие от VCL, для TListBox в событии OnClick еще старый ItemIndex листбокса. Новый установлен дальше, ловить можно в OnItemClick.

один из мелких незаметных моментов, которые при этом могут осложнить жизнь.

1) размер - 52 мб exe - как-то меня не очень радует. Против 13 VCL.
2)В редакторе много чего чисто VCL-ного задействовано.

попробовал отказаться от Memory mapped files в пользу обычного TFileStream - получил на винде при просчете маршрута замедление в три раза.
Пришлось на коленке состряпать порт MemMapFile на Posix



остальное вроде не меняется.

все оказалось проще, чем казалось сначала.

потом проведу тесты на андроиде, чтобы сравнить время.