- AlexKhomich
- Постоялец
После работы, один вечер (2 часа), на разборку примера, и по пути, немного исследований, как рендерить в таргеты и т.п. Оказалось очень удобно! И ещё где-то около часа в другой вечер, на уже написание. На самом деле по пути у меня ещё другое совсем было, но быстро под конец собрал эту демку.
Скорость разработки на C# и Vortex2D, улётная!
Очень рад что демка подняла настроение, самому приятно!
На данный момент, цепляется лишь один момент: классы для Size и Point использованы стандартные (System.Drawing), и происходит частенько мешанина, и необходимость объявлять новые Vector2, было бы намного удобнее почти везде иметь возможность тупо использовать Vector2, если это Point или Size.
Также у камеры, функция WorldToScreen, имеет только 2 параметра. Но думаю что т.к. исходники открыты, можно добавить больше overload функций, которые будут преобразовывать простые Vector2 и т.п.
ColorU - очень удобный :)
ЗЫ, для рендера света, использовал таргет 32F формата на канал. Но там был только 4ёх канальный A32B32G32R32F, а есть ли на 3 канала, без альфы?
И ещё, я погуглил, но толком не нашёл инфы о такой структуре:
using(canvas <= ...) {Меня интересует этот оператор: <=
Или он в движке описан (не является стандартным)?
Была вот такая структура:
canvas <= camera <= shader <= normalMap*2
Не позволило. Потому что как понимаю, shader по логике бы относился не к canvas, а к camera. Как послать тогда несколько данных?
Также почему у текстуры которую посылаю в шейдер нужно указывать *2, это определяет индекс в регистре :register(si); для шейдера, так?
Вау, это очень хорошо, что для тебя всё удобно и просто.
Size/Point просто целочисельные... я их переюзал. Кстати, попробуй просто писать их вместо Vector2 и наоборот, если надо. Вроде бы я добавил поддержку неявних операторов для этих типов.
Насчёт типов текстур... Я их очень давно не пересматривал. Добавил только те, которые поддерживаются на почти всём оборудовании. Надо будет поревизить.
Обновил пост 60..
Ещё вопрос, если используется Camera2D, то по стандарту нулевая точка мира, будет в центре камеры, так?
И ещё вопрос, может я поленился посмотреть внимательно, но Handle по стандарту привязан к верхнему левому углу текстуры, при отрисовке. Какие функции отвечают за переназначение этого, чтобы например отрисовка происходила по координате относительно центра или другой точки текстуры?
UPD: нашёл: Sprite - Origin.
Отвечаю на пост 60.
1.
using(canvas <= ...) {Это фича Вортекса. Структура реализована переопределением оператора <= для того, что бы упростить применение стейта на определённый участок выполнения.
2.
canvas <= camera <= shader <= normalMap*2
Печально, должно было позволить. Это цепочная структура должна применятся последовательно к канве. Буду разбираться. Альтернатива этой конструкции:
using (canvas <= camera)
using (canvas <= shader)
using (canvas <= normalMap * 2) {
}3.
normalMap*2
Да, это установка normalMap текстуры в второй семплер (s2). В библиотеке s0 и s1 зарезервированы. s0 под текстуру спрайта, а s1 - под кисти наложения (оверлеи).
Привет, классная библиотека!
Это ты здорово придумал, обернуть d3d9x.dll.
А к какой именно версии у тебя d3dx9.lib?
Последние обновление D3DX9_43.dll датируется 26.05.2010, вроде бы как...
Привет. У меня последняя версия с статической линковкой (.lib файл) (Summer 2005). Следущая уже шла с d3dxXX.dll.
А что ты имел ввиду под "обернуть d3d9x.dll"?
Имел ввиду, что в целом хорошая идея использовать C++/CLI, что бы сделать свою библиотеку такого рода :)
Глупый вопрос, наверное, но как отключить логи?
По умолчанию в папке с откомпилированным приложением при каждом запуске создается файл логов. Не то чтобы это сильно мешало, просто интересно.
Log.Configure(false, null);
Это должно отключить логирование полностью, включая системную консоль. Вызов следует сделать ещё до создания инстанса игры/инициализации приложения.
Движок, работает под Win64, Vista?
Да, работает, основная разработка идёт на Win7 x64.
*Наивный вопрос* Возвращение к движку автором планируется?
Возможно, если автору будет интересен проект, который на движке хотят сделать. И, что важно, автор насколько поменял мировозрение за 2 года, что ему придется переписывать движек с нуля, что бы его не тошнило :)
AlexKhomich
Ого, какие люди! Привет!
Считаю твой движок лучшим решением для разработки 2д игр на .NET.
Однако есть некоторые моменты, которые считаю неудобными/неправильными:
1. В игровом цикле используется Application.DoEvents - здесь написано, почему так делать нельзя: [1] и [2]
2. Решение о том, чтобы сделать Спрайты immutable - это, возможно, грамотное решение, но только если бы спрайт был легковестным value-типом, который можно было бы аллоцировать на стеке. Сейчас же получается, что для таких элементарных вещей как flip - надо создавать новый объект.
Столкнулся вот с такой ситуацией: анимация персонажа представлена в виде сетки, я ее грузил SpriteGrid'ом, но персонаж нарисован "в одну сторону", чтобы повернуть его обратно, нужно было делать flip спрайта текущего кадра анимации = создавать новый объект.
3. Рендеринг текста. Провел простой эксперимент: создал окно в котором рендерил много тайлов. Прогнал профайлером и офигел, что hotpath-ом является вывод фпс. Время на отрисовку моих тайлов было ничтожным по сравнению с лежащей под замером фпс работой. Там самое слабое место - getHashCode - взятие каких-то там таймеров по хэшу, это дело создает безумную течку памяти.
4. Типы Vector, Rect и прочие надо наверное не в неймспейс Vortex.Graphics, а просто в корень - Vortex или Vortex.Types.
А так в целом, ничего удобнее не видел. Правда нужно дизайн максимально продумывать с точки зрении использования памяти. Все эти конструкции using( canvas <= xxx ) нужно на этот предмет особенно проверять.
Тема в архиве.