Forum.iFiction.Ru

Retran написал:

Eten, вы бы хоть чего-нибудь почитали и хотя бы с терминологией разобрались. Вы API от байткода отличаете?

В общем, мнение:
а) Проект не нужен, так как все это уже есть (см. Glulxe тот же).
б) Все равно не взлетит.

Retran, вы хотя бы проявили уважение к теме и прочитали ее до конца? По моему, так нет. Раз так, то читайте:

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

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

И на будущее, Retran. Есть сущевственная разница между виртуальным проигрывателем в рамках ИЛ и виртуальной машиной общего назначения. Раз вы пытаетесь сравнивать Gluxe (огромное и большое по возможностям ПО с т.з. вирт. машины) с вирт. проигрывателем (что значительно меньше по возможностям вирт. машины и специализированнее), то вы явно не разбираетесь в данном вопросе. И в данном случае, Glulxe , как раз наоборот не подходит для этих задач (уж проще на QSP с URQ писать). Да и у меня большие сомнения, что ваши доводы имеют смысл, хотя не стану оспаривать правоту вашего мнения, основанного на тенденции большинства "печальных" результатов. Однако, не все крутится вокруг них.

Насчет API и байткода. Смысл и суть самого API реализуется в моем проекте, при этом разработчики внешних языков (QSP, URQ и т.д.) абстрагируются от реализации уже всем известных функций, методов и прочее касаемое особенностей ИЛ, к тому же интерфейс и возможности проигрывателя определяются только на момент проигрывания квеста (отсюда и идет виртуализация). А для простоты хранения и обработки команд API, они реализованы на уровне низкоуровневого псевдоасемблерного кода (т.е. проигрыватель воспринимает готовые команды). Так что, на мой взгляд, я учел все факторы (хотя не все здесь упомянул), чтобы упоминать заявленные вами термины и полагать их уместными в своем проекте "Неоргек".

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

Отредактировано Eten (27.08.2010 22:11)

да дайте уже ему разрешения, и пусть пишет что хочет.

--

а посты зря скрыл.

Предполагаю что этот проект станет проекцией подхода .NET на плоскость РИЛ и его ждет успех Windows .NET.

P.S. добавил слово Windows.

Отредактировано Ntropy (28.08.2010 04:28)

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

Nex написал:

Получить одобрение Байта и Корянова(кстати, почему именно создателя досурки, а не первой рипурки? а может акурки или фурки?) можно и по e-mail.

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

И я что-то не заметил, что fireton согласился бы на выдачу исходников по своей фурке, из которой можно взять код исполненения языка URQL и перенести его на платформу в ее понятиях, соблюдаю принципы действия и прочее языка. И к тому же я хочу получить это согласие офиально, чтобы потом не выкореживались с тем, что я типа не давал такого согласия. Т.е. все по честному, мне дают исходники по языку, чтобы я знал как это должно работать и смог это повторить на языке платформы. Вот поэтому я эту тему и написал.

Сомневаюсь, Этен, что ты разберёшься в исходниках фурки. А "как оно должно работать" можно легко узнать, посмотрев описание URQL + фуркин readme.

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

И я не очень понимаю, что Этен хочет там смотреть. "Как должно работать" можно почитать в описании URQL, а мои решения ему, боюсь, не упёрлись никаким боком.

"...это продолжается уже четвертый год"
"...поэтому откланяюсь на месяц"
Да, до новых встреч))

Retran написал:

Eten, на ваши доводы отвечать не буду, ибо даже не знаю, что мне на это ответить.

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

Так, вот литература, которой я пользуюсь (ссылки увы дать не могу, т.к. давно их растерял и не помню где нашел):
1) В.А. Серебряков "Лекции по конструированиё компиляторов", Москва, 1993. (у меня только распечатка, электронку посеял)
2) А. Е. Пентус, М. Р. Пентус, "Теория формальных языков", учебное пособие, МГУ имени М. В. Ломоносова, Москва 2004.

Это единственные книги, которые у меня есть и к которым я обращаюсь по сложным вопросам. Также могу по рекомендовать все, что находится в яндексе по ключевым словам "+компилятор +транслитератор". Т.к. на текущий момент, в рунете уже есть сайты с хорошим материалом, хотя бы для чтобы въехать в тему (см. по ключевым словам). Были и другие материалы на начальном этапе в 2007 году, но со временем я их освоил и перестал хранить у себя, а щас уже не помню где их находил, но полагаю, что весь этот материал можно найти на любом сайте по данной тематике. К слову, сам начинал изучение с разбирания на практике лексического анализатора, синтаксический и семантический анализаторы строятся проще, но там свои фишки. Создание конечного результата не составляет проблемы, т.к. этот процесс всего лишь получение объектной модели из входящего кода (банальное сравнение - это постройка древовидного интерфейса). В последствии эту модель можно интерпретировать или компилировать. В таком порядке я могу, на собственном опыте, рекомендовать освоение этой темы.

В довесок, все же открою доступ к чтению, уже сформировавшейся информации по проекту "Неоргек", по этому адресу. Там можно найти описание проекта (см. раздел Документация) и некоторые статьи, почти доработанные по основам проекта, на которых будет строиться вся реализация языков на нем (см. раздел Разработка). В разделе Руководство, пока будет пусто до первого релиза. Делаю примечание, что раздел Разработка создан для готовящихся страниц вики и информация поставляется "как есть", но по крайней мере у вас есть возможность ознакомиться с некоторыми моментами в моем проекте. И кстати, я пока открыл только возможность чтения для гостей.

Полагаю, что данный пост дает вам настолько исчерпывающий ответ, насколько я его способен дать на данный период.

Отредактировано Eten (29.08.2010 09:13)

Ах да, не забудьте напомнить Oreolek, чтобы он острожнее писал про открытость кода насчет URQ.

Список платформ с открытым кодом я писал в вики, он проверен. Но по сабжу у меня есть три вопроса.

1. А вот как с поддержкой Милены, INSTEAD и QuestBox?
2. Как показывает практика (см. модуль URQ для INSTEAD), вариантов URQ - просто море. Игры писались под досурку, игры пишутся под FireURQ. Предугадать все грязные хаки - невозможно. Хотя бы потому, что одни игры управляются с клавиатуры, а другие требуют использовать мышь. Есть ли какие-нибудь реальные идеи унификации или просто "я хочу сделать универсальный проигрыватель"?
3. Почему я должен буду удалить с компа QSP\URQ и поставить Этот Замечательный Проигрыватель? Пожалуйста, два варианта ответов - как игроку и как автору.

Есть такая штука, как ScummVM. Её ставят и ей пользуются, потому что она позволяет легко и удобно играть в старые игры под DOS и древние винды. В ней есть менеджер игр, и запускать без него игры - это тяжело и трудно, и не факт что вообще заработает. Есть ли смысл делать эмулятор FireURQ, если мы можем поставить сам FireURQ и не заморачиваться?

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

Отредактировано Oreolek (29.08.2010 10:05)