Come evitare i valori subpixel in un gioco 2D indipendente dalla risoluzione con proiezione ortografica?


8

Sto cercando di eseguire il rendering indipendente dalla risoluzione degli sprite in movimento in un gioco 2D. Il mio piano è lavorare in un sistema di coordinate fisso nel mio mondo (ad esempio 960x540) e utilizzare la proiezione ortografica per ridimensionarla su o giù per adattarla alla finestra. Faccio letterboxing per gestire diverse proporzioni.

Secondo la maggior parte dei tutorial, sono libero di usare qualsiasi dimensione mi piaccia per il frustum della vista, ma ho scoperto che in molti casi ciò porta al problema che finisco per usare i valori subpixel sul viewport. Ad esempio un vertice in (62,62) in un sistema di coordinate di 960 x 540 finisce in (51.6666667,51.6666667) su una finestra con le dimensioni 800 x 450.

Ho notato due tipi di problemi con questo:

  • il campionamento delle trame cambia continuamente per gli oggetti che sono in movimento a seconda di dove si trovano i vertici rispetto al centro di un pixel
  • i miei oggetti vengono allungati di tanto in tanto in senso orizzontale o verticale a causa di arrotondamenti

Qual è la migliore pratica per evitarlo (mantenendo l'indipendenza di risoluzione in termini di velocità di movimento e così via)? E dove sarebbe il posto migliore per fare questo? Prima di passare i vertici agli shader o all'interno del vertice shader?


Come stai eseguendo il ridimensionamento e le traduzioni per adattarle alla nuova finestra? Matrici? Ridimensionare e spostare manualmente le posizioni degli oggetti?
Emir Lima,

@EmirLima Sto moltiplicando le coordinate per una matrice combinata vista-modello-proiezione all'interno del mio shader di vertice. Tutto il ridimensionamento viene eseguito dalla matrice di proiezione ortografica.
Eric,

potresti arrotondare o pavimentare le corde, (forse in vert shader)
t123

@ tm1rbrt Grazie per il tuo commento. Penso che dovrei sempre pavimento o soffitto per evitare 1 pixel in più o in meno in larghezza o altezza. Ho provato a farlo all'interno del vertex shader, ma l'imprecisione nei calcoli lo rende difficile se non impossibile. Ho finito col pavimentare quelli che avrebbero dovuto essere numeri interi perfetti al numero intero precedente.
Eric

Risposte:


1

Per arrivare alla domanda principale, se influenzare o meno i vertici prima o durante lo shader, è preferibile utilizzare uno shader. Se sai come scrivere una routine che può prendere in considerazione la finestra e il sistema di coordinate, è preferibile utilizzare uno shader in quanto consente a molti sprite di essere regolati in parallelo. Inoltre, assicura che le coordinate "cosmetiche" rimangano separate dalle coordinate in-game nel codice CPU in modo che l'una non influenzi l'altra.

Puoi farlo nel vertice O nel pixel shader. Nel pixel shader è possibile spostare i texel per bloccarli sui pixel del display.

In DirectX9 avevo bisogno di farlo con HLSL per ovviare a questo inconveniente angoli di texel fossero posizionati a 0,5, 0,5 rispetto al pixel , rendendo le trame nitide un po 'sfocate. La correzione di questo cambia la posizione fisica dei texel senza spostare i vertici.

Nel tuo caso, l'offset varierà da frame a frame, quindi passa le coordinate vere dello sprite allo shader per calcolare l'offset decimale. Ricorda di bloccare il campionamento delle trame per evitare di avvolgere le trame.


3

Penso che memorizzerei due serie di coordinate.

  1. Uno usato per disegnare i tuoi oggetti DISPLAY POSITIONe
  2. un secondo usato per mantenere a TRUE POSITION.

In questo modo è possibile disegnare sprite con coordinate arrotondate per eliminare la distorsione causata da dimensioni fisse dell'area di visualizzazione.

Ma questo ti consente anche di mantenere la posizione esatta senza influenzare la tua logica di gioco. a causa della natura dei sub-pixel, penso anche che non noterai alcuna discrepanza tra la vista e la logica di gioco.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.