Hvorfor går gamle spil alt for hurtigt på moderne computere?

Hvis du nogensinde har forsøgt at få et vintage computerspil op og kører på et moderne system, har du sandsynligvis været chokeret over hvordan hurtig spillet løb. Hvorfor løber gamle spil ude af kontrol på moderne hardware?

Tidligere i dag viste vi dig, hvordan du kører ældre software på moderne computere; dagens spørgsmål og svar session er et godt kompliment, der graver ind på, hvorfor nogle ældre software (specifikt spil) aldrig virker at fungere lige, når du forsøger at køre dem på moderne hardware.

Dagens Spørgsmål & Svar session kommer til os med venlig hilsen af SuperUser-en underafdeling af Stack Exchange, en community-driven gruppe af Q & A-websteder.

Spørgsmålet

SuperUser-læser TreyK vil vide, hvorfor gamle computerspil kører hurtigt på ny hardware:

Jeg har et par gamle programmer, jeg trak en Windows-computer fra begyndelsen af 90'erne af og forsøgte at køre dem på en relativt moderne computer. Interessant nok kørte de i en flammende hurtig hastighed - nej, ikke de 60 billeder pr. Sekund slags hurtigere, snarere den oh-my-god-the-character-er-walking-at-the-speed-of-sound slags hurtig. Jeg ville trykke på en piletast og tegnets sprite ville zip over skærmen meget hurtigere end normalt. Tidsprogression i spillet skete meget hurtigere end det skulle. Der er endda programmer lavet til at bremse din CPU, så disse spil faktisk kan afspilles.

Jeg har hørt, at dette er relateret til spillet afhængigt af CPU-cyklusser, eller sådan noget. Mine spørgsmål er:

Hvorfor gør ældre spil dette, og hvordan kom de væk med det?

Hvordan gør nyere spil ikke gør dette og køre uafhængigt af CPU frekvensen?

Så hvad er historien? Hvorfor blæser sprites i gamle spil på tværs af skærmen så hurtigt, at spillet bliver unplayable?

Svaret

SuperUser bidragyder JourneymanGeek bryder det ned:

Jeg tror, at de antog, at systemuret ville køre med en bestemt hastighed og bundet i deres interne timere til den pågældende klokkefrekvens. De fleste af disse spil løb nok på DOS, og var ægte tilstand (med komplet, direkte hardwareadgang) og antog, at du kørte a IIRC 4,77 MHz-system til pc'er og uanset standardprocessor, som modellen løb for andre systemer som Amiga.

De tog også kloge genveje baseret på disse antagelser, herunder spare en lille smule ressourcer ved ikke at skrive interne timing loops inde i programmet. De tog også op så meget processorkraft som de kunne - hvilket var en anstændig idé i dagene med langsomme, ofte passivt afkølede chips!

Oprindeligt var en måde at omgå forskellige processorhastigheder den gode gamle Turbo-knap (som nedsatte systemet ned). Moderne applikationer er i beskyttet tilstand, og OS har tendens til at styre ressourcer - de ville det ikke give lov til en DOS-applikation (som kører i NTVDM på et 32-bit system alligevel) for at bruge hele processoren i mange tilfælde. Kort sagt, OS'er er blevet klogere, ligesom API'er.

Stærkt baseret på denne vejledning på Oldskool PC, hvor logik og hukommelse mislykkedes mig - det er en rigtig læst og går nok mere dybt ind i "hvorfor".

Ting som CPUkiller bruger så mange ressourcer som muligt til at "sænke" dit system, hvilket er ineffektivt. Du kan hellere bruge DOSBox til at styre klokkens hastighed, som din ansøgning ser.

Hvis du er nysgerrig efter, hvordan den faktiske kode blev implementeret i tidlige computerspil (og hvorfor de tilpasser sig så dårligt til moderne systemer uden at være sandboxet i et slags emuleringsprogram), vil vi også foreslå at tjekke denne lange men interessante sammenbrud af behandle i et andet SuperUser svar.

Har du noget at tilføje til forklaringen? Lyde af i kommentarerne. Vil du læse flere svar fra andre tech-savvy Stack Exchange brugere? Tjek den fulde diskussionstråd her.