x - devlog :: Создание игр :: Форум :: Independent Games Developers Contests

Ну вот когда зарелизишь сессионку с мультиплеером, реализованную на своём движке без архитектурного планирования на основе KISS принципа, тогда и будет о чём говорить. Пока что я вижу только ля-ля.

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

Всё что угодно будет "нормально с точки зрения поддерживаемости", когда оно уже выкинуто в мусорку и никогда не потребует поддержки :)

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

Опубликовано 18.02.2022 14:29 (3 года назад) #

Какой же ты бред затираешь :) Я тебе привел примеры почему делать как ты - плохо, ты же мне говоришь "сделай хреново и потом приходи". Дурак?

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

Чукча не читатель?

редакция от mv2, 18.02.2022 14:32

Опубликовано 18.02.2022 14:35 (3 года назад) #

mv2, с хамами не разговариваю, проваливай.

Опубликовано 18.02.2022 14:38 (3 года назад) #

Doj написал:
mv2, с хамами не разговариваю, проваливай.

Не обижайся :(
Ты вроде сам совета хотел - вот его и получил, причем от всех отписавшихся в этой теме по сути: не переусложняй.

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

редакция от mv2, 18.02.2022 14:41

Опубликовано 18.02.2022 15:37 (3 года назад) #

mv2, я извиняюсь, если погорячился с формулировками. Мы не согласны в теории, уже давно не называем новой аргументации, и я всячески пытаюсь вывести тебя из теории в реальный мир, в котором всё сложно и неоднозначно.

Совет "не переусложняй" может принимать очень разные формы.

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

Я сейчас выбрал другой подход: минимизировать количество телодвижений пользователя движка в простых задачах, чтобы в условиях конкурса быстрее экспериментировать и получать что-то рабочее. Это упрощение использования движка, но закономерное усложнение того, что под капотом. Однострочники xFont('...').DrawText(''); пишутся и читаются проще, чем ручное создание и использование TFont и TTextLine.

Исходя из опыта того же DGLE: DGLE2 делался с проработкой архитектуры и планированием, и он пришёл на смену "наивному и простому" DGLE1. DRON приводит в пример игру на DGLE2, а не DGLE1.

редакция от Doj, 18.02.2022 15:38

Опубликовано 18.02.2022 15:43 (3 года назад) #

теории в реальный мир, в котором всё сложно и неоднозначно.

Ну я потому и привел свои проекты в пример :) Разве что у меня не было опыта поддержки ПОСЛЕ релиза - вот там дааа, уже свои могут подводные всплыть.

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

А это уже вопрос универсальности :) вот на движке квейка гонки особо не сделаешь например.

А вообще я топил больше за "фреймворковость" движка - в моем даже граф сцены под каждую игру отдельно пилится.

Опубликовано 18.02.2022 19:58 (3 года назад) #

Разу уж тут в суе упомянули меня и DGLE, то я отпишусь :-)
DGLE первый был простой как полено и по сути не являлся движком, а был чем-то вроде SDL но для джунов. В принципе и DGLE2 был не сильно лучше, ну то есть его проблема была в том, что сделать сколько-нибудь высокоуровневый и гибкий движок это реально неподьемная задача для одного-двух людей. Концептуально, до сих пор считаю архитектуру весьма хорошей, но попытка сделать ООП движок, который и в С++ и Delphi и C# работает, что в итоге привело к COM архитектуре и IUnknown compliance. А писать код с такой архитектурой было достаточно утомительно, хотя у меня получалось, но никто кроме меня по сути не готов был на такие жертвы, все хотели либо конструктора, либо синтаксического сахара, либо что-то простое, в исходниках чего они могли бы легко разобраться и расширять, а архитектура DGLE2 нифига не простая. Если интересно, то движок до сих пор доступен тут https://dronprogs.org/#project-dgle
В итоге, я хочу сказать, что если желание реально сделать игру/проект, то в современных реалиях нужно брать тот движок, который максимально подходит твоим ценностям. Для меня вот, по сути, Defold это то, каким должен был стать DGLE.
А если хочется делать свои технологии, то надо делать максимально по KISS и чтобы самому было по кайфу. Я могу выложить архивчиком (раз уж репозиторий пока приватный) то, что я написал этим летом, оно сильно отличается от того как я делал раньше. Но даже тут, ч вот столкнулся с тем, что поддержка OpenGL (WebGL), Metal и DX12 (что по сути есть все основные рендеры), то даже это почти неподьемная задача. А я еще хотел консоли подержать, благо есть доступы ко всем девкитам, но это еще как бы все усложняет. В прочем, все еще в моих мечтах я сделаю такую либу )

Опубликовано 18.02.2022 20:05 (3 года назад) #

Отдельно хотел дать некоторые комментарии по твоему коду примеров, что ты выкладывал:
>xFont('font.ttf@16 outlined=3').Pos(10, 300).DrawText('Hello World!', []);
Кажется, что если всегда в стринге таскать кегль и шрифт не очень круто. В этом случае не понятно как контролировать ресурсы, как происходит менеджмент ресурсов? Программисту не будет понятно когда шрифт создается, ведь я могу просто где-то написать xFont('font.ttf@20 outlined=3')... и это приведет к пересозданию шрифта. Короче имхо будет путаница.

>Главное, что нужно понять: перевод — это функция
Это плохое решение. Единственный нормальный вариант это использование ключей и json/xml/что угодно для хранения переводов.
Например:
SetLocale("ru-ru");
xFont('font.ttf').Pos(10, 300).DrawText('$hello_world$', []);
Ну и где-то в конфиге
<en-us>
hello_world = "Hello World"
</en-us>
<ru-ru>
hello_world = "Привет Мир"
</ru-ru>

>Fluent Context
Вот это классная идея!

редакция от DRON, 18.02.2022 20:07

Опубликовано 18.02.2022 21:02 (3 года назад) #

>xFont('font.ttf@16 outlined=3').Pos(10, 300).DrawText('Hello World!', []);
Кажется, что если всегда в стринге таскать кегль и шрифт не очень круто. В этом случае не понятно как контролировать ресурсы, как происходит менеджмент ресурсов?

Под капотом там менеджер ресурсов с дедубликацией. Т.е. даже если написать в нескольких разных местах 'font.ttf', 'font.ttf@20 outlined=3', 'font.ttf@16 outlined=3' и 'font.ttf@16 outlined=3 blablabla garbage', файл font.ttf будет загружен один раз, и атласы расшарятся между разными вариациями.

Итоговые расходы на этот способ в сравнении с честным созданием TFont: запрос к хештаблице в рендере для поиска нужного TFont. Т.е. с практической точки зрения ни о чём.

Для избежания путаницы ничто не мешает объявить и использовать глобальную константу MAIN_FONT = 'font.ttf@16 outlined=3' или честно создать шрифт через TFont.

Это плохое решение. Единственный нормальный вариант это использование ключей и json/xml/что угодно для хранения переводов.

Мне кажется, ты не совсем понял что я сделал. У меня переводы хранятся в lua скриптах и позволяют любые трансформации делать. Вот json или xml с фиксированными строчками -- это плохое негибкое решение.

редакция от Doj, 18.02.2022 22:42

Опубликовано 18.02.2022 23:20 (3 года назад) #

COM архитектуре и IUnknown compliance

Так причем тут COM? У тебя интерфейсы в системе регистрировались? Или ты все классы с vtable com считаешь? :) Понятно что железная наследованность от IUnknown из за делфи, но ком тут не причем совсем)) Один раз IUnknown реализовал и усё, можно даже QueryInterface не реализовывать, Delphi только с as его вызывает если не ошибаюсь.

благо есть доступы ко всем девкитам, но это еще как бы все усложняет.

К каким если не секрет? Просто интересно насколько отличаются хоумбрю девкиты от официальных. Особенно xbox360 если такой у тебя есть.

Для избежания путаницы ничто не мешает объявить и использовать глобальную константу MAIN_FONT = 'font.ttf@16 outlined=3' или честно создать шрифт через TFont.

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

редакция от mv2, 18.02.2022 23:25

Опубликовано 18.02.2022 23:49 (3 года назад) #

А вообще я топил больше за "фреймворковость" движка - в моем даже граф сцены под каждую игру отдельно пилится.

Нужен баланс. Чисто фреймворк не решает многих проблем. Та же дедубликация ресурсов, когда на карте 100 врагов, которые используют 5 текстурок.

Я введу систему алиасов, если посчитаю это полезным (типа xAliasFont('main', 'font.ttf@16 outlined=3') и дальше использовать 'main'), но пока что не хочу этим переусложнять, т.к. есть альтернативные варианты. Что не так с глобальной константой? Это способ объявить параметры шрифта в одном месте с использованием во многих местах с проверкой в compile-time правильности написания идентификатора.

Опубликовано 19.02.2022 01:03 (3 года назад) #

Та же дедубликация ресурсов, когда на карте 100 врагов, которые используют 5 текстурок.

А ты глянь как эта проблема решена у меня в игре :)
В код любой сущности зайди(монстр, пикап). Подсмотрел у дедов(half life).

Что не так с глобальной константой

Ну тогда не совсем понятно в чем отличие от экземпляра TFont, который где нить в инициализации создан с нужными параметрами?=

Опубликовано 19.02.2022 01:39 (3 года назад) #

А ты глянь как эта проблема решена у меня в игре :)

Ну, то есть вообще никак не решена. Тупо хардкод глобальных переменных pAmmo, pHealth, pQuad и дальше вот такой вот ручной ужас:

Mesh mesh = ItemType == ItemType.Ammo ? pAmmo : (ItemType == ItemType.Health ? pHealth : pQuad)

Я не говорю, что тут нет дедубликации, я говорю, что твой _фреймворк_ не даёт никакого решения проблеме, и _программисту_игры_ нужно менеджить ресурсы вручную для каждого нового _контента_.

Мне это не подходит.

TFont нужно где-то объявить, где-то отдельно вызвать конструктор с нужными параметрами уже когда движок проинициализирован. Константа объявляется в одну строку в одном месте.

редакция от Doj, 19.02.2022 01:44

Опубликовано 19.02.2022 08:05 (3 года назад) #

Ну, то есть вообще никак не решена

Да вообще)) Я хз чем ты смотрел код, там есть метод Precache который вызывается в конструкторе энтити, который если нужно подгружает ресурсы. Игра уровневая - там будет очень хреновым тоном при каждом спавне пикапа перезагружать модельку, или когда игрок убивает всех монстров в перерыве между раундами, а затем игра снова их спавнит.

А как бы ты решил проблему постоянного стриминга ресурсов с диска? Добавил бы какой нить флаг ResourceFlagPersist а при выгрузке вызывал бы UnloadPersistent? А как бы интегрировал это в уже готовую ресурсную систему завязанную на рефкаунтах(если ты конечно не вручную управляешь ресами)? Не забывай что система ресурсов скорее всего построена на слабых ссылках, и хукать _Release и проверять есть ли у ресурса флаг - тоже не очень хороший тон. Тут всё ещё остаётся много нюансов.

Mesh mesh = ItemType == ItemType.Ammo ? pAmmo : (ItemType == ItemType.Health ? pHealth : pQuad)

Я не хотел дублировать стопицот классов на каждый тип пикапа(их всего три), в этом нет никакого смысла. В Projectile тоже самое - только там параметры пули/ракеты "data-driven", а не миллион предков типа Bullet, Rocket, SuperMegaRocket, UltraRocket, ну ты понял короче, а основной критерий - прожектил разрывной или просто пулька.

У нас с тобой видимо чуть разное мышление просто - твоя мысль в том что должно быть больше мелких конкретных классов сущностей(ну или возможно data-driven подход) унаследованных от какого-то базового, моя же в том что брезговать стейтами в пределах отдельного супер-класса(снаряда например) не стоит, иногда это удобнее чем поддерживать 100500 предков и смотреть че там сломалось у них в виртуалах.

Создай синглтон по типу TUIStyle?

редакция от mv2, 19.02.2022 08:09

Опубликовано 19.02.2022 08:13 (3 года назад) #

Вот кстати нашёл пост свой с гдру:

Если задаться целью, то можно и что покруче запилить. Я, например, пилил за 3-4 дня двигло с простеньким сценграфом, системой сущностей, звуком, были зачатки мультирендера. Рендер был простенький ффп, динамический батчинг(тормозной), фрустум куллинг, куллинг с исчезновением по дистанции, морфинг. Материалы юзали комбайнеры, с системой слоёв. Умел рендертаргеты. Тени не умел, скиннинг по какой-то причине не прикрутил.

Забыл ещё что движок искаробки имел крутой менеджер ресурсов, но был в одном потоке(временно). Например:

class TextureLoader : AbstractLoader<ITexture>

{

  public TextureLoader(ResourceManager instance) : base(instance) {}



  public ITexture RequestLoad(Stream asset, string name)

  {

     ...



     return Resources.Engine.GraphicsPipeline.Device.CreateTexture(data);

  }

}

Хотел прикручивать стриминг по приколу, но не пошло. Алсо хотел запилить простенький мультиплеер на TCP, но это тоже осталось "в мечтах".

Система сущностей, как и почти всё в движке строилась на рефлексии, например:

class Light : Entity

{

  public override void OnSpawn()

  {

    Halo = Engine.Resources.Load("textures/halo.png");

  }

}



...



Engine.Scene.Spawn("Light");

Скриптинг был на любом .NET языке, который двигло компилировал на лету, возможен был даже хот релоад. Всё это за ~неделю было запилено.

Опубликовано 19.02.2022 09:03 (3 года назад) #

Ну да, тогда ок, правда хочется просто создать объект и дальше го использовать, а не обращаться каждый раз через ф-ю/конструктор со стрингой. Меня это чисто даже визуально немного коробит.
Забыл в прошлый раз написать, хотел еще добавить что UTF-8 прошлый век, сейчас намного лучше использовать везде сразу UTF-16 не париться, UTF-8 же только больше проблем создает. Все операционки уже UTF-16 под капотом используют со времен Windows 8 кажется, так что смысл движкам гнаться за сомнительной экономией памяти? Ты передавая стринги (константные массивы чаров по факту, но не суть) в функции типа xFont, больше потеряешь производительности, чем от перехода с UTF-8 на UTF-16.

Это я как раз понял и это как раз плохо и неудобно на мой взгляд. Обычно же переводы отдают на сторону и они воспринимаются как набор строк, а логики там совсем не должно быть. То есть идеально просто иметь key - value массив. В коммерческих всех играх, что я видел и как мы в студии работаем, то это именно так. Если надо иметь возможность подставлять в текст значения, менять св-ва текста внутри строки и тд, то используется html like тэги и все, переводчикам это не мешает, у тебя же это lua скрипт с нагромождением ифов, свичей и какой-то логики. Ну и я просто не вижу смысла в этом. На быстродействие это тоже хуже сказывается, тем более, что если язык зафиксировать на старте приожения, то все значения ключей можно просто закешировать, со скриптом так не получится.

Опубликовано 19.02.2022 09:25 (3 года назад) #

Регистрировать в системе и не обязательно, обязательно поддерживать методы IUnknown, возвращать всегда E_RESULT, поддерживать систему GUID дурацкую, необходимость для строки использовать только const char* и что-то еще, дело было давно, не помню. В общем, это было основным архитектурным просчетом. Очень неудобно получать результаты работы ф-и через запись в переменную по ссылке, что приводило к геморрою в виде необходимости заводить кучу ненужных локальных переменных. Вот пример, а раз уж мы тут про шрифты, то пример вывода какого-то текста в примерах движка

char res[16];

		sprintf_s(res, "%u", _uiScore);



		uint w, h;



		_pFnt->SetScale(_fSize);

		_pFnt->GetTextDimensions(res, w, h);	

		_pRender2D->SetBlendMode(BE_NORMAL);

		_pFnt->Draw2D(_stPos.x - w / 2.f, _stPos.y - h / 2.f, res, ColorWhite(255 - _uiCounter * 5));

а по идее это все могло выглядеть, например так, если бы не было COM compliance:

TVector2 size = _pFnt->GetSize(toString(_uiScore), _fSize);

_pRender2D->SetBlendMode(BE_NORMAL);

_pFnt->Draw2D(_stPos.x - size.x / 2.f, _stPos.y - size.y / 2.f, toString(_uiScore), ColorWhite(255 - _uiCounter * 5));

Вроде и не такая большая разница, но по факту, постоянная необходимость конвертировать в массив char строки и заводит кучу временных переменных бесило ужасно. Первый DGLE был популярным, потому что там можно было быстро что-то наговнякать и оно работало, а тут надо было писать больше кода. При этом, до сих пор считаяю что плагинная архитектура, изоляция рендера, собственный микшер звука и куча других вещей были сделаны реально круто. Работа с окном и консолью, например, является образцовой даже по меркам больших коммерческих движков, в том же Unity это хуже сделано и имеет разные проблемы, которых был лишен DGLE2.

PS4, PS5, XBox One, XBox Series, Nintendo Switch, мы на все эти платформы разрабатываем. Под PS4 и Nintendo Switch мне довелось пописать рендер на C++, остальные так -- просто посмотрел, че как там устроено, благо у нас все на Unity и он хорошо абстрагирует от низкого уровня. Ну и официальные девкиты и SDK не имеют ничего общего с Homebrew от слова совсем )

Вот это, кстати яркий пример отсутствия архитектуры и DDD (Data Drive Development) подхода, ну типа да, на DGLE1 это вот так же и выглядело примерно, но это уже не KISS, это просто хардкод. В DGLE1 архитектуры то ведь тоже не было никакой :-) Я помню 3d[Power] меня тогда троллил, что мой движок это просто компиляция разных семплов в одну кучу, ну примерно так оно и было.

Mesh mesh = ItemType == ItemType.Ammo ? pAmmo : (ItemType == ItemType.Health ? pHealth : pQuad)

Опубликовано 19.02.2022 09:32 (3 года назад) #

Doj Сейчас, кстати вообще вся эта мода вокруг ECS, я вот думал в своей либе что писал летом именно на это и сделать ставку. У нас в компании своя ECS для Unity написана, которая еще и из коробке умеет все по сети синхронизировать. У нас даже несколько компаний купили коммерческую лицензию так сказать на продукт, так как он для Unity уникален. Подумай, у себя тоже что-то такое сделать.
И где можно, кстати на твои исходники посмотреть и движок пощупать?

Опубликовано 19.02.2022 09:45 (3 года назад) #

поддерживать систему GUID дурацкую

Тут ты что-то упустил видимо, в Delphi легко можно любые плюсовые интерфейсы унаследованные от IUnknown юзать, HRESULT совсем не обязателен(если это не VCL). В шарпе тоже(см. Marshal). А гуиды(и QueryInterface) юзается только если приводить интерфейс as'ом. Хотя могу и ошибаться.

Очень неудобно получать результаты работы ф-и через запись в переменную по ссылке, что приводило к геморрою в виде необходимости заводить кучу ненужных локальных переменных

А вот это да :) Мне тоже не нравится такое.

Вот это, кстати яркий пример отсутствия архитектуры

Скачай архив и посмотри сам, там вполне себе неплохая архитектура в целом. Я уже описал почему я решил так сделать с пикапами.

Топишь за DDD, но казус в том что никакого DDD ни в одном из твоих публичных проектов нет :)

на DGLE1 это вот так же и выглядело примерно, но это уже не KISS, это просто хардкод

DGLE1 был оберткой над огл которая даже стейты не умела сама контроллировать, нужно было вызывать чото типа SetShadowSampler, SetTextureCombiner или как то так :) Особенно повеселило начистую скопипащенный класс фрустума.

Сравнение с твоим движком некорректно, код там явно лучше большинства твоих хоум-проектов, я гарантирую это :)

редакция от mv2, 19.02.2022 09:47

Опубликовано 19.02.2022 19:27 (3 года назад) #

А как бы ты решил проблему постоянного стриминга ресурсов с диска? ... А как бы интегрировал это в уже готовую ресурсную систему завязанную на рефкаунтах(если ты конечно не вручную управляешь ресами)?

Есть объект-холдер (например, TFontHolder или TTextureHolder), который держит ресурс и выполняет всю тяжёлую работу по загрузке и подготовке ресурса к использованию. Холдер находится внутри менеджера ресурсов и недоступен напрямую пользователю движка.

Он хранит количество ссылок на себя, причём ссылки имеют разные приоритеты. Пока что есть только два приоритета: PRIORITY_REQUIRE для ресурсов, которые нужны немедленно и заблокируют рендер пока не будут загружены, и PRIORITY_NORMAL -- для ресурсов, которые потребуются когда-то потом. Ресурсы с PRIORITY_NORMAL могут грузиться в фоне в отдельном потоке. Добавлю другие приоритеты, если в них появится необходимость, но пока что этих двух хватает.

Есть объект-ссылка (например, TFont или TTexture) -- это уже интерфейс для пользователей ресурса. Когда TTexture создаётся, в соответствующем TTextureHolder увеличивается счётчик ссылок, когда уничтожается -- счётчик ссылок уменьшается. Пользователь ресурса может поменять приоритет: например, когда объект на уровне невидимый, его текстуре можно выставить PRIORITY_NORMAL, а как только он становится видимым, -- PRIORITY_REQUIRE.

Есть квоты на занимаемую память. Как только квота исчерпывается, менеджер ресурсов пытается найти и освободить ресурсы без пользователей (т.е. с 0 ссылок). Пока что я не попадал в ситуации, когда этот механизм был бы необходим.

Описанное уже реализовано в DEng и опробовано на практике. Вот пример игры (сделанной на джем):
https://ooyoot.itch.io/al-dente

Всё по DDD. Уровень со всей логикой грузится из специального файлика, ресурсы ставятся в очередь на загрузку в той последовательности, в которой они появятся в игре, в итоге когда игрок заходит в очередную новую локацию, в ней уже всё прогружено.

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

Да вообще)) Я хз чем ты смотрел код, там есть метод Precache который вызывается в конструкторе энтити, который если нужно подгружает ресурсы.

Precache -- это код игры, а не фреймворка. Фреймворк с его MD2Model никакого решения дедубликации и вообще менеджмента не предлагает.

Сейчас, кстати вообще вся эта мода вокруг ECS

Я делал нечто похожее в одной игре лет 13 назад, но в те времена это называли Decorable+Decorators паттёрном :)

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

Но когда ещё и сам вручную должен писать код всех этих компонентов и их взаимодействий, затраты времени на написание служебного кода вокруг основной логики не оправдают себя ИМХО.

В любом случае, я внедрять ECS (или декораторную) архитектуру в DEng или x точно не буду.

И где можно, кстати на твои исходники посмотреть и движок пощупать?

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

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

Всё получится, строковые константы у меня также поддерживаются наравне с функциями:

lua_getglobal(L, @S[1]);

  if lua_type(L, -1) = LUA_TSTRING then begin

    Result := AnsiString(lua_tostring(L, -1));

    lua_pop(L, 1);

    Exit;

  end else if lua_type(L, -1) = LUA_TFUNCTION then begin

    // ... pcall

  end;

Любые политики кеширования реализуемы, если возникнет проблема с производительностью (например, можно перебрать глобальные переменные скрипта, и те из них, что строки, как-то закешировать, что бы это ни значило). Закешировать результат функции с заданными параметрами тоже возможно.

Страница 2 из 3

Перейти на форум:

Конкурсы

Открытые конкурсы:

Активных нет

Недавние конкурсы:

Случайная игра

Мини-чат

Вам необходимо залогиниться.

Архив чата