А вообще я не фан, и слушаю обычно радио, от хардкора я отошел года 3 назад вобщем-то.

Этот треугольник не относится к 2Д плоскости, образно можно было бы сказать что он лежит на поверхности сферы, в таком случае возможно что сумма углов равна 270 градусов.

Поэтому несмотря на то что тело имеет размер в виде длины и ширины, например квадрат, который нарисовал DartNekit, этот квадрат может быть задан в 1Д системе, в виде указания координаты например, верхнего левого угла квадрата. То есть, если у нас есть 1Д координатная система на интервале например от 0 до 100, левый верхний угол квадрата, предположим находится в точке 5, то есть Х равно 5. Тогда, независимо от размера квадрата, координата его верхнего левого угла по оси Х равна 5. Если у нас квадрат, например, 2х2, тогда по оси Х, координата верхнего правого угла равна 5+2 = 7. Да, мы используем для этих вычислений сведения о размере квадрата, но координату мы все равно можем задать в 1Д системе.

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

Все это потому что речь идет о координатных системах, а не о размерах.

Задать можно в любой координатной системе, при рендере из 1Д приводится к 2Д, вот и все.

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

Твой аватар может быть задан в 2Д системе полярных координат, а рендериться на мониторе путем трансформации в декартову 2Д систему.

Кроме того, так как размер пиксела 1х1 юнитов, тогда каждый пиксел твоей авы может быть задан и в 1Д системе.

Необязательно, в ДХ и ОпенГЛ немного разные координатные системы, кроме того они могут быть переназначены (т.е. можно их изменить).

По большому счету в ДХ и в ГЛ соответсвенно, left-handed и right-handed координатные системы.

Существует понятие как dimension, соответсвенно это измерение от 1Д до 4Д, где пространство от 1Д до 3Д описывается координатной системой, в которой могут быть заданы точки X,Y,Z, при этом логично что в 1Д системе может быть только 1 координата, в 2Д опять же только 2 координаты, в 3Д само собой - 3 координаты. В 4Д системе четвертая координата, а может быть правильнее сказать - параметр, - это время.

Не важно как вы графически все это рисуете, например : ************** эти звезды могут быть обозначены и в 1Д системе и в 2Д, тогда в 1Д у нас есть смещение слева направо по оси Х, образно говоря.

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

А вообще читаем тут : http://en.wikipedia.org/wiki/Dimension , если на английском не понятно, там слева выбираем на русском и читаем.

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

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

Также мне не очень понятно, чья именно лицензия будет в силе, в случае использования, моя или же ваша, либо обе.

Как именно LGPL будет уживаться с коммерческой лицензией, например, поскольку LGPL предусматривает наличие копилефта, так как копилефт это :

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

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

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

Вердикт - повторение пройденного и уже сто раз разжеванного западными разрабами, на три балла из 10 потянет.

ИМХО.

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

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

Я бы предпочел на английском языке. Но кому-то наверное проще на своем языке, действительно.

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

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

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

По большому счету я немного иронизировал насчет терминала, хотя можно и через Lynx зайти. На данный момент я не на Юниксах вообще, так как нет необходимости, поскольку у меня больше нет сервера. Когда было нужно, то использовал FreeBSD и OpenSUSE.

Если на сервер ставить, то FreeBSD быстрее и безопаснее, так как сервера на FreeBSD еще не были взломаны, а в терминале я могу сделать все что угодно, тогда как в ГУИ только то что предусмотрели разработчики ГУИ. Конечно, терминал есть и в Линикусе, но ФриБСД я так думаю все же в большей степени Юникс.

Не впечатляет. КДЕ и графический интерфейс лично не признаю, только консоль (терминал). И конечно же, только FreeBSD/NetBSD.

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

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

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

Я может быть по-русски не очень точно сказал, но с анси строкой проблем нет. Ни с чтением из файла 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) использоваться движком в ближайшее время не будет вообще, поскольку я предпочту работать над другими частями, хотя бы ИИ, чем разбираться с Юникодом.

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

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