|
25.11.2012, 21:53
|
#16
|
Мастер
Регистрация: 19.03.2007
Сообщений: 1,039
Написано 153 полезных сообщений (для 252 пользователей)
|
Ответ: TatEngine
я уже удалил,
дождусь лучше версии, где не будет глючить прорисовка рабочей области
а пока проверю комп полностью
|
(Offline)
|
|
26.11.2012, 14:59
|
#17
|
Unity/C# кодер
Регистрация: 03.10.2005
Адрес: Россия, Рязань
Сообщений: 7,568
Написано 3,006 полезных сообщений (для 5,323 пользователей)
|
Ответ: TatEngine
Сообщение от jimon
генерим шрифт размером 8192*8192 с помощью BMFont
|
Что-то BMFont падает если визуализация идет более чем на одну страницу...
Хочу в Unity попробовать такие шрифты завести...
|
(Offline)
|
|
26.11.2012, 17:28
|
#18
|
|
Ответ: TatEngine
Сообщение от pax
Что-то BMFont падает если визуализация идет более чем на одну страницу...
Хочу в Unity попробовать такие шрифты завести...
|
попробуй подобрать размер чтобы всё на 1 странице уместилось, это обычно 800-1200 pt, ну или попробуй 4096*4096, плюс еще надо padding везде побольше указать чтобы при даунскейле был запас места вокруг каждого глифа
|
|
|
Сообщение было полезно следующим пользователям:
|
|
26.11.2012, 18:10
|
#19
|
Unity/C# кодер
Регистрация: 03.10.2005
Адрес: Россия, Рязань
Сообщений: 7,568
Написано 3,006 полезных сообщений (для 5,323 пользователей)
|
Ответ: TatEngine
Почитал новые туторы и взглянул на редактор еще раз. Оказывается нету проверки типов входов и выходов при соединении, было бы очень клево ее добавить, а то получается что можно назначить что хочешь, куда хочешь...
|
(Offline)
|
|
19.01.2013, 02:23
|
#20
|
|
Ответ: TatEngine
выложил тулзы под макось, разработка проектов и движка потихоньку переходит на опенсорс репозиторий, showcase дорос до 9 комерческих проектов, но большинство пока под NDA надеюсь скоро появится время продолжить серию базовых туториалов и сделать демо проект
|
|
|
Эти 3 пользователя(ей) сказали Спасибо за это полезное сообщение:
|
|
25.08.2013, 18:48
|
#21
|
Мастер
Регистрация: 19.03.2007
Сообщений: 1,039
Написано 153 полезных сообщений (для 252 пользователей)
|
Ответ: TatEngine
как дела у движка и какие на нем выпущены проекты под какие платформы? будут ли новые туторы, желательно по всем доступным компонентам движка.
вобщем тему надо обновить
|
(Offline)
|
|
01.09.2013, 23:53
|
#22
|
|
Ответ: TatEngine
Сообщение от dimanche13
как дела у движка и какие на нем выпущены проекты под какие платформы? будут ли новые туторы, желательно по всем доступным компонентам движка.
вобщем тему надо обновить
|
проекты в основном делались под iOS, сейчас есть :
была куча проектов не под издательство : презентации, конференции и тд, и так же всякие поделки которые не вылились в нечто более серьезное
в основном в движке более менее всё обкатано, но нашлись некоторые очевидные проблемы с тулсетом : он неудобный в некоторых случаях
мы собрали большой опыт в разных use cases с разными движками и хотим сейчас их систематизировать в универсальном тулсете - llgm (аналогия с llvm - low-level game machine), основная идея в том что WYSIWYG для игр работают не достаточно хорошо, например задача : вставьте 500 анимаций и назначьте их разным объектам, нужно еще поискать редактор в котором это будет удобно делать, и задавшись целью написать тулсет которым хочется пользоваться мы погрузли в R&D
в основном за всю историю IT самые сложные и разнообразные use cases были в редакторах текста, люди придумали очень мощные инструменты для редактирования текста : latex, vim, regexp, etc, потому мы решили использовать текстовое представление как основное, сделать некий markup language для игр
за основу markup language мы взяли qml ( http://en.wikipedia.org/wiki/QML) - json подобный язык на котором внезапно удобно писать, declarative + reactive programming + scripting, и перекраиваем его для нужд realtime, назвали его game markup language - GML
оно выглядит примерно так :
material
{
id: sprite_mat
texture
{
file: "foo.png"
}
shader: "sprite"
}
sprite
{
material: sprite_mat
transform.x: 100
}
sprite
{
material { texture.file: "bar.png" }
transform { x: 50; y: 100 }
}
сам язык очень похож на json, стараемся сделать даже так чтобы GML был надмножеством json (любой json код - валидный gml код), можно будет переводить gml в json и обратно
сейчас изучаем использование этого языка, некоторые вещи делаются очень быстро в тексте, некоторые вещи делаются очень наглядно в unity-style редакторе, а некоторые возможно сделать только в excel (вставка 500 анимаций), представление в виде objects with properties позволяет легко переходить из одного вида в другой и обратно
плюс разрабатываем универсальный тулсет в которой плагинами можно встроить все что угодно, и продвигаем систему кеширования через весь тулсет, те если мы поменяли только позицию спрайта то бейкинг лайтинга не вызовется, плюс спрайт подвинется в движке моментально, потому что движок будет подключен к тулсету по сети
основной фишкой llgm мы стараемся сделать абсолютную универсальность и простоту - GML будет полностью schema-driven без хардкода каких либо имен или структуры, потому можно будет подстроить тулсет под ваш движок, или вообще делать импорт\экспорт из существующих движков
по самому движку tatengine : есть планы по его рефакторингу, нужно обновить тулзы по работе с ide, добавить task-driven многопоточность, вынести геймлогику в скрипты и тд
так и не решили пока с гуи, возможно declarative + reactive programming упростит создание гуи (в QML оно достаточно просто делается), но это пока только догадки, production бывает ломает любые догадки =) возможно попробуем тупо встроить chrome чтобы забыть наконец-то о гуи
ps. дальше еще будет =)
|
|
|
Эти 5 пользователя(ей) сказали Спасибо за это полезное сообщение:
|
|
02.09.2013, 00:01
|
#23
|
.
Регистрация: 05.08.2006
Сообщений: 10,429
Написано 3,454 полезных сообщений (для 6,863 пользователей)
|
Ответ: TatEngine
Какие преимущества у GML над JSON'ом?
|
(Offline)
|
|
02.09.2013, 00:25
|
#24
|
|
Ответ: TatEngine
Сообщение от moka
Какие преимущества у GML над JSON'ом?
|
удобнее писать руками, удобнее читать глазами, меньшая избыточность, lazy syntax, ну и да - комментарии в коде
разделителем может быть : или , или ; или его вообще может и не быть
например :
// gml
sprite { transform { x: 5 } }
sprite { transform { y: 20 } }
// json
[
{ "type" : "sprite", "childrens" : [ { "type" : "transform", "x" : 5 } ] },
{ "type" : "sprite", "childrens" : [ { "type" : "transform", "x" : 20 } ] },
]
еще думаем над всякими плюшками типа string literals и raw strings (как в C++), что позволит писать GML в UTF-8, а на выходе получать строку в UTF-16 или 32, а raw strings позволит не экранировать символы в теле строки и писать там скрипты любой сложности прям внутри GML файла
например :
script
{
text : R"(
// lua script
print("wow");
)"
}
стараемся упростить все до предела чтобы на нем именно ХОТЕЛОСЬ писать, есть много красивых инструментов, а любимых очень мало
так же в schema-driven будет много экспериментальных вещей : lazy types, lazy nested objects, lazy scripts и тд, но это не относится к синтаксису языка
например :
/* сам объект sprite по schema требует чтобы к нему был присоединен объект типа transform, у sprite для этого есть дефолтное поле с именем transform которое принимает ссылку (bind в терминологии qml) на объект с типом transform */
sprite
{
// но если мы опишем объект с типом transform в теле sprite то gml сам его подхватит и прилинкует к полю transform
transform { }
}
sprite
{
transform { id: a }
transform { id: b }
transform : a // спрайт будет двигаться трансформом A
}
sprite
{
transform : transform { x : 5 } // nested objects
}
spr // вместо указания полного типа можно указывать только первые буквы, да и еще убирая гласные (эксперимент)
{
trn { x: 5 }
}
spr
{
trn.x : 5 // можно обращаться к полям объекта через поля-ссылки
}
spr
{
trn.x := math.sin(t) * 50 // если вместо : написать = или := то парсер будет ожидать nested script, выражение с = выполнится во время загрузки, выражение с := будет выполнятся каждый кадр (reactive programming)
}
и всякие прочие штуки чтобы упростить жизнь и сделать язык от которого оргазмируешь в прямом смысле
|
|
|
Сообщение было полезно следующим пользователям:
|
|
02.09.2013, 04:32
|
#25
|
.
Регистрация: 05.08.2006
Сообщений: 10,429
Написано 3,454 полезных сообщений (для 6,863 пользователей)
|
Ответ: TatEngine
Сообщение от jimon
удобнее писать руками, удобнее читать глазами, меньшая избыточность, lazy syntax, ну и да - комментарии в коде
разделителем может быть : или , или ; или его вообще может и не быть
например :
// gml
sprite { transform { x: 5 } }
sprite { transform { y: 20 } }
// json
[
{ "type" : "sprite", "childrens" : [ { "type" : "transform", "x" : 5 } ] },
{ "type" : "sprite", "childrens" : [ { "type" : "transform", "x" : 20 } ] },
]
|
Чем не:
sprites: [
{ "transform": { "x": 5 } },
{ "transform": { "x": 20 } },
]
?
Сообщение от jimon
еще думаем над всякими плюшками типа string literals и raw strings (как в C++), что позволит писать GML в UTF-8, а на выходе получать строку в UTF-16 или 32, а raw strings позволит не экранировать символы в теле строки и писать там скрипты любой сложности прям внутри GML файла
например :
script
{
text : R"(
// lua script
print("wow");
)"
}
стараемся упростить все до предела чтобы на нем именно ХОТЕЛОСЬ писать, есть много красивых инструментов, а любимых очень мало
так же в schema-driven будет много экспериментальных вещей : lazy types, lazy nested objects, lazy scripts и тд, но это не относится к синтаксису языка
например :
/* сам объект sprite по schema требует чтобы к нему был присоединен объект типа transform, у sprite для этого есть дефолтное поле с именем transform которое принимает ссылку (bind в терминологии qml) на объект с типом transform */
sprite
{
// но если мы опишем объект с типом transform в теле sprite то gml сам его подхватит и прилинкует к полю transform
transform { }
}
sprite
{
transform { id: a }
transform { id: b }
transform : a // спрайт будет двигаться трансформом A
}
sprite
{
transform : transform { x : 5 } // nested objects
}
spr // вместо указания полного типа можно указывать только первые буквы, да и еще убирая гласные (эксперимент)
{
trn { x: 5 }
}
spr
{
trn.x : 5 // можно обращаться к полям объекта через поля-ссылки
}
spr
{
trn.x := math.sin(t) * 50 // если вместо : написать = или := то парсер будет ожидать nested script, выражение с = выполнится во время загрузки, выражение с := будет выполнятся каждый кадр (reactive programming)
}
и всякие прочие штуки чтобы упростить жизнь и сделать язык от которого оргазмируешь в прямом смысле
|
Это не будет языком, а будет "разметкой".
Да и любая попытка "упростить" требует создание каких либо механик, а они в 90% не оправдываются продакшаном и имеют ограничения. Которые в итоге вынудят других разрабатывать свои велосипеды.
Те же schem'ы, всегда имели % разрабов их не уважающих.
|
(Offline)
|
|
Сообщение было полезно следующим пользователям:
|
|
02.09.2013, 13:54
|
#26
|
|
Ответ: TatEngine
Сообщение от moka
Чем не:
sprites: [
{ "transform": { "x": 5 } },
{ "transform": { "x": 20 } },
]
?
|
первая строчка и уже не валидный json по двум причинам : ключ должен быть строкой, текст должен быть объектом (это не описано в стандарте, но 95% парсеров которые я видел не умеют парсить файл который не является объектом)
плюс опять же - комментариев нету, добавь их и твой файл никто не сможет распарсить, что уже не json
а в случае если ты хочешь описать все спрайты с помощью одного массива то получается что тебе нужно добавлять новые спрайты только в этот массив, что не удобно, можно тогда сделать объект "entity" и там уже делать спрайты и тд, получится ровно то что сейчас в юнити
основной минус такого подхода - слишком большая сложность и громоздкость, json представление мы делали в tatengine, и единственным плюсом был рабочий merge в системах контроля версий формат оказался хоть и читабельным, но писать его руками не хотелось
Сообщение от moka
Это не будет языком, а будет "разметкой".
|
1) любая разметка - декларативный язык программирования
2) разметка с reactive programming взлетает для самописного кода, так же как html взлетает с nested js, nested css и прочим nested которое можно разместить в теле html файла
Сообщение от moka
Да и любая попытка "упростить" требует создание каких либо механик, а они в 90% не оправдываются продакшаном и имеют ограничения.
|
мы собрали опыт с unity, опыт со своим движком, опыт с cocos2d, udk и прочими и думаем как сделать удобнее, так же есть опыт людей из Qt : http://doc-snapshot.qt-project.org/q...t3d-qml3d.html, они потихоньку делают свой 3д движок на базе qml, потому текущее начинание это побольшей части research, ведь такую разметку в итоге можно превратить хоть в blitz3d код
Сообщение от moka
Которые в итоге вынудят других разрабатывать свои велосипеды.
|
таких уже нету, все пишут на unity
Сообщение от moka
Те же schem'ы, всегда имели % разрабов их не уважающих.
|
любой язык вообще-то имеет schema, даже C++, это как бы часть того что собирает набор токенов языка в семантическое дерево, просто json и xml могут описать любые объекты, а schem'ы нужны чтобы проверять некоторые поля на валидность с граматикой нужных для приложения объектов
если ты имеешь ввиду "напиши schema для своего же кода" - то нет, с тулсетом будет поставляться дефолтная schema gml с абстракциями уровня примитивов рендера, камеры, трансформов, материалов, скриптов и тд, но сам тулсет будет schema-driven, в чем смысл ? в том что в случае большой необходимости можно поменять schema на свою, например для движков где 3д камеры нету, а трансформам Z позиция не нужна
потому для обычного обывателя schema по началу вообще будет не доступна - он о ней даже знать не будет, кроме как из ошибок компиляции =)
а нужно это всё чтобы можно было тулсет внедрить в любой движок как промежуточное представление, раньше для этого хотели использовать collada, но её не очень то и удобно писать руками, и дальше промежуточного формата моделей она не сильно ушла из-за слабого тулсета
|
|
|
Эти 4 пользователя(ей) сказали Спасибо за это полезное сообщение:
|
|
20.11.2013, 21:00
|
#27
|
Мастер
Регистрация: 12.01.2009
Сообщений: 980
Написано 389 полезных сообщений (для 632 пользователей)
|
Ответ: TatEngine
d3d9 рендер в разработке ( для wp8 ).
|
Я правильно понимаю что для магазина мелкомягких нужен dx11? Или вы без него обойдётесь?
|
(Offline)
|
|
21.11.2013, 00:55
|
#29
|
Мастер
Регистрация: 12.01.2009
Сообщений: 980
Написано 389 полезных сообщений (для 632 пользователей)
|
Ответ: TatEngine
Если у меня есть рендер написанный с d3d9 то мне всеравно его придется переписать через интерфейсы d3d11, или там можно из d3d11 получить интерфейс для d3d9 и не менять основную часть кода?
|
(Offline)
|
|
Ваши права в разделе
|
Вы не можете создавать темы
Вы не можете отвечать на сообщения
Вы не можете прикреплять файлы
Вы не можете редактировать сообщения
HTML код Выкл.
|
|
|
Часовой пояс GMT +4, время: 22:49.
|