Świetne! Wreszcie moi łucznicy będą trafiać w ruchomy cel

Idea przykładu fajna, ale jednak zastosowany mechanizm sprawia że przy stałym ruchu gracza kościotrup nie zawsze trafia (chociaż i tak w większości trafia, a w tdsach nie ma co się z tym bawić bo i tak gracz będzie robił uniki) w cel. Nie mam pomysłu jak to wyjaśnić to daję obrazek:
img832.imageshack.us/.../fgfdgdfg.png

I teraz po kolei kroki, które wykona algorytm w tym przykładzie (czarne to kościotrup, niebieskie jabłko):
1. Sprawdzamy, w ilu klatkach strzała doleci do AKTUALNEJ pozycji gracza. Wynik - 4 klatki (taki przykład ofc). Czerwona linia na obrazku.
2. Obliczamy, na jakiej pozycji będzie gracz za tyle klatek, ile wyszło na wyżej. Niebieska linia na obrazku, ta pozycja gracza, która nam wyszła jest oznaczona jako puste niebieskie kółko.
3. Strzelamy w to puste niebieskie kółko. Zielona linia na obrazku.
//tutaj koniec algorytmu, ale obserwujmy dalszy przebieg zdarzeń
4. Niestety, wyszło tak, że strzale dojście do pozycji którą wyliczyliśmy zajęło 6 klatek (sprawdzaliśmy to w 1 punkcie, wtedy innymi danymi nie dysponowaliśmy), a nie 4. I przez te 6 klatek gracz zdążył ominąć trajektorię - różowe kółko.

Obliczanie pozycji, na której będzie gracz w momencie gdy trafi go strzała nie opiera się na dystansie do rzeczywiście tego punktu, gdzie trafi go strzała (choć szczerze sam nie mam pojęcia jakby to obliczyć, mógłby się wypowiedzieć jakiś ekspert : D), a na dystansie do gracza. A nas interesuje PRZYSZŁA pozycja gracza i to na niej powinniśmy oprzeć obliczenia - a nie na aktualnej.
Opieramy się na czerwonej kresce, a powinniśmy na zielonej.

Inna sprawa, że wychodzi na to, że aby obliczyć przyszłą pozycję gracza potrzebujemy pozycji gracza. Dlatego to takie ciekawe : D

Ale Ty uwzględniasz ruch przyspieszony którego nie ma w tym przykładzie.

Nie chce mi się myśleć dokładnie jaki by to miało sens, ale logiczne wydawało by się zrobienie po prostu powiedzmy 5 iteracji - z których każda opierała by się na wyniku poprzedniej.
Czyli że rysunek który wyżej dałem to 1 iteracja - w drugiej program liczy, gdzie będzie gracz za 6 klatek (długość zielonej kreski, tą, którą właśnie obliczyliśmy). I wtedy przekazujemy do następnej iteracji, aby obliczyła, gdzie będzie gracz za (tutaj wynik tej 2 iteracji) klatek.

Całkowicie precyzyjne by to nie było, ale było by to już dużo większe przybliżenie.

Stary, komplikujesz sobie życie. Do podręcznika fizyki, marsz.

Nie, nie uwzględniam przyspieszonego : D

Obliczamy, gdzie będzie gracz, gdy trafi go strzała - ale opieramy to na AKTUALNEJ sytuacji (aktualnym dystansie kościotrup-gracz, co przekłada się na wynik "w ilu klatkach strzała dotrze do celu"), a nie na tej przyszłej. Nie mam pojęcia jak to lepiej wyjaśnić, także muszę liczyć, że kogoś oświeci i zrozumie, o co mi chodzi

Tyle tylko że mówię, do gier to w 100% wystarcza - ale tak czysto teoretycznie patrząc to ten przykład nie jest całkiem skuteczny

Zresztą najlepiej zwiększyć sobie ekran i się zauważy, że rzeczywiście gdy poruszamy się tak, że szybko zmienia się dystans jabłko-kościotrup (mijamy go w odległości gdzieś 150px) to szkielet w nas po prostu nie trafia (mimo, że nie zmieniamy kierunku ani prędkości).

Chyba inne podręczniki od fizyki mamy

Dobra, już to widzę.

W alarmie szkielecika trzeba poprawić liczenie dist.

dist = point_distance(
x,
y,
obj_apple.x + lengthdir_x( obj_apple.apple_speed, obj_apple.apple_direction ),
obj_apple.y + lengthdir_y( obj_apple.apple_speed, obj_apple.apple_direction )
);

Zwykły błąd, bo w końcu ma strzelać w kierunku przyszłej pozycji jabłka, a nie obecnej.

Dawidds i tak masz pałę za sposób rozwiązania problemu.

Napiszmy o tym pracę magisterską i chodźmy na piwo. Dla mnie tamto rozwiązanie jest wystarczające, bo snajper nie jest potrzebny

Dawidds, to nie wystarczy brać sobie odległości kosciotrup - przyszła pozycja gracza, zamiast kosciotrup - gracz? Wtedy masz wszystko policzone bezbłędnie, tak na chłopski rozum, bo z fizyki to ja same 2 mam :/

Się obudziłeś : D
No ale jak już mamy się czepiać to na chłopski rozum wychodząc od tego co napisałeś:

1. Chcemy obliczyć [odległość kościotrup - przyszła pozycja gracza], potrzebujemy do tego ofc:
-pozycja kościotrupa (mamy)
-przyszła pozycja gracza (nie mamy, liczymy)
2. Do obliczenia [przyszła pozycja gracza] potrzebujemy:
-kierunku gracza (mamy)
-jego prędkości (mamy)
-czasu, jaki zajmie pociskowi dotarcie do tej [przyszłej pozycji gracza] - (nie mamy, liczymy)
3. Do obliczenia [czasu jaki zajmie pociskowi dotarcie do tej [przyszłej pozycji]] potrzebujemy:
-prędkości pocisku (mamy)
-dystansu jaki musi przebyć pocisk, czyli właśnie [odległość kościotrup - przyszła pozycja gracza] - no jak nieciężko zauważyć, zapętliliśmy się.

Myślę że trochę lepszy sposób na pokazanie tego niż to co pisałem ostatnio, ale i tak gadanie nad tym jest czystą głupotą bo w 95% przypadków pocisk mimo drobnej nie-precyzji (tak, wiem, słowotwórstwo - you're doing it wrong) trafi gracza, a w pozostałych 5% gracz zrobi unik i tyle ze snajperskich zdolności szkieletu, więc naprawdę nie ma o czym gadać. Czysto matematycznie technika jest nieprecyzyjna, ale w kontekście gier i tak w 100% wystarczająca.

I end of topic, bo nie dam rady tego lepiej wytłumaczyć a na pisanie aplikacji która to zademonstruje jestem zbyt leniwy.