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]

You can also edit the key bindings, but yeah, known problem. It's not entirely obvious how to fix it. (Not least since I don't have a french keyboard - no, changing the X11 keyboard mapping is *not* the same thing.)

[Ter13]

To be fair, Nvidia's most recent cards are sucking hard on the OpenGL support. I upgraded from a 6800GT to an 8800GTX, and found my opengl games running 20FPS slower.

I then upgraded to an ATI 4870, and found that it was doing well, just not as well as I could hope.

The new Nvidia chipsets are really leaving much to be desired in openGL mode as well, but not as much as ATI. Really, with both, the difference is marginal.

[JimiD]

First of all, Hi, I'm new to this forum and to df, but not new to roguelikes: I've caught on pretty quivk and learned to navigate the interface well. I've tried 40d11 just last night, but it wasn't much faster than 40d with PARTIAL:0 and SINGLE_BUFFER:YES , as well as G_FPS_CAP:20. I have chosen a site that had moderate mountains and a brook running through it (with one small water fall), and my map was 6x6 tiles in the local view of the selection screen. Altogether, even with my FPS_CAP at 1000, my comp runs it at about 80-110, with only my seven dorfs. I am trying to find the best combination of init.txt tweaks to help me get the most speed for the game without sacrificing weather, temperature, etc.My HP comp has an Intel 1.6GHz processor, has 520mb SDRAM, and runs WinXP SP2. Please help?

I have a 1.3Gz and 730 odd MB of RAM, and dont get 80-110!

So dont worry too much now.

You can easily play DF, but it will slow down if you have too much stuff going on at once:

- 100+ dwarves
- Weather
- Temperature
- Flowing water (and mamga?)

With all of the above, my FPS drops to above 10.  With only 100 odd dwarves, 20-30FPS which is still plenty playable.

Weather has a big FPS saving if you turn it off, but you loose ponds refilling, and potentially seasonal freezing?
Temperature excludes freezing and magma, but seems to have a good FPS saving too.
Flowing water and magma are fun, and save a bit of FPS - having a running waterfall is very FPS damaging to low end machines.

So, depending on where you are embarking, and what you plan to do, tune your init file to suit.

Buying a new PC is easier, but costs a little more...

[Random832]

You can also edit the key bindings, but yeah, known problem. It's not entirely obvious how to fix it. (Not least since I don't have a french keyboard - no, changing the X11 keyboard mapping is *not* the same thing.)

Well, all physical keyboard hardware itself sends identical signals, except for extra keys not present on US101 (and except for USB vs PS/2 of course). Unfortunately, the key between left shift and ZW is precisely that extra key.

Geekman, please post the output (output goes to the xterm you start it in) of the program "xev" when you press the </> key in it.

[Geekman]

KeyPress event, serial 33, synthetic NO, window 0x2e00001,
    root 0x1a6, subw 0x0, time 79361306, (480,242), root:(485,291),
    state 0x11, keycode 94 (keysym 0x3e, greater), same_screen YES,
    XLookupString gives 1 bytes: (3e) ">"
    XmbLookupString gives 1 bytes: (3e) ">"
    XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0x2e00001,
    root 0x1a6, subw 0x0, time 79361441, (480,242), root:(485,291),
    state 0x11, keycode 94 (keysym 0x3e, greater), same_screen YES,
    XLookupString gives 1 bytes: (3e) ">"
    XFilterEvent returns: False

[Random832]

OK, there's the keycode - 94. At least, on X86 and whichever of PS2/USB you're using. But all this raises the question of why DF doesn't simply look at the keysyms (and thus not have any issues with other layouts) in the first place.

[Baughn]

Because the input code is a tentacled horror, that's why.

It was originally written for windows.. it didn't /have/ keysyms in the unicode sense, plus some things (like shift-2 being @) are hardcoded and would take a whole lot of work to fix.

[Earthquake Damage]

You can easily play DF, but it will slow down if you have too much stuff going on at once:

- 100+ dwarves
- Weather
- Temperature
- Flowing water (and mamga?)

Add "Cave-ins" to this list.  It makes a huge difference in FPS for me.

[Behrooz Wolf]

I've noticed some odd control effects in 40d11 when dealing with rapid series of keypress inputs.

Specifically, when multiple keypresses are entered rapidly while moving through different areas of the interface, some of the commands appear to be either lost, or delayed.  This causes things like an autohotkey script that digs a pattern of 30 detailed rooms to go absolutely haywire.

Try putting lthis line at the top of your script:

Code: [Select]

SetKeyDelay 25,, Play

That sets a default delay of 25 milliseconds per keypress/release.  More importantly, it changes all Send commands to SendPlay commands, which in my experience are more reliable.

Last minute edit: this is assuming AutoHotkey.

That works... if you set a remarkably high delay.  For some operations such as placing furniture or anything else that's heavy on the interface, I begin to lose inputs with a script input delay less than 400 to 500ms... which renders scripting pretty useless.  Definitely not optimal, I've just gone back to 40d as the serious command lag isn't worth the slight graphical speedup.

[Baughn]

I've only just now started reading the keyboard code used in 40d10/11 (which wasn't written by me), and there's definitely something deeply unnatural going on. I'll see what I can do.

In the meantime, you might want to try 40d9, which IIRC doesn't have that particular problem.

[Veroule]

You can also edit the key bindings, but yeah, known problem. It's not entirely obvious how to fix it. (Not least since I don't have a french keyboard - no, changing the X11 keyboard mapping is *not* the same thing.)

Well, all physical keyboard hardware itself sends identical signals, except for extra keys not present on US101 (and except for USB vs PS/2 of course). Unfortunately, the key between left shift and ZW is precisely that extra key.

Geekman, please post the output (output goes to the xterm you start it in) of the program "xev" when you press the </> key in it.

Because the input code is a tentacled horror, that's why.

It was originally written for windows.. it didn't /have/ keysyms in the unicode sense, plus some things (like shift-2 being @) are hardcoded and would take a whole lot of work to fix.

To further expand on what Baughn said; all the original DF code was designed and based for Windows, and uses Windows Virtual Keycodes.  When the SDL library was added to make multi-platform support possible a translation table was also made so that Toady wouldn't have to make further changes in the portions of the code we can't see.  That translation table goes from the SDL_keysym.sym to the Windows VK_*.

Now that there has been a lot more testing on other platforms we have a better idea what the exact problems are.  I am working on quite a few ways to further simplify the keyboard code and make more stable.  One of those things is eliminating the sym to VK table, and rewriting some portions of the mid-level classes to handle it.

Because I can't completely determine where the problem with different layouts and languages comes from I will be adding some debugging stuff for d12.  I am not sure how far I will go with the debugging stuff, but I will try bypass the SDL while the debug reporting is enabled.  I should be able to do it on the Windows build without any trouble, but the number of reports of layout problems with Windows is much less then Linux and OSX.  The extra information should allow for a final solution, please be patient it make take quite a few more versions to be fully sorted.

[Baughn]

Then there's what I just asked Toady about, which I can't believe we never suggested before..

If we make the graphics code into a DLL, we'll be able to release and test patches *without* having to go through toady. Not to mention test our own incremental changes on DF instead of BC.

Of course it won't always work - header changes are an issue, though not an insurmountable one, but.. How's that?

[bhelyer]

Then there's what I just asked Toady about, which I can't believe we never suggested before..

If we make the graphics code into a DLL, we'll be able to release and test patches *without* having to go through toady. Not to mention test our own incremental changes on DF instead of BC.

Of course it won't always work - header changes are an issue, though not an insurmountable one, but.. How's that?

Genius, sir, genius.

[Veroule]

I am all for that as well.

When I look through the code that comprises the totality of BC I see large amounts of 'dead wood'.  However it is very difficult to determine if some portions are really dead in DF.  Getting rid of all that dead code would make improving and maintaining the interface so much easier.

[Mel_Vixen]

A little question: Is the Sound-code also included in BC?