Проекты
GameDev.ru / Проекты / Форум / Judy (5 стр)

Judy (5 стр)

Страницы: 1 2 3 4 5 6 7 Следующая »
quyseПостоялецwww24 сен. 201514:36#60
Alprog
Я испытываю личную неприязнь к винде, особенно 8-10 :) Так что в основном из-за идеологических соображений. Ну и дополнительную платформу всё же тяжело поддерживать, хотя надо признать, что DX это бОльшая часть поддержки винды.
IfПостоялецwww24 сен. 201517:59#61
quyse
> Я испытываю личную неприязнь к винде, особенно 8-10 :)
Я тоже испытываю нечто подобное. Наверное неспроста, ведь эта паскуда отправляет куда-то в сеть, зашифрованные скрины экрана :)
AlprogМодераторwww24 сен. 201519:47#62
quyse
If
Не, это всё понятно. Но Vulkan же так и так будете вкручивать, а он и под виндой бегает. Причём даже под всякие XP-7.
quyseПостоялецwww24 сен. 201520:09#63
Alprog
> Но Vulkan же так и так будете вкручивать, а он и под виндой бегает
Где он бегает, его же нет ещё? И вроде же ещё не известно, будет ли он на винде, Microsoft может сделать как с XBox'ом, на котором, если не ошибаюсь, OpenGL нет. А у них же сейчас "универсальные приложения" для десктопов/мобилок/приставок, вот и сделают универсально - DX12 only. И даже если вулкан будет под виндой бегать, то неизвестно насколько хорошо, в плане поддержки драйверами и собственно виндой.
AlprogМодераторwww24 сен. 201520:14#64
quyse
> И вроде же ещё не известно, будет ли он на винде
Известно, что будет на десктопе. И на андроиде, кстати. А вот с маком и iOS пока не ясно.
AlprogМодераторwww25 сен. 20155:42#65
Встретил quyse на стриме случайно. Прикольно :)

А тем временем убунта с GCC мне все нервы поистрепала. Ничерта не компилится, выдаёт сегфолты там, где абсолютно штатно работают clang и msvc. Есть теория, что это из-за того, что Qt собрано GCC 4.9.1, а я компилирую 4.9.2. Но это же линукс: старую версию компилятора просто так не поставить — надо всё компилировать самому. А там те ещё приключения.

Апдейт: Докопался до сути. GCC помимо всего прочего не умеет правильно линковать при конфликте имён в одном неймспейсе.
То есть у меня было два класса Window (один не мой) в глобальном namespace проекта, и хотя они по коду никогда не включаются в один файл, линкер путается с методами только в путь.
Если в такой ситуации комментировать и расккоментировать код туда-сюда, попутно компилируя, то один и тот же код в итоге работает по-разному (потому что в *.o файлах будет дичь в зависимости от прошлых компиляций).
В связи с чем отладить и выследить этот момент было непросто.

AlprogМодераторwww13 окт. 201519:20#66
123 | Judy

Не могу определиться, как делать иерархию: прямое наследование или компонентная система.
С одной стороны, мне нравится, когда есть чёткая иерархия наследования: если нужно ловить апдейты, наследуемся в lua от какого-нибудь нода и добавляем в метатаблицу нужный функционал. Это понятно и привычно.
Но это всё здорово лишь до тех пор, пока мы создаём такие объекты из кода. Как только потребовалось «навесить» скрипт на объект в редакторе, а, тем более, на лету поменять или сохранить/загрузить иерархию в файл — начинаются проблемы.

С другой стороны, эту проблему отлично решает компонентная система. Когда скрипт — это всего лишь один из опциональных компонент у нода. Но в этом случае начинается разброд и шатание: компоненты ищут друг друга; пробираются через кучу проверок и дополнительных полей, прежде, чем получить какие-то данные; кроме того, скрипт не является потомком класса Image, он находится где-то сбоку, что неудобно. Хочется как-то объединить два подхода, но пока не нашёл компромисс.

ХаусПостоялецwww15 окт. 20159:59#67
Alprog

А исходники доступны?

ХаусПостоялецwww15 окт. 201510:03#68
Alprog
> Причём буду пытаться реализовать фичу существования GAPI бок о бок:

Зачем?

AlprogМодераторwww15 окт. 201515:45#69
Хаус
> А исходники доступны?
https://github.com/Alprog/Judy

> Зачем?
До появления nextgen-GAPI в этом была толика практического смысла: на тот момент был единственный способ утилизировать всю мощь нескольких GPU — создать несколько независимых DX- или GL-контекстов. Будут ли они при этом соответствовать одному или нескольким GAPI принципиальной разницы не имело. На сегодняшний же день, когда GAPI позволяет фичу Multi-Adapter, наиболее корректный ответ на вопрос «зачем» — это «прост».

All
Запускаю очередной стрим разработки:
https://www.livecoding.tv/alprog/

ХаусПостоялецwww15 окт. 201517:39#70
Alprog

Он только квады рисует? Какой-то очень скромный получился. :)
Есть доступные техно-демки? Анимация, частицы, шрифты, режимы смешивания, физика и т.д.?

AlprogМодераторwww15 окт. 201518:05#71
Хаус
> Анимация, частицы, шрифты, режимы смешивания, физика и т.д.?
Рендерера пока нет как такового. Пока есть только свой рефлекшн, парсер аттрибутов, свой биндинг в луа и сериализация, своя среда со встроенным дебагером приложения по TCP/IP. Но со временем всё будет.
AlprogМодераторwww9 ноя. 20157:05#72
cin
Рендер — это вещь вторичная, на самом деле. Что такое "рендер движок" я не особо понимаю, но если говорить о движках вообще, то из бесплатного можно какое-то время перекантоваться на cocos2d-x.
Сейчас небольшой сайд-проектик с ребятками намечается, как раз на нём собрался делать.

All
Две недели был перерыв. Сейчас снова потихонечку занимаюсь.
Вести с полей: я подглядел кое-какие идеи в tolua++, cocos2d-x и lqt, и немного доработал свой биндинг классов.
Интеграция у меня круче, чем в том же кокосе, по следующим пунктам:

  • У меня можно переопределить виртуальную функцию С++ класса в lua и она будет вызываться из С++.
    Пока только Update, но думаю сделать как-нибудь универсально + завести битовую маску перегруженных функций, чтобы лишний раз не дёргать.
  • У меня полностью синхронизировано время жизни С++ объекта и его lua counterpart.
    Т.е. пока счётчик ссылок на С++ объект не равен 0, то непустой луашный объект не будет уничтожен gc; и наоборот: пока луашный объект не будет съеден gc, с++ объект продолжает жить.
    Таким образом, программисту игры на lua вообще не придётся думать о памяти. О том, чтобы ненужное удалялось, а нужное всегда было ещё живо, позаботится движок и луашный gc.
  • У меня поддерживается lua 5.3.

Пока думаю, как поступить со структурками, которые по значению передаются (векторы, матрицы). Можно как в кокосе — превращать их в таблицы. Но в этом случае придётся дублировать функционал на луа-стороне (всякие там dot, cross и прочее).
Либо же заводить юзердату, чья память полностью управляется lua. Это проще и универсальнее, потому что у меня уже есть всякие самописные биндинги автоматические, но, возможно, это не лучшее решение в плане производительности.

ХаусПостоялецwww13 мар. 201622:16#73
Alprog

Какие новости?

AlprogМодераторwww13 мар. 201622:56#74
Хаус
> Какие новости?
Проект не брошен, но отложен. Я принялся делать МиС РПГ 2 на сильно модифицированном cocos2d-x, которую в последствии планирую портировать на свой движок.
По ходу некоторые вещи в архитектуре переосмысливаю (в основном это касается 3D), что повлияет на финальный дизайн Judy.
Краткую историю о том, как же так получилось, можно почитать в теме МиС РПГ на первой странице.
Страницы: 1 2 3 4 5 6 7 Следующая »

/ Форум / Проекты / Утилиты

2001—2018 © GameDev.ru — Разработка игр