Come posso mantenere il mio personaggio centrato sullo schermo?

Sto realizzando un gioco simile a Legend of Zelda: Link to the Past (azione-avventura 2D dall'alto in basso). Voglio che il personaggio rimanga centrato sullo schermo quando si muove.

Attualmente, ogni volta che il giocatore vuole muoversi, sposto tutta la mappa nella direzione opposta. Funziona, ma quando aggiungo più oggetti al mondo, spostarli diventa più complicato.

C'è un modo migliore per affrontare questo?

2d camera movement

— asbumste
fonte

Crea una videocamera e spostala. In sostanza, tutto verrà disegnato con un offset basato sulla posizione della telecamera. Spostare l'universo per spostare il tuo personaggio è un po 'eccessivo il professor Farnsworth.

— MichaelHouse

+1 per fare riferimento al suo riferimento al suo riferimento futurama: P

— Doorknob

@ Byte56 Grazie, è vicino a quello che sto facendo, quindi potrei continuare così. Ma questo ha molto senso. Vuoi inserire una risposta in modo che io possa accettarla?

— asbumste,

Quale sottosistema di rendering stai usando?

— bobobobo,

Risposte:

Il modo tipico di gestirlo è creare un oggetto camera. La forma più semplice di una telecamera è solo una posizione. Questa semplice fotocamera definisce il "centro" della vista corrente. Quindi non modifichi tutte le posizioni delle tue tessere / entità, sottragga semplicemente le coordinate della videocamera dalle posizioni durante il disegno. In questa situazione, la fotocamera non si "sposta".

Mentre la cinepresa e il tuo personaggio condivideranno una posizione per la maggior parte del tempo, potresti comunque volerli avere come valori separati, quindi, ad esempio, puoi fermare il movimento della cinepresa quando raggiunge la fine del mondo, ma consenti giocatore per continuare a muoversi.

Si muove una videocamera leggermente più avanzata. Tutte le entità e le tessere vengono disegnate senza offset e la posizione da cui si esegue il rendering cambia. Questo è molto simile alla fotocamera di base e puoi ancora eseguire molte delle stesse ottimizzazioni per il rendering selettivo (chiamando solo drawciò che la fotocamera può vedere), su entrambi. È essenzialmente solo un modo diverso di pensarci.

— MichaelHouse
fonte

Ciao Byte, ho implementato con successo quello che hai detto ... Penso. Ma ora sto incontrando problemi ... puoi aiutare a dare un'occhiata? Un ragazzo ha detto che in realtà non ho bisogno di nessuno cam variables... e ha offerto un metodo alternativo ... stackoverflow.com/questions/18199373/…

— Growler

Daremo un'occhiata più tardi, per ora ti suggerisco di chiedere in chat .

— MichaelHouse

No, questo è il modo sbagliato di procedere.

Come hai intenzione di fare il rilevamento delle trappole? Che dire di quando il giocatore raggiunge i bordi delle pareti? Il tuo sistema di visualizzazione funzionerà per i dungeon o dovrai riscrivere una parte significativa del codice?

Il mondo è geometria. Il giocatore è la geometria. Il mondo non si muove. Il giocatore lo fa. Impostare la posizione della telecamera al centro sul lettore. Sempre . E questo è tutto.

Non cercare di ottenere fantasia con "oh se Faccio scivolare il mondo, allora darà la comparsa il giocatore si sta muovendo". Alla fine della giornata complicherai la matematica con strani sistemi di coordinate.

È vero che il rendering di OpenGL funziona in realtà "fissando la telecamera per puntare verso il basso - z, e trasformando e ruotando tutta la geometria del mondo in modo che si adatti al volume della vista canonica", ma non si deve pensarci in quel modo durante la programmazione . gluLookAtha parametri denominati eye, looke upper una ragione, quindi puoi pensare in termini di un sistema di coordinate sensibile.

— bobobobo
fonte

Uno dei più grandi errori che ho commesso con un sistema di interfaccia utente GL che stavo sviluppando è stato il tentativo di lavorare in coordinate canoniche ([-1,1]) "per renderlo più semplice". Tutti gli oggetti dello schermo avevano coordinate in [-1,1]. Questo è stato un errore enorme , ho costantemente cercato di pensare in questo intervallo [-1,1], convertendo tra pixel e NDC, riconvertendo. Quando ho rinunciato a questa idea di lavorare in NDC e ho appena lavorato in pixel e convertito in NDC appena prima del rendering come si suppone , c'era una differenza nel modo in cui era facile pensare a posizionare gli elementi sullo schermo, elaborazione degli eventi di input, ecc.

— bobobobo