16Aug
Se você já tentou obter um jogo de computador antigo instalado em um sistema moderno, provavelmente ficou chocado com o rápido o jogo executado. Por que os jogos antigos ficam sem controle sobre hardware moderno?
Mais cedo, hoje mostramos como executar software antigo em computadores modernos;A sessão de perguntas e respostas de hoje é um bom elogio que invoca o motivo pelo qual alguns softwares mais antigos( especificamente jogos) nunca parecem funcionar bem quando você tenta executá-los em hardware moderno.
Today's Question &A sessão de atendimento chega a cortesia do SuperUser - uma subdivisão do Stack Exchange, um agrupamento comunitário de sites Q & A.
A pergunta
Leitor de superutilizador TreyK quer saber por que os antigos jogos de computador ficam loucos rapidamente no novo hardware:
Eu tenho alguns programas antigos que tirei um computador com Windows anterior dos anos 90 e tentei executá-los em um computador relativamente moderno. Curiosamente, eles correram a uma velocidade rápida e ardente - não, não o estilo de 60 quadros por segundo de jejum, e sim o tipo de "oh-meu-deus-o-personagem" que está caminhando na velocidade do somvelozes. Eu pressionaria uma tecla de seta e o sprite do personagem iria zip na tela muito mais rápido do que o normal. A progressão do tempo no jogo estava acontecendo muito mais rápido do que deveria. Há mesmo programas feitos para diminuir a velocidade da sua CPU para que esses jogos sejam realmente jogáveis.
Eu ouvi dizer que isso está relacionado ao jogo dependendo de ciclos de CPU, ou algo assim. Minhas perguntas são:
- Por que os jogos mais antigos fazem isso, e como eles fugiram com isso?
- Como os jogos mais recentes não fazem isso e funcionam independentemente da freqüência da CPU?
Então, qual é a história? Por que exatamente o sprites em jogos antigos chama a tela tão rápido que o jogo se torna não jogável?
A resposta
SuperUser contribuinte JourneymanGeek quebra-lo:
Eu acredito que eles assumiram que o relógio do sistema funcionaria a uma taxa específica, e amarrado em seus temporizadores internos para essa taxa de clock. A maioria desses jogos provavelmente funcionava no DOS e era de modo real( com acesso direto e direto ao hardware) e assumiu que você estava executando um sistema iirc 4,77 MHz para PC e qualquer processador padrão que o modelo funcionasse para outros sistemas como o Amiga.
Eles também tomaram atalhos inteligentes com base nessas premissas, incluindo salvar um pequeno número de recursos ao não escrever laços internos de tempo dentro do programa. Eles também adquiriram tanto poder do processador como podiam - o que era uma idéia decente nos dias de chips lentos, muitas vezes passivamente arrefecidos!
Inicialmente, uma maneira de contornar a velocidade do processador diferente era o bom e antigo botão Turbo( que desacelerou o sistema).As aplicações modernas estão em modo protegido e o SO tende a gerenciar recursos - eles não permitem um aplicativo DOS( que está sendo executado em NTVDM em um sistema de 32 bits de qualquer maneira) para usar todo o processador em muitos casos. Em resumo, os SOs ficaram mais inteligentes, assim como as APIs.
Baseado fortemente neste guia no PC Oldskool, onde a lógica e a memória me falharam - é uma ótima leitura, e provavelmente vai mais profundamente no "porquê".
Stuff, como CPUkiller, usa tantos recursos quanto possível para "diminuir" o sistema, o que é ineficiente. Você seria melhor usar o DOSBox para gerenciar a velocidade do relógio que sua aplicação vê.
Se você está curioso sobre como o código real foi implementado nos primeiros jogos de computador( e por que eles se adaptam tão mal aos sistemas modernos sem serem armazenados em algum tipo de programa de emulação), também sugerimos verificar essa quebra longa, mas interessantede processo em outra resposta do SuperUser.
Tem alguma coisa a adicionar à explicação? Som na parte dos comentários. Deseja ler mais respostas de outros usuários Tech-savvy Stack Exchange? Confira o tópico de discussão completo aqui.