Quali vantaggi hanno OpenGL, SFML e SDL rispetto al rendering software?

Ho iniziato a guardare il flusso di Hero fatto a mano , in cui Casey Muratori crea un motore di gioco senza utilizzare framework o simili. Ieri sono arrivato alla parte in cui ha mostrato come un'immagine viene disegnata sullo schermo. Per quanto ho capito, ha appena allocato un po 'di memoria grande quanto la dimensione dello schermo che vuole disegnare. Quindi ha creato una bitmap che ha passato alla memoria buffer che ha allocato e l'ha disegnata sullo schermo usando una specifica funzione os.

Questo sembra abbastanza semplice. Ho usato GameMaker, cambiato in Love2D, ho lavorato un po 'con Sprite Kit, ma mi chiedevo sempre cosa stesse realmente accadendo sotto questo strato a volte confuso.

Detto questo, perché anche preoccuparsi di usare le librerie grafiche (OpenGL, SFML, SDL, ...) quando tutto ciò che devi fare è semplicemente allocare un po 'di buffer, passare una bitmap e disegnarla sullo schermo?

Se poi vuoi disegnare cose distinte sullo schermo, devi semplicemente scriverle sulla tua bitmap che poi viene passata nel buffer. Sono abbastanza nuovo nella programmazione, ma questo mi sembra abbastanza semplice. Per favore correggimi se sbaglio.

Non si tratta solo di velocità di esecuzione, ma anche di semplicità. Sebbene il rendering del software utilizzato in questo esempio sia molto più lento rispetto all'utilizzo dell'accelerazione hardware (ovvero una GPU), disegnare alcune bitmap sullo schermo è un compito così banale che non si noterà un calo delle prestazioni.

Tuttavia, attività di basso livello come la rasterizzazione dei triangoli, l'ordinamento di profondità e simili sono concetti ben compresi che la GPU può gestire implicitamente con pochi comandi. La reimplementazione di quelli in modalità software sta essenzialmente reinventando la ruota. Questo va bene se vuoi ottenere una comprensione di basso livello di come viene eseguito il rendering, io stesso ho scritto un renderer software 3D solo per esplorarlo un po ', ma per la maggior parte dei casi è una perdita di tempo quando OpenGL può farlo più velocemente la scatola.

L'esempio che hai dato suona in modo estremamente semplice, disegnando una singola immagine sullo schermo, quindi l'implementazione è semplice. Una volta che inizi a stratificare sulla complessità, scoprirai che diventa sempre più complicato ottenere tutto il rendering correttamente. Le cose che le persone dovevano fare nei giorni di Quake del rendering del software 3D erano pazze, anche se apprezzo che non andrai così lontano (ancora).

La mia domanda è: perché nemmeno preoccuparsi di usare qualcosa come open gl, sfml, sdl quando tutto ciò che devi fare è semplicemente allocare un po 'di buffer, passare una bitmap e disegnarla sullo schermo?

Breve: perché è veloce (OpenGL, DirectX).

Lungo:

Puoi pensare di poterlo fare tutto da solo. Disegna i pixel su uno schermo. Potresti scrivere una piccola libreria per disegnare forme, come quadratini o triangoli. Questo funzionerà, ovviamente. Ci sono molte librerie là fuori per fare esattamente questo. Alcuni di loro implementano persino le specifiche OpenGL (quindi sono come un lato software per l'opengl) che farà esattamente quello che fa Casey Muratori. Calcolano tutto sul lato software, impostano i pixel sul lato software e scrivono il risultato sullo schermo.

Tuttavia questo è lento . La CPU che alla fine eseguirà tutte queste cose non è stata creata per questo scenario. Ecco a cosa servono le GPU. Ciò che OpenGL fa (a meno che non sia un'implementazione del software ovviamente) è prendere tutto ciò che gli dici di fare e inviare tutti i dati, tutte le chiamate di disegno, quasi tutto sulla scheda grafica e dire alla GPU di fare il lavoro. La GPU è stata creata appositamente per questo tipo di lavoro. Moltiplicare i numeri in virgola mobile (ecco cosa fai molto quando disegni una scena 3D) ed esegui shader. E questo in parallelo. Solo per farti un'idea di quanto è veloce la GPU, pensa a una semplice scena in 3D a schermo intero con 1920x1080 pixel. Questi sono, moltiplicati, 2.073.600 pixel da disegnare. Per ogni singolopixel, la GPU eseguirà il framment-shader almeno una volta , il più delle volte più di una volta. Ora, supponiamo che corriamo a 60 frame al secondo. Ciò significa che la GPU esegue il framment-shader 2.073.600 * 60 = 124.416.000 volte al secondo . Pensi di poter fare qualcosa del genere sulla tua CPU? (Questa è una spiegazione piuttosto semplificata, ci sono molte più cose da considerare come il numero di pixel che sorpassi da oggetti più vicini, quanti MSAA usi e così via, tuttavia le 124.416.000 volte al secondo sono probabilmente il più basso che puoi ottenere, e tu avrò facilmente molto più di 60 fps con una scena semplice)

Questo è ciò che fanno OpenGL e Direct3D, per ciò che i motori vedono la risposta di @Uri Popovs.

Quello che fa è chiamato rendering software , ciò che OpenGL fa è chiamato rendering GPU

Qual è la differenza tra loro? Velocità e memoria.

La rasterizzazione (compilazione di triangoli sullo schermo) richiede del tempo. Se lo fai sulla CPU, in sostanza prendi quel tempo lontano dalla logica di gioco, soprattutto se non è ottimizzato bene.

E non importa quanto sia piccola l'immagine, deve allocare una certa quantità di memoria. Le GPU hanno una memoria video per questo.

Mentre le risposte degli altri sono più corrette di qualsiasi risposta io possa dare, voglio sottolineare il fondamentale fraintendimento su come funziona lo sviluppo del software che penso sia alla base della tua domanda. Mentre è sempre possibile fare le cose "da soli" senza un framework, e spesso c'è un grande vantaggio educativo nel farlo, la realtà è che non è così che viene creato il software moderno.

Qualcuno ha creato l'hardware e i linguaggi della macchina che girano su di esso. Qualcun altro crea linguaggi e compilatori di livello superiore, driver e sistemi operativi, librerie grafiche e così via. Ognuno di noi si basa sul lavoro dei nostri predecessori. Non è solo "ok", è un requisito.

Stai disegnando la linea di ciò che è "accettabile" o meno in un punto arbitrario nella toolchain. Potresti semplicemente dire "perché usare C ++ quando puoi fare la stessa cosa in assembly?", O "perché affidarti ai driver della tastiera quando puoi leggere altrettanto facilmente le tensioni che escono dai suoi fili e calcolarlo da solo?" Non ci sono abbastanza ore al giorno o anni nella vita perché tutti possano fare tutto da soli.

Questo non si applica solo allo sviluppo del software, ma alla vita moderna in generale. Hai mai sentito parlare del tizio che ha costruito lui stesso un tostapane, da zero? http://www.thomasthwaites.com/the-toaster-project/ . Ci è voluto molto tempo e molti sforzi. Per un tostapane. Prova a costruire tutto ciò che è necessario per attualizzare un videogioco fuori dall'etere da solo!

I motori fanno molto di più che basta disegnare un'immagine sullo schermo. Gestiscono illuminazione, ombre, input, rilevamento delle collisioni. Anche solo la parte di rendering è molto più complessa della semplice pressione di un buffer sullo schermo. Soprattutto per le scene 3d devi fare molti calcoli su dati molto più complessi di una bitmap. Lascia che ti dia un'analogia con un'auto: quello che stai descrivendo come semplice è lo scarico dell'auto. Basta fare un tubo con le giuste dimensioni e quindi si spinge il gas da un'estremità all'altra. Tuttavia, questo è ben lungi dall'essere l'unica cosa che accade nel meccanismo dell'auto.

Le risposte di cui sopra sono eccellenti, ma nessuna va oltre il motivo più importante per cui si preferiscono OpenGL e simili. Il motivo principale è utilizzare hardware dedicato progettato appositamente per funzionare con cose come il rendering di milioni di pixel su uno schermo, la GPU .

Con il rendering del software, utilizzando la CPU, il renderer eseguirà il ciclo, uno per uno, su tutti i pixel di una bitmap ed emetterà ordini per mostrarli tutti sullo schermo. Quindi, se stai eseguendo il rendering di un'immagine di dimensioni 1000x1000, i 1.000.000 di loop per la tua CPU vanno oltre. Dopo tutto, sono progettati pensando al controllo; molte condizioni se, saltando da una serie di istruzioni all'altra e una direzione rigorosa del flusso di controllo. Tuttavia, una GPU è progettata con la consapevolezza che eseguirà molti loop simili su pixel sullo schermo.Una GPU farebbe un ciclo for con 1000000 iterazioni e dividerebbe il lavoro sul suo enorme numero di core affinché ciascuno funzioni ** in parallelo e indipendente l'uno dall'altro **. Quindi, diversamente dalla CPU, ogni volta che una GPU incontra una condizione if-else, gestirà entrambi i rami del codice su due core di se stesso E ALLORA, alla fine, guarderà a cosa valuta la condizione e scarta il risultato del ramo non necessario (ecco perché molte condizioni if-else negli shader GPU sono disapprovate; sono sempre responsabili di uno spreco).

Quindi sì, le GPU sono costruite attorno al parallelismo . Ciò rende il lavoro sui pixel per loro molto più veloce rispetto alle CPU.

Vedi Devo davvero usare un'API grafica?

Certo, puoi chiedere un buffer, impostare alcuni bit e scriverlo sullo schermo. Questo era essenzialmente l'unico modo per eseguire la programmazione grafica su PC fino alla disponibilità di acceleratori grafici a metà degli anni '90 da 3DFX. Anche in Windows, DirectX è stato sviluppato per fornire accesso diretto alla memoria video.

Ma su hardware non PC, macchine da gioco dedicate, ci sono sempre state tecniche per accelerare la grafica scaricando il lavoro dal processore. Anche l'Atari 2600 aveva "sprite hardware", in parte perché non aveva abbastanza RAM per un framebuffer.

Le console di gioco successive (metà degli anni '80) furono ottimizzate per i giochi con piattaforma. Ancora una volta, nessun framebuffer; invece il programmatore potrebbe specificare griglie di tessere :

L'hardware grafico Genesis è composto da 2 piani scorrevoli. Ogni piano è composto da tessere. Ogni riquadro è un quadrato di 8x8 pixel con 4 bit per pixel. Ogni pixel può quindi avere 16 colori. Ogni riquadro può utilizzare 1 di 4 tabelle di colori, quindi sullo schermo puoi ottenere 64 colori contemporaneamente, ma solo 16 in ogni riquadro specifico. Le piastrelle richiedono 32 byte. 64 KB di memoria grafica. Ciò consentirebbe 2048 tessere uniche se la memoria fosse utilizzata per nient'altro.

Le moderne CPU sono abbastanza veloci da fare qualsiasi gioco 2D nel software, quindi OpenGL / DirectX per la grafica 2D non offrirebbe alcun vantaggio, oltre ad aggiungere un'altra dipendenza e uno strato di complessità al tuo progetto, come ad esempio impostare una matrice di proiezione 3d per disegnare un mucchio di sprite e caricamento di dati su GPU.

OpenGL ti costringerebbe anche a impacchettare tutti i tuoi sprite all'interno di trame 512x512 (un artefatto di vecchie console, come PSX, che impacchettano la grafica in pagine di memoria video), richiedendo di scrivere un codice di impacchettamento degli sprite piuttosto complesso.

D'altra parte, se stai facendo 3d, renderizzando milioni di triangoli con ombreggiature complesse, allora la GPU è inevitabile. Molto tempo fa esisteva la versione 2d più semplice di Direct3d, chiamata DirectDraw, che la GPU accelerava il disegno sprite, ma ora Microsoft non lo supporta più, forse perché le CPU sono abbastanza veloci da fare 2d senza accelerazione, se non ti interessa il risparmio energetico .