Varför går gamla spel på väg för snabbt på moderna datorer?

Om du någonsin har försökt att få ett vintage datorspel igång på ett modernt system, har du troligtvis varit chockad över hur snabb spelet sprang. Varför går gamla spel ute av kontroll på modern hårdvara?

Tidigare idag visade vi dig hur man kör gammal programvara på moderna datorer; dagens fråga och svar är ett bra komplement som gräver till att vissa äldre program (specifikt spel) aldrig verkar fungera rätt när du försöker köra dem på modern hårdvara.

Dagens Question & Answer-session kommer till oss med tillstånd av SuperUser-en indelning av Stack Exchange, en community-driven gruppering av Q & A-webbplatser.

Frågan

SuperUser-läsaren TreyK vill veta varför gamla datorspel körs galen snabbt på ny maskinvara:

Jag har några gamla program som jag drog av en tidig 90-årig Windows-dator och försökte köra dem på en relativt modern dator. Intressant nog, de sprang i en blixtsnabb snabb hastighet - nej, inte de 60 bilderna per sekund snabbare, snarare den oh-my-god-the-character-är-walking-at-the-speed-of-sound slags snabb. Jag skulle trycka på en piltangent och karaktärens sprite skulle zip över skärmen mycket snabbare än normalt. Tidsprogression i spelet hölls mycket snabbare än det borde. Det finns även program som görs för att sakta ner din CPU så att dessa spel kan spelas.

Jag har hört att detta är relaterat till spelet beroende på CPU-cykler, eller något liknande. Mina frågor är:

• Varför gör äldre spel det här, och hur kom de undan med det?
• Hur gör nya spel inte gör detta och springa oberoende av CPU frekvensen?

Så vad är historien? Varför exakt sprites sprites i gamla spel över skärmen så fort blir spelet ospelbart?

Svaret

SuperUser-bidragare JourneymanGeek bryter ner det:

Jag tror att de antog att systemet klockan skulle springa i en viss takt och bundet i sina interna timers till den klockfrekvensen. De flesta av dessa spel körde förmodligen på DOS, och var riktigt läge (med fullständig, direkt hårdvaruåtkomst) och antagde att du körde en IIRC 4,77 MHz-system för datorer och vilken standardprocessor som modellen körde för andra system som Amiga.

De tog också snabba genvägar utifrån de antagandena, inklusive att spara en liten bit av resurser genom att inte skriva interna timing loopar inuti programmet. De tog också upp så mycket processorkraft som de kunde - vilket var en anständig idé i dagarna med långsamma, ofta passivt kylda marker!

Ursprungligen var ett sätt att komma runt annorlunda processorhastighet den bra gamla Turbo-knappen (som saktade ner ditt system). Moderna applikationer är skyddade och OS brukar hantera resurser - de skulle inte tillåta en DOS-applikation (som körs i NTVDM på ett 32-bitars system ändå) för att använda hela processorn i många fall. Kort sagt, OS har blivit smartare, liksom API: er.

Tungt baserad av den här guiden på Oldskool PC där logik och minne misslyckades - det är en bra läsning och går förmodligen mer i djupet i "varför".

Stuff som CPUkiller använder upp så många resurser som möjligt för att "sakta ner" ditt system, vilket är ineffektivt. Du kan bättre använda DOSBox för att hantera klockhastigheten som din ansökan ser.

Om du är nyfiken på hur den faktiska koden implementerades i tidiga datorspel (och varför de anpassar sig så dåligt till moderna system utan att vara sandlåda i någon form av emuleringsprogram), skulle vi också föreslå att du undersöker denna långa men intressanta uppdelning av bearbeta i ett annat SuperUser-svar.

Har du något att lägga till förklaringen? Ljud av i kommentarerna. Vill du läsa mer svar från andra tech-savvy Stack Exchange-användare? Kolla in hela diskussionsgängan här.