3r3se7ven

(macierzy) szerokość * wysokość * głębokość + (macierzy) szerokość * wysokość * moduł sprzężenia (zazwyczaj rozmiaru 2 par bitów na które można zadać dagger) czyli x*y*liczba kolorów + tablica x*y*(dodatnie, ujemne, zerowe, nieprzypisane); O ile karta graficzna nie kombinuje sobie z optymalizacją to zajmie to ceil do rozmiaru windows display h*w.

Bardzo mi się to podoba. Gra o lesie wodorostów?

To nie teoria, to praktyka. W teorii drabina jest prosta jak konstrukcja cepa. Potem dochodzi podły gracz-wielki generator gliczów i równie wredny gameplay i jest kaszan. Nie wiem jaką robisz grę i jak wymyśliłeś próbkowanie przestrzeni. Dlatego podaję potencjalne zgrzyty na jakie się natkniesz przy różnych podejściach. Za parę dni chyba będę w Polsce to wykopię coś z kompa pod GMs. Komplikacja drabiny nie wynika z tego czy to jest platformówka czy nie, tylko z warunków jej działania: -czy start jest oskryptowany i po szynach na górę; <<tutaj odłączasz graczowi kontrolę i jest spokój, jak jeszcze na gameplayu nic nie grozi graczowi to raczej się uda -czy jest interrupt i można zawrócić; -czy gracz sam łazi po drabinie i w jakim zakresie (góra dół, prawo lewo); -czy może z niej skakać, strzelać, inne akcje; -czy na drabinie można zginąć; Jak widzisz pole wejściowych generuje przestrzeń wyjściowych i dlatego specjalne tryby ruchu generują takie problemy. Każde odklejenie postaci od podłoża to takie właśnie zagadki :)

W złą stronę kombinujesz. Co jeśli z jakiegokolwiek urojonego powodu bohater nie dostanie zwrotki z końca drabiny? Bo na przykład próbkowanie ma zbyt rozległe? (to się dzieje jak coś ruszy bohatera). Bohater musi mieć zapis że jest w trybie włażenia po drabinie, a przynajmniej był i właśnie nie jest, i że należy przeprowadzić audyt w sprawie jakiejś podłogi. (na przykład szuka drabiny z której leci). Takie dane pobierasz ze stanu zachowania boahatera tam montujesz triggery wykluczania i wkluczania w fizykę (podłóg). Koncepcja tworzenia bloków końcowych wynika z NESowej zajętości przestrzeni na bardzo dużych blokach przy prędkości maksymalnej jednego bloku w jednostce próbkowania zajętości. Jeśli nie korzystasz z takiej mechaniki to musisz te dane prowadzić ze strony obiektu bohatera. To od bohatera wymagasz ciągłości zdarzeń - drabina - podłoga. Wyzwalacz końca drabiny ma ręce i nogi w takiej mechanice gdy wejście na drabinę i poruszanie po niej jest oskryptowane bez ingerencji gracza (czyli może rozpoznać początek drabiny i kliknąć że włazi, albo nie kliknąć, a jak kliknie to do końca jedzie po szynach). Za tydzień powinien mieć dostęp do gms to mogę Ci przysłać działającego gotowca. O ile pamiętam (kilka lat temu to robiłem), to po rozpoznaniu że drabina była, że dalej się wspina, a drabiny nie ma w promieniu testu szukał sobie podłogi, żeby na nią wleźć i rozpoczynał animację włażenia przez krawędź. Teraz mam na tapecie 3d gdzie już w sposób sterowalny postać łazi po murze góra dół i wertykalnie po przejściu w tryb climbing i przełącza sterowanie z pród/tył na góra dół. To by mogło być rozwiązanie które by Ci pasowało, jeśli na drabinę można wskoczyć i można z niej zeskoczyć. Masz rozpiskę ciągłości stanów bohatera? (character finite state of the machine)? //w jeszcze innym projekcie mam point_distance zbliżenia do drabiny co jest trigerem dla skryptu wyrzucającego ikonę włażenia na drabinie, a dalej po szynach, przy czym długość drabiny nie wynika ze skryptu, to już character dokonaje rozrachunku czy drabina jest, czy starczy włażenia. Bierz pod uwagę, że wiele takich funkcji po mnożeniu (zazwyczej interupt triger przerywający akcję przed jej zakończeniem, jak wybuch, napaść, pułapka) będzie wymagała podobnego mechanizmu szukania sobie miejsca do posadzenia d przez character i rozpoczęcia jakiejś akcji (choćby i leżenia nieprzytomnym). Czyli każda akcja będzie zawierać pole konsekwencji legalnych i zabronionych. //jeśli zależy Ci na ruchu po drabinie góra dół, to warto zrobić pole drabiny działające wyłącznie na animację postaci, a z drabiny robiącą serię półek do wskakiwania, które w trigerze tej animacji będą powiązane ze "skokiem" w górę i w dół o szczebel. To bardzo arcadowe rozwiązanie zeplatformówek strzelanek.

Threef jeszcze raz Ci objaśniam... niekoniecznie rozumiesz co czytasz. Skoro piszę coś o rozwiązaniu problemu to najwidoczniej miałem taki sam i rozwiązałem. W sposób który wg Ciebie sobie przeczy. Bo najwidoczniej później z redukcji do last step wyrasta kolejny problem, i kolejny i kolejny i jakoś trzeba to w końcu rozwiązać globalnie. Gdzieś tu jest zamieszczony przykład mojej starej zrobionej na obiektach i przez to przycinającej gierki o rootach na wielopoziomowej izometrii. Otóż roboty zajmują pewną przestrzeń i ściany też. Można skoczyć jednym an drugi, ale można też zamknąć przesuwane rota na robotach w polu zamknięcia. Najwidoczniej nie utykają mi w ścianach. Choć czasem potrafią wystrzelić z drzwi jak z procy i odbić się od ściany :) Roboty poruszają się po siatce równoważnej dla mp_grid tylko z wykorzystaniem rozszerzonego greed i skracania do słabego JPS. Czyli jak czegoś nie rozumiesz - czytaj jeszcze raz. Do skutku, a jak nie ma skutku - doprecyzuj czego nie rozumiesz. Najczęstsza przyczyna zapytań u programistów "rozwiązanie problemu wygenerowało problem". //============== I nie krępuj się, jak czytam co sądzi o shaderach dentysta z Bergen to otwieram podręcznik do grubszej matmy i staram się dowiedzieć czy ja w ogóle zrozumiem jak to przekopię.

Oczywiście. Tylko moc obliczeniowa telefonu ma swoje ograniczenia względem przyzwyczajenia do rozmachu z pc. Shadery (w tym blend mode, taki starszy wujo shadera) pod andkiem mają kompletną funkcjonalność, tylko przestrzeń przygotowana na rezultat nie jest wystarczająca. Warto przygotować całą mechanikę tworzenia obrazu pod to co chcesz uzyskać na końcu. GMS ma tu swoje ograniczenia, niektóre bardzo poważne. Podstawowym jest ustalony na sztywno typ danych, w tym typ danych dla tekstur (spritów, teł, surfaców). No i o jakimś głębszym world matrix w andku można zapomnieć z przyczyn zrozumiałych. Przemyśl najpierw co ma być narysowane. Większość ludzi jedzie obiektami z draw self a później z tego same zgryzoty.

Atakujecie problem od jednej strony. Co jeśli kolejne takie rezultaty nie będą wynikały z ruchu po siatce, a z innych przyczyn mechaniki gry w tym z próby naprawy ruchu po siatce? Kolejna łata?

Threff - wyskakuj z przeróbką obrazu bez użycia shaderów jak chcesz się wypowiadać na temat meteorytyki dyskusji. A jak tego nie robiłeś - nie wtrącaj się tym co zrobili. To jest upomnienie użytkownika. A jak Ci się nie podobają użytkownicy to od tego masz uprawnienia aby ich stąd wysłać na orbitę. Zachęcam. A jak Ci ktoś przyśle zapytanie o napisanie mu w kilka godzin boulder dasha to mu napiszesz. Tak w ramach merytoryki i udzielania się potrzebom użytkowników na forum.

Przetestować wszystkie instancje pod kątem x czy nie jest powtórzone korzystając z for. A jeśli jest to sprawdzić też y. Pchnąć w losowym kierunku młodszą numerem instancję w kierunku losowym przeciwnym do starszej. I nie musisz analizować dlaczego tak się stało, w grze to może być rezultat całej masy różnych zdarzeń z kreacją włącznie. Taki glicz deleter.

Co nie pojedzie? Ze śwagrem jak popchniesz pojedzie ^^ //================= To jest porażające, że ludzie myślą iż rozwiązania to tak nagle się pojawiły zaimplementowane z całą architekturą i z niczego nie wynikają. Ot tak nagle sobie sobie softwearowe shadery wyskakują i pracują na... dobrych chęciach procesora i ramu? No to by się nie nazywały szadery jako oddzielny rodzaj oskryptowania tylko by sobie były częścią kodu. Pamięta ktoś czasy sprzed shaderów? Jak się do odpalenia shadera podłączało jedną kartę grafiki wyjściem do wejścia drugiej, ta dopiero nakładała wodotryski na macierz i dopiero szło to do monitora?

Fajny knur (penetrator loch). Błędy w mechanice (pixel perfect obecność wroga na bohaterze, zamiast distance). Nieczytelni wrogowie, żeby się świecili albo co. Brak info (czym strzelać, jakie klawisze). Brak helpa (jak wyżej). Nie działa ESC.

Ja bym nie wierzył, po prostu spróbuj. Zamień na przykład wczytany surface na ds_grida, zmanipuluj wedle przeliczenia blur choćby, spróbój też w drugą stronę ff i wyświetl jako pixele, zacznij od rozmiaru 1/10 obrazu bo się będzie cięło jak emo z paczką żyletek.

Odpalisz, możesz sobie zrobić shader w kodzie bez użycia shadera. Polecam. Zobaczysz wtedy jak to powoli idzie bez dXowych bibliotek. Tak działały sowtwarowe rendery na amisi i pradawanych cadach.

Jak samochód nie stoi na kołach to nei powinien opaść jak mu odkręcę koła. To że są pisane w OGL nie zmienia kwestii że interpretowane są przez dX.

Odinstaluj dX i sprawdź :)

A w rzeczywistym świecie jak możesz to robić? Midichlorianami?

Zawijaj wiersze. Ciężko to wyczytać. Koniec drabiny musi być obsługiwany przez jakieś zachowanie bohatera, które masz pod przyciskiem w dół i musi być trigger, który sam to wywoła. Na przykład można oskryptować takie zachowanie i jeśli pomiędzy last step a new step jest że drabina była, a nie ma to trzeba poszukać podłogi. To że bohater spada w dół to sukces. Często pierwsze drabiny wysyłają go na orbitę :)

Impulsami. Właśnie dlatego trzeba rozumieć jak się taki silnik buduje żeby wiedzieć dlaczego działa jak działa. Kalkulator ułatwia pracę, jeśli jesteś w stanie sprawdzić czy wynik ma coś wspólnego z tym co miało być wynikiem. Jak nie jesteś to taka proteza za Ciebie nie policzy czy mu nie zadajesz błędnych danych.

Napisz tekstem co autor miał na myśli jak to pisał. Coś podejrzewam, że autor pominął nawiasy w syntaxie i ma pętlę co step z tym warunkiem: place_meeting(x+32,y+3,obj_niewidzialny) na ten place_meeting(x+32,y+3,obj_niewidzialny) co skutkuje przekładaniem wartości zespolonej (image scale)(znak) na przeciwny znak.

Możesz zrobić w kolizji próbkowania lokalnego pola (tak dużego jak Ci smakuje z tej bitmapy) i z niego uzyskać tangent (styczną) wektora kierunkowego powierzchni kolizji. A dalej to już po ludzku tak jak z rykoszetem. Przydatne w poślizgach 3d (heightmap) by określić czy samolotem jeszcze się ślizgasz po lotnisku czy zaryłeś i urwałeś koło na dziurze.

To ja się pozytywnie podsumuję:

Przyniosę ze dwie klawiatury przy których GMS zgłupieje, a winda nie, i ze dwa kontrolery. Klawiatura fizycznie wysyła sygnał, który BIOS oznacza jako complex (int)(+); Winda otrzymuje ten (int) jako wartość dla tablicy po tym jak procesor zapyta co słychać w InputDevice (BIOS nie czyta wszystkich wartości, ale wszystkie jakie dostanie zapisuje). GMS pobiera asynchronicznie dane z klawiatury i ustawia je jako complex(int)(tablica GMS dla last/curent pressed/released). A dlatego tak dziwnie poneiważ my korzystamy z klawiatury synchronicznie do step event. I dlatego niektóre przyciski mimo że czytane przez windę nie są czytane przez GMSa bo to nei ejst ta sama tablica. A shadery lecą przez directX. Mam silne podejrzenie że bełkotliwie wyjaśniam dlaczego nie należy stosować bezpośredniego odczytu wartości (int) z klawiatury tylko referencję znaku, chodzi o to że jak podłączysz szwedzką czy arabską klawiaturę to się część rzeczy, które działają w windzie wykrzaczy w GMSie. Ale mam zaświadczenie że mogę być bełkotliwy i nierozumiany ^^ Wbudowana fizyka to podszepty złego tak jak gender, a wpędzanie w to nowych powinno kończyć się na stosie i dołożę do tego swoją pochodnię. To jedna z tych funkcji, które są przeznaczone dla użytkowników, którzy umieją fizykę zbudować sami i wtedy chcą skorzystać z gotowej. To jak z mnożeniem - umiesz wielokrotnie dodawać - używasz mnożenia, inaczej to black box z którego wyskakują niezrozumiałe wyniki.

Nocturne mi to przetłumaczył jak kilka lat temu chciałem klawisze zmapować kiedy jeszcze z windy w global_key były wczytywane :)

To sprawdź jak to działa na kilku klawiaturach z różnymi sterownikami. Teraz jest dużo egzotyki.

Przecież klawiatura w GMS jest wirtualna ^^ Jeśli Ci wczytuje poprawne wartości to masz szczęście, mi z kilku klawiatur tylko jenda na ps2 tak robi.