Skocz do zawartości

Wchodzenie pod górkę


Sheriff99

Rekomendowane odpowiedzi

Hej, jak widzicie ostatnio zająłem się tworzeniem całkowicie nowej gry. Skupiam się teraz na jej fizyce no i niestety napotkałem na problem, który zeżarł mi już sporą część czasu, a mianowicie wchodzenie pod górkę. Najpierw chciałem to załatwić po swojemu - bezskutecznie, potem próbowałem zaimplementować 3 przykłady(w tym także Tymona), ale także bezskutecznie, podczas gdy w demonstracyjnych planszach działają. Oczywiście moje sprite'y mają wycentrowane originy, a kąt platform to 45 stopni. Chciałbym do tego dojść sam, więc proszę was o sugestie.

Odnośnik do komentarza
Udostępnij na innych stronach

Metoda "wypychania" może mimo wszystko doprowadzić do wielu bugów. Poza tym, silnik oparty na takim systemie jest ograniczony w pewnym sensie; jeżeli zamierzasz jakkolwiek odwzorowywać zachowania realne i chcesz scalić swój ruch z "naturalną" fizyką:

 

tumblr_nzztkbXL1X1urjt23o1_1280.gif

 

to warto poświęcić nieco więcej czasu. Być może pomoże Ci opis mechaniki powyżej: link.

Odnośnik do komentarza
Udostępnij na innych stronach

Zamierzam dołączyć w wolnej chwili :).

 

Tym niemniej, jeżeli ktokolwiek chce zająć się podstawami fizyki, nie ominie operacji algebraicznych na macierzach (nie jest to jakoś szczególnie trudne) oraz trygonometrii.

 

Można też liczyć wszystko na wektorach i iloczynach skalarnych. Na dobrą sprawę wypadałoby zrobić testy wydajności i porównać dwie metody.

Odnośnik do komentarza
Udostępnij na innych stronach

Jak robiłem swój silnik fizyczny w C++, to na wektorach działało szybciej. Tyle że w C++ można zbudować klasy, do elementów których bezpośredni dostęp jest szybki. W GM struktury ds_ mają, w porównaniu, długi czas dostępu do zawartości - może się okazać, że metoda z wektorami i iloczynem skalarnym jest niewiele szybsza od metody z funkcjami trygonometrycznymi.

Niezależnie natomiast od metody, trzeba by napisać własny quadtree w przypadku, gdy ma się zamiar kłaść dużo wielokątów. To jest nieciekawa sprawa, ciężko mi sobie wyobrazić kod w GML, który by za to odpowiadał.

@Sheriff99, zostają dwie realistyczne opcje:

1) Metoda Sutikku jest najprostszą metodą i tę metodę polecam, nie widzę powodu, żeby budować wokół Twojego problemu jakiś niesamowity silnik fizyczny.

2) GM ma wbudowany silnik fizyczny, który robi praktycznie wszystko to, co jest na przykładzie Jakima, w dodatku w całości jest opisany w dokumentacji. Dla wymagających jest odpowiednią metodą.

 

Jakim, nie bardzo rozumiem, co mają macierze do implementacji kolizji, chodzi o 3D? Bo ja robiłem to w 2D i nigdzie nie korzystałem z macierzy. A może chodzi o inne rzeczy związane z fizyką?

Odnośnik do komentarza
Udostępnij na innych stronach

Cel jest jedynie dydaktyczny, by poczuć fizycznego bluesa. Oczywiście jak już się to zrobi, warto skorzystać z dostosowanych ku temu metod. Tym bardziej, że GM niezbyt nadaje się do modelowania czegokolwiek z racji swojej struktury. Nic ponad to :).

 

Zachowanie obiektu sprężystego podczas kolizji można opisać prostą macierzą. Kolizje same w sobie sprawdzane są poprzez iloczyn skalarny.

 

No, przede wszystkim nie sugeruję, by robić własny silnik, ale kto by nie chciał platformówki, w której można swobodnie się ślizgać po krzywych? :c

Odnośnik do komentarza
Udostępnij na innych stronach

Jeśli chcesz dodać odpowiedź, zaloguj się lub zarejestruj nowe konto

Jedynie zarejestrowani użytkownicy mogą komentować zawartość tej strony.

Zarejestruj nowe konto

Załóż nowe konto. To bardzo proste!

Zarejestruj się

Zaloguj się

Posiadasz już konto? Zaloguj się poniżej.

Zaloguj się
  • Ostatnio przeglądający   0 użytkowników

    • Brak zarejestrowanych użytkowników przeglądających tę stronę.
×
×
  • Dodaj nową pozycję...