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)

Oreolek написал:

А вот как с поддержкой Милены, INSTEAD и QuestBox?

Однозначного ответа на этот вопрос дать пока не могу. Но у меня схожие принципы с LUA, возможно мне удастся перенести математику языков этих платформ.

Oreolek написал:

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

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

Oreolek написал:

Почему я должен буду удалить с компа QSP\URQ и поставить Этот Замечательный Проигрыватель? Пожалуйста, два варианта ответов - как игроку и как автору.

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

А теперь конкретно по вопросу.

Авторам:
Обеспечение поддержки, ставших уже привычными, языков ИЛ лучшее решение, чем создавать велосипеды. Все остальное зависит от их разработчиков. Не будут давать инфу, значит будут их аналоги. А при хорошем наборе языков, есть из чего выбирать (очень полезно для новичков). Плюс платформа не ограниченна возможностями того или иного языка, это языки осуществляют использование возможностей платформы. Не нравится язык пиши на другом, нету такого, тогда добавьте. А кроссовость проигрывателя позволит добиться распространения квеста не только под Винду. Насчет LUA, то по мне так, лучше найти ему замену, но спец. для ИЛ (это платформа в силах это осилить). Но вопрос с LUA лучше рассматривать отдельно.


Игрокам:
С помощью сетевой возможности, можно будет запускать не сетевой квест и играть в него, например вдвоем за одного героя. Или каждый/группа за определенного героя. А также можно в специально сетевые квесты для игры компанией игроков (бывать в разных местах квестах и иметь впечатление от сюжета на развитие, которого влияет каждый из игроков, возможно лишь в сетевушных играх). И в не сетевых квестах информация будет выводиться полностью для всех, а в сетевых с т.з. персонажа (но это все определяется автором и языком исходников). Возможность сыграть в квесты с глючной или старой платформы на этой, тоже вещь заманчивая. При опять же кроссовости, не надо будет ограничивать своей ОС.

Oreolek, когда про сингловые игры учавствующие в сети, то подразумевал, что автор писал сингловый квест изначально. Но людям хочется поиграть в него компанией и как они там будут играть, дело лично ихнее и я не собираюсь их ограничивать. Т.е. они играют в сингловый квест по сети. Автор, конечно может (если язык будет позволять подобное) сделать прописку, как квесту работать без сетевого режима и в сетевом. Но это потребует его времени. Другое дело, когда он пишут, либо под сингл, либо под сеть. Это как писать, под одну ОС, или под несколько.

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

Под стартовой точкой имеется следующее. Когда ты собираешься писать квест с нуля, тебе надо сделать все управляющие элементы, по просту говоря движок, а уже потом писать квест. На уровне выше, ты просто выбираешь подходящую для тебя платформу с ее родным языком и пишешь квест на ней. Так вот на моей платформе ты выбираешь язык по нужным тебе возможностям и самый понятный и удобный для тебя, и пишешь свой квест. Т.е. эта платформа, поднимает эту самую стартовую точку на порядок выше. И соответственно, что я не смогу включить все возможности в эту платформу, чтобы не вышло путаницы. Но это уже будет хорошим началом для нового типа платформ, особенно если учесть, что она будет идти с открытым кодом и определенными ветками развития. Т.о. я не только обеспечиваю стартовую точку, но также и будущее для такого рода платформ. Поэтому очень важно заложить все необходимые и сочетаемые возможности, а также предпосылки для того еще не вошло в состав возможностей платформы. То что платформа не может включить буквально все подряд, как раз говорит не в пользу универсальности общего смысла в рамках ИЛ, а в функциональности и широком спектре возможностей, с возможностью довести ее до универсальности. Но, если в этом будет реальная необходимость. Кстати, стартовая точка в голове, это чаще всего уровень реализации -1 и он редко у кого доходит хотя бы до нуля.

Также я не стану называть свою платформу велосипедом, т.к. есть не мало факторов и предпосылок, закладываемых в ее основу, что по сравнению с ней построение еще одной легкой платформы, как раз и есть велосипед. А у меня, первоначально, только пока что вариант тяжеловеса в платформах. Т.е. URQ - это очень легкая платформа, QSP - средний уровень, Neorgek - тяжелый уровень. Т.е. я не собираюсь делать "идеальную" платформу, а больше ставку ставлю на практичность и помощь в уходет от нужды к возвращению к языкам общего назначения. И, Oreolek, понятие велосипед определяется не только мнением пользователей, но и факторами и возможностями, а также позиционированием и направлением развития платформы. Учитывая все выше сказанное, ты не прав в утверждении, что моя платформа это велосипед. Про идеи говорить не буду, т.к. любая - всегда велосипед. Даже то, чем ты сейчас занимаешься. Но ты же не удовлетворяешься одной идеей, и я также.

Новичкам трудно не будет, если написать краткий мануал по тому, как вообще стоит начать выбор языка (а не платформ!). С другой стороны надо обеспечивать поддержку используемых языков в ИЛ, т.е. брать из используемого, а не создавать новое. В крайнем случае, можно создать ихнии аналоги, чтобы не было так сложно переходить с одного языка на другой. Но тут есть несколько моментов, язык может быть не переносимым, из-за разработчика (ну не хочет он), из-за не возможности перенести. И другой момент, аналога может не быть.

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

Ладно, тут пересмотреть добавляемые возможности. Т.е. я изначально хотел сделать платформу с начало без музыки и видео, и изображений. А в следующей версии добавить их. (это вам не платформы лепить, а разобрать все на элементарные понятия и перебрать все необходимое) Поэтому я изначально реализую запланированное в ветке СТК1, а после уже буду дополнять ее до допустимого наличия возможностей. К тому же раз я пишу на Qt то там есть уже подобного рода применение HTML и CSS (про CSS пока много сказать не могу, но перечень HTML гляну и дам ссылку позднее). В крайнем случае можно реализовать поддержку самостоятельно, как уже привычный способ разметки текста. Насчет парсера, тут мне помощь в информации, чтобы я смог перебрать все необходимое и сделать возможности для реализации нормального и удобного парсера.

А это уже требует цитаты:

Oreolek написал:

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

Я много раз разбирал разные квесты и языки на элементарные команды и элементы интерфейса. Все это было закреплено в описании проекта и в основах. Особенно, учитывая, что наши квесты пишутся с первого уровня стартовой точки (см. выше), а следовательно они могут быть разобраны на элементарные понятния. Тем более, что при испольнении моя платформа работает с основами и элементарными командами. Т.е. она на порядок шире платформ с уровнем стартовой точки ныне используемых платформ, где просто реализуются некоторые возможности.

Oreolek написал:

Список поддерживаемых платформ:
INSTEAD - Windows, Linux, Mac OS X, есть порт на планшеты Nokia
QSP - Windows, Linux, готовится Mac OS X, есть порт на PSP
URQ - DOS, Windows
Милена - Windows
QuestBox - Windows

INSTEAD - ограничен двумя библиотеками, QSP не имеет ровной кроссплатформенности, кроме разве что для ОС на ПК.
URQ - развивается только в линейке Windows (DOS это основа всех Windows до Vista и выше), на другие ОС они ее врядли реализуют.
Милена - тоже самое, что и выше, также ограничен библиотекой LUA.
QuestBox - слабый проигрыватель, пока что, также ограничен библиотекой LUA.

Neorgek - Windowds, Linux, возможно Mac. Все остальное, ограничивается закладываемыми возможностями первой ветки СТК1, т.к. она реализует базовые возможности. Поэтому, как мы ее равновесно разовьем, такие предпосылки для разных ОС она и даст. Т.е. можно кашу, о которой ты меня спрашивал выше, а можно поступить разумнее и просто разбить на разные ветки развития. Именно такой позиции я и придерживаюсь и на мой взгляд лучше не спешить с набором возможностей в первой ветке, а обеспечить ее масштабируемость.

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

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

Отредактировано Eten (30.08.2010 08:15)

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

За такое и темную устроить не жалко.

Т.е. эта платформа, поднимает эту самую стартовую точку на порядок выше.

И делает ее недосягаемой для среднестатистического "быдла" вроде меня, которое толком ничего не знает о программировании=)

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

Т.е. Предлагаете плодить велосипеды?

Новичкам трудно не будет, если написать краткий мануал по тому, как вообще стоит начать выбор языка (а не платформ!).

Почему я должен выбирать язык, а не платформу? ИМХО, даже если я буду делать что-то в Вашем плеере, а это маловероятно, т.к. Вы делаете плеер, а не тот же самый Qgen. Так вот... даже если я буду делать что-то в Вашем плеере, мне придется скачать Qgen, а раз так, то учитывая, что большинство сидит с оригинальным QSP, мне будет намного проще и эффективнее делать это дело в нем. И проблема выбора языка вообще не встанет.

Eten, а ты думал над социальной составляющей своей платформы? Ведь разделение на платформы — это дополнительное развлечение в виде деления на "партии", привлечение сторонников и получение удовольствия уже от того, что если даже у тебя самого получается плохо — в диалоге с представителем "лагеря противников" ты всё равно можешь с гордостью сказать: "У нас круче!"

С wine не всегда все гладко. Например, я не могу играть в игры под FireURQ, так как у меня везде видео только intel, и в wine не работает 3d, которое нужно для furq.... Конкретный пример, где кроссплатформенность не помешала бы, но ее нелегко, наверное сделать. Так-что проще пренебречь жалкими процентами пользователей типа меня.

Насчет темы: я не против велосипедов, но слишком глобальная задача. Кидаю идею: язык для if игр, но более высокоуровневый чем urq/qsp (то, что я делаю из lua в INSTEAD, сделать с чистого листа). Задача очень научная и требует ответственного подхода. Также сложность еще в том, что качество языка проверяется в основном на практике, так что только теорией не отделаешься.

QSP - Windows, Linux, готовится Mac OS X, есть порт на PSP

На самом деле, вот так:
Windows, Linux, MacOS X (осталось выложить сборку на сайт), Windows Mobile, PSP, PocketBook, Flash, готовятся порты на iPhone, Java и Bada. Был работающий прототип плеера на BeOS/Haiku.

Насчет темы: я не против велосипедов, но слишком глобальная задача. Кидаю идею: язык для if игр, но более высокоуровневый чем urq/qsp (то, что я делаю из lua в INSTEAD, сделать с чистого листа).

А с чего Вы взяли?)))
ИМХО, об этом судить авторам, а не Вам.
и с точки зрения автора идеальный язык должен работать по принципу:

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

Oreolek написал:

Милена не работает точно

Я играл в кэбмена через вайн. А в остальном все верно, русская рулетка.

Отредактировано Cheshire (30.08.2010 17:46)

gloomy написал:

С wine не всегда все гладко. Например, я не могу играть в игры под FireURQ, так как у меня везде видео только intel, и в wine не работает 3d, которое нужно для furq.... Конкретный пример, где кроссплатформенность не помешала бы, но ее нелегко, наверное сделать. Так-что проще пренебречь жалкими процентами пользователей типа меня.

Насчет темы: я не против велосипедов, но слишком глобальная задача. Кидаю идею: язык для if игр, но более высокоуровневый чем urq/qsp (то, что я делаю из lua в INSTEAD, сделать с чистого листа). Задача очень научная и требует ответственного подхода. Также сложность еще в том, что качество языка проверяется в основном на практике, так что только теорией не отделаешься.

Я достаточно знаком с OpenGL и могу сказать, что он куда удобнее в плане кроссплатформенности, чем DirectX. А как программисту, мне не привыкать к большому изобилию кода, который нужно написать для реализации всяких плюшек. К тому же, у OpenGL различно только получение контекста для окна, в Qt  я с этим особых проблем не заметил (сам изучал OpenGL на Visual C++ и Delphi 7, вещь рульная).  Для звука скорее всего использую OpenAL или любую другую подходящую открытую библиотеку. Да и создатели Qt придерживаются тех же принципов реализации программ, поэтому писать буду на нем. В плане кодеков буду использовать открытые.

Поговорим через год.

APROMIX написал:

Не так сложен как интересен Да и не лучше ли просто поддержать готовый Lua в проекте?

Кхм, APROMIX, а вот ты сможешь взять на себя смелость и, в отличии от firetona, к примеру дать мне твои исходники с пояснениями о LUA, чтобы я смог понять каким образом ты его используешь? Ведь мне нужно увидеть готовый пример, а проигрыватель у тебя простой. Можешь выслать мне на почту, я никому показывать не стану. К тому же, если я не ошибаюсь, LUA очень похож на JAVASCRIPT во всем (но это только первое впечатление).

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

Т.о. мне нужно знать, как вы, разработчики своих проигрывателей, применяете LUA при создании своего проигрывателя и что используете в нем из LUA. И вопрос на будущее, так ли нужен LUA? Сам лично могу ответить только через год.

Отредактировано Eten (01.09.2010 07:10)

APROMIX написал:

Об исходниках - я спрошу Kariot'а, и если он согласится, вышлю.

Если узнаешь ответ, то хотя бы сообщи здесь или кинь мне в личку, чтобы я знал.

Уважаемые форумчане, несмотря на все метания Oreolek и попытку убедить себя в своих же взглядах, а возможно и на всех. Могу сказать только одно, я буду определять базовый функционал и возможности исходя из того, куда можно перенести впоследствии эту платформу. Изначально я ориентируюсь больше на ОС для ПК, но предпочту оставить возможность переноса и на мобильные устройства, если таковое будет возможно.

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

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

А может дать ему красивое имя, например, Милена Звучит красиво и всем все сразу понятно.

Прошло почти 11 месяцев, т.е. почти год. Увы, на этот период я ничего не могу вам дать "пощупать" или показать в готовом виде. Но, я знаю точно, что готов приступить к созданию платформы Неоргек во всех смыслах и отношениях, а если, что и будет не готово, то это всего лишь вопрос времени, когда оно изменится и уйдет с пути моего, как очередное препятствие. И эту платформу реализую, да достигну цели своей!

По сроку своему могу сказать, что "пощупать" платформу в вашем понимании вы сможете не раньше 2012 года. Т.к. мне нужно полностью создать проигрыватель, компилятор и конструктор, чтобы дать, в полной мере, возможность это сделать вам.

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

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

З.Ы.
Свое слово я сдержал, перед Nex-ом. У меня действительно есть реализация, но она настолько сырая, что ее не нужно показывать. Т.к. после переделки она перестанет быть сырой, а ваши представления врядли поспеют за мной. Иначе говоря, я не хочу показывать то, что не готово и не возможно понять, без участия в разработке.

Бородатого кота надо меньше рыбой кормить, а то борзеть начинает.

З.Ы.
fireton, .

fireton написал:

Этен, не хами.

Ну, уж извини тогда, но твой постик тоже можно по разному воспринять.

З.Ы.
Сарказм, Сарказма, Сарказмит. Так,что давай тоже без этих лестностей.

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