Hvorfor går gamle spill langt for raskt på moderne datamaskiner?

Hvis du noen gang har prøvd å få et vintage dataspill som kjører på et moderne system, har du sannsynligvis blitt sjokkert over hvordan rask spillet kjørte. Hvorfor går gamle spill ut av kontroll på moderne maskinvare?

Tidligere i dag viste vi deg hvordan du kjører eldre programvare på moderne datamaskiner; dagens spørsmål og svar sesjon er et fint kompliment som graver inn hvorfor noen eldre programvare (spesifikt spill) aldri ser ut til å fungere rett når du prøver å kjøre dem på moderne maskinvare.

Dagens Spørsmål & Svar-sesjon kommer til oss med høflighet av SuperUser-en underavdeling av Stack Exchange, en fellesskapsdrevet gruppering av Q & A-nettsteder.

Spørsmålet

SuperUser-leser TreyK vil vite hvorfor gamle dataspill kjører sprø fort på ny maskinvare:

Jeg har noen gamle programmer jeg dro av en tidlig 90-årers Windows-datamaskin og prøvde å kjøre dem på en relativt moderne datamaskin. Interessant nok kjørte de i en raske, raske hastighet - nei, ikke de 60 rammene per sekund, rask, snarere den oh-my-god-the-character-er-walking-at-the-speed-of-sound slags rask. Jeg ville trykke på en piltast og karakterens sprite ville zip over skjermen mye raskere enn normalt. Tidsprosess i spillet skjedde mye raskere enn det burde. Det er til og med programmer laget for å redusere CPUen din slik at disse spillene faktisk kan spilles.

Jeg har hørt at dette er relatert til spillet, avhengig av CPU-sykluser, eller noe sånt. Mine spørsmål er:

• Hvorfor gjør eldre spill dette, og hvordan kom de bort med det?
• Hvordan gjør nyere spill ikke gjør dette og kjøre uavhengig av CPU frekvensen?

Så hva er historien? Hvorfor spruter sprites i gamle spill over hele skjermen så fort spillet blir uoppspillbart?

Svaret

SuperUser-bidragsyter JourneymanGeek bryter det ned:

Jeg tror de antok at systemet uret ville kjøre til en bestemt hastighet, og bundet i sine interne timere til den klokkefrekvensen. De fleste av disse spillene kjørte trolig på DOS, og var ekte modus (med fullstendig, direkte maskinvaretilgang) og antok at du kjørte a IIRC 4,77 MHz-system for PCer og hvilken som helst standardprosessor som modellen kjørte for andre systemer som Amiga.

De tok også smarte snarveier basert på disse forutsetningene, inkludert sparing av en liten bit ressurser ved ikke å skrive interne timing looper inne i programmet. De tok også opp så mye prosessorkraft som de kunne - noe som var en anstendig idé i dagene med sakte, ofte passivt avkjølte sjetonger!

I utgangspunktet var en enkel måte å komme seg rundt annerledes prosessorhastighet på, den gode gamle Turbo-knappen (som senket systemet ned). Moderne applikasjoner er i beskyttet modus og operativsystemet har en tendens til å administrere ressurser - de ville ikke tillate en DOS-applikasjon (som kjører i NTVDM på et 32-bits system uansett) for å bruke hele prosessoren i mange tilfeller. Kort sagt, OSene har blitt smartere, som har APIer.

Sterkt basert på denne veiledningen på Oldskool PC hvor logikk og minne mislyktes meg - det er en flott lesning, og sannsynligvis går mer i dybden i "hvorfor".

Ting som CPUkiller bruker opp så mange ressurser som mulig å "sakte" ned systemet ditt, noe som er ineffektivt. Du vil hellere bruke DOSBox til å administrere klokkefrekvensen din ser på.

Hvis du er nysgjerrig på hvordan den faktiske koden ble implementert i tidlige dataspill (og hvorfor de tilpasser seg så dårlig til moderne systemer uten å være sandboxed i et slags emuleringsprogram), vil vi også foreslå å sjekke ut denne lange, men interessante sammenbruddet av behandle i et annet SuperUser-svar.

Har du noe å legge til forklaringen? Lyde av i kommentarene. Vil du lese flere svar fra andre tech-savvy Stack Exchange-brukere? Sjekk ut hele diskusjonstråden her.