Написание скрипт движка для игры (Delphi)

Интересуют на данный момент такие вопросы:
Можно ли сделать так чтоб из скрипта можно было обращаться к переменным программы по их имени.
Я конечно понимаю, что при компиляции все лишнее выбрасывается и оптимизируется. Но небось есть же способ узнать  Новые имена переменных, чтоб их сопоставить как -то со старыми и к ним обратиться.
К примеру есть у меня глобальная объект Win
в скрипте чтоб можно было написать вот так
Win.Visible False

Kavis
Не во всех языках есть reflection. В це# и в жабе есть, а в цэпэпэ - теоретически можно сказать что есть.

в Lua можно переопределить __index и __newindex для глобальной таблицы
на днях (может даже сегодня) выложу библиотеку (как раз для Delphi), которая позволяет качественно взаимодействовать с Lua

DevilDevil
Жду

http://www.gamedev.ru/projects/forum/?id=140784

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

Вот, я пишу на досуге свой двиг, посмотри на мой класс хеш таблицы (она кстати динамическая):

http://code.google.com/p/orionphp/source/browse/trunk/libs/HashList.pas

DevelS
А можно небольшой пример как работать с этим модулем, чтоб чисто начать.

DevelS
внутри Lua - очень хорошие хеш-алгоритмы

что касается конкретно моей реализации (вышеупомянутая CrystalLUA) - то хеш алгоритм там ещё лучше )
всё написано на ассемблере, быстрые бинарные поиски, быстрые сравнения строк )

но библиотечка ничо так )
если хочешь поделюсь своими алгоритмами (хешпоисками и хеш по строкам) - я в своё время долго над этим думал )
реализовал просто )

DevilDevil
> внутри Lua - очень хорошие хеш-алгоритмы
Какие? :)

>что касается конкретно моей реализации (вышеупомянутая CrystalLUA) - то хеш алгоритм там ещё лучше )
Математически показал, что коллизий меньше? :)

> всё написано на ассемблере, быстрые бинарные поиски, быстрые сравнения строк
Сравнение строк от конца к началу - не кеш френдли. Префетчер на core умеет следить за 12 потоками "вперед", и только за 4 потоками "назад".

RPGman
я тут тестировал его на 1000 похожих строк и ужаснулся - один и тот же хеш мог пог повторяться по 7-8 раз
пришлось усовершенствовать алгоритм и на 1000 похожих строк повторения были 2 раза максимум
но это на похожих строках. и на 1000. на непохожих вероятность коллизии меньше

поиск не от конца к началу и не от начала в конец, а с конца и начала к середине
таким образом 100 хешей перебираются за 7 итераций. 1000 - за 10.
бинарный поиск ёп )

одна хеш запись - 8 байт (хеш и указатель/ID)
даже если в твоём классе будет 20 свойств/методов, то хеш таблица занимает 160 байт, что вполне укладывается в кеш )

DevilDevil
> поиск не от конца к началу и не от начала в конец
Я не про поиск. Я про вот это:

function SameStrings (const S1, S2 : string) : boolean; overload;
...
@loop_dword:
   mov ebx, [eax + ecx*4 - 4]
   cmp ebx, [edx + ecx*4 - 4]
   jne @exit_false_pop
   dec ecx
   jnz @loop_dword
...
end

это сравнение строк
у свойств и методов есть обыкновение быть маленькими. кроме того я думаю S[1] и S[50] будут в одной кешированной странице. Не ?
ну и проверка на равенство тут не побайтовая, а по возможности по 4 байта

так что должно быть быстро
значительно быстрее чем какой-нибудь strcomp()

DevilDevil
> кроме того я думаю S[1] и S[50] будут в одной кешированной странице. Не ?
Только при условии выравнивания начала строки на размер кеш линии - 64 байта большинстве современных x86 (всех?)
Прыжок в конец строки из 50 символов практически наверняка даст промах.

> ну и проверка на равенство тут не побайтовая, а по возможности по 4 байта
>так что должно быть быстро
При условии, что "у свойств и методов есть обыкновение быть маленькими", то код, который сначала пытается сравнить байты, потом сравнивает двордами, читаемыми по невыравненным адресам, это офигенский тормоз против тупого побайтового strcmp().

RPGman
я тебе не верю )

где взята инфо ?

Ну, райнтайм скрипт движка вполне может работать с своей программы, так в чем проблема?