Ha közvetlenül a hardverra programoznánk, minden sokkal gyorsabban futna ugye?

"de csak össze lehetne hozni valahogy a windowsra írt driverekkel"

Benne van, hogy Windows-ra írt... azaz kell alájuk egy Windows...

Egyébként szerintem lehet benne valami amit mondasz, gyorsabb lehetne talán. De az a gond, hogy MINDEN hardverre külön kéne megírni a dolgot... ami ugye nem kevés idő. Jó, akkor pakolsz bele driver-eket, és a hardver fölé húzol egy réteget, ami a megfelelő drivert használja. Meg képzeld el, mi van, ha valaki kitalálja, hogy hú, kéne még egy játék. Copy-zza bele ezt a driverkezelő kódot? Legyen ez benne minden játékban? Neeem, akkor legyen ez egy külön csomag, amit a játékok alá lehet telepíteni. Ugyanoda lyukadsz ki, ahol most vagyunk. Talán a multitasking, process ütemezés megspórolható, de ennek is lehetnek hátrányai.

Szerintem. De kivi leszek hozzáértőbbek válaszára is. :)

Gyorsabban futna. DE:

- Nem sokkal(Nem vagyok játékfejlesztési szakértő, de talán 15%-os sebességnövekedést tudnának elérni így)

- 10x annyiba kerülne egy játék, mert annyival több időt venne el a fejlesztés.

És itt van az érdekes pont a történetben:

Van egy 150K HUF-os géped, amin nem fut a 15000 FT-os játék.

Melyik éri meg jobban? Venni +2 Gb RAM-ot meg egy új videókarit 50K-ért, vagy inkább vennél 150000 FT-ért játékot, amit gépi kódban írtak, és elfut a 150K-s gépeden is? :D A kérdés persze költői.. :)

Az assembler előnyeként szokták említeni a hatékonyságot. De, ha belenézel egy assembler nyelvű kódba, akkor nagyon hamar össze tudsz zavarodni, pedig még ez is egy réteg a gépi kód fölött. Végső optimalizáláshoz hasznos.

Ráadásul nem is hordozható. A C például sokkal kényelmesebb, bár Javát C-re keresztfordítani nem egyszerű, és nem is biztos, hogy utána kiigazodnál rajta, vagy be tudnád építeni a rendszerindítóba.

de mutatták, hogy tetszőleges programot bele lehet tenni az indítóba, de ha közben elindul az operációs rendszer, azt a másik program nem biztos, hogy fogja szeretni.