Keuntungan apa yang dimiliki OpenGL, SFML dan SDL dibandingkan rendering perangkat lunak?

24

Saya mulai menonton aliran Handmade Hero , di mana Casey Muratori menciptakan mesin permainan tanpa menggunakan kerangka atau semacamnya. Kemarin saya sampai pada bagian di mana dia menunjukkan bagaimana gambar digambar ke layar. Sejauh yang saya mengerti dia hanya mengalokasikan beberapa memori sebesar ukuran layar yang ingin dia gambar. Dan kemudian dia menciptakan bitmap yang dia berikan ke memori buffer yang dia alokasikan dan menggambarnya ke layar menggunakan fungsi spesifik os.

Ini tampaknya cukup lurus ke depan. Saya menggunakan GameMaker, berubah menjadi Love2D, bekerja sedikit dengan Sprite Kit tetapi saya selalu bertanya-tanya apa yang sebenarnya terjadi di bawah lapisan yang terkadang membingungkan ini.

Mengingat itu, mengapa repot-repot menggunakan pustaka grafis (OpenGL, SFML, SDL, ...) ketika semua yang harus Anda lakukan hanyalah mengalokasikan beberapa buffer, meneruskan bitmap dan menggambarnya ke layar?

Jika Anda kemudian ingin menggambar hal-hal yang berbeda untuk layar Anda, Anda hanya menulis mereka ke bitmap Anda yang kemudian diteruskan ke buffer. Saya cukup baru dalam pemrograman, tetapi ini tampaknya cukup sederhana bagi saya. Harap perbaiki saya jika saya salah.

pengguna148013
sumber
11
nanti dalam seri-nya (sekitar episode 220) ia akan menggunakan opengl. Alasan dia melakukan itu adalah kecepatan.
ratchet freak
5
Caranya adalah menentukan apa yang akan ditarik ke layar. Semua hal tekstur GPU / bayangan, segitiga, proyeksi kamera, dll. Harus dilakukan terlebih dahulu untuk memutuskan apa warna setiap piksel. Mendorong warna piksel ke layar adalah bagian yang mudah.
user14146
2
Sebagai catatan, SDL dan OpenGL tidak saling eksklusif. SDL adalah "lapisan abstraksi perangkat keras" yang juga menangani jendela, acara, dan input yang bertentangan dengan sekadar perpustakaan grafis. SDL juga memiliki dukungan untuk digunakan bersama dengan OpenGL sehingga SDL dapat melakukan semua hal non-grafis sementara OpenGL menangani gambar. Juga perhatikan bahwa OpenGL paling sering bekerja langsung dengan GPU sedangkan SDL mungkin atau mungkin tidak tergantung pada versi dan sistem yang dikompilasi.
Pharap
SFML menggunakan OpenGL untuk rendering, jadi sebenarnya semua yang dilakukan SFML adalah menyediakan antarmuka yang lebih sederhana untuk menggunakan OpenGL.
Cornstalks
2
Techcnailyl apa yang dilakukan Casey masih menggunakan perpustakaan grafis. Pustaka ini disebut GDI , dan meskipun itu merupakan bagian dari API utama OS, pustaka ini secara teknis masih berupa pustaka grafis.
Pharap

Jawaban:

41

Ini bukan hanya tentang kecepatan eksekusi, tetapi juga tentang kesederhanaan. Meskipun rendering perangkat lunak yang digunakan dalam contoh ini akan jauh lebih lambat daripada menggunakan akselerasi perangkat keras (yaitu GPU), menggambar beberapa bitmap di layar adalah tugas yang sepele sehingga Anda tidak akan melihat penurunan kinerja.

Namun, aktivitas tingkat rendah seperti rasterisasi segitiga, pengurutan dalam dan sejenisnya adalah konsep yang dipahami dengan baik bahwa GPU dapat menangani secara implisit dengan beberapa perintah. Menerapkan kembali mereka dalam mode perangkat lunak pada dasarnya menciptakan kembali roda. Ini bagus jika Anda ingin mendapatkan pemahaman tingkat rendah tentang bagaimana rendering dilakukan, saya sendiri menulis renderer perangkat lunak 3D hanya untuk menjelajahinya sedikit, tetapi untuk sebagian besar keadaan itu membuang-buang waktu ketika OpenGL dapat melakukannya lebih cepat dari kotak.

Contoh yang Anda berikan terdengar sangat mendasar, hanya menggambar satu gambar di layar, maka implementasinya mudah. Namun, begitu Anda mulai melapisi kerumitan, Anda akan merasa semakin rumit untuk mendapatkan semua yang dirender dengan benar. Hal-hal yang harus dilakukan orang-orang di masa Gempa rendering perangkat lunak 3D adalah gila, meskipun saya menghargai Anda tidak akan sejauh itu (belum).

Richard Greenlees
sumber
12
OpenGL tahu istilah seperti titik, garis, dan segitiga. Sebagian besar waktu Anda akan bekerja dengan segitiga. Untuk mempelajari cara bekerja dengan OpenGL saya dapat merekomendasikan opengl-tutorial.org . Untuk mengetahui apa yang dilakukan OpenGL di bawah tenda, lihatlah wiki resmi: opengl.org/wiki/Rendering_Pipeline_Overview
tkausl
1
Saya akan memberi +1 tetapi saya tidak suka sedikit tentang "menciptakan kembali roda" karena saya merasa itu memberi kesan yang salah dalam hal sejarah komputasi. Render Bitmap adalah yang pertama, maka OpenGL adalah yang "menciptakan kembali roda". Mereka memiliki dua alasan bagus untuk melakukannya: 1) Standardisasi dan 2) akselerasi GPU. Menciptakan kembali roda tidak selalu merupakan hal yang buruk jika versi baru merupakan peningkatan (yaitu roda dengan ban vs roda gerobak kayu). Poin kuncinya di sini bukanlah bahwa rendering perangkat lunak adalah menciptakan kembali roda, itu harus lebih rendah daripada rendering GPU.
Pharap
4
@Pharap kecuali sekarang , menulis penyaji perangkat lunak benar-benar menciptakan kembali roda, terlepas dari apakah itu secara historis atau tidak.
porglezomp
1
Ini hanya setengah jawaban. Jawaban selanjutnya adalah separuh yang lain, tetapi jawaban yang lengkap (termasuk sedikit penjelasan tentang perbedaan antara OpenGL dan hal-hal lain yang ia sebutkan) akan menjadi jawaban yang tepat untuk pertanyaan ini.
Jasper
1
@ user148013 "Apakah opengl tahu istilah seperti titik, garis, segitiga?" OpenGL modern berurusan secara eksklusif dengan primitif ini. Anda tidak dapat merasterisasi apa pun kecuali mereka.
Nax 'vi-vim-nvim'
25

Pertanyaan saya adalah: mengapa repot-repot menggunakan sesuatu seperti open gl, sfml, sdl ketika semua yang harus Anda lakukan hanyalah mengalokasikan beberapa buffer, meneruskan bitmap dan menggambarnya ke layar?

Pendek: Karena cepat (OpenGL, DirectX).

Panjang:

Anda mungkin berpikir Anda bisa melakukan ini sendiri. Gambar piksel ke layar. Anda dapat menulis perpustakaan kecil untuk menggambar bentuk, seperti paha depan atau segitiga. Ini akan berhasil, tentu saja. Ada banyak perpustakaan di luar sana untuk melakukan hal ini. Beberapa dari mereka bahkan mengimplementasikan OpenGL-spec (sehingga mereka seperti sisi perangkat lunak untuk OpenGL) yang akan melakukan persis seperti yang dilakukan Casey Muratori. Mereka menghitung semuanya pada sisi perangkat lunak, mengatur piksel pada sisi perangkat lunak dan menuliskan hasilnya ke layar.

Namun ini lambat . CPU yang pada akhirnya akan menjalankan semua hal ini tidak dibuat untuk skenario ini. Untuk itulah GPU digunakan. Apa yang dilakukan OpenGL (kecuali tentu saja itu adalah implementasi perangkat lunak) adalah mengambil semua yang Anda suruh untuk dilakukan dan mendorong semua data, semua panggilan-draw, hampir semuanya ke kartu grafis dan memberitahu GPU untuk melakukan pekerjaan. GPU dibuat khusus untuk jenis pekerjaan ini. Mengalikan angka floating point (thats apa yang Anda lakukan banyak ketika menggambar 3D-adegan) dan mengeksekusi shader. Dan ini secara paralel. Hanya untuk membuat Anda merasakan seberapa cepat GPU, pikirkan tentang adegan sederhana dalam 3D dalam layar penuh dengan 1920x1080 piksel. Ini adalah, dikalikan, 2.073.600 piksel untuk menggambar. Untuk setiap orangpixel, GPU akan menjalankan fragmen-shader setidaknya sekali , sebagian besar kali lebih dari sekali. Sekarang, katakanlah kita menjalankan 60 frame per detik. Ini berarti, GPU menjalankan fragmen-shader 2.073.600 * 60 = 124.416.000 kali per detik . Apakah Anda pikir Anda dapat melakukan hal seperti ini pada CPU Anda? (Itu penjelasan yang cukup disederhanakan, ada banyak hal yang perlu dipertimbangkan seperti berapa banyak piksel yang Anda overdraw oleh benda yang lebih dekat, berapa banyak MSAA yang Anda gunakan dan sebagainya, namun 124.416.000 kali per detik mungkin adalah yang terendah yang bisa Anda dapatkan, dan Anda Akan dengan mudah memiliki lebih dari 60fps dengan adegan sederhana)

Itulah yang dilakukan OpenGL dan Direct3D, untuk mesin apa yang melihat @Uri Popovs menjawab.

tkausl
sumber
8
Dia membuat game 2D, itu topik lain seperti 3D. Dan ketika saya mengatakan lambat itu tidak berarti bahwa ia memiliki kurang dari 60 fps tetapi itu berarti bahwa kartu grafis akan melakukan pekerjaan yang sama di sebagian kecil dari waktu yang dibutuhkan CPU, setidaknya ketika datang ke ruang 3D.
tkausl
4
Ya alasan GPU lebih baik karena mereka diatur untuk memparalelkan shader.
ratchet freak
4
@ user148013 Dari apa yang saya lihat dari orang ini, saya akan mengatakan dia kebalikan dari "sangat bijak".
Bartek Banachewicz
4
Bukan hanya karena lebih lambat untuk di-render (renderer perangkat lunak Casey sangat cepat). Itu juga banyak data untuk terus mendorong dari RAM umum ke RAM video. Mendorong bitmap raksasa ke kartu video, tergantung pada jenis busnya, bisa memakan waktu yang cukup lama. Menggunakan GPU, Anda sesekali menekan tekstur, dan menggunakannya untuk frame demi frame.
Adrian McCarthy
2
@ user148013 Ada perbedaan antara pemrograman yang mencolok dan bagus. Mereka dapat tumpang tindih, tetapi seringkali mereka berada dalam konflik. Saya meletakkan "Saya dapat menerjemahkan dalam perangkat lunak [seperti halnya MESA dapat ...]" di bawah mencolok dan tentu saja tidak baik .
11

Apa yang dia lakukan disebut rendering perangkat lunak , yang dilakukan OpenGL disebut rendering GPU

Apa perbedaan di antara mereka? Kecepatan dan memori.

Rasterisasi (mengisi segitiga di layar) membutuhkan waktu. Jika Anda melakukannya pada CPU, Anda pada dasarnya mengambil waktu itu dari logika permainan, terutama jika itu tidak dioptimalkan dengan baik.

Dan tidak masalah, seberapa kecil gambarnya, ia perlu mengalokasikan sejumlah memori untuk itu. GPU memiliki memori video untuk ini.

Bálint
sumber
Apakah rendering perangkat lunak juga dimungkinkan pada OS X? Karena sepertinya semua yang ada hubungannya dengan grafis dilakukan oleh OpenGl sekarang Metal.
user148013
2
@ user148013 Anda memiliki beberapa kesalahpahaman. OpenGL adalah multiplatform API, sehingga dapat berjalan di OS X, bahkan dapat berjalan di semua hal dengan GPU "modern" (post 2000). Logam adalah API terpisah untuk perangkat Apple saja. Render perangkat lunak juga merupakan hal yang terpisah dari keduanya, dan ya, itu dapat dilakukan pada OS X juga. Ini pada dasarnya hanya mengatur piksel secara manual di layar dengan CPU.
Bálint
Itulah mengapa saya bertanya karena sejauh yang saya tahu perenderan perangkat lunak tidak dapat dilakukan pada OS X. Kakao menjangkau ke OpenGl, Quarz menggunakan OpenGl, Core Framework menggunakan OpenGl. Mereka semua sekarang menggunakan Metal sebagai jalannya lebih cepat. Tetapi saya belum menemukan satu fungsi yang menarik buffer ke layar tanpa menggunakan GPU (OpenGl, Metal).
user148013
1
@ user148013 Karena tidak spesifik untuk OS, atau implementasi. Katakanlah Anda ingin mengimplementasikannya di java, karena itu pilihan yang terkenal untuk pengembangan multi-platform. Dengan java, Anda bisa melakukannya dengan terlebih dahulu membuat jendela (JFrame), lalu alih-alih menggambar lurus di atasnya, Anda menggambar pada gambar, lalu Anda meletakkan gambar ini pada bingkai. Namun tidak akan tahu istilah "segitiga" atau "garis". Hanya warna. Anda perlu mengimplementasikannya sendiri dengan algoritma rasterization. Inilah mengapa kami lebih suka OpenGL, lebih cepat, dan sedikit lebih mudah digunakan. Ini pada dasarnya adalah API rasterisasi.
Bálint
2
@ user148013 Kenapa tidak? Jika mereka dapat membuka jendela, dan mereka dapat menggambar 1 gambar di atasnya tanpa API, maka mereka bisa.
Bálint
8

Sementara jawaban dari orang lain lebih benar daripada jawaban yang bisa saya berikan, saya ingin menunjukkan kesalahpahaman mendasar tentang bagaimana pengembangan perangkat lunak bekerja yang menurut saya mendasari pertanyaan Anda. Meskipun selalu mungkin untuk melakukan hal-hal "sendiri" tanpa kerangka kerja, dan seringkali ada manfaat pendidikan yang besar dari melakukannya, kenyataannya adalah bukan bagaimana perangkat lunak modern dibuat.

Seseorang menciptakan perangkat keras dan bahasa mesin yang berjalan di atasnya. Orang lain membuat bahasa dan kompiler tingkat tinggi, driver dan sistem operasi, perpustakaan grafik dan seterusnya. Kita masing-masing membangun atas karya para pendahulu kita. Itu bukan hanya "oke", itu suatu keharusan.

Anda menarik garis dari apa yang "dapat diterima" atau tidak pada titik sembarang dalam rantai alat. Anda bisa dengan mudah mengatakan "mengapa menggunakan C ++ ketika Anda bisa melakukan hal yang sama dalam perakitan?", Atau "mengapa mengandalkan driver keyboard ketika Anda bisa dengan mudah membaca voltase yang keluar dari kabelnya dan menghitungnya sendiri?" Tidak ada cukup jam dalam sehari, atau bertahun-tahun seumur hidup bagi setiap orang untuk melakukan semuanya sendiri.

Ini tidak hanya berlaku untuk pengembangan perangkat lunak, tetapi untuk kehidupan modern secara umum. Pernahkah Anda mendengar tentang pria yang membuat pemanggang roti sendiri, dari nol? http://www.thomasthwaites.com/the-toaster-project/ . Butuh waktu yang sangat lama dan banyak usaha. Untuk pemanggang roti. Cobalah membangun semua yang diperlukan untuk mengaktualisasikan gim video dari eter semuanya sendirian!

erich8
sumber
2
Saya pikir ini adalah jawaban yang baik karena menyatakan mengapa menggunakan kerangka kerja itu baik tanpa meremehkan gagasan menciptakan kembali roda untuk tujuan pendidikan.
Pharap
3

Mesin melakukan lebih banyak hal yang hanya menggambar di layar. Mereka menangani pencahayaan, bayangan, input, deteksi tabrakan. Bahkan hanya bagian rendering jauh lebih kompleks daripada hanya mendorong buffer ke layar. Untuk adegan 3d khususnya Anda perlu melakukan banyak perhitungan pada data yang jauh lebih kompleks daripada bitmap. Biarkan saya memberi Anda analogi dengan mobil: Apa yang Anda gambarkan sebagai sederhana adalah knalpot mobil. Anda cukup membuat pipa dengan ukuran yang tepat dan kemudian Anda mendorong gas dari satu ujung ke ujung lainnya. Namun ini jauh dari satu-satunya hal yang terjadi dalam mekanisme mobil.

Uri Popov
sumber
3

Jawaban di atas sangat baik, tetapi tidak ada yang benar-benar melampaui alasan paling penting mengapa OpenGL dan yang lebih disukai. Alasan utama adalah untuk menggunakan perangkat keras khusus yang dirancang khusus untuk bekerja dengan hal-hal seperti rendering jutaan piksel pada layar, GPU .

Dengan perenderan perangkat lunak, menggunakan CPU, renderer akan melakukan perulangan, satu per satu, pada semua piksel pada bitmap dan mengeluarkan perintah untuk menampilkan masing-masing di layar. Jadi, jika Anda merender gambar berukuran 1000x1000, 1.000.000 loop untuk CPU Anda akan berakhir. Mereka dirancang dengan kontrol dalam pikiran; banyak kondisi jika, melompat dari satu set instruksi ke yang lain dan arah aliran kontrol yang ketat. Namun, sebuah GPU dirancang dengan pengetahuan bahwa ia akan melakukan banyak perulangan piksel serupa pada layar.GPU akan mengambil loop for dengan iterasi 1000000 dan membagi pekerjaan lebih dari jumlah inti untuk masing-masing untuk bekerja ** secara paralel, dan independen satu sama lain **. Jadi tidak seperti CPU, setiap kali GPU menemukan kondisi if-else, ia akan menangani kedua cabang kode untuk dua inti dari dirinya sendiri DAN LALU, pada akhirnya, itu akan melihat apa yang dievaluasi kondisi dan membuang hasil dari cabang yang tidak dibutuhkan (itu sebabnya banyak kondisi if-else di GPU shaders tidak disukai; mereka selalu bertanggung jawab atas pemborosan).

Jadi ya, GPU dibangun berdasarkan paralelisme . Itu membuat bekerja pada piksel untuk mereka jauh lebih cepat dibandingkan dengan CPU.

Aiman ​​Al-Eryani
sumber
0

Lihat Apakah saya benar-benar perlu menggunakan API grafik?

Tentu, Anda dapat meminta buffer, mengatur beberapa bit di dalamnya dan menuliskannya ke layar. Itu pada dasarnya satu-satunya cara untuk melakukan pemrograman grafis pada PC sampai ketersediaan akselerator grafis pada pertengahan 90-an dari 3DFX. Bahkan di Windows, DirectX dikembangkan untuk memberikan akses langsung ke memori video.

Tetapi pada perangkat keras non-PC, mesin permainan khusus, selalu ada teknik untuk mempercepat grafik dengan melepas pekerjaan dari prosesor. Bahkan Atari 2600 memiliki "sprite perangkat keras", sebagian karena tidak memiliki cukup RAM untuk framebuffer.

Kemudian (pertengahan 80-an) konsol game dioptimalkan untuk game platform. Sekali lagi, tidak ada framebuffer; alih-alih, pemrogram dapat menentukan kisi-kisi ubin :

Perangkat keras grafis Genesis terdiri dari 2 pesawat yang dapat digulir. Setiap pesawat terbuat dari ubin. Setiap ubin berukuran 8x8 piksel persegi dengan 4 bit per piksel. Setiap piksel dapat memiliki 16 warna. Setiap ubin dapat menggunakan 1 dari 4 tabel warna, jadi pada layar Anda bisa mendapatkan 64 warna sekaligus, tetapi hanya 16 di ubin tertentu. Ubin membutuhkan 32 byte. Ada memori grafis 64K. Ini akan memungkinkan 2048 ubin unik jika memori digunakan untuk hal lain.

pjc50
sumber
-2

CPU modern cukup cepat untuk melakukan permainan 2d apa pun dalam perangkat lunak, jadi untuk grafis 2d, OpenGL / DirectX tidak akan menawarkan keuntungan, di samping menambahkan ketergantungan lain dan lapisan kerumitan pada proyek Anda, seperti mengatur matriks proyeksi 3d untuk menarik banyak sprite dan mengunggah data ke GPU.

OpenGL juga akan memaksa Anda untuk mengemas semua sprite Anda di dalam tekstur 512x512 (sebuah artefak dari konsol lama, seperti PSX, mengemas grafik ke dalam halaman memori video), mengharuskan Anda untuk menulis kode pengemasan sprite yang agak rumit.

Di sisi lain, jika Anda melakukan 3d, merender jutaan segitiga dengan bayangan yang kompleks, maka GPU tidak dapat dihindari. Dahulu ada versi Direct3d 2d yang lebih sederhana, yang disebut DirectDraw, yang GPU mempercepat gambar sprite, tetapi sekarang Microsoft tidak lagi mendukungnya, mungkin karena CPU cukup cepat untuk melakukan 2d tanpa akselerasi, jika Anda tidak peduli dengan penghematan energi .

SmugLispWeenie
sumber