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

[Andir]

The zooming code has been completed, a remaining texturing problem has been fixed (fixing the odd border glitches), and a patch has been sent.

Meanwhile, the code is immediately available for you Linux users, if you see the HEAD link in the first post. You'll like it, I promise.

Is it really supposed to do this?

Spoiler (click to show/hide)

Spoiler (click to show/hide)

It even does it in full screen now.

Also, after closing it, Gnome thinks my desktop is only half height... if I maximize a window, it only fills the top half of the screen.  I can expand a window into this space, but upon maximizing... it's half height.

Example:  (Iceweasel is maximized...)

Spoiler (click to show/hide)

[Impaler[WrG]]

Windows version works for me, window expansion is working nicely but zoom has some usability issues.  First the responsiveness of the scroll wheel is too low as it seems to take several 'clicks' of the wheel before zooming outward begins, second the tile graphics darken dramatically even after the smallest amount of zooming and third the whole of the UI shrinks right along with the map window (though you seem to already be working to address this).

Keep up the good work guys!

[Organ]

Holy christ you can adjust window size on the fly now! That's awesome.
Still, the keyboard input isn't working exactly like 40d9. I am using an alternate layout called Colemak, on a qwerty keyboard.
Now the game seems to take most of the input correctly, except some, where it reads me as pressing the qwerty equivalent. An example is at the embark screen, the physical N on my computer should be 'K'. But when I press the N key (expecting the embark square to move down), the game wants me to make a note. The interesting thing is the physical 'J' key, which should be N, reads as N, and also prompts me to make a note. There are other examples of this in the other menus as well. I think d12 is getting most of the keyboard input from the right place (i.e. after the conversion from qwerty to colemak) but then for some keys it's looking a little too early in the chain and reading the physical qwerty keypress. That's my 100% layman's blind guess as to what's happening. Anyway thanks so much guys for working so hard at this. I know the easiest fix is probably me just switching back to qwerty, but I thought I should let you guys know to see if anything could be done for d13.

[Baughn]

Shrinking the entire UI along with the map is unavoidable. The only thing I can do is alter the grid size; Toady's code decides what to do with it.

The darkening effect is unfortunate. I'm not sure there's anything to be done about it per se; it's an effect of the linear interpolation GL uses. However, you could change the interpolation from linear to nearest in init.txt; that cures the darkening, but to me it looks worse in other ways.

Andir: No, it should never do that. I apparently failed to consider what would happen if BLACK_SPACE was on, so good catch.

Of course, what happens to your desktop shouldn't happen either way. Are you running compiz by any chance?

[Baughn]

Andir: Assuming the problem actually is caused by me, I've put up a new 40d12-head that probably fixes it. Could you test it?

[Baughn]

About the performance problems: For some reason the sound thread gets jammed, sucking up 100% of the cpu time.

I'm looking into it, but meanwhile you could turn sound off, see if that helps.

EDIT: It happens specifically when DF tries to get hold of the sound device, and fails. Should be a pretty simple fix, though firefox does the exact same thing. ^^;

Anyone got performance problems where sound in fact works? Or is turned off?

[Draken]

I found that some one earlier had a similar problem,
but I couldn't find anything more than "It shouldn't happen"
I get an error telling me that 'Index' should be in the 'data' folder. It is.
If I replace it with the index file from vanilla Dwarf Fortress (which I wouldn't expect to work...) then it doesn't complain, but then has only a black screen.
This makes me think it is something wrong with the Index file, but I could be wrong

Vista Home Premium SP1
ATI Mobility Radeon

[Baughn]

That occasionally happens if you unzip a new DF on top of an old one. Don't.

If you didn't.. complain to toady? Except it seems to work for everyone else, so.. your download may be corrupt?

[Draken]

Cheers. 
A re sizable window is something that I think this game really needed, Nice work

[Baughn]

Zoom not functioning with framebuffers/partial-printing has been fixed. Um. Yeah. If it wasn't working for you, try standard mode.

Or, as usual, the linux 40d12-head tarball.

There's still some (temporary) graphical corruption in partial-printing mode. I'm looking into it.

[Andir]

Andir: Assuming the problem actually is caused by me, I've put up a new 40d12-head that probably fixes it. Could you test it?

Tested, and it's fixed.  I didn't know it was the blackspace that made it disconnect from the edge like that, but on or off it now works as intended I believe.  No ghosting with it on, and it zooms perfect with it off.  I have not tried with compiz enabled.  It has always screwed up DF before.  I don't have it installed right now so I can't test it.  If you want, I can load up DF on my Ubuntu box and see what happens... maybe later today I'll try it anyway.

Edit:
About that graphical bug in partial print... I noticed that each tile glitches for a second if you move the window with the latest HEAD version.  I'm assuming these are tied together, but I cannot get it to glitch in partial:2 on my machine.  if I move the window it glitches then fixes itself.

PS, sound doesn't seem to affect the performance for me.

PPS, I noticed that if you keep scrolling after it has reached the extents, it continues to count up the zoom even though it's not zooming anymore.  You have to zoom back out as much as you did to get back to zooming in if that makes sense.  Um... if I zoom out 100 times, DF stops at 25, but the zoom value is still 100.  I have to zoom back in 75 times before DF responds to the zoom in.

[Baughn]

I'm aware of that last problem.. working on it as we speak.

Using partial:2 fixes the glitchiness for me as well. I get it with partial:0.. there shouldn't be a difference, but.. well.

The sound problem happens specifically if sound is on, but it fails to initialize in some way. I've failed to reproduce it after first noticing it, however; it's probably linked to some confusion in the sound driver. Eventually it'll happen again, and then I can debug it.

[Andir]

Tested another 10 times or so, save and restart, sound off/on and can't get sound to influence performance.  When I first ran it, there was noticeable input lag (2-3 seconds) but I thought it was switching to frame_buffer that fixed that.

Also, partial:0 is working fine for me.

x64 Debian on Thinkpad T61 with Intel GMA X3100 in case it matters.

[Baughn]

Right, as I said it's probably a combination of driver bug and DF bug. Fixing it anyway.

[Baughn]

And patched. Zooming is now prevented beyond the limit of what actually affects the display.