Tak a John Carmack má zase co dělat :-)

je krom cadu a podobne naprosto nulova

pro q: Chybovat se je lidské,spousta grafických editorů a střižen videa, těmi profesionálními počínaje, používají pro efekty právě a někdy i jen rozhraní OpenGl. Takže je jen dobře, že se rozvíjí i nadále.

tim lip jen houst
uz aby byla pryc diktatura dx10 only vista
kdyby se to povedlo a OGL bylo multiplatformni a multisystemovy a slo na tom hrat pac by se na to delaly hry bylo by to moc fajn

Název Open Graphics Library (OpenGL) není žádný "svobodný software", ale rozhraní oteřené k dalšímu vývoji. A definují ho ty "nejkomerčnější" firmy na světě - tak proč zrovna CDR prudí se svým nablblým newspeakovým slovníkem, vhodným spíš pro Waicovo (L)živě.cz?
Open=otevřený, Free=svobodný.

Když né DX10 ve XP, tak aspoň nový OpenGL i pro XP.

nevím co řešíte, podle známého experta Víta Vzteklého je D10 i pro XP :) - http://www.vit-stekly.cz/clanek/22-directx-10-na-stazeni-/

to Radek123: to by mě zajímalo, jaký je rozdíl mezi svobodným a otevřeným *standardem*? když tam není žádná implementace, která by byla pod jistou licencí, v čem vidíš rozdíl? prostě jsou zveřejněné a volně dostupné specifikace, co víc můžeš chtít? podávat návrhy může jistým způsobem určitě každý. ale o to vůbec nejde. aby byl software svobodný (free), stačí když je dostupný pod vhodnou licencí, vůbec si do toho vývojáři nemusí nechat od komunity kecat. takže tvoje argumentace je velice pochybná. i kdyby šlo o něco důležitýho, jakože nejde.

nemate to jedno? DX ma len minimalne zastupenie na trhu. A to konkretne je iba na win a xbox. Zda sa to vela? v skutocnosti realne vobec nie. pretoze nDS, PSP, PS2, PS3, Wii, Linux, MacOSX maju spolu daleko, daleko viac uzivatelov nez MS. Nastastie. Btw precitajte si preco sa DX vyvijal od autora. Zistite, ze to bolo preto, ze win bol tak neschopny OS, ze sa na nom nedala ziadna hra vyvinut. a ze to bolo viac menej vypnutie vsetkych OS featur (od inputu keys a mysi az po swapovanie systemu). No dnes je to trochu ine a konkuruje to oGL na MS platformach.

Tým Dx10 pre WinXp som si nie istý. Odkaz smeruje na Dx10 SDK. Priamo na Microsofte sa v popise SDK síce uvádzajú aj systémy XP, ale zas inde (http://msdn2.microsoft.com/en-us/library/bb219721.aspx#Will_DirectX_10_b...) Microsoft na otázku Will DirectX 10 be available for Windows XP? uvádza jasné No. Tak si vyberte.

outtony:
zbožné přání - DX běží na cca 30% konzolí (xbox) a na cca 99% pc (windows), hodně velká firma si může dovolit vyvýjet pro obojí, ale většině se OGL nevyplatí...
momentálně zvažuji jestli použiji opengl nabo directx ... a i když jsem byl původně pro opengl, tak čím dál víc o něj ztrácím zájem... jeho API je hodně zastaralé (kde to viděli ve 21 století neobjektové api... ?) a v mnoha ohledech neefektivní - což se dá obejít jen za cenu spousty programování, které už je v DX dávno hotové.
ještě poznámka k výkonu a featurám (obvyklé flame téma): je to u obou knihoven úplně stejné (ještě aby ne, když obojí využívá stejný hardware)...

Azazel: Co ma OpenGL spolecneho s tim, jestli pouzivas objektovou nadstavbu nebo ne? Ta graficka karta stejne o objektech vubec nic nevi.

OpenGL je API te nejnizsi urovne, nad nim samozrejme existuji objektove i neobjektove knihovny (GLU, GLUT, OpenInventor, SDL, ..).

MarSik: pokud chceš OpenGL používat, tak si k němu musíš objektovou nadstavbu napsat - a to je pořádná fuška (o těch knihovnách co si uvedl bych rozhodně neřekl, že mají dobré API (některé nejsou ani objektové)) Oproti tom DX mám velice solidí objektové rozhraní...
Nízkoúrovňové knihovny jsou zkrátka přežitek... protože není žádný důvod volat jednotlivé funkce grafické karty, stejně jako nevoláme jednotlivé instrukce procesoru

To: Azazel

Vzdy se velice dobre bavim, kdyz zacne nekdo kazat o tom, jak je "nezbytne nutne" objektove rozhrani a ze bez nej se pry dnes uz "neda programovat". Ja osobne mam zkusennost s "objektovymi" programatory pomerne spatnou. To jsou presne ti lide, kteri pri sebemensim problemu zacnou tvrdit, ze "to nejde" a ze potrebuji "pohodlnejsi prostredi" k praci. Zpravidla si hraji s objekty, aniz by meli aspon tuseni, co se deje pod tim. Pro reseni slozitych technickych problemu z 90% nepouzitelni, na generovani tun balastu experti :-)

Azazel: Tak prikazy OpenGL rozhodne nejsou instrukce karty a nastavit vlastnosti jednou a pak vykreslit zaraz treba milion bodu v particle systemu (protoze OpenGL je stavovy stroj a neni tu barvu potreba nastavovat pokazde) muze byt o dost efektivnejsi udelat primo pomoci OpenGL nez pres jakoukoliv nadstavbu.

A ja o tech API nerekl, ze jsou vsechny objektove. Ale treba OpenInventor i SDL je. Neni proste vsechno zlato co se trpyti a plati to i o objektech, ne vsude jsou uplne vhodne, mohou usetrit praci, ale maji pri spatnem pouziti i schopnost snizit vykon.

2 mm2klokan:

Obavam se ze bez OO pristupu dnes tezko napises dobre navrzenou aplikaci. Je jasne, ze ve specifickych pripadech jako jsou vestavene systemy bude lepsi pouzit neco efektivniho (typicky ASM nebo C), ale jinak je lepsi venovat pozornost navrhu, aby vysledny kod k necemu vypadal.

Prave to je treba jeden z duvodu proc je DX tak uspesne u hernich vyvojaru - programatory to nuti navrhovat kod peclive. Zato v OGL nemas nikde nejakou jistotu ze nekdo v tymu nekde v nejakem miste nezavola primo funkce z OGL (uz sem takove pripady videl :( ). Ono kdyz pracujes sam tak je to v pohode, ale jakmile je tym vetsi tak je ten dobre navrzeny opravdu potreba.

To: Tom007

Navrhnout dobrou aplikaci lze vpodstate v cemkoliv a vzdy to zalezi predevsim na lidech. Diky nejruznejsim objektovym nastrojum programovani jaksi "zlidovelo", takze se za programatora dnes vydava kdejaky mamlas. V takovem pripade mate pravdu - s timto materialem je lepsi pracovat pomoci objektovych nastroju, ktere jim umetaji do jiste miry jedinou spravnou cesticku.
Nic proti objektum. Sve opodstatneni maji prave z vyseuvedeneho duvodu jisteho "zlidoveni" programovani, kdy technicka kvalifikace mnoha programatoru je dnes velice nizka. Ale vydavat jej za zachranu IT sveta je prinejmensim posetile.

2 MarSik

Zrejme budes bud velky fanda OGL, ktery D3D nikdy nevidel a nebo jsi mozna jen nekde cetl, ze OpenGL je stavovy stroj a D3D ne. Takze ti to vysvetlim velmi jednoduse:

OGL je naprosto stejny stavovy stroj jako D3D. ... Uz je to jasne? :)

Protoze i v D3D plati, ze kdyz nastavis treba difusni barvu tak je proste od te doby nastavena a to se nemeni. Navic D3D ma primo metodu SetRenderState, ktera toto vse zarizuje (narozdil od OGL, kde je tech metod vic a hure se to programuje).

Takze co se tyka tveho prikladu ohledne casticoveho systemu, tak ten muzes na D3D vytvorit naprosto shodne.

Navic jeste jedna poznamka ... v nekterych lidech evokuje vyraz OOP zvysenou narocnost - to samozrejme u D3D neplati, protoze ono neni objektove tim zpusobem, ze by se nekde vytvareli nejake objekty. Jde pouze o to, ze D3D poskytuje COM rozhrani na API funkce v DLL knihovnach D3D-runtime a ovladacu. Tim je zajisteno propojeni mezi programem a API. U OGL je stejne napojeni, akorat jsou to obycejne funkce a stav OGL je udrzovan v promennych OGL contextu.

2 mm2klokan

No mozna to bude tim, ze pod OOP predevsim vidis ruzne klikaci vyvojova prostredi typu C++ Builder nebo "programovani" v C# nebo Visual Basicu pod Visual Studiem. Abych se priznal, tak taky nemam rad tyhle lidi, co k tomu sednou, jen klikaji a obcas dopisou kod do vygenerovaneho tela metody (a pak si nakonec jeste mysli, ze uz umi programovat :) ).

Ja mam pod OOP spis na mysli system, kdy prijdes k prazdnemu projektu a vse navrhujes sam, tj. IDE by ti melo slouzit pouze jako pomocny nastroj na hledani objektu a metod, parametru apod.

Opravdu si dnes nedovedu predstavit navrh slozitejsi aplikace v neobjektovem jazyku, obcas treba neco musim delat v C a v takovych pripadech stejne pisu kod poloobjektove s tim, ze prvni parametr davam vzdy jako explicitni this.

Neco jineho jsou samozrejme male aplikace jako treba nejake utility prikazoveho radku, ale u tech vetsich je proste to OOP a dobry navrh potreba.

Azazel: No to mi tedy pověz, co ti přinese objektové API u OpenGL. Je to jen odlišný způsob volání, nic víc to v této oblasti není. U OpenGL tě alespoň nečeká přepisování kódu s další verzí - u Direct3D s novou přejmenují rozhraní, některé funkce atd. a je o zábavu postaráno.

OpenGL se nevyplatí? Nesmysl. Spíš je otázka, proč vůbec Direct3D používat, když s OpenGL to jede i na těch Windows...

Tom007: Jak, poloobjektove ? Prvni prekladace C++ prekladali do C. Neni problem psat v cistem C objektove, jenom te pri tom programovaci prostredi nevede za rucicku. Mimochodem, mezi priklady ciste objektove knihovny psane v cistem C (tedy neobjektovem jazyku) patri Gtk, to je ta knihovna nad kterou bezi firefox.

Nejde o to jestli je jazyk objektovy nebo ne. Dulezite je, aby si programator umel vybrat spravny nastroj (zhusta ty objekty) na to, co zrovna dela.

A "D3D ... neni objektove tim zpusobem, ze by se nekde vytvareli nejake objekty" je nazorna ukazka, ze ta objektovost D3D je naprosto k nicemu, jenom syntakticky cukr pro programatory, kteri si mysli ze objektovost je vlastnost jazyka a ne navrhu aplikace.

To: Tom007

Nemam na mysli jen klikatka pro diletanty, i kdyz je pravda, ze ta mne lezou na nervy nejvic. Velke projekty vznikaly i v dobe, kdy objektove programovani rozhodne nebylo bezne a vzdy byla kvalita zavisla predevsim na lidech, kteri se na tom podileli, nikoliv na programovacim jazyce ci konkretnich knihovnach.
Podstatnou vyhodou objektoveho programovani je prave to, ze s jeho pomoci lze lepe vyuzit i programatory s nizsi kvalifikaci, kteri by v projektu jinak delali bordel (a tady nejde jen o klikatka, ktera jim k tomu dame - tady jde predevsim o omezeni, co clovek muze delat a co ne). Technicke vyhody tam ale prilis nevidim.

2 hkmaly

Obavam se ze si trochu pletes pojmy s dojmy :) Existuje totiz rozdil mezi "objektove orientovanym pristupem" a "objektove orientovanym programovanim". Objektove orientovany pristup je to co sem napr. popisoval - tj. explicitni predavani this, nebo napr. tvuj priklad Gtk. Tohle ale nelze povazovat za plnohodnotne OO programovani. Zakladem OOP je totiz dedicnost, zapouzdreni a hlavne polymorfismum. Ani jedno vsak v C ani jinych neobjektovych jazycich nemams - proto sem to oznacil za poloobjektove.

A co se tyka D3D tak uz sem to jednou psal nize .... Je to kvuli kvalitni navrhu a nicemu jinemu, v OGL muze vznikat naprosty chaos a tezko se to hlida, obzvlaste pokud ma tym treba 20 a vice lidi. V Direct3D proste nemas sanci volat nikde zadne metody dokud nedostanes ukazatel na rozhrani, takze mas celkem dobry prehled o tom, kde se graficke API vyuziva a kde ne.

LD: Omlouvám se, ale do diskuse už zasahovat nebudu. Pokud tu 3/4 lidí nemá ani elementární základy programování (o znalosti OGL nebo DX nemluvě), tak to zkrátka nemá cenu...

2Azazel: Pokud mluvime o praci s grafikou, tak je kupodivu i dnes stale treba predevsim vykon a cim vyssi programovaci metody pouzivas, tim vic o nej prichazis. Je sice fajn ze to za tebe osetri vsechno mozny, ale osetri to i nemozny => vyslednej kod bude neskutecne pomalej. Vzdycky je vsehno neco za neco, jsem presvedcen o tom, ze soucasne nenarocnejsi gamesky, ktere ma problem rozdejchat i nevykonejsi HW by nebylo problem pri trose optimalizace bez potizi rozchodit na HW o 2 - 3 generace starsim.

Dokonce mam zvlastni pocit, ze gamesa ktera takovy HW vyzaduje vypada velmi casto subjektivne jeste hur, nez gamesa o 2-3generace zpet a pokud si takove dve hry porovnam tak aby byly hratelne (stara s max detailama, nova osekana co to de) na starsim hw, bude ta nova hra vypadat naprosto desive. Proc asi ? Protoze na optimalizaci vsici serou.

jjjjj : ok, přesvědčil jsi mě, ještě jednou přispěji
co má společného objektový/neobjektový přístup s rychlostí? Odpovím si sám: nic ! Nevím kdo šíří fámy o tom, že čím "nízkoúrovněji" se bude programovat tím to bude rychlejší, ale pravděpodobně to nebudou lidé, kteří někdy programovali a jestli ano, tak určitě ne dobře...
Naopak, pokud zadám dvěma stejně dobrým programátorům aby něco (cokoli) naprogramovali a jeden dostane assembler a druhý třeba to c++, tak program v assembleru bude za delší dobu, bude obsahovat víc chyb a hlavně bude pomalejší ! a rozdíl se bude dramaticky zvyšovat s tím jak rozsáhlý program to bude.
 
PS: ty si vůbec neuvědomuješ co všechno dneska počítačová hra dělá oproti hře řekněme 10 let zpátky, kdyby sis to uvědomoval, tak něco takového vůbec nemůžeš napsat - bez optimalizací by se současné hry vůbec nehýbaly...

No pod OGL sa mi prave paci to, ze si to mozem cele riadit ako potrebujem, ked to nepotrebujem, pouzijem nejaku kniznicu, ktora okrem ineho vacsinou obsahuje aj podporu DX. Tak neviem co riesite, a okrem toho napr. half-life1 (resp. CS mod) mal moznost zvolit DX al OGL a viete co? Pod OGL to slo uplne krasne, pod DX mi to laguje za pohybom mysi je to asi pol sekundy a to som mal nvidiu. Na ucenie je rozhodne vhodnejsie OGL, jednoduchy program ktory nieco zobrazi sa da napisat na par riadkov, DX to je niekolkokrat tolko. Navyse existuje nieco co sa vola OpenGL-ES a to je v uz pomerne dooost vela mobiloch. Takze OpenGL nie je mrtve API.
K tym novym vs. starym hram - zoberme napr. take HL2 (ja viem ze nie je OGL). Tam ked som videl screenshoty, tak som vedel, ze si to musim zahrat uz len koli grafike. Ked vidim screenshoty tolko ospevovaneho oblivionu (vsetci vieme kym...), tak nechapem co na tom kto vidi.

azazel> nizkourovnovy program napr. v C bude vzdy rychlejsi ako v nejakom pythone, jedine java JIT compiler v poslednych verziach sa splha na vykon C. C ma optimalizacie rovnako ako C++ + nema nieco, comu sa hovori dan z abstrakcie. Ked to chces optimalizovat, musis do toho zacat tahat sablony a to sa mi nezda, ze by veci zjednodusilo alebo sprehladnilo (aspon pre vyvojara tych sablon).
Aj ked ja som D3D videl len z rychlika, neni tam nieco ako easy mod (neviem ako to volaju) a advanced? Lebo ten advanced je podla mna kvazi to iste co opengl a ten easy je o tom spomaleni, ale zas je easy :-). (aby bolo jasne o com sa vy dvaja hadate)

2Azazel: Nevsim sem si ze by se objevil nejaky genialni algoritmus a nejak revolucne zmenil fungovahi her. A bavime se o grafice, coz kdyz zustanema u 3D je stale totez. Jasne, muzu si diky vykonu dovolit vic polygonu, detailnejsi textury, ... ale pokud dam vedle sebe dve veci tak by ta novesi bud mela teda vzdy vypadat lip nebo je neco spatne a ty vsemozny vypocty ktery dela GPU jsou k hovnu.

A tvrdit, ze nizkourovnovym programovanim neziskas vykon ... asi si nikdy nic narocnyho nedelal, i dnes se specificky veci, kde zalezi na kazdym cyklu pisou v asm, protoze zadnej prekladac nevytvori optimalni kod. A chyb tam bude +- stejne.

Pamatuju doby, kdy se resil kazdej byte a kazda instrukce. Kdyz sem si kdysi se spoluzaky hral, tak rozdil vykonu grafickych hratek (rotace 3D objektu) napsana a kompilovana z paskalu byla 10x pomalejsi nez totez v C a 50x pomalejsi nez totez napsano primo v ASM.

Otevri oci, je to videt vsude kolem ze kdyby se sw optimalizoval opravdu alespon castecne, bude na soucasnym HW vsecho doslova litat.

1, pokud mluvíme o grafice, tak tam se skoro nic optimalizovat ndaá, prostě podstrčíš data grafický kartě a ta je zobrazí - a je to jen a jen na ní jak rychle
2, dneska už opravdu !nikdo! v asembleru nepíše a jestli jo, tak je to pako...
a to "+- stejně chyb" beru jako vtip

ještě, aby mě někdo špatně nepochopil - pokud to má být rychlé, tak se určité optimalizace dělat musejí, ale nejsou to optimalizace ve stylu "napíšem to v asembleru" ale spíše ve stylu "nebudeme strkat tý kartě každej trojúhelník zvlášť, ale všechny najednou", apod.
a takové optimalizace se pochopitelně dělají - a je jich celá řada, jinak by se to vůbec nehýbalo...

Ahoj,
jsem autor blogu www.vit-stekly.cz, kde píši že directx 10 je možné i na WinXP. Jelikož spousty lidí tvrdí že to nejde, nechť mi řeknou co je tedy toto:
http://www.microsoft.com/downloads/details.aspx?FamilyId=2DA43D38-DB71-4...

Když se kouknete na datum vydání je již po vidání win vista s directx 10! HM? že by microsoft updatoval staré 9.0c? no to se mi moc nezdá, rozhodněte sami!

azazel> tak to si robis srandu nie? si myslis, ze tam cpu data co to da? preco si myslis, ze nvidiacke ovladace dokazu tak zmenit vykon od verzie k verzii? poviem ti novinku. ovladace si zistuju aka aplikacia(hra) bezi a podla toho sa prisposobia

Azazel: V asm se pise, ale jen male kousky kodu napriklad na vyuziti SSE nebo MMX. Ale jinak s tebou souhlasim, ze optimalizace ma smysl delat upln jinym zpusobem nez pre[pisem do assembleru. (Ono napsat optimalni kod v assembleru neni zadna sranda, pri dnesnich super a hyperskalarnich architekturch totiz zalezi i na poradi instrukci).

2 Vít Steklý

Nechci ti do toho mluvit, ten tvuj blog sem teda nevidel, ale s takovou urovni znalosti jakou tu predvadis bys asi mel misto psani vlastniho webu spis cist nejake vzdelavaci weby ohledne temat o kterych pak chces psat.

Ten tvuj odkaz vede na aktualizaci runtime DirectX coz je naprosto bezne, protoze ke kazdemu aktualizovanemu SDK vychazi soubezne i runtime. Nebo sis nikdy nevsiml, ze hra chce aktualizovat DirectX prestoze uz v systemu je?

Jinak tady mas vypis stazitelnych SDK a ke kazdemu existuje runtime verze (ktera je vzdy jeho soucasti) http://www.microsoft.com/downloads/results.aspx?DisplayLang=en&nr=20....

Takze pro tvoje vlastni dobro doporucuju tvuj udajny clanek o teto problematice stahnout a pripadne udelat nejakou napravu, ktera by zabranila desinformaci lidi.

4 Tom007
no hry moc nehraju ale když už tak to co řikáš je jasný ale runtime má své číselné označení třeba c a podobně a pokud vim DirectX 9.0d zatím není... nebo teda už je?

2 Vít Steklý

Zrejme si to nepochopil, runtime je porad 9.0c, to oznacuje DX9 s SM3.0. Nicmene vtip je v tom, ze ani DXSDK neni bezchybne a obcas se proste najde nejaky zadrhel kvuli kteremu se aktualizuje cele SDK a s nim i runtime knihovny. Vetsinou se to taky aktualizuje kvulo novym funkcim, pomocnym utilitam a podobne. Jinak co se tech chyb tyka tak vetsinou nejde o kriticke chyby primo v D3D ale spis v D3DX coz je pomocna knihovna, ktera obsahuje spoustu peknych funkci, vetsina top vyvojaru ji ignoruje, protoze maji ty funkce implemenotvane ve vlastnich knihovnach, ale najde se spousta lidi, kteri tuto knihovnu vyuziji a prave proto MS ty updaty vydava.

Jinak v kazdem SDK je napsano, co bylo pridano a upraveno. Staci se podivat do prislusne SDK dokumentace. U runtime DX toto napsano neni (protoze to zajima pouze vyvojare) a tak pokud chces vedet detaily pak neni nic jednodussiho nez vyhledat SDK prislusne k danemu runtime DX.

Pry OGL je mrtvy, lolec. V OpenGL je napechovano vic penez, nez v celym MS DirectX i se vsema tema hrama. Na OpenGL se spoleha 99 % vsech konstrukcnich programu, 3D animacnich programu a jinych enterprise veci. OpenGL je standard, ktery tu bude stale, DirectX je vymysl jedne firmy, ktera taky muze zkrachovat...

To: Azazel

Dnes nikdo nepise v Assembleru ? A jestli ano tak je pako ?
Chlapecku, musis taky vystrcit nos ze sveho vysokourovnoveho aplikacniho dvorecku, kde podstrkavas prikazy grafickym kartam. Ze ty se s tim nesetkavas, jeste neznamena, ze se to nedela.
Assembler se pouziva napr. pri tvorbe operacnich systemu (minimalne ve fazi portace na konkretni CPU je temer vzdy nutne v nem sem tam neco udelat), pomerne casto se k nemu saha i pri programovani ovladacu atd.... Dale se velmi hojne pouziva pri programovani mikrokontroleru, kterych mas kolem sebe spoustu a jenom to nevidis :-). Mozna by ses divil, kde vsude mas doma mikrokontroler, naprogramovany v Assembleru, v horsim pripade v cistem C v kombinaci s Assemblerem :-))

Ano...vysokourovnove jazyky daly spouste lidi iluzi, ze rozumeji pocitacum :-)

2  Vít Steklý: mě se zdá, že mate vidiny z WOW. Firmy mají problémy při psaní kvalitních ovladačů pro novou grafickou architekturu ve Vistě. A do toho MS bude firmy nutit, aby přepisovali ovladače pro WinXP. Napsat dobrý ovladač trvá cca 8-10 měsíců a tudíž stojí spoustu peněz. Rozdíl mezi MS 3 a MS 4 je asi tak stejný jako mezi oslem a koněm. Podle mě ten Váš link bude pouze příprava na SP3 pro Win XP.

mm2klokan: já myslel, že se tu bavíme o normálním programování ? Jistě pokud potřebuješ naprogramovat pračku, nebo nějakej jednoúčelovej čip a náhodou pro to neexistuje minimálně Céčkovej překladač, tak to v asembleru napsat musíš - ale neděláš to kvůli optimalizacím, ale proto, že to jinak nejde !
 

azazel: ale programovanie v asm v pripade SSE robis koli optimalizaciam, aj ked to ide bez toho

v případě SSE, zapnu u překladače aby to přeložil se SSE... rozhodně žádný asembler nepíši
pokud jste schopen optimalizovat lépe než překladač, tak klobou dolu (ale nevěřím tomu)

Hej, ide to kompilatorom, ale nezabudni si pozret ci sa tam aj nejaka sse instrukcia objavila. Zapnutie SSE totiz vo vacsine pripadov znamena nieco ine ako si clovek predstavuje. Keby bolo take jednoduche vektorizovat a sparalelnit softver kompilatorom, myslis ze by intel k tomu vyzyval vyvojarov? (aj napriek tomu, ze ich kompilator je v tom dost dobry) Moderne CPU maju stovky instrukcii a niektore su navrhnute len koli jednej aplikacii (napr. kompresia obrazu) a povedz mi ako by asi mohol kompilator rozoznat semantiku a pouzit tu instrukciu? SIMD sa da automaticky pouzit len v jednoduchych pripadoch.
Este uvediem jeden priklad - prehravac mplayer. Pustal som s nim full HD video a aj ked pisal ze moj system je pomaly, nebadal som ziadne sekanie v obraze. S wmp to malo tak 10fps. Mplayer ma samozreme casti pisane v asm.

To: Azazel

Neznam "normalni" a "nenormalni" programovani. Znam pouze programovani, ktere se da pripadne rozdelit treba na aplikacni a systemove.
Zrovna v pripade mikrokontroleru je treba casto sahnout k assembleru proto, ze ve vyssim programovacim jazyce je vysledny kod zoufale neefektivni, pripadne se do zarizeni vubec nevejde. Pricinou neni, ze by neexistoval prekladac. I mikrokontroler treba s 1kB FLASH ROM a 64B RAM se da teoreticky programovat v Cecku - ze se tak neda udelat skoro nic, zatimco v assembleru casto ano, to je vec uplne jina.

mm2klokan :
programování mikrokontrolerů není normální programování, stejně jako programování některých ovladačů, nebo programování nízkoúrovňových funkcí operačních systémů nebo třeba programování obráběcích strojů
ale ani v těchto případech se v 99% k asembleru nesahá
 
to co ty popisuješ jsou všechno extrémní situace

Každopádně se omlouvám za klamnou informaci, nyní jsem to upravil, snad už to všem dojde... Jinak již jsem řekl že počítačové hry nehraju a hlavně pokud jsou časově náročné jako je například WOW. Programuju ve Visual Studiu ale k DirectXům jsem se ještě nedostal, takže děkuji za informace o tom jak to alespoň trochu funguje.