Wie vermeidet man den „Treppeneffekt“ in der Pixelkunstbewegung?

Ich rendere Sprites mit genauen Pixelkoordinaten, um den durch Antialiasing verursachten Unschärfeeffekt zu vermeiden (die Sprites sind Pixelkunst und sehen bei Filterung schrecklich aus). Da die Bewegung der Objekte jedoch mit variabler Geschwindigkeit, Schwerkraft und physikalischen Wechselwirkungen einhergeht, wird die Flugbahn mit Subpixel-Genauigkeit berechnet.

Bei ausreichend großen Bildschirmgeschwindigkeiten (vΔt größer als 2 oder 3 Pixel) funktioniert dies sehr gut. Bei geringer Geschwindigkeit kann jedoch ein merklicher Treppeneffekt auftreten, insbesondere entlang diagonaler Linien. Bei sehr langsamen Bildschirmgeschwindigkeiten (v << 1 Pixel pro Sekunde) ist dies kein Problem mehr, daher suche ich nur nach einer Lösung für Zwischengeschwindigkeiten.

Links ist die geplottete Trajektorie für eine große Geschwindigkeit dargestellt, die durch einfaches Runden der Objektkoordinaten erhalten wird. In der Mitte sehen Sie, was passiert, wenn die Geschwindigkeit abnimmt, und den Treppeneffekt, von dem ich spreche. Rechts den Ort der Flugbahn, den ich mir wünschen würde.

Ich interessiere mich für Algorithmusideen zum Filtern der Trajektorie, um das Aliasing zu minimieren und gleichzeitig das ursprüngliche Verhalten bei großen und kleinen Geschwindigkeiten beizubehalten. Ich habe Zugriff auf Δt, momentane Position und Geschwindigkeit sowie eine beliebige Anzahl vorheriger Werte, aber da es sich um eine Echtzeitsimulation handelt, weiß ich nichts über zukünftige Werte (obwohl eine Schätzung unter bestimmten Voraussetzungen bei Bedarf extrapoliert werden könnte). . Beachten Sie, dass aufgrund der Physiksimulation auch plötzliche Richtungsänderungen auftreten können.

Hier ist ein kurzer Überblick über einen Algorithmus, der einigermaßen gut funktionieren sollte.

1. Berechnen Sie zunächst die Richtung, in die sich das Objekt bewegt, und prüfen Sie, ob es näher an der Horizontalen oder Vertikalen liegt.
2. Wenn die Richtung eher vertikal (horizontal) ist, stellen Sie die Position des Objekts entlang des Richtungsvektors auf die Mitte der nächsten Pixelzeile (-spalte) ein.
3. Runden Sie die Position auf die Mitte des nächsten Pixels ab.

Im Pseudocode:

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);
}

Edit: Ja, getestet, funktioniert ganz gut.

In einer allgemeinen physikbasierten Welt kann man nicht viel dagegen tun. Wenn sich alle Ihre Objekte entlang von Linien oder bestimmten Kreisen bewegen, können Sie etwas tun. Aber Sie arbeiten unter der tatsächlichen Physik. Das Objekt ist dort, wo die Physik es ausdrückt. Sie zeichnen einfach eine pixelbasierte Annäherung an diesen Ort.

Es ist im Allgemeinen etwas, das Sie akzeptieren müssen, wenn Sie sich an Pixelkoordinaten halten möchten. Es sollte nicht zu auffällig sein, es sei denn, Sie zeigen mit einer unglaublich geringen Auflösung an (weniger als 640 x 480, obwohl dies von der nativen Auflösung und Größe des Displays abhängt).

Wenn die anstehende Bewegung senkrecht zur letzten Bewegung (im Bildschirmbereich) ist, ignorieren Sie sie und verwenden Sie die letzten Bildschirmkoordinaten. Wenn dies zu einem Stottern führt, das genauso schlimm ist wie das Treppenhaus, können Sie versuchen, die Summe aus dem anstehenden und dem letzten Satz zu verschieben.

Ich denke, das Problem liegt in v <sqrt (2). v> sqrt (2) sollte sich immer mindestens um eine volle Diagonale bewegen, um den Treppeneffekt zu vermeiden. Möglicherweise nützlich für das Beschneiden, das die vorherigen Bewegungsvergleiche benötigt.