programming_tutorials/04_opengl_basics/wip/ogl/sw_render.txt

double buffer
windowed mode etc igy megy -> kép kiiszámol bufferbe swap
render resolution -> scale

framebuffer
pixelek, color values rgb bztes
per pixel transparencz

2d koord -> 1d coord


window

sw render
pixelek
cpun kiszámol

//raycaster

hardware render //gpu

ogl, ogl es, dx, vulkan, metal, etc 

sok mag
milzen magok nem cpou
mother of all multithreading


gpunak feldolgozható formátumra alakítjuk -> vertexek texek etc

visszakapjuk a framet

meshek -> megmutat , plussz 2ds guival is
triket tud rajzolni

gpunak feldolgozható formátum

a gpu gzakorlatilag 3szögetek tud csak kirajzolni. -> rendering api függő

koordináta rendszer -> mi választjuk meg -> egy kamera gyakorlatilag mátrixtranzformáció -> fogunk 4ds mátrixot ->  relativitás -> a lényeg
hogy egy 3ds v 2ds modell a kamerához képest jó helyen legyen -> cam mátrixxal megszorozunk egy objektum minden vertexét -> 
úgy lehet értelmezni, hogy odaviszi az origóhoz őket -> és a megadott képernyőnkön a megadott mátrixal pont az lessz kirajzolva amit akarunk

-> left handed right handed 

0 
   \
I    \
       \
1   --   2

-> koordináta rendzser Ó kamerától függ, hogy végül mekkora lessz a képer nyőn -> ált fizikai mértékegységeket használnak
-> az eredméyn ugyan az, mert úgy van megcsinálva

vertex

index -> indices -> lehet 2d v 3d is -> de mindig 1ds tömb -> [ 0, 1, 0, 0, 1, 0 ] vagy [ 0, 1, 0, 0, 0, 0, 1, 0, 0 ]

tömb -> [0, 1, 2] v [ 0, 2, 3 ] -> nem ugyan az! -> winding order

face culling 
mi mondjuk meg a winding ordert -> cw, ccw
->mi mondjuk meg, hogy legyen e face vulling és hogy melyik -> backface, frontface, off 
-> pl cel shader outline -> backface 

összekötés-> sorrend nem mindegy -> culling

efficiensebb, de nem mindig lehet (texture atlas):

0   --   3
   \
I    \   I
       \
1   --   2

[0, 1, 2, 0, 2, 3] 


0,3   --   5
   \
I    \   I
       \
1   --   2, 4

[0, 1, 2, 3, 4, 5] 


vertex egyéb adadtok -> minden vertexhez 1 bejegyzés tartozik a tömbből
uv, uvx, color, normal etc lehet saját
több tömb

uv map:
textúrát feltöltjük gpoura

0,0   --   1,0
    \
I     \     I
        \
0,1   --   1,1

-> minecraft

-> csálunk tömböket

shaderek:
script program ami a gpun fut

vertex, fragment

vertex: minden vertre
vannak változói amiket bepopulál a gpu a beállításoknak megfelelően -> vec3 uv -> meg,monjuk hogy glAddArr(uv arr, size, shader param)

frag minden fragment

azaz minden virtuális pixelre, amin az aktuális 3ds modell látható

zbufffer
egy tömb ami a pixelek jelenlegi mélységét tárolja
z fighting
->note átlátszóság 

skybox -> csak kirajzoljuk alapnak, meg buffer töröl
 lazered render -> skzbox, etc -> pl portal,

shderek :
gl 2.0+

pl videókártya hads törés etc 

újabbakba van compzute shader, cuda etc


gl 1.0 foixed pipeline

immediate mode render
nem annyira optimális
eqvivalens azzal mintha mutex lenne  vs megy a thread a háttérbven

jó debugra
áll a gpu, cpu küldés overhead etc
de könnyebb most 




//app


mainloop

show

//framerate independency
delta = 0;

start = time()
input()
update(delta)
render()

slduration = (1/60) - time() - starty()
if (slduration > 0)
    sleep(slduration)


delta= time() - starty()


capped framreate, not capped, maybe vsync

//animations
mozgókép -> hogy megy

input-> kari update poz
process -> pl dobozok update, mob update
render


//gui upaz, de van
bool shoiuld_render = false;

input-> minden updateli magát in pőlace -> más optimalizáció, az elemek újrarenderelhetik magukat néha -> sw főleg
process -> pl van animáció, lehet hogy kimarad

if shoiuld_render:
    render