Skocz do zawartości

PsichiX

Użytkownicy
  • Postów

    5 647
  • Dołączył

  • Ostatnia wizyta

  • Wygrane w rankingu

    12

Treść opublikowana przez PsichiX

  1. @Ignatus Ad. 1. cytując z dokumentacji w skrypcie: id - identyfikator przebiegu renderowania (czyli jakaś nazwa po prostu); view_index - numer viewa, do którego należeć będzie ten przebieg. Działa to tak, że jeśli dasz -1 to pass będzie renderował się dla każdego viewa, czyli będzie zapisywał informacje do swego surface ze wszystkich viewów, ale jeśli podasz np. 0 to będzie zapisywał informacje o obiektach renderowanych wyłącznie w view[0]. clear_color - kolor, jakim wypełni się surface zanim zacznie zbierać informacje o obiektach. stosuje się to po to, by wyczyścić surface. clear_alpha - alpha, jaką wypełni się surface zanim zacznie zbierać informacje o obiektach. stosuje się to po to, by wyczyścić surface. target - id obiektu lub obiektów, które mają być brane pod uwagę przy zapisie do surface przebiegu. możesz podać id konkretnego obiektu, grupy obiektów (np. obj_fire, stała all, czy parenty różnych obiektów - obj_dirt) Ad. 2. patrząc na listę dodawanych passów, mamy kolejno: multipass_add("dirt_mask", 0, c_black, 0, obj_dirty); multipass_add("dirt_color", 0, c_black, 0, obj_dirt); z tego wiemy, że będziemy zbierać 2 rodzaje informacji o obiektach: maski zabrudzeń, oraz kolor zabrudzeń. dla informacji masek zabrudzeń (dirt_mask) będziemy zbierać informacje o obiektach typu obj_dirty, a obiekt ten jest parentem dla wszystkich innych obiektów, które mają być oznaczone jako zdolne do brudzenia się krwią, a więc wszystkie obiekty na scenie gry, które chcesz, by były zdolne do brudzenia się, nadajesz im parenta obj_dirty. Do takich obiektów należeć mogą ściany, jakieś przedmioty w pomieszczeniach, najpewniej to, co nie jest podłogą. Podobnie ma się rzecz z obiektami, które mają brudzić, czyli wystarczy, że obj_blood będzie miał parenta obj_dirt, to wszystkie obiekty krwi trafią do surface przebiegu dirt_color. Ten system nie wymaga tworzenia obiektów w jakiś szczególny, niestandardowy sposób, tworzysz je tak samo jak zawsze - system podczas zbierania informacji o obiektach do swoich surfacesów ogarnia wszystkie obiekty na scenie oznaczone identyfikatorem przekazanym w ostatnim argumencie funkcji multipass_add(). Ad. 3. tak jak wyżej to opisałem: obj_dirt to parent dla wszystkich innych obiektów, które mają brudzić, jest to taka grupa obiektów brudzących. obj_dirty zaś jest parentem dla wszystkich obiektów, które mają przyjmować na siebie zabrudzenia. Ad. 4. wystarczy, że utworzysz go na scenie i będzie on posiadał parenta obj_dirt. Jest jeszcze jedna ważna rzecz, którą muszę wyjaśnić, otóż: jak zapewne zauważyłeś w kodzie draw obiektów tv, coach, blood i innych, mają one w sobie linijki takie jak ta: if (multipass_current() == "dirt_color") { draw_self(); } chodzi w tym o to, że event draw obiektu może być wywoływany wiele razy dla wielu przebiegów, które zechcą pobierać informacje o danej grupie obiektów. Dajmy na to, dodam dwa przebiegi, które oba jako target podadzą ten sam typ obiektów all. a więc event draw Twojego obiektu wywoła się nie raz, jak normalnie, ale aż 3 razy (raz dla sceny normalnie, oraz dwa dodatkowe razy bo dwa przebiegi zarzyczyły sobie informacji o wszystkich obiektach sceny) - tym kodem wyżej upewniamy się, że nasz obiekt będzie rysowany tylko i wyłącznie dla przebiegu o nazwie "dirt _color" i będzie niewidoczny dla innych przebiegów oraz nie zostanie narysowany na scenie normalnie, bo chcemy by kolor krwi był tylko w surface przebiegu, którym potem zmiksujemy krew z maską zabrudzeń i w ten sposób dostaniemy finalne obsmarowanie krwią widoczne tylko tam, gdzie są obiekty brudzące się. Jeśli nie dodasz tego sprawdzania bieżącego przebiegu, wtedy krew zostanie narysowana zarówno na scenie normalnie, jak i w każdym surface każdego przebiegu, a tego nie chcemy. Jeśli chcesz, aby jakiś obiekt rysował się normalnie na scenie, ale także rysował jakiś swój inny wariant dla jakiegoś przebiegu (np. chcesz aby na scenie obiekt rysował żarówkę, ale też chcesz, aby dla przebiegu "glow" narysował poświatę światła emitowanego przez żarówkę), to wtedy kod wygląda coś jak to: // rysujemy poświatę żarówki dla przebiegu "glow": if (multipass_current() == "glow") { sprite_index = spr_glow; // na chwile zmieniamy sprite obiektu na poświatę. draw_self(); // rysujemy obiekt. sprite_index = spr_lightbulb; // przywracamy obiektowi sprite żarówki. // rysujemy obiekt żarówki normalnie dla sceny gry: } else if (multipass_current() == undefined) { draw_self(); } Ad. 5. zależy jak dokładną informację potrzebujesz. Generalnie to co Cię interesuje najbardziej to shader ten bierze 2 tekstury z surfacesów dwóch przebiegów "dirt_mask" oraz "dirt_color" i dla każdego piksela ekranu kolorem wynikowym RGB będzie kolor tekstury dirt_color (czyli kolor zabrudzeń, tutaj krwi) zaś kanałem alpha będzie kanał alpha tekstury "dirt_mask" przemnożony przez kanał alpha "dirt_color" - obrazowo to działa tak, jak nazwa "maskowanie" sugeruje: kolor krwi będzie widoczny tylko i wyłącznie tam, gdzie istnieją obiekty maski (czyli obiekty zdolne do zabrudzenia się). Ad. 6. - nie ma żadnej listy - jedyne, co musisz to nadać obiektom krwi parenta obj_dirt oraz dodać im do eventu draw: if (multipass_current() == "dirt_color") { draw_self(); } - tutaj nie ma także żadnej listy - tak samo jak z krwią, musisz nadać obiektom brudzącym się parenta obj_dirty oraz dodać kod do eventu draw: if (multipass_current() != "dirt_color") { draw_self(); } - poza tym wyżej musisz oczywiście dodać do gry skrypty z grupy "multipass" oraz stworzyć obiekt zajmujący się obsługą przebiegów, tak jak to wygląda w obiekcie obj_dirt_multipass_render. Głównie interesują Cię kody: Event Create: multipass_initialize(); multipass_add("dirt_mask", 0, c_black, 0, obj_dirty); multipass_add("dirt_color", 0, c_black, 0, obj_dirt); Event Destroy: multipass_cleanup(); Event Draw: multipass_render(); Event Draw GUI: var sampler_mask = shader_get_sampler_index(sh_dirt, "s_Mask"); var texture_mask = multipass_texture("dirt_mask"); shader_set(sh_dirt); texture_set_stage(sampler_mask, texture_mask); draw_surface_stretched( multipass_surface("dirt_color"), 0, 0, display_get_gui_width(), display_get_gui_height() ); shader_reset();
  2. @Hawaxi pierwsza rzecz, jaka przychodzi mi na myśl to: // calculate saturation of color. float sat = dot(gl_FragColor.rgb, vec3(1.0)); // calculate alpha boolean filter (we get 1.0 only if saturation is not zero). float f = step(0.004, sat); // 1 divided by 255 is ~0.004. // multiply alpha by boolean filter to make black color fully transparent. gl_FragColor.a *= f; Przetestowałem lokalnie i działa - sprawdź jak na iOSie się to zachowuje. W razie czego zwiększ 0.004 i zobacz, na jakiej wartości iOS usuwa czarny.
  3. nie no jasne, ze nie ja, grafa do exampla wzieta z paczek Kenny'ego oraz Asset packow itch.io - ja pixelowac nie potrafie, a zeby efekt fajnie pokazac potrzebowalem jakiejs decent grafiki : D
  4. to imo najciekawsza rzecz, jaką w GMSie dotąd zrobiłem (pomijając to, że GMSa niemal nigdy dotąd nie ruszałem - wierny 6.1! xD)
  5. UPDATE: dokończony example załamań obrazu dla efektów wody oraz ognia. DOWNLOAD: http://storage.psichix.io/MultipassRendering.gmz Nom, to teraz czas na odpowiedź na pytania Ignatusa
  6. @Ignatus dziś nie zdążyłem odpowiedzieć na pytania, ale o takie mi właśnie chodziło i na nie odpowiem przed zrobieniem następnego exampla! A swoją drogą: UPDATE - poprawiłem błąd nieśledzenia view, oraz dodałem example załamań wody (także na maskach), ale nie skończyłem go komentować więc jest WIP. W ruchu wygląda lepiej, bo widać dobrze te delikatne załamania.
  7. ja bym jednak poprosil o narysowanie tego, bo totalnie nie wiem o co chodzi : D
  8. pierwszy na serio powazny projekt forumowy, wielka inspiracja dla wielu projektow wiec dziwnym byloby zeby nie pamietano - to byly swietne czasy widzac jak ludziki ucza sie robic gry dzieki nawiazywaniu do rozwiazan almory : D
  9. @Ignatus a wiem co powoduje ten blad i w nocy go naprawie - blad zwiazany z draw gui: miast rysowac surface jak jest, musze go zeskalowac do rozmiarow okna zeby byl zalezny od rozmiarow okna a co do niezrozumienia to po to tu jestem by wyjasnic to, co niezrozumiale, ale do tego potrzebuje abys mi powiedzial czego nie rozumiesz, a raczej dlaczego nie rozumiesz - czy to wina tego, ze nie rozumiesz komentarzy, a moze co innego? gorsze od niewiedzy jest strach przed zadawaniem pytan, wiec nie krepuj sie bo jestem w stanie wszystko opowiedziec ale musze wiedziec czego nie rozumiesz i co mam wytlumaczyc, inaczej jakakolwiek proba pomocy Tobie skonczy sie fiaskiem
  10. @Uzjel @hgter wrzuciłem na inny uploader i ulepszyłem nieco przykład link w pierwszym poście oraz tu: http://storage.psichix.io/MultipassRendering.gmz
  11. Przykład z gotowymi skryptami bazowymi do zarządzania renderowaniem wieloprzebiegowym. Nazwa może być niezrozumiała, ale zasada działania jest dosyć prosta: pozwala to wyrenderować wiele wariantów tych samych obiektów zależnie od tego, jakie informacje sobie zażyczymy. W tym przykładzie jest to renderowanie informacji o obiektach, które mają się brudzić krwią oraz informacje o obiektach brudu - po wyrenderowaniu tych obu przebiegów otrzymujemy tekstury z tymi informacjami gotowe do uzyskania finalnego zabrudzenia krwią elementów pokoju jak i ścian. W razie niejasności lub niezrozumienia nie bać się, tylko pytać tutaj a ja na każde pytanie z chęcią odpowiem, bez odsyłania do jakichś linków - chcę aby każdy był w stanie na końcu rozumieć zasadę działania i potencjał multipass renderingu jak i cudownych możliwości, jakie ze sobą niesie. Co jakiś czas będę urozmaicał paczkę o nowe przykłady zastosowania, bo jest ich na prawdę masa! Aktualne efekty: Dirt (blood) Distortions (heat and water) Volumetric fog Download: http://storage.psichix.io/MultipassRendering.gmz
  12. osiagi porwnywac mozna, jak wrzucisz na scene jakies 100 lub 1k lub 10k obiektow swf w obu edytorach i wtedy sprawdzic jakie wyniki maja
  13. tu nie chodzi o to, ze nikt nie wie - tu chodzi o to ze ten "najprostrzy" sposob sprawi, ze bedziesz sie jeszcze bardziej z tym miotal, bo ma to restrykcje gdzie na przyklad moga pojawiac sie elementy krwi, a gdzie nie, plus wydajnosc to zabije. my serio staramy sie rozwiazac ten problem na sposoby, ktore pozbawia Cie meczarni i nie zabija aplikacji. to nie jest taki trywialny problem, jak Ci sie wydaje i tutaj w kazdej metodzie zyskujesz cos, tracac cos innego - nie ma tu sytuacji win-win. jak chcesz miec to zrozumiale dla Ciebie, to bedzie to niewydajne i bugogenne, ale zyskujesz wygode prostej implementacji. w druga strone implementacja jest nieco bardziej skomplikowana, ale zyskujesz na wydajnosci.
  14. okej, w domu pokombinuje z tym, dzis raczej nie ale jutro najpredzej
  15. @Ignatus a powiedz mi, z ktorej wersji GMa korzystasz? sprobuje znalezc ominiecie problemu dla niej,
  16. są skomplikowane bo to nie jest taki prosty trick na zrobienie tego w grze z widokiem top-down. jak ja bym to zrobił: dzielisz rendering na kilka passów (pass to w skrócie przebieg renderingu, dla przykładu pierwej renderujesz scenę normalnie do surface, w kolejnym passie renderujesz informacje o światłach do drugiego surface, w trzecim renderujesz same normalki sceny do trzeciego surface, a w czwartym zaś w shaderku renderujesz już kombinację trzech surface na ekran gdzie masz wynikowy obraz oświetlonej sceny z cieniowaniem wypukłości - oczywiście tak się dokłądnie nie robi oświetlenia, ale rozumiesz już jak działają passy renderingu); w pierwszym passie renderujesz scenę normalnie na ekran; w drugim passie renderujesz na biało elementy, na których ma się odkładać krew i zabrudzenia zaś na czarno wszystko to, czego ma nie brudzić, do surface #1 - to będzie maska krwi i zabrudzeń; w trzecim passie renderujesz krew i zabrudzenia do surface #2 - to będzie kolor krwi i zabrudzeń; w czwartym passie rysujesz pełnoekranowy czworokąt z shaderkiem, w którym jako alphe stosujesz któryś z kanałów RGB z surface #1, a kolor zabrudzenia i krwi bierzesz z RGB surface #2. ten pass renderujesz na ekran. jeśli uznasz tę metodę za wartościową, to daj znać to zrobię przykład jak takie coś działa.
  17. 1. upewnij sie, ze odpowiedz z php wysylasz w kodowaniu UTF-8 oraz ze strona html uzywa kodowania UTF-8. 2. zainstaluj sobie dodatek do chrome do debugowania zapytan http, wyslij powyzsze zapytanie i wklej odpowiedz z niego do walidatora JSON online i powiedz, czy widzi odpowiedz jako poprawnie zformatowana i wrzuc jej tresc do posta, to sprawdzimy co dalej mozna z tym zrobic.
  18. w tej aplikacji? zadne. ale jesli juz musza byc to banery male - problem polega na tym, ze starsze osoby i tak nie beda widziec reklam, nie beda umialy ich wylaczyc ani obchodzic sie z nimi, po prostu nie ten target. jesli chcesz przetestowac serwisy, ktore wymieniles, zanim trafia do konkretnej gry, stworz mala, bardzo prosta gierke logiczna, albo zrecznosciowa (np. strzelanie z procy/luku do celu) i wtedy reklamy filmowe mozesz wstawic jako sposob na mozliwosc kontynuowania "misji" po stracie wszystkich szans trafienia perfekcyjnego.
  19. uzytecznosc jest koszmarna dzieki tym logom oraz reklamom - starsze osoby nie beda tym zachwycone
  20. 1. tak jak gnysek mowi - iOSowe safari ma blokade odtwarzania dzwieku, dopoki nie kliknie sie w element strony. musisz dodac jakas warstwe, ktora klikasz i dopiero przechodzi do wyswietlania prezentacji. 2. powodem moze byc duzy rozmiar assetow gry, musialbys sprawdzic ile wazy paczka assetow wygenerowana przez modul HTML5. Druga sprawa to sposob w jaki GM laduje te assety: jesli GM laduje je synchronicznie (co byloby glupie, ale mozliwe i do tego neizgodne z wytycznymi responsywnosci), wtedy przegladarka moze sie zawiesic i ciagle dostarczanie inputu moze wymusic mechanizmy probujace odblokowac przegladarke i w koncu wywalic ja. mozesz sprawdzic i mi opisac, jak GMowe HTML5 laduje assety? Inna sprawa tez, ze generalnie aplikacje canvasowe HTML5 dzialaja wolniej na mobilkach, ktore nie sa tak szybkie jak PCty, a takze sam GM ma bardzo biedny silnik pod przegladarki, ktory dodaje spory narzut wzgledem contentu jaki ma serwowac. 3. Aplikacja canvas HTML5 taka, jak gra, powinna wypelniac caly dokument, oraz na mobilkach uwzglednic device viewport, a samo swipe'owanie powinno byc zaimplementowane w skryptach aplikacji. Ja dla gier przegladarkowych stosuje taki szablon HTML5, jak ponizej: <html> <head> <meta charset="utf-8"> <title>SoulHunter prototype - made with Oxygen game engine</title> <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=0" > </head> <body style="margin: 0; padding: 0"> <canvas id="screen-0" style="width: 100%; height: 100%; cursor: none" onclick="javascript:window.openInFullscreen()" ></canvas> <script src="app.js" type="text/javascript"></script> </body> </html> interesuje Cie glownie drugi tag meta oraz atrybut stylu w tagu canvas jak i styl w tagu body.
  21. nie no, coś Ty - do prototypu użyłem tej ujowej starszej wersji portowanej z flasha D: na emscriptenowego będę zmieniał przed releasem, jak będę miał zaprototypowany cały gameplay i wejdę w fazę optymalizowania gry, nie wcześniej emscriptenowa bedzie hulac w porownaniu do 1:1 portu flasha : D
  22. przed serializacja do pliku zamien wszystkie "dziwne" znaki stringa na ich jakas reprezentacje, ktora zachowa je w jednej linii (np. sposob HTMLowy, czyli %<kod-ascii-znaku>) i przy deserializacji z pliku zamien je z powrotem na wlasciwe - mozesz pokazac, jak wyglada plik INI po zapisie?
  23. Najsss okej, masz jeszcze jakieś uwagi co do prototypu? konstruuje liste rzeczy, ktore wkurwiaja ludzi (oraz dlaczego), zeby do najblizszego builda dodac. Plus, jak bardzo rozgrywka jest nudna i czy masz pomysl moze co mogloby sprawic wieksza frajde z grania? Bo mnie osobiscie rozgrywka nuzy ale to moze byc wina tego, ze non stop w to gram, gdy robie wiec malo miarodajna ocena :<
  24. jestes dopiero druga osoba, ktorej sie to sterowanie nie podoba (pierwsza jest moj ojciec xD) i mimo tego, ze jestescie oboje statystycznym bledem, to ja coraz mocniej mysle o tym, by jednak dodac w opcjach wybor metody poruszania pomiedzy lokalnym a globalnym ukladem odniesienia - dzieki za uwage, jest to cos, co moge dodac od kopa i dodam do nastepnego builda! Swoja droga, jakim cudem Ci to dziala na 7-mio letnim sprzecie? xD ale nie wymieniales czasem jakichs podzespolow (procek/grafika) na nowsze?
  25. Hola, hola, bo zagalopowaliscie sie ze swoimi asumpcjami Pora na male wyjasnienie (ponownie), ktore pozwoli Wam zauwazyc sens tego wszystkiego: Moj cel istnienia jako programisty jest prosty i jasny: biore gowniana technologie i robie wszystko, by wyciagnac z niej jak najwiecej, gdy widze ze tool ma potencjal osiagnac lepsze wyniki. Najstarsi GMClanowcy pamietaja moje poczatki jako tworcy - od samego poczatku robilem Xenona jako plugin do GMa, zamiennik obecnego wtedy gunwianego renderera i byl to calkowicie nowy i diametralnie szybszy renderer niz to, co oferowal GM na czasy GM 6.1. Z czasem przenioslem sie na oficjalne forum GMA (potem YYG) i tam ludzie docenili jego walory, zaczely powstawac podobne projekty i w koncu tworcy GMa poprawili nieco wbudowany rendering na szybszy - cala spolecznoscia sprawilismy, ze GM stal sie lepszy w tym, czym byl najgorszy. Po zalatwieniu sprawy z GMem bralem sie za kolejne narzedzia do robienia gier, wyciagalem z nich jak najwiecej i zglaszalem sie do ich tworcow lub community z dowodem, ze da sie osiagnac wiecej, ale tu i tu jest lipnie, to i to mozna poprawic i jak. Wielu sie podobalo moje podejscie, ze pokazywalem ze ich twory maja ogromny potencjal i razem z commmunity pracowalismy nad poprawa narzedzi - udawalo sie. Pare lat temu mialem nawet zabawny epizod z Click Fusion, bo ludziki tam mieli bardzo ubogie wsparcie dla shaderow i po mojej prezentacji (za ktora dostalem darmowy klucz CF od tworcow zebym mogl dalej grzebac w nim :D) calkiem fajnie ruszyl rozwoj ich wsparcia shaderow A wiec mowiac, ze tym projektem osiagnalem genialniejsze mozliwosci, nizeli oferuja obecne toole gier dla WebGL, wcale nie sklamalem i nie mowilem tego, zeby posmyrac sie po jajach, tylko stwierdzilem fakt - nie ma w tym nic z wygorowanego ego, serio powinniscie wyluzowac - jesli kogos boli to, ze mowie iz robie technologicznie lepsze rzeczy niz X, a jest to prawda, to w ogole nie powinniscie w takim razie reagowac w zaden sposob jak na przytyk, bo ponownie: stwierdzilem tylko fakt, nie sklamalem, a nie zamierzam okrywac siebie zbytnia skromnoscia, jesli ktos mowi mi ze to, co zrobilem jest technologicznie gowniane Wyluzujcie, przestancie sie spinac o byle co
×
×
  • Dodaj nową pozycję...