DOS Games

This is a discussion on DOS Games within the Game Programming forums, part of the General Programming Boards category; Although it wouldn't reduce CPU usage, is it wise to clamp the graphics frames and do thinking as fast as ...

  1. #16
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    Although it wouldn't reduce CPU usage, is it wise to clamp the graphics frames and do thinking as fast as possible?

    Or let them both run at the same rate? At the moment my 'thinking' is unlimited (delta time is used) -- but I limit the rendering FPS to say 100. The rendering doesn't do anything time based though.

  2. #17
    Registered User
    Join Date
    Apr 2007
    Location
    Sydney, Australia
    Posts
    217
    Quote Originally Posted by Bubba View Post
    There is no problem with 100%. Games take over the system as they should. Hence the whole concept of full screen is to immerse the player in the game. They could care less about IMs, Word, or anything else running in the background.

    Games take 100%. Sleeping is absurd. The reason there isn't a rush to correct this 'problem' is because it is not viewed as a problem. All of my modern games push my CPU usage to 100%.
    What about programs such as Fraps that record the screen? Would 100% cpu usage affect this?

  3. #18
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,614
    Quote Originally Posted by Bubba View Post
    There is no problem with 100%. Games take over the system as they should. Hence the whole concept of full screen is to immerse the player in the game. They could care less about IMs, Word, or anything else running in the background.

    Games take 100%. Sleeping is absurd. The reason there isn't a rush to correct this 'problem' is because it is not viewed as a problem. All of my modern games push my CPU usage to 100%.
    What is absurd is that they eat 100% CPU.
    No, we mostly don't care about the background processes, but we DO care about the electric bill and there's where the problem lies.
    They don't have to eat 100% CPU to immense the player in a wonderful experience.
    Use as much as they need, and no more.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  4. #19
    Registered User guesst's Avatar
    Join Date
    Feb 2008
    Location
    Lehi, UT
    Posts
    179
    You know, I have an old mode 13h game somewhere around. Maybe I'll post the code, but I seem to remember it using interupts for it's input and screen redraw so that it spent quite a bit of time doing nothing. Unfortunately interupts are no loger a viable resource, which is too bad. I really miss them.

    Funny, my tetris game recently got commented on that it used 100% of the CPU and I took that to be a bad thing trying to think how I could fix it. (It was because the system was looping the input check while waiting for the timed drop.) Turns out it's not a problem, eh? Groovy. I wasn't going to do anything about it anyways.
    Type-ins are back! Visit Cymon's Games at http://www.cymonsgames.com for a new game every week!

  5. #20
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,614
    No, you should listen to feedback. It is a problem, if you ask me.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  6. #21
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    Nothing wrong with 100% CPU usage for a game IMO. The faster it runs the less you have to interpolate between frames (thus, theoretically -- smoother play).

  7. #22
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,596
    What is absurd is that they eat 100% CPU.
    No, we mostly don't care about the background processes, but we DO care about the electric bill and there's where the problem lies.
    They don't have to eat 100% CPU to immense the player in a wonderful experience.
    Use as much as they need, and no more.
    You want the game running as fast as possible, rendering as fast as possible, processing as fast as possible, using as much memory as is available, eating as much video memory as the card has. Simple: You want to max out the resources available to your game. And when I say max out I mean 100% completely max them out. Games like Oblivion, Doom 3, Microsoft Flight Simulator X, Spore, Sims2, and tons of others need every ounce of every resource the computer has to offer. If the computer has 3 gig, use it, if it has 6 gig, use it. Of course there is a buffer zone so the system doesn't run out of memory but most games will attempt to use everything they can.

    There is nothing wrong with multi-threading the app to gain performance and newer games are using this but I assure you it is not with the intent of bringing the CPU usage down. I don't think the gamers would be happy if their game slowed down just b/c the devs wanted to bring the CPU usage down so they added some sleeps.
    Gamers pay good money for their hardware and the latest and greatest game ought to use every piece of it.

    Some forums say that CPU usage on single core CPUs is always gonna be at 100% on games. Others say this shouldn't happen but give no valid 'graphics related' reasons why. Most of the game physics are being done on the CPU unless you have an Ageia PhysX card. If the game is not heavy on physics and is using a lot of shaders then I could see single core CPU usages below 100%. Personally I do not see the issue with 100% usage and I'm not even sure I would completely trust Microsoft's little CPU gauge as being accurate. There is a lot more going on in the background if you have other apps running in the systray. So even though the gauge shows 100% you really need to look at the details and see which apps are taking the most. Most of the time in a Windows app is spent in idle processing. Most of the time in a game is spent in the update/render loop. This could account for the 100% since this loop is running 60 to 100 times per second or more depending on v-sync settings. This could ramp CPU usage up but this does not mean you are overtaxing it by any means. If you figure there are 200 objects to update 60 to 100 times per second then you are doing 12000 to 20000 updates per second. Depending on the game and how they update objects this could result in a matrix multiply to get to world space right on the CPU or perhaps it is on the GPU. There are still a lot of software algos under the hood that make the game run super fast. Hardware is great but software algos still determine what to draw and what not to draw for the most part. The limiting factor here is the bus since you can't just throw millions of vertices across the bus and expect to get good performance. You also cannot expect to just brute force your way onto the screen by sending everything you have to the card and let it cull what isn't visible. Games still require a significant amount of CPU to cull away objects that do not need to be rendered or processed.


    I'm not sure you can get all of that below 100%. With DirectX10 and mesh instancing and geometry shaders I'm sure we will see these usage numbers drop significantly.
    Last edited by VirtualAce; 05-30-2008 at 07:26 PM.

  8. #23
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,614
    I do agree with you, Bubba. The point was if there is any available resources left - spent doing unnecessary things, then it can be optimized as to not use all 100%.
    Some games are smart enough to pause everything if you tab out. I like that too. I like tabs where it is possible to tab out, too.
    If there's a possibility of getting below 100% while still retaining smooth performance - do it!
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  9. #24
    Dr Dipshi++ mike_g's Avatar
    Join Date
    Oct 2006
    Location
    On me hyperplane
    Posts
    1,218
    Ok, theres one thing I don't quite get. If say you cap your frame rate at 60-100fps, then if the computer needs to use 100% of its time running the game at that speed then it will. However, if it doesent then it wont end up using more resources than it needs to whilst appearing the same. The only situation where I could see this causing any loss of performance would be if there is a huge variance between loop times (which I guess could occur if you run some of the more demanding thing once every x loops). Maybe I'm missing something here as I guess most new games don't tend to do this
    Last edited by mike_g; 05-31-2008 at 08:47 AM.

  10. #25
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,467
    I don't even think mode 13h has such a straightforward relation to frame rates.

    I always thought any speed control done during the time mode 13h was a common place was by CPU speed calculation. The game would then run at the same speed on any computer. I simply don't remember how they would do it exactly, but I'm pretty sure it wasn't by frame rate clamping. They would probably interfere with the APIC or the Real Time Clock.

    I'm not sure this is possible to do anymore since current windows versions lack a DOS mode.

    My real suggestion here is to not programmatically reduce mode 13h game through FPS reducing. As shown this forces the CPU into more work than it should. Instead, code it in DOS using the methods of the time, then run it under DOSBox, or code it normally in windows and run it with slowdown tools like Mo'Slo.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  11. #26
    Registered User
    Join Date
    Jan 2007
    Posts
    330
    Quote Originally Posted by Bubba View Post
    You want the game running as fast as possible, rendering as fast as possible, processing as fast as possible, using as much memory as is available, eating as much video memory as the card has. Simple: You want to max out the resources available to your game. And when I say max out I mean 100% completely max them out. Games like Oblivion, Doom 3, Microsoft Flight Simulator X, Spore, Sims2, and tons of others need every ounce of every resource the computer has to offer. If the computer has 3 gig, use it, if it has 6 gig, use it. Of course there is a buffer zone so the system doesn't run out of memory but most games will attempt to use everything they can.
    the games you mention are big commercial titles. The other dude is talking about a tetris he made. Absolutely no need to go 100% with tetris

  12. #27
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,596
    Closed. Please don't bump old threads.

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Small VGA unit for DOS games
    By VirtualAce in forum Game Programming
    Replies: 1
    Last Post: 10-17-2003, 12:08 AM
  2. Video Games Industry. 5 years left.
    By Cheeze-It in forum A Brief History of Cprogramming.com
    Replies: 26
    Last Post: 12-10-2002, 09:52 PM
  3. DOS games on new computers...
    By deathstryke in forum Tech Board
    Replies: 8
    Last Post: 11-18-2002, 09:45 AM
  4. Some cool old dos games
    By funkydude9 in forum A Brief History of Cprogramming.com
    Replies: 0
    Last Post: 11-11-2002, 02:12 PM
  5. DOS program versus DOS console program
    By scromer in forum A Brief History of Cprogramming.com
    Replies: 4
    Last Post: 01-10-2002, 12:42 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21