Wpis z mikrobloga

@TadeuszSynZygmunta: Nie nie mogę używać assetów Jamesona. Mechanik nie mam po co kopiować, bo ta gra opiera się na czymś zupełnie innym, ale nie chcę jeszcze kłapać dziobem. Owszem będzie walka, handel i kopanie w asteroidach, ale zupełnie inaczej niż w Jamesonie. Moje umiejętności graficzne też poszły do przodu i nie zależy mi na tych zacofanych pixelartach.

Teraz opieram się na takich digitalach bez poszanowania praw pixelartu, lepiej to wygląda, ma
Pobierz rezoner - @TadeuszSynZygmunta: Nie nie mogę używać assetów Jamesona. Mechanik nie mam...
źródło: comment_ZU0cHVARyo5sHkPyoy9WWpSnMKOGrqS4.jpg
@regis3: Byłbym dalej z robotą, gdybym nie dyskutował ciężko o zaletach/wadach tworzenia GUI w "immediate mode" - znaczy, że zamiast tworzyć jakiś tam obiektowy model swojego GUI, tworzysz i obsługujesz je w pętli gry na bieżąco - tak jakbyś rysował canvasem - http://jsbin.com/qumowi/3/edit?js,output

Dla mnie to jakaś mitologia, która kuleje jak tylko pojawiają się drag-n-dropy, layouty, animacje i poważna komunikacja między widgetami a grą. Nie mówiąc jak chcesz zmeinić logikę tego
@rezoner: Rozumiem :) Ja wolę ostatnio klasyczne i skuteczne podejście. Tzn takie jak w natywnych rozwiązaniach GUI (c# winforms, czy delphi vcl czy jakie tam inne). Wymyślałem kilka razy coś swojego ale zawsze wracam do tego. W sumie wszędzie widzę 2 podejscia. Albo to stare i sprawdzone imperatywne, albo trochę odświeżone gdzie mamy jakiś język opisu okien (qml, xaml, w sumie html).

Podobno w wielu grach stosuje się GUI tworzone we
@regis3: Ja ostatnio nawet z dziedziczenia zacząłem korzystać (to takie małe tabu w js). Chyba wiek buntu mija ;p

Z perspektywy lat wydaje mi się, że to co było w Delphi / C++ Builder to jedno z najbardziej niedocenionych rozwiązań w kwestii GUI.