basic imgui

[gemicha]

Какъв XML? Какъв ексел?

Погледни си address bar на browser-a и ще видиш, че е доста по-сложен, от това, което написах. Има и икони, има и oще бутони.

[stoiko]

докато чакаме да втасат адрес баровете и екселските таблици, ето ви още малко imgui. тоя код е поизтупан и променен но не и gui извикването.

Код: Избери всички

for ( int y = 0; y < INVENTORY_HEIGHT; y++ ) {
    for ( int x = 0; x < INVENTORY_WIDTH; x++ ) {
        int i = x + y * INVENTORY_WIDTH;
        box_t *box = inventory[i];

        v2_t boxPosition = v2Add( windowPosition, v2xy( x * boxSize.x, y * boxSize.y ) );

        boxResult_t res = UI_ClickRect_l( boxPosition, boxSize, i );
        if ( res ) {
            hotPosition = boxPosition;
            hotBox = box;
            if ( res == BR_RELEASED ) {
                return box;
            }
        } else {
            DrawBox( boxPosition, boxSize, boxScale, M_PI / 5, box );
        }
    }
}

if ( hotBox ) {
    float angle = GameTime() * 2;
    DrawBox( hotPosition, boxSize, boxScale * 1.5, angle, hotBox );
    ...
    tooltip code here
    ...
}

[pdimov]

аз очаквах хората да искат някакви анимирани контроли за игри, но явно ще се пише ексел...

exceldev-bg.net

[stoiko]

exceldev-bg.net

[gemicha]

аз очаквах хората да искат някакви анимирани контроли за игри, но явно ще се пише ексел...

exceldev-bg.net

Да, зная, че е сложно, но UI е труден проблем. Започва се с един push button, което е лесно. Оставаш с впечатление, че проблемът е лесен. Играеш си с различни начини на представяне. Правиш го да бъде 1-2 макроса и изглежда супер. После идва следващите няколко контрола. Обикновенно editbox, checkbox, и може би radio control. Editbox не е проблем. Просто повече код. Е трябва да сложиш различни shortkeys и може би clipboard ако си на Windows. И малко по малко навлизаш в проблемът. После ти се иска да имаш ListBox, Combobox, Panels, Tabs, ... Пишеш малко и виждаш, че става по-трудно. Трудно е да се реализират и трудно е да се опишат. Искаш да има картинки, искаш да има различен фон, различен цвят на селекция.

И в този момент си казваш "ама за не пиша ексел". Я да видим как мога да направя целия GUI без Listbox. И почваш да режиш от играта вместо да добавяш. Така хем си с добро усещане за "супер" реализация, хем имаш някакво GUI в играта. Е разбира се не забравяш да посочиш на тези, които са извървяли пътя и не са компрометирали интерфейса на играта си, колко по-зле е тяхната реализация.

Направи всичко, което другия GUI може и тогава сравнявай. Преди това сравнението е невалидно. Ако беше лесен проблем ScaleForm нямаше да съществуват.

Успех с реализацията на ComboBox + autocomplete. Аз съм много заинтересован да видя как изглежда.

[pdimov]

Успех с реализацията на ComboBox + autocomplete. Аз съм много заинтересован да видя как изглежда.

Не знам защо си мислиш, че подобен контрол е някаква огромна философия. Има тук-там тънкости, като например къде се пази състоянието на отвореност и позицията на скрола, че списъкът на горния контрол закрива по-долни контроли, които като код са обичайно под него и са в Z order по-напред, че като отвориш списък на комбо номер 2 списъкът на комбо номер 1 вероятно се затваря, има си малко хамалогия, но нищо кой-знае какво.

Ти направи по твоя начин следното: горе хоризонтален избор на категория, под него вертикален списък с избираеми неща от категорията, и като swipe-неш с пръста наляво, цялата категория барабар със списъка ходи вляво и отдясно идва следващата, плавно, като на iPhone. Това си е клипнато по оригиналния размер. Ако задържиш, виждаш половината от едната вляво, половината от другата вдясно. В краищата може и лек фейд да се вкара за пълнота. Това за N категории по M неща във всяка, като (поради суеверие) може би не искаме да имаме M*N UI обекта активни в паметта винаги. (При Стойко активните UI обекти са константата нула, та той няма грижи с последното изискване )

И това е елементарно, разбира се. Но ако като си писал листчето в началото не си го предвидил, може и да не се окаже толкова лесно.

[gemicha]

Нямам време за подобни упражнения. Работя по доста по-интересни проблеми.

Стойко прояви желание да покаже колко по-добре е неговата библиотека. Аз съм съгласен да погледна какво е направил ако направи нетривиален контрол, а не просто бутон.

[stoiko]

започнах да имплементвам контролите на BIGBUGEX защото за разлика от гемича не решавам никакви интересни проблеми и имам много време:


Имплементация на 1

Код: Избери всички

static void UI_SetContextFace( void ) {
    RT_Face( ui_widgetsContext.face, ui_widgetsContext.faceSize, ui_widgetsContext.faceScale ); 
    R2D_Colorc( r_white );
}

static uiWidgetResult_t UI_SolidRect_wg( v2_t position, v2_t size, int handle ) {
    uiWidgetResult_t res = UI_ClickRect_wg( position, size, handle );
    R2D_Colorc( ui_widgetsContext.colors[res] );
    R2D_SolidRectv( position, size );
    return res;
}

void UI_Record_wg( v2_t position, v2_t size, int numFields, const float fieldSeparators[], const char *fields[], int handle ) {
    v2_t fieldPosition = position;
    float separatorThickness = 1;
    float st2 = separatorThickness * 2;
    for ( int i = 0; i < numFields; i++ ) {
        float step = fieldSeparators[i] * size.x;
        v2_t pos = v2xy( fieldPosition.x + separatorThickness, fieldPosition.y + separatorThickness );
        v2_t sz = v2xy( step - st2, size.y - st2 );
        UI_SolidRect_wg( pos, sz, handle );
        UI_SetContextFace();
        v2_t textPos = v2Add( pos, ui_widgetsContext.faceOffset );
        RT_Printf( textPos.x, textPos.y + sz.y, fields[i] );
        fieldPosition.x += step;
    }
}

Ползване:

Код: Избери всички

// всеки кадър
...
    const char *record[3] = {
        "yoga", "Director", "Offline",
    };
    const float fieldSeparators[3] = { 0.4, 0.3, 0.3 };
    UI_Record_wg( position, size, 3, fieldSeparators, record, 1 );
...

Ползване в цикъл:

Код: Избери всички

    const char *records[NUM_RECORDS][3] = {
        { "yoga",             "Director", "Offline" },
        { "Enji",             "Officer",  "Offline" },
        { "Space Blue Alpha", "Officer",  "Offline" },
        { "Monday",           "Operator", "Fish" },
        { "Nostos",           "Operator", "Offline" },
        { "feanor",           "Operator", "Offline" },
        { "flo02",            "Operator", "Offline" },
    };
    const float fieldSeparators[3] = { 0.4, 0.3, 0.3 };
    for ( int i = 0; i < NUM_RECORDS; i++ ) {
        UI_Record_wg( position, size, 3, fieldSeparators, records[i], 1 + i );
        position.y += size.y;
    }

[Zero_effect]

Сега въпроса е как това нещо се ползва от повече от един thread без да се lock-ва глобалния mutex.

[stoiko]

Сега въпроса е как това нещо се ползва от повече от един thread без да се lock-ва глобалния mutex.

по един instance на thread ако искаш контроли в различни тредове. може би имаш предвид претакане на данни от друг thread? тогава -- каквото си сготвиш. или аз не разбирам въпроса.

[Zero_effect]

Цялата работа е, че имаш един растеризатор, който не е много подходящо да се пипа от много нишки едновременно. Цялата библиотека този факт го заобикаля. Е, за toy project става, но е непрактично за нещо по-голямо. В някой момент ще почне да вкарва чакане в изпълнението и тогава ще почне истинската мъка.

[stoiko]

Цялата работа е, че имаш един растеризатор, който не е много подходящо да се пипа от много нишки едновременно. Цялата библиотека този факт го заобикаля. Е, за toy project става, но е непрактично за нещо по-голямо. В някой момент ще почне да вкарва чакане в изпълнението и тогава ще почне истинската мъка.

какъв е тоя растеризатор? какво значи изпълнение? imgui-то върви в един thread, рендер бакенда обикновено върви в друг. imgui-то извиква фронтенда на рендерера или билд частта или както там и викате, която сортира и сготвя геометрия/дипове за GPU-то. това се прави и с останалата геометрия на играта - мешове, терен, и т.н. пак да каже че може би не разбирам въпроса.

[Zero_effect]

Смисъл готви буфери, които ги точиш всеки кадър на GPU-то. Right. Тоя разговор сме го водили вече колко е efficient целия дизайн от ерата на Quake. Аз разглеждам целия дизайн от гледна точка на това колко е актуален за сегашното поколение GPU-та.

[stoiko]

Смисъл готви буфери, които ги точиш всеки кадър на GPU-то. Right. Тоя разговор сме го водили вече колко е efficient целия дизайн от ерата на Quake. Аз разглеждам целия дизайн от гледна точка на това колко е актуален за сегашното поколение GPU-та.

ама това вече е в рендерера. това според мен няма общо с IMGUI-то. дали ще нарисуваш контролите immediate или deferred, няма значение. затова ти казвам, обясни ми как това че ползваш immediate vs deferred UI води до чакане най-долу в рендер треда. и какво е решението де може би ако не са ти анимирани контролите може да ги кешираш и да не преточваш геометрията... ама това не противоречи на IMGUI. просто няма да ги пращаш всеки кадър...

[Zero_effect]

За да приготвиш въпросния буфер ще ти е необходимо някакво време. Ако просто си ръчкаш от много нишки цялата работа ще доведе до някакъв момент, в който се чака за това данните да станат готови. В най-добрия случай може да се разминеш с някакъв сорт double/triple buffering, за да може да не вкарваш зависимост между нишка, която обработва командите към GPU-то и тази, която ти блъска game логиката. Това, обаче не се споменава никъде, 'щото е ясно, че си правиш проекта single threaded. Разбира се, още по-хубаво ще е, ако се сглабят "command buffer-и" директно и просто се вкарват към останалите за изпълнение. Би било не лошо и да имаш поне малко retained mode, а не цялото нещо да изхвърля напълно буферите между update-ите и да почва отначало с точенето. Това ще гарантира още по-голяма производителност и ще минимизира блокирането между GPU и CPU за извършване на трансфери.

[BIGBUGEX]

Ма "Space Blue Alpha" не се събира. Тва е проблема който визирах. Трябват два паса за тая таблица. Първия за да се изчисли ширината на колоната и втория за самото изчертаване.