Print

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

Faster than 40d, no problems

42 (26.1%)

Faster than 40d, problems

72 (44.7%)

No slower than 40d, no problems

14 (8.7%)

No slower than 40d, problems

16 (9.9%)

Slower than 40d, no problems

2 (1.2%)

Slower than 40d, problems

3 (1.9%)

Doesn't work (please explain)

12 (7.5%)

Total Members Voted: 160

[Baughn]

Yeah, I looked, I just forgot to comment.
Funny thing, too; DF uses quads (I really need to do something about that), which regardless of their speed means the sort of picture you got, with lines sticking out, is absolutely impossible.

In other words, driver/gpu error. We're seeing a lot of that, I guess. 

[Ogantai]

I dont know how much the pathing code evoilved since then but maybe the Pathing algorithm of AKQ is similiar to the algorithm in DF.

It's not.

Any chance Today could release a BC-like program with pathfinding?

This would be my ultimate DF-wet dream. If that happened I wouldn't sleep until I had written a super awesome, multithreaded efficiently-cached BC pathfinding algorithm.

Unfortunately A* isn't very parallelizeable. A route cache would improve performance tremendously though. (Someone else in the suggestions forum ran a simulation and was getting orders of magnitude improvement over non-cached pathing.)

[Footkerchief]

May I suggest discussing the pathing parallelizations in this thread which was just created a few days ago for that topic?

[shaver]

Unfortunately A* isn't very parallelizeable.

It doesn't really have to be, given that DF could path multiple dwarves/creatures concurrently rather than parallelize the planning of a single path.  Intel's TBB would be helpful if it weren't GPL, but John Ratcliff's JobSwarm is probably a good start.  Could also be applied to parallelizing pressure calculations, temperature effects, etc.

That said, I much prefer the "do less" model of route caching and hierarchical path planning to the "do just as much in a shorter period of time" model of parallel path planning, given DF's insatiable CPU-and-therefore-battery hunger.

[Jurph]

Back with more info ASAP.

Back to 178ish, things are working nicely.  I'm going to give my machine a thorough purging (kill off unneeded drivers, software, etc.) and try to upgrade later in the week.  For reference, 40d9 runs at ~25 just like the other 40d versions.  I haven't bothered with adjusting the NO(2)/NO/NO settings because they didn't make a difference for 40d6.

[Udib Gasolbomrek]

(running d9 on an iMac G4@1GHz (ppc7450) w/ NVIDIA GeForce4 MX):

I've been getting some intermittent key-press problems.  Nothing major, although I did once end up in a lengthy loop of saving / re-launching the game when I tried to quit that I suspected was due to keystrokes building up in the buffer.  The main problem is that shift-A, in particular, requires several tries before it 'takes'.  Cursor control is a bit more stately than with the baseline version.

There seems to be a definite pattern to the partial print flakiness (which is much higher in d9 than d-baseline);  some game screens are far, far more likely to experience problems than others.  Would the details regarding which be of diagnostic use to either Toady or Baughn?

[Baughn]

I'm looking into the key-press problems; I've got yet another different way to handle that I'm going to try that might work better.

It's not as obvious why partial-printing might be acting up more in 40d9 than 40d, as the algorithm used is exactly the same; all I can think of is that we now specifically ask for a double-buffered window (unless otherwise configured), whereas 40d was happy with anything.

Partial-printing doesn't work for me without the framebuffer toggle on, at all, so I can't really test it.

[bhelyer]

For what it's worth, baughn, I run PP:YES:0,FB:NO,SB:NO on my machine, and there is no flickering to speak of.

[Veroule]

Well I think I have finished all of my study of the code in BC.  I realized that a number of the smal, simple, obvious optimizations would have no effect on DF gameplay.  They would effect the framerate for other screens like the menu, units list, stocks, etc.

After searching everywhich way imagineable I also cam to the conclusion that the partial print code is only used in the main fortress mode screen in DF, so there is very little we can do with it in BC.

The other wonderful conclusion I came to is the keyboard routines that are spanned over 3 different files are doing 5-10 times the amount work that is actually necessary to track keypresses.  Since some of those routines are called with every frame at a low level, optomizing in this area will have a solid impact for all screens in DF.  I will probably have to completely gut all the keyboard code in order to make it right.

[Mel_Vixen]

 [...] realized that a number of the smal, simple, obvious optimizations would have no effect on DF gameplay.

Please submit them anyway to toady or Baugn. Many of us have older Computers that would like one or two FPs more.

[DavesWorld]

Please submit them anyway to toady or Baugn. Many of us have older Computers that would like one or two FPs more.

Yes please.
Optimization good.

[Gertack]

My goal is to optimise everything I can find a faster way for in the BC code.  Some of that code is directly used by DF which is the entire point of this project and topic.  Other parts may provide Toady and idea about how to do things better in DF.

Unfortunately BC doesn't have DF's pathfinding code, right? That seems to be where the real bottleneck is for those of us with decent graphics cards. Any chance Today could release a BC-like program with pathfinding?

Indeed. My 230-pop fort is likely dying by pathfinding and 0 FPS isn't very playable except by leaving it running overnight.  I linked it in my comment in this thread, but I have no access to profiling DF or to write code to make whatever the bottleneck is faster (I'm a programmer).

40d9 has the curious property of using 100% of one core and 50% of the other core in my 2-core system, although it is still at 0 FPS so I can't tell whether it has sped anything up in practice.

[bhelyer]

Debugging BC shows that a few threads are spawned that aren't started by us; FMOD comes to mind. One of those things is probably running on the other core, contributing nothing to the running of your fortress but sweet, sweet music (perhaps). Or not; what would I know?

[Ampersand]

I think even if the most we could do is have two pathfinding jobs done at the same time, that would be a considerable improvement. Just think of the difference between a 200 pop fortress and a 100 pop fortress.

[Areyar]

40d8 worked fine for me up till now.

I've only made a few changes to the keybindings (for laptop use) over the weekend, (game is on portable HDD.) .

Just now when I tried to run the exe, the opening screen (demo == off) stuck at 0fps and 100%CPU use.

Don't have any more time to investigate right now.

edit:
I've checked some. The game will run normally on another laptop.
Also rebooting or shifting with F11, does not resolve issue.

Have to check whether starting in fullscreen/windowed mode makes a difference, as I played only FS on LT and only tried to run windowed on the tower....
both ways worked fine before changing keybindings for /,* to -,= though.

in any case a weird bug. (which has nothing to do with having multiple worlds I assume)

2: had some weird graphical freakout when the envoy opened a negotiations screen while I was designating an area.

SOLVED: setting FRAME_BUFFER to OFF, resolves my 0FPS problem.
(Forgot I changed this at the same time as the keybindings.)