Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 2 3 [4]

Author Topic: Maximizing FPS?  (Read 4613 times)

wuphonsreach

  • Bay Watcher
    • View Profile
Re: Maximizing FPS?
« Reply #45 on: March 06, 2011, 11:04:57 pm »

Run memtest86+ for at least 24 hours. if it runs with no issues, install a barebones, stripped windows xp install on some drive and just run DF and the tools you like. By stripped, I mean it. disable every service you wont use. disable anything from auto loading on bootup, etc.
So close... Memtest86+ is not the best tool for that job, Prime95 in "torture test" mode is.  Prime95 will catch all sorts of weird issues that Memtest86+ won't, because Prime95 really puts a beating on the cache/memory timings and you'll know within a day whether your overclock is truly stable.  My rule of thumb since the late 90s is that if you can run Prime95 for 24-48 hours without a single bit error, then you're good to go for a few years.  But if you can't get a clean run, then you've got a timing error or bad RAM.

And if you have more then 1 core, no real need to run a stripped down Windows install.  All of the garbage tasks get offloaded to the other cores anyway.
Logged

Nopkar

  • Bay Watcher
    • View Profile
Re: Maximizing FPS?
« Reply #46 on: March 07, 2011, 01:59:24 am »

man, reading all of this makes me sad.  "Minimize items, small stockpiles, cut down on the digging, don't have sprawling fortresses etc etc" is VERY un-dwarvenly to me. I hate dying an FPS death, but I also hate cutting my multitude of stockpiles brimming with junk...it makes me feel all dwarfy :)
Logged

-Jobs are to be assigned to Dwarves in alphabetical order, regardless of skill or specialization.

mrbaggins

  • Bay Watcher
    • View Profile
Re: Maximizing FPS?
« Reply #47 on: March 07, 2011, 04:04:42 am »

To give you a slightly better sense of the costs involved in an A* search and how they proliferate when spaces are open rather than confined, imagine that you are trying to reach a rock 10 spaces north of your current position, but in three completely different spaces:

1) You are at the end of a 1-space wide, 10-long corridor. At the other end is the item you want. In this case A* will find the object in exactly 10 steps, which is as good as it is ever going to get.

2) You are at a 4-way intersection with the corridors going off 20 spaces in all directions. The item is 10-spaces north. In this case you are going to find the object in about ~40 steps (A* has to search down all 4 corridors at once - it usually doesn't make any assumptions about what direction the object is in!)

3) You are standing on the surface, with nice green grass in all directions. The item is 10 spaces to the north. In this case basic A* is going to find the object in approximately ~400 steps - it has to search the entire square volume around you in concentric fashion before it finds the object! This is why a large starting embark area can have such dire consequences for pathing. Srlsy. 0_o;

Now, there are A* optimizations that can allow for much faster searches in some conditions like the open field, such as favoring steps that move towards the object, and making ones that move away from it more expensive, for example - but those search optimizations are making assumptions that might make other searches much MORE expensive, so there are usually trade-offs for this kind of thing.

There are also multi-layer A* concepts where the entire search space is broken up into large sections of 'geometry' that can be stepped through extremely quickly to get close to where the target is, but these implementations are quite complex and can take up a fair amount of memory to boot, so I have no idea if they are used in DF.

In a game like DF where the paths are frequently convoluted, I suspect that A* makes relatively few assumptions - but you'd have to ask Toady about the details. ;)

What you've written seems more applicable to a breadth first search, not a decent A* implementation.

Assuming the heuristic function is even something as simple as straight line distance to goal, your example 2 and 3 will be solved in 10-20 steps.
Logged

ThePup

  • Bay Watcher
    • View Profile
Re: Maximizing FPS?
« Reply #48 on: March 07, 2011, 04:58:06 am »

although 1x1 through the use of nano fort can get really good fps on even the worse computers.

Is there any way to get nanofort working with the latest DF?  I've wanted to create a 1x1 for my netbook, but seems to only work up to 31.12  last I saw  :(

My current fort was hovering around 15-20FPS on a 2x2 with around 70 dwarves.  I turned off temperature and it jumped to 30-35.  Big difference on low end hardware like a netbook.
Logged

Niseg

  • Bay Watcher
    • View Profile
Re: Maximizing FPS?
« Reply #49 on: March 07, 2011, 06:06:49 am »

I think there are 2 main problems as I mensioned before - flyers failing to find a path (you know what I mean) combined with no limit on each "NPC" processing time.

if you look up A* in wikipedia you'll find it's a dual loop algorithm ( worst N^2 but it's not).
The outer loop steps and the inner loop decides where to go .

The Issue with flyers is that their Inner loop has many neighbors especially when they are up in the air. Unlike a dwarf that usually have at most 10 options but fliers up in the air have 9*3-1 = 26 options.  this means that the cost of each flying step is higher .

I'm not sure if Toady limits the outer loops  . The outer loop means how many steps a dwarf/cat/whatever can calculate per "frame" . if there is no limit on it the dwarfs would calculate the whole path each time they want to go somewhere. dwarves don't seem very smart, they'll only recalculate their path each turn if they are tracking a moving target . If they are heading toward an item and the  path get blocked they'll go on the path until they hit a wall before recalculating it.

There is also another small issue mainly for hostile mobs- how persistent they are to get to their targets . if they never give up they would try to path into your fortress all the time even if they fail miserably each time it would load the cpu like crazy. 
Logged
Projects:Path finding simulator(thread) -A*,weighted A*(traffic zones), user set waypoints (path caching), automatic waypoint room navigation,no-cache room navigation.

PopeRichardCorey

  • Bay Watcher
    • View Profile
Re: Maximizing FPS?
« Reply #50 on: March 07, 2011, 11:53:12 am »

man, reading all of this makes me sad.  "Minimize items, small stockpiles, cut down on the digging, don't have sprawling fortresses etc etc" is VERY un-dwarvenly to me. I hate dying an FPS death, but I also hate cutting my multitude of stockpiles brimming with junk...it makes me feel all dwarfy :)

I think compact, efficient fortresses (with elaborate, sealed off catacombs) is very dwarvenly.  The rest, though, I agree...  Sad solutions :(
Logged
And when you build your fortress walls from the bones of skeletal elephants, slain my weapons forged from melted goblin plunder, fed on cattle that graze on grass that blinks.  Then, you will know dwarfdom.

Marthnn

  • Bay Watcher
  • Everything's possible
    • View Profile
Re: Maximizing FPS?
« Reply #51 on: March 07, 2011, 12:43:51 pm »

I'm not sure if Toady limits the outer loops  . The outer loop means how many steps a dwarf/cat/whatever can calculate per "frame" .
I would say Toady did limit the outer loop, since I've often seen flying goblin mounts being stuck forever 10 z-levels in the air. They ended up moving a couple squares once every 2-3 seasons. Or is it an unrelated bug?
Logged
Marthnn likes obsidian, steel, star ruby, goblin-cap wood, the color bloody red and giant desert scorpions for their tails. When possible, he prefers to consume sunshine. He absolutely detests cave blobs.

A dwarf wants to heal.  A dwarf is motivated to heal.  A dwarf is, by Armok, going to heal or die trying!  Because if he doesn't heal, he doesn't get alcohol.
Pages: 1 2 3 [4]