forum.boolean.name
Страница 60 из 70 « Первая < 1050545556575859 60 616263646566 > Последняя »
Показывать 64 сообщений этой темы на одной странице

forum.boolean.name (http://forum.boolean.name/index.php)
-   Проекты C++ (http://forum.boolean.name/forumdisplay.php?f=56)
-   -   [TrueHorror] - разработка (http://forum.boolean.name/showthread.php?t=17293)

Samodelkin 21.05.2015 16:08
Ответ: [TrueHorror] - разработка
 
Можно попробовать даже Self-Shadowed Radiosity Normal Mapping. В игре чел ходит с фонарём или зажигалкой по темной пещере так что свет падает под острым углом к поверхности, так что самозатенение бампа весьма кстати.
Проблема только в том что для генерации нужны также и карты высот, а Wegox делает сразу лоу-поли и ищет подходящие нормал-карты. Найти соответствующие друг-другу нормал-карты и карты высот и так чтобы они подходили к общей геометрии не так-то просто. Применение эффекта с неправильными картами скорее только ухудшит общий результат рендеринга.

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

mr.DIMAS 29.05.2015 18:57
Ответ: [TrueHorror] - разработка
 
Вложений: 8
Появилось еще немного времени на игрушку. Недавно скачал юнити 5, поковырял новый гуй, и понял что хочу такой же. Действия кнопочек\слайдеров\радиокнопок выполняются через делегаты, но в цпп нет делегатов. Пришлось запилить.

Код:
class ruIContainer {
public:
    virtual ~ruIContainer() {   

    };

    virtual void Call() = 0;
};

template< class T, class M > class ruContainer : public ruIContainer {
private:
    T * mClass;
    M mMethod;
public:
    explicit ruContainer( T * theClass, M  theMethod ) : mClass( theClass ), mMethod( theMethod ) {

    };

    virtual void Call() {
        (mClass->*mMethod)();
    }
};

class ruDelegate {
private:
    ruIContainer * mContainer;
public:
    ruDelegate() : mContainer( nullptr ) {

    };
    ~ruDelegate() {
        if( mContainer ) {
            delete mContainer;
        }
    }
    ruDelegate( const ruDelegate & other ) {
        mContainer = other.mContainer;
        (const_cast<ruDelegate&>(other)).mContainer = nullptr;
    }
    template< class T, class M > static ruDelegate Bind( T * theClass, M  theMethod ) {
        ruDelegate delegat;
        delegat.mContainer = new ruContainer< T, M >( theClass, theMethod );
        return delegat;
    }
    void Call() {
        if( mContainer ) {
            mContainer->Call();
        }
    }
    void operator = ( const ruDelegate & other ) {
        mContainer = other.mContainer;
        (const_cast<ruDelegate&>(other)).mContainer = nullptr;
    }
};

class ruEvent {
private:
    vector<ruDelegate> mListenerList;
public:
    void AddListener( const ruDelegate & delegat ) {
        mListenerList.push_back( delegat );
    }

    void RemoveAllListeners() {
        mListenerList.clear();
    }

    void DoActions() {
        for( auto iter = mListenerList.begin(); iter != mListenerList.end(); iter++ ) {
            iter->Call();
        }
    }
};
Пользуюсь так
Код:
... где-то внутри класса Menu
button.AddListener( ruDelegate::Bind( this, &Menu::OnButtonClick ));
Плюсы делегатов для гуя можно перечислять долго, но от себя скажу, что с ними я запилил модальные окна для вопросов, анимацию элементов меню и много еще чего. И все очень удобно, не нужно городить неведомый спагетти-код.

Немного скриншотов, графон в гуй не завезли - и скрины заболели джпегом. Кстати последние скрины с исправленным хдр и без него.

Samodelkin 29.05.2015 20:04
Ответ: [TrueHorror] - разработка
 
Цитата:
с ними я запилил модальные окна для вопросов
То есть проблема активных элементов решена и можно перекрывать одними окнами другие при этом управление будет захватывать только активное окно? В том числе и перехватывать управление с персонажа, если я вожу курсор то перс не поворачивается?

mr.DIMAS 29.05.2015 20:15
Ответ: [TrueHorror] - разработка
 
Не понял вопрос. Модальное "окно" это на скрине в менюшке по центру. Фокуса у "окон" все равно нет - ибо это не окно, в привычном понимании. Ну если фокус слетит с главного окна приложения, то перс все равно будет поворачиваться и мышка в меню будет ездить. Чтобы это убрать, мне надо выпилить DirectInput из движка и юзать сообщения окна и RawInput для получения скорости мыши.

Samodelkin 29.05.2015 21:01
Ответ: [TrueHorror] - разработка
 
Речь идёт об окнах GUI. Модальным называется окно, которое блокирует работу приложения, пока от пользователя не будет получен ответ. Это значит, что пока пользователь не нажмёт Да или Нет (или другую доступную кнопку), то он не сможет переключиться на любое другое окно (или в случае игры наверное и продолжить игру не сможет -- хотя тут на усмотрение разработчика). В случае с примером на скрине, главное меню должно быть заблокировано.

mr.DIMAS 29.05.2015 21:38
Ответ: [TrueHorror] - разработка
 
Нет, меню не блокируется, и не надо - например, жмешь Новая игра, а потом вспоминаешь что хочешь загрузиться, и можно смело жать Загрузить игру. Про то что такое модальное окно я знаю, хз почему назвал то окошко модальным.

Samodelkin 29.05.2015 21:55
Ответ: [TrueHorror] - разработка
 
Возможно в данном конкретном случае блокировать и не надо, но этот механизм нужен для структуризации интерфейсов. Если для каждого окна прописывать что блокируется а что нет, то по мере увеличения количества окон код будет увеличиваться в геометрической прогрессии. Я подумал что раз ты начал делать делегаты, то видимо хочешь создать какой-то задел, чтобы в более сложных играх, например RPG создавать сложные интерфейсы, тогда понабиться универсальный подход, предусматривающий работу с перекрытием и иерархией окон, не усложняющий и не увеличивающий размер кода в зависимости от количества окон. Такой же как с делегатами -- они же теперь универсальные и работают с любым количеством действий.

mr.DIMAS 29.05.2015 22:04
Ответ: [TrueHorror] - разработка
 
Действительно, надо будет сделать перекрытие и блокировку окон.

mr.DIMAS 31.05.2015 16:03
Ответ: [TrueHorror] - разработка
 
Понадобились освещаемые частицы. И сразу затык с блендингом словил. Мне нужно отрендерить частицы с аддитивным блендингом для правильного освещения, и в то же время нужно чтобы частицы использовали альфа канал. Если я рендерю с аддитивным - то альфа не учитывается, если учитываю альфу( D3DRS_SRCBLEND = D3DBLEND_SRCALPHA, D3DRS_DESTBLEND = D3DBLEND_INVSRCALPHA ) - то с каждым новым источником света частицы становятся темнее. Что я делаю не так? Может рисовать частицы в текстуру и потом их уже аддитивно рендерить на экран?

Mr_F_ 31.05.2015 16:21
Ответ: [TrueHorror] - разработка
 
Попробуй srcBlend = srcAlpha, destBlend = one. Типа умножил цвет на альфу и сложил с экраном.

Samodelkin 31.05.2015 16:41
Ответ: [TrueHorror] - разработка
 
http://techblog.floorplanner.com/ren...rred-pipeline/
Для частиц самое то, только надо их разбивать на не пересекающиеся группы, и рисовать каждую группу за раз.

mr.DIMAS 31.05.2015 16:55
Ответ: [TrueHorror] - разработка
 
С таким блендингом работает, но прозрачность частицы почему-то зависит от освещенности.

Код шейдера http://pastebin.com/h6qP2BKp

Mr_F_ 31.05.2015 17:02
Ответ: [TrueHorror] - разработка
 
Цитата:
но прозрачность частицы почему-то зависит от освещенности.
Логично, это же аддитивный бленд. Ярче - сильнее видно, чернее - слабее видно. Вряд ли тебе он нужен - не знаю, зачем ты задумал его юзать.
Дым всякий надо рисовать с обычным блендом.

Цитата:
с каждым новым источником света частицы становятся темнее. Что я делаю не так?
такого быть не должно - хз что не так. В шейдере у тебя один лайт.

mr.DIMAS 31.05.2015 17:03
Ответ: [TrueHorror] - разработка
 
Ну так аддитивный мне нужен для множества лайтов.
Цитата:
Дым всякий надо рисовать с обычным блендом.
А освещение?

Mr_F_ 31.05.2015 17:43
Ответ: [TrueHorror] - разработка
 
Цитата:
Ну так аддитивный мне нужен для множества лайтов.
мультипасс? ну разве что ты каждый отдельно отсортированный объект будешь рисовать сначала с амбиентом и альфой обычной, потом с вышеуказанным блендом аддитивно на каждый лайт, потом следующий объект так же - тогда проканает.
производительность конечно очень сомнительная будет.
если бы ты делал tiled деферед, можно было бы освещать альфу так же, как и неальфу.

дешёвый вариант, который иногда вполне канает: считаешь среднее освещение приходящее в середину каждого альфа-объекта в виде сферической гармоники или просто с 6 сторон, типа сумма saturate(dot(lightN, vec)), где vec = float3(1,0,0), float3(-1,0,0), float3(0,1,0) итд. Потом рисуешь форвардом альфа-объекты, применяя одну гармонику/куб света на весь объект.


Часовой пояс GMT +4, время: 02:01.
Страница 60 из 70 « Первая < 1050545556575859 60 616263646566 > Последняя »
Показывать 64 сообщений этой темы на одной странице

vBulletin® Version 3.6.5.
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Перевод: zCarot