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]

Don't suppose you found any solutions?

snooptodd: Try disabling compiz, or better yet disable compositing entirely. That could be interfering; ISTR there was some issue with double-buffering not working under compiz.

Oh, and you could /turn off/ double-buffering in init.txt by turning single-buffer on, which might also work. Actually, try that first.

[numerobis]

You don't seem to be using the system keyrepeat rate, which indicates you're actually figuring out keyrepeat all by your lonesome.  Also, sometimes a key 'sticks' and I can unstick it by hitting the key again, which indicates etc etc.  Is there a strong reason to do this -- i.e. isn't that something OpenGL or SDL or whatever should be dealing with?

Another thing, it seems like a game frame goes by every time I hit a key -- so I get meetings occurring while paused and so on.  Once again, I'm not entirely convinced of my diagnosis, but if so, that seems like a bug.

[Exponent]

Another thing, it seems like a game frame goes by every time I hit a key -- so I get meetings occurring while paused and so on.  Once again, I'm not entirely convinced of my diagnosis, but if so, that seems like a bug.

That's been a long-standing problem which doesn't seem to have anything to do with these graphic-code versions.  (Bug 768)

[Baughn]

You don't seem to be using the system keyrepeat rate, which indicates you're actually figuring out keyrepeat all by your lonesome.  Also, sometimes a key 'sticks' and I can unstick it by hitting the key again, which indicates etc etc.  Is there a strong reason to do this -- i.e. isn't that something OpenGL or SDL or whatever should be dealing with?

Yes, SDL doesn't have quite the right behaviour when dealing with key-repeat. I used to have it do all the work, but then if you pressed a, pressed b and then released a, b would never repeat - annoying for arrow keys.

The code in 40d9 is still somewhat buggy, though. Patches were sent to Toady a very long time ago; I guess he'll get around to them once the next release is ready.

[snooptodd]

Don't suppose you found any solutions?

snooptodd: Try disabling compiz, or better yet disable compositing entirely. That could be interfering; ISTR there was some issue with double-buffering not working under compiz.

Oh, and you could /turn off/ double-buffering in init.txt by turning single-buffer on, which might also work. Actually, try that first.

ok, it works this morning.
there must have been a fix uploaded yesterday unfortunately im not getting local mail so i cant tell what was updated.
i did see a post over at the ubuntu formus that seems to confirm my suspicion.

edit:
yep sdl was upgraded
[UPGRADE] libsdl1.2debian 1.2.13-4ubuntu2 -> 1.2.13-4ubuntu3
[UPGRADE] libsdl1.2debian-alsa 1.2.13-4ubuntu2 -> 1.2.13-4ubuntu3

[MuonDecay]

Wow, I just now get around to trying this.

You know what? It's great! It's noticeably faster, even on a computer with a powerful video card. I guess the DF graphics were just shoving more data than necessary through my CPU bottleneck.

And as a bonus side effect, there is no longer a 3-5 second delay when I switch between DF and another windowed game. Now it's instantaneous. Handy.

[numerobis]

Yes, SDL doesn't have quite the right behaviour when dealing with key-repeat. I used to have it do all the work, but then if you pressed a, pressed b and then released a, b would never repeat - annoying for arrow keys.

Ewwww.

Do the patches you sent include attempts to figure out the system keyrepeat rate?  It seems to be queryable via SDL_GetKeyRepeat(), maybe.

[Baughn]

No, it's set via init.txt, same as for 40d.

[Topace3k]

Just stopping by to say that 40d9 with Yes:0 No No brought my 100+ dwarf multifeature fort currently in the midst of the massive HFS slowdown up from a crippling ~14 fps to a painful but bearable ~25 fps.  Thanks!

[Flok Speargrabber]

So I boot this up and load up a fortress that gave me ~50 - 70 FPS on .40d.
I get ~ 10 - 20 FPS on 40d9.
The fortress itself is a decent one; 2x2 with 101 pop, and ~11 animals.

Computer specs:
Windows XP
Pentium 4 Processor 2.8 GHz
2.12 GB RAM
ATI Raedeon 9800 PRO
I think that's all the relevant information?

[Topace3k]

What kind of frame refresh combination are you using from the init?

[Flok Speargrabber]

What kind of frame refresh combination are you using from the init?

[FPS_CAP:100]
[G_FPS_CAP:50]

[Topace3k]

What kind of frame refresh combination are you using from the init?

[FPS_CAP:100]
[G_FPS_CAP:50]

I meant this section:
[PARTIAL_PRINT:YES:0]
[FRAME_BUFFER:YES]
[SINGLE_BUFFER:NO]

[Random832]

Well, yeah, but you're supposed to run the scripts, not dwarfort.exe directly.

I named it that specifically *because* unix users tend to assume executables shouldn't really be named .exe. Perhaps I should put it in a libexec subdirectory instead.

The convention for executable binaries that aren't supposed to be started directly (firefox, openoffice, etc) is to name it ending in -bin (and name the shell script with no extension)

[Flok Speargrabber]

What kind of frame refresh combination are you using from the init?

[FPS_CAP:100]
[G_FPS_CAP:50]

I meant this section:
[PARTIAL_PRINT:YES:0]
[FRAME_BUFFER:YES]
[SINGLE_BUFFER:NO]

I can't find that in the init text file.