Om du någonsin har försökt få igång ett vintage-dataspel på ett modernt system har du troligen varit chockad över hur fast spelet gick. Varför har gamla spel slut på kontroll på modern hårdvara?
Tidigare idag har vi visade dig hur du kör äldre programvara på moderna datorer ; dagens frågestund är en trevlig komplimang som gräver in i varför en del äldre program (speciellt spel) aldrig verkar fungera rätt när du försöker köra dem på modern hårdvara.
Dagens Fråga & Svar-session kommer till oss med tillstånd av SuperUser - en underavdelning av Stack Exchange, en community-driven gruppering av Q & A-webbplatser.
Frågan
SuperUser-läsaren TreyK vill veta varför gamla datorspel går galet snabbt på ny hårdvara:
Jag har några gamla program som jag tog fram en Windows-dator från tidigt 90-tal och försökte köra dem på en relativt modern dator. Intressant nog sprang de med en snabb hastighet - nej, inte de 60 bilderna per sekund typ av snarare, snarare oh-min-gud-karaktären-går-med-ljudhastigheten snabb. Jag skulle trycka på en piltangent och karaktärens sprite skulle zippa över skärmen mycket snabbare än normalt. Tidsutvecklingen i spelet hände mycket snabbare än det borde. Det finns även program till sakta ner din CPU så att dessa spel faktiskt 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 detta, och hur kom de undan med det?
- Hur gör nyare spel inte gör detta och kör oberoende av CPU-frekvensen?
Så vad är historien? Varför existerar sprites i gamla spel över skärmen så snabbt att spelet blir ospelbart?
Svaret
SuperUser-bidragsgivare JourneymanGeek bryter ner det:
Jag tror att de antog att systemklockan skulle köras i en viss takt och bundna i sina interna timers till den klockfrekvensen. De flesta av dessa spel sprang antagligen på DOS, och var riktigt läge (med fullständig, direkt maskinvaruåtkomst) och antog att du körde en iirc 4,77 MHz-system för datorer och vilken standardprocessor som helst som modellen körde för andra system som Amiga.
De tog också smarta genvägar baserat på dessa antaganden inklusive att spara en liten bit resurser genom att inte skriva interna tidsslingor inuti programmet. De tog också upp så mycket processorkraft som de kunde - vilket var en anständig idé i dagarna av långsamma, ofta passivt kylda marker!
Ursprungligen var ett bra sätt att komma runt olika processorhastigheter den gamla gamla Turbo-knapp (vilket saktade ner ditt system). Moderna applikationer är i skyddat läge och operativsystemet tenderar att hantera resurser - det skulle de inte göra tillåta en DOS-applikation (som körs i NTVDM på ett 32-bitars system ändå) för att använda upp hela processorn i många fall. Kort sagt, OS har blivit smartare, liksom API: er.
Tungt baserad den här guiden på Oldskool PC där logik och minne misslyckades med mig - det är en bra läsning och går förmodligen mer djupt in i "varför".
Saker som CPUkiller använd så många resurser som möjligt för att "sakta ner" ditt system, vilket är ineffektivt. Det skulle vara bättre för dig att använda DOSBox för att hantera klockhastigheten som din applikation 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 sandlådas i något slags emuleringsprogram), föreslår vi också att du kolla in denna långa men intressanta uppdelning av processen i ett annat SuperUser-svar.
Har du något att lägga till förklaringen? Ljud av i kommentarerna. Vill du läsa fler svar från andra tekniskt kunniga Stack Exchange-användare? Kolla in hela diskussionstråden här .
