Print

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

Faster, no (unknown) problems

Faster, problematic

Same speed, no (unknown) problems

Same speed, problematic

Slower, no other (unknown) problems

Slower, problematic

Doesn't work at all

[Scarpa]

Ran into an odd occurrance last night, thought it'd be worth reporting.

Running Window 7, d19, custom tileset and whatever the init defaults are for rendering.

Was at the trade depot selecting goods to haul to the depot and I accidentally hit F11 instead of F9 to exit. This triggered fullscreen but the tileset seemed to revert to the default curses charset, or at least the tileset I was using was stretched to the default curses size (I use a 9x9 charset). This itself wasn't a big deal but then when I hit F11 to get back to windowed mode a dialog box popped up that it couldn't find some curses...bmp file, I didn't catch the exact filename. After hitting OK the DF window disappeared and I had a mild panic attack thinking the process had stopped. Fortunately DF was still running in taskbar and while I couldn't restore it I could maximize it which seemed to clear everything up. I then saved and restarted the process to make sure nothing nasty popped up later.

If this isn't already a known issue or you need a better bug report I can try to reproduce it tonight.

[Baughn]

I've rewritten async mode (and, incidentally, the timer code) so helgrind's happy now.. and it's taken the effective CPU use of the graphics code to, apparently, 0%.

Yep. If you've got a dual-core, you'll be looking at a pretty solid speedup. If you're not.. well, actually you might still get a speedup (the reasons are pretty complex), just not as big of one.

I'm dropping shader mode, though. There's just not any point in having it anymore. This works better.

Veroule: Can you try the newest matrix version? It's not quite done (still got three sets of arrays, two would do nicely), but that shouldn't matter for speed/stability tests. I know it sometimes fails to quit, but that seems to be the only problem; still, please check. (And switch the loop in tetris.cpp for SDL_Delay, I guess, since that's what failed last time)

For benchmarking purposes, the last pre-async commit was d27b0bfa60946bf30288710974c58a8bb40322e3.

[Slinkyfest]

Well, its been well over a year since I seriously played dwarf fortress, I was just wondering who I should ask to update the speed optimizations in the df wiki

http://df.magmawiki.com/index.php/Maximizing_framerate

It is rather outdated. Admittedly, they did not have this lovely gang of individuals banging out code to make DF go supersonic, but I like to squeeze out what little fps I can, as it all matters when you hit 200 dwarves and have a fully fledged fortress. So, again, apologies if this is the wrong spot for it.

[Huin]

- Bridge linking is broken.

Isn't this fixable by changing the interface.txt to avoid "linking bars" using just "b" but to use "Alt+b", such as this:

[BIND:HOTKEY_TRAP_BARS_FLOOR:REPEAT_NOT]
[KEY:Alt+b]

I haven't tried this in d19 yet, but I think it fixed it for me in a prior d1x release, maybe d17 or d18.

[Veroule]

I am pulling the new matrix branch in for testing now.  I started reading over the commit and I already see a problem.  Line 323 of enabler.cpp "SDL_Delay(milliseconds);".  If you recall the reason for switching to a timer from exactly that sort of calculated delay was that Windows doesn't respect a delay of <10 ms.  This causes all users on Windows to get lower frame rates.

Nothing really stands out as being hazardous to threading synchronizations, but it does look like there a number of unnecessary calculations being done.

[Baughn]

They're per-frame calculations. Per-gframe, even. A couple extra floating-point ops won't be noticable there.

As for windows.. Though I'll probably use that method mentioned earlier to reduce the timer granularity, only the renderer thread is delayed by this. The simulation thread allows itself a buffer of up to three seconds; if the renderer thread is delayed, the buffer just expands to fit, and it keeps going at max speed.

[Veroule]

That sounds like a good plan, and is very sensible.  I like it.

First blush is that it is faster.  I took out the slowing loop in the logic for a top speed test and it is much better than what I had put together.

I did encounter a lock up from the synchronization.  You should be able to replicate it.
Click the X to bring up the keybinding screen.
Click the X to bring up the keybinding screen.
Click the X to bring up the keybinding screen.
Move selector to 'exit & discard'
Press enter to select
Press enter to select
Press enter to select
Press space to exit program

It should lock during that exit.  2 bugs, `1 is the lockup, the other is that the keybindings screen can be repeatedly added.  To correct the second add "virtual char is_option_screen(){return 1;}" to the header for the screen.

I am out of debugging time for the morning, but will look deeper this afternoon.

[Baughn]

Once again I couldn't replicate your lockup. This time helgrind is also completely clean, so I have nothing to go by.

I hope you'll be able to figure it out. I'm going to keep looking, but I'm not very optimistic.


EDIT: I figured it out, I think. Try now?

[Veroule]

Got latest, testing now.

[Baughn]

It wasn't quite fixed, but should be by now.

[doomcup]

Sorry to say, it's not working for me on 64-bit Arch Linux. I made the sorry decision to build my rig with an ATI card, and thus am using the free drivers, which Dwarf Fortress balks at for some reason.

Yet another game I have to keep windows around for, I say pretending to be suprised 9_9

[Baughn]

Use PRINT_MODE:2D.

[Veroule]

*sigh*
RE commit "Remove the pointless concept of spare gps arrays and swapping":  Go look at the code I sent you; particularly renderer:display.
On to the only consistent bug found so far.
Zooming out with scroll wheel occasionally crashes.  Sometimes it just screws up the drawing.  It will crash if you do it a few more times.  This is a problem with the async, from the first version I tested through all revisions.

[Baughn]

Sure, your code is where I got the inspiration for that. I pointed it out earlier, even.

An yes, all the enabler calls used to resize the grid haven't been rewritten to handle async yet. I'm working on it.

[vyznev]

Line 323 of enabler.cpp "SDL_Delay(milliseconds);".  If you recall the reason for switching to a timer from exactly that sort of calculated delay was that Windows doesn't respect a delay of <10 ms.  This causes all users on Windows to get lower frame rates.

The generally recommended way to deal with unreliable timed delays (which, let's face it, they all are) is to keep track of how much time you've actually spent and adjusting the delay based on that.  Like this (in pseudo-C):

Code: [Select]

time = getCurrentTime();
while (condition) {

    doSomething();

    time += timestep;
    delay = time - getCurrentTime();
    if (delay > 0) {
        sleep(delay);
    } else if (delay < -bailout) {
        time -= delay;  // just can't keep up :(
    }
}
For interactive apps like DF, a reasonable value for the bailout limit is something on the order of the human reaction time: say, 0.25 seconds.

(Ps. Apologies if I'm just stating the obvious here.  I haven't looked at your code, so I don't know if you're doing something like this already or not.)