» Вопросы по Embarcadero RAD Studio XE3

Цитата:

Собираетесь заняться разработкой игровых приложений?

ага, почти, с конца 2011г., только черт меня дернул начать это делать на firemonkey - поверил в маркетинговые сказки
- теперь вот не знаю куда податься, то-ли ждать fm3-qt5.1, или вообще переходить unity3d....

sergionn

unity3d на порядок перспективнее! Там уже сейчас есть то, чего для FMX никогда не будет (asset library/store). Ну и он прямо для игр, и их ужем много и удачных.

deks согласен на 100%, делал бы игру - не задумывался бы ни на секунду,
но игру я не потяну - много народу нужно, а у меня нет ни времени ни возможностей собирать команду, поэтому ваяю нечто среднее, околоигровое
Остановился на обезьяне так как был большой соблазн, в написании единого кода для mac и win + давнишний опыт в delphi, последняя многочисленная, а вторая имеют бОльшую отдачу, но видимо с обезьянкой что-то не судьба - сраную поддержку dx10 и то не смогли обеспечить из-за 2 багов, перевожу проект под lazarus - smartmobliestudio............

sergionn
Я ни разу не слышал, чтобы разрабы FM ассоциировали его с играми. Говорят: «да, в принципе можно, но он не для этого». Да, и сам Крюков, опираясь на свой опыт работы в геймдеве, в одном из вебинаров говорил, что требования сильно разные.
Да и что можно использовать в FM для игр? Канву, импорт моделей и рендеринг видео в текстуры, разве что. Ну и гуй, хотя про него можно сказать, что лучший тот, который от игры не отвлекает, следовательно тот, которого никто не замечает

Цитата:

чтобы разрабы FM ассоциировали его с играми.

на данном этапе fm ни то что с играми ассоциировать нельзя - на нем нереально сваять ни одно серьезное приложение, так демо поделки для отдела маркетинга, причем мешают этому пара-тройка злосчастных багов, на которые видимо Евгений ПОЛОЖИЛ большой и толстый *********

Цитата:

на нем нереально сваять ни одно серьезное приложение

Что не помешало кому-то на FMX1 сваять трехмерный морской бой с анимацией и эффектами, и игру, в нарды что ли, для AppStore

нельзя сейчас эти баги трогать! НЕЛЬЗЯ !

иначе кто и зачем ХЕ4 купит ?

Цитата:

Что не помешало кому-то на FMX1

ну припустим и на fm1 и fm2 много чего наваяли, но success storyes нет.........
про нарды я промолчу, их по моему и на такой _http://www.runrev.com/products/Overview/ системе сбацать можно


Цитата:

нельзя сейчас эти баги трогать! НЕЛЬЗЯ !

+100500! - смех сквозь слезы............

FailMonkey.

короче не видать нам delphi под intel-amd на llvm
в ближайшей перспективе: https://forums.embarcadero.com/message.jspa?messageID=531092#531092

ну хоть одна хорошая новость...

sergionn
Arioch1

Заметим, что у RO есть универсальный компилятор с одной кодовой базой для .NET/Java/ObjC. И у них как-то получается делать debug под VS во всех этих платформах! И это все при их 2,5 человека в R&D. Да, на Frameworks/RTL у них не хватает потенциала, но они позволяют юзать родные RTL платформ.

К чему я это? Странно слышать от ЭМРО сетования на сложности в разработке компиляторов! Лучше бы они купили RO. Хотя для ЭМРО VS вообще никуда не уперлась.. Тогда бы была нормальная поддержка .NET, Android/Java и ObjectiveC (iOS/OSX). Ну и FMX нужно изолировать от платформ, делая ее опцией - хочешь, используй эмуляцию UI через FMX, а хочешь - родную на платформе.

Нужно признать факт - базовые вещи в кодовой базе ЭМРО устарели до состояния списания "в утиль" - deprecated. Базовые вещи - это код внутри IDE (какие нафиг 2 парсера?!), API этого IDE (которое очень слабое, и все разработчики расширений делают собственный парсер, вместо использования УЖЕ ВСТРОЕННОГО парсера IDE - пример MMX, Castalia). Еще базовая вещь - VCL компилятор, который тоже устарел. Нужно "прыгать" на LLVM или что-то аналогичное: с "отделяемым" модульным парсером, с различными FrontEnd и Back-End генераторами кода для разных платформ. По текущим временам для любого КРОСС-платформенного решения НУЖНО поддержка МИНИМУМ Android/iOS для мобилки и Win/Win8/OSX для десктопа. А лучше чтобы был Linux Server, Windows Phone. Я не говорю про экзотику в виде Linux Embedded, RIM/BB, ...

Ну и с имеющимся RTL у ЭМРО не все в порядке. VCL устоялась, да, но она лет тка 10 назад остановилась в развитии.

Где в RTL/Frameworks есть ORM? А что-то для Web вида .NET? (не смешите про IntraWeb, к тому же ЭМРО не контролирует эту технологию и она не OpenSource). Ну даже классика в виде паттернов MVC/MVP/MVVM все равно отсутствует. Устарело ОЧЕНЬ значительная часть RTL.

Ну - в плане баз данных, сейчас возможно BDE отправят на покой. Но Database без MVC/MVP/MVVM подхода? Без Scaffolding? Без ORM? Для текущих времен это несерьезно.

Ну а графика? Какой нормальный engine можно прикрутить к Delphi? Unity3D? нет. Вообще никакой. FMX обеспечивает 3D возможностями, которые даже для презентационной графики особо не годятся! FMX3D нужно довести до приемлемого уровня поддержки хотя бы КАКОГО-ТО вида его применения. Например, для построения визуализации трехмерных объектов. Ну и с плоской графикой не все ясно.. Мало какие решения "из коробки" достаточны для любого реального применения (например, сделать PDF документ с графиком - как?!).

Сетевые возможности Дельфи "из коробки"? Indy? Не очень серьезно. Ну и никаких API для распространенных сервисов.

Не совсем ясно, что ЭМРО таки хочет сделать в плане RTL.. Вроде бы делает огромные бандлы из дешевых стартовых версий компонентов, но это похоже на маркетинговый трюк, а ценник студии задирает оч сильно. Купили пару производителей компонентов. ИМХО, тупиковый путь. ЛУчше бы поддержали сильные Open-Source решения, ну и в рамках такого решения, например, похоронили Interbase и поддержали бы Firebird. В современных условиях RTL/Frameworks лучше всего делать Open-Source, делить на компоненты и выкладывать на приличных хостингах с легкой групповой работой (GitHub?). Берем пример с MS с ее Entity Framework и ASP.NET

согласись это разные вещи - в уже отлаженный x-platform компилятор добавить +1 платформу и написатьx-platform компилятор имея на руках только узко заточенный на wintel продукт.

Или вот возьми Lazarus - вроде и не Эмба, и людей не мало, а GDB / Win64 до сих пор толком не работает.

ТАк что это не однозначно. Как минимум в CLR/JVM в отладчик ихзначально загонялись интерфейсы, обхекты и т.д., а в Dwarf/GDB загонялисьтолько DLL-ные вещи, примитивные типы, и их езё действительно надо суметь расширить.

deks

Цитата:

VCL устоялась, да, но она лет тка 10 назад остановилась в развитии.

А поддержка жестов и тача? А скининг? LiveBindings в конце концов. Какие пути развития видишь ты?

Arioch1


Цитата:

уже отлаженный x-platform компилятор

У RO изначально был только .NET компилятор. Позже был сделан кодогенератор для Java, а сейчас сделали кодогенератор ObjC c привлечением LLVM. Так что у RO не все так просто было, но они справились. При этом они делали рефакторинг и не боялись "ломать" существующую кодовую базу, а постоянно ее "апгрейдили" под новые задачи. У ЭМРО же так никто и не сделал нормальный внутренний парсер паскаля для IDE, не были произведены важные refactorings в продукте - в результате мы имеем то, что имеем - худо-бедно работающую IDE, но которая сложно поддается модификации.


Цитата:

возьми Lazarus

Не будем сравнивать Open-Source проект с коммерческими компаниями. Все ж таки за деньги народ должен работать немного интенсивнее. А вот у того же FPC уже есть кодогенераторы и для ObjC-сред, и для Java VM. Не говоря о куче Linux таргетов! Поэтому отсутствие полированности на одной из платформ - ну, се ля ви..


Цитата:

поддержка жестов и тача

Не принципиально для win-приложений. Покажите мне хоть одно приложение, которое их использует на Win Vista и Win7. (а у меня был HP TouchSmart!). Поддержка жестов актуальна для Win8, где есть планшетные устройства, но Дельфи не поддерживает Win8 нативно - только legacy desktop приложения.


Цитата:

скининг

Куплен у KSDEV.


Цитата:

LiveBindings

ИМХО, ненужно усложнен. И вообще, для такой фичи нужны Frameworks, которые его нормально используют - типа ORM/etc. Таких нету.


Цитата:

Какие пути развития видишь ты?

Внедрить нужные фишки, реализованные в других языках/платформах: async/await или другие удобные средства организации асинхронного программирования (Delphi с потоками без OTL - это ад, но на OSX нету OTL), множественные обработчики событий, ARC (да, уже делают - но когда сделают?!), аспекты, нормальную встроенную Collections на шаблонах, более удобные блоки (анонимные функции) ...

Вообще, в плане языка у Дельфи не очень плохо - все таки многое есть! Большинство претензий - к RTL. Вот в RTL многого нету! Где приличная сетевая библиотека (типа CIS, + TMS Cloud Pack)? Где текстовый редактор под FMX (TRichView/ScaleRichView)? Где поддержка файловой работы со стандартными типами документов - PDF/XLS/DOC (без установленного MSOffice - как у гностиков)? Где Web view для FMX (DCEF)?

Путь развития один - или покупать коммерческих вендоров (они таки и делают - KSDev, AnyDAC), и развивать самим, или поддерживать Open Source проекты, которые решают нужные задачи. Я за поддержку OpenSource - это результативнее.

deks

Цитата:

Не принципиально для win-приложений.

Не принципиально, конечно, хотя лучше она есть, чем её нет. В качестве примера можно привести Оперу, которая поддерживает управляющие жесты. Ну а convertible pc выходили задолго до Windows 8.


Цитата:

Дельфи не поддерживает Win8 нативно - только legacy desktop приложения.

Ни какие они не legacy. Они classic. WinRT никогда не заменит собой классический десктоп.


Цитата:

Куплен у KSDEV.

Вот это как раз не принципиально. Купили или сделали сами не важно. Важно, что развитие VCL продолжается.


Цитата:

ИМХО, ненужно усложнен. И вообще, для такой фичи нужны Frameworks, которые его нормально используют - типа ORM/etc. Таких нету.

На счет усложненности согласен. Я бы даже сказал о ненужности, но это мое личное мнение.


Цитата:

Внедрить нужные фишки, реализованные в других языках/платформах: async/await или другие удобные средства организации асинхронного программирования (Delphi с потоками без OTL - это ад, но на OSX нету OTL), множественные обработчики событий, ARC (да, уже делают - но когда сделают?!), аспекты, нормальную встроенную Collections на шаблонах, более удобные блоки (анонимные функции)

Это ты сейчас о RTL говоришь. Я же спросил тебя о путях развития VCL, раз ты про неё говорил.

Цитата:

У RO изначально был только .NET компилятор. Позже был сделан кодогенератор для Java

LLVM - это сильно.
А вот CIL и JVM должны быть исторически очень похожи. И аналогичные конструкции должны быть картированы проектами типа IKVM

Более того - это языки другого уровня. Не надо реализовывать объекты, интерфейсы, ARC/GC - все готово.


Цитата:

более удобные блоки (анонимные функции)

+много


Цитата:

ARC (да, уже делают - но когда сделают?!)

Уже есть с Delphi 4, а принудительно на него переводить всех на него - сомнительно.
Хочется - перрепишите RTL и VCL на интерфейсы.
Мен как раз это очень не нравится.


Цитата:

нормальную встроенную Collections на шаблонах

Вопрос в компиляторах, библиотеки-то есть.
Например S4D - но чуть начинаешь использовать - компилятор падает.

Опять же - шаблоны недоделанные. почему я не могу сделать класс-сумматор
function sum<t> (const v1, v2: t):t; begin result := v1+v2 end; ?
Или допустим хочу я сделать generic контейнер для разных record'ов. Так там все методы множиться начнут, для каждого рекорда отдельное тело. В то время как для 90% методов вся разница только в sizeof и чисто семантическом (т.е. не существующем для процессора) типе указателя на начало рекорда. Немногие методы, которые бы реально внутрь записи лезли (сравнение, например) можно сделать виртуальными. Но нет, тупой компилятор будет все методы размножать типа Add, GetItem и т.д.

ЛУчше бы они компилятор хороший сделали - а библиотеки люди напишут.

Лучше бы они generic enumerator сделали, чтобы можно было разные for-in циклы запускать по одному объекту.


Цитата:

множественные обработчики событий

Это больше к VCL. В той же s4d их вроде реализовали.

Но! слышал сравнения с Qt, что их слот-сигнал довольно тормозной сравгительно с прямым вызовом a la VCL
Тaк что если делать множественные события, то только после того, как реально появился второй обработчик. По умолчанию должен быть прямой вызов.

Все равно Дельфи не будет JVM-языком с перекомпиляцией во время работы. Потому быстрое выполнение для нее не на последнем месте.

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


Цитата:

аспекты,

Тоже спорно. Кому надо - могут напрямую менять VMT или патчить вход в функцию. Примеров в сети довольно. А в мейнстрим это пихать довольно опасно. Совместно с мульти-событиями да ARC это такой лютый ... клубок кода... устроят....



Добавлено:

Цитата:

Я же спросил тебя о путях развития VCL

Давно я не занимался JVCL, закуклилась их команда и черт с ними.
Но когда пишешь компоненты - реально все время натыкаешься на место, где VCL монолитен и не расширяется.

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

...и кстати, кто скажет, что за observers появились у классов ? в хелпе как всегда фига. Кто как и для чего это использует ?

deks
Не думаю, что для ребят из эмбаркадеро проблема написать llvm pascal компилятор. А вот написать llvm pascal компилятор, который будет компилить большую часть старого кода без изменений - это у кого угодно пупок развяжется. RO даже браться не стали, т к задача для них не подъемная.

Arioch1
От лайвбиндингов копайте, оно именно для них делалось.

Цитата:

аписать llvm pascal компилятор.

ТАк компилятор они вроде написали. Они говорят, что стандарты отладочной информации в llvm и elf такие, что просто нельзя полноценно передать все возможности языка и потому они не могут сделать поддержку отладки. Якобы так.

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

>> что за observers появились у классов ?

вы про это?
_http://docwiki.embarcadero.com/Libraries/XE3/en/System.Classes.TObservers

O! там туториал появился. Не густо, но уже что-то. Спасибо.

Привет всем
Подскажите кто знает как можно менять шрифт цвета Tgroupbox XE3
почемуто не работает.
На Delphi 7 нормально меняет или это XE3 так задумано?
Заранее благодарен

vcl skins не включал ?

Arioch1
Достаточно и системных тем, что бы половина настроек цвета в VCL отвалилась.

Смотрел "свежее" видео по 3-й бете нуги, - и опять не понимаю какой смысл в ней:
весь код чужой, не олд-скул паскаль, идеология другая, все другое. Только синтаксис старый, но я думаю не проблема вместо ":=" ставить просто "=", а вместо бегинов-эндов - {} и т.п., и так уже приходиться , а все остальное придется ЗАНОВО учить!
Какой смысл в этом костыле в виде RO, - чего одни танцы с бубном по ремоте мосту на мак стоят. Что это за разработка такая с виртуальной машиной?
За те грубо 400 баксов можно собрать хороший хакинтош, и писать на родном objectc, под реальной операционкой.
Кто скажет про плюсы в виде андроида - та же хрень ВСЕ НОВОЕ, ВСЕ не паскалевское, все писать с НУЛЯ! А кростплатформенная либа получиться с такими костылями - мама не горюй!
Нет я больше на ро не смотрю! Это тупиковый путь!

sergionn
Так они и предлагают только язык + среду с интеграцией в какие-то сторонние инструменты. RO, вроде бы, никогда не предлагала ни фреймворков ничего такого (Sugar должен стать первым). У них позиция такая: полная интеграция в платформу и минимум своего.
В этом плане мне больше нравится подход Borland, которые снабдили свой язык фреймворком, который на голову превосходил тогдашние решения в части построения GUI. Наверное и EMB можно так сделать: FireMonkey для кросс-платформы и достаточно умный компилятор для достаточно прозрачного взаимодействия с окружением, чтобы кому надо могли использовать средства платформы для интерфейса.

HeMet
во всех роликах мужик за кадром твердит как мантру - это ваш привычный паскаль, но!
1) это ложь, это уже не тот паскаль, старый код не перенесешь без ГЛУБОКОЙ переработки,
а с нуля я ТОЧНО буду писать на objectc, java, c++, не проблема, и либ всяческих БЕСПЛАТНЫХ на порядок больше
2) единственное достоинство их оксигена - язык похож на паскаль, ВСЕ

Цитата:

а с нуля я ТОЧНО буду писать на objectc, java, c++

Если я одно и то же могу написать на них и на OP, я выберу OP, потому что мне структура языка больше нравится, а заботу обо всем остальном на себя берет RO. Думаю, на это и давят.
Другое дело, что иногда кажется что их Паскаль — это java/objc с begin end и := .

Добавлено:
У кого XE3 с последним апдейтом, можете сказать? что написано в TPlatformWin.RegisterCanvasClasses и TPlatformWin.UnregisterCanvasClasses? А то запостил им багу _http://qc.embarcadero.com/wc/qcmain.aspx?d=112476 , а они не смогли воспроизвести.

EMBO хочет отжать бабло за своё тупиковое решение для разработки под IOS?
_http://now.eloqua.com/es.asp?s=608&e=79603

И тут же сами пишут что скоро будет новый инструмент.
_http://www.embarcadero.com/ru/products/rad-studio/ios-development#!prettyPhoto

Arioch1
это где vcl skins?
вроде такого опцию не трогал