Skocz do zawartości
  • Ogłoszenia

    • Uzjel

      GMClan wrócił!   12.08.2017

      GMClan.org już działa, więc jeżeli ktoś wchodził przez adres forum.gmclan.org to może już wrócić do starych zwyczajów. Jeżeli strona wam się nie wyświetla to wyczyście cache i ciasteczka.
    • gnysek

      Świętujemy urodziny GMCLANu ?   16.08.2017

      Wypowiedzcie się! http://forum.gmclan.org/index.php?/topic/34002-15-lat-gmclanu-świętujemy  

Exigo

Użytkownicy
  • Zawartość

    1168
  • Rejestracja

  • Ostatnia wizyta

Reputacja

0 Neutralny

O Exigo

  • Tytuł
    Master of Posts
  • Urodziny 05.10.1993

Contact Methods

  • Website URL
    http://

Previous Fields

  • Steam
    exigow

Profile Fields

  • Skąd
    Warszawa
  • Płeć
    Male
  1. Warlocks 2: God Slayers

    @Anty, kto jest autorem tych konceptów? Macie kogoś nowego w teamie (ostatnio wrzucaliście oferty na skillshota)? Tak zwyczajnie pytam, z ciekawości, bo koncepty pełną gębą. ;>
  2. Optymalizacja draw

    Pierwszy pomysł: Niewykluczone że Game Maker ma wbudowany sprite batching, więc można mu pomóc rysując wszystko "wszerz", a nie "w głąb". Szkopuł tkwi w tym, że obiekty nie mogą na siebie nachodzić (obiekty, nie sprite). Poniżej pseudokod który pokazuje jak rysujesz obecnie (dla porównania). Poniżej pseudokod który może przyśpieszyć. W pierwszym rozwiązaniu VBO resetuje się za każdym razem przed narysowaniem tekstury (zakładając że nie używasz atlasu tekstur), czyli masz 3750 draw calli. W drugim rozwiązaniu tekstura zmieniana jest jedynie tyle razy, ile masz tekstur (czyli wyjdzie coś koło ~kilkunastu draw calli). Nie mam benchmarka na potwierdzenie, ale w innych silnikach taka strategia działa, tylko że bardziej komplikuje kod (optymalizacje mają to do siebie że komplikują, kek). Drugi pomysł (nie wyklucza się z pierwszym): Jeśli obrazki nie są dynamiczne, możesz rysować planszę do surface i przerysowywać ją tylko wtedy, kiedy coś się na niej zmienia. Przełączanie bufora (surface_set_target i surface_reset_target) może mieć duży narzut, czyli nie możesz robić tego per obiekt w evencie draw, ale globalnie, raz na klatkę lub rzadziej (bo inaczej będą krótkie "przywieszki" podczas przerysowywania; będziesz miał 25x25 bind calli). Trzeci pomysł (też się nie wyklucza): napisz swój shader wycinając niepotrzebne rzeczy (np. z blending który jest podawany jako atrybut w defaultowym shaderze). Elo.
  3. Galeria Grafik

    @I am Lord, nie jestem w stanie wskazać konkretnych źródeł. Musisz jednak zrozumieć że GLSL to dosć specyficzny język programowania i nie da się "nauczyć shaderów". Możesz nauczyć się języka, ale w zależności od tego co będziesz chciał robić (oświetlenie, rozmycie, etc.) to będziesz musiał odpowiednio dokształcić się w temacie żeby w ogóle wiedzieć co chcesz zrobić. W 90% przypadków będziesz adaptował gotowe rozwiązania, a nie pisał od zera. Większość rzeczy jest już wymyślona, tylko trzeba poskładać to w kupę żeby wyszło coś fajnego. Polecam stronkę ShaderToy jako źródło inspiracji, rozwiązań, oraz prezentacji tego co można zakodzić przy pomocy shaderów. Btw. warto śledzić ogarniaczy którzy poświęcają swój czas aby opisać "jak rozwiązałem pewien problem" by podzielić się tym na swoim blogu. Np. ostatnio dużo czerpałem z tego wpisu implementując flary anamorficzne (artefakty kamery) o których chyba kiedyś wspominałem. To jest jeden z przykładów, a takich jest bardzo dużo w sieci. @Milena78, dzięki. Co do pytania: polecam materiały tego typu co podlinkowałem wyżej.
  4. Galeria Grafik

    @I am Lord, 10% całego kodu gry to shadery w GLSL, czyli całkiem sporo. Z gameplayem średnio, bo jedyne co można na tą chwilę zrobić to przemieszczać jednostkami. Wygląda na to że muszę zmienić priorytety. @Ignatus, docelowo chcę aby mechanika dzieliła się na dwie warstwy: pierwsza, główna, to taktyczna gra czasu rzeczywistego w której musisz wygrać bitwę posiadając z góry narzucony pakiet jednostek posiadając na boku jakąś mini-misję, a druga, w skali makro byłaby bardzo uproszczoną turówką w której musisz podbić galaktykę podzieloną na regiony dające pewne bonusy, np. unikalną jednostkę lub takie, które wzbogaciły by bardziej mechanikę (np. dwie akcje na turę, czy coś w tym stylu). @koziu, założę się że twoja gra przy obecnym stanie rzeczy ma bardziej zaawansowany design od mojej.
  5. Galeria Grafik

    Miałem lekką przerwę z RTS-em, ale niedawno wróciłem do prac. Przepisałem sporą część kamery i renderera odchodząc od rzutu ortogonalnego i sztucznie wyliczanej paralaksy na rzecz perspektywy; batcher ma teraz oś Z. Musiałem dopisać frustuma do obcinania sceny (wcześniej to był prostokąt) oraz reprojekcję myszki ekran->świat żeby można było kontrolować jednostki. Działa. Póki co, materiałów zawartych poniżej jeszcze nigdzie nie wrzucałem po za GMC. * Nowy efekt silników wzorowany na samolotach odrzutowych (są bardzo charakterystyczne). Tu gif: http://imgur.com/Dljy8vO * Tu gif jak sobie latają z widocznym efektem (nowej) paralaksy: http://imgur.com/KLnPVcF * Album do którego wrzucam co jakiś czas nowe animacje / screenshoty, pełniący rolę pamiętniczka lub devloga: http://imgur.com/a/IQG1D Poniżej prezentacja nowego świata:
  6. Galeria Grafik

    Zamockowałem interfejs przed właściwą implementacją. Te widgety (bloki z paskami na górze) mogą być (będą) klikalne. Na przykładzie jest "grupa 3" oraz "formacja delta". Podczas aktywacji widget płynnie się rozszerza oraz rozjaśnia. Tła widgetów rozmywają treść znajdującą się za ich warstwą + lekki overlay. Taka jest cała idea. Czcionka to Microgramma. Obawiam się że ograniczenie kolorów (wszystko jest monochromatyczne) utrudni czytelność (brak czerwieni/zieleni).
  7. Galeria Grafik

    @Wojzax, ogarnij jeszcze rigowanie, bo bez tego postacie nie mają żadnej wartości poza tej prezentacyjnej (szczególnie że masz go w T-pose więc kwestia dodania kości). W twoich pracach z modelu na model jest coraz bardziej pro. :) @I am lord, fakt. Myślałem o dodaniu dodatkowej "warstwy" do logiki poruszania statków, coś w stylu flockingu/boidów. Kiedyś zrobiłem proof of concept tej techniki (symulacje na bazie agentów), napisane w Scali, tutaj link do projektu na githubie. Asteroida generowała by wektor separacji jak reszta statków, ale zdecydowanie większy. Bardzo proste rozwiązanie. Wracając, obecnie jest dużo kodu odpowiedzialnego za relacje squadów oraz jednostek między nimi, które mogą mieć wspólne cele (atak/ruch do punktu/etc.) łącząc się w tymczasowe kolektywy które się rozpadają po osiągnięciu celu. Kiedyś trawiłem na write-up od programisty z Ensemble Studios, Dave-a Pottinger-a, który w obszerny sposób opisał parę patentów na przemieszczanie się jednostek w ichniejszych RTS-ach. Aż kupiłem Age of Mythology na Steamie żeby sobie to samemu przeklikać; taka mała inżynieria odwrotna. Oczywiście nie skończyło się na klikaniu, a na maratonie przejścia wszystkich kampanii (nie mogłem się powstrzymać tej pokusie, gra jest za dobra). :jezor: Przed chwilą zacommitowałem proceduralne generowanie asteroid na podstawie tekstury-mapy. W skrócie: wczytujecie bohomazy, a z czerwonego kanału generowana jest mapa asteroid. Poprawiłem też rysowanie kamieni. Ziarno pseudo-losowości brane jest z pozycji i intensywności koloru (random to mersenne twister - daje najlepsze efekty). Generalnie ustaliłem sobie za cel łatwą edycję treści. W tym przypadku odpalając MSPainta otrzymuje się pełnoprawny "edytor map". Złożone dane przetrzymywane są w JSONach (statki, definicje materiałów do renderowania, etc).
  8. Galeria Grafik

    @hamtaren, tak, Homeworld jest główną inspiracją. Ostatnio ograłem Deserts of Kharak i przez klimat już do reszty mi odbiło. Co do drugiego planu: wcześniej była bieda i same statki. Nie dało się zorientować w przestrzeni (przez brak "uchwytu" dla oka). Od kiedy dodałem jakieś statyczne asteroidy w tle, jest już lepiej. Docelowo chcę uzyskać jakąś sztuczną perspektywę (ale nie wpływającą na gameplay; jedynie jako efekt wizualny) oraz delikatny pył dla podkreślenia głębi. @Nikas, no żyję. :) Jakoś ostatnio urwał się kontakt. Teraz jest jakiś wysyp jamów/eventów więc można utworzyć okazję i zobaczyć się.
  9. Galeria Grafik

    Dawno się tu nie udzielałem. :) Sorry za 13MB. Nie potrafię robić gifów. Wyłączyłem UI na czas nagrania. Piszę w wolnych chwilach, po za pracą i życiem. Tech to LWJGL + Kotlin (swoją drogą, ######sty język).
  10. Zmniejszenie Draw Calls

    Być może źle używasz batchera. Powinieneś mieć, nie wiem, coś koło max 3-4 draw calle na klatkę. Największy performance uzyskasz używając atlasu tekstur. Winowajce masz tutaj (przykład): https://github.com/libgdx/libgdx/blob/maste....java#L232-L233 (linie 232-233). Każde przełączenie tekstury wymusza flusha, czyli wyrenderowanie i całkowity reset VAO który uzbierałeś do buforu - tym jest właśnie draw call. Jeśli jednak koniecznie nie chcesz używać atlasu, posortuj chociaż rysowania po teksturze, czyli coś w stylu: najpierw wszystkie chmurki, potem wszystkie gwiazdki, etc. Ale to będzie trochę na około problemu (da się zejść do poziomu 1 call == 1 aktywna tekstura). Ostatecznie możesz też zmodyfikować batchera i jego shader; wymaga to lekkiej znajomości OpenGL-a (+ GLSL-a). Samo API dostarcza taką możliwość. Batcher, w założeniu, służy "do wszystkiego" i jest idioto-odporny, więc ma nawalone jakichś zbędnych macierzy, dodatkowych atrybutów (niepotrzebny color? przez które jest potem wszystko przemnażane (a przez cały lifetime shadera wynosi vec4(1, 1, 1, 1) i zaśmieca VAO)), etc., dużo ficzerów których pewnie i tak nigdy nie użyjesz. Jak się postarasz i sprecyzujesz co dokładnie chcesz rysować, z połowę tych rzeczy można zwyczajnie wyciąć, co zoptymalizuje sam shader jak i CPU który jest akurat największym bottleneckiem dla batchera (bo skalowanie, rotacja, translacja - wszystkie są na cpu, TAK, CPU!, czytaj: wszystkie przekształcenia macierzowe (w 2d jest proste cos/sin, ale wciąż), robi Java a nie karta). Np. niesamowicie da się zoptymalizować renderowanie sceny opartej o siatkę (przykład z życia). Mam nadzieję że pomogłem. :) Polecam przejrzeć source i zobaczyć jak on działa. Im więcej rozumiesz co jest w środku, tym większe triki możesz z tym robić. Dawno tu nie pisałem. ;D
  11. 7 Zjazd Twórców Gier (2014)

    Dobra, jadę.
  12. Optymalne wczytanie mapy z pliku

    Jest też opcja zapisywania tego w bitmapie - w sumie najciekawsza z możliwych. :D Tylko nie wiem jak z prędkością odczytywania kolorów z piksela. Plus jest taki że nie musisz sobie pisać dedykowanego edytora (jak to ma miejsce w plikach binarnych), a jedynie zwykły Paint wystarczy do edycji. Zapisujesz sobie do kanału R typ obiektu, a na B kąt - zostały ci jeszcze dwa puste (oczywiście nic nie stoi na przeszkodzie aby obsługiwać sobie więcej niż jedną bitmapę).
  13. Optymalne wczytanie mapy z pliku

    No to posortuj sobie obiekty aby mieć gwarancję zachowania kolejności. Ustaw jakąś flagę na początku pliku jaka jest maksymalna szerokość i wysokość. Nie będziesz musiał wtedy odczytywać wartości w stylu "[b_88X96]". W ogóle wrzuć najlepiej cały plik, bo w sumie nie wiem na czym tak naprawdę pracujesz (czy określasz puste pola czy nie). Btw. obczaj to: https://github.com/bjorn/tiled/wiki/TMX-Map-Format Jest to chyba najbardziej popularny format do tile-map. Możesz sobie dopisać jakiś prosty parser tego, lub po prostu się zainspirować. :)
  14. Optymalne wczytanie mapy z pliku

    Spróbuj zapisywać binarnie, nie tekstowo. Dostaniesz kilkukrotnego boosta przy wczytywaniu.
  15. Jaki język i jaki kurs?

    Co ty na to? Bardziej multiplatformowo już się nie da.
×