Jump to content
  • Advertisement
Sign in to follow this  
deadlydog

Why do old games run too fast

This topic is 4348 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
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!