Все это делается только для фана. Образования специального нет, погромистом нигде не работал.
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



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

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

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

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

У меня обращение к кускам внутри больших файлов по конкретным адресам - 40 байт там, пару десятков байт там, сотня тут.

Примерно в таком формате:







Т.е. обращение к mapped файлу как к массиву.

Именно про эти два куска я писал, что менял их на TFileStream (Seek&Read) - и получил падение скорости в три раза.
Подозреваю что тут тот самый редкий случай, когда ММФ действительно нужно, и нормальной альтернативы нет.

_Vasilisk_Vizit0rу меня нет такого, что надо вычитывать большие файлы подряд.MMF именно это и делает выделяет буфер под весь файл (если Вы мапите сразу все), считывает файл в этот буфер и отдает его Вам

почитал мсдн, подумал.

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

Там файлов, которые мапятся- в сумме на 500 мб и больше.

добрался домой, пришел в себя и занялся делом.

Сделал конвертирование из 15битного формата в полноценный FMX RGBA 32б. Андроид по традиции преподнес сюрпризов с отрисовкой.
Вот один из них:


Другой момент - это когда присваиваешь одному битмапу другой, потом на первом рисуешь Rect - а он в тех местах, где пиксели непрозрачные - не отрисовывается. Выкатил на fire-monkey.ru вопрос, может опытные люди подскажут.
Еще всякое-разное с андроидом было, с размерами TImage, выводом изображения на него и прочее.

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

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

забыл упомянуть еще момент.
Tbitmap -
задаешь размеры, затем
Result.Map(TMapAccess.Write,BitmapData);
затем в цикле
P := BitmapData.GetScanline(Y);
и заполняешь только те пиксели, которые используются.
И получаешь сюрприз, что в незаполненных пикселях мусор. И пофиг, что сразу после задавания размера ты делал
Result.Canvas.Clear(TAlphaColorRec.Null);

Зло где-то в районе Result.Map, я не копал глубоко, да и конкретное место неинтересно.

Приходится в каждой итерации делать

P := BitmapData.GetScanline(Y);
FillChar(PCardinalArray(P)[X], Width * SizeOf(TAlphaColor), 0);

SaperskyVizit0rИ получаешь сюрприз, что в незаполненных пикселях мусор.
Похоже, это такая оптимизация, FM в режиме "только запись" не гоняет картинку из видеопамяти, считая, что она всё равно будет полностью перезаписана.
Можно использовать TMapAccess.ReadWrite, хотя очистить картинку FillChar-ом наверняка будет быстрее.

это логично, и это первое о чем я подумал.
Только вот....




:)

авторТам по-старинке FillRect не работает?
там по-старинке почти ничего не работает, все изменено. Но более-менее логично, примеры и справка + чтение FMX сурсов нормально помогают.

может кто-то в курсе - есть ли какая-то возможность под андроид получить инфу о memory corruption ДО того как андроид вышибает со стеком, в котором фигурирует :F6EAF8AC __bionic_heap_corruption_error и прочее такого плана?
Overflow checking + Range checking не помогает.
Ошибка повторяема, проблема где-то в дельфо-андроидных конвертациях PAX'а больших структур (> 4б) при вызове из скрипта внутреннего метода приложения. Знаний, чтобы понять что там не так - явно не хватает. Если проблему структуры размером 3б я решил по аналогии с проблемами структур пакса еще для винды, то в случае большой структуры так уже не катит. Там вовсю работают конструкторы-деструкторы, фиг поймешь что и где не так.

На этой неделе было время свободное, занялся андроидной версией.


1)с удивлением узнал, что в стандарном сете иконок для андроида нет сохранения. вообще. Что-то похожее еще примерно похожее на открыть есть, а для сохранения нет.
Нашел в полном наборе materials ( https://material.io/icons) иконку сохранения, попробую ее на досуге впилить в стиль.

2) Долго ругался на вызов файлдиалога. Благодаря тому, что с какой-то версии FMX не поддерживает ModalWidows, все действия после вызова файлдиалога пришлось переносить в коллбеки. Особенно классно выглядит это, когда в одной цепочке может быть несколько вызовов файлдиалога, например при открытии файла запрос на сохранение измененного с файлдиалогом для выбора куда сохранить, а потом за ним опендиалог.

3) на удивление легко и правильно завелись Notifications. Неожиданно.

4) поимел вдоволь секса с попыткой сделать редактирование в android-style, когда при редактировании строки или поля оно взлетает наверх, чтобы было видно при открытой виртклаве. Так вот, сделать это легко и просто получается только для TEdit. Для TMemo - все сложно, оно-то наверх прыгает, но при этом верхняя часть уходит за экран. Долго и нудно возился, пока не сделал в лоб - при показе VK меняю layout с tmemo стиль alTop и выставляю нужный Height.
Пробовал и примеры из дельфийского набора, и vkbdhelper.

5) довеском про tmemo - большие проблемы с лонг-тапом и тем, что из него вытекает. Меню показывается, но если нажать на кнопку в появившемся меню или попытаться изменить область выделения - отличный шанс вылететь с невнятной ошибкой в потрохах переходников явы. Пришлось отключить LongTap, но все равно при желании можно получить краш. Что-то там сильно неладно в потрохах. Надо спросить на fire-monkey.ru, может у кого есть решение.

6) андроид 8 походу еще не поддерживается - приложение деплоится, работает нормально, но при этом среда виснет на Launching Application. Т.е. отлаживать на 8 дроиде не получится.



P.S. Кстати, после покупки нового домашнего компа с i5 на борту - компиляция под андроид перестала быть чем-то смертельным, когда можно ставить на компиляцию и уходить кушать, курить и пить кофе. Ощутимо дольше, чем VCL, но уже можно жить. Тот случай, когда проц действительно имеет значение. Знал бы, что будет такой эффект - может и на i7 бы разорился.

по нынешним временам мало - всего 8 гб. Но я в игры не играю, мне больше точно не надо.

А до этого был какой-то целерон убогий и 2 гб памяти. Старый комп тогда сгорел, денег небыло, пришлось покупать все самое дешевое. Ноут быстрее работал, чет это убожество.