Windows Game Mode: Hry se vrací zpět k hardwaru
i Zdroj: PCTuning.cz
Hry Článek Windows Game Mode: Hry se vrací zpět k hardwaru

Windows Game Mode: Hry se vrací zpět k hardwaru | Kapitola 3

Michal Rybka

Michal Rybka

3. 2. 2017 03:00 36

Seznam kapitol

1. Hry zadrátované v hardwaru 2. Bezpečně, ale pomaleji 3. Když hra ovládala počítač 4. Moderní konzole 5. DirectX: když je maximální výkon problém 6. Windows Game Mode

Bylo nebylo, v dávné minulosti měl programátor k dispozici veškerý hardware. S časem jsme se od této myšlenky přes hardwarovou abstrakci dostali k Windows tak, jak je známe dnes – robustnímu systému, který se podobá spíš sálovým počítačům. Microsoft se nicméně míní vrátit zpět, aby na Windows zachránil hraní.

Reklama

Nejjednodušší funkcí zabudované ROM byl IPL (Initial Program Loader), který měl zjistit přítomnost programu na nějakém médiu, zavést ho do paměti, nastartovat ho a „potom jít do pr*ele“, jak tomu rozšafně říkali kodeři 80. let. IPL tu byl od toho, aby podporoval načtení z kazeťáků, disketovek, modulů, WafaDrive a čehokoliv jiného, to byla jediná jeho funkce, jediná hardwarová abstrakce. Načítaný program se „probudil v paměti na standardní zaváděcí adrese se standardními parametry“ - a bylo na něm, jak se zachová.

Pokročilejší paměti ROM nabízely aplikacím své služby – byly jim schopné říct, kolik je k dispozici paměti, zda jsou k dispozici mechaniky a některá standardizovaná rozšíření. Problém je ve slově „některá“, protože zabudovaná ROM typicky počítala pouze se zařízeními dodávanými přímo výrobcem. V komplikovanějších případech tak IPL načetl operační systém dodávaný s atypickým zařízením, které pak zajišťovalo jeho funkci a komunikaci s ním. To se týkalo systémů se zrychleným zaváděním z pásky (Turbo...), nezávisle vytvořených disků anebo třeba vylepšených rozšíření paměti, které podporovaly stránkování anebo zrychlený přenos.

Hry si mnohdy přinesly svůj vlastní loader anebo celý operační minisystém. U Commodore 64 (1982) bylo běžné, že ROM načetla zavaděč, který přes rozhraní disketové mechaniky nahrál do její vlastní paměti RAM upravený operační systém, který se spustil. Mechanika měla vlastní procesor MOS 6502 na 1 MHz a 2 KB RAM, což stačilo pro přeprogramování jejího chování, což se typicky používalo jako ochrana proti kopírování nebo pro zrychlené nahrávání.

Nakonec to ale bylo to samé: Hra kralovala celému systému, dělala si, co se jí zlíbilo a systém v ROM tu byl jen od toho, abyste z něj použili ty funkce, které se vám zrovna hodily. Zabudovaný BASIC anebo jeho zbytky (například Sharp MZ 800 měl v ROM jen část BASICu) vám mohl nabídnout třeba trigonometrické funkce anebo převod z kartézských souřadnic grafiky do paměťových souřadnic. Nebylo to moc efektivní, většina expertů si to dělala po svém, ale bylo to tam, když jste to potřebovali.

Původně přesně takhle fungovaly i konzole: V podstatě měly v ROM systém jen od toho, aby kontroloval originalitu médií a aby podporoval rozšiřující moduly výrobce. Situace se začala komplikovat s tím, jak se rozšiřoval multiplayer. Lokální multiplayer nebyl problém, dokud hráči seděli u té samé konzole, byl limit pouze v počtu vstupů, což řešil multitap, který duplikoval počet zapojitelných kontrolérů.

Věci začaly být podstatně složitější s nástupem internetu, nejprve formou dialupu a později broadbandu. Složitost operačního systému konzolí v podstatě explodovala, protože zatímco dříve stačilo jednoduše kontrolovat integritu software na cartridgi, přes modem mohlo přilézt dovnitř cokoliv. Najednou se objevily problémy s bezpečným připojením, s výpadky, s proměnlivou latencí, s nutností kontrolovat validitu uživatelských účtů a tak dále a tak dále. Potom přišla digitální distribuce, která vyžaduje kontrolu integrity balíčků a řadu dalších funkcí. A potom přišly sociální funkce, nahrávání gameplay videí a jejich přímý streaming, což v podstatě znamenalo, že původní loader se rozvinul v podstatě plnohodnotný operační systém.

Předchozí
Další
Reklama
Reklama

Komentáře naleznete na konci poslední kapitoly.

Reklama
Reklama