játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5511
FZoli:    4894
Kuz:    4455
gaborlabor:    4449
kicsy:    4304
TPG:    3402
monostoria:    3284
DMG:    3172
HomeGnome:    2919
Matzi:    2529

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2198
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1654
syam:    1491
> 1 <
Jedi - Tag | 175 hsz       Online status #51184   2007.04.19 05:46 GMT+1 óra  
Idézet
ShAdeVampirE :
És persze belső térre is van nekünk Portals technikánk, amit akkor érdemes használni, ha nem nagy belső terekkel dolgozunk, hanem kisebb, elszeparáltabbakkal (pl. normál szobák), melyeket ajtók választanak el.



Önmagában a sima portál-technikát manapság már nem nagyon alkalmazzák a nagy számításigénye miatt, helyette van PVS. A portáltechnikát inkább már csak a PVS kiegészítéseként használják, mert egy-két feaure-t azért könnyen meg lehet oldani vele, amit PVS-el nem, vagy csak nagyon nehezen lehetne (portálok dinamikus áthelyezése, tükrök, teleportkapuk, ...).

Igazából nem az a baj vele, hogy nagy színterekre nem lehet alkalmazni, hanem az, hogy speciálisan kellene hozzá felépíteni a színterünket, ha jó teljesítményt akarunk vele elérni. Figyelni kell, hogy sose látszódjon túl sok portál egy adott cellából, különben a sok látógúla-vágás miatt megfekszik. Pl. a Duke Nukem 3D (ami sima portálmotor volt) pályáinak felépítésén ez nagyon jól látszik.

   
syam - Törzstag | 1491 hsz       Online status #51172   2007.04.19 01:55 GMT+1 óra  
na kicsit körbenéztem térgörbítés háza táján:
alapvetően 2 technikát találtam - egyik a BVH, másik pedig térfelosztás( octree, kdtree, bsp ill. a uniform grid, ami kicsit kilóg a sorból)
alias aalberik
   
ShAdeVampirE - Törzstag | 1313 hsz       Online status #51165   2007.04.18 22:15 GMT+1 óra  
És persze belső térre is van nekünk Portals technikánk, amit akkor érdemes használni, ha nem nagy belső terekkel dolgozunk, hanem kisebb, elszeparáltabbakkal (pl. normál szobák), melyeket ajtók választanak el.
   
Jedi - Tag | 175 hsz       Online status #51156   2007.04.18 17:34 GMT+1 óra  
Idézet
syam :
az octree a külsö terepre való, bsp (ill. egyéb származéka) pedig belsőre ( tul sok választék nincs)



Azért nem ilyen "szegényes" a választék. Nagyon sok helyen használnak kD-fákat (főleg külső színtérnél), kibővített BVH-t és más hierarchikus grid-eket, mivel ezeket nagyon jól lehet hardveresen gyorsítani. S manapság az a trend, h amit csak lehet, azt nyomjuk át a gpu-ra. Pl. a GameTools-ban is sok ilyen van.

   
syam - Törzstag | 1491 hsz       Online status #51130   2007.04.18 11:28 GMT+1 óra  
az octree a külsö terepre való, bsp (ill. egyéb származéka) pedig belsőre ( tul sok választék nincs)
lehet kombinálni a 2t: ilyenkor az octree egyik cellájába berakják a bspt

az ode tud meg hash alapú térfelosztást, amit máshol nem láttam
alias aalberik
   
ShAdeVampirE - Törzstag | 1313 hsz       Online status #51125   2007.04.18 11:20 GMT+1 óra  
Vki aki jártasabb a témában el tudná mondani, hogy milyen típusú játékhoz mit szoktak használni? Gondolok arra, h pl. Octree-nél egyáltalán nem mind1, h azt egy külső terepre, v belső, irodai terepre alkalmazod; típustól függ az optimális szűrési technika.
   
syam - Törzstag | 1491 hsz       Online status #51071   2007.04.18 08:48 GMT+1 óra  
vagy pedig ROAM - egyik gyakorlati példája az open outcast techdemoja
alias aalberik
   
ferchild - Törzstag | 815 hsz       Online status #51067   2007.04.18 07:56 GMT+1 óra  
CLOD
Feci Barath (by Kuz)
XD
http://már nem elérhető...új lesz
   
comal - Tag | 1 hsz       Online status #51058   2007.04.18 07:32 GMT+1 óra  
Egy összefüggő domborzatnál, hogy oldják meg azt, hogy részletes a felület, és a távolabb levő részek nem részletgazdagok? Ahogy közeledek az adott ponthoz, úgy változik a részletessége.
Köze van ennek a geomorph vagy octree technikához? Már hallottam róluk, de nem tudom mit takarnak.

   
damaniac82 - Guests | hsz       Online status #5269   2006.01.26 04:53 GMT+1 óra  
Frustum culling optimalizáció... Nem tom saját ötlet-e vagy csak újra feltaláltam a kereket, de mindenestre íme. Spherical Frustum Cullingnak (SFC) neveztem el, a lényege, hogy minden testet vagy ha pályáról van szó, akkor szektorokat (1 szektor = 1 szoba, 1 folyosó, etc, amit álalában egy pontból be tudsz látni. Tehát az L alakú szoba az két szektor...) burkológömbbe fogsz. A normál frustum culling algoritmusod elé beteszed az SFC-t, s ezzel jó részét gyorsabban dobálod ki a dolgoknak, mint az FC-nél. Miért? Vagyünk egy példát. Van egy kockád, amiről meg akarod tudni, látod-e. Namost normál FC-nél ez annyit jelent, hogy 8 vertexet hasonlítasz a frustumhoz. ==> három lehetőség:
1) benne van mind a 8 = a tárgy látható
2) valamennyi benne van = a tárgy részben látható
3) egy sincs benne, a tárgy nem látható

Namost, SFC ellenőrzéskor csak annyit kell nézned, hogy a gömb metszi-e valamelyik oldalát a frustumnak. Ha metszi, akkor a tárgy részben látható, stb...

De emellett a burkológömbök másra is jók. Ha pl van distance fog (pl. GTA3 - draw distance beállítás), akkor marha jól el lehet bűvészkedni azzal, hogy ha a

DG - RG > DD

feltétel teljesül, akkor nem látható a tárgy. Ahol: DG - burkológömb középpontjának távolsága, RG - a burkológömb rádiusza, DD - draw distance. Ha ez nem teljesül, akkor a tárgy (részben) látható...

De persze még 10000 elmélet van ilyesmikre

------------------------------------------------------------
[url=http://maniac.iceglow.com> OpenGL Tutorials & iNSANEX DevBlog[/url]

   
Gaborious - Guests | hsz       Online status #5268   2005.06.23 01:08 GMT+1 óra  
Naskacok ígérem hogy a mostani nyári szünet után írok ide pár hasznos cikket pluszba a nem látható tartalmak kiszűréséről.
Nagyrészt majd a 3d-s megoldásokat fogom boncolgatni.
Adiggis legyetek türelemmel és okosodjatok.

Bocsi ha túl kritikus/pesszimista/kötekedő vagyok, de TE sem úszod meg.

   
HomeGnome - Guests | hsz       Online status #5267   2005.06.08 03:35 GMT+1 óra  
Gaborious: nagyon jol leirod a dolgokat, es kivancsian varom milyen 3D-s technikakat mutatsz be a folytatasban! Viszont lenne egy apro keresem: leirnad legyszi mindezt meg1x egy kulon cikkben is? Mert szerintem az irasod boven van olyan jo, hogy siman megallja a helyet egy kulon cikkben is, mintsem hogy elkallodjon itt egy szimpla forumbejegyzesben...

HomeGnome

   
Gaborious - Guests | hsz       Online status #5266   2005.06.08 01:40 GMT+1 óra  
Folyt köv 3D-s szűrés témában.

Bocsi ha túl kritikus/pesszimista/kötekedő vagyok, de TE sem úszod meg.(Módosította Gaborious 2005.06.08. 09:41-kor)

   
Gaborious - Guests | hsz       Online status #5265   2005.06.08 01:40 GMT+1 óra  
Na szóval pár dolog a nem látható dolgok kiszűréséről 2D-ben.
Talán kezdem az elején. Miről is van szó. Teszem azt csinál vki egy játékot, és eljut odáig, hogy meg tudja jeleníteni a pályát a sok tereptárggyal meg mindennel csak hát lassú az egész. Gondolja biztosan mert még csak prealfa állapotban van a játék a jövőben majdcsak megjavul. Akinek nem lenne tiszta: a prealfa programállapot a program még nagyon kezdetleges állapota ahol a program optimalizálása valszeg még nem történt meg. Ha már megtörtént de nem sikerült túl jól az optimalizálás azaz a játék ugyanúgy szaggat vagy nem változott sok az előző még optimalizálatlan állapot előtti állapothoz képest AKKOR valszeg ahogy az angol szakirodalom mondani szokták a bottleneck nem ott van. A bootleneck jelentése annyit tesz hogy szűk keresztmetszet avagy ott vmi fékezi a rendszert.
Nos ha sikerült felismerni a játék szűk keresztmetszetét nagy valószínűséggel eljut a programozó odáig hogy lassú a CPU, lassú a VGA az egész lassú.
Nos eddig arról volt szó hogy a programozó az egész pályát mindenestül kirajzolta.
AZ EGÉSZ PÁLYÁT!!!! Mivel mi csak egy pici részét látjuk a pályának ezért felmerülhet az emberben hogy: ha én most a pályának csak egy kicsi látható részét jelenítem meg akkor vajon gyorsabb lesz-e a rendszer.
A válaszom egyértelmű IGEN.
Hogy miért? Nos: kevesebb lemez/memória művelet mert nem kell minden objektumot előhívni a tárolóból előkészíteni a megjelenítésre és elküldeni az adatait a VGA kártyának. Ebben a folyamatban a következők a bootleneck-ek:
CPU-MEMÓRA kapcsolat sebessége, MEÓRIA-VGA (AGP) kapcsolat, VGA feldolgozó-képesség (vertex processing és fill-rate limit).
Azzal hogy megszűrjük a megjeleníteni kívánt dolgokat az előbb felsorolt bottleneck-ek korrigálódnak. Nagyon fontos hogy a játék a rendszer erőforrásait kiegyensúlyozottan használjuk azaz egyiket se használjuk túlzottan, hanem ahol lehet a terhelést osszuk szét a rendszerben illetve úgy tervezzük meg a rendszert hogy ez az egyenletes eloszlás megvalósulhasson.
Mi most csak azt nézzük meg hogyan lehet a nem látható objektumok kiszűrésével megnövelni az egész rendszer áteresztőképességét (sebességét).

Kezdjük a legegyszerűbbel:
2D-s nézetben ha pl egy scrollozós játékról van szó akkor az egész pálya egy hosszú , hosszú szalagnak képzelhető el. Mi a képernyőn a szalagnak csak egy részét látjuk. Tegyük fel hogy (tfh) a tereptárgyak a pályán csak pozícióval vannak ellátva (avagy az a fa/bokor hogy van a pályán).
Amikor kirajzolunk egy részt a pályából akkor kirajzoljuk a hátteret és jönnének a tereptárgyak. Tfh a tereptárgyak egy nagy listában vannak. Ahhoz hogy kirajzolhassuk a pályán lévő tereptárgyakat végig kell menni az egész listán és az összes tereptárgyra meg kell vizsgálni hogy a képernyőn látható-e, és ha látható akkor kirajzoljuk. A probléma ott van hogy végig kell menni a listán méghozzá az egészen.
Nem lehetne valahogy csoportosítani a tereptárgyakat hogy ne keljen végignézni az egész pályát, hiszen ha a pálya közepén vagyunk akkor minek nézzük a pálya eleji és a pálya végi dolgokat, nem lehetne valahogy csak a közepét elérni. A programozónak felvillan a szeme: ezaz rendezem a tereptárgyakat koordináták alapján. Tfh a szalagpályán mindennek x,y koordinátája van és ha x koordináta alapján rendezem növekvő sorrendben az objektumokat a listában akkor a lista elején a pálya eleji tárgyak vannak hasonlóan a lista végén pedig a pálya végén található tárgyak. Na de ezzel mi volt a baj?
Ha pl. keresni akarja a pálya közepén lévő tárgyakat akkor az listának a felét legalább be kell járni hogy kiszűrhesse mi látható mi nem. Hasonlóképp a lista végével. A baj az hogy nem tudjuk hogy a listában hol helyezkedik el az az első elem ahonnan végignyálazva a listát bizton megállapítható hogy melyek láthatóak (ha eljutunk egy olyan tárgy pozíciójához ami nincs a képernyőn akkor ott a list további vizsgálatát be lehet fejezni mert mivel a tereptárgyak pozíció szerint rendezve vagyon, így az összes utána következő tereptárgy se lesz látható).
Programozónknak eszébe jut olyan, mi lenne ha gyorsabban keresném meg azt a bizonyos első elemet a listában ami már látható? Hogyan lehetne ezt gyorsan megcsinálni.
Mivel listáról van szó ami rendezve van, a keresés x koordináta szerint nem bonyolult.
Eddig a lineáris keresést használtuk de annak előnye hogy bár rendezetlen listában mindent megtalál bár túl lassú. Használjuk a bináris keresést a listán ehhez szükséges az hogy a lista rendezett legyen viszont így a keresési idő logˇ2(n) (ahol n az elemszám)
Tehát sokkal gyorsabb. Hogyan működik ez?
Tfh meg tudjuk határozni hogy a képernyő bal illetve jobb széle mely virtuális x értéknek felel meg (avagy megmondjuk hogy a képernyő a pályán mely x tartományt látja)
Vesszük az egész listát , (***)megnézzük a középső elemét. Ha az adott elem a képernyőn van (vagyis látható) akkor elkezdünk visszafelé menni amíg nem jutunk olyan elemhez ami már nem látható aztán a korábban talált elemtől (amitől előbb visszafelé kezdtünk menni) most elindulunk a lista vége felé és ott is addig megyünk míg egy nem látható elemet találunk.
Ha korábban vett középső elem nem látható akkor meg kell állapítani hogy koordinátája alapján a látható x tartomány előtte vagy utána van. Ha előtte akkor vesszük az középső elemtől lista eleje felé eső részét és elvégezzük megint rajta a *** -os résztől illetve ha a utána van a látható x tartomány akkor pedig vesszük a középső elemtől a lista vége felé eső listadarabot és azon elvégezzük a ***-os részt. Ez addig megy míg találtunk egy olyan elemet ami látszik. Ilyenkor még meg kell nézni hogy vannak e előtte/utána még látható elemek. Ennek az egésznek az előnye hogy a képernyőn látható tárgyak a listában egymás után vannak szünet nélkül.
DE ez csak egy pirmitív 2d-s scrollozós játék volt. Mi van ha a szalagpályát nem egész magasságában látjuk De mi van ha vmi Mariós játék kell ahol a szalagpályán csak egy téglalapnyi területet látunk vagyis nem látjuk egyszerre a pálya tetejét és alját.
Nos ebben az esetben is alkalmazható a fentebb leírt módszer csak amikor végigmegyünk a lista azon darabján amit korábban egy az egyben meg lehetett jeleníteni (mert a lista minden eleméről tudjuk hogy látszanak) most nem léphetjük meg. Ezen pici kis lista minden eleménél most már ellenőrizni kell, hogy melyek látszanak melyek nem.
Ha nem túl magas a pálya vagy nincs túl sok tereptárgy akkor az előző módszer még mindig megfelel bár egy ezt tovább lehet „optimalizálni”. Nos most már mérlegelni kell (és nem csak most, de már akkor amikor a saját algoritmusodat kitalálod) hogy mi a gyorsabb! Előfordulhat hogy már annyira túlfinomítod a szűrőalgoritmusodat hogy gyorsabb ha bruteforce nyersen kirajzolod az összes tereptárgyat mintsem az algoritmusoddal válogasd ki mi látszik mi nem. Tehát mindig figyelembe kell venni hogy a szűrő-algoritmusnak gyorsítania kell a játékot és nem lassítani. Meg lehet azt is lépni mint most az esetünkben, hogy kiszűrünk annyit dolgot amennyit lehet minél gyorsabban aztán bruteforce. Vagyis jelen esetben x koordináta alapján kiválogattuk melyek lehetnek láthatóak de már nem foglalkoztunk a y koordináta szerinti láthatósággal, hanem úgy ahogy van kirajzoltuk az egészet.
Persze előfordulhat hogy tovább lehet hatékonyan gyorsítani az egészet ha y koordináta lapján is szűrjük a látható tárgyak listáját.
Ebben az esetben jobb 5let híján nagyban bonyolódik a helyzet.
Tehát mindig mérlegelni kell mi a leggyorsabb. Sokszor az egyszerű algoritmusok a gyorsabbak de néha a bonyolult megoldások vezetnek sebességnövekedéshez (lásd lineáris vs bináris keresés).


Bocsi ha túl kritikus/pesszimista/kötekedő vagyok, de TE sem úszod meg.

   
ShAdeVampirE - Guests | hsz       Online status #5264   2005.06.03 10:19 GMT+1 óra  
Erröl már volt egy rövidebb szösszenet ebben a témában: 3D térkép játékhoz
Sztem nézd át, és ha még van kérdésed, akkor tedd fel

____________________
/ ShAdeVampirE /
([url="http://shadevampire.uw.hu">ShAdeVampirE otthona a neten...[/url])

   
beast - Guests | hsz       Online status #5263   2005.06.02 14:08 GMT+1 óra  
van Octree, quadtree, bsp meg ilyenek...
ezeket magyarazza valaki el...

beast

   
nagyy - Guests | hsz       Online status #5262   2005.06.02 11:38 GMT+1 óra  
Én innen lestem el hogyan lehet ezt megoldani:

http://www.codesampler.com/oglsrc/oglsrc_12.htm#ogl_frustum_cu lling

Igaz hogy őszinte legyek van egy két része, amit nem nagyon értek, hogy miért úgy van, de működik, úgyhogy gond egy szálse.

nagyy

   
Gaborious - Guests | hsz       Online status #5261   2005.05.31 05:56 GMT+1 óra  
Na senkit sem érdekel a tépma, vagy mindenki olyan penge?
Tessék kérdezni vagy megosztani a gondolatokat, 5leteket (kérdezzetek akár hülyeséget, megbeszéljük)

"A programozó olyan mint a bináris politikus. Utasít, rendelkezik mások erőforrásaival és számonkéri az eredményeket"

   
Gaborious - Guests | hsz       Online status #5260   2005.05.27 04:23 GMT+1 óra  
Natehát csak mondjátok, ki mit használ.
Itt meg tudjuk beszélni, kinek mi kell és azt hogyan érheti el. Persze lehetetlent senki ne kérdezzen.


"A programozó olyan mint a bináris politikus. Utasít, rendelkezik mások erőforrásaival és számonkéri az eredményeket"

   
Gaborious - Guests | hsz       Online status #5259   2005.05.27 04:22 GMT+1 óra  
Idézet
warlock írta:
Az eljárást ha jól emléxem frutumcullnak hívják nekem eddig csak 2dre sikerült megcsinálnom (persze 3d-s térben).
Így annyival könnyebb dolgom volt hogy a mélységgel nem kellett számolnom.
Az én logikámnak az volt a lényege hogy megnéezm a kamera heylét meghogy hova néz és utána egy sor trigonometriai összefüggéssel meg 1 csöp geometriával kiszámítom benne lehet e a képben.
Részleteket nem írok mert holnap matekéretségi nem akarom az agyam fárasztani.
Ha érdekel vkit akkor majd utána leírhatom....


a frustum culling lényege a következő.
Képzeljünk el egy olyan testet ami a camera látómezejét szimbolizálja. Ez általában egy 6oldalú csonka gúla,

Akkor látható egy objektum ha az objektum benne van teljesen vagy részlegesen ebben a csonkagúlában.

anyag a témához
http://www.cg.tuwien.ac.at/studentwork/CESCG/CESCG-2002/DSykoraJJelin ek/

http://www.flipcode.com/articles/article_frustumculling.shtml

http://www.racer.nl/reference/vfc.htm

http://www.kraftwrk.com/fru stum_culling.htm

http://www.ce.chalmers.se/~uffe/vfc.pdf

http://ra sterized.tripod.com/Articles/FrustumCulling.html

http://www.cs.unc.edu/~s alomon/Research/FSOC/

"A programozó olyan mint a bináris politikus. Utasít, rendelkezik mások erőforrásaival és számonkéri az eredményeket"

   
Gaborious - Guests | hsz       Online status #5258   2005.05.27 04:13 GMT+1 óra  
Idézet
vologya írta:
Ez a D3D ben a culling.(Valami Frustum culling, de nem tuti). A DX ben 3 lehetőségünk van.Ha a szűrést az úramutató irányával megeggyező irányban akkor CW culling, ha ellenkező irányban, akkor CCW culling és persze a NONE(vagyis semmi). Ez még ma is gyakran használt technológia főleg az OpenGL ben, de a mostani kártyák a hardwares TTL segítségével ezt a problémát a LOD (level of detail) lal oldják meg. Itt a távolság függvényében csökkenti a kártya automatikusan az objektumok minőségét, mígnem teljesen eltűnnek! Igy néha egy nagyobb területnés sok objektummal megspórolhatjuk a vertexek 60-85% át!

1001011011101001000100011
Te backface cullingról beszélsz.
A backface cullingnak az a lényege hogy azon 3szögek melyek normálvectora a camera vectorával egy irányba néz vagy kis szöget de max 90 fokos szöget zár be az a kamera felöl nem látható vagyis elhagyható.
A CW és CCW opciók arra valók hogy a 3szög esetén hogy vegye a normálvectort ugyanis nem kötelező megadni, mert a csúcsok sorrenjéből is meghatározható a normálvector és ezen számítást befolyásolja hogy a csúcsokat CW óramutatónak megfelelően vagy CCW azzal ellentétes irányban veszem a csúcsokat a normálvector számításnál.

"A programozó olyan mint a bináris politikus. Utasít, rendelkezik mások erőforrásaival és számonkéri az eredményeket"

   
vologya - Guests | hsz       Online status #5257   2005.05.27 04:08 GMT+1 óra  
Ez a D3D ben a culling.(Valami Frustum culling, de nem tuti). A DX ben 3 lehetőségünk van.Ha a szűrést az úramutató irányával megeggyező irányban akkor CW culling, ha ellenkező irányban, akkor CCW culling és persze a NONE(vagyis semmi). Ez még ma is gyakran használt technológia főleg az OpenGL ben, de a mostani kártyák a hardwares TTL segítségével ezt a problémát a LOD (level of detail) lal oldják meg. Itt a távolság függvényében csökkenti a kártya automatikusan az objektumok minőségét, mígnem teljesen eltűnnek! Igy néha egy nagyobb területnés sok objektummal megspórolhatjuk a vertexek 60-85% át!

1001011011101001000100011

   
warlock - Guests | hsz       Online status #5256   2005.05.27 03:34 GMT+1 óra  
Az eljárást ha jól emléxem frutumcullnak hívják nekem eddig csak 2dre sikerült megcsinálnom (persze 3d-s térben).
Így annyival könnyebb dolgom volt hogy a mélységgel nem kellett számolnom.
Az én logikámnak az volt a lényege hogy megnéezm a kamera heylét meghogy hova néz és utána egy sor trigonometriai összefüggéssel meg 1 csöp geometriával kiszámítom benne lehet e a képben.
Részleteket nem írok mert holnap matekéretségi nem akarom az agyam fárasztani.
Ha érdekel vkit akkor majd utána leírhatom....


   
Gaborious - Guests | hsz       Online status #5255   2005.05.27 03:14 GMT+1 óra  
Hali.
Itt egy topic ahol lehetne összegezni,
-ki milyen módszert használ arra, hogy a 3D-s térben a nem látható tárgyakat/pályarészeket stb kiszűrhesse.

Akinek nem lenne világos a téma fontossága akkor csak annyit mondok, hogy pl a járékon belüli renderelés (kép számítás) sebessége nagyban függ, hogy mennyi adatot zúditunk a nyakába. Ha sok adatot adunk neki, akkor a videokártya kiszűri hogy mi látható (magyarán mindent kirajzol csak egyes dolgok a képernyőn kívül esnek tehát nem láthatóak) de ha sikerül drasztikusan lecsökkenteni az adat mennyiséget (vagyis sikerül a nem látható/felesleges részeket elhagyni) akkor a videokártya is gyorsabban kész lesz a kép kiszámításával (nem is beszélve arról hogy a sok geometriai adat pl agp buszon keresztül is igen lassan csurog).

Natehátkéremszépen tessék nyilatkozni.

"A programozó olyan mint a bináris politikus. Utasít, rendelkezik mások erőforrásaival és számonkéri az eredményeket"

   
> 1 <