Como evitar o "efeito escada" no movimento de pixel art?

Estou renderizando sprites nas coordenadas exatas de pixels para evitar o efeito de desfoque causado pelo antialiasing (os sprites são pixel-art e ficariam horríveis se filtrados). No entanto, como o movimento dos objetos envolve velocidade variável, gravidade e interações físicas, a trajetória é calculada com precisão de subpixel.

Em velocidades de espaço na tela grandes o suficiente (vΔt maior que 2 ou 3 pixels), isso funciona muito bem. No entanto, quando a velocidade é pequena, um efeito notável da escada pode aparecer, especialmente ao longo das linhas diagonais. Isso não é mais um problema em velocidades de espaço de tela muito lentas (v << 1 pixel por segundo), portanto, estou apenas procurando uma solução para valores de velocidade intermediários.

À esquerda, encontra-se a trajetória plotada para uma grande velocidade, obtida pelo simples arredondamento das coordenadas do objeto. No meio, você pode ver o que acontece quando a velocidade diminui e o efeito da escada de que estou falando. À direita, o lugar da trajetória que eu gostaria de obter.

Estou interessado em idéias de algoritmos para filtrar a trajetória, a fim de minimizar o aliasing, mantendo o comportamento original em velocidades grandes e pequenas. Eu tenho acesso a Δt, posição instantânea e velocidade, além de um número arbitrário de valores anteriores, mas como é uma simulação em tempo real, não conheço valores futuros (embora, se necessário, uma estimativa possa ser extrapolada sob certas suposições) . Observe que, devido à simulação física, mudanças repentinas de direção também podem ocorrer.

Aqui está um resumo rápido, em cima da minha cabeça, de um algoritmo que deve funcionar razoavelmente bem.

1. Primeiro, calcule a direção em que o objeto está se movendo e verifique se está mais próximo da horizontal ou vertical.
2. Se a direção estiver mais próxima da vertical (horizontal), ajuste a posição do objeto ao longo do vetor de direção para o centro da linha de pixels mais próxima (coluna).
3. Arredonde a posição para o centro do pixel mais próximo.

No pseudocódigo:

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: Sim, testado, funciona muito bem.

Não há muito o que você possa fazer sobre isso em um mundo geral baseado na física. Se todos os seus objetos estivessem se movendo ao longo de linhas ou círculos específicos, você poderia fazer algo. Mas você está operando sob a física real. O objeto é onde a física o coloca; você está simplesmente desenhando uma aproximação baseada em pixel desse local.

Geralmente, é algo que você deve aceitar se quiser manter as coordenadas de pixel. Não deve ser muito perceptível, a menos que você esteja exibindo em uma resolução incrivelmente pequena (inferior a 640x480, embora dependa da resolução e tamanho nativos da tela).

Quando o movimento pendente é perpendicular ao último movimento (no espaço da tela), ignore-o e use as últimas coordenadas da tela. Se isso levar à gagueira tão ruim quanto a escada, tente mover a soma do último e do movimento pendente.

Eu acho que o problema está em v <sqrt (2). v> sqrt (2) deve sempre mover pelo menos uma diagonal completa, evitando o efeito de escada. Talvez útil para podas que precisam de comparações de movimentos anteriores.