Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[theothersteve7]

Aye, there seems to be a large number of people who, and for the life of me I can't understand why, have voted for graphics, multithreading and numerous other technical and utterly boring things.  I dont recall playing any game in my life and thinking, "if the graphics were better, you know, I might continue playing.  But as they are, oh geesh just hit reset, please."

You might not like it, but the lower-level aspects of the game are really what's holding it back.  If the interface were abstracted, we'd triple our player base in a month.  If the game were multithreaded, we'd almost never have another FPS death.  I personally have no complaints about the graphics, though; the tilesets are good enough.

It's the equivalent to a fortress deciding to build an obsidian farm before they have a reliable food supply.  It's a cornerstone of computer science to polish the fundamental building blocks of your program before you start adding frills.  The reason I'm getting back in to DF myself is because I found out how many bugs were fixed since I last played, not because he added vampires.  The biggest annoyance for me right now is how the entire fishing industry is defunct because fish go extinct.

Minecarts are an example of a system I can support.  It solves an existing problem, rather than being a fluffy new idea that messes things up more than it helps.

[ab9rf]

If the game were multithreaded, we'd almost never have another FPS death.

This is oft-stated by people here, but I don't believe for a moment that it's true.  Multithreading just pushes the boundary back a bit; it doesn't solve the problem.  The problem is that DF's code is (in critical places) grossly inefficient.  Multithreading will just let it be grossly inefficient on all (or at least more than one) of your cores, instead of just one of them.

You solve inefficiency by rewriting the inefficient code, not by throwing more resources at the problem.  Someone needs to profile DF, identify where it's sucking down the most CPU, and improve that code so that it uses less CPU.  Repeat until performance improves.  I know for a fact that there are cases where DF uses O(n) algorithms where O(ln n) or even O(1) approaches are possible; some of these are in large iterated loops.  And there is ample evidence that DF does little or no caching, which means things that could be computed once and cached are instead recomputed with every iteration of either the simulation or the screen renderer.  (I am aware that some things are cached, such as pathing information.  However, there are far more that are not.)  Addressing these issues would do far more to eliminate FPS death than just trying to shim multithreading into the app somehow.

[greenskye]

According to this thread, the largest FPS drain are bloated item vectors. It's a good read, so I'd suggest skimming through it.

[Solifuge]

In response to the OP, my suggestions have been sitting in the same place for years, and I haven't had to change them yet:

Your votes:
   - Abstract the Interface
   - Full graphics support
   - Improved Mechanics

[Normandy]

My votes:

Extra chairs in office for meetings
Return of the Guild Masters
Yearly Status Report

The yearly status report and the extra chairs in the office (so diplomats and liasons don't go running around) are just small details that I feel would make a few details easier to manage (i.e. tracking fortress growth and the status of meetings).

Return of the guilds ftw.

[ab9rf]

According to this thread, the largest FPS drain are bloated item vectors. It's a good read, so I'd suggest skimming through it.

I was already aware of this.  This is one of the places where there are O(n) operations being used where a more reasonable implementation would be O(ln n) or O(1).  Std::vector is not a good container for sparse arrays, and the items vector (especially) very rapidly becomes sparse in a DF fortress, especially as item ids are never reused.  (The unit vector not so much, since deceased units remain around forever.)  Of course, the elements of the item vector are just pointers, so the list itself is not large, but there are countless places where the code has to iterate over the entire item list (or one of its partitions: Toady realized that this was inefficient and tried to solve it by having both an all-items list as well as several partitions of the list, separately maintained, but that doesn't really solve the problem).  Some lists appear to have a keysearch interface overlaid on them that might allow a O(ln n) (binary) or O(1) (hash) search for certain keys. 

Simply replacing std::vector in the right places with one of the other STL containers, or with a container extended with better accessors than the ones offered by the base STL templates, would likely be able to substantially improve DF performance.  Identifying the right places to do this would require doing some profiling first, though.