Классы в скрипте
Понадобилось использовать классы, которые объявляются в создаются в скрипте. Так как в стандартной версии такого нет, был реализован "на коленках" наследник TfsScript с нужным функционалом.
Имеет ли смысл развивать этот проект, или в будущем всё же появится реализация классов в скрипте ???
Имеет ли смысл развивать этот проект, или в будущем всё же появится реализация классов в скрипте ???
Комментарии
Я задавал этот вопрос разрабам, они сказали что очень заняты.
Реализовать можно, но ничего общего с классами Delphi они иметь не будут и поэтому их можно будет использовать только в скрипте, в программе нельзя.
Можно легко использовать записи (record), учитывая что запись-простейший класс, хотя можно подумать и о реализации самих записей.
Я и говорю скриптовые классы в программе использовать нельзя, только в скрипте.
Насчет записей попробуйте такой код, он не прокатывает:
addClass(TPoint,'');
Архив повержден
Demo.rar - неожиданный конец архива
файлообенник
У меня масса логики реализовано в скриптах, возможность использования собственных структурных типов была бы чрезвычайно полезной.
Реакция разработчиков непонятна.
Напиши здесь как можно использовать записи как классы, архив открыть не могу.
Мы практически ничего не можем сделать с такими классами, не переопределить методы, а уж тем более наследоваться от абстрактных классов.
Это фактически просто красивая обертка для объединения переменных.
То же самое и структуры, обычно когда просят добавить структуры в скрипт, имеют введу не обертку для доступа к переменным того же скрипта, а обертку для реальных структур, чтобы можно было использовать функции со структурами в качестве параметров для внешних функций. Что сделать на автоматизме не возможно, структуры это область данных доступ к которой осуществляется по смещению, которое считает компилятор.
А объявления в скрипте никакого функционала не добавляют, кроме "красивого" кода
Реальное - например использование FastScript для выполнения программ написанных на Delphi, уменьшение повторяющегося кода.
>Мы практически ничего не можем сделать с такими классами, не переопределить методы, а уж тем более наследоваться от абстрактных классов.
Если вы смотрели демку, то в первом наследовании это реализовано
>Что сделать на автоматизме не возможно, структуры это область данных доступ к которой осуществляется по смещению, которое считает компилятор.
Запись - это тот же класс без свойств и методов. Реализовав классы - легко реализуются структуры
Не в упрёк будет сказано, но FastScript остановился в развитии. Я понимаю, что он написан для FastReport и выполняет практически все его потребности, но раз уж вы позиционируете его как отдельный продукт стоит ли останавливаться на достигнутом ? Мне кажется многие бы хотели иметь в приложении полноценный Delphi-Scripter. Сделал Script.LoadFromFile('MyForm.pas') и всё работает. К тому же скорость FastScript ну совсем уж не Fast (
Смотрел, я говорю не про доступ к полям предка, а про виртуальные функции и vmt.
Т.е. чтобы работала такая конструкция(а так же возможность вызова inherited).
Иначе все это сводится до красивой обертки данных, о чем я и говорил.
В скрипте, да. А я говорю об обертке между кодом Delphi. Т.е. AddRecord(TRect) - невозможно, у TRect нет rtti.
Скрипт компилируется в промежуточный XML, следовательно , чем больше код скрипта, тем дольше время исполнения.
К слову последние версии скрипта немного оптимизированы и исполняют большие скрипты быстрей чем предыдущие версии.
Для FS на данный момент можно сделать многое, если его переключить на новый rtti D2009-XE, т.е. автоматическое добавление всех динамических методов, событий , без AddEvent итд. Вот только теряется поддержка младших версий Delphi у которых бедный rtti.
И это "К тому же скорость FastScript ну совсем уж не Fast" ложь. Всё работает как надо если запускать скомпилированный предварительно скрипт. FastScript делает компиляцию в xml и потом уже её выполняет. Так вот, компиляция действительно не быстрая, но там как-бы скорость и не нужна...
Тогда может я что-то пропустил ? Это всё уже реализовано ???
Простой тест доказывает обратное, у меня FS выполняет 30 секунд, а Delphi меньше 1
Никто не задумывался над вариантом компилировать код обычным delphi-компилятором, который генерирует машинный код? Компилировать pas файлы в библиотеки (dll) или приложения (exe) и запускать их из памяти?
В таком случае скорость работы будет идентична обычному приложению. (естесственно после компиляции, когда копия машинного кода уже в памяти)
p.s. архив все равно битый. Может стоит заархивировать его zip?
p.s.s. ответ на вопрос - да, конечно стоит.
Например, в моем случае - объем не имеет значения, важна только скорость работы откомпилированных скриптов. (сервер ММОРПГ игры обслуживающий миллионы пользователей)
Распространение компилятора со своим приложением - нарушение лицензии, т.е. пользоваться таким скриптом могут только те, кто купил Delphi.
К слову для игр, компилятор Delphi далеко не самый лучший выбор. Текущие версии поддерживают простой набор команд x86, т.е. ни о какой оптимизации see или даже простого mmx и речи не идет. В вашем случае лучше использовать связку VC++ и Lua, и не ждать от интерпретатора, предназначенного в первую очередь для работы с отчетной системой компилируемого кода
Вот в том то и дело, что народ часто путает тёплое с мягким...
Начинают тестировать производительность, смаковать синтаксис, цокать языком на отсутствие языковых конструкций, хотя на самом деле делают это по сути от безделья. Не замечая, что "тормоза" движка совсем не тормоза, если рассматривать картину по решаемым задачам в целом и сравнивая производительность других модулей, участвующих в решаемой технической задаче или их комплексе. Например нагруженная БД гораздо более существенный "тормоз"...
Что лучше для игр - личное мнение каждого (на мой взгляд: любой проект можно написать на любом языке, на том же уровне производительности, вопрос только в затраченном времени и усилии), у меня контролируется производительность каждой функции, каждого оператора, если появляется узкое место - всегда находится способ это исправить, в очень исключительных случаях приходится делать ассемблерные вставки.
Да, народ может и путает, но в моем случае БД используется только для постепенной загрузки данных в кеш-сервер, и дальше работа с кеш-сервером (также периодический дамп данных в БД обратно). И узкими местами в данный момент являются - количество поддерживаемых соединений, более 33000 пока не удается и вся нагрузка идет на процессор, который обрабатывает tcp-ip соединения. А если часто используемые скрипты тоже будут кушать процессор, то количество соединений еще больше упадет. Да, 33000 очень высокая цифра, но на нее никто и не ориентируется, в нашем случае достаточно будет 5000 игроков на 1 сервер, но тем не менее важно определить на сколько сильно влияет на производительность в целом каждый элемент системы.
Скрипты очень хорошо подходят для "квестов" (заданий). Но слабо подходят для реализаций интеллекта NPC, которых одновременно на сервере может находится более 10.000. Хотя мне был бы интересен вариант вынести логику NPC в скрипты и дать возможность сторонним разработчикам пробовать выстраивать свою логику, к тому же это полезно будет, если движок будет переносится для другой игры и логику придется менять.
Еще скрипты полезны тем, что многие обновления можно реализовать без перезагрузки сервера, это очень удобно
Ладно, не буду навязывать свои проблемы Кто ищет работу - есть вакансии (Киев)
Просто если приложение оперирует большим потоком данных такими, как вектора и координаты, то лучше выбирать компилятор поддерживающий хотя бы mmx. Естественно все выбирается под конкретную задачу.
Насчет ассемблерных вставок, разве делфийский asm может обрабатывать команды mmx/sse (movups/movq/CVTPD2PS/CVTPD2DQ) ?
У меня он бывало и более простые инструкции x86 не принимал.
Так же возможно облегчить работу скрипта, к примеру перенести честь нагрузки на функции/классы приложения и использовать их в скрипте.
Но это уже часть реализации.
DimaBr
Методы теперь вызываются, но вот полиморфизма нет.
Т.е. у вас жестко привязывается к типу объявленной переменной, а не созданного класса.
Достаточно поменять объявление Test2: TTest2 на Test2: TTest :
и функции у вас почему-то не работают: