• Advertisement
Sign in to follow this  

Why do old games run too fast

This topic is 4169 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Just a quick question. I'm writing a report for one of my classes and was wondering why some older games run super fast on todays newer computers. My guess is because they were using a frame-based (as opposed to time-based) design without locking the game to 30 or 60 fps. Is this correct or am I way off? Thanks.

Share this post


Link to post
Share on other sites
Advertisement
Basically, some old games tied themselves to the speed of the machine, rather than to real time. As machines got faster, their execution got faster as well.

Share this post


Link to post
Share on other sites
Quote:
Original post by bakery2k1
Basically, some old games tied themselves to the speed of the machine, rather than to real time. As machines got faster, their execution got faster as well.

So basically then they used a frame-based game design without locking the game to X frames per second. Thanks, I just wanted to confirm this before I used it in my report.

Share this post


Link to post
Share on other sites
Sorta, except that it wasn't really a "frame based system" it was more of a "overall-speed" thing. A game meant for a 20mhz processor was made to run at correct speed on a 20mhz processor. Most likely, they weren't thinking about frames per second when making the game, just execution time.

Share this post


Link to post
Share on other sites
Basically if you have code like this:

// wait for ~10us
for (int i = 0; i < 182638 /* whatever works on the devs machine */; ++i)
continue;

It will break when you move to a faster machine. You see such timing loops relatively commonly in the code of people who convince themselves that checking the system clock is either to expensive or that it's not accurate enough.

It's also common that you have such loops accidentally. They're not spelled out in two lines like that. It's just the way their code fell out and they didn't do enough testing on a wide variety of machines to discover the timing problem.

Share this post


Link to post
Share on other sites
Quote:
Original post by deadlydog
So basically then they used a frame-based game design without locking the game to X frames per second. Thanks, I just wanted to confirm this before I used it in my report.


no, games today are still frame-based, thats why it called frams per SECOND.
frames are connected to time (if you use fps calculation)! so you dont have to lock them to a special X, cause if frames increase, the movement per frame will decrease. so you always have a connection to real time!

old games dont connect frames to seconds, they dont connect anything to time, so if you can calculate it faster it will work faster.

Share this post


Link to post
Share on other sites
Quote:
Original post by Anon Mike
Basically if you have code like this:

// wait for ~10us
for (int i = 0; i < 182638 /* whatever works on the devs machine */; ++i)
continue;

It will break when you move to a faster machine.

Or when you use a modern compiler, most compilers used at that time didn't optimize like current compilers do so you could actually just put in a lot of NOPs somewhere.

Quote:
You see such timing loops relatively commonly in the code of people who convince themselves that checking the system clock is either to expensive or that it's not accurate enough.

Of course this isn't acceptable today (it doesn't even work), but there was a time when it was a reasonable thing to do.

Share this post


Link to post
Share on other sites
Consider what "old games" came from. the earlier generations of home computers didnt come so that you could replace the CPU, or the RAM, or anything. You bought a processer, 640k of RAM, etc, and everybody had the same machine, except for your extras like modems and printers.

In that time, it made perfect sense to time thing based on the machine, so if I decided that counting from 1 to 2000 bought me the right amount of time before I told my game to move forward again, that would work on my machine, your machine, etc.

This followed forward into the newer machines, and before true multitasking systems, you could get pretty much the same effects. It took a while before people started realizing that things would start speeding up over time. The acceleration of upgradeable hardware started to throw this into sharp relief, but dont forget another critical change, the multitasking angle that started coming into the home market. in DOS days, when you ran a game, it got control fo the system. Later, programs had to start sharing cycles with everything else you were trying to run.
That starts to mess with hacky ways of measuring time, and you really have to start paying attention to the clock, because theres no way to reliably guess how much time is going to pass between counting from 2 to 3.

Share this post


Link to post
Share on other sites
Quote:
Original post by Chicki
Quote:
Original post by deadlydog
So basically then they used a frame-based game design without locking the game to X frames per second. Thanks, I just wanted to confirm this before I used it in my report.

no, games today are still frame-based, thats why it called frams per SECOND.
frames are connected to time (if you use fps calculation)! so you dont have to lock them to a special X, cause if frames increase, the movement per frame will decrease. so you always have a connection to real time!

old games dont connect frames to seconds, they dont connect anything to time, so if you can calculate it faster it will work faster.

Right, so games today aren't really frame-based, they are time-based, which was the other alternative I said in my first post. We just use a FPS counter to see what kind of speed we are getting from the game. The only way a game could be frame based today would be to lock the frames per second.

Maybe I should clarify. When I say a game is frame based, I mean that the movement of objects within the game is based on how many FPS the game is displaying at. For example, if in my code I just Position += 5 then every frame the Position would increment by 5 units. This can potentially work, as long as the FPS is locked to say 30 FPS. If you did not lock the frame rate then everything would move lightning quick if you were getting 300 FPS. Time based movement on the other hand would be saying move 5 units per second, so each frame it would calculate what portion of that 5 units to move in that one particular frame. So most games today are not frame based as you say, they are actually time based. The problem may just be our different interpretations of the terminology.

Share this post


Link to post
Share on other sites
Quote:
Original post by Anon Mike
Basically if you have code like this:

// wait for ~10us
for (int i = 0; i < 182638 /* whatever works on the devs machine */; ++i)
continue;


Some older games didn't even do that. When you had 48KB of memory, a 320 KB disk, no hard drive, and a 3.88 MHz machine, many developers didn't even bother putting in NOPs or other versions of waiting. Those extra clock cycles could be used for better purposes. Then again, many machines were so slow that they drew directly to the graphics device rather than creating a back buffer.

Using the knowledge of the processor was common use, not only with graphics, but with sound. This is one of the reasons many games won't have their sound work correctly.

But there were many other problems older games didn't worry about that cause them not to work today. Malloc? Hogwash! I know for a fact that the memory at 0x00001000 is owned by me.

But yes, older games are frame based. When you have limited resources, you have to sometimes use tricks to get the most out of them. Sometimes they are not exactly safe, and not really thinking how they're going to run 5 or 10 years from now.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I think you need to get away from this 'frame based' mode of thought.
Not every game is synchronized with the video refresh, in fact I'm going to bet that most of those old games were not.
So it really isn't a good way of thinking about the problem of speed... faster video cards really is Not the reason old games run too fast, this is purely a cpu issue, not talking frames here...

Quote:

The problem may just be our different interpretations of the terminology.

make sure you get the Right terms before you go giving a presentation...
there is no interpretation, only right and wrong

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
I think you need to get away from this 'frame based' mode of thought.
Not every game is synchronized with the video refresh, in fact I'm going to bet that most of those old games were not.
So it really isn't a good way of thinking about the problem of speed... faster video cards really is Not the reason old games run too fast, this is purely a cpu issue, not talking frames here...

Quote:

The problem may just be our different interpretations of the terminology.

make sure you get the Right terms before you go giving a presentation...
there is no interpretation, only right and wrong


He does have the terminology right. When we say a game is frame-based we don't mean that it's "synchronized" with the refresh rate. Time-based movement basically means that objects move X virtual space units per Y virtual time units. If the virtual time units are obtained from the CPU's clock, the movement is indepedent of the machine because the ratio (virtual time units)/(real time units) is the same for all machines, since all clocks run in the same speed no matter if they're in a 286 or a Pentium. Frame-based movement means that object move X space units per Y frames. Frame, in simple terms, means every time you process and render a new "snapshot" of your game's world. It is not indepedent of the machine because the ratio (frames)/(real time units) is not the same for all machines. The developers of those old games used tricks like loops to get the desirable ratio for the machine they worked on, but in faster machines the ratio increases, and naturally the game runs faster.

Also, video cards are completely irrelevent. I'm pretty sure that any game that used hardware acceleration(ie relatively modern) used time-base movement. Those old games used the CPU for nearly everything, including drawing the graphics, and they don't use it even today, regardless if they run in a system that does have HW acceleration, simply because they're unaware of it.

This has happened to me too with a slot machine game I made in BASIC around 10 years ago. I used the correct "for" loops to make the fruits roll in the screen in the speed I wanted them to in my 286, and then when I go and try it in a friend's 486...BAM! you couldn't even see them :)

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Hey guys, I got a question that hopefully you will be able to help me. I got Unreal Tournement 2003 or 2004 and I installed it on my new laptop which has like a 1.7 Centrino processor, 512MB RAM, and integrated video. So it's a nice comp but I mean it's not the latest and greatest for sure. But I installed UT on it and the game is running SUPER fast. I can not figure out why. I have increased the graphics to max on the game hoping to slow it down but it didnt make a difference. I reinstalled the game and the same problem. Any ideas?

-Mike

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
deactivate speedstep while playing ;)

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
This is just a hunch, but if its a dual core processor try starting the game, minimizing, going into task manager, find the games process, right click and goto set affinity, and uncheck one of the CPUs.

I have had to do this for some programs so that they run correctly, or so that some will run without crashing (Maya 7).

Not sure if it will work, but its worth a try.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
its not a dual core processor. and i wish speed stepping was the problem, lol. but the whole game (into video and all) just goes like UT on steroids. Its kinda weird, normally ppl complain about a game going too slow or lagging, but this darn thing is too fast.

and by the way, i installed the game on one of my other comps which is a 3.2GHz and it runs perfectly.

-Mike.

Share this post


Link to post
Share on other sites
UT has game options where u can crank up game speed. make sure that hasnt been jacked all the way up.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
the game speed is at 100%. It is almost normal speed at 50% but still fast.

-Mike

Share this post


Link to post
Share on other sites
Quote:
Original post by firewall1
well i have a nes emulator and the games run as slow now as they did back then(in the good way)

Yes, but the emulator is attempting to be accurate, so it limits its own speed where necessary.

The OP was referring to old PC games, running on newer PC hardware.

The same thing will happen to NES games if you were to overclock the CPU in it.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement