Bagaimana cara menjaga karakter saya terpusat di layar?

Saya membuat game yang mirip dengan Legend of Zelda: Tautan ke Masa Lalu (petualangan aksi 2D top-down). Saya ingin karakter tetap terpusat di layar ketika dia bergerak.

Saat ini, setiap kali pemain ingin bergerak, saya memindahkan semua peta ke arah yang berlawanan. Ini berfungsi, tetapi saat saya menambahkan lebih banyak objek ke dunia, memindahkan semuanya menjadi lebih rumit.

Apakah ada cara yang lebih baik untuk mendekati ini?

2d camera movement

— asbumste
sumber

Buat kamera dan pindahkan itu. Intinya, semuanya akan digambar dengan offset berdasarkan posisi kamera. Menggerakkan alam semesta untuk menggerakkan karakter Anda sedikit berlebihan Profesor Farnsworth.

— MichaelHouse

+1 untuk referensi referensi referensi futurama-nya: P

— Doorknob

@ Byte56 Terima kasih, itu dekat dengan apa yang saya lakukan, jadi saya mungkin tetap seperti itu. Tapi itu masuk akal. Ingin memasukkan itu ke dalam jawaban sehingga saya bisa menerimanya?

— asbumste

Subsistem render apa yang Anda gunakan?

— bobobobo

Jawaban:

Cara khas menangani ini adalah dengan membuat objek kamera. Bentuk kamera yang paling sederhana hanyalah posisi. Kamera sederhana ini mendefinisikan "pusat" dari tampilan saat ini. Jadi Anda tidak mengubah semua posisi ubin / entitas Anda, Anda cukup kurangi koordinat kamera dari posisi saat menggambar. Dalam situasi ini, kamera tidak "bergerak".

Meskipun kamera dan karakter Anda akan berbagi posisi sebagian besar waktu, Anda mungkin masih ingin memilikinya sebagai nilai yang terpisah, sehingga Anda dapat, misalnya, menghentikan kamera dari bergerak ketika mencapai akhir dunia, tetapi biarkan pemain untuk terus bergerak.

Kamera yang sedikit lebih maju memang bergerak. Semua entitas dan ubin digambar tanpa offset dan posisi dari mana Anda membuat perubahan. Ini sangat mirip dengan kamera paling dasar, dan Anda masih dapat melakukan banyak optimasi yang sama untuk rendering selektif (hanya memanggil drawapa yang dapat dilihat kamera), pada keduanya. Ini pada dasarnya hanya cara berpikir yang berbeda tentang hal itu.

— MichaelHouse
sumber

Hai Byte, saya sudah menerapkan apa yang Anda katakan dengan sukses ... saya pikir. Tapi sekarang saya mengalami masalah ... bisakah Anda melihatnya? Seorang lelaki berkata bahwa saya sebenarnya tidak memerlukan cam variables... dan menawarkan metode alternatif ... stackoverflow.com/questions/18199373/…

— Growler

Saya akan memeriksanya nanti, untuk saat ini saya sarankan Anda bertanya tentang hal itu dalam obrolan .

— MichaelHouse

Tidak, ini cara yang salah untuk melakukannya.

Bagaimana Anda akan melakukan deteksi perangkap? Bagaimana dengan saat pemain mencapai tepi dinding? Apakah sistem penglihatan Anda berfungsi untuk ruang bawah tanah atau Anda harus menulis ulang sebagian besar kode?

Dunia adalah geometri. Pemain itu geometri. Dunia tidak bergerak. Pemain melakukannya. Atur posisi kamera ke tengah pada pemain. Selalu . Dan hanya itu yang ada untuk itu.

Jangan mencoba dan membiasakan diri dengan "oh jika saya menggeser dunia, maka itu akan memberikan penampilan pemain bergerak". Anda hanya akan memperumit matematika dengan sistem koordinat aneh pada akhir hari.

Memang benar bahwa rendering OpenGL sebenarnya bekerja dengan "memperbaiki kamera untuk menunjuk ke bawah - z, dan mengubah dan memutar semua geometri dunia sehingga sesuai dengan volume tampilan kanonik", tetapi Anda tidak seharusnya berpikir seperti itu saat pemrograman . gluLookAtmemiliki parameter bernama eye,, lookdan upkarena suatu alasan - sehingga Anda dapat berpikir dalam hal sistem koordinat yang masuk akal.

— bobobobo
sumber

Salah satu kesalahan terbesar yang saya buat dengan sistem UI GL yang saya kembangkan adalah mencoba untuk bekerja dalam koordinat kanonik ([-1,1]) "untuk membuatnya lebih sederhana". Semua objek layar memiliki koordinat dalam [-1,1]. Ini adalah kesalahan besar , saya terus-menerus mencoba berpikir dalam kisaran [-1,1] ini, mengubah antara piksel dan NDC, mengonversi kembali. Ketika saya menyerah pada ide ini untuk bekerja di NDC dan hanya bekerja dalam piksel dan dikonversi ke NDC sebelum melakukan rendering seperti yang seharusnya , ada perbedaan besar dalam betapa mudahnya memikirkan elemen-elemen penentuan posisi di layar, proses masukan acara, dll.

— bobobobo