Показать сообщение отдельно
Старый 29.01.2013, 08:26   #25
SS_TKA
Новый Пользователь
 
Регистрация: 17.03.2012
Город: Киев
Регион: Украина
Машина: Alfa Romeo
Сообщений: 4
SS_TKA is on a distinguished road
По умолчанию

Цитата:
Может кто-нибудь покритикует идею, чтобы убрать слабые места
Может уже и поздно критиковать и автор сам все понял, но раз просили...

Насколько я понял из написанного, автор просто вдохновился LUA, а LUA - всего лишь еще одна технология программирования с использованием конфигураций, т.е. вместо LUA можно использовать и xml и ini файлы и UML, spring и т.д. и т.д. сути не меняет, меняются подходы.
Цитата:
Lua быстра, а учитывая то что при первом запуске скрипт компилируется и лежит в памяти готовым-для-запуска, оно вообще летает.
Все относительно... По сравнению с вызовом конструкторов с переданными параметрами "зашитыми" в код классов в C, C++, Pascal и т.д. Lua просто самый последний тормоз Но она не для этого и при правильном использовании ее быстродействие не имеет значения, при неправильном это постоянные тормоза, которые так или иначе будут исправлены до использования.
Цитата:
Основной плюс в том, что фактически оболочка получается с открытым кодом в текстовом виде (за исключением движка конечно же)
Ха-ха И в чем плюс? Что пользователи которые не хотят программировать должны будут копаться не в 20-100 настройках, а править целый скрипт или скрипты? да еще и без отладки и как я понимаю без подробного логирования? Любите искать более менее трудные ошибки в программе без дебагера и логов?
А те кто хотят программировать не смогут, т.к. часть исходников (движок) закрыты (с таким успехом можно считать, почти любую программу, с открытыми исходниками, ведь настройки можно менять ). Да и вообще, что же мешает сделать проект c/без LUA и предоставить исходники раз это такой большой "+"
Цитата:
2. Основа для графики - OpenGL. Решает проблемы с корректным масштабированием, со скоростью отрисовки, но не жрет много ресурсов.
Популярные графические движки, пока слава богу, не жрут память! Память жрут плохие алгоритмы и ошибки
В принципе, конечно идея более гибкого, внешнего конфигурирования, фрон-енда, это хорошо, но только когда уже есть фрон-енд, система логирования работы фрон-енд и хорошая документация, а без этого смысла нет.
И на завершение, есть проект evilcpc, который решает данные задачи (конфигурирования) менее гибко, используя технологию плагинов (не радуемся, как я понял, использовать его из коробки как фронт-енд для стороннего ПО нельзя).
SS_TKA вне форума   Ответить с цитированием