Wchodzenie pod górkę

[Sheriff99]

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.

[Sutikku]

Sprawdzasz czy napotkałeś przeszkodę i jeśli troszkę nad nią jest pusto, to wchodzisz wyżej i w prawo (no w to miejsce co sprawdzamy nad platformą)

 

[Sheriff99]

Dzięki za odpowiedź. Ufff w końcu metodą prób i błędów sobie poradziłem - temat do zamknięcia.

[Jakim]

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ą:

 

 

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

[Sheriff99]

Dzięki, Jakim, postaram się przestudiować to!

[I am Lord]

Jak masz tytuł inżyniera to może ci się uda :D

Jakim bardziej pomocny byłby pseudokod a nie jakiś matematyczny język którego nikt nie kuma :P

[Jakim]

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.

[Amaterasu]

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ą?

[Jakim]

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