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

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

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

Я может быть по-русски не очень точно сказал, но с анси строкой проблем нет. Ни с чтением из файла TXT, ни с отображением. Вопрос в том что текстура шрифта может содержать 256 символов, то есть таблица 16*16, это значит что в CreateFont сейчас можно подать ANSI_CHARSET, BALTIC_CHARSET, и RUSSIAN_CHARSET. Это то что мною одобрено сейчас на мое личное усмотрение и протестировано. Я могу без проблем сохранить в Ноутпаде TXT файл в кодировке ANSI набрав туда текст по-русски, который правильно отображается в Ноутпаде, так как у меня поставлена сейчас русская локаль в Винде. Этот текст читается и выводится на экран без проблем, при указании RUSSIAN_CHARSET при генерации шрифта движком.

Что касается Unicode wide string (wchar_t), могу сказать - я с Юникодом не работал. Возможно позднее я обращусь за консалтингом на американские или западные форумы и этот вопрос будет решен.

Поэтому сейчас локализованный текст будет храниться либо в TXT файле в кодировке ANSI, либо я сделаю свой формат.

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

Для того чтобы разработчику не требовалось ставить локаль в Винде и в принципе даже раскладку языка - предполагается что локализуемый текст будет набираться в стороннем редакторе и храниться в Юникоде, после чего переводиться в ANSI и HTML код национальных символов (то есть те символы, которые не находятся на интервале от 32 до 127 в ANSI), после чего движком будет читаться и парситься либо такой вот TXT/HTML, либо
данный текст и коды будут сконвертированы в формат движка в виде который будет соответствовать таблице 16*16 = 256, то есть в виде например char. То есть Юникод и wide char (wchar_t) использоваться движком в ближайшее время не будет вообще, поскольку я предпочту работать над другими частями, хотя бы ИИ, чем разбираться с Юникодом.

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

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

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

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

Линк : http://atom.ueuo.com/

Я назвал раньше эту тему ATOM engine, поскольку у самого проекта шутера наименования нет. Я не предполагал что это может привести к заблуждениям, и также думал что нахождение темы в разделе "Разработка движков" обусловлено наличием факта разработки своего движка независимо от того, поставляется он для публики или нет.

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