Извините, ничего не найдено.

Не расстраивайся! Лучше выпей чайку!
Регистрация
Справка
Календарь

Вернуться   forum.boolean.name > Проекты > Проекты C++

Ответ
 
Опции темы
Старый 25.11.2012, 21:53   #16
dimanche13
Мастер
 
Регистрация: 19.03.2007
Сообщений: 1,039
Написано 153 полезных сообщений
(для 252 пользователей)
Ответ: TatEngine

я уже удалил,
дождусь лучше версии, где не будет глючить прорисовка рабочей области
а пока проверю комп полностью
(Offline)
 
Ответить с цитированием
Старый 26.11.2012, 14:59   #17
pax
Unity/C# кодер
 
Аватар для pax
 
Регистрация: 03.10.2005
Адрес: Россия, Рязань
Сообщений: 7,568
Написано 3,006 полезных сообщений
(для 5,323 пользователей)
Ответ: TatEngine

Сообщение от jimon Посмотреть сообщение
генерим шрифт размером 8192*8192 с помощью BMFont
Что-то BMFont падает если визуализация идет более чем на одну страницу...

Хочу в Unity попробовать такие шрифты завести...
__________________
Blitz3d to Unity Wiki
(Offline)
 
Ответить с цитированием
Старый 26.11.2012, 17:28   #18
jimon
 
Сообщений: n/a
Ответ: TatEngine

Сообщение от pax Посмотреть сообщение

Что-то BMFont падает если визуализация идет более чем на одну страницу...

Хочу в Unity попробовать такие шрифты завести...

попробуй подобрать размер чтобы всё на 1 странице уместилось, это обычно 800-1200 pt, ну или попробуй 4096*4096, плюс еще надо padding везде побольше указать чтобы при даунскейле был запас места вокруг каждого глифа
 
Ответить с цитированием
Сообщение было полезно следующим пользователям:
pax (26.11.2012)
Старый 26.11.2012, 18:10   #19
pax
Unity/C# кодер
 
Аватар для pax
 
Регистрация: 03.10.2005
Адрес: Россия, Рязань
Сообщений: 7,568
Написано 3,006 полезных сообщений
(для 5,323 пользователей)
Ответ: TatEngine

Шейдер написал по примеру, надо теперь генератор меша сделать на основе инфы о шрифте... а в Unity 4 сделать импортер.
http://f4.s.qip.ru/etSMyDRW.png
http://f2.s.qip.ru/etSMyDRX.png


Почитал новые туторы и взглянул на редактор еще раз. Оказывается нету проверки типов входов и выходов при соединении, было бы очень клево ее добавить, а то получается что можно назначить что хочешь, куда хочешь...
__________________
Blitz3d to Unity Wiki
(Offline)
 
Ответить с цитированием
Старый 19.01.2013, 02:23   #20
jimon
 
Сообщений: n/a
Ответ: TatEngine

выложил тулзы под макось, разработка проектов и движка потихоньку переходит на опенсорс репозиторий, showcase дорос до 9 комерческих проектов, но большинство пока под NDA надеюсь скоро появится время продолжить серию базовых туториалов и сделать демо проект
 
Ответить с цитированием
Эти 3 пользователя(ей) сказали Спасибо за это полезное сообщение:
falcon (24.01.2013), Harter (19.01.2013), pax (19.01.2013)
Старый 25.08.2013, 18:48   #21
dimanche13
Мастер
 
Регистрация: 19.03.2007
Сообщений: 1,039
Написано 153 полезных сообщений
(для 252 пользователей)
Ответ: TatEngine

как дела у движка и какие на нем выпущены проекты под какие платформы? будут ли новые туторы, желательно по всем доступным компонентам движка.
вобщем тему надо обновить
(Offline)
 
Ответить с цитированием
Старый 01.09.2013, 23:53   #22
jimon
 
Сообщений: n/a
Ответ: TatEngine

Сообщение от dimanche13 Посмотреть сообщение
как дела у движка и какие на нем выпущены проекты под какие платформы? будут ли новые туторы, желательно по всем доступным компонентам движка.
вобщем тему надо обновить
проекты в основном делались под iOS, сейчас есть :
  • Lil Flippers
  • Flora : Jewel Quest
  • Dream Gym (пока тут не начинали маркетинговую компанию, но как только будет presskit то я расскажу подробнее)

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

в основном в движке более менее всё обкатано, но нашлись некоторые очевидные проблемы с тулсетом : он неудобный в некоторых случаях

мы собрали большой опыт в разных 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 пользователя(ей) сказали Спасибо за это полезное сообщение:
ant0N (02.09.2013), falcon (05.12.2013), Harter (02.09.2013), moka (02.09.2013), pax (30.09.2013)
Старый 02.09.2013, 00:01   #23
moka
.
 
Регистрация: 05.08.2006
Сообщений: 10,429
Написано 3,454 полезных сообщений
(для 6,863 пользователей)
Ответ: TatEngine

Какие преимущества у GML над JSON'ом?
(Offline)
 
Ответить с цитированием
Старый 02.09.2013, 00:25   #24
jimon
 
Сообщений: n/a
Ответ: 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)
}
и всякие прочие штуки чтобы упростить жизнь и сделать язык от которого оргазмируешь в прямом смысле
 
Ответить с цитированием
Сообщение было полезно следующим пользователям:
Harter (02.09.2013)
Старый 02.09.2013, 04:32   #25
moka
.
 
Регистрация: 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)
 
Ответить с цитированием
Сообщение было полезно следующим пользователям:
Harter (02.09.2013)
Старый 02.09.2013, 13:54   #26
jimon
 
Сообщений: n/a
Ответ: 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 пользователя(ей) сказали Спасибо за это полезное сообщение:
Кирпи4 (02.09.2013), Harter (02.09.2013), moka (02.09.2013), pax (30.09.2013)
Старый 20.11.2013, 21:00   #27
Samodelkin
Мастер
 
Регистрация: 12.01.2009
Сообщений: 978
Написано 388 полезных сообщений
(для 631 пользователей)
Ответ: TatEngine

d3d9 рендер в разработке ( для wp8 ).
Я правильно понимаю что для магазина мелкомягких нужен dx11? Или вы без него обойдётесь?
(Offline)
 
Ответить с цитированием
Старый 20.11.2013, 23:13   #28
jimon
 
Сообщений: n/a
Ответ: TatEngine

Сообщение от Samodelkin Посмотреть сообщение
Я правильно понимаю что для магазина мелкомягких нужен dx11? Или вы без него обойдётесь?
там directx 11 с feature level 9_3

http://msdn.microsoft.com/en-us/libr...v=vs.105).aspx

http://msdn.microsoft.com/en-us/libr...v=vs.105).aspx
 
Ответить с цитированием
Сообщение было полезно следующим пользователям:
Samodelkin (21.11.2013)
Старый 21.11.2013, 00:55   #29
Samodelkin
Мастер
 
Регистрация: 12.01.2009
Сообщений: 978
Написано 388 полезных сообщений
(для 631 пользователей)
Ответ: TatEngine

Если у меня есть рендер написанный с d3d9 то мне всеравно его придется переписать через интерфейсы d3d11, или там можно из d3d11 получить интерфейс для d3d9 и не менять основную часть кода?
(Offline)
 
Ответить с цитированием
Ответ


Опции темы

Ваши права в разделе
Вы не можете создавать темы
Вы не можете отвечать на сообщения
Вы не можете прикреплять файлы
Вы не можете редактировать сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.


Часовой пояс GMT +4, время: 09:34.


vBulletin® Version 3.6.5.
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Перевод: zCarot
Style crйe par Allan - vBulletin-Ressources.com