Jak uniknąć „efektu schodów” w ruchu sztuki pikseli?

Renderuję duszki z dokładnymi współrzędnymi pikseli, aby uniknąć efektu rozmycia spowodowanego wygładzaniem krawędzi (duszki są pikselami i wyglądałyby okropnie, gdyby były filtrowane). Ponieważ jednak ruch obiektów obejmuje zmienną prędkość, grawitację i interakcje fizyczne, trajektoria jest obliczana z precyzją subpikseli.

Przy wystarczająco dużych prędkościach przestrzeni ekranu (vΔt większych niż 2 lub 3 piksele) działa to bardzo dobrze. Jednak gdy prędkość jest mała, może pojawić się zauważalny efekt schodowy, szczególnie wzdłuż linii ukośnych. Nie jest to już problemem przy bardzo niskich prędkościach przestrzeni ekranu (v << 1 piksel na sekundę), więc szukam tylko rozwiązania dla średnich wartości prędkości.

Po lewej stronie jest wykreślona trajektoria dla dużej prędkości, uzyskana przez proste zaokrąglenie współrzędnych obiektu. Na środku widać, co dzieje się, gdy prędkość staje się mniejsza, i efekt schodów, o którym mówię. Po prawej stronie chciałbym uzyskać miejsce trajektorii.

Interesują mnie pomysły algorytmów do filtrowania trajektorii w celu zminimalizowania aliasingu, przy jednoczesnym zachowaniu oryginalnego zachowania przy dużych i małych prędkościach. Mam dostęp do Δt, natychmiastowej pozycji i prędkości, a także dowolnej liczby poprzednich wartości, ale ponieważ jest to symulacja w czasie rzeczywistym, nie wiem o przyszłych wartościach (choć w razie potrzeby oszacowanie można ekstrapolować przy pewnych założeniach) . Pamiętaj, że z powodu symulacji fizyki mogą również wystąpić nagłe zmiany kierunku.

Oto krótki zarys algorytmu, który powinien działać całkiem dobrze.

1. Najpierw oblicz kierunek, w którym porusza się obiekt, i sprawdź, czy jest bliżej poziomej czy pionowej.
2. Jeśli kierunek jest bliższy pionowi (poziomo), dostosuj pozycję obiektu wzdłuż wektora kierunku do środka najbliższego rzędu pikseli (kolumny).
3. Zaokrąglij pozycję do środka najbliższego piksela.

W pseudokodzie:

if ( abs(velocity.x) > abs(velocity.y) ) {
    x = round(position.x);
    y = round(position.y + (x - position.x) * velocity.y / velocity.x);
} else {
    y = round(position.y);
    x = round(position.x + (y - position.y) * velocity.x / velocity.y);
}

Edycja: Tak, przetestowane, działa całkiem nieźle.

W świecie opartym na fizyce niewiele można tak naprawdę zrobić. Gdyby wszystkie twoje obiekty poruszały się wzdłuż linii lub określonych kręgów, możesz coś zrobić. Ale działasz w oparciu o rzeczywistą fizykę. Obiekt jest tam, gdzie umieszcza go fizyka; po prostu rysujesz przybliżoną lokalizację w pikselach.

Jest to na ogół coś, co musisz zaakceptować, jeśli chcesz trzymać się współrzędnych pikseli. Nie powinno to być zbyt zauważalne, chyba że wyświetlasz w niewiarygodnie małej rozdzielczości (mniejszej niż 640 x 480, choć zależy to od natywnej rozdzielczości i rozmiaru wyświetlacza).

Gdy oczekujący ruch jest prostopadły do ​​ostatniego ruchu (w przestrzeni ekranu), zignoruj ​​go i użyj ostatnich współrzędnych ekranu. Jeśli prowadzi to do jąkania, które jest tak złe jak schody, możesz spróbować przesunąć sumę oczekującego i ostatniego ruchu.

Myślę, że problem leży w v <sqrt (2). v> sqrt (2) zawsze powinien przesuwać się przynajmniej o pełną przekątną, unikając efektu schodów. Może przydatny do przycinania, które wymagają wcześniejszych porównań ruchów.