Sto realizzando un gioco basato su sprite, e ho un sacco di immagini che ottengo in una risoluzione ridicolmente grande e le ridimensiono in base alla dimensione dello sprite desiderata (ad esempio 64x64 pixel) prima di convertirle in una risorsa di gioco, quindi quando disegno il mio sprite all'interno del gioco, non devo ridimensionarlo.
Tuttavia, se ruoto questo piccolo sprite all'interno del gioco (motore in modo agnostico), alcuni pixel di destinazione verranno interpolati e lo sprite sembrerà macchiato.
Ciò dipende ovviamente dall'angolo di rotazione e dall'algoritmo di interpolazione, ma a prescindere, non ci sono dati sufficienti per campionare correttamente un pixel di destinazione specifico.
Quindi ci sono due soluzioni a cui riesco a pensare. Il primo consiste nell'utilizzare l'immagine enorme originale, ruotarla negli angoli desiderati, quindi ridimensionare tutte le varianti ricorrenti e metterle in un atlante, che ha il vantaggio di essere abbastanza semplice da implementare, ma consuma ingenuamente il doppio dello sprite spazio per ciascuna rotazione (ogni rotazione deve essere inscritta in un cerchio il cui diametro è la diagonale del rettangolo dello sprite originale, la cui area è doppia rispetto a quel rettangolo originale, supponendo sprite quadrate).
Ha anche lo svantaggio di avere solo un set predefinito di rotazioni disponibili, che può andare bene o no a seconda del gioco.
Quindi l'altra scelta sarebbe quella di memorizzare un'immagine più grande, e ruotare e ridimensionare durante il rendering, il che porta alla mia domanda.
Qual è la dimensione ottimale per questo sprite? Significato ottimale che un'immagine più grande non avrà alcun effetto sull'immagine risultante.
Ciò dipende sicuramente dalla dimensione dell'immagine, dalla quantità di rotazioni desiderate senza perdita di dati fino a 1/256, che è la differenza cromatica minima rappresentabile.
Sto cercando una risposta teorica generale a questo problema, perché provare un mucchio di taglie può andare bene, ma è tutt'altro che ottimale.