Come si evita l '"effetto scala" nel movimento della pixel art?

Sto eseguendo il rendering di sprite con esatte coordinate pixel per evitare l'effetto sfocato causato dall'antialias (gli sprite sono pixel art e apparirebbero orribili se filtrati). Tuttavia, poiché il movimento degli oggetti comporta velocità variabile, gravità e interazioni fisiche, la traiettoria viene calcolata con precisione subpixel.

A velocità dello spazio dello schermo sufficientemente grandi (vΔt maggiore di 2 o 3 pixel) funziona molto bene. Tuttavia, quando la velocità è piccola, può apparire un evidente effetto scala, specialmente lungo linee diagonali. Questo non è più un problema a velocità dello schermo molto lente (v << 1 pixel al secondo), quindi sto solo cercando una soluzione per valori di velocità intermedi.

A sinistra è la traiettoria tracciata per una grande velocità, ottenuta per semplice arrotondamento delle coordinate dell'oggetto. Nel mezzo puoi vedere cosa succede quando la velocità si riduce e l'effetto della scala di cui sto parlando. A destra, il luogo della traiettoria che vorrei ottenere.

Sono interessato alle idee dell'algoritmo per filtrare la traiettoria al fine di minimizzare l'aliasing, mantenendo il comportamento originale a velocità grandi e piccole. Ho accesso a Δt, posizione istantanea e velocità, nonché a un numero arbitrario di valori precedenti, ma poiché si tratta di una simulazione in tempo reale, non conosco i valori futuri (anche se, se necessario, una stima potrebbe essere estrapolata in base a determinati presupposti) . Si noti che a causa della simulazione fisica, possono anche verificarsi improvvisi cambi di direzione.

Ecco un rapido schema, dalla parte superiore della mia testa, di un algoritmo che dovrebbe funzionare abbastanza bene.

1. Innanzitutto, calcola la direzione in cui si sta muovendo l'oggetto e controlla se è più vicino all'orizzontale o verticale.
2. Se la direzione è più vicina alla verticale (orizzontale), regola la posizione dell'oggetto lungo il vettore di direzione al centro della riga di pixel più vicina (colonna).
3. Arrotonda la posizione al centro del pixel più vicino.

In pseudocodice:

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

Modifica: Sì, testato, funziona abbastanza bene.

Non c'è molto che tu possa davvero fare al riguardo per un mondo basato sulla fisica generale. Se tutti i tuoi oggetti si muovessero lungo linee o cerchi specifici, potresti fare qualcosa. Ma stai operando sotto la fisica reale. L'oggetto è dove la fisica lo mette; stai semplicemente disegnando un'approssimazione basata su pixel di quella posizione.

In genere è qualcosa che devi accettare se vuoi rimanere con le coordinate dei pixel. Non dovrebbe essere troppo evidente a meno che non si stia visualizzando a una risoluzione incredibilmente piccola (inferiore a 640x480, anche se dipende dalla risoluzione e dalle dimensioni native del display).

Quando il movimento in sospeso è perpendicolare all'ultimo movimento (nello spazio dello schermo), ignoralo e usa le coordinate dell'ultimo schermo. Se questo porta a una balbuzie che è tanto grave quanto la scala, potresti provare a spostare la somma del movimento in sospeso e dell'ultimo movimento.

Penso che il problema risieda in v <sqrt (2). v> sqrt (2) dovrebbe sempre spostarsi di almeno una diagonale completa, evitando l'effetto scala. Forse utile per la potatura che necessita dei precedenti confronti di movimento.