16Aug
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 fort 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( spesielt spill) aldri ser ut til å fungere akkurat 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-leseren TreyK vil vite hvorfor gamle dataspill kjører galt raskt på ny maskinvare:
Jeg har noen gamle programmer jeg trakk 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 typefort. 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 dette og kjører uavhengig av CPU frekvensen?
Så hva er historien? Hvorfor brenner sprites i gamle spill over 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 inn 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 et 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 chips!
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 ville være bedre å bruke DOSBox til å administrere klokkefrekvensen din søknad ser.
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 en slags emuleringsprogram), vil vi også foreslå å sjekke ut denne lange men interessante sammenbruddav prosessen 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.